クライアントからの突然の仕様変更を受けたときの「巻き戻し判断」と工数再積算｜現場で使える実践テクニック

#クライアント対応 #トラブル対応 #プロジェクト管理 #仕様変更管理 #工数再積算
C
クリオ
Web制作ディレクター / フロントエンジニア

こんにちは！

今日は「クライアントからの突然の仕様変更を受けたときの『巻き戻し判断』と工数再積算」についてお話しします。

仕様変更が発生したときに僕が失敗した話

Web制作の現場で最も焦る瞬間は何か、知ってますか？
それはプロジェクトが進行中の状態で、クライアントから「あ、ちょっと仕様変わっちゃったんですけど…」って連絡が来たときなんです。
僕も5年目くらいのころ、ほんまに痛い目を見ました。

当時のプロジェクトは、ECサイトのリニューアルで納期が2週間後に迫ってました。
フロントエンドの実装は80%くらい進んでて、デザイナーも修正対応に入ってたんです。
そこでクライアントから「商品一覧ページのフィルタ機能、複数選択に対応させたい」という連絡が。

僕はね、その時「あ、大丈夫っすよ。ちょい修正で対応できますから」って安易に返事しちゃったんです。
実装を見てみたら、フィルタ機能は単一選択前提で設計されてて、JavaScriptの状態管理からAPIの仕様まで全部変わる必要があったんです。
結局3日間かけて対応したし、デザイナーも修正に追われました。

その時、僕が気づいたのは「仕様変更が来たとき、何でもかんでも『対応します』って言うのは危険や」ってことなんです。

「巻き戻し判断」って何か、どう判断するのか

仕様変更の連絡を受けたとき、ディレクターがまず判断すべきことは「この変更、実装したものを部分的に直すだけで済むのか、それとも設計から巻き戻す必要があるのか」ということなんです。

「巻き戻し判断」というのは、僕が現場で作った造語なんですけど、要は「この変更を受けると、既に完了した仕事のどこまでやり直す必要があるか」を見極めることなんです。

巻き戻しの3つのレベル

  • レベル1（軽い） ： CSSやテキストの修正だけで済む。既存の構造に影響なし
  • レベル2（中程度） ： HTMLの構造を部分的に変更する必要がある。JavaScriptの小修正も必要
  • レベル3（重い） ： システム設計から見直す必要がある。データベース設計やAPI仕様も変わる可能性がある

まず僕は仕様変更の内容を受け取ったら、技術スタッフと一緒に30分かけてこのレベルを判定するようにしてます。

例えば、さっきのECサイトの例だと、これは明らかにレベル3だったんです。
でもそのときの僕は「フィルタの選択方式を変えるだけだから軽い」って勘違いしちゃったんですよ。

巻き戻し判断のチェックリスト

実装を見る前に、以下の質問を自分たちに投げかけるといいですよ。

  • この変更は、既に出力したHTML構造に影響するか？
  • JavaScriptの状態管理ロジックを変更する必要があるか？
  • APIのレスポンス形式や仕様が変わるか？
  • デザイン（CSSのみ）の変更で済むのか、それともマークアップが必要か？
  • テスト項目が追加や変更されるか？

ここで「構造が変わる」「APIが変わる」という答えが出たら、それはほぼレベル2以上です。
正直に「この変更には工数がかかります」と伝える必要があります。

影響範囲を整理して工数を正確に再積算する方法

巻き戻しのレベルが判定できたら、次は「具体的にどのくらい時間がかかるのか」を計算する必要があります。
ここで失敗すると、納期に遅れたり、チームのモチベーションが下がっちゃいます。

ステップ1：影響を受ける領域をマップ化する

まずはプロジェクト全体の中で「どこが変わるか」を可視化します。
僕は簡単なスプレッドシートを使って、こんな感じでリストアップしてますよ。

  • フロントエンド実装 ： HTMLマークアップ / CSSスタイル / JavaScriptロジック / 既存テスト修正
  • バックエンド実装 ： APIエンドポイント修正 / データベース調整 / 既存機能との相互作用確認
  • デザイン ： ワイヤーフレーム修正 / デザインカンプ修正 / デザインシステム更新
  • QA ： テスト計画修正 / 新規テストケース作成 / リグレッションテスト

これを見ると、仕様変更の”本当の影響”が見えてくるんです。
「あ、フロントだけじゃなくてバックも変わるんだ」とか「デザインもやり直しが必要か」とか。

ステップ2：各領域で「新規」「修正」「削除」を分ける

影響範囲が見えたら、それぞれを細かく分類します。
例えば、フロントエンドなら：

  • 新規 ： 新しく実装する部分は？
  • 修正 ： 既存実装のどこを直す？
  • 削除 ： いらなくなったコードやHTMLはある？

この分類が重要なのは、工数の計算方法が違うからです。
修正は「新規実装の50〜70%の工数」くらいで考えるといいですよ。
ゼロから作るより楽ですけど、既存コードの確認や回帰テストの手間があるからです。

ステップ3：最初の見積の「3倍」で計算する（リスク考慮）

これはね、僕が本当に何度も失敗して学んだ教訓なんです。
仕様変更時の工数は、最初に見積もった時間の「3倍」で計算するといいですよ。
理由は、見えない問題が必ず出てくるからです。

  • 既存のコード品質が低くて、修正に時間がかかる
  • 影響範囲を見落としてて、後から追加の修正が発生する
  • テスト工程で想定