アジャイルに働くためのフレームワークとして、企業の70％以上が採用する「スクラム」。ソフトウェア開発はもちろん、ソフトウェア以外の商品開発や事業開発にも応用可能として、活用の幅が広がっている。

だが、小規模のチームにスクラムを導入できても、それを部署全体・組織全体に拡大するフェーズでは、多くの組織が壁にぶつかっているのが現状だ。

企業規模でアジャイルを実現するための秘訣は、何なのか。スクラムを組織に拡大させるフレームワーク「Scrum@Scale」を導入ポイントとともに解説する。

ある会社では、新規プロダクトにスクラムを導入。自律したスクラムチームが迅速に開発を進め、これまで半年かかっていたリリースを半分の3ヶ月で実現した。ユーザーの反応を見ながら機能のアップデートを続け、顧客満足度も向上した。

この成功例を見て、スクラムは社内でも評判となり、スクラムチームの数が次々と増えていった。そこでついに、全社に関わる一大プロジェクトも、スクラムで実施することに。

しかし、ここで問題が発生する。

大規模なプロジェクトの開発計画は、すでに年間のリリース計画が確定済み。複数の部門が協議して決まった計画なので、なかなか変えるのは難しい。顧客の声をリアルタイムで計画に反映したいと考えるスクラムチームはその強みを発揮できずにモチベーションが下がり、プロジェクトが立ち行かなくなってしまったのだ。

この企業のように、チーム単位の導入はうまくいっても、スクラムを組織に拡大する段階で以下のような課題にぶつかる企業は少なくない。

1つ目は、全社の経営計画とのコンフリクトだ。

そもそもスクラムを組織全体に適応させる際に必要なのは、組織全体の方向性を揃えながらも、各スクラムチームの自律を確保する、新たな組織運営のしくみだ。

しかし現実には、開発チームはスクラムを採用していても、組織全体の経営は従来のウォーターフォール型、という企業は少なくない。

ウォーターフォール型の経営では、数年先を見据えた中期経営計画を起点に、各事業部にタスクを落とし込んでいく。一方でスクラムチームは、顧客の要望やフィードバックをリアルタイムで計画に反映させ、自律して開発を進めたい。

このような組織では、すでに策定された計画と、スクラムチームが顧客のフィードバックに基づいて作成するバックログに、乖離が生まれてしまう。結果的に、スクラムチームが、創造性や機動力を発揮しづらくなってしまうのだ。

２つ目は、スクラムチーム同士の連携不足だ。そもそもスケールの目的は、スクラムチーム同士が協力することで、より大規模なプロダクトや課題解決に取り組めること。

だが、複数のスクラムチーム同士の連携ができないと、スクラムチームの活動が局所最適となり、組織としてのゴールを達成することができない。また、スクラムチームのプロセスや品質に差が出る、仕事が重複、もしくは抜け漏れが生まれるなどの弊害が生まれ、結果的に組織としてのパフォーマンスも下がってしまう。

急成長するスタートアップなどでは特に、社内体制の整備が間に合わずにチームが乱立し、収拾がつかなくなってしまうケースが発生しやすい。

多くの組織に当てはまるこれらの課題の多くは、汎用的なフレームワークを用いることで乗り越えられる。そのフレームワークが、Scrum@Scaleだ。

Scrum@Scaleは、スクラムの共同考案者であるJeff Sutherland博士を中心に、Spotifyでアジャイルコーチを務めたHenrik Kniberg氏ら、世界中のアジャイルコーチが協力して、確立させた。

ここからは、Scrum@Scaleを使うことで、スクラムをどう組織に拡大し、組織とスクラムチームの方向性を揃えながら、スクラムチームの自律を両立させられるのかを見ていこう。

Scrum@Scaleの構造は、意外にシンプルで、チームの最小単位であるスクラムチームの数を増やすことで、組織全体に拡大していく。ただ、有象無象にスクラムチームを増やしていけばいいわけではない。

ポイントは、複数のスクラムチームが「フラクタル構造」（注1）を形作りながら、ネットワークのように互いに繋がっていることだ。

こうすることで、スクラムチームを無限に拡張することがでるほか、「チームレベル」「プロダクト・サービスレベル」「事業レベル」というように、扱う領域の広さを基準にチームのまとまりを作ることができる。このチームごとのまとまりがあるため、連携や情報共有もしやすくなるのだ。

注1：フラクタル構造とは、ある一部分を切り取って見ると、全体に相似した構造になっている構造のこと。

ではScrum@Scaleを使うと、スクラムのスケールにおける課題をどのように解決できるのか、紐解いていこう。

まずは前述の、組織全体の方向性とスクラムチームの優先順位が乖離し、機能しなくなるという問題。これは「組織の意思決定をどのように進めるか」という問題と直結している。

そこでScrum@Scaleが推奨するのが、「実用最小限の官僚機構」という考え方だ。

官僚的な組織とは、中央統制と専門化された職務分担に基づく組織の管理体系のこと。規模が大きくなるほど、傾向として組織は官僚的になる。

具体的な弊害には、仕事のプロセスに承認が求められ、意思決定のスピードが遅くなる、中央で意思決定が下されるため現場の声が反映しづらくなるなどが挙げられるだろう。

とはいえ、大規模な組織運営を完全にフラットに運営するのは無理があり、官僚的な要素を完全に排除することはできない。そこでScrum@Scaleは、官僚機構は実用最小限に抑えることを推奨するのだ。

具体的な手法を見ていこう。まず大前提として、スケールしたスクラム組織の最上位には、２つのリーダーシップの役割を置く。そのうちの一つが、リーダーシップと最上位のプロダクトオーナーとが構成する定期的なフォーラム、「エグゼクティブメタスクラム（EMS）」だ。

EMSは、組織全体の方向性、つまり、組織全体の戦略的ビジョンや会社レベルのバックログの優先順位に責任を持つ。さらに各スクラムチームのプロダクトオーナーと連携し、顧客からの学びを会社のビジョン、戦略に反映させる役割を持つ。

もう一つが、「エグゼクティブアクションチーム（EAT）」と呼ばれ、チームでは解決できない、組織レベルで協力しなければならない課題や障害を解決するリーダーシップのスクラムチームだ。

EATは各レベルのスクラムマスターと連携。チームの生産性を向上させ、より顧客にフォーカスするために必要な組織構造（予算配分や人事評価のプロセスなど）を確立する役割を担う。
EMSとEATが先導することで、各スクラムチームが自律しつつ、組織全体の戦略と各スクラムチームの実行の整合性が取れる、「アジャイルな組織運営」が可能になる。

Scrum@Scale組織の運営の中心となるのが、プロダクトオーナーサイクル（POサイクル）とスクラムマスターサイクル（SMサイクル）である。

POサイクルとは、一言で言えば「組織が何をすべきか（「What」）」を調整する手順を示したものだ。EMSと、各プロダクトオーナーからなるプロダクトオーナー組織（PO組織）が連携して、組織全体のバックログと各スクラムチームのバックログの方向性を揃えることで、組織のビジョンを実現していく。

その具体的な手順はこうだ。POサイクルは、PO組織が「企業全体の戦略的ビジョンを明確にする」ことから始まる。そのビジョンをもとに、バックログの優先順位をつけるのだ。

その後、各レベルのプロダクトオーナーがバックログの分割とリファインメントを行い、各スクラムチームにReady（準備完了）のバックログを供給。PO組織は、顧客のフィードバックを得るための実用最小限のプロダクト（MVP）を決定した上で、リリースまでの計画を立てる。

プロダクトがリリースされたら、得られた顧客のフィードバックを再び、組織全体のビジョン、そして、組織のバックログに反映していくのだ。

一方SMサイクルは、組織のプロセス（「How」）を調整するもの。EATと各スクラムマスターからなるスクラムマスター組織（SM組織）が連携して、組織全体のパフォーマンスの最大化を目指す。

SMサイクルには、大きく4つの仕事がある。

1つ目は、チームのコーチング。SM組織が連携してチームをコーチングし、各スクラムチームが最高のチームとなれるよう、支援する。

2つ目は、スクラムの進め方の継続的改善だ。チームで解決できない障害はスケールドデイリースクラムを通じて、毎日EATメンバーにレポートされる。EATは、その障害をいち早く取り除く。

3つ目は、チーム横断の調整。スクラムマスター組織は、QC活動やコミュニティ活動を通じて、スクラムチーム間の調整がスムーズにできるように支援する。

4つ目はデリバリーだ。スクラムマスター組織は、スプリントごとのデリバリーが実現できるようにスクラムチームを支援する。プロダクトがリリースされたらデリバリーのプロセスに関するフィードバックを得て、組織がより迅速にデリバリーできるように支援する。

POサイクルとSMサイクルにスクラムの経験的プロセスの柱である透明性を追加するとScrum@Scaleフレームワークの完成となる。スクラム同様、Scrum@Scaleも経験的プロセスの柱である透明性・検査・適用を実践することが欠かせない。

多くのステップを見てきたが、POサイクル・SMサイクルを最初からすべて完璧にこなす必要はない。まず重要なのは、スクラムチームの状況や、各プロダクトのユーザー数、ROIの状況などを徹底的に見える化すること。そこからPOサイクルとSMサイクルを実践して、その度に得られる学びを生かして調整、発展させていけばいい。

POサイクルで組織のビジョンを実現し、SMサイクルで組織変革を実践する。Scrum@Scale組織では、この２つのサイクルがポイントとなる。Scrum@Scaleを用いて、スクラムチームの成果を組織の成功へつなげ、アジャイルな組織へと変革していこう。

（Illustrated by Yoshie Sekita）