CASE 03 ／契約と合意

「依頼があってから対応」という、契約の穴

その障害の原因は、コードでも設計でもなく、契約書の一文でした。誰も悪くないのに、誰かが困る。そういう故障の話。

状況

あなたは、外部サービスとの連携を含むシステムの保守を担当するディレクターです。ある朝、クライアントから連絡が入ります。

「管理画面から、いつもの登録作業ができなくなっています」

調査の結果、連携先の外部サービスがAPIのバージョンを更新し、一部の項目が廃止されていたことが原因と判明。対応期限は、既に過ぎていました。

なぜ誰も対応しなかったのか。契約書には、こう書かれていました——「対応契機は、クライアントからの依頼があってから」。

従来は、外部サービス → クライアント → 担当チーム、という経路で更新通知が流れ、依頼が発生していました。しかし今回は、外部サービスからの通知そのものが直前までなく、依頼は発生しなかった。つまり、誰もボールを持っていなかったのです。

あなたなら、どうする？

障害は現在進行中です。最初の1時間で、何をしますか。　—　選ぶと、その選択の「ありがちな帰結」が開きます。正解当てではありません。全部読み比べてください。

— 残り 3 件の帰結が未読です —

優先度の高いAPIの修正が完了し、業務は復旧しました。次は、クライアントへの原因報告です。

ここで新しい壁が現れます。担当チームから上がってきた調査報告が、技術的には正確なものの、そのままではクライアントに伝わる内容になっていないのです。専門用語の羅列、時系列の欠落、「結局なぜ起きて、次はどう防ぐのか」への回答不在。報告の解読と再構成に、想定外の時間が溶けていきます。

あなたなら、どうする？

その調査報告を、どう扱いますか。　—　選ぶと、その選択の「ありがちな帰結」が開きます。正解当てではありません。全部読み比べてください。

— 残り 3 件の帰結が未読です —

復旧と報告を終えた後、本質的な再発防止として行われたのは、コードの修正ではなく契約と体制の修正でした。

外部サービスの更新通知を誰が監視し、誰が検知の責任を持つのかを再定義。「依頼があってから対応」という受け身の構造に、「更新の検知」という能動的な役割を追加したのです。

外部依存のあるシステムでは、依存先は当然に変化します。変化を検知する仕事は、契約書に書かれない限り、この世に存在しない仕事になる——これが、この障害の本当の教訓でした。

同じ穴が自分の案件にもないか、16項目で点検できます（登録不要・約3分）。

NEXT STEP

株式会社Enlyt（エンライト）は、10年かけて言語化した“観点”を、現役の実践者が御社の会議に入って移植します。 AIは、その観点を毎週回し続けるエンジン。6ヶ月で、御社だけで回る状態にして抜けます。

無料の健康診断を申し込む →診断を受けても、契約の義務は一切ありません。

本サイトのケーススタディは、プロジェクトの現場で起こりがちな状況を再構成したものです。特定の企業・団体・案件を指すものではありません。