本格的にデジタルトランスフォーメーション（DX）が進む中、ソフトウェア開発の現場で活用されているのがスクラムの規模を拡張させた「スクラムオブスクラム」と呼ばれる手法です。スクラムオブスクラムは、柔軟性の高いソフトウェア開発に寄与するだけでなく、企業成長の足かせとなるような旧態依然とした企業文化にメスを入れる取り組みとして注目されています。
この記事では「スクラムオブスクラム」に注目し、誕生した歴史や目的、構成メンバーの役割、活用のメリットなどを解説します。
スクラムオブスクラムとは
スクラムオブスクラムとは、同じミッションに臨む独立したスクラムを合体（統合）させスクラムオブスクラムと呼ばれる大人数のチーム体制を指した言葉です。また、アジャイル開発の一つであるスクラムの拡張版ともいえます。「スクラム」という言葉は、スポーツのラグビーに由来します。具体的には、数人でスクラムを組むことで相手の攻撃チャンスを奪い、自分たちの攻撃につなげるというものです。強いスクラムを組めるチームほどチームに余裕が生まれ、相手に対してもプレッシャーを与えられるのです。
スクラムの体制をとる場合、開発は決まったステップを「スプリント」と呼ばれる単位を用いて行います。スプリントは、スクラムにおける工程を短期間で繰り返すことです。具体的には、開発作業により何らかのプロダクト（産物）を作成したのち、プロダクトの内容やチームについて振り返り（フィードバック）を与え、次のスプリントに備えるというサイクルを繰り返します。スクラムの人数や規模を拡大したスクラムオブスクラムの場合も同様で、複雑なソフトウェア開発でも継続的かつ柔軟なプロジェクト管理が可能です。
チームを構成するメンバーが増えると、メンバー間に生じるコミュニケーションパスも増えるのが課題です。各メンバーのコミュニケーション力の強化に役立つきっかけを提供してくれるのもスクラムオブスクラムの特徴といえます。
迅速かつ反復型のソフトウェア開発は「アジャイル開発」と呼ばれ、これにスクラムの手法も含まれます。スクラムとアジャイル開発の関連性についての詳細を知りたい方は、以下の記事も併せてご覧ください。
スプリントとは？アジャイル開発やスクラムとの関係性 メリットを解説
アジャイル開発とスクラム開発の違いとは？それぞれの開発手法について特徴やメリット、その関係性について解説
スクラム オブ スクラムの歴史
「スクラムオブスクラム」の基となるスクラムの手法は、1995年にKen Schwaber と Jeff Sutherlandが共同発表したものです。2人は複雑な製品ラインを含む8つのユニットを調整し、互いを同期させる手段を模索していました。そこで、ユニットごとにスクラムをとった場合、ユニット間での効率性（やりとり）が低下することに気づきます。この点に対しユニットを分けず、8つ全てのユニットを「スクラムオブスクラム」として結集させることで、より効率的な生産体制を構築できることを導いたのです。
これに基づき2001年にSutherland 氏が「Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies」（アジャイルは拡張可能: 5 つの企業での SCRUM の発明と再発明）として発表し、スクラムオブスクラムが注目されるようになりました。この手法は常に進化を続けており、2020年にはスクラムガイドとしてさらに汎用性の高い手法へアップデートされています。
Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies
スクラム オブ スクラムを取り入れる目的
スクラムオブスクラムの目的は、複数のスクラムチームの作業を調整し生産性を高めることです。スクラムは本来、仕事をチームで行う際のソリューション（問題への解決策・ノウハウ）に価値を与えることを重視しています。複雑化したシステムの一部に問題が生じると、そのほかの正常なシステムに対して直接的もしくは間接的に悪影響を及ぼすおそれがあります。問題の特定や解決に時間がかかるほど、システムの生産性は低下し企業に損失を与えかねません。
スクラムオブスクラムは、独立した3〜9程度のスクラムで構成されます。1つの問題解決は将来への糧として蓄積され、各メンバーが属するスクラムに対してもブラッシュアップが可能です。日頃からスクラムオブスクラムの体制を整備しておくことで、システムの問題発生時にもメンバーミーティングを通じて迅速な原因究明と解決につながる解決策が得られるでしょう。
スクラムオブスクラムの全体像
スクラムオブスクラムの基となるスクラムの考え方は「経験から知識が生まれ、意思決定は観察に基づく」という「経験主義」、「無駄を省き本質に集中する」という「リーン思考」の2点から生み出されています。スクラムは「スプリント」と呼ばれる1週間から4週間程の期間を繰り返すように進めます。1つのスプリントは、以下のようなステップで構成されるのが特徴です。
（1）バックログの作成
達成したいプロダクトに必要な機能（要件）を書き出し「バックログ」を作成する。
（2）スプリント目標の決定
バックログのリストから今回のスプリントにおけるスプリント目標を決定する。目標が決まったら、スプリント目標を実現するための課題への要件・バックログを作成する。
（3）実行
開発チームを中心に開発（成果物を生み出す）に取り組む。日々の進捗状況は15分程度デイリースクラムの場で互いに確認しながら進める。
（4）レビュー（検証）
スプリントの最後を目安に、開発チームからステークホルダーに向け今週の成果を説明するミーティングを実施する。説明を基にフィードバックを受け、今後の方向性に変更があればバックログの修正を行い、次回のスプリントに向けた準備を行う。
（5）スプリントレトロスペクティブ（振り返り）
スプリントの振り返りとして、成果物以外に注目し、過程や内外のメンバーとの関係、運営面の見直しを行う。良かった点と共に挙げられた課題に対しては課題を洗い出し、レビュー同様次回以降のスプリントの運営に生かす。
スクラム オブ スクラムのルール
企業やプロダクトによって多少の変動はありますが、最適かつ効果的な成果を出すために、スクラムオブスクラムの体制や方針にはルールが決められています。ここでは、標準的なルールやメンバーとなる参加者、ミーティングについて見ていきましょう。
グランドルール
ソフトウェア開発の現場では、要件が細部まで定まっていないケースや必要な機能が途中で変更になることも少なくありません。ソフトウェアは「開発」が目的なのではなく、ソフトウェアを活用して「成果」を出すことが重視されるためです。スクラムの考え方は「Scrum of Scrum Ground Rules」で示されており、以下のような標準的なグランドルールがあります。
- 独立したスクラムチームで毎日行われるデイリースクラム同様、15分程度で行う。
- メンバーはそれぞれ、自分が所属しているスクラムチームの名前を伝える。さらにチームの役割や特徴について紹介する。（特定の個人への言及は避ける）
- ミーティングではチームで抱える問題についてのみ報告する。（解決策に関する話題はほかのチームの報告後に行う）
- 各チームの報告が終わったのち、報告された問題への解決策について話し合う。解決策はミーティング内で解決もしくは、将来ミーティングで取り上げるテーマとする。
参加者
スクラムとスクラムオブスクラムは、共にチーム体制であることをお伝えしました。では、最大5つのスクラムで構成されるスクラムオブスクラムの各参加者には、どのような役割があるのでしょうか。
基本となるスクラムでは、メンバーに役割（ロール）を割り振るのが特徴です。主な役割は、作成するプロダクトの責任者となる「プロダクトオーナー」、一定のスキルを有し実際に開発を行う「開発チーム」、プロジェクト全体の円滑な進捗をサポートする「スクラムマスター」の3つです。
スクラムオブスクラムの参加者は、独立したスクラムの代表者で構成されます。各機能を横断するメンバーで構成され、割り振られる役割はスクラムと同様です。また、3つの役割に加え、スクラムオブスクラムのチームには「品質保証リーダー」と「スクラム オブ スクラム マスター」も存在します。
品質保証リーダーにより生成されたプロダクトの品質は維持・監督され、スクラム オブ スクラム マスターによって進捗状況や達成度合いのフィードバックを受けます。両者が介入することで、スクラムオブスクラム全体の生産性や有効性は改善しながら機能することができるのです。
数人の開発チーム単位であれば「スクラム」、プロダクトサービスレベルであれば「スクラムオブスクラム」、さらにこれを組織レベルへ拡大（統合）させたものは「スクラムオブスクラムオブスクラム」もしくは「Scrum@Scale」と呼ばれるものもあります。いずれもスクラムの考え方を応用しているので、このようなフレームワークも知っておくとヒントになるかもしれません。
ミーティングの頻度
2020年に発表されたスクラムガイドやスクラムのグランドルールでは、デイリーミーティングとして毎日15分程度のミーティングの場を設けることとしています。ミーティングを通じてメンバーの時間やタスク管理能力を向上させ、責任範囲も明確になります。ミーティングの頻度や要点は、次のようにまとめられます。
デイリースクラム
- デイリースクラムは開発者のための15分であり、計画されている今後の作業調整や進捗状況の検査（振り返り）、スプリントバックログの適応を行う。
- 開発者がゴール（成果）への進捗に対し実行可能な計画作成をすることで集中と自己管理を促進する。
- デイリースクラムによりコミュニケーションが強化される結果、障害物の特定や対策、ほかの不要な会議を削減できる。
- デイリースクラムで対策を要する課題が明らかになった場合、なるべく早期により多くの時間を確保して話し合いを行う。
アジェンダ
有益かつ生産的なスクラムオブスクラムを維持するために、 日々のミーティングの最後に「アジェンダ」として以下のような質問に答える時間を設けることが推奨されています。
- 「前回のミーティング以降、自分たちのチームはどのような成果を挙げましたか？」
- 「次回のミーティングまで、自分たちのチームは何を行動・成果を目指しますか？」
- 「今チーム内で抱えている課題やハードルはどのようなことですか？」
- 「特定のチームがほかのチームの作業に対して支障になることはありますか？」
参考：スクラムガイド™
これらについて、ミーティングのファシリテーター（進行役）が参加する各メンバーに問いかけ、問われたメンバーは問いに対して「簡潔」かつ「速いペース」で回答します。全てのメンバーが回答するまで、メンバーが発言した回答への改善策をその都度話し合うことは控えましょう。
スクラムを構成するメンバーの人数や規模が大きくなるほど、コミュニケーションレベルを維持することが難しくなります。最後にこのような時間を設けることで、メンバーが元々所属しているチームでの生産性や効率の維持・向上に役立ちます。プロセスの透明性を保つとともに成果物や進捗状況の検証、プロダクト全体への適応などを確認しながら進めることが大切です。
スクラムオブスクラムを取り入れるメリット
スクラムオブスクラムの全容について、さまざまな角度から解説してきました。これまでの内容を整理するとともに、スクラムオブスクラムを取り入れることで、以下のようなメリットが期待できます。
- 開発者は自分の取り組みが成果物という形でコミット（確約）することを意識して臨めます。
- スクラムという手法はソフトウェア開発のみならず、サービスや商品（製品）、PTAなどのコミュニティへも応用可能です。
- 各スクラムチームに求められる成果やチーム内外の統制、互いのコミュニケーションを重視するためプロジェクトの透明化が図れ、見通しも明確になることで大幅な手戻りを防止できます。
- 日々のミーティングを設けることで、特定のスクラムチームへの業務の偏りや依存状態に陥ることを避けられるでしょう。
- スクラムオブスクラムの体制を継続することで、個々のコミュニケーション力の強化やメンバー同士の対立を防ぎ、柔軟性の獲得にも寄与します。
まとめ
スクラムオブスクラム、そして基本となるスクラムの手法について理解いただけましたでしょうか。
システム開発の現場では、個々のスキル差を課題としているところも少なくないようです。特定の担当者への属人化やチームへの仕事の偏りが生じているままでは、企業全体として持続的に生産性を維持・向上させるのは容易ではありません。スクラムやスクラムオブスクラムは互いのコミュニケーションやマネジメントの要素を重視している分、習得に難しさを感じるかもしれません。それでも日々のトライ＆エラーを継続することで、盤石な組織体制の構築、機敏性向上に寄与するでしょう。
また、過去に実施したアジャイル開発のプロジェクト管理手法セミナー（講師：弊社社長梅田）の講演資料を公開しています。併せてぜひご覧ください。
