海外市場では90％近くの企業が導入していると言われる「アジャイル開発」。

まだ海外企業ほどその割合は多くはありませんが、近年は日本国内でもアジャイル開発を導入する企業が増えています。

▼アジャイル型開発手法に関する方針×従業員数規模（出典：ガートナー ジャパン）

そして、それらの導入企業において次なるポイントとなるのが、「どのようにアジャイルをスケーリングさせていくか」という点です。

事業や組織の拡大に伴い、複数のチームで協力しながら大規模な開発プロジェクトに取り組むケースも出てきますが、その際は単一のチームで進めていた時と比較して、意思決定ルートや情報連携などが複雑化するといった課題が生まれます。

おそらく、導入した当初の体制のままでは、うまく前に進めることができない場面も出てくることでしょう。

そこで今回は、将来的にチームのアジャイル開発をどのようにスケーリングさせていくかを検討されている方や、その参考としてどのようなスケーリング手法があるかを知りたい方に向けて、その基礎知識から企業の事例までをご紹介します。ぜひご参考ください。

＜目次＞

• 「アジャイル（開発）」の意味と、そのスケーリングとは
• アジャイルスケーリングのための代表的なフレームワーク
• 【事例5選】アジャイルスケーリングの要素を取り入れている企業
• • 職種を超えた連携を生み出す「スクワッド組織」運営 / READYFOR
  • ひとつのプロダクトを全員で作る大規模スクラム（LeSS）を導入 / Retty
  • 拡大と分権化が進む中、誰もがプロダクト改善に臨む組織へ / ヤプリ
  • スプリントは1週間。素早く直せるシステム設計も実行 / AnyMind Group
  • 全社の開発を止め、好きな開発に専念できる「Hack Week」 / メルカリ

「アジャイル（開発）」の意味と、そのスケーリングとは

まず、アジャイル開発とは、「機敏・迅速・柔軟なソフトウェア開発」の手法の総称を指しており、特定のひとつの手法を指すわけではありません。その共通点としては、「実装した機能をいち早くリリースし、細かく反復して改良する」という特徴が挙げられます。

※アジャイル開発の基礎知識については、「【事例7選】「アジャイル」とは？ 開発やHRなど多くの分野で注目される理由を徹底解説！​​」をご覧ください。

小規模なチームにアジャイル開発を導入することは、環境さえ整っていればさほど難しくはなく、導入によって成果を上げている企業も多いことでしょう。

しかし、開発するプロダクトの規模が拡大したり種類が増えていくにつれて、複数のアジャイルチームを組成したり、異なるチーム間の連携を円滑にしたりする工夫が必要になってきます。

そのような事業環境の変化の中で、アジャイル（俊敏性）を保ったまま、より良い開発を行える体制にスケールさせていく難易度は高く、「この手法を取れば解決できる」といった正解の型があるわけではありません。また、大規模な組織にアジャイル開発をゼロから導入する際も、小規模な企業に導入するのとは異なる独自の工夫が必要になります。

今回解説するアジャイルのスケーリングとは、単純に開発チームの規模を大きくする「拡大」ではなく、企業のビジネスモデルや組織文化に合わせて、独自のスタイルで開発体制を「拡張」していくことを指しますが、その際に役立つのが「Scaled Agile Framework®（以下、SAFe）​​」をはじめとした、大規模アジャイル開発における各種フレームワークです。

これからご紹介する様々なフレームワークを参考に、自社に合う形にカスタマイズしながら最適なスケーリングの仕方を見つけていただければと思います。

アジャイルスケーリングのための代表的なフレームワーク

Digital.ai社が世界のアジャイル開発の動向について調査を行った15th Annual State Of Agile Report（2021年）では、「あなたの組織ではアジャイルのスケーリングのために、どのようなフレームワークを基にしていますか」という質問に対して、下図のような回答結果が得られたと発表されています。

この結果から分かるように、アジャイルのスケーリングには多くのフレームワークがありますが、5年ほど前までは「Scrum@Scrums」が主流だったところから、現在は37%のシェアを占める「SAFe​​（セーフ）」へとトレンドが移行しています。

ここでは代表的なものとして、下記4つのフレームワークの概要をご紹介します。

• Scaled Agile Framework®（SAFe）
• Scrum＠Scrums（Scrum of Scrums）
• Spotify Model
• Large Scale Scrum（LeSS）

①経営者を含め組織全体にアジャイルを浸透させる「SAFe」

Scaled Agile, Inc社が提唱する「SAFe」は、リーン、アジャイル、DevOpsの手法やマインドセットを組織全体で大規模に実践するフレームワークとして、世界でもっとも活用されているものとなります。

特に複数のアジャイルチーム間の連携を促進するのに役立ち、小規模なチームから数千人を要するような複雑な大規模システムまで適用することが可能です。

SAFeの大きな特徴は、システム開発だけに焦点を当てたものではなく、経営やビジネス全体まで包括して、企業や組織のビジネスアジリティを向上させることを目的としたフレームワークであるということです。

そのため、自社にSAFeを導入する場合は技術者だけでなく、経営者やマネジメント層、ビジネス担当者までがトレーニングを受け、SAFeを習得した推進チームによって、組織全体に徐々にその考え方や手法を広めていくこととなるでしょう。

SAFeの導入にあたっては、基本的にScaled Agile, Inc社の国内パートナー企業による導入支援を受けたり、SAFeインストラクター資格であるSPC（SAFe Program Consultant）​取得に関する研修などで詳細を学ぶ形になります。

今回はSAFeの概要とメリットに触れられればと思いますが、まず組織にSAFeを実装するための12個の手順を示したロードマップを見てみましょう。

例えば、最初の「Reaching the Tipping Point」は、企業・組織の転換点として変化の必要性を認識し、未来のビジョンを描くようなステップとなります。その後、経営者やマネージャーへのトレーニングを示す「Train Lean-Agile Change Agents」など、実践的な学びへと進んでいきます。

出典：SAFe Implementation Roadmap

このような手順を踏むことで、リーン、アジャイル、DevOpsの手法やマインドセットが組織全体にインストールされた状態へと近づいていくわけです。

また、Scaled Agile, Inc社では、組織の規模や目的に応じてSAFeを「Essential、Large-Solution、Portofolio、Full」という4つの段階に分けており、例えば50〜125名ほどの小規模チームでは下図のような構成で全体像（Big Picture）を示しています。

▼小規模チームに向けたSAFe全体像_Essential（出典：以下、Scaled Agile, Inc.）

※出典元サイトで各アイコンをクリックすると、詳しい説明を確認することができます。（英文表記）

そして、複数のアジャイルチームを束ねるような大規模なチームであれば、下図のような構成となります。

SAFeはシステム開発のみならず経営・事業にまで焦点を当てていることから、「事業ポートフォリオ」「大規模ソリューション開発」「複数のアジャイルチームによるシステム開発」という三つの階層に分けて、全体像を示しているという形ですね。

▼大規模チームに向けたSAFe全体像

このSAFeを実装することで、経営層による意思決定が迅速に行えるようになり、ゴールや戦略、開発方針のベクトルを全社一体ですり合わせることができるようになります。さらには、複数チームによる協働が円滑になることで、高品質なプロダクトを迅速にリリースできるため、組織全体のビジネスアジリティの向上が実現できると言われています。

実際に、SAFe導入企業へのアンケートによれば、「市場へのリリース速度が50%向上」「品質が50%向上」「生産性が35%向上」「従業員エンゲージメントが30%向上」といった効果が得られているそうです。

出典：https://www.scaledagileframework.com/safe-for-lean-enterprises/

SAFe発祥の地である米国では、政府をはじめ​​「Fortune 100​​」選出企業の70%以上でこの手法が採用されており、同社の日本法人が「国内企業へのSAFe導入は直近1年で2倍に増えた」と公表していることからも、日本国内でのSAFe導入はますます加速していくと思われます。

より具体的な内容を知りたい方は、Scaled Agile, Inc社のHPに豊富なコンテンツがありますので、ぜひ参考ください。

②スクラム同士を繋ぎ、連携する「Scrum＠Scrums（Scrum of Scrums）」

組織内のスクラムが増えてきて、それらが協力して複雑なソリューションを実現しようとする際には、異なるスクラム間での情報連携や意思決定などの難易度が高まります。

そういった課題を解決し、情報透明性を保ちながらスピードを落とさずに開発を進めることを目的として、各スクラムマスターが集まり、課題などの情報共有を行いながらスクラム同士をつなぐ手法がScrum＠Scrums（スクラムオブスクラム）です。

さらに組織が大きくなれば、それぞれのScrum＠Scrumsのメンバーの中から代表者同士が集まり、新たなScrum＠Scrum＠Scrumsを作るといったように、フラクタル構造でネットワークのように繋がっていくのが特徴です。

こちらが、SAFeが台頭する以前に広く用いられてきたスケーリング手法となります。

出典：https-//www.agilest.org/scaled-agile/scrum-of-scrums/.jpg

Scrum＠Scrumsは各スクラムの代表者で構成される仮想チームとして、独立した個々のスクラムを繋ぐ役割を担いますが、各スプリントの終了時には統合したプロダクトを顧客に提供するリリースチームとしての機能なども担っています。

また、Scrum＠Scrumsのメンバーは、通常のスクラムチームで行うデイリースクラムと同様に、15分程度の拡張デイリースクラムを行います。

その場では、自チーム全体に焦点を当てて、前回のミーティング以降に行ったことと次回までに行うこと、進捗を妨げている問題、自チームが担っている他チームに関連する作業などについて共有する形です。そこで生まれた課題の改善や障害などへの対応を行うのも、Scrum＠Scrumsメンバーの役割となります。

③汎用的ではないがエッセンスを取り入れる企業多数「Spotify Model」

組織の拡大に伴って開発体制を徐々に変化させてきたSpotify社。その中でSpotify Modelと呼ばれるアジャイル開発体制を確立し、2012年にホワイトペーパー「Scaling Agile @ Spotify」でその内容を発表しました。

Spotify初期にアジャイルコーチを務めたヘンリック氏は、このモデルはSpotify社が自社サービスや組織の急成長に適応するために独自に生み出していて、その内容は今後変化し得るものであり、他社でも使える汎用的なモデルとして作ったわけではないと語っています。その前提がありながらも、Spotify Modelやそのエッセンスを採用した企業は数多く存在しています。

基本的な開発チームの単位は、独立した「分隊（Squad）」です。各分隊には異なったスキルセットを持つメンバーが集まっていて、「バックエンドシステムをスケーリングする」「決済方法を提供する」といった長期的なミッションを持ち、プロダクトオーナー（以下、PO）が作業の優先順位をつけていきます。

それに対してどのようにその作業を実行するかについては、メンバー自身が判断しながら動くことができる自己組織化したチームになっています。

また、各POはSpotifyとして掲げるロードマップを軸に、別の分隊のPOと連携しながら、それぞれのプロダクトバックログをうまく調整する役割も担っています。さらに、分隊はアジャイルコーチに協力を求め、仕事の進め方を進化させるための振り返りやコーチングなどをサポートしてもらうことができます。

分隊が複数集まる「部隊（Tribe）」は100名以下になるように設計されており、​​定期的に集まって各自の働き方やリリースした成果物、新しいツールなどを紹介し合います。例えば、全体の10%前後の作業時間を個人の学びなどに自由に使える「Hack Days（Week）」の成果を発表し合うことで、相互に学びを得ている形です。​

出典：https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

Spotify Modelでは各分隊が独立していることから、会社としての団結力を持つために「支部（Chapter）」と「ギルド（Guild）」も設置されています。

支部には一つの部隊の中で同じスキルを持つメンバーが集まり、それぞれの専門領域や特定の課題について議論していきます。また、ギルドは組織全体に横断で広がっている一種のコミュニティで、アジャイルコーチギルド、テスターギルドのように同じ専門領域に関心を持ち、情報共有をしたいメンバーが集まる形です。

Spotify Modelのエッセンスを取り入れる際は、こちらのようなチェックリストを参考にしていただければと思います。「分隊は自律的ですか？」「顧客からのフィードバックはすぐに得られますか？」「実験はチームで歓迎されますか？」といった、25項目のチェックリストになっています。

④既存のスクラムの仕組みを拡張しやすい「Large Scale Scrum（LeSS）」

前述のSAFeと比較して、シンプルなソリューション開発に臨む時に取り入れやすいのがLeSSです。

2〜8チーム（各チーム最大8人）で開発を行う形を基本のLeSSと呼び、8チーム以上の規模になった際にはエリアプロダクトオーナーを置き、各拠点のLeSSを拡大していく「LeSS Huge」という手法にスケールしていきます。

LeSSは大規模な開発においても最小限のアプローチで行うのが特徴で、ひとつのプロダクトに対してPOを一人置き、バックログもひとつのみで、全チーム共通でスプリントを進めていきます。個々のメンバーに担当を割り当てるというよりは、すべてのメンバーが全体に目を向けるイメージですね。

LeSSを運用する際には、「透明性」「顧客中心」「システム思考」「リーン思考」などの10の原則が定められています。

出典：https://less.works/less/framework

LeSSは既存のスクラムが根付いている組織であれば、その性質と大きく変わることがないので実装コストが少なく、LeSSの導入によって役割が急激に増加するようなこともありません。

一例として、LeSSに関する著書「Large-Scale Scrum: More with LeSS（著：Craig Larman、Bas Vodde）」は日本語訳も発売されており、国内での勉強会が豊富で企業事例も公開されているので、他の手法と比べても学びやすいフレームワークだと言えるでしょう。

【事例5選】アジャイルスケーリングの要素を取り入れている企業

基本のアジャイル開発は方法論などが確立されており、情報も豊富にあるためチームに取り入れやすい一方で、それをスケーリングする際には、フレームワークをそのまま真似したり、他社事例を流用する形で成功させるのは難しいのが実情です。

アジャイルのスケーリングにおいては、事業や組織の構造といったビジネスの根幹部分から最適化させていく必要があり、それぞれの企業のビジネスモデルや文化に合わせて独自のスタイルを模索していく形になるでしょう。

ここでは、これまでに挙げたフレームワークのエッセンスを取り入れて、組織開発している企業事例をご紹介します。

職種を超えた連携を生み出す「スクワッド組織」運営 / READYFOR

日本初のクラウドファンディングサービス「READYFOR」を運営する、READYFOR社。

同社では、ビジネスメンバーとエンジニアといった職種が異なるメンバーが一体となって、スピード感を持って業務を遂行するために、職種ごとのチーム編成をやめて「スクワッド組織体制」を導入しました。

ビジネスメンバーとエンジニアが共通言語を持って業務を遂行することで、スピード感を持ってミッションの実現へと前進できるようになったそうです。

従来は開発チーム全体でひとつの共通目標を追う形でしたが、エンジニア組織が拡大して10名を超えた頃から、フロントエンド・バックエンド・プロダクトマネジャーといった役割ごとにチームを分け、異なる目標を持つ必要性が出てきました。

しかし、役割単位でチームOKRを設定すると、必ずしも全社的なミッションに紐付かない部分が出てくるんです。メンバーによっても注力すべきミッションが異なっているので、適切なOKRを設定することが難しい側面がありました。

そこで、より良い組織の形を模索して行き着いたのが、Spotifyなどの先進的な企業で取り入れられていた「スクワッド組織」です。

スクワッド組織では、職種が異なるメンバーを「ミッション単位」で集め、スクワッドと呼ばれるチームを編成します。そして、スクワッドごとにミッションに基づいて意思決定をし、業務を遂行するのが特徴です。

この組織体制とOKRをかけ合わせることで、目標設定を最適化できるとともに、メンバーの自律性が促進され、意思決定スピードの向上も期待できると考えました。

現在は、半期もしくは四半期ごとに各スクワッドのOKRを決めて運用するフローとなっています。

▼スクワッド組織の導入によるミッションとOKRのアラインメント（イメージ図）

参考：組織の「乳化」を目指す。職種を超えた連携を生み出す「スクワッド組織」運営とは

ひとつのプロダクトを全員で作る大規模スクラム（LeSS）を導入 / Retty

日本最大級の実名型グルメサービス「Retty」を展開するRetty社。

当初はサービスの「ネット予約」「検索」​​といった目的別のチームに分けて、領域ごとに強く権限移譲をして開発していたものの、全社として何を優先すべきかという視点ではなく、自分たちの守備範囲の中で動く「部分最適」のような開発になってしまっていたそうです。

結果として、サービス全体としてユーザー体験がちぐはぐだったり、思っていた通りに成長しなかったり、といった課題が挙がっていたことから、全社的に大規模スクラム「LeSS」の体制へと移行しました。

LeSSにおいては、「組織全体でひとつのスクラムを回すことを考える。その上で、人数が多くスケールが必要なところを工夫する」という考え方を基に、ワンチームで開発を行っているそうです。

参考：「ひとつのプロダクトを全員で作る」大規模スクラム（LeSS）を導入したRetty開発組織の進化

拡大と分権化が進む中、誰もがプロダクト改善に臨む組織へ / ヤプリ

アプリ開発・運用・分析をノーコードで提供するアプリプラットフォーム「Yappli（ヤプリ）」を開発・提供するヤプリ社。

2013年に3名で事業をスタートした同社も、今や正社員数は250名に迫り（2022年6月末時点）、サービスの導入実績は600社以上。Yappliを通じて作られたアプリの累計ダウンロード数は1億を突破するなど成長を続けています。

その成長の裏側で、同社は事業と組織の継続的な成長のために数多の取り組みを実施してきました。例えば、創業初期から急成長フェーズを支えたYappliのCMS（コンテンツ管理画面）を、PHPからGoに全て刷新するという一大プロジェクトを実施。

また、月に2回、各自が好きな改善案件に集中できる「Yappdateday（ヤップデートデイ）」の実施や、誰でも改善アイデアをプレゼンできる「ヤプリク」の開催、組織全体の開発生産性を高めるための精鋭エンジニアメンバーで構成された「遊撃チーム」の設置など、組織全体でプロダクトの改善に向き合ってきたといいます。

組織づくりの文脈ですごく良いなと思っている取り組みが、「ウィンセッション（win session）」です。

我々は目標管理にOKRを導入しており、運用はヤプリ風に味付けはしていますが、仕組みとして良い部分は制度として積極的に活用するようにしていて。そのひとつがウィンセッションです。

具体的には、各プロジェクトの2週間分の進捗や取り組み、成果を発表して、それをお互いに称え合うという時間になっています。

発表者も小ネタを挟みながら笑いをとったり、Slackの実況チャンネルではにぎやかしがワイワイ盛り上がったり。プロダクト開発本部の雰囲気作りや、メンバーのヒーローマーケティング機会の創出にすごく役立っています。

参考：誰もがプロダクト改善に参加する組織を。巨大な技術的負債も乗り越えたヤプリの現在地

スプリントは1週間。素早く直せるシステム設計も実行 / AnyMind Group

2016年の創業後、世界13ヵ国、17拠点で事業を展開するAnyMind Group社。

ブランドの生産・EC構築・マーケティング・物流をワンストップで支援するプラットフォームを提供する同社では、「Product Developmentチーム」が7つのプロダクトの開発を担っています。

開発においてはスピーディーに成果を発揮することを重視し、「チームは小さく」「スプリントは1週間で回す」「マネジメントは現場の邪魔をしない」「個人よりチームの目標達成にフォーカスする」といった方針のもとで組織づくりを行っているそうです。

Product Developmentにおいては、エンジニアやプロダクトマネジャーがプロダクトごとにチームを編成し、それぞれが開発を行っています。これを、社内では「縦の軸」と呼んでいます。

それぞれのチームは、多くても15人、少ないチームでは3、4人ほどです。エンジニアって、一人ひとりが独立して動けるわけじゃないんですよね。プロダクトはひとつなので、最終的にはひとつのソースコードにマージする必要がある。

人数が増えるとコミュニケーションコストも増え、整合性も取れなくなるので、増えてきたら分割することになります。

マネジメントに関しては、そもそも多数のプロダクトを抱えるエンジニア組織を束ねることを考えると、「マネージャーが全部見る」というのは無理なんですね。ですから基本的には、現場が何でも決定していくことを良しとする、という大前提があります。

なので、あくまでも現場の意思決定の邪魔をしない、彼らがタスクに集中できるように整える、というサーバントリーダーシップに近いことを意識していますね。

参考：創業5年で13ヵ国に展開！AnyMind社の「現場の意思決定を邪魔しない」開発チームの在り方

全社の開発を止め、好きな開発に専念できる「Hack Week」 / メルカリ

半年ごとにエンジニアが「自由に」開発できる期間を設けることで、非連続な技術力の成長を後押ししているメルカリ社。

同社では、少数精鋭だったエンジニア組織が、2年で約3倍までに急増。それに伴って、「個人の裁量が減った」「目標ドリブンになりすぎて、新しい技術の習得が難しい」といった声が挙がり始めていたといいます。

そこで、開発スケジュールにメリハリをつけることや、新しい技術を検証してプロダクトに還元することを目的に、エンジニアのための技術のお祭り「Mercari Hack Week」を開催。

定期的に開催されているHack Weekには、同社のエンジニアほぼ全員に加えてプロダクトマネージャーや人事のメンバーも参加。結果的に100以上のアイデアが生まれ、実際のプロダクト機能に実装されたものもあるそうです。

Hack Weekはエンジニア主体のイベントですが、デザイナーやプロダクトオーナー、HRの方も参加していました。例えば、HRメンバーから「採用管理システムを自動化しませんか」と提案して、エンジニアとチームを組んで進めることもできます。

Hack Week開催後に実施したアンケート調査では、参加者の約90％が「満足」という高いレートを付けてくれて。「作りたいものを自由に開発できて嬉しかった」「業務では使えない技術に挑戦できた」といったポジティブな声を、たくさんもらうことができました。

運営側としても、個人の技術力の強化はもちろん、組織力の底上げにもなっていると感じます。また、Hack Week自体が社内外への「エンジニアリングの強さ」のアピールになると思っていて。

「自由に使える時間が1週間あれば、これだけのアイデアや新しい技術が出るんだ」と、エンジニア組織のポテンシャルを可視化できたことで、通常業務にも良い影響が生まれています。

▼Hack Weekの目的として社内に共有したスライド

参考：全員参加の技術の祭典！「自由な開発」で成長スピードを高める、メルカリの組織づくり

今回は、アジャイル開発のスケーリングをテーマに、その定義から各社の事例までご紹介させていただきましたが、いかがでしたでしょうか？

スケーリングには画一的な成功の型がないため難しさもありますが、これまでに生まれているワークフレームの発想や要素から、自組織の拡張へのヒントが得られると幸いです。（了）