CASE 01 ／ 品質と納品
検収の1週間前、すべてが崩れた
不具合の報告は、いつも一番聞きたくないタイミングでやってくる。公開直前に始まった崩壊と、そこからの生還の記録。
状況
あなたは、ある事業会社の顧客向けWebサービス構築プロジェクトのPMです。要件の確定から数ヶ月、公開予定日まであと1週間。クライアントによる最終の検収が進んでいます。
金曜の夕方、クライアントから連絡が入ります。「複数の条件が組み合わさったとき、処理が正しく行われないケースがあります。ほかにも気になる点をリストにしました」——開いたリストには、不具合と思われるものと、仕様変更の要望と思われるものが混在して、ずらりと並んでいました。
テストで発見されたのは、テストケースの網羅から漏れていたパターンでした。公開日には、もう間に合いません。
あなたなら、どうする？
最初の返信で、何を伝えますか。 — 選ぶと、その選択の「ありがちな帰結」が開きます。正解当てではありません。全部読み比べてください。
— 残り 4 件の帰結が未読です —
状況・続き
このケースでは、公開は二度延期されました。個別の修正では収まらず、「現状のサービスは期待値を満たしていない」という根本の不信に向き合うことになります。
複数回の顧客MTGを重ね、残タスクの一覧を全件再構成し、新しい公開日で再合意。以後の追加要求は対象外とする線引きも、このとき同時に文書化しました。
——しかし、話はここで終わりません。数週間後、クライアントからこう告げられます。「納得のいく進捗が得られなければ、この日をもってプロジェクトの終了もありえます」。継続可否の判断日が、設定されたのです。
あなたなら、どうする？
判断日まで、数週間。何に賭けますか。 — 選ぶと、その選択の「ありがちな帰結」が開きます。正解当てではありません。全部読み比べてください。
— 残り 4 件の帰結が未読です —
実際の顛末
チームはWBSと日次定例で進捗を完全に可視化し、判断日の時点で予定タスクをすべて完了させました。結果、プロジェクトは継続の判断を獲得。その後も遅延が発生した際は「いつ、どうやって巻き返すか」を先回りで提示し続け、サービスは無事に公開されました。
振り返って効いたのは、大きな挽回策ではなく、小さな約束を10連続で守ったことでした。
このケースの教訓
- 信頼が毀損した瞬間から、正論の効力は停止する。切り分けは関係の回復後に。
- 立て直しの再合意は「文書化された全量のタスク一覧 ＋ 新しい期日 ＋ 以後の線引き」の3点セット。
- 判断日を突きつけられたら、賭けるべきは速度ではなく透明性。
持ち帰りチェックリスト
- テスト観点の網羅は、第三者のレビューを通したか
- 納品基準（何をもって完成とするか）は、着手前に文書で合意したか
- クライアントが進捗を「見に行ける」場所はあるか
同じ穴が自分の案件にもないか、16項目で点検できます（登録不要・約3分）。
案件の健康診断を受ける →NEXT STEP
こうした事故は、担当者の能力ではなく「孤立」から起きます。
株式会社Enlyt（エンライト） は、10年かけて言語化した“観点”を、現役の実践者が御社の会議に入って移植します。 AIは、その観点を毎週回し続けるエンジン。6ヶ月で、御社だけで回る状態にして抜けます。
無料の健康診断を申し込む →診断を受けても、契約の義務は一切ありません。本サイトのケーススタディは、プロジェクトの現場で起こりがちな状況を再構成したものです。特定の企業・団体・案件を指すものではありません。