「納期は守って、変更には柔軟に」が炎上を招く

私が関わってきた案件でも、納期が最優先とされ、何を作るのかを顧客と合意しきれないまま開発に入らざるを得ず、スプリントレビューや受入テスト（UAT）で変更要求が数多く出たことがありました。1つの案件だけではありません。ウォーターフォールとアジャイルの「いいとこ取り」で進めたいハイブリッド開発の案件では、どれだけ経験のあるPMがいても普通に起こる、進め方の構造の問題です。この記事では、なぜ炎上しやすいのか、どこで区切れば防げるのかを整理します。

ハイブリッド開発は、両取りの期待から始まる

ハイブリッド開発とは、要件定義などの上流はウォーターフォールで、開発はアジャイルで進めるといったように、2つのやり方を組み合わせる進め方です。この進め方の案件では、顧客と開発側の双方に、次のような期待が同時にあることがよくあります。

• 納期と予算は、最初に決めたとおりに守ってほしい（ウォーターフォールの期待）
• 途中で気づいたことは、柔軟に取り入れてほしい（アジャイルの期待）
• ドキュメントは必要最低限でよい（コストを抑えたいという期待）

最後の一つは、顧客と開発側の双方にある期待です。顧客はコストを抑えたい。開発側にとっても、ドキュメントをいくら作っても、それだけで顧客に届けられる価値は多くありません。

けれども、納期・予算・範囲のすべてを固定したまま、変更だけを柔軟に受けることはできません。本来のアジャイルは、期間と体制を固定する代わりに、作る範囲を動かして調整します。ハイブリッド型では、この「何を動かして調整するのか」が決まらないまま、両方のよいところだけが期待されがちです。

そして、顧客の予算は決まっています。両取りの結果あふれた分は、請負なら開発側の赤字に、準委任なら顧客の信頼の低下になって返ってきます。

ハイブリッド開発の現実的な進め方：要件定義までをゲートで区切る

私が現実的だと考えているのは、次のような形です。

1. 要件定義（必要なら大枠の設計まで）：ゲートを設けて、ウォーターフォールのように進める。ゲートで範囲を確定させる
2. 開発と単体テスト：スプリントに分けて、アジャイル的に作って見せながら進める
3. 結合・総合・受入テスト：当初の計画どおりに進める

なぜ要件定義まではゲートで区切るのか。理由は予算です。

多くの会社では、そのプロジェクトに今年度いくら使えるかが、前の年度の段階で決まっています。決まった予算の中で進める以上、「作りながら考える」をプロジェクトの最初から始めると、予算をかなり使ったタイミングで「まだ何もできていません」という状態が生まれかねません。予算の枠がある案件ほど、最初に範囲を決めておく必要があるのです。

要件定義のゲートで確かめる3つのこと

1. その要件は、予算に収まるか

要件定義を進めながら、早い段階で「いま出てきている要件は、この予算に収まりそうか」を大まかに判断しておきます。要件定義が終わってから「予算に収まりません」と分かっても、打てる手は限られます。

よく言われるのが、「既存システムの置き換えなのだから、簡単に見積もれるでしょう」という話です。確かに、ざっくり見積もることはできます。ただ、要件定義を進めると、「やっぱりあれも」「やっぱりこれも」と要件は増えていくものです。今のシステムで当たり前にできていることが洗い出され、この機会に直したいことが加わります。

そこで、見積もりは2段階で出します。要件定義の前に出すのは、あくまで幅のある概算です。要件定義をしっかり行った後に、「御社の要件だと、全体でこのくらいです」と、バッファーも含めた見積もりを出します。見積もりの前提を受注前にどう確かめるかは、コラム#02でも触れています。この2段階を顧客と合意しておけるかどうかは、実は受注の時点で決まります（後で触れます）。

2. その要件は、その期間で実現できるか

予算と並んで大きいのが、期間です。これだけの要件を、このスケジュールで本当に実現できるのか。顧客の事情で「やらなければならない」こともあるでしょう。

だからこそ、実現が難しいと分かったときにどうするかを、早い段階から考えておきます。たとえば、外部のパートナーを加えて体制を強化する。範囲を分けて、段階的にリリースする。体制の強化は、必要になってから探しても、すぐには人を集められません。要件定義の段階で見通しを立てておけば、手を打つ時間が残ります。

3. 要件の範囲は、確定しているか

要件定義のゲートでは、要件を確定（ファイナライズ）させます。「これは要件に入っている」「これは入っていない」を、顧客と一覧で合意します。これがないまま開発に入ると、後から「やると思っていました」「やらないと思っていました」で揉めることになります。何を作るかの合意と、承認する人の決め方は、コラム#03で詳しく書いています。

入っている要件に、顧客が優先度まで付けてくれれば理想的です。ただ、これは顧客の特性次第です。要件定義をしている間、顧客は全部が欲しいものです。顧客にも他の仕事があり、予算が本当に足りなくなるまでは、優先度を付ける必要を感じていません。そこに時間をかけても、なかなか進みません。だから、どの要件なら後ろに回せそうかは、PMが自分の中で見立てておきます。

確定した要件は、その後のベースライン（合意した時点の状態）になります。開発に入ってからの要望は、このベースラインからの差分、つまり「変更」として扱います。変更が出たら、何が変わり、予算と納期にどう響くのかを確かめ、顧客の決める立場の人に承認してもらってから、ベースラインを更新します。冒頭の場面で「直すのか、追加で相談するのか」の議論から始まってしまうのは、このベースラインがないからです。

「ドキュメントは必要最低限」の落とし穴

ハイブリッド型では、「ドキュメントは必要最低限で」という方針もよく取られます。顧客はコストを抑えたい。開発側も、価値を生まない資料づくりに時間を使いたくない。どちらも、もっともな考え方です。

ところが、ここで削られがちなのは、設計書の細かさだけではありません。何を合意したのかの記録まで、一緒に消えてしまいます。スプリントレビューの「いいですね」が何を承認したことになるのか、後から変えると全体が崩れる前提はどこで決まったのか。これが残っていなければ、変更かどうかの判断も、影響の見積もりもできません。

もう一つ、見落とされがちな影響があります。保守・運用に引き継げないことです。

保守・運用は、別のチームや別の会社が担うこともよくあります。顧客がいずれ内製し、自走したいと考えていることもあります。なぜこの仕様なのかが分からないまま引き継げば、調べ直しが続き、「この会社は何を残していったのか」と思われかねません。すべては書き残せなくても、引き継ぐ相手が困らない準備はしておきたいところです。

これは開発側にとっての機会でもあります。引き継げる資料があれば、価値を出しにくい保守・運用を早めに移し、自分たちの人と時間を、顧客のビジネスの価値を上げる次の仕事に振り向ける提案ができます。

「必要最低限」にすべきなのは、ドキュメントの量です。合意の記録まで最低限にしてよいわけではありません。

開発をスプリントで進めるのは、大きな変更に早く気づくため

要件を確定させても、変更要求はなくなりません。

要件定義や設計は、文書で合意します。けれども、動かないものを文書で見ながら合意した内容は、どうしても認識のずれが起きやすくなります。開発側は定義したとおりに作った。それでも、できあがったものを顧客が触ってみると、「これでは業務で使えない」と判断され、変更要求（CR）が出されます。

軽微な変更要求なら、大きな問題にはなりません。問題は、業務上重要で、しかも取り込むのに大きな労力がかかる変更要求です。予算の枠が決まっている以上、これを受け止めるなら、その分の時間を何かで空けなければなりません。「この変更を入れるなら、代わりに何を落としますか」というトレードオフを、顧客に判断してもらう必要があります。

この判断は、早ければ早いほど選択肢があります。すべてを作り切った後では、もう落とせるものは残っていません。残るのは、予算の追加か、納期の延長か、開発側が赤字で抱えるかです。だから開発は、スプリントで作りながら見せます。大きな変更要求に、できるだけ早く出会うためです。

あわせて、スプリントレビューだけに頼らないことも大切です。スプリントレビューは、その回に作った部分を確かめる場で、全体を通した業務の流れを確かめる場にはなりにくいからです。主要な業務がひととおりつながったときなど節目を決め、業務部門の責任者など全体を判断できる人に見てもらいます。冒頭の「これでは、現場の業務が回りません」を1か月目に聞けていれば、落とせるものはまだ多く残っていたはずです。

落とす順番は、PMが自分の中に持っておく

では、何から落とすのか。アジャイルには、「トレードオフ・スライダー」という考え方があります。品質・コスト・納期・範囲などを並べ、何かを調整しなければならなくなったとき、どれから動かすのかの順番を決めておくものです。

ただ、このスライダーを顧客の前に出して「どれから動かしますか」と決めてもらおうとしても、まずうまくいきません。顧客にとっては全部が大事なので、「どれも動かさないでください」という話にしかならず、かえって揉めるだけです。特に日本の案件では、納期が厳しいことが多くあります。

だからスライダーは、PMが自分の中に持っておくものです。予算、要件の量、期間、そしてプロジェクトの状況から、「この案件で、いざというときに調整するのはどこか」を頭の中で決めておきます。どの要件なら後ろに回せそうかという見立ても、その手がかりになります。

そのうえで、いざというときにその順番で判断してもらえるよう、顧客とのコミュニケーションを重ねていきます。顧客の考えは、急には変わりません。状況を共有しながら、「この状況で納期を優先するなら、範囲はこうなりますよね」という話を、早いうちから少しずつしておきます。いざ何かを動かさなければならなくなってから初めて切り出しても、受け入れてもらうのは難しいからです。

実は、受注の時点で決まっている

ここまでの話は、プロジェクトが始まってからの進め方に見えるかもしれません。けれども、その多くは、受注の時点で決まっています。

• 要件定義を開発とは別の契約にして、その結果をもとに開発を見積もる（多段階契約）のか。それとも、要件が決まる前の概算で、開発まで一括で約束してしまうのか
• 概算を出すときに、「要件定義の後に見積もりを出し直す」ことを顧客と合意しているか
• このスケジュールで足りなくなったときに、体制を強化できる見通しがあるか

受注の後に、これらを変えるのは難しくなります。最初の概算が、いつの間にか約束として扱われ、そこからあふれた分を開発側が抱える。ハイブリッド型の炎上の多くは、ここから始まります。

案件の状態を確かめる5つの問い

受注を控えた案件、ハイブリッド開発で進めている案件があれば、PMに次のことを聞いてみてください。すぐに答えが返ってこなければ、注意が必要です。

1つでも答えに詰まったら、受注前リスクチェック30（無料・約5分・登録不要）で、案件全体を確かめてみてください。

外から見ると、すぐに気づける

顧客に全部を決めてもらおうとせず、PMが見立てを持ち、早めに少しずつ話していく。ハイブリッド開発を炎上させないPMの仕事は、ここに尽きると私は考えています。

ただ、それを案件の中にいながら続けるのは簡単ではありません。概算が、いつの間にか約束になっている。要件の範囲があいまいなまま開発に入っている。変更が変更として扱われていない。こうしたことは、毎週のスプリントを回しているPMほど気づきにくく、気づいても言い出しにくいものです。目の前の進捗は出ていて、顧客の担当者も「いいですね」と言っているからです。

一方で、案件の外にいる人が見積もりの前提と計画を見ると、何が決まっていて何が決まっていないのかは、意外なほどすぐに分かります。そして、手を打ちやすいのは、受注の前です。

Valmoについて　大型案件の受注前とキックオフ直後に、提案や計画を外から審査し、不採算案件を防ぐ支援をしています。大手SIerのような審査部門を持たない会社の、「外付けの審査室」です。

関連：「こんな仕事は頼んでいない」と言われる前に ・ 大型案件レビュー ・ プロジェクトアシュアランス（案件審査）とは

コラム一覧へ