納期直前の仕様変更にどう対応する？ 範囲・費用・日程の選び方
公開日まで二週間。顧客から「検索条件を一つ追加してほしい」と言われる。画面の項目だけ見れば短い作業に見える。だが既に決めたデータの取り方、権限、試験、利用者への説明を変えるなら、終盤の小変更は小さくない。担当者が好意で引き受け、日程も費用もそのままと答えれば、後で守れない約束になる。
この記事の目次
小さな要望が、残りの仕事を変える
選択は追加要求を拒絶するか、無条件で受けるかではない。目的を守るために今入れるなら、何を延期し、日程や費用をどう変えるかを合わせて決める。重要な欠陥の修正と、便利だが後日でもよい新機能を分ける。要求者の肩書きや声の大きさだけで順番を決めない。
変更の影響は実装時間より広い
NASAのシステムエンジニアリングハンドブックは、要件変更が費用・日程だけでなく、構造、インターフェース、運用、検証、安全へ波及することを示し、適切な審査と承認を勧める。米国の大規模・安全性を重視する開発の指針で、一般的な民間サイトの変更には同じ審査会の大きさは要らない。しかし「追加した機能を作る時間だけが費用ではない」という論点は移せる。
着手前に三つをつなげる。誰が利用する要求か。既存の仕様・データ・外部接続と何が変わるか。何を試し直さなければ失敗を見逃すか。影響が局所で試験できる変更と、他の設計まで見直す変更は別である。後者を「画面一つ」と呼ぶと、影響分析を省いたまま進む。
GAOのスケジュール評価指針は、信頼できる統合日程が変更の影響を読む助けになり、基準計画を維持する重要性を述べる。基準は計画を凍らせるためではなく、何を変更したために、いつの約束が動いたかを見えるようにするためにある。初期計画が不正確なら、比較の起点も弱い。無理な日程を守るために新しい要望だけを責めるのではなく、既存の見積りと残作業も更新する。
「このまま」の意味を三つに分ける
顧客が「納期はこのまま」と言うとき、完成する機能の範囲まで据え置くつもりか、費用も変えないつもりか、単に重要な日付を動かせないのかが違う。動かせない日付なら、追加する機能と後回しにする機能を交換できる。範囲も変えられず安全な試験も省けないなら、追加の人員や別の供給方法を検討する。ただし増員にも引継ぎと調整が必要で、終盤の万能策ではない。
要求を取り下げる案も残す。依頼者が新しい利用場面を説明できず、既存の機能で目的を達せられるなら、設計変更より使い方の改善がよい可能性がある。逆に目的が法令対応や重大な欠陥の回避であれば、単に「次期に回す」とは言いにくい。必要性を確認し、延期したときの影響と、入れたときの影響を同じ表で比べる。
仮想例の二つの追加要求
以下は仮想例であり実際のプロジェクト調査ではない。請求システムの公開直前に、色や表示順の変更が求められた。利用者の仕事を止めず、公開後にも直せるなら、既定の期日を守り次の更新へ回す案がある。後回しの理由と予定を明示し、無視されたと感じさせない。
条件を変える。請求先の識別を誤ると別の顧客へ書類が送られる欠陥が見つかった。公開後に直すより、範囲を縮めてでも識別の修正と再試験を優先する。この場合は表示改善を延期し、公開日の再確認も含めて意思決定する。要求は同じ「追加」でも、欠陥の損失と後から戻せるかで答えが逆になる。
変更しない場合の危険も同じ表へ
変更管理という言葉は、追加を拒むための手続きに見られがちだ。しかし要件が欠けていたと分かったのに基準計画へ固執すれば、予定どおりに使えないものを完成させる。追加する費用だけでなく、追加しない場合の損失を比べる。顧客の仕事が止まるのか、後の更新で十分なのか、代替の運用でつなげるのかを依頼者と確認する。
また、変更の重さはコードの行数と一致しない。外部の帳票の一文が変わるだけでも契約や利用者教育に影響する。内部の大きな改修でも、外から見える振る舞いを変えず、検証できる範囲が明確なら影響は抑えられる。作業量の見積りと、失敗時の被害の見積りを分ける。NASAの大規模開発の審査形式をそのまま小規模案件へ持ち込むのではなく、依存と責任を読む考え方を使う。
残作業を更新しない約束は守れない
依頼を受けると決めたら、実装担当だけに伝えてはならない。試験の担当者が旧仕様で合格を出し、操作説明が古いまま公開されれば、変更の承認は形式だけになる。変更が影響した設計、試験、運用、顧客への説明を同じ版で更新し、誰がいつ確認するかを予定へ組み込む。計画の差分が見えれば、後で起きた遅延を新しい依頼へすべて押し付けることも避けられる。
逆に、承認を細かくしすぎて小さな文言修正まで長い会議で待たせれば、修正の機会を失う。影響が局所で戻せる変更は、事前に決めた権限の中で軽い確認にする。重要な外部接続や安全性、期限へ波及する変更は複数の担当者で見る。変更の種類で経路を分けるのであって、すべてを重くすることが統制ではない。
残作業を戻した計画で、追加・交換・延期を比較してみます。期限まで10日、残作業8日、追加機能3日、接続の再検証2日という一人作業の仮定なら、追加は13日で期限を越えます。既存機能を3日分外す案は再検証を含めて10日、追加を次回へ送る案は今回は8日です。ただし、延期で今回使えなくなる機能の影響は、この日数とは別に残ります。
比較の単位は追加機能の3日だけではない。外せる作業がまだ未着手か、外すことで接続試験が減るか増えるかまで計画へ戻す。NASAの変更管理とGAOの工程指針を使う理由は、この依存を計画へ反映するためであり、見積もった日数の正確さを保証するためではない。
完成後に約束を検証する
公開後は、承認時に見込んだ便益、追加した試験・教育の費用、外した機能の影響を対応させて確認する。変更理由が初期の聞き漏らしか、後から生じた条件かを分け、次の企画へ戻す。
断る場合も代替案と次に採る条件を示す。ただし法令上の必要事項や安全を欠く変更は、単に次版へ送らず、既存範囲・納期・費用の見直しとして決定者へ渡す。初期の確認方法は要件の合意、試し方は試作品の記事で扱う。
承認する人にも選択肢を渡す
変更の判断に必要なのは、依頼書の枚数ではない。追加の目的、採らない場合の損失、影響する作業と試験、納期・範囲・費用の組合せを短く並べる。承認者は「今入れる代わりに何を外すか」「いつなら検証が終わるか」を選ぶ。決定したら開発・利用者・運用の関係者へ同じ版の内容を伝え、古い仕様で試験や説明を続けない。
変更を認めるのは計画管理の失敗ではない。情報が増えた結果、計画を修正するのは合理的だ。ただし「今の全部に新しい全部を足す」という約束は、影響を測らない限り成り立たない。目的と試験の範囲を示し、何を交換するかを決めてから受ける。追加要求を断るときも、どの条件なら次回採るかを明確にする。