運用保守の開発期間・スケジュール・納期について

システムの運用保守は、開発プロジェクトとは時間軸の捉え方が根本的に異なります。新規開発であれば「いつまでに何を完成させて納品するか」という明確な納期（ゴール）が存在しますが、運用保守はリリースした後にシステムを「動かし続ける」ための継続的な営みであり、明確な終わりがありません。そのため「運用保守に開発期間や納期はあるのか」「スケジュールはどう組み立てるべきか」という問いに対しては、開発プロジェクトとは別の発想で答える必要があります。実際、運用保守フェーズは準委任契約や月額定額のマネージドサービスとして提供されることが一般的で、「期日までに成果物を納める」ではなく「24時間365日の稼働を維持し、SLA（サービスレベル合意）で定めた時間内に初動対応を続ける」ことが評価軸となります。この違いを理解しないまま開発の感覚でスケジュールを引くと、運用設計や引き継ぎの期間を軽視し、リリース直後に障害対応が回らなくなるという失敗に陥りがちです。

本記事では、運用（オペレーション）と保守（メンテナンス）の総論的な視点から、運用保守における「期間」「スケジュール」「納期」の考え方を体系的に解説します。運用保守体制を立ち上げる際の移行・引き継ぎ期間、本番リリース後の定例保守サイクル、SLAで縛られる初動・復旧の時間軸、そして「終わりのある開発」と「終わりのない保守」の違いまで、発注担当者が押さえるべきポイントを整理します。個別のシステム（アプリ・EC・業務システムなど）の運用保守を検討している方にとっても、上位概念としての時間設計の指針となる内容です。最後までお読みいただくことで、運用保守フェーズのスケジュールを適切に設計するための判断軸が身に付くはずです。

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

▼全体ガイドの記事
・システム運用保守の完全ガイド

運用保守に「納期」概念が薄い理由

運用保守のスケジュールを考える前に、まず「運用保守には開発のような納期が存在しない」という前提を理解することが重要です。新規開発や改修プロジェクトでは、特定の機能やシステムを完成させて納品するという明確なゴールと、そこに至る納期（プロジェクトの終わり）が存在します。請負契約で進められることが多く、「期日までに要件を満たした成果物を納めること」が評価基準となります。一方、運用保守フェーズには「ここまでやれば終わり」という明確な納品物がありません。システムは生き物のように日々稼働し続け、ユーザーが使い続ける限り、監視・障害対応・改善が無期限に続いていきます。この本質的な違いが、運用保守の時間設計を開発とはまったく別物にしているのです。

運用保守と開発の時間軸の違いを端的に表すなら、開発が「点」の目標であるのに対し、運用保守は「線」の継続だと言えます。開発における時間は「いつ完了するか」という一点のゴールに向かって収束していきますが、運用保守における時間は「24時間365日の稼働をいかに維持し続けるか」「障害発生時にSLAで定められた時間内（たとえば15分以内など）にいかに初動対応を開始し続けるか」という、終わりのない品質維持のプロセスです。したがって運用保守のスケジュール管理は、ガントチャートで完了日を引くような発想ではなく、月次・四半期の定例サイクルを通じて品質を維持・向上し続けるPDCAサイクルとして設計する必要があります。契約形態も、成果物の完成を約束する請負契約ではなく、エンジニアの稼働時間やスキル、提供されるサービス品質そのものを価値とする準委任契約や月額定額のマネージドサービスが主流となります。この前提を発注側・受注側の双方が共有しておかないと、「いつになったら運用が安定するのか」「どこがゴールなのか」といった噛み合わない議論が発生してしまいます。

運用保守という言葉は、性質の異なる2つの業務を束ねた総称です。期間やスケジュールの考え方も、運用と保守では分けて理解する必要があります。「運用（オペレーション）」は、システムを止めずに動かし続ける日常業務を指します。サーバーやネットワークの死活監視、リソース監視、バックアップの実行、バッチ処理（ジョブ）の運行管理、ユーザーからの問い合わせへの一次対応などが含まれ、これらは毎日・毎週・毎月といった定常的なサイクルで繰り返されます。運用における「期間」は、特定の作業の納期ではなく、「いつからいつまで、どの時間帯にこの監視・対応体制を提供し続けるか」というサービス提供期間として契約に明記されます。一方の「保守（メンテナンス）」は、不具合の修正や改善、更新によってシステムを正しい状態に保つ技術作業です。発見された不具合を直す是正保守、障害が顕在化する前に防ぐ予防保守、機能や品質を高める完全化保守、環境変化に合わせる適応保守の4種類に分類されます。保守作業には「セキュリティパッチの適用を3営業日以内に完了する」「緊急の不具合は当日着手する」といった個別の期限が設定されますが、これは開発の納期とは異なり、SLAという継続契約の中で繰り返し守られるべき約束です。運用は「継続的な監視のサイクル」、保守は「都度発生する作業の期限の集合」として、それぞれの時間軸を整理しておくことが、適切なスケジュール設計の第一歩となります。

運用保守体制の立ち上げスケジュール

運用保守に納期がないとはいえ、体制を「立ち上げる」フェーズには明確なスケジュールが存在します。むしろ、ここを軽視するとリリース直後に運用が破綻するため、運用保守における最も重要な期間設計はこの立ち上げ・移行フェーズにあると言っても過言ではありません。立ち上げは大きく「準備フェーズ（要件・SLA合意）」「移行・整備フェーズ（運用設計・ランブック・監視設定）」「並走フェーズ（ハイパーケア）」「完全移行」という流れで進みます。それぞれのステップに必要な期間を見積もり、本番リリース日から逆算してスケジュールを組むことが、安定した運用のスタートを切るための鍵となります。

立ち上げの最初の山場が、運用設計とランブック（運用手順書・障害対応マニュアル）の整備です。このフェーズでは、まず監視対象・アラートの重要度・対応窓口を定義し、「インシデント応答30分以内」「障害復旧4時間以内」といったSLAを明確にして、発注側と運用チームの期待値をすり合わせます。続いて、アラート発生時の一次切り分けや復旧作業のための運用手順書（ランブック・プレイブック）を作成し、監視ツールの設定として閾値のチューニングや通知ルールの設計を行います。この運用設計・ランブック整備・監視設定には、システムの規模や複雑さにもよりますが、一般的に数週間から1〜2ヶ月程度を要します。重要なのは、この期間を本番リリース前から並行して確保しておくことです。開発が完了してから慌てて運用設計に着手すると、監視の設定漏れや手順書の不備が放置されたまま本番を迎え、最初の障害でパニックになるという事態を招きます。運用設計は開発工程と並行して進め、リリース時点でランブックと監視体制が整っている状態を目指すのが理想的なスケジュールです。とくに外部のベンダーへ運用を委託する場合は、システムの仕様や運用ノウハウを正確に引き継ぐための期間設計が欠かせず、引き継ぎだけで2ヶ月（8週間）程度を見込むケースもあります。

運用設計と監視設定が整ったら、いきなり運用チームへ全面的に引き継ぐのではなく、自社担当者と保守チームが一緒に監視・対応を行う「並走期間（ハイパーケア）」を設けるのがセオリーです。この期間は運用開始から3〜6ヶ月程度を目安とし、実際に発生したインシデントを通じて手順書の不足や誤りを洗い出し、運用チームが完全に自力で対応できる状態に達してから完全移行とします。並走期間を省略してしまうと、ランブックに書かれていない想定外のトラブルに対応できず、復旧が長引いてSLA違反を起こすリスクが高まります。とくに、開発を担当したベンダーと運用を担当するベンダーが異なる場合は、システムの内部仕様に関する知識の断絶が起きやすいため、並走期間中に開発側のナレッジを運用側へ移管しておくことが極めて重要です。引き継ぎを段階的に進めるモデルとしては、8週間をかけて「1〜2週目で全体把握、3〜4週目で業務習得、5〜6週目で実務OJT、7〜8週目で独立運用準備」と進める方法が知られています。このように立ち上げフェーズには明確なマイルストーンとスケジュールが存在し、ここを丁寧に設計することが、その後の終わりのない運用を安定させる土台となるのです。

実際のプロジェクトでは、本番リリース日を起点に運用保守の立ち上げスケジュールを逆算して組み立てます。一例として、リリースの2〜3ヶ月前から運用設計に着手し、監視対象の洗い出しとSLAの草案作成を行います。リリースの1〜2ヶ月前にはランブックの初版を作成し、監視ツールの設定とテスト環境での通知確認を済ませます。リリースの2〜4週間前には、運用メンバーへの教育とリハーサル（机上訓練や障害対応シミュレーション）を実施し、緊急連絡網やエスカレーションフローを最終確認します。そしてリリース当日からハイパーケア期間に入り、3〜6ヶ月かけて運用を安定させていきます。このスケジュールはあくまで中規模システムの目安であり、ミッションクリティカルな基幹システムや24時間365日稼働が求められるサービスでは、さらに余裕を持った期間設計が必要です。逆に、SaaS型の監視ツールやMSPの標準パッケージを活用する場合は、運用基盤がすでに用意されているため、数週間から1ヶ月程度で運用を開始できるケースもあります。いずれにせよ、「運用保守には納期がない」という言葉を「準備にも時間をかけなくてよい」と誤解してはなりません。立ち上げ期間の設計こそが、運用保守スケジュールの肝なのです。

SLAが定める初動・復旧の時間軸

運用保守における「期間」の話で、開発の納期に最も近い概念がSLA（サービスレベル合意）で定められる時間です。SLAは、運用保守の品質を客観的な数値で約束する契約であり、その中核に「いつまでに対応するか」という時間軸の指標が含まれます。これらの時間目標は一度きりの納期ではなく、契約期間中に発生するすべての障害・問い合わせに対して繰り返し守られるべき継続的な約束である点が、開発の納期との決定的な違いです。ここでは、運用保守のスケジュールを実質的に支配するSLAの時間指標を整理します。

SLAで定められる時間指標のうち、運用保守のスケジュールに直結するのが応答時間と復旧時間です。インシデント応答時間（着手の有無を回答するまでの時間）は、契約のグレードによって「翌営業日」から「1時間以内」まで幅があります。重大障害については、「障害発生後30分以内に通知する」ことを遵守率100%で求められるケースもあります。障害復旧時間は「1回の障害につき6時間以内」を基準としつつ、「95%以上のケースで4時間以内に復旧する」といった遵守率付きで設定されるのが一般的です。さらに、ヘルプデスクの問題解決率を「24時間以内に95%以上」、重大障害の発生件数を「年2回まで」とするなど、品質の上限・下限を時間と回数で縛る指標も組み合わされます。これらの数値は業務への影響度に応じて設計されるべきもので、たとえば数分の停止が大きな損失につながるECサイトの決済系と、夜間に停止しても翌朝までに復旧すればよい社内システムとでは、求められる応答・復旧時間がまったく異なります。発注側は、自社システムの停止が業務にどれだけ影響するかを見極めたうえで、過剰でも過小でもない適切なSLAの時間設定を選ぶことが重要です。

運用保守のスケジュールには、障害発生時の応答・復旧という「受動的な時間軸」だけでなく、計画的に繰り返す「能動的な定期作業の時間軸」も存在します。これが予防保守の周期です。たとえばセキュリティの脆弱性診断は、システムの重要度に応じて「年1回」から「毎月」までの間隔で実施します。ハードウェアの定期点検は「年1回から年3回」、定時バックアップは「24時間ごと」など、明確な周期を定めて運用カレンダーに組み込みます。是正保守においても、緊急の不具合は「当日〜翌日に着手」、通常の不具合は「次回のメンテナンスウィンドウでまとめて対応」といった具合に、緊急度別の時間ルールを設けます。これらの定期作業をスケジュール化しておくことで、「気づいたらパッチが何ヶ月も当たっていなかった」「バックアップが失敗したまま放置されていた」といった、運用の盲点による重大インシデントを未然に防げます。予防保守の周期設計は地味な作業ですが、終わりのない運用を計画的かつ持続可能にするための、運用保守スケジュールの背骨と言える要素です。

並走期間を経て完全移行した後も、運用保守はシステムを放置するわけではありません。月次あるいは四半期ごとに定例レビュー会を実施し、PDCAサイクルを回し続けることが、継続フェーズにおけるスケジュール管理の中心となります。定例レビューでは、まず事前に合意したSLAが達成できているか（稼働率、応答時間、復旧時間など）を、実績データに基づいて確認します。そのうえで、不要なアラート（ノイズ）の削減、発生したインシデントの根本原因分析（恒久対策の検討）、ランブックのアップデート、自動化ツール導入の進捗確認といった改善活動を議論します。この定例サイクルがあることで、運用保守は「ただ現状維持するだけの守りの活動」から「継続的に品質を高めていく攻めの活動」へと進化します。発注側にとっても、月次・四半期のレビューは運用の状態を可視化し、追加投資の判断や改善要望を伝える貴重な機会です。終わりのない運用保守だからこそ、定期的なチェックポイントを設けて方向性を確認し続けることが、長期にわたってシステムの価値を維持する上で欠かせないのです。このように運用保守の「スケジュール」とは、納期に向かう直線ではなく、定例サイクルを繰り返す円環として捉えるのが正しい理解です。

SLAで定めた応答・復旧時間を実際に守り続けるためには、障害発生から復旧までの時間の流れ（タイムライン）を具体的に設計しておくことが欠かせません。障害対応のタイムラインは一般に、検知・受付、初動・切り分け、応急対応、根本対応・復旧、報告・再発防止という段階に分かれ、それぞれにかかる時間を見積もって全体の復旧時間を組み立てます。ここで重要になるのが、平均確認時間（MTTA：障害を検知してから担当者が対応に着手するまでの時間）と平均復旧時間（MTTR：障害発生から復旧までの時間）という2つの指標です。MTTAを短縮するには監視とアラートの設計が、MTTRを短縮するにはランブックの整備と習熟が効いてきます。そして、定められた時間内に解決できない場合に備えて、エスカレーション（上位担当者や専門チームへの引き継ぎ）のフローと、その発動タイミングをあらかじめ決めておく必要があります。たとえば「一次対応で30分以内に復旧の目処が立たなければ二次対応チームへ、二次対応で1時間以内に進展がなければ責任者と開発元へエスカレーションする」といった具合に、時間を区切ったエスカレーション基準を設計します。この時間軸の設計が曖昧だと、一次担当者が抱え込んでいる間に復旧時間が経過し、気づいたときにはSLA違反という事態に陥ります。障害対応のタイムラインとエスカレーション設計は、SLAという「約束した時間」を絵に描いた餅にしないための、運用保守スケジュール管理の実務的な要となるのです。これらは立ち上げフェーズのランブック整備に含めて準備し、定例レビューで実績をもとに継続的に改善していくべき項目です。

まとめ

本記事では、運用保守における「開発期間」「スケジュール」「納期」の考え方を、運用と保守の総論的な視点から解説しました。運用保守は開発プロジェクトと異なり、明確な納期（ゴール）が存在しない「線」としての継続的な営みであり、準委任契約や月額定額のマネージドサービスとして提供されるのが一般的です。そのため、ガントチャートで完了日を引く発想ではなく、24時間365日の稼働維持とSLAで定めた初動・復旧時間を守り続けるという、品質維持のサイクルとしてスケジュールを設計する必要があります。一方で、運用保守体制の「立ち上げフェーズ」には明確な期間とマイルストーンが存在し、運用設計・ランブック整備・監視設定に数週間〜1〜2ヶ月、並走期間（ハイパーケア）に3〜6ヶ月を見込み、本番リリース日から逆算してスケジュールを組むことが安定運用の鍵となります。また、SLAの応答・復旧時間、予防保守の周期、月次・四半期の定例レビューといった時間軸を組み合わせることで、終わりのない運用を計画的かつ持続可能なものにできます。運用保守の発注を検討されている方は、「納期がないから準備も不要」と誤解せず、立ち上げ期間の設計と継続サイクルの仕組みづくりに十分な時間を確保することをお勧めします。具体的な体制や期間の設計にあたっては、まず信頼できるパートナーに相談してみることから始めるとよいでしょう。

▼全体ガイドの記事
・システム運用保守の完全ガイド

株式会社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を創業。