市場機会を見つけ誰よりも早く行動する自律分散型組織を目指せ

米Amazon.comには3300のスクラムチームがある

　実際、米国ではAmazon.comやApple、Google、Salesforce.com、Teslaといった企業がScrum Inc.に講習を受けに来ている。例えばAmazon.comには3300ものスクラムチームがあるという。和田氏は、その理由をこう説明する。

　「スクラムはITとビジネスの一体型チームであり、ビジネス価値の高い順に、やるべき仕事のリストである『バックログ』をながめ、ビジネス価値の高い順に、その機能を1〜2週間という短いサイクルでリリースします。顧客に直接対峙し、すばやく顧客のフィードバックを取り入れ、自らの仕事のプロセスを改善します。

　このサイクルを繰り返すことで、複雑性が非常に高まっている市場においても、顧客が欲しがるものをいち早く届けられるのです」

図2：世界の成長企業が採用する「スクラム」のプロセス

　スクラムの基本構造は、（1）4〜5人のメンバーで自律型チームを作ること、（2）マネジャーがいないこと、（3）プロダクトオーナーとスクラムマスター、開発者の3つの役割と責任だけがあること、の3つである。

　しかし、スクラムの取り組みを全社的なDXにまで拡大することは難しい場合が多い。実際、「企業のデジタル変革が期待を上回ったという企業は5%にすぎない」という調査結果もある。なぜ変革はうまくいかないのか。和田氏はこう説明する。

　「従来組織にスクラムを導入した場合、既存の組織運営モデルとのコンフリクトが発生します。これは私がKDDIで初めてスクラムに取り組んだときに感じたものでもあり、スクラムコーチとして顧客企業に組織的な導入を支援する際にパイロットチームが抱える課題でもあります。

　従来型の日本企業は、年単位で計画を管理しています。サービスをどうしていくかの意思決定を上層部が決める仕組みになっている企業が多く、スクラムチームが優先順位を決められません。

　また組織は、ビジネス、マーケティング、開発、運用など機能別に別れており、その機能ごとに多くの“壁”がある。スクラムチームが顧客から非常に良いフィードバックを得ても、チーム間の連携ができず、顧客が本当に求める開発ができないのです」

自律分散型の組織運営モデルとして開発された「Scrum@Scale」

　判断が自主的にできる組織とそうでない組織を比較すると、「プロジェクトの成功率は3倍以上違う」という調査もある。

　「スクラムチームを最大限に活用するためには、スクラムチームが自分たちで意思決定を下し、必要に応じてチームで連携する組織運営モデルが必要です。チームの活動やチーム間の連携に課題があれば、リーダーシップが、その障害をすばやく解決できるような新たな仕組みが必要です」と和田氏は強調する。

　そこでSrcum Inc.は、Amazon.comなどのアジャイルな企業に見られる組織運営パターンをフレームワーク化し、スクラムチームを最大限に活用するための自律分散型の組織運営モデルを開発した。「Scrum@Scale」が、それだ。

図3：「Scrum@Scale」は自律分散型の組織運営モデル

　Scrum@Scaleでは、複雑性が高まる市場に対して素早くサービスを提供するために、組織全体として会社全体のサービスやプロジェクトのバックログを可視化し、明確な優先順位をつける。その元でスクラムチームが、ビジネス価値が高いサービス／プロジェクトにフォーカスし、すばやく連携し、自律的にサービスを生み出していく。

　Scrum@Scaleは、スクラムチームの自己相似形（フラクタル）になる構造を持つ。（1）組織されたプロダクトオーナーに相当する「エグゼクティブメタスクラム（EMS）」、（2）組織されたスクラムマスターに相当する「エグゼクティブアクションチーム（EAT）」、（3）組織された開発者に相当する「スクラムオブスクラム」の3つの役割と責任で構成される。

　EMSは、会社のビジョン・戦略を提示し、会社のバックログの優先順位付けに責任を持つ。EATは組織へのスクラム導入と、組織の生産性を最大化する継続的な組織変革に責任を持つ。スクラムオブスクラムは、顧客価値単位に構成される複数のスクラムチームの集まりで、スプリントごとに品質の基準を満たしたプロダクトやサービスの機能の提供に責任を持つ。