ITシステム不具合対応の開発期間・スケジュール・納期について

ITシステム不具合対応とは、稼働中のシステムで発生した不具合（バグ・障害）を検知・報告された後に、その原因を切り分け、再現確認を行い、重要度と緊急度から優先度を判定した上で、応急処置にあたる「暫定対応」と根本解決にあたる「恒久対応」を使い分けながら収束させる一連の実務を指します。同じ「保守」領域でも、常時システムを見張り異常の兆候をいち早く検知してアラートを発報する「保守監視」とは役割が異なり、不具合対応は「すでに発生した（あるいは報告された）不具合に対して、いかに早く業務影響を止血し、いかに根本原因を突き止め、いかに再発させない形で収束させるか」という、発生後の実務対応力に主眼が置かれる領域です。不具合の切り分け、優先度判定会議、暫定対応と恒久対応の時間軸の使い分け、修正パッチの検証、そして事後の再発防止策の検討までを含む、システムを安定的に運用し続けるための「守りの実務」の中核を担っています。

経済産業省の「DXレポート」でも指摘されているとおり、日本企業のIT関連費用の8割以上が既存システムの運用保守に充てられており、その中でも不具合対応は日々発生し続ける実務として、開発・情シス双方のリソースを恒常的に消費しています。しかし、いざ不具合が発生した際に「対応にはどのくらいの時間がかかるのか」「暫定対応と恒久対応で納期感はどう違うのか」「優先度によってスケジュールはどう変わるのか」を体系的に理解している担当者は決して多くありません。対応が後手に回れば業務影響が長引き、逆に不要な不具合にまでリソースを割けば本来注力すべき開発が滞ります。本記事では、ITシステム不具合対応の開発期間・スケジュール・納期に焦点を当て、暫定対応と恒久対応それぞれの時間軸、障害レベル別のSLA目標復旧時間、優先度判定とスケジュール決定のプロセス、切り分けから恒久対応完了までの標準フロー、そして事後対応の期限までを体系的に解説します。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・ITシステム不具合対応の完全ガイド

ITシステム不具合対応の開発期間の全体像

不具合対応の期間を考える上で最も重要なのは、「対応にかかる期間はひとつではない」という前提を持つことです。障害発生時に根本解決とサービスの継続復旧を同時に進めようとすると、変更テストや再デプロイに膨大な時間を要し、システムの停止時間そのものが長期化してしまいます。そのため実務では、対応を「暫定対応（インシデント管理）」と「恒久対応（問題管理）」という2つの時間軸に明確に分離して進めるのが定石です。この2つを混同したまま「不具合対応にはどのくらいかかるか」を一括りに議論すると、現場の温度感と経営層の期待値がずれ、無理な短納期を強いられたり、逆に本来急ぐべき止血対応が後回しになったりする原因になります。まずはこの2つの時間軸の違いを正しく理解することが、現実的なスケジュール設計の出発点です。

暫定対応は、利用者が通常業務を再開できる状態を最優先で確立することを目的とした「止血対応」です。時間軸としては分単位〜時間単位というスピードが最重視され、原因の特定に固執せず、予備サーバーへの切り替えや再起動、代替手段の提供といった応急処置を行います。この段階でエンジニアが根本原因の調査に時間を割いてしまうと、業務停止時間そのものが長引くため、暫定対応の目的はあくまで「業務を止めないこと」に絞り込む必要があります。暫定対応が完了し利用者が業務を再開できる状態になった時点で、対応の主眼は次の恒久対応フェーズへと引き継がれます。この切り替えのタイミングを明確にしておくことが、対応チーム内での役割分担と、経営層・利用部門への状況報告をスムーズにする鍵になります。

恒久対応は、暫定対応でサービスが継続できた後に着手する、根本原因を排除し再発を防ぐための取り組みです。ログ分析による原因の特定、詳細なコードやパラメーターの修正、本番同等環境での機能検証を経てパッチを適用するというプロセスを踏むため、暫定対応とは対照的に中長期的な時間軸で進められます。恒久対応にどれだけの期間を要するかは、不具合の技術的な難易度と、後述する優先度判定の結果によって大きく変動します。単純な設定ミスであれば数日で完了することもありますが、システムアーキテクチャの構造的な問題に起因する不具合であれば、数週間から数ヶ月の中長期的な計画が必要になるケースもあります。重要なのは、暫定対応が完了したからといって恒久対応を後回しにしすぎないことです。恒久対応を先延ばしにし続けると、同じ不具合が繰り返し発生し、結果的に対応工数が膨らみ続けるという悪循環を招きます。また、恒久対応の完了をもって「不具合対応が終わった」とみなすのではなく、後述するポストモーテム（事後検証）まで含めて一連のプロセスと捉えることが、再発防止の観点からも重要です。

障害レベル別のSLA目標復旧時間

不具合対応の納期感を具体的にイメージするには、障害の深刻度（レベル）に応じてどの程度の対応時間が求められるのかという、SLA（サービスレベル合意）の一般的な水準を押さえておくことが有効です。すべての不具合を同じ速度で対応しようとすると現場が疲弊するため、深刻度に応じた段階的な目標時間を設定するのが実務上の標準的な考え方です。

SLA目標の一例として、コンサルティング会社等が示す障害レベル別の水準を紹介します。「Critical（極大）」は全社業務が停止し全ユーザーがアクセス不可能になるような状態（インターネット回線全断、ランサムウェア被害等）で、検知から15分以内の初回応答と1時間以内の目標復旧時間が求められます。「High（大）」は部門・特定業務・主要機能が停止する状態（特定SaaSの停止、サーバー障害等）で、検知から30分以内の初回応答、4時間以内の目標復旧時間が目安です。「Medium（中）」は一部の非コア機能に不具合が生じているものの代替手段（ワークアラウンド）がある状態で、翌営業日の朝会等での共有と、翌営業日中の復旧が目安になります。「Low（小）」は画面表示の乱れなど実務遂行への影響がない軽微な不具合で、週次定例報告の枠組みで共有し、1週間以内の復旧が目安です。あわせて、可用性の目標値として月間稼働率「99.5%以上」といった指標が用いられるケースもあります。自社のシステムでこのようなレベル分けとSLAをあらかじめ合意しておくことで、不具合発生時に「どのくらいの時間で対応すべきか」を現場が迷わず判断できるようになります。逆に、こうしたレベル分けを持たないまま不具合対応にあたると、軽微な不具合にも重大障害と同じ体制で対応してしまい、結果的に本来優先すべき対応が遅れるという本末転倒な事態を招きかねません。

SLAの目標値だけでなく、実際の企業がどの程度の対応スピードを実現しているかを知ることも、自社のスケジュール感を検討する参考になります。PagerDutyが公開している事例によると、株式会社ココナラは、インシデント管理ツール（PagerDuty）の導入により、日中に発生したアラートに対する平均確認時間（MTTA：Mean Time To Acknowledge）を1分以内に、暫定対応としての平均修復時間（MTTR：Mean Time To Repair）を1営業日程度に収める運用を実現しているとされています。この事例が示すのは、適切なインシデント管理の仕組みを整えれば、「アラートに気づくまでの時間」と「暫定対応が完了するまでの時間」をそれぞれ大幅に短縮できるということです。逆にいえば、こうしたツールや体制が整っていない組織では、同じ深刻度の不具合であってもMTTA・MTTRが大きく長引く可能性が高く、SLAの目標値と実際の対応力にギャップが生じやすい点には注意が必要です。

不具合の優先度判定とスケジュール決定のプロセス

発見された不具合のすべてを直ちに修正するわけではありません。開発チームが実際に修正を行うスケジュールは、「不具合判定会議」などの場で、開発リソースの空き状況と相談しながら決定されます。この優先順位付けの軸となるのが「重要度（システムへの影響）」と「緊急度（時間軸の要件）」の掛け合わせによるマトリクスです。

優先度「最高（Blocker）」は、システムのコア機能が著しく破損している、あるいは致命的な脆弱性が存在する状態を指します。リリース予定日や顧客との契約期限が数日以内に迫っている場合が典型例で、開発チームの全タスクを直ちに中断し、最優先でアドホックなホットフィックス（緊急修正）を実行します。優先度「高（Critical）」は、主要機能が機能しないものの複雑な代替手段で回避可能な状態で、次のスプリントリリース、あるいは数週間以内のデプロイが求められます。スプリントのバックログの最上部に強制的に配置され修正されます。優先度「中（Major）」は、補助的な機能のダウンや特定環境下での不具合が該当し、緊急度が低いため恒久的な修正を一定期間保留しても実害がないと判断されます。計画されたリリース枠に余裕がある期間などを活用して順次消化していきます。優先度「低（Minor）」は、軽微な表示崩れやスペルミスなど、操作に支障がない不具合です。数ヶ月から半期放置されてもビジネス上の問題は発生しないと判断されるため、開発ロードマップに余裕が出たタイミングでまとめて修正されます。このように、同じ「不具合」であっても優先度によってスケジュール感はまったく異なり、「数日以内」から「数ヶ月〜半期」まで幅があることを理解しておく必要があります。

スケジュールを左右する優先度判定を、バグを発見したテスト担当者や個人のエンジニアが単独で行うことは避けるべきだとされています。これは「検出者バイアス」と呼ばれる問題で、発見した本人は「自分が見つけた不具合はすぐに直すべきだ」と考えがちですが、開発全体のコンテキスト、すなわち残されている技術的負債の状況や全体のリリーススケジュールを十分に把握できていない可能性が高いためです。そのため、優先度の判定は、開発全体の事情を理解しているプロダクトマネージャー（PM）やプロダクトオーナー（PO）などが主導して決定することが、ガバナンス上重要とされています。この体制を整えておくことで、個々の担当者の主観によってスケジュールが場当たり的に変動することを防ぎ、組織全体として一貫性のある納期感を持って不具合対応を進められるようになります。

切り分け・再現確認から恒久対応完了までの標準フロー

ここまで見てきた時間軸・SLA・優先度の考え方を踏まえ、不具合の発生から収束までを一連の流れとして整理すると、全体のスケジュール感がより具体的にイメージできます。

不具合対応の最初のステップは、発生の検知と一次切り分けです。監視ツールのアラートやユーザーからの問い合わせによって不具合が認知されると、まず影響範囲（どの機能が、どの利用者に、どの程度の影響を与えているか）を特定し、前述の障害レベル（Critical〜Low）に応じた初回応答時間内に一次対応を開始します。ここでの目的は原因の完全な特定ではなく、あくまで業務影響を止めることです。予備システムへの切り替えや再起動、代替手段の案内といった止血対応を、対象レベルごとに定められた目標復旧時間（Criticalなら1時間以内、Highなら4時間以内など）を目安に完了させます。この段階のスピード感は、後続の原因調査・恒久対応のスケジュールに直接影響しないため、「まず止血、原因究明は後」という順序を徹底することが、結果的に全体の対応期間を短縮することにつながります。

暫定対応でサービスが継続できる状態になったら、次は原因調査と再現確認のフェーズに移ります。ログ分析によって発生条件を特定し、開発環境や検証環境で不具合を意図的に再現させることで、原因の仮説を検証します。原因が特定できたら、不具合判定会議などを経て前述の優先度が決定され、そのスケジュールに沿って修正パッチの開発を進めます。修正が完成したら、本番環境にそのまま適用するのではなく、本番同等環境での機能検証を行い、意図した不具合が解消されていること、そして修正が新たな不具合を生んでいないことを確認した上で、恒久対応としてパッチを適用します。この一連のプロセスにかかる期間は、優先度「最高」であれば数日以内、優先度「高」であれば次スプリントから数週間以内が目安となり、優先度「中」「低」であれば数ヶ月から半期というスパンで計画的に消化されることになります。

恒久対応によって不具合が収束した後も、対応そのものはそこで終わりではありません。原因分析や再発防止策を話し合う「ポストモーテム（事後検証）」は、関係者の記憶が新しいうちに実施することが望ましく、目安としてはインシデント解決後72時間以内、あるいは2〜3営業日以内に実施することが理想的とされています。この期限を過ぎてしまうと、対応にあたったメンバーの記憶が薄れ、詳細な経緯や判断の根拠が曖昧になり、再発防止策の質が低下してしまいます。ポストモーテムをスケジュールにあらかじめ組み込んでおくこと、そして恒久対応の完了と同時に実施日を確定させることが、不具合対応のプロセス全体を「一度きりの火消し」で終わらせず、継続的な改善サイクルとして機能させるための重要なポイントです。なお、恒久対応の中でも根本原因がシステムアーキテクチャの限界に起因すると判明した場合は、パッチ修正では対応しきれず、より大規模な改修や作り直しの検討が必要になることがあります。この判断基準については、本テーマの「フルスクラッチ・オーダーメイド開発」編で詳しく解説しています。

まとめ

本記事では、ITシステム不具合対応の開発期間・スケジュール・納期について、暫定対応と恒久対応の時間軸の違い、障害レベル別のSLA目標復旧時間、優先度判定とスケジュール決定のプロセス、切り分け・再現確認から恒久対応完了までの標準フロー、そして事後対応の期限までを体系的に解説しました。暫定対応は分単位〜時間単位のスピードで業務影響の止血を最優先し、恒久対応は原因調査から検証・パッチ適用までを含む中長期的な時間軸で進めるという、2つの時間軸を明確に分離する考え方が不具合対応スケジュールの基本です。障害レベルに応じてCriticalなら1時間以内、Highなら4時間以内といった目標復旧時間の目安があり、修正の優先度は重要度と緊急度のマトリクスによって「数日以内」から「数ヶ月〜半期」まで大きく変動します。優先度判定を検出者個人に委ねず、開発全体の事情を理解するPM等が主導することも、スケジュールの一貫性を保つ上で欠かせません。不具合対応にかかる期間は、システムの複雑さや技術的負債の蓄積状況によっても左右されるため、自社の状況を踏まえた現実的な納期感を持つことが重要です。具体的な対応体制やスケジュールの設計については、複数の開発会社・保守運用パートナーに現状のシステム構成と求めるSLA水準を提示して相談することをお勧めします。

▼全体ガイドの記事
・ITシステム不具合対応の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。