アジャイル開発の理想と現実：なぜ「ただの計画なき開発」に陥るのか

「アジャイルだから仕様は後で決めましょう」の罠

システム開発の現場で「今回はアジャイルで進めたい」という要望をもらうことが増えた。しかし、その言葉の裏にある期待を探っていくと、「要件定義をサボりたい」「開発途中でも無料で仕様変更し放題にしたい」という本音が透けて見えることが少なくない。断言するが、それはアジャイルではない。ただの「計画なき開発」だ。

受託開発とアジャイルの相性の悪さ

そもそも、予算と納期がガチガチに決まっている日本の一般的な受託開発契約と、アジャイル（特にスクラム）は相性が悪い。アジャイルは「スコープ（作るもの）を柔軟に変えながら、価値を最大化する」手法だが、発注側は「決まった予算内で、最初に思い描いたものを全部作ってほしい」と考えている。この前提のズレを放置したままスプリントを回し始めると、必ずどこかで破綻する。

破綻を防ぐための3つの防波堤

1. 「やらないこと」を明確にする

アジャイルは仕様変更を受け入れるが、それは「無限に機能を追加できる」という意味ではない。新しい機能を入れるなら、代わりに何かを落とす（スコープから外す）必要がある。この「トレードオフの原則」を、プロジェクトのキックオフ段階で発注側と強く合意しておかなければならない。

2. プロダクトオーナー（PO）の覚悟を問う

アジャイルが機能するかどうかは、発注側のプロダクトオーナーの力量にかかっている。バックログの優先順位を即座に決断し、時には現場の要望を切り捨てる権限と覚悟があるか。POが「持ち帰って検討します」を連発するプロジェクトは、アジャイルのスピード感についていけず、確実に停滞する。

3. 最初の数スプリントは「捨てる」覚悟で

チームがアジャイルのやり方に慣れ、ベロシティ（開発速度）が安定するまでには、最低でも3〜4スプリントはかかる。最初のうちは見積もりも外れるし、予定通りに進まない。これを「失敗」と捉えず、「チームの現在地を測るための投資」として許容できるかどうかが問われる。

手法ではなく、対話の質を変える

アジャイルは銀の弾丸ではない。むしろ、関係者間のコミュニケーションコストはウォーターフォールよりも跳ね上がる。手法の導入にこだわる前に、「発注側と開発側が、ひとつのチームとして対話できる関係性を作れるか」を自問してみてほしい。それができないなら、従来通りのウォーターフォールで進めたほうが、お互いにとって幸せな結果になる。