ツー・ピザ・チームは始まりに過ぎない – パート2: 高パフォーマンスのアジャイル組織はアカウンタビリティとエンパワーメントがカギです

前回のブログ記事では、プロジェクトへの従来型のアプローチとスキルベースのチームが、高パフォーマンスなアジャイル組織になる事を妨げている理由についてお話ししました。高パフォーマンスなアジャイル組織とは、迅速にイノベーションを実現し、素早く市場に新しいアイデアを投入し、短い時間で高度なテクノロジーを使ったソリューションを展開できる組織です。

答えは何だったでしょうか？ 明確な線引きのされた説明責任（アカウンタビリティ）と権限と環境を与えること（エンパワーメント）が高パフォーマンスなアジャイル組織には必須だということです。行動する事を奨励されその権限を与えられている環境では、説明責任を持つ従業員はチームの目標に沿ってワークロードを管理し、必要な時には積極的に支援を求め、ミスを犯したときには責任を取ります。これはマイクロマネジメントの対極です。

私自身の経験や、多くの企業と協力してデジタルトランスフォーメーションを進めてきた中から、私は企業が高パフォーマンスなアジャイル組織になるための4つの重要な特徴を見つけました。

シングルスレッド・リーダー

シングルスレッド・リーダーとは、モバイルアプリケーション、顧客アカウント、または電子商取引ストアの検索機能など、特定のプロダクトに対して、完全に専任で、説明責任を持つリーダーです。シングルスレッド・リーダーは、戦略を実際の成果に変える責任があり、その為の権限と環境を用意されています。

戦略的なイニシアティブを最も鈍らせてしまう方法は、誰かの兼務の仕事にする事です。これは、一見、望ましいやり方に見えます。CIOがイニシアティブが重要だと宣言しても、初めから終わりまで自主的に行動して結果を出すための権限と環境が、誰にも与えられていません。全員が他の誰かが行動することを期待しています。ここで、シングルスレッド・リーダーが登場します。

私はチームが成功するか否かにおいて最も重要な要素は、リーダーの強さ、リーダーがチームに時間を費やすことができるか、そして、リーダーがチームを率いる為の権限を与えられているか、であることを発見しました。

あなたのチームとプロジェクトの全体を見て、シングルスレッド・リーダーが居るかを確認してみてください。チームリーダー達は一つの活動に専念していますか、それとも複数のプロジェクトや製品に取り組んでいますか？ 彼らは問題を解決し決定を下し、結果をもたらす権限を与えられていますか？それとも、官僚主義の壁をよじ登って、承認を得たり調整事を行ったりする必要がありますか？

未だであれば、チームをシングルスレッド・リーダーのモデルに変更してください。チームリーダーが、上長達の承認を得るために走り回るのではなく、チームを率いることや製品についての意思決定の為に時間を使える様にしてあげてください。

リーダーについてのトピックの最後として – これが最も強調すべき事ですが – もしあなたが調整役（リエゾン）やパートナーを多用するモデルを使っている場合、彼らがどの様な効果を出しているかをしっかりと見てください。彼らは、ほとんどの場合、責任も権限も持たない状況に居ます。シングルスレッドから程遠い状況ですが、それが彼らの責任であるとは限りません。彼らが担うべき役割を考え直してください。彼らがシングルスレッド・リーダーになれば、ビジネスに対してもっと大きな価値を引き出せるはずです。彼らに専有できるリソースと、明確で集中できる責任と目的を与えてください。

単一のアプリケーションやサービスを中心に構成された小さな専任のチーム

シングルスレッド・リーダー達は当然、単独では成り立ちません。彼らは、多様な知識とスキルを持つ人々で構成され、コミュニケーションにかける時間は少なく、行動に多くの時間を使う、専任で学際的なチームを率います。彼らのチームは、コードの納品、テストの完了、新しい基準の作成、といった偽りの進捗状況には目を向けず、安定したコードの開発にほとんどの時間を費やします。

「コンウェイの法則」という言葉を聞いた事があると思います。これは、「組織がシステムを設計する場合、生み出される設計は、その組織のコミュニケーション構造に制約される」というものです。つまり、あなたのシステム設計は、あなたの組織構造とほとんど同じ形になります。簡単に言えば、もしあなたがレガシーなスキルベースの組織を維持するのであれば、システムをモダンなマイクロサービスに移行するのは難しいでしょう。実現させようとするのであれば、組織の設計から再考する必要があります。

そうではなく、お客様の視点で製品を見てみましょう。小さなチームをプロダクトを中心にして組織してください（「プロダクトチーム」と呼びましょう）。彼らの担当領域を明確にし、専任のリソースを与え、明確な目標を設定することで、説明責任と与えられた権限を明確にしてください。これによって、顧客やステークホルダーは、誰に、どうやって関わることで目的を果たせるかを知ることができます。あなたの（内部や外部の）顧客にどうやってあなたに働きかければ良いのかを考えさせないでください。あなたの方が、どうやって彼らに働きかけるかを考える必要があります。

私の同僚のブライアン・ランダーマンは、彼のブログ記事「サービスのサイズとスコープの検討」で、このモデルにどの様に対応すべきかをうまく説明しています。彼は彼のチームがどの様に機能しているかを、次の様に端的に紹介しています。「製品やサービスを所有するために、我々は、通常5人〜10人程度の、小さなチームを組織します。各チームは製品やサービスの1つのコンポーネントに責任を持ちます。そのコンポーネントはチームが発案から運用まで、完全に所有できるくらい小さくなければいけません。もし、コンポーネントが小さく、1つのツー・ピザ・チームが複数のコンポーネントを所有できるようであれば、そうしても良いでしょう。しかし、複雑さが増すにつれて、1つのチームがコンポーネントを完全に所有できる様にするために、意識的にこれらのコンポーネントのサイズを小さくする（または、分割する）必要があります。」

最もパフォーマンスの高いチームは、「自分でコードを書いて、自分でコードを修正する」というやり方で運用しています。プロダクトチームは、発案から、技術的な対応、テスト、デプロイ、そして、運用と保守まで全ての工程に責任を持ちます。そこには、技術担当と運用担当、といった線引きはありません。彼らは、一つのプロダクトチームとして集まり、ビジネス的な価値を提供するというオーナーシップの意識を共有しています。彼らは成果物が完成するたびに解散して、次のプロジェクトへ進むような事はありません。これによって、彼らは顧客と顧客のニーズに対する深い理解を育むだけでなく、実験をする、イノベーションを起こすといった長期的な見方も可能にします。これはさらに、パフォーマンス、財務状況、成果に対して明確な説明責任を確立し、問題への対応をより明確にします。

プロダクトチームは事実上「特別扱い」をされ、チーム間の調整やコミュニケーションが少なくなります。これにより、応答時間を短縮し、俊敏性を高め、より良いイノベーションを実現することができます。

料金所ではなく、ガードレールを

リーダー達は、責任と権限を持ち自律的に行動できるチームを望んでいるとよく言いますが、実際には多くの場合中途半端で、手放すことに対する恐れが妨げになっていることが多いようです。もし、みんながそれぞれやりたい事をやり始めたらどうなるでしょうか？もし、誰かが新しいテクノロジーを実装したら？どの様にコンプライアンスの確認をできるでしょうか？私の同僚のグレゴリー・ホープは、著書『クラウド戦略(Cloud Strategy)』の中で、「各自がそれぞれに最善だと思う事を行っているのは、自律性ではない。アナーキー（無秩序）だ。」と述べています。

この無秩序を克服した上でコントロールを保つためには、停止して承認を得る事や、先に進む前に他のチームとの調整が必要な料金所の方式ではなく、ガードレールの方式を採用する必要があります。ガードレールの方式には様々なやり方があります。例えば、DevOpsのパイプラインに埋め込んだ（セキュリティやコンプライアンス等の）サービスチームによって作られたコンプライアンスを維持、確認する為の自動テストがあります。これらのテストは完全に自動化され、ほとんどが開発者からは見えず、DevOpsのパイプラインへの干渉が最小である必要があります。チームの中に、”丸投げ”や”提出してフィードバックを待つ”という対応が存在しえなくなります。また、ガードレールは共通の原則や目標を通して、さりげない形で表現され、チームにガイダンスと特定の分野における意思決定の基準となる尺度を与えます。

本当にこのガードレール方式を受け入れるのであれば、徹底的にあなたのソフトウェア開発ライフサイクル（SDLC）の雑草を取り除き、ボトルネックを見つける必要があります。SDLCをマッピングし、チーム間の引き継ぎがある場所を探し、なぜそのチームが自分たちで問題を解決するための権限が与えられていないのか、または、なぜその問題を自己解決するという手段が取られていないのかを確認してください。私は自身のキャリアの中で、これを幾度となく行ってきましたが、毎回、新たな気づきを得られ、少し残念な気持ちにもなります。しかし、自分が把握していないことは改善できません。私は、これは簡単な事で大きなインパクトがあると信じています。SDLCの10％の効率改善は、すべてのチームの効率を10％向上させます。

信頼について再考する

リーダーとして、あなたはプロダクトチームが統制目標を達成するための権限を与えられるモデルを作るだけでなく、ガードレールの中で迅速に行動できるようにする必要があります。セキュリティチームやコンプライアンスチームによって確立された統制機能は、プロダクトチームが組織全体の原則を守る責任を持ち、テストフレームワークを継続的に活用するということを信頼する必要があります。同じようにプロダクトチームは、彼ら自身が自分達に対するコントロールを持っており、信頼性が高く、安全で、コンプライアンスを満たしたソリューションを提供する事に対して、完全な責任がある、という事を理解する必要があります。

これができなければ、軽快で、仕事の早い、自律的なプロダクトチームを、官僚主義や不要なコミュニケーションによって、効率の悪いチームにしてしまいます。つまり、圧制的な料金所の方式に引き戻してしまいます。

ツー・ピザ・チーム、再登場

アマゾンでは、このプロダクトチームをツー・ピザ・チームと呼びます。我々は、これが正しい働き方だと強く信じています。確かに、ツー・ピザ・チームと呼ぶ事で、チームの規模に意識が向きますが、より重要な事はチームの自律性とアカウンタビリティです。シングルスレッドの責任者、小規模で自律的なチーム、料金所でなくガードレール、および信頼について再考することでアカウンタビリティとエンパワーメントの明確な基盤を作ることができ、あなたの組織は高パフォーマンスなアジャイル組織となる道を前進するでしょう。

著者について

Tom Godden

Tom Godden は、アマゾンウェブサービス (AWS) のエンタープライズストラテジストおよびエバンジェリストです。AWS 入社以前は、Foundation Medicine社の最高情報責任者として、世界をリードする FDA 規制を受けた、転帰を改善し、次世代の精密医療に情報を提供するための、がんゲノム診断、研究、患者の転帰プラットフォームの構築を支援しました。以前は、オランダのAlphen aan den RijnにあるWolters Kluwerで複数の上級技術リーダーを務め、ヘルスケアおよびライフサイエンス業界で17年以上経験しています。トムはアリゾナ州立大学で学士号を取得しています。

翻訳は Solutions Architect 多田が担当しました。原文はこちらです。