【米SVPG社 翻訳記事】傭兵のチームと宣教師のチーム

‍

　作者：マーティ・ケーガン

　翻訳者：インターンスタッフ（アーテリジェンス）

１、傭兵のチーム　vs、宣教師のチーム

ジョン・ドーア氏の名言

「我々は傭兵のチームではなく、宣教師のチームが必要だ。」

これは、伝説的なVCであるジョン・ドーア氏が残した、プロダクト業界で私が一番好きな名言の一つです。この名言には多くのことが集約されており、強いリーダー、組織、そしてプロダクトチームの核心をついています。

例えの解説（傭兵のチームと宣教師のチームの違い）

傭兵のチームと宣教師のチームという二つの例えを理解するのはそこまで難しくはありません。宣教師のチームはモチベーションが高く、ビジネスのコンテキストを深く理解しており、顧客目線で物事を見ようとしています。対して、傭兵のチームは責任感がない、エンパワーされていない、意欲のない、顧客との関係性がほとんどないチームです。

今までの私の経験から、宣教師のチームと傭兵のチームはモラル、スピード、そして結果全てにおいて比べ物にならないほどの差があると言えます。

２、傭兵のチームになってしまう３つの理由

ではなぜより多くの企業が宣教師のチームモデルを取り入れないのでしょうか？主に３つの理由があると考えます：

リーダーシップ

非常に多くの幹部職やステークホルダーたちは、自分たちが正しいと考え議論の余地を与えません。そして彼らの方針に従うだけのチームを求めます。これらのリーダーたちはよくチームの動きが遅く、そして詳細まで隅々説明しなければ違うことをやってしまうと私に相談してきます。粗末な結果が自分の責任だと考えることは滅多にありません。

人事

宣教師のチームの重要性をしっかりと理解しているリーダーもいます。しかし、彼らは傭兵のチームが形成されてしまう組織体系の中で働らかされている場合があります。例えば、チームのデザイナーやエンジニアを積極的にアウトソーシングしているケースでは、宣教師のチームを作ることは困難です。なぜなら、彼ら他の会社で働いていることがあり、言われたものを作るという契約を結んでいるからです。これは傭兵の典型例で、大きな無駄につながります。

プロセス

世に出回っている複数のプロダクト開発のプロセス、特に「法人」向けに作られたと言われているような開発プロセスは、傭兵のチームのモデルに基づいたものが多いです（誰もこのような紹介の仕方はしませんが）。例えば、SAFeについて何人かが私に問い合わせたことがありますが、いつも私はSAFeは二流が使うプロセスだと答えています。なぜなら強いプロダクト企業でSAFeを使っているところを一つも知らないからです。そして、SAFeについて様々なことを聞き、読みましたが、継続的なイノベーションを必要としているテクノロジープロダクト企業にとってこれ以上にひどい開発モデルはないと言えます。対照的に、Spotifyが掲げるスケールを考慮したアジャイル開発プロセスは私が是とする考え方に沿っており、これは宣教師のチームのモデルに基づいたものだと考えています。

３、傭兵のチームから宣教師のチームへと、どのように改革を行うか？

３要素の相関関係

上記の3つの要素には相関関係があります。大抵一つの要素に問題があると、時を経るにつれてまた別の要素の問題を引き起こします。組織改革を行う際も、この３つの要素が改革の中で一番重要かつ難しい課題となるでしょう。

改革の手法（１、リーダーシップ　２、人事　３、開発プロセス）

では、その改革をどのように行えばいいのでしょう？

それは３つの要素から始まります：

まず、リーダーシップチームを教育する必要があります。

次に、スタッフのスキルレベルを上げる必要があります。プロダクトマネージャーを始め、プロダクトデザイナー、そして少なくともシニアエンジニア・テックリードまでの水準を上げましょう。チームの構造がこのような形でない場合には、より強固な、領域を横断したプロダクトチーム（Spotifyの言葉を使うのであれば「スクアッド」）に積極的に改造するべきです。

最後に、チームを最大限に活かせるプロセスやテクニックを取り入れることが必要です。これにははかなり労力を割かなければなりませんが、まずは組織とそれぞれのプロダクトチームのために魅力的なプロダクトビジョン、そして測定可能な成果目標を設定することから始めましょう。

もしあなたの組織が宣教師のチームではなく傭兵のチームのように動いているのであれば、真剣になぜこのような状況になっているのか、また改善するための改革を起こすことが可能なのかを考えるべきです。

‍