事業貢献の本質は、ビジネスとITの調和
鈴木氏はまず、「事業貢献」について定義した。事業貢献とは、ビジネスとITが適切にリンクした状態を指す。システムの企画、開発、デリバリー、フィードバック、そして、再び企画というループが回っている状態だ。このループの回転がスムーズであるほど、事業貢献度が高いと言える。
単にサイクルが速く回れば良いわけではない。適切なサイクルのスピードが重要だ。ECサイトやオンラインWebサービスなら1週間以内の短いサイクルも考えられるが、業務システムの場合は1〜3か月程度の長めのサイクルが適している。
鈴木氏は「多くの現場では、さまざまな理由からこのループがうまく回らず、事業貢献ができません。せっかく良いものを作ろうとしても、会社の成果に結びつかないことがあるのです」と指摘した。
近年では、事業貢献を目指すためにアジャイル開発やスクラムを採用することが多い。その中心にはプロダクトオーナー（PO）がいて、顧客（ユーザー）と開発者をつなぐ役割を果たす。POは顧客の課題やニーズを見出し、それをIT的にどう実現するか開発者と調整しながら進める。
しかし、この理想的な形がうまく機能しないケースがある。例えば、アジャイルを採用しているにもかかわらず、決まった機能を決まった期間で作ることを要求されるなど、ウォーターフォール的なアプローチを強いられることがある。社内の都合が優先され、顧客への価値提供がないがしろにされる場合もある。
このような問題が生じる根本的な理由は、チームの中だけで物事を決められない組織構造にある。会社には階層があり、常に組織内での合意形成が必要となる。つまり、顧客と開発者という二者間だけでなく、周囲にも重要な関係者がいるからだ。予算を確保するために意思決定者や上層部に対して稟議を通したり、経営会議で説明したりする必要がある。また、業務システムの場合、業務部門との調整も欠かせない。顧客とPO、そして開発者を「横の合意形成」とした場合、意思決定者とPO、そして業務部門という「縦の合意形成」が必要となるのだ。
「一度承認されたことでも、ある部門の部長から却下されて変更を余儀なくされることがあります。スプリント開始後にそんな指示を受けると困ります。また、事業部長の承認が必要で来月の会議まで待ってくれと言われても、次のスプリントのタスクがなくなってしまいます……といった状況では、アジャイル開発の利点をいかせません」（鈴木氏）
アジャイルとウォーターフォールの違いを関係者にわかりやすく伝える方法
アジャイル開発の本質を理解することが、組織的な問題を解決する第一歩だと鈴木氏は説く。彼は遊園地にある電車のアトラクションを例に挙げ、アジャイルの仕組みを説明した。
この例えでは、電車が開発者たち、ホームの乗客が案件、駅長がプロダクトオーナーを表す。電車への乗車は、スプリントプランニングでのタスク引き渡しに相当する。通常の電車と異なる点は、走行中にホームの乗客（案件）の並び順（優先順位）を変更できることだ。
重要なのは、電車（開発者たち）が定期的に運行を続け、電車に乗る乗客（案件）が決まるのは出発直前でも構わないという点だ。これにより、進行中の作業と将来の計画を分離できる。電車が出発した後も、ホームでは次の乗客の並び替えができる。この並び替えは走行中の電車に影響を与えない。このモデルにより、変化する要求に迅速に対応しつつ、安定した開発プロセスを維持できる。
一方、ウォーターフォール型開発はタクシーに例えられると鈴木氏は語る。タクシーは行きたい場所に自由に行けるため柔軟性のあるアジャイルに似ているように思えるが、実際は違う。ウォーターフォールでは、案件が決まってから初めて開発チームの調達を始める。これはタクシーを捕まえるのに似ており、適切なチームが見つからない可能性がある。また、開発の質はチーム（運転手）の能力に大きく左右される。さらに、IT業界の好況期には優秀なチームの確保が難しくなる。これは雨の日にタクシーが捕まりにくくなるのと似ている。
最大の問題は、一度開発（走行）が始まると、方向転換が困難になることだ。タクシーで高速道路を走行中に目的地を変更するのと同様、ウォーターフォールでは途中での要件変更が大きな混乱と追加コストやリスクを招く。これらの特徴は、変化の激しい現代のビジネス環境には適さないと鈴木氏は指摘している。
電車モデル（アジャイル）では、誰がどの電車に乗っているかを管理するだけで、全体の状況が把握しやすい。これは複数の案件を並行して進める際に特に有効だ。タクシーモデル（ウォーターフォール）では、多数の案件を個別に追跡するのは煩雑になりがちだ。
POへの単なる権限委譲は責任放棄──トップが組織の調整にコミットするべき
ただし、電車モデルには重要なルールがある。乗客（案件）は電車の出発時間に間に合わせなければならない。この責務はビジネス側にある。乗車準備が整っていない、つまり要件が曖昧で正確な見積ができない案件は、電車に乗せられない。この考え方を組織全体で理解することが重要だ。アジャイルの成功は、電車（開発者たち）の性能だけでなく、乗客（案件）の準備状態にも大きく依存する。走行中の電車への「飛び乗り飛び降り自由」な状態になれば、当然、良い開発はできない。
鈴木氏の電車モデル・タクシーモデルの説明は、ビジネス側も含めた組織全体の理解を得やすいという。理解が進めば、次は電車のダイヤを組む。これはリリースサイクルとリードタイムの設定に相当する。リリースサイクルは電車の周回時間、リードタイムは改札から乗車して戻ってくるまでの時間に例えられる。通常、リードタイムはリリースサイクルの2〜3倍になることが多い。
多くの大企業では、新機能や業務改善のリリースサイクルは3か月（年4回）で、リードタイムは6〜9か月程度に設定するのが良い。一方、保守や小規模な改修は週単位（年50回程度）でリリースし、リードタイムは2〜3週間だ。
ここで重要なのは、改札通過から電車乗車までのプロセスを明確にし、組織内で合意形成すること。これは案件の優先順位決定プロセスになる。一般的には、ビジネス側とPO、開発者で決める。まず案件募集の締切日を決め、ビジネス側が案件を検討する。POは相談に乗り、要件の確認を行う。次に開発者が概算見積を行い、リスクポイントを洗い出す。その後、優先順位の調整を行い、案件規模が開発のキャパシティ内に収まるよう調整する。最後にスプリントプランニングをして開発がスタートする。
「特に強調したいのは、締め切りを守ることの重要性です。電車の発車時刻に遅刻した人が電車に乗ろうとするのは明らかに問題視されます。同じようにプロジェクトの締め切りを守れないことは深刻な問題で、この考え方を組織全体で理解し、共有する必要があります」
組織の縦と横のリズムを合わせることに組織全体が合意できるかどうかが、事業貢献できるチームが機能するかのカギとなる。POは駅長のような役割を果たして横と縦の調整を行う。ただし、POが全てを決定するのではなく、組織全体でのプロセス整備とステークホルダーとの調整が重要だ。鈴木氏は「POへの単なる権限委譲は、組織としての責任放棄にすぎません。むしろ、上層部が組織のプロセス整備にコミットし、その中でPOが調整役として動き回る方がはるかに効果的です」と語った。
事業貢献を加速させる新たなプラットフォーム戦略
一方、技術面での課題として、まずモノリスの問題がある。巨大な一枚岩のシステムでは、一部分の変更が全体に影響を及ぼし、影響調査やテストに多大な時間がかかる。これがアジャイルな開発を妨げる要因となっている。この問題を解決するためにマイクロサービスが提唱された。機能間の依存性を最小限に抑え、独立した変更を可能にする考え方だ。しかし、近年では全てをマイクロサービス化することは新たな問題を生むことが指摘されている。データの不整合、複雑な構成管理、高いメンテナンスコストなどが課題となる。
そこで現在は、モノリスとマイクロサービスの両極端を避け、適切な粒度を考える方向に進んでいる。システムの特性に応じて、モノリス、アプリケーション、サービス、マイクロサービスなど、さまざまな粒度を選択できる。また、これらの連携方法も、同期APIだけでなく、非同期API、DB共有、ファイル連携、イベントストリームなど、状況に応じて適切に選択する必要がある。鈴木氏は「銀の弾丸は存在せず、各システムやプロダクトの特性に合わせて適切なアーキテクチャを選択することが重要です」と話した。
鈴木氏は、技術的な問題の新しい解決策として、Internal Developer Platform（IDP）またはプラットフォームエンジニアリングと呼ばれる手法を紹介した。これは、複数のチームやシステムが個別にクラウド設定を行う代わりに、一元管理するためのプラットフォームやガイドラインを準備する考え方だ。
IDPは、DevOpsや運用管理基盤として機能し、コンテナ化を重視する。Kubernetesなどのコンテナオーケストレーションツールを使用し、Gitリポジトリ、CI/CD、オブザーバビリティ、チケット管理などを統合する。これにより、セキュリティ設定が完了したクラウド環境とテンプレート、ガイドラインを提供できる。
さらに、社内の基幹システムのデータやロジックも統合し、新サービス開発時の基幹システムとの調整を簡素化する。これは、1週間〜3か月といったサイクルで開発を行う際の大きな障壁を取り除くことにつながる。IDPの運営について鈴木氏は書籍「チームトポロジー」（日本能率協会マネジメントセンター刊）の概念を紹介した。直接的に事業貢献する「ストリームアラインドチーム」と、それを支える「プラットフォームチーム」によって運営していくというものだ。
最終的には、IDPをもとにして、システムを段階的にモダナイズし、新しいサービスを作成していく。モノリスな構造から、より分割された事業貢献しやすいシステムへと徐々に移行していく。
最後に鈴木氏は、「従来のシステムの一括再構築では、システムの中身は変わっても枠組みは変わらないことが多かったです。しかし、システムの枠組み自体を、事業や業務の範囲に合わせて柔軟に変更する必要があります。そのためにプラットフォームを構築し、そこから少しずつシステムを切り出していくアプローチが効果的です」とコメントした。
