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

より速く、より多くのイノベーションを

より速く、より多くのイノベーションを。これは単純な指示のように聞こえます。私が知るほとんどのエグゼクティブは、新しいアイデアをより早く市場に投入し、イノベーションを加速し、高度なテクノロジーを使ったソリューションをより短時間で導入したいと考えています。ああ、しかもそれをやるのは、セキュリティで信頼性が高く、コンプライアンス、耐障害性に優れたソリューションを構築しながらです。でも、どうすれば良いでしょうか？従来のチームを組織し、権限を与える方法では、容易にはいきません。真の俊敏性は、買ったり注文したりできる物ではありません。クラウドはこれらを実現するのに確かに役立ちますが、クラウドだけでは企業が求めるメリットは達成できません。

どうすれば達成できるでしょうか？高パフォーマンスのアジャイルチームには、アカウンタビリティとエンパワーメントが必須です。本当に高パフォーマンスのアジャイル組織になるためには、組織構造をこれまでとは違う視点で見て、考え方や行動を進んで変える必要があります。

アマゾンウェブサービス（AWS）では、ツー・ピザ・チーム、ピザが 2 枚で足りるくらい小さな、通常は 5 ～ 10 人のチームにする事から始めます。しかし、チームのサイズだけでは不十分です。より速く、よりイノベーティブに、そして新しい先進テクノロジーを活用するためのカギは、ビジネス価値を提供するための明確な線引きのされた説明責任（アカウンタビリティ）を持つチームの確立と、その実現の為の権限と環境を与える（エンパワーメントする）ことです。

この記事では、従来の組織モデルが、どの様に我々の夢である俊敏性の実現から遠ざけているかについて説明します。フォローアップ記事では、アカウンタビリティとエンパワーメントを組織の構造に焼き上げるための実践的な戦略を提案します。それでは、始めましょう。

スキルベースのチームではいけない

多くの経営幹部と同様に、私はIT 機能を専任のスキルベースのチームに整理するモデルを完成させようとして、過去25年以上にわたって多くの時間を費やしてきました。スキルベースのチームはすべてが素晴らしく、きれいで、整然としています。すべてのデータベースエンジニアを1つのチームに、すべての品質エンジニアを別のチームに、すべてのソフトウェアエンジニアを別のチームに、という風に。分かったのは、言うは易く行うは難しという事です。

理論的には、スキルベースのチームは一貫性の構築、技術的優位性の提供、リスクの軽減、コストの削減を実現する為の基準とベストプラクティスを確立する為に専門知識を活用します。このモデルが一定の成果を出していないという事ではありません – 確実に、組織内の無秩序なテクノロジーの拡大を排除し、特定のテクノロジーを標準化するのに役立っています。ただ、今日における高いパフォーマンスを出すアジャイルな組織に対しては、十分に機能するとは言えません。スキルベースの組織モデルは、どの様にテクノロジーをイノベーションと戦略的優位性の為に活用するかではなく、どの様にテクノロジーを管理するかに重点を置いています。これはイノベーションが起こらないというのではなく、チームがイノベーションを起こすための権限や環境を与えられたり、期待されていたりしている事をほとんど感じていないので、イノベーションが起きたとしても偶発的だということです。

従来のスキルベースのモデルでは、企業は、作業が分割され、複数のスキルベースのチームに分担される、プロジェクトベースのチーム（プロジェクトチーム）の利用を強要されます。このモデルでは、目標の設定、作業の優先順位付け、一貫したサービス提供のために、チーム間の調整と交渉のポイントが複数必要となります。これらはすべて非常に非効率的で、コミュニケーションミスや遅延が起こりやすく、チームは簡単に過負荷になる可能性があります。

これらのチームの規模拡大を制限するものはほとんどなく、数百人規模に拡大することもあります。驚くことではありませんが、チームメンバーの数が増えるにつれて、生産性が低下する相関関係があります。これは、大きなチームであるほどモチベーションやチーム内での調整の損失が大きくなるという、リンゲルマン効果として知られています。大規模なチームは、そのメンバーに大きな認知負荷をかけます。例えば、6人のチームであれば15の個別の関係を保つ必要があります。多いですよね？比較すると、25人のチームは300の関係が、50人のチームでは1,225の関係が存在します。

私の経験では、これらのスキルベースのチームは最適ではないことが分かりました。あなたはどうでしょうか？スキルベースの組織モデルが、ソリューションをより迅速に構築するのに役立つと感じていますか。コンプライアンスを向上させますか？顧客やステークホルダーとの連携に役立ちますか？率直に言って、疑わしいと思います。実際、私はあなたがスキルベースのチームがボトルネックになるのを避けることはほぼ不可能だと気づいたと確信しています。スキルベースのチームで、組織の他のチームと同じスピードを維持しながら、コスト削減と標準化を実現することは非常に困難です。

誰が結果に責任をもつのか？

スキルベースのチームは非効率的で扱いにくいだけではありません。俊敏性に対する行動障壁をも作り出します。これらのチームには非常に多くの専門知識が集中されているので、確実に上手くいくと期待されます。しかし、実際には、結果について誰かに責任を持たせることが事実上不可能になります。スキルベースのチームでは、なんとなく全員が結果について責任を持ちますが、同時に、誰にも責任がないように見えます…まあ、それについて何かできる人もいません。ほとんどの場合、サービス提供の責任者であると同時にサービス提供についての権限も与えられている個人はいません。各スキルベースのチームには複数の成果物があり、そのすべてが時間の奪い合いとなります。そして、最終的な成果物の完成に集中する一人の人、プログラムマネージャまたはプロジェクトマネージャ、は多くの場合、優先順位を決めたりリソースの調整を行ったりすることはできず、問題をエスカレーションするだけです。

さらにまずいことに、これらのリソースの一時的で断片的という性質から、彼らはいくつものプロジェクトを転々として、時間と注意を分散させられ、結果として長期的な所有者としての見方を何一つとして持たない様な動機付けになってしまっています。これはエンジニアリングとオペレーションの責任が2つの異なるチームにある時に見られます。エンジニアリングのチームは、コストやその製品がどの様に使われるかを考えることなく、ソリューションを構築します。「それはオペレーション側の責任だ」と彼らは言います。オペレーション側は、「貧弱なエンジニアリングに対応」するために、より大規模で高価なインフラストラクチャを構築することで対応します。誰もコストの責任を取らず、それぞれが自分の役割を果たすだけです。このプロセスは設計どおりに機能し、経営幹部であるあなたが、その請求書の対応をすることになります。

これらのチームの大きさから責任の分散と呼ばれる心理現象に陥ります。ある出来事を目撃する人が多いほど、誰かがその出来事に対して行動を起こす可能性が低くなる現象です。この現象は、これらのチームにおいても同様に見られ、誰もが、他の誰かが責任を取ると仮定しています。誰もが、絶対に他の誰かが修正する、他の誰かが安全かを確認する、他の誰かが本番環境に展開できることを確かめる、と考えます。

たとえ、誰かが行動を起こそうとした時でも、彼らに与えられた権限は限られているので、効果的な対応を行うのが難しくなっています。代わりに、これらのチームリーダーはコンセンサスの上で決定されている事や、権限のある誰かが行動するまでエスカレーションし続けないといけない状況に集中せざるを得ません。これはエンパワーメントとは正反対です。

誰を信頼できるか？

リスクを管理するために、そしてスキルベースのチームによって分散した責任を埋め合わせるために、我々はチームに罰則の様な厳格な監査ベースのコントロールフレームワークの実施を求めるプロセスを作ることがあります。このプロセスは、理論上は、一連のチェックリストと監査を通じて、信頼を確立し、プロジェクトの品質とコンプライアンスを証明するために設計されています。しかし、実際には開発者が非準拠のコードを記述したいという前提に基づいて設計されており、監査人の目標はそれを掴むことになっています。この前提は正しくありません。圧倒的に、開発者は良いコードを書きたいのです。そうではないように扱うことは、彼らとの間に不信感を産み、生産性を悪化させます。この信頼感の欠如は、結束や共有されたゴールの欠如や、チーム間の”丸投げ”体質によって悪化します。

ビジネスとIT

コミュニケーションが断片化され、多くの引継ぎを必要とするスキルベースの組織構造は、IT部門を遠ざけ、企業内で他の部門との分離を強くします。チームはそれが何かも、解決すべき問題は何かも理解していない物を顧客へ提供する事を、頻繁に求められるという状況に置かれます。

なぜ、こうなったのでしょうか？我々IT部門はテクノロジーを企業の他の部門から手の届かない所に置くことが心地よくなってしまっているからです。我々は、大きな曖昧なプロジェクトによる責任の分散や、匿名性を受け入れており、それが明確なオーナーシップ、共有された優先順位、強い顧客理解を確立することを難しくしているからです。

これを克服するために、大規模なプログラムオフィスが創設され、ビジネス・テクノロジー担当者（またはビジネス・パートナー）が雇用され、ITとビジネスの間のパイプ役として活動します。残念ながら、これらの役割は、多くの場合、命令を聞き、状況を伝える以上のことができないため、IT部門が何をしているかの不満と謎を深める事につながります。さらに、エンジニアは、彼らが最も嫌う3つの事をするように求められます：(1) 会議に出席する、(2) PMO にエンドレスに状況報告をする、(3) 互いにコミュニケーションをとる。これらの活動のすべては、仕事をしている人たちに仕事をさせるのではなく、情報を引き出したり、抽出したりします。

この全ては、ただIT部門と連携する事を困難にするだけで、しばしばシャドウITを生み出します。多くの場合、シャドウITは、その部門が独自のITを使いたいからではなく、IT部門の遅延、応答の少なさ、不透明性に対して不満を抱き、何かを実現するのに抵抗が最も少ない方法を探したからです。

次のステップ

この状況では、結果がありのままに認識されないことが多いので、チーム間で責任と説明責任を分散させ、チームメンバーのモチベーションを落としています。貢献は評価されず、報酬が誤って適用され、罰則は薄められるか、または決して発生しません。

もっと良い方法が必要です。自分に次の質問をしてみてください。

リーダーとして、どの様な決断を下していますか？プロジェクトの些細な事に捉われていますか？
チームはあなた、他の組織、または誰かに隠れて活動していますか？
プロジェクトが遅れた時や、システムがダウンした時に、複数のリーダーやチームで調整をする必要がありますか？新しい機能をリリースするために協力して作業する場合はどうでしょうか？
組織内にシャドウ IT が広がっていますか。

これらの質問に「はい」と答えた場合は、おそらくチームの構成方法を再考する必要があります。開発者に、独自の決定を下す権限を与えられておらず、自分たちの仕事に対して責任を持つ事が奨励されていない可能性があります。

良いニュースは、別のやり方もあるということです。おそらくあなたはアカウンタビリティ、オーナーシップ、エンパワーメントの重要性をすでに理解しているかもしれません。あるいは、組織がこれらの課題に苦しんでいることに気づき始めているかもしれません。問題を特定することは戦いの半分です。どうやって修正するかについて考える時がきました。次の記事では、説明責任とエンパワーメントをチーム構造に取り込み、高パフォーマンスのアジャイル組織に成長させる実践的な方法について説明します。

著者について

Tom Godden

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

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

Amazon Web Services ブログ