アジャイルを選んだのに、なぜ半年先の仕様を約束しているのか

二週間ごとに開発成果を見せる。しかし顧客は、その場で優先順位を変えられない。予算も納期も機能一覧も半年前に確定しており、変更には別の承認が要る。例えばこのような現場で、打ち合わせを増やしても、学んだことを次の作業へ反映する余地は小さい。

アジャイルとウォーターフォールの比較で見落とされやすいのは、方式の名前より先に、約束の仕方が進め方を決めていることだ。短い周期で作ることと、短い周期で選び直せることは同じではない。

本稿が提案する選び方は、利用者から学んだ結果を次の作業へ反映できる範囲では反復型を使い、変更が大きな波及を持つ境界では先に合意を固めるというものだ。案件全体へ一つの方式を貼るより、何を固定し、どこを学習に開くかを決める。これは研究から組み立てた実務案であり、特定方式による成功の保証ではない。

「成果がよい」の中身を分けて研究を読む

Gemino、Reich、Serradorの2021年の論文は、国際的な477案件を対象に、伝統的手法、アジャイル、両者の混合型を比較している。要旨では、混合型とアジャイルは関係者にとっての成功で伝統型を上回る一方、予算・時間・範囲・品質の成果は同程度と報告している。Agile, Traditional, and Hybrid Approaches to Project Success

この結果は「アジャイルなら必ず安く、早くなる」という読み方を支えない。回帰分析による国際・業種横断の比較であり、同じ案件を無作為に方式へ割り当てた実験でもない。方式を選んだ企業の能力や案件の性質が、結果と関係している可能性が残る。

それでも、混合型を未完成なアジャイルと決め付ける必要がないという材料にはなる。重要なのは、何を得たいかである。納期の予測可能性を高めたいのか、利用者に必要な機能を見つけたいのか、作った後の修正を減らしたいのか。成功の意味を決めなければ、比較する数字も選べない。

この論文だけから、業界別の最適な反復期間や方式の勝率までは分からない。本稿では公開要旨で確認できる比較結果を用い、具体的な運用の境界は、以下の条件から考える。

利用者へ見せても、何も変えられなければ学習にならない

英国政府のサービス開発ガイドは、利用者の必要を調べ、小さく作って試し、フィードバックを基に改善する進め方を説明する。公共サービスの実務指針であり、日本の受託開発契約へ直接適用される規則ではない。GOV.UK「Agile and government services」

この考え方を使うには、レビューの参加者だけでなく、レビュー後に決められる人が必要だ。操作が分かりにくいと判明しても、仕様変更を誰も承認できないなら、開発チームは不満を集めるだけになる。

着手前に確認したいのは三点である。利用者に実際の作業を試してもらえるか。その結果を判断できる責任者がいるか。判断によって次に作るものを変えられるか。三つ目には、予算と納期の中で機能を入れ替える権限や、発注側と受注側の合意方法も含まれる。

例えば、期限と予算を固定しても、優先度の低い機能を外し、重要な修正へ時間を回せるなら、学習の余地は残る。逆に全部を固定したまま、現場だけに柔軟性を求めると、調整は追加労働や未処理の変更要求として現れ得る。

変更しやすい画面と、変更しにくい取引の境界

反復型に向くかを「要件が曖昧か」でだけ分けるのは足りない。曖昧でも、毎回の変更が多数の他システムを巻き込むなら、学習一回の費用は大きい。

本稿の判断案では、利用者の操作、情報の持ち方、外部への約束を分ける。操作の試作は何度か変えやすくても、取引番号の意味や決済の確定時点は、後から変えると連携先や既存データに影響する。後者を先に検証することは、すべての画面を事前確定することとは違う。

この表は実証済みの診断尺度ではない。工程を選ぶ際の、見落としやすい条件を整理したものだ。計画を作ることと、計画を一切変えないことも分けたい。反復型でも、予算、依存関係、利用者に確認する時点は計画する必要がある。

発注側にも、選び直す時間を確保する

開発側が二週間で変更できても、発注側の判断が月一回なら、反復の速さはそのまま意思決定の速さにならない。レビューで誰が何を決め、判断を待つ間はどの作業を進めるかを、双方で合意しておきたい。判断する人の参加時間も、開発に必要な資源の一部である。

納期や予算を守る責任を曖昧にする必要はない。変更を受け入れる際に、代わりに何を後へ送るか、追加費用を誰が判断するかを示す。反復型を導入しても、変更の費用が消えるわけではない。ここを隠して方式だけを切り替えると、後から費用と期待の食い違いが表面化する。

同じ申請システムでも、選ぶ方式が変わる

仮に、社内の経費申請画面を作る案件を考える。経理へ渡す項目と計算ルールは定まり、利用者が迷わず入力できるかが不明だとする。毎週、実際の申請者に試してもらい、入力順や説明を変更できるなら、画面を小さく作って反復する意味がある。

ところが、会計側の連携形式まで未決で、月末処理に一度しか接続試験の機会がないとする。画面の反復だけを速めても、重要な不確実性は減らない。この場合は、先に連携の検証時点と受け渡し条件を確保し、そこへ至る作業を計画する方を優先する。

さらに、外部との接続を模擬環境で繰り返し確かめられるようになれば、固定していた範囲を小さくできる。方式を変える根拠は、アジャイルを理解する人が増えたことだけではなく、検証と変更の費用が変わったことにある。

導入初期に計画駆動で始め、安定した境界の内側を反復へ移すこともできる。反対に、反復中に安全上重要な条件が見つかれば、その範囲の実装を止め、先に検証する判断が必要になる。

混合型を、二重管理にしない

組み合わせるだけでうまくいくわけではない。機能一覧と作業一覧を別々の責任者が変更し、週次報告と反復レビューで異なる優先順位を指示すれば、チームは二つの計画に従うことになる。

組み合わせる場合は、固定する約束と変更できる範囲を一つの判断表にまとめたい。外部接続の日付は固定、利用者向けの機能順は変更可能、ただし接続項目へ影響する変更は責任者が判断する、といった区別である。

レビューで見つかった問題には、次の反復で直す、後へ送る、採用しないという結論を付ける。未決のまま積み上がるなら、作業の速さより判断能力が制約になっている。会議を追加する前に、誰のどんな決定が欠けているかを確かめる。

試行の評価では、反復を何回回したかではなく、試して見つかった問題をどれだけ反映できたか、重要な条件をいつ発見したかを見る。納期と費用に加え、利用者が必要な作業を完了できるかも追う。比較対象の案件規模や難易度が違えば、方式だけの効果にはできない。

アジャイルを選ぶ理由は、短い会議や新しい肩書を導入するためではない。学習の結果で仕事を変えられるからである。変えられる範囲を先に明示し、その内側を反復する。変更の影響が大きい境界は、検証と合意を先行させる。 この約束ができれば、方式の名前を巡る議論を、実際に機能する進め方の選択へ変えられる。