「アジャイルは責任者が分かりにくくて、相談しづらいんです」。筆者が支援していたプロジェクトで顧客の担当者から言われた言葉だ。そのプロジェクトは顧客による内製チームで、社員を中心に構成されていた。逆に相談しやすいはずだが、といぶかりながらも相談したい内容を確認した。「次のリリースにどうしても入れたい機能があるんですよ。今までの開発だったら何とか押し込んでもらっていたんですが、プロダクトオーナーに聞いてもスクラムマスターに聞いても、別の作業を落とすなら可能だ、の一点張りなんです」。私はこの言葉を聞いて落胆するとともに、根強く残る“お客様意識”に恐怖を覚えた。

　こうした考え方は、ウォーターフォール型のプロジェクトでは、望ましくはないが通用した。プロジェクトの責任者は「プロジェクトマネジャー（PM）」として明確に示されている。顧客はPMと交渉すれば、たいていはなんとかする方向で動いてもらえる。顧客はお客様、プロジェクトマネジャーは業者であり、わがままを言いやすい。約束したスコープを踏み越え、追加の要求を「押し込む」行為は、当然のように行われている。

　もちろんPMも無策に押し込みを受け入れるわけではない。追加要求の押し込みを想定して、バッファーという形で余力を見積もりに含ませておく。見積もりや計画に不透明な“のりしろ”を残してプロジェクトを進め、双方の許容範囲の中で落としどころを探る、というのが今の現実的なプロジェクトマネジメントの姿だ。

アジャイルでは無駄をそぎ落とす

　一方、アジャイルでは、無駄をそぎ落としてプロジェクト運営の透明性を突き詰める。基本行動としては、要求の追加や変更を受け入れる。そして、それを反映させた再見積もりと再計画を実施。要するコストと時間を加えた計画を許容できるか判断する。許容できないなら、既存の要求を除外するか要求の変更を取りやめる。「バッファーを使って無理矢理押し込む」という考え方は存在しない。

　こうしたアジャイルプロジェクトでは、PMのような集中した権限を持つ人がいない。リリースする製品の仕様や要求の優先順位は「プロダクトオーナー（PO）」が責任を持ち、作業の見積もりやアサイン、進捗状況の把握は「スクラムマスター」が主導する。技術面は「アーキテクチャーオーナー（AO）」が支える。この“三権分立”によってプロジェクトの重要な判断が行われる。

　例えば、エンドユーザーから追加要求の依頼が入ったとする。POが「製品仕様にぜひ追加すべき」と判断したなら、優先度を付けてバックログ（取りかかる予定の仕事）に追加する。AOは技術的な難易度を判断して、見積もり値を割り付ける。新たな技術要素が必要なら大きな値になる。スクラムマスターは見積もり値と優先度を考慮して、実装可能なスプリントに割り当てる。計画変更によって、実装予定だった機能の割り当てられるスプリントがリリースよりも後になることもある。

　さて、冒頭の担当者の質問に戻ろう。回答は次のようなものになる。「責任者は、PO、スクラムマスター、AOの三者です。それぞれがシステマチックに決定していくので、無理矢理押し込むものではありません。既存機能を落とさずに追加したいなら、一緒にその方法を考えましょう」。既存機能の簡略化やスプリントの組み立て方の工夫で、うまく収まる可能性もある。そうしたアイデアを皆で出し合えるのが、アジャイルの最大の利点だ。