「いつものウォーターフォール」で受け入れが荒れた ― 開発アプローチとライフサイクルは案件で選ぶ

深く考えず「今回もウォーターフォールで」と決めた案件。ところが画面まわりの要望が最後まで揺れる性質のもので、受け入れテストの段階になって「思っていた操作感と違う」が一気に噴き出した——アプローチの選択そのものがズレていた、私の実体験です。この記事では、その反省から始めて、PMBOK第7版のパフォーマンスドメイン③「開発アプローチとライフサイクル」を、選び方の目線で整理します。

この記事でわかること

「いつものやり方」を惰性で当てると何が起きるか
開発アプローチ(予測型・適応型・ハイブリッド)とライフサイクルの関係
案件の中でアプローチを「部分ごとに」選ぶという発想

筆者はSIerのPMです。ウォーターフォールも反復型も経験した立場から、PMPの学び直しで整理し直した「作り方の選び方」を書きます。

このドメインが扱うのは、成果物を、どういう進め方(予測型・適応型・ハイブリッド)で、どんな段階を踏んで作るかを、案件の性質に合わせて選ぶ活動です。予測型(いわゆるウォーターフォール)は要件を先に固めて順に進めるやり方、適応型(アジャイル)は短い反復を回しながら少しずつ形にするやり方、ハイブリッドはその二つを混ぜて使うやり方。ライフサイクルは、こうしたアプローチに沿ってプロジェクトが通る「段階のつながり」です。

「いつものウォーターフォール」で受け入れが荒れた
「新しい方が優れている」という思い込み
アプローチの選択は、あとから効いてくる
私が続けている工夫
よく聞かれること
振り返って
関連記事

「いつものウォーターフォール」で受け入れが荒れた

PMを任されて間もない頃、ある業務システムの案件で、私は深く考えず「今回もウォーターフォールで」と決めました。会社として慣れたやり方でしたし、契約も一括請負。要件定義→設計→開発→テストと、順番に進めるのが当然だと思っていたのです。

ところが、この案件は画面まわりの要望が最後まで揺れる性質のものでした。利用部門も「実際に触ってみないと、ほしい形が言葉にできない」という状態。それでも予測型の枠に押し込んで進めたので、受け入れテストの段階になって「思っていた操作感と違う」という指摘が一気に噴き出し、画面系の手戻りがふくらみました。要件が固まらないものを、固める前提のやり方で作っていた——アプローチの選択そのものがズレていたのです。

この反省から、次の案件では一つの案件の中でアプローチを分けるようにしました。仕様が安定している裏側の処理は予測型のまま、要望が揺れる画面まわりだけは、早めに動くプロトタイプを見せて反応をもらう反復型に切り替える。いわゆるハイブリッドです。「触ってから決めたい」部分を先に触ってもらえるようにしただけで、受け入れ段階の「ちゃぶ台返し」がぐっと減りました。案件を丸ごと一色に塗る必要はなかったのだと、このとき実感しました。

「新しい方が優れている」という思い込み

実のところ、私は長いあいだ「アジャイルは新しくて良い、ウォーターフォールは古い」という二項対立で捉えていました。だから「どちらが正解か」を探そうとしていたのです。

でも、優劣の問題ではありませんでした。要件が安定している案件では予測型がきれいに効きますし、探りながら作る案件では適応型が向いています。大事なのは「どちらが偉いか」ではなく「この案件(あるいはこの部分)は、どちらの前提に近いか」を見極めること。しかも、それは案件開始時に一度選んで固定するものでもなく、部分ごとに選び分けてよい。試験勉強をしている方も、「アジャイル=常に正解」という選択肢は疑ってかかるくらいでちょうどいいです。

アプローチの選択は、あとから効いてくる

要件がはっきり決まっている案件に反復型を当てても手間が増えるだけですし、逆に、要件が固まりきらない案件を予測型で押し切ると、最後の最後で「これじゃない」が噴き出します。作り始める前の「どう作るか」の判断が、その後の手戻りの量を静かに決めているのです。

私が続けている工夫

着手前に「この成果物の要件は、どれくらい固まっているか」を一度見立てる
案件を一色に決めず、「安定した部分は予測型・揺れる部分は反復型」と分けて考える
適応型を選ぶときは、短い反復を回せるチーム体制と顧客の関与がセットで要ることを確認する

よく聞かれること

Q. ハイブリッドは、具体的にどう設計すればいい?
まず成果物を「要件が安定している部分」と「探りながら決める部分」に仕分けます。前者は予測型、後者はプロトタイプなどの反復型、と割り当てるのが出発点です。全体の節目(マイルストーン)は共通で管理すると、ばらけません。

Q. 一括請負契約でも適応型は使える?
工夫は要りますが、不可能ではありません。契約上の成果物と検収条件は予測型的に握りつつ、要件が揺れる部分だけプロトタイプで合意形成を先に進める、という組み合わせなら現実的です。契約形態とアプローチは、分けて考えると選択肢が広がります。

振り返って

開発アプローチとライフサイクルのドメインとは、「アジャイルかウォーターフォールか」を選ぶことではなく、案件の性質に合わせて作り方を選び、必要なら部分ごとに混ぜることでした。あなたが今動かしている案件は、要件がどれくらい固まっていますか? 「揺れる部分」だけでも先に触ってもらう形にすると、後半がずいぶん楽になるかもしれません。