アジャイル開発を電車に例えると
まずはアジャイル開発から見ていこう。鈴木氏は「突然ですが、クイズです」と切り出した。タクシーと電車のどちらがアジャイルっぽく見えるだろうか。
答えは電車だ。タクシーはどこへでも行けて自由度が高いものの、調達に時間がかかり、ドライバーのスキルに左右されることもある。一方電車は、運行区間や料金があらかじめ定められていて自由度が低い半面、ルールが明確なので、安定的・継続的に何かをデリバリーするときには便利である。
電車の在り方をスクラムで考えてみよう。電車は定期的に駅から駅へと運行している。ホームでは乗客が並んで待ち、電車が着くと定員まで乗客を乗せて発車する。電車の運行がスプリントで、出発ホームがプロダクトバックログ（やりたいことのリスト）、乗客はプロダクトバックログのアイテム（リストの1つ）となる。
電車は乗客を安全に目的地まで運ぶことに集中すればいいので、次の電車の乗客が誰かは気にしなくてもいい。これは「いまやること」と「次にやりたいこと」の分離であり、開発リソースの調達が不要で無駄がないと言える。
ただし、電車に乗り遅れないようにする（荷物をまとめてホームで待つ）のは乗客の責任となる。スクラム開発で言うと、プランニングまでに要件を詳細化し並べ、見積もり可能なレベルにする必要がある。
ここに見えない壁がある。この詳細化は開発側ではなくビジネス側の責任なのだ。スプリント内で開発者が詳細化していると、見積もりは曖昧になってしまう。
プロダクトオーナーの役割
そこでビジネスを理解できるプロダクトオーナー（PO）が要件の詳細化を主導していく。この詳細化は調整事項が多いため、スプリントとは独立して行う。もしPOが企画部門やビジネス側出身で詳細化のスキルが乏しいのであれば、開発経験者をPO支援（プロキシPO）につけるといい。なおスクラムマスターが暗黙的にPOを担うことも多いが、これはアンチパターンだ。スクラムマスターが機能しなくなってしまう。
鈴木氏は「POの最大の仕事は決定すること」と言う。電車の例だと、どの電車にどんな順番で誰を乗せるかを決めることにあたる。決定を遅延させたり、覆したりしてはいけない。また、POをうまく機能させるためには組織全体でPOの決定を尊重する必要があるが、困難もある。
POはユーザーや開発者に向けた横の調整だけではなく、意思決定者や業務との縦の調整もしていく必要がある。会社の意思決定者に向けては説明責任があり、業務現場にはオペレーションの業務調整など合意形成する必要がある。
もしPOがスティーブ・ジョブズのように、会社の全権を掌握する意思決定者であり、プロダクトの育て方も理解し、業務側の意思決定者でもあり、顧客の未来も見えているのであればいいが、通常は縦と横の調整は難しい。
この壁を越えるための策として、鈴木氏は「組織としての意思決定プロセスを明確にする」ことを伝えているそうだ。鈴木氏のおすすめは、縦の合意形成に必要な人を集めたミーティングの定期的な開催。これをスプリントと同じサイクルで行うのだが、ミーティングはスプリントプランニングの手前なので、スプリントレビューとは別にする。
鈴木氏は「偉い人と細かく定期的に話す。3カ月前だと忘れられてしまうことでも、毎週やっていると現場と意識が合うのでミーティング時間が短くなり、ITをグリップしている感覚も持てるので、うまく回るようになります。また小さな失敗の報告がしやすくなります」と話す。
