アジャイル作業のスケールアップアプローチはなぜ失敗するのか？

原文(投稿日：2019/03/21)へのリンク

アジャイルのスケールアップでお困りですか？あなただけではありません。局地的なアジャイル導入に成功した組織であっても，そのアジリティを組織全体に拡大することに苦労しているのです。問題は身近なパターンとして現れます。この中に心当たりはありませんか？

1. 他の組織のモデルのコピーは機能しない
2. 組織のデザインとアジャイルの目標が相反している
3. ひとつのチームでうまくいったことを，すべてのチームに"コピー・アンド・ペースト"しようとしている
4. 組織のさまざまな部分を独立的に最適化している
5. アジャイルエンジニアリングのプラクティスへの投資が不十分である

この記事では，アジャイルをスケールアップする際に直面する，一般的かつ体系的な課題について論じます。最後には，ポピュラーなスケーリングフレームワークが採用している，これらの課題へのアプローチの比較を行います。

他の組織のモデルのコピーは機能しない

大規模なアジャイルを持続するためには、組織構造、作業方針、行動を変える必要があります。他の大規模な変革と同じように、やりがいのある作業です。

手短な解決策は、他の組織で使用して成功を収めたアプローチをコピーすることです。この方法は，短期的にはメリットはあるかもしれません。しかし，時間が経つにつれて，このアプローチは成功しない確率が高くなるでしょう。

なぜでしょうか？アジャイルの旅には近道がないからです。アジャイルがあなたにとって何を意味するのか，それをどのようにサポートするのか，といったことに取り組まなくてはなりません。他の人たちの問題とあなたの問題は違います。彼らの答をコピーする訳にはいかないのです。

組織のアジリティの拡大を考えるのであれば，組織内の人たちが自分なりの働き方を持つ必要があります。そのためには彼らが，彼ら自身の状況において，彼ら自身のプロセスを作り上げなくてはならないでしょう。自身のプロセスを作り上げることで，自分たちにとって何がうまくいくかを学び，その結果として，"ここでのやり方"が新たな文化として現れるのです。

他の誰かのモデルを採用するというのは，質問を知る前に答を求めることに似ています。おそらくは成功しないでしょう。そうではなく、最も単純なプロセスから始めることを考えてください。それを基盤として，経験的プロセス制御(Empirical Process Control)と，改善すべきものすべてに対して透過的なフレームワークを使用して構築するのです。そのフレームワークはスクラムと呼ばれるものです。

2001年，Toyotaは，"The Toyota Way"という本を出版しようとしました。これを聞いた同社のCEOはその題名に反対し，"The Toyota Way 2001"と呼ぶべきだ，と指示しました。次の年になれば，同社の働き方は変化しているからです。

真のアジャイルによってこそ，組織は、絶え間なく変化する世界に適応し続けることが可能になるのです。他の誰かの"モデル"をコピーしてアジリティへの道を近回りしたところで，ある時点での彼らの状況を反映しただけの，つまらない偽物になるのが関の山でしょう。

組織のデザインとアジャイルの目標が相反している

組織がアジリティを追求するのは、変化を続ける市況への適応能力を向上させるためです。そのためのアジャイルな方法は、競合他社よりも早く学ぶ，ということです。組織レベルでこれを達成するには、組織に対して，迅速な学習と変化への適応に最適化されたデザインを備えることが求められます。

アジリティに最適化した組織のデザインには，次のようなメリットがあります。

• プロダクトやサービスのパフォーマンスに関する透明性が向上し、より優れた戦略実行の管理が可能になる
• 具体的な成果の達成に向けて，戦略的なチーム配置と資金配分を行う能力が向上する
• 問題に最も近い位置にあって、適切な情報による適切なタイミングでの意思決定が可能な人々による，迅速な決定が可能になる
• 変化する市況に対して，資本と人員をより活用できるようになる
• 高い目標を設定し，それを達成する組織文化が生まれる

よいことばかりのように思われますが，偶然起きるものではありません。組織のデザインは、適応性に関する目標と明確に一致させる必要があります。従来の組織デザインは，一般的にはリソースの使用率と成果の予測可能性を中心に、さまざまな目標に合わせて最適化されています。このことは、次のようなシナリオに適応する能力を妨げる可能性があります。

• 予測可能性を望むということは，詳細なプランの作成と，そのプランに対するパフォーマンス測定に重点を置くという意味です。プランからの逸脱は、プランを新たな現実に適応させるのではなく、プランの遵守を徹底することによって対処されます。
• そのような組織には，プランからの逸脱を悪とする傾向があります。これは透明性を低下させると同時に，罰を避けたいという考えから，結果的にプランの誤りを示すような情報が隠蔽されるようになるのです。
• 階層的コントロールを肯定する考え方から，意思決定は，解決すべき問題や支援する顧客との距離の近さよりも，組織における個人のレベルを基準として実施されるようになります。これは意思決定を遅らせる要因になり得ます。

フォーミュラ1カーとオフロードラリーレースカーのデザインの比較から，これを説明しましょう。

フォーミュラ1カーは，有名でよく整備された，舗装のしっかりしたサーキットでのスピードと運転性のために最適化されています。天候の変化に対処しなければならない場合はありますが，メカニカルな問題を扱う専門のピットクルーがいますし，経路探索に関する問題はありません。

ダカールラリーでレースするようなオフロードラリーチームは、スペアパーツをすべて自分で持っていなくてはなりません。様々な路面状況に対処しなければなりませんし，競争相手よりも早くゴールに到達するには，臨機応変な行動が必要です。

フォーミュラ1カーもオフロードレーサーもスピードを目標としていますが、オフロードラリーでは未知数が多いため，チームや車に高い順応性が求められます。フォーミュラ1カーの方が速度では勝りますが，それははるかにコントロールされた環境で走行するからに過ぎません。もしラリーに出れば，ほぼ一瞬で取り返しのつかないほど壊れてしまうでしょう。

今日の世界における組織は，変化する条件への対応能力が勝者を決めるという，フォーミュラ１レースよりオフロードレースに近いレースの中にあるといえるでのです。

組織の一般的なデザインは階層構造である

上述のように，階層構造は、プランからの乖離を迅速に識別し排除することによって，プランの遵守行動を効率面から最適化します。

John Kotter氏は，階層構造がこれとは別の目標をもたらすことを強調しています。

... 問題なのは、思想的にも実務レベルにおいても、階層構造(およびその管理プロセス)は変化に抵抗するものであるということです。異例を排除し，プロセスを標準化し，短期的な問題を解決して，現在の運用モードにおけるストップウォッチ的な効率を達成しようとするのが階層構造なのです ...

アジリティはその本質から、プランに誤りがあって修正または破棄しなければならない場合を想定しなければなりません。階層構造の組織にとってこれは脅威です。コントロールや効率の最適化，適応性や学習速度の最適化が不可能になるからです。そのため、組織デザインを表面的に変更させても、古い体系的な目標が残ることになるのです。

アジャイル展開のイニシアティブが現行の権力構造と対立し始めると，システムは旧来の目標を維持しようとするため，活動を阻まれる可能性が非常に高くなります。彼らは現行の作業標準に関する取り決めや方針を持ち出して，新たな作業方法を否定する手段として使用します。このようになるのは，彼ら自身が変化を拒みたいという理由よりも，むしろ彼らが働いているシステム自体が，彼らが抵抗するように期待しているのです。

ひとつのチームでうまくいったことを，すべてのチームに"コピー・アンド・ペースト"しようとしている

もうひとつの一般的な誤解は、アジリティの拡大とはチームが変わればよいことであって，管理システム，組織の構造や方針，組織全体の文化といったものは大きく変わらなくてもよい，という考えです。これに賛同する組織は，スクラムチームのコピー・アンド・ペーストでアジリティを拡大しようとします。各スクラムチームにはプロダクトオーナとチームのバックログ，開発チーム，多くの場合はスクラムマスタが新たに配置されるのです。

このような戦略は、複数のスクラムチームがひとつのプロダクトに取り組む必要があると，急速に崩れ始めます。多くのスクラムチームが参加することで，調整の必要が発生し，結果としてプロセスが追加され，依存関係を管理するための調整役がさらに増えることになります。新たに参加したチームには、それぞれが全体を考慮せずに，自身のアウトプットをローカルに最適化しようとする傾向が現れます。

プロセスが多くなるということによって，正しさを保証する責務はプロセスにあると誰もが考えるようになり，チームの所有権や説明責任を崩壊させます。プロセスの改善は他の誰かの問題になるのです。チームと顧客との間での引き継ぎが増えることも，顧客の共感を失い，プロダクトに対するチームの理解を低下させる原因になります。

最後には、新たに参加したチームのバックログにより、プロダクトレベル全体で進捗の透明性が低下し、新たなステータスや調整のためのミーティングが必要になります。このような複雑性の増加すべてが，組織の適応能力を低下させるのです。

組織のさまざまな部分を独立的に最適化している

階層組織でアジリティを拡大しようとする場合，既存の組織構造でアジャイルを運用することに重点が置かれることから，組織内の人々やチームそれぞれが隔離された状態のままになります。結果として，アジャイルビジネス分析チーム、アジャイルアーキテクチャチーム、アジャイルプロジェクト管理チーム、あるいはDevOpsチームといった、機能的にサイロ化されたチーム，自分たちだけでは何も提供できないようなチームが出来上がることになります。各チームがひとつのコンポーネントに重点を置いている場合にも，同じような問題が存在します。アジャイルデータベースチーム、アジャイルUXチーム、あるいはアジャイルJavaチームが生まれるのです。これらのチームは，いずれも自分自身では何の価値も提供することができません。

このようなチームであっても，個々にパフォーマンスを向上すれば全体のパフォーマンスが向上する，と考えるのは間違いです。なぜなら，チームが連携して作業成果物を生み出すという，重要な問題が見落とされているからです。

部分的なパフォーマンスを落とした方が全体のパフォーマンスは向上する，という場合はたくさんあります。システムのパフォーマンスは、部分部分がどのように相互作用するかに依存するのであって、それぞれの部分が独立的に活動する方法に依存するのではないのです。

Russell L. Ackoff教授 ("Recreating the corporation"，オックスフォード大学出版局，1999年)

実用的なプロダクトを開発する能力がチームになければ，ユーザニーズを満たすソリューションを開発しているかどうかを知ることはできません。スケールアップしていない状態でもこれは同じですが，スケールアップした場合はその影響も大きくなります。この問題を解決するには、チームが機能横断的であること，コンポーネント横断的であること、ユーザの問題解決に責任を負うこと、完全なエンドツーエンドのソリューションを提供すること，が必要になります。

つまり，こういうことです。

• よりよい顧客成果を遅滞なく提供するための，プロダクトを中心とした組織デザイン
• ひとつのプロダクトに取り組む機能チームで構成された，プロダクト組織の構築
• 機能横断型(cross-functional)チームが機能横断的なマネージャに報告する，機能横断型組織への移行
• プロダクトオーナに対して、市場顧客あるいはユーザから受け取ったフィードバックに基づく投資決定を下す権限を与える，予算編成システムの導入
• 学習と協力的な機能横断型フレームワークを重視し，チームおよびチームメンバの能力を継続的に拡大し，問題解決の権限を彼らに与えると同時に，その能力向上をサポートするような管理システムと文化の変革

アジャイルエンジニアリングのプラクティスへの投資が不十分である

アジャイルチームに参加して開発チームやスクラムマスタ，プロダクトオーナの業務を支援してくれるコーチの雇用が必要であることは広く理解されていますが，そのチームの実践する技術的な優秀性を改善するためのコーチを雇用することの重要性はほとんど理解されていません。結果として，コード品質の維持や向上ができないため，アジャイルを拡張することができないのです。

アジャイルソフトウェア開発において重要なのは、短時間かつ低コストで変更が可能で，期待されたものを提供できていることを検証できるように，ソフトウェアが柔軟であることです。これを実現するには、アジャイルエンジニアリング手法を使用して高品質のソフトウェアを開発する必要があります。プロセスや付箋紙，スクラムマスタ，アジャイルな組織デザインなどをすべて揃えることができたとしても，高品質なソフトウェアとエンジニアリングプラクティスにおける高い能力がなければ，プロセスはその途中までしか進むことができません。

アジリティの拡大は，ビルドプロセスとテストプロセスの効率的な自動化から始まり，最終的にはデリバリパイプライン全体を完全に自動化することが必要です。プロダクトの部分部分が簡単に変更ないし置き換えできるために，開発対象プロダクトが分離型アーキテクチャを備えていることも必要となります。バージョン管理の方法も重要です。トランクベース開発、特に機能ブランチの排除と継続的インテグレーションは、チームが効果的に同期し、技術的負債が目に見えないまま徐々に肥大することを避ける上で，まさに必要不可欠なものです。

これらの課題に対して，さまざまなスケーリングフレームワークが採用しているアプローチを比較する —  SAFe、LeSS、Nexus

さまざまなスケーリングフレームワークに見られる違いは、アジャイルのスケールアップにおける主な課題に対する思想的な違いを反映しています。SAFeは，可能な限り既存の組織に適合するように試みることで，対立を回避し，混乱を最小限に止めようとします。LeSSは、既存の組織デザインを，複数チームでプロダクト開発を行う上での根本的な障壁であると見なし，これに正面から対抗します。Nexusは，組織の問題を解決しようとはせず、代わりに複数のチームが協力して大きなプロダクトを開発することに重点を置きます。次の表ではこれらの違いを示した上で，さらにはそれぞれが５つの課題とどのように対応しているかを比較しています。

結論: アジャイルの拡大とは，組織的なアジリティの向上である

他人の真似をしても，アジリティを拡大することはできません。自分自身で、独自のコンテキストにおいて，どのようなプロセスや構造、ポリシが機能するのかを学ばなければならないのです。アジリティを継続的に向上させるには、組織内の人々が自身のプロセスを所有し、時の経過と共に改善することが求められます。

その過程の中で、変革の機会を探してください。

• 組織設計の変更: 利用することではなく，価値を最大化することに重点が移るように、新たな作業の取り決めやポリシ、新たな組織構造が必要になるかも知れません。大部分の組織は構造化されているので、組織内において，価値は垂直ではなく水平に流れます。
• スキルの変化: 顧客と共同で構築した高いレベルのプロダクトを高い頻度で提供できるようにするためには，新たなプラクティスを学ぶことが必要になるでしょう。
• 振る舞いの変革: チームの成果に責任を持つ真のチームにあって，チームとともに仕事をするように，自分自身に求めるようになります。

アジリティは，組織が採用するプロセスやツールやフレームワークのようなものではありません。試行と学習を包含する考え方であり，仕事の方法なのです。難しい作業をすべて省くことのできる近道はありませんが，幸運なことに，試行や学習は楽しいものなので，それが未知の領域に足を踏み入れることの抵抗を少なくしてくれます。すべての答を持つ必要はありません。新しいことを試すという目標と意欲さえあればよいのです。

著者について

Cesario Ramos氏は2001年からアジャイルプロダクト開発に取り組んできました。現在はアジャイル組織のコーチおよび製品開発のエキスパートとして，世界中で活躍しています。氏はこれまで、ハイテク，大手銀行、保険、通信など、さまざまな組織で働いてきました。書籍"EMERGENT —  Lean & Agile adoption for an innovative workplace"の著者であり、"Scrum Patterns"の共著者です。氏は世界中の会議で数多く講演し、LeSS会議を共催しています。Scrum.org公認LeSSトレーナー兼プロフェッショナルスクラムトレーナーでもあります。2010年には、世界中でコンサルティングとトレーニングを提供するコンサルティング会社であるAgiliXを設立しました。

Kurt Bittner氏は、短期間のフィードバック駆動サイクルによる実用的ソフトウェア開発の経験を，30年以上にわたって積んできました。その間，大手銀行と保険、製造、小売といった組織、大規模な政府機関など、さまざまな組織がアジャイルなソフトウェア配信プラクティスを採用するのを支援してきました。Forrester Researchの元テクノロジー業界アナリストでもあります。氏が取り組んでいるのは、組織や顧客に気に入られるようなソリューションを提供する、強力かつ自己組織化されたハイパフォーマンスチームの構築を支援することです。氏は"Nexus Framework for Scaling Scrum"など、ソフトウェア開発関連のトピックに関する4冊の本の著者です。現在はコロラド州ボールダを拠点として、Scrum.orgのエンタープライズソリューション担当副社長を務めています。