アジャイルは"電車"、ウォーターフォールは"タクシー"？──事業貢献を加速させる組織改革とプラットフォーム戦略

【23-A-6】事業貢献できるチームを機能させるための組織とプラットフォーム

　事業に貢献するチームは、「ビジネス目標」と「IT活動」が整合している状態が望ましい。これを実現するためのマネジメント手法として、アジャイルが広く知られているが、チームの組織的・技術的な環境が適切でなければ、その効果は十分に発揮されない。2024年7月23日に開催されたDevelopers Summit 2024 Summerで、グロース・アーキテクチャ＆チームス（Graat）の代表取締役社長、鈴木雄介氏は、企業内のIT組織がどのように事業に貢献していくかについて、実践的な知識と方針を共有した。

事業貢献できるチームを機能させるための組織とプラットフォーム - デブサミ夏2024 from Graat（グラーツ）

事業貢献の本質は、ビジネスとITの調和

　鈴木氏はまず、「事業貢献」について定義した。事業貢献とは、ビジネスとITが適切にリンクした状態を指す。システムの企画、開発、デリバリー、フィードバック、そして、再び企画というループが回っている状態だ。このループの回転がスムーズであるほど、事業貢献度が高いと言える。

　単にサイクルが速く回れば良いわけではない。適切なサイクルのスピードが重要だ。ECサイトやオンラインWebサービスなら1週間以内の短いサイクルも考えられるが、業務システムの場合は1〜3か月程度の長めのサイクルが適している。

　鈴木氏は「多くの現場では、さまざまな理由からこのループがうまく回らず、事業貢献ができません。せっかく良いものを作ろうとしても、会社の成果に結びつかないことがあるのです」と指摘した。

グロース・アーキテクチャ＆チームス株式会社 代表取締役社長 鈴木 雄介氏

　近年では、事業貢献を目指すためにアジャイル開発やスクラムを採用することが多い。その中心にはプロダクトオーナー（PO）がいて、顧客（ユーザー）と開発者をつなぐ役割を果たす。POは顧客の課題やニーズを見出し、それをIT的にどう実現するか開発者と調整しながら進める。

　しかし、この理想的な形がうまく機能しないケースがある。例えば、アジャイルを採用しているにもかかわらず、決まった機能を決まった期間で作ることを要求されるなど、ウォーターフォール的なアプローチを強いられることがある。社内の都合が優先され、顧客への価値提供がないがしろにされる場合もある。

　このような問題が生じる根本的な理由は、チームの中だけで物事を決められない組織構造にある。会社には階層があり、常に組織内での合意形成が必要となる。つまり、顧客と開発者という二者間だけでなく、周囲にも重要な関係者がいるからだ。予算を確保するために意思決定者や上層部に対して稟議を通したり、経営会議で説明したりする必要がある。また、業務システムの場合、業務部門との調整も欠かせない。顧客とPO、そして開発者を「横の合意形成」とした場合、意思決定者とPO、そして業務部門という「縦の合意形成」が必要となるのだ。

プロダクトづくりはユーザーと開発者だけでは進まない

　「一度承認されたことでも、ある部門の部長から却下されて変更を余儀なくされることがあります。スプリント開始後にそんな指示を受けると困ります。また、事業部長の承認が必要で来月の会議まで待ってくれと言われても、次のスプリントのタスクがなくなってしまいます……といった状況では、アジャイル開発の利点をいかせません」（鈴木氏）