運用保守には開発のような納期がなく、予定は立ち上げの準備、SLAの時間設定、定例レビューを組み合わせて組み立てます。
立ち上げには、運用設計と手順書の整備に数週間から1〜2ヶ月、並走に3〜6ヶ月を見込みます。アプリ・EC・業務システムにも通じる時間設計の判断軸です。
▼全体ガイドの記事
・システム運用保守の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
運用保守に「納期」概念が薄い理由
運用保守は、システムを動かし続ける継続的な業務です。ユーザーが使うかぎり、監視や障害対応、改善が続きます。
スケジュールを組む前に、運用保守には開発のような納期がないことを押さえておきます。ここまでで終わるという明確な納品物がないため、時間設計も開発とは別のものになります。
「点」の納期と「線」の継続という時間軸
開発は完成日という「点」を目指します。一方で、運用保守は稼働を維持する「線」の活動です。
- 開発：新規開発や改修では、期日までに機能やシステムを納める請負契約が多く、完成が評価の基準になります。
- 運用保守：24時間365日の稼働を維持し、SLAで定めた所定時間内の初動対応を続ける活動です。
- 契約：稼働時間やスキル、サービス品質を価値とする準委任契約や月額定額サービスが主流です。
たとえば、障害発生後15分以内の初動といったSLAの時間目標は、契約中に何度も守る必要があります。
完了日を追うガントチャートよりも、月次・四半期の定例サイクルでPDCAを回し、品質を維持・向上する設計が必要です。さらに、双方で前提を共有しておかないと、運用のゴールをめぐる認識がずれます。
運用と保守それぞれの「期間」の捉え方
運用保守は、性質の異なる運用と保守をまとめた呼び方です。そのため、期間の考え方も分けて捉えます。
- 運用：サーバーやネットワークの死活とリソースを監視し、バックアップ、ジョブ管理、問い合わせの一次対応を毎日・毎週・毎月続けます。
- 保守：不具合の修正、改善、更新で状態を保ち、障害予防や機能向上、環境変化への対応を行います。
運用の期間は、いつからいつまで、どの時間帯に体制を提供するかを契約に記しておきます。
保守は、是正、予防、完全化、適応の4種類に分かれます。是正は不具合を直すこと、予防は発生前に防ぐこと、完全化は機能や品質を高めること、適応は環境変化に合わせることです。
保守には、個別の期限も設定します。たとえば、パッチを3営業日以内に適用する、緊急不具合に当日着手するといった形です。一方で、保守の期限は開発の納期と違って、継続契約のSLAで繰り返し守る約束です。
運用は継続的な監視サイクル、保守は都度発生する作業期限の集まりです。このため、別々の時間軸で捉えることが設計の第一歩になります。
運用保守体制の立ち上げスケジュール
運用保守に納期はなくても、体制を立ち上げる段階には明確なスケジュールがあります。準備を軽視すると、リリース直後に運用が破綻しかねません。
- 準備フェーズでは、要件とSLAへの合意を取りつけます。
- 移行・整備フェーズでは、運用設計、ランブック、監視の整備を行います。
- 並走フェーズ（ハイパーケア）を経て、完全移行に至ります。
各段階の期間を見積もり、本番リリース日から逆算して予定を組むと、安定運用につながります。
運用設計・ランブック整備・監視設定の期間
最初の山場は、運用設計とランブック（運用手順書・障害対応マニュアル）の整備です。
- 監視設計：監視対象、アラートの重要度、対応窓口の決定
- 手順整備：一次切り分けや復旧作業のランブック、プレイブックの作成
- 監視設定：閾値の調整と通知ルールの設計
応答30分以内、復旧4時間以内といったSLAも明確にします。そうすると、発注側と期待値をそろえやすくなります。
この整備には、規模や複雑さに応じて数週間から1〜2ヶ月程度かかります。開発工程と並行して進め、リリース時点で手順書と監視体制を整えておくのが理想です。
開発完了後に着手すると、設定漏れや手順書の不備を抱えたまま本番を迎え、障害時に混乱するおそれがあります。外部委託の場合は、仕様やノウハウの引き継ぎも加わるため、2ヶ月（8週間）程度を見込むケースもあります。
並走期間・ハイパーケアの3〜6ヶ月
設計後すぐに全面移行はせず、自社の担当者と保守チームが並んで監視・対応する並走期間を設けます。
- 全体把握：1〜2週目に、システムと業務の全体像を把握
- 業務習得：3〜4週目に、運用業務を身につける
- 実務OJT：5〜6週目に、実務を通じて対応する
- 独立準備：7〜8週目に、単独運用への備え
並走は運用開始から3〜6ヶ月が目安です。インシデントを通じて手順書の不足や誤りを直し、自力で対応できる状態になってから、完全移行します。
並走を省略すると、手順書にないトラブルで復旧が遅れ、SLA違反のリスクが高まります。また、開発と運用のベンダーが異なる場合は、開発側が持つ内部仕様の知識も移管します。
立ち上げには明確な節目と日程があります。丁寧な設計が、その後の継続運用の土台になります。
リリース日からの逆算スケジュール例
中規模システムでは、本番リリース日から次のように逆算する例があります。
- 2〜3ヶ月前に運用設計へ着手し、監視対象を洗い出して、SLA案を作成します。
- 1〜2ヶ月前にランブック初版を作り、監視設定とテスト環境での通知確認を済ませておきます。
- 2〜4週間前に運用メンバーを教育し、机上訓練と障害対応のリハーサルを重ねます。
- 緊急連絡網とエスカレーションを確かめ、当日から3〜6ヶ月のハイパーケアに入ります。
ミッションクリティカルな基幹システムや24時間365日稼働のサービスでは、この逆算にさらに余裕を持たせる必要があります。
SaaS型監視ツールやMSPの標準パッケージを使う場合は、基盤が用意済みのため、数週間から1ヶ月程度で始められることもあります。
運用保守に納期がないことは、準備が不要であることを意味しません。立ち上げ期間の設計が、スケジュール全体の要になります。
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）は障害発生から復旧までの時間を指します。監視とアラートの設計はMTTAの短縮に、ランブック整備と習熟はMTTRの短縮に、それぞれ役立ちます。
時間内に解決できない場合に備えて、上位担当者や専門チームへ引き継ぐエスカレーションの流れと時点を決めておきます。
たとえば、一次対応で30分以内に復旧の目処が立たなければ二次対応へ進みます。二次対応で1時間以内に進展がなければ、責任者と開発元へ連絡します。
基準が曖昧だと、一次担当者が抱え込んでしまい、復旧時間を過ぎてから気づくため、SLA違反となる恐れがあります。
タイムラインと連絡基準は立ち上げ時のランブックに含め、定例レビューで実績をもとに改善していきます。この設計が、SLAの約束を実効あるものにし、運用保守の予定管理も支えます。
まとめ
運用と保守の総論から見ると、運用保守は明確な納期がない「線」の活動で、準委任契約や月額定額のマネージドサービスとして提供されるのが一般的です。
完了日を基準にするより、24時間365日の稼働とSLAの初動・復旧時間を守る品質サイクルを設計することが大切です。一方で、立ち上げには期間とマイルストーンがあり、運用設計などに数週間から1〜2ヶ月、並走に3〜6ヶ月を見込みます。
そのため、リリース日から逆算して予定を組むことが、安定運用の鍵になります。さらに、SLAや予防保守の周期、月次・四半期レビューを組み合わせ、継続運用を計画します。
「納期がないから準備も不要」とは考えず、立ち上げ期間と継続サイクルを整えましょう。具体的な体制や期間は、信頼できるパートナーに相談しながら検討できます。
▼全体ガイドの記事
・システム運用保守の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。