事業貢献の本質は、ビジネスとITの調和
鈴木氏はまず、「事業貢献」について定義した。事業貢献とは、ビジネスとITが適切にリンクした状態を指す。システムの企画、開発、デリバリー、フィードバック、そして、再び企画というループが回っている状態だ。このループの回転がスムーズであるほど、事業貢献度が高いと言える。
単にサイクルが速く回れば良いわけではない。適切なサイクルのスピードが重要だ。ECサイトやオンラインWebサービスなら1週間以内の短いサイクルも考えられるが、業務システムの場合は1〜3か月程度の長めのサイクルが適している。
鈴木氏は「多くの現場では、さまざまな理由からこのループがうまく回らず、事業貢献ができません。せっかく良いものを作ろうとしても、会社の成果に結びつかないことがあるのです」と指摘した。
近年では、事業貢献を目指すためにアジャイル開発やスクラムを採用することが多い。その中心にはプロダクトオーナー（PO）がいて、顧客（ユーザー）と開発者をつなぐ役割を果たす。POは顧客の課題やニーズを見出し、それをIT的にどう実現するか開発者と調整しながら進める。
しかし、この理想的な形がうまく機能しないケースがある。例えば、アジャイルを採用しているにもかかわらず、決まった機能を決まった期間で作ることを要求されるなど、ウォーターフォール的なアプローチを強いられることがある。社内の都合が優先され、顧客への価値提供がないがしろにされる場合もある。
このような問題が生じる根本的な理由は、チームの中だけで物事を決められない組織構造にある。会社には階層があり、常に組織内での合意形成が必要となる。つまり、顧客と開発者という二者間だけでなく、周囲にも重要な関係者がいるからだ。予算を確保するために意思決定者や上層部に対して稟議を通したり、経営会議で説明したりする必要がある。また、業務システムの場合、業務部門との調整も欠かせない。顧客とPO、そして開発者を「横の合意形成」とした場合、意思決定者とPO、そして業務部門という「縦の合意形成」が必要となるのだ。
「一度承認されたことでも、ある部門の部長から却下されて変更を余儀なくされることがあります。スプリント開始後にそんな指示を受けると困ります。また、事業部長の承認が必要で来月の会議まで待ってくれと言われても、次のスプリントのタスクがなくなってしまいます……といった状況では、アジャイル開発の利点をいかせません」（鈴木氏）
