暫定対応と恒久対応の切り替え基準｜発注側が確認すべき5つの質問

2026-08-03

「暫定対応で対処しました。現在は復旧しています」

開発会社からこの一文を受け取ったとき、何と返しているでしょうか。多くの場合は「ありがとうございます」で終わります。止まっていたサービスが動いている以上、それ以上聞くことが思いつかないからです。

しかし半年ほど経ったころ、同じ障害の報告を何度も受けていることに気づきます。改修を依頼したら「影響調査に時間がかかります」と言われ、見積もりも以前より上がっている。このとき初めて、あの一文が何を意味していたのかを考えることになります。

この記事は、エンジニアではなく開発を「依頼する側」つまり発注担当者、社内のPM・ディレクターに向けたものです。暫定対応と恒久対応の基本的な違いや放置リスクの全体像は、【2026年版】暫定対応と恒久対応の違いとは？システム障害時に経営者・DX担当者が知っておくべき判断基準 で詳しく整理をしています。

本記事では要点だけ最初に押さえたうえで、その次の段階、報告を受けた側が何を確認し、どう指示を出し、いつ切り替えを判断するかに絞ります。

Enlytでは、障害対応で揉める案件の多くが、障害が起きた瞬間ではなく、依頼の入口で「完了」の条件を決めていなかったことに端を発すると考えています。だからこの記事も、報告を受けた後の確認だけで終わらせず、次の依頼で同じズレを繰り返さないための整え方、受注前・依頼前の上流整理まで含めて扱い、技術の話ではなく進行の設計の話となります。

暫定対応と恒久対応の違い ——「完了」という言葉の二重性が認識齟齬を生む

暫定対応と恒久対応は、言葉の上では並んで語られますが、発注側と開発側で「どこまでやれば完了か」の認識がずれやすい対象です。まずは両者を一言で押さえておきます。

暫定対応とは：影響を止めるための応急処置（症状の停止）

暫定対応は、障害の影響をいったん止めて、サービスを動く状態に戻すための応急処置です。原因そのものは残っている場合があり、同じ障害が再発する余地を残しています。

恒久対応とは：原因を除去し、同じ障害を再発させない状態

恒久対応は、障害の根本原因を取り除き、同じ事象が二度と起きない状態にすることです。多くは別途の原因調査と改修を伴い、暫定対応とは判断する人もタイミングも変わります。

そのうえで、実務で問題になるのは用語の定義そのものより、「完了」という言葉が二つの意味を持ってしまうことです。

「対応しました」「直りました」「対処済みです」これらの言葉は、症状が止まったことと原因が消えたことの両方を指せてしまいます。開発側は前者の意味で使い、発注側は後者の意味で受け取ります。ここに悪意も手抜きもありません。それぞれの持ち場から見れば、どちらの用法も正しいからです。

ITサービス管理の国際的な体系であるITILでは、この2つを別々のプラクティスとして扱います。サービスが再稼働した時点でインシデントは終了しうるが、根本原因が解決されるまで問題は残るという整理です。原因と回避策が記録された問題は「既知のエラー」として管理され、解決されて初めてクローズされます。

つまり「暫定対応で対処しました」は、インシデントが閉じたという報告であって、問題が閉じたという報告ではありません。

最後の行が要点です。暫定対応は開発側の判断で進みますが、恒久対応に進むかどうかを決められるのは、費用と優先順位を握っている発注側だけです。ここを開発会社に委ねると、判断そのものが宙に浮きます。

恒久対応が抜け落ちる現場では、「言ってくれなかったから」と「聞かれなかったから」がほぼ必ず同時に出てきます。技術力ではなく、期待値が揃っていないという進行上の問題です。

恒久対応が後回しになる、よくある現場パターン

「一旦、様子見で」が結論になっていく

障害の直後は関心が高く、恒久対応の話も出ます。ところが数日たって再発しないと、様子見がそのまま結論になります。誰も「やらない」と決めていないのに、実質やらないことが決まっている状態です。

この現場でよく起きているのは、決定事項と検討事項が混ざっていることです。議事録を見返すと「恒久対応も検討」と一行だけ残っている。けれど、それが決めたことなのか、その場で話に出ただけのことなのかが区別されていない。決定と検討が同じ箇条書きに並んでいると、後から読み返した人はたいてい、検討事項を「やらなくてよかったこと」として処理します。判断が下されていないため、次に同じ障害が起きたときも、また同じ会話が最初から始まります。

恒久対応が、見積もりにも計画にも現れない

暫定対応は保守契約の範囲内で処理されることが多く、請求書にも計画表にも項目として出てきません。一方の恒久対応は別途の見積もりが必要になるため、誰かが議題に上げなければ検討自体が始まりません。見えていないから議論されず、議論されないから見えないままという循環に入ります。

復旧手順が特定の担当者の頭の中にしかない

「あの障害はあの人が対応してくれる」という状態は、一見安定して見えます。しかし異動や退職で手順ごと失われ、記録が残っていなければ恒久対応の検討はゼロからの調査になります。経済産業省が2018年9月に公表した「DXレポート」でも、老朽化・複雑化したシステムについて「保守・運用が属人的となり継承が難しい」と答えた事業者が6割以上にのぼることが示されています。

拠点やチームによって報告の粒度が違う

ある拠点は原因の仮説まで書いてくれるのに、別の拠点は「復旧しました」の一行で終わることがあります。発注側は受け取った情報の粒度でしか判断できないため、報告が薄いチームの案件ほどリスクが見えないまま進みます。意識の差ではなく、報告フォーマットが決まっていないという設計の問題です。多拠点・リモートの体制では、違いを尊重するだけでは足りず、どこを標準化し、どこを明文化するかを決めておく必要があります。

発注側の指示の粒度が、暫定対応を固定化させる

見落とされがちですが、発注側の指示の粒度が、そのまま対応の粒度になります。気づかって使った柔らかい表現が、恒久対応を止めていることは珍しくありません。

私たちが案件に入るとき、最初に目を通すのは障害の技術ログよりも、発注側と開発側が交わしてきた言葉のほうです。「とりあえず」「いったん」「お任せします」が続くやりとりほど、半年後に同じ障害が戻ってくる。現場に伴走していると、これは経験的にかなり当たります。柔らかさは相手への配慮ですが、判断の条件が抜け落ちたまま伝わると、その配慮はそのまま先送りに変わります。

右列に共通しているのは、「誰が」「いつまでに」「何をもって」判断するかが入っていることです。期待値コントロールとは、丁寧に伝えることではなく、判断の条件を先に決めておくことを指します。

右列に共通しているのは、「誰が」「いつまでに」「何をもって」判断するかが入っていることです。期待値コントロールとは、丁寧に伝えることではなく、判断の条件を先に決めておくことを指します。

障害報告を受けたら、発注側が確認すべき5つの質問

技術的な詳細がわからなくても、判断材料は集められます。以下の5つは、報告への返信にそのまま貼れる粒度でまとめています。

① 今回の対応は、症状を止めたものか、原因を直したものか

暫定対応と恒久対応のどちらなのかを明確にする質問です。「一旦は大丈夫です」と区分を答えない場合は、まだ切り分けられていないサインです。

② 原因は特定できているか、まだ切り分け中か

恒久対応を検討できる段階かどうかを見ます。「おそらく〜だと思われます」で止まるなら、原因はまだ特定できていません。

③ 今回の対応で、手作業や運用ルールが増えていないか

見えにくい継続コストの有無を確認します。「影響はありません」と即答されるときほど、確認する価値があります。

④ 恒久対応をする場合、どこまで直すことになるか

範囲と規模の見当をつけます。範囲を示さず「対応は可能です」とだけ返るなら、まだ調査が必要な段階です。

⑤ この件の恒久対応の要否は、いつ・誰が判断するのか

判断の期限と責任の所在を確かめます。「追ってご相談します」で期日が入らない場合は、判断が宙に浮きます。

すべてに即答が返らなくても構いません。「まだ切り分け中です」も判断に使える情報です。特に重要なのは②と⑤で、原因が特定できているかどうかと、いつ誰が判断するのか。この2点さえ押さえておけば、その案件が宙に浮くことはなくなります。

実際の現場では、こんなふうに進みます。
「復旧しました」という一行の報告に対して、返すのは②と⑤だけ。
「原因は特定できていますか、それともまだ切り分け中ですか」「この件の恒久対応の要否は、いつ誰が判断しますか」。
翌日、「原因はログ肥大と判明し切り分けは完了、恒久対応の要否は来週の定例で判断します」と返ってくる。この一往復で、宙に浮きかけていた案件が、期日と判断者のついた案件に変わります。ここまで、技術的な議論は一度もしていません。発注側がしたのは、区分と期限を言葉にして返すことだけです。

「質問はわかったが、案件が多くてどこから確認すればいいか整理しきれない」 ——そんな段階でも構いません。Enlytでは、積み上がった暫定対応の棚卸しと、確認すべき案件の優先順位づけからご一緒できます。

［障害対応・運用体制のご相談はこちら］

集まった答えを、恒久対応の3パターンに仕分ける

答えが返ってきたら、次の3つのいずれかに振り分けます。ここまで来れば、専門知識がなくても意思決定ができます。

すぐに恒久対応へ進めるケース

売上や顧客対応に直接影響している、再発の頻度が高い、復旧のたびに手作業が発生している。こうした場合は、他の開発項目より先に見積もりを依頼します。

計画に載せて恒久対応するケース

影響は限定的だが再発リスクは残り、原因は特定できている。次回リリースのスコープに、正式な項目として組み込みます。

意図的に暫定対応のまま維持するケース

影響が軽微、コストが見合わない、近く仕様変更でその機能ごと作り替える。この判断は悪い判断ではありません。優先順位をつけること自体が発注側の役割です。問題なのは、判断しないまま時間が過ぎ、記録も残らないことです。「維持すると決めた」という事実と理由、見直しの時期が書かれていれば、担当者が変わっても引き継げます。

暫定対応から恒久対応へ切り替える判断基準

基礎編の記事では、その時点の状態から判断する切り口を示しました。ここでは同じ論点を、発注側が数字の推移として追える形に置き直します。単発の状態ではなく、悪化しているかどうかで見るのがポイントです。

切り替えを判断する4つのサイン（数字の推移で見る）

2つ以上に当てはまったら、恒久対応の見積もりを依頼するタイミングと考えてよいでしょう。特に「対応できる人が1人」と「改修への影響が出始めた」が重なったときは、放置のコストが跳ね上がる前兆です。

暫定対応を放置するコストとリスク（技術的負債の観点）

ここで補助線になるのが、リスクと問題の切り分けです。すでに起きている事象が「問題」、まだ起きていないが構造上いつか起きるものが「リスク」。暫定対応を積み重ねた状態は、問題としては解決済みに見えて、リスクとしては増え続けている状態にあたります。

DXレポートは技術的負債を「短期的な観点でシステムを開発し、結果として、長期的に保守費や運用費が高騰している状態」と定義しています。暫定対応の積み重ねが、まさにこれです。社内で予算を通す際は、発生回数と1回あたりの対応時間、業務影響を並べ、恒久対応の見積もり額と比較できる形にすると議論が進みます。暫定対応のコストは請求書に現れないだけで、確実に発生しています。

恒久対応の必要性は感じていても、費用対効果を社内でどう説明するかで止まってしまう ——それはよくある詰まりどころです。発生回数や対応時間を、予算判断に使える形へ整理するところから、セカンドオピニオンとしてお手伝いできます。

［Enlytに相談する］

恒久対応の判断を宙に浮かせない仕組み（記憶に頼らない運用）

ここまでの内容を担当者の注意力で回そうとすると、忙しくなった時点で必ず抜けます。障害は忘れた頃に起きるものであり、記憶に依存した管理は人の異動で消えます。本来は、開発会社側の運用として回っているのが望ましい部分です。パートナーを選ぶとき、あるいは今の体制を見直すときは、次の点を確認してみてください。

• 暫定対応が一覧として記録され、定期的に棚卸しされているか
• 一覧に「業務影響・実施した対応・原因の特定状況・恒久対応の要否・次回の見直し日」が揃っているか
• 「今すぐ止血すればよい不具合」と「放置すると再発する構造」が切り分けられているか
• ある案件で見つかった再発の芽が、他の案件にも横展開されているか
• 判断が滞ったときにエスカレーションする条件が決まっているか

Enlytでは、この役割をPMOが担っています。週次のヒアリング、リスクと問題の切り分け、横展開、エスカレーションを実務として回すことで、暫定対応の判断を個人の記憶に委ねない状態をつくっています。日本とベトナムの多拠点・リモート体制のため、「言わなくても伝わる」という前提が使えません。だからこそ、何を記録し、どこを標準化し、どこを明文化するかを設計する必要がありました。監視して報告させる部門ではなく、火種の段階で拾って次の案件に活かす予防管理として置いています。発注側から見れば、聞かなくても報告に出てくる状態かどうかが、仕組みが回っているかの分かれ目になります。

本当の分かれ目は、依頼の入口で「完了」を決めているか

ここまでは報告を受けた後の話をしてきましたが、Enlytがより重視しているのは、その手前です。恒久対応を依頼する段階、さらに言えば、最初にその開発を発注する段階で、「何をもって完了とするか」と「今回の対象から外す部分」を文章にしておけば、そもそも後から確認し直す場面の多くは要らなくなります。

私たちが受注前整理や要件の見える化を強みにしているのは、この「揉めないように進める設計」を上流でつくるためです。曖昧な言葉は、その場では衝突を避ける優しさに見えて、実際には将来の揉め事を先送りしているだけ。この前提に立つと、完了の定義を先に置くことは、面倒な手続きではなく、後工程のコストと摩擦を減らす投資になります。範囲の詰め方が甘いまま進んだ開発が後工程で膨らむ構図は、障害対応に限りません。

まとめ｜発注側の役割は、暫定対応と恒久対応の切り替えを設計すること

「暫定対応で対処しました」という報告を受けたとき、発注担当者に求められているのは、技術的な妥当性の評価ではありません。その対応が何を終わらせ、何を終わらせていないのかを確認し、次の判断を宙に浮かせないことです。

原因は特定できているか、いつ誰が判断するのか。この2つを毎回確認するだけで、障害対応は「開発会社にお任せ」の案件から「一緒に進める案件」へと変わります。暫定のままにすると決めた判断も含めて記録に残っていけば、担当者が変わっても、拠点が離れていても、同じ質で引き継がれます。

PM・ディレクターの価値は、進行を管理することではなく、曖昧さを減らし、期待値を揃え、事後発生を防ぎながら、同じ問題が二度起きない状態を設計することにあります。それは開発会社だけの仕事ではなく、依頼する側にも同じだけ持ち場があります。

システムの障害対応・運用体制についてのご相談

「止まったままの案件が心当たりある」「恒久対応が要る気はするが、社内でどう説明すればよいかわからない」——そうした段階からのご相談も歓迎しています。

Enlytは、受注前整理や要件の見える化といった上流工程からの伴走を強みとしています。積み上がった暫定対応の棚卸し、恒久対応の優先順位づけ、判断を止めないための運用設計まで、運用保守の体制づくりを含めてご一緒できます。現在の進め方についてのセカンドオピニオンとしても、お気軽にお声がけください。

Enlytへのお問い合わせはこちら

あわせて読みたい

• スコープ管理が崩れる本当の原因｜手戻りを防ぐディレクターの進め方 「完了の定義」や範囲の詰め方を、上流でどう固めておくか。本記事の「依頼の入口で完了を決める」という考え方と対になる記事です。
• システム開発の責任範囲はどこまで？発注者と開発会社が「検収間際」で揉めないための切り分け方 暫定対応か恒久対応か、そして「どちらが判断を持つか」を考えるうえで直結する、発注者と開発会社の責任範囲の切り分け方。
• 仕様書は渡したのに、なぜ違うものが上がってくるのか｜解釈のズレを生む構造と防ぎ方 「完了」や指示の言葉が受け手で別の意味になる本記事で触れた「言葉の二重性」を、仕様書の解釈という切り口でより広く扱っています。

白武 歩実

Enlytにて主に開発ディレクションおよびUI/UX設計を担当。 マクアケ、京セラ、大手通信キャリアなど、豊富な経験を持ち、エンジニア・デザイナー・クライアント間の橋渡し役としてプロジェクトを円滑に推進。 技術とデザイン、両方の視点を理解したコミュニケーションを強みとしている。

View More