ITシステム定期メンテナンス計画は、現状調査から運用手順のリハーサルまでの3段階で進みます。各段階は2〜4週間、全体では約1.5〜3か月が目安です。
保守運営はチーム編成やシフトなどの体制・人員、保守監視は異常検知やアラート対応などの即時性、保守管理はSLAやCABなどの統制を扱います。定期メンテナンスは、時期・対象・周期を決めるカレンダー設計が中心です。
▼全体ガイドの記事
・ITシステム定期メンテナンスの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
定期メンテナンス計画プロジェクトの開発期間の全体像
新たに計画を策定する場合は、まず既存システムの年間カレンダーとパッチ適用ルールを整えます。続いて、停止時間帯であるメンテナンスウィンドウを設計し、業務部門に周知します。そのうえで、運用フローを作成し、リハーサルを行います。
標準的な規模では、各工程に2〜4週間かかるため、全体では約1.5〜3か月が目安です。
この期間は、計画策定そのものの目安です。
自動化ツールの導入や保守委託契約の見直しを伴う場合は、さらに長くなります。
予防保守と事後保守の違いが期間設計に与える影響
保守業務は事後保守（是正保守）と予防保守に分かれます。期間を見積もるには、両者で対応時期が異なる点を押さえておく必要があります。
- 事後保守：稼働中に見つかった不具合や故障の修復。発生前に対応時期は計画できません。
- 予防保守：障害前に潜在的なバグや機器の劣化を見つけて対処し、予定を組んで計画的に行います。
予防保守では、対象システムを棚卸しし、点検項目を洗い出しておく必要があります。ここが不十分だと、後工程のカレンダー策定やウィンドウ設計で漏れが見つかり、手戻りにつながります。
規模・システム数によって変わる期間目安
期間は、対象システム数と構成の複雑さを踏まえて、規模別に見積もります。
- 小規模：単一システムなら約1〜1.5か月
- 中規模：複数の基幹システムなら約2〜3か月
- 大規模：全社基盤などでは3〜6か月程度
小規模では、標準的な点検項目とパッチ周期を設定すれば、既存資料を流用できる場合があります。
中規模では、ベンダー契約やパッチ提供周期が異なるため、担当者への聞き取りや点検記録の照合に時間がかかります。
大規模では、24時間365日稼働する複数システムを横断して、部門ごとの利用状況に応じた停止時間を段階的に調整します。
どの規模でも、最初にシステムを棚卸しして既存資料の精度を確かめておくと、後工程の期間を見積もりやすくなります。
工程別スケジュール（現状調査から運用開始まで）
計画策定は3段階で進みます。最初に現状調査と要件定義を行い、次にカレンダーとパッチ計画を立てます。最後に運用フローと手順書を作成し、リハーサルを行います。各段階を2〜4週間で組み、全体を1.5〜3か月とするのが標準的なスケジュールです。
現状調査・要件定義フェーズ（2〜4週間）
要件定義では、対象システムの構成と保守契約に加えて、業務への影響を把握します。
- 構成と契約：機器・ソフトウェアの棚卸し、保守契約書、パッチ公開周期
- 業務影響：利用部門への聞き取り、繁忙期や決算期など避ける時期の確認
- 成果物：システム一覧、点検・適用状況、業務影響の調査結果
複数部門やグループ会社が同じシステムを使う場合は、聞き取り対象が増えるため、2〜4週間より長めに見積もるのが望ましいです。
調査が不十分なまま進むと、月次バッチの時間帯など後から制約が判明し、カレンダー策定で手戻りが起こります。
カレンダー策定・パッチ適用計画フェーズ（2〜4週間）
現状調査の後は、年間保守カレンダーとパッチ適用計画を策定します。
- 年間保守カレンダー案：月次・四半期・年次の点検項目
- パッチ適用ルール：適用の時期と順序
- ウィンドウ設計案：停止時間帯の複数候補とSLAへの反映案
毎月第3水曜日の深夜1時〜3時を、定例の停止枠にできます。
あわせて、業務部門や経営層に向けた説明資料もまとめます。
複数システムを横断する場合は、システム同士の依存関係も調整します。たとえば、あるシステムの停止中に、別システムのバッチ連携が失敗するケースもあります。
メンテナンスウィンドウ設計と年間保守カレンダーのスケジュール
計画の中心は、停止時間帯を設計するメンテナンスウィンドウと、年間保守カレンダーです。両者は密接に関連しており、それぞれに工程と注意点があります。
メンテナンスウィンドウ設計のステップ
メンテナンスウィンドウは、点検やパッチ適用のためにシステムを停止する時間帯です。設計時には、業務への影響、バッチとの競合、戻し時間の順に、停止の影響と作業時間を調整します。
- 業務影響を抑える：利用者が少ない深夜や休日を候補にします。
- バッチとの競合を避ける：夜間の日次バッチやバックアップと重ならないよう、ジョブスケジューラの実行時刻を調べます。
- 戻し時間を確保する：適用失敗時に元の状態へ戻す時間を枠内に設けます。
海外拠点からアクセスするシステムでは、時差を考慮して停止時間帯を選びます。
官公庁向けの維持管理業務委託仕様書などでは、計画点検による停止に発注者の事前承諾が必要です。
民間企業でも、経営層や利用部門への説明と承認に要する期間を、計画に含めておくのが望ましいです。
年間保守カレンダーの立て方とベンダーリリースサイクルとの同期
年間カレンダーには、社内の点検・報告時期と、ベンダーのパッチ対応日を組み込みます。
- 自社の定期点検：ハードウェア保守は年1回の例があります。
- 定期報告：維持管理業務の報告は年4回の例があります。
- パッチ対応：公開周期に合わせ、月次の検証日と本番適用日を設定します。
自社が定める定期点検は、そのままカレンダーに入れます。
定期報告は、3月・6月・9月・12月末などに設定されることもあります。
ベンダーが毎月第2火曜日にパッチを公開する場合は、その周期に合わせて検証日と適用日を組みます。
決算期や月末・月初などアクセスが集中する時期は、原則として定期メンテナンスの対象から外します。
社内の業務周期と社外ベンダーの公開周期を統合する作業では、調整に想定以上の時間がかかることがあります。そのため、期間は長めに見込みます。
納期を左右する要因と遅延の典型パターン
定期メンテナンス計画には、新規システム開発とは異なる固有の遅延リスクがあります。
代表的な2つの要因と、その対策を見ていきます。
EOL対応の見落としによる手戻り
見落としやすいのは、OSやミドルウェアのEOL（サポート終了）です。サポートが終わると、新たな脆弱性に対するパッチも提供されなくなります。
EOLを迎えた機器では、故障時の部品調達も難しくなります。調査で得た情報は、次の2点で計画に反映します。
- EOLの一覧化：全OS・ミドルウェア・ハードウェアの終了時期を記録
- 更新時期の設定：計画的な更新サイクルを年間カレンダーに反映
たとえば、適用計画の策定後に、ミドルウェアのサポートが半年後に切れると判明する場合があります。その場合、計画停止のスケジュールを組み直す手戻りが発生します。
要件定義・設計の段階から疎結合を意識すると、機能拡張や環境変更の影響を抑えられます。さらに、疎結合の設計は、将来のバージョンアップにかかる期間を短くすることにもつながります。
業務部門との調整不足・承認プロセスの遅延
もう一つの典型的な遅延要因は、停止候補について業務部門と想定以上に時間をかけて合意するケースです。繁忙期や重要業務の時期は、部門ごとに異なります。
複数部門が同じシステムを使う場合は、全部門が納得する停止時間帯を決めにくいことがあります。そこで、次の2点を早めに整えます。
- 合意形成：調査段階から主要部門を交え、複数の候補時間帯を提示
- 承認準備：初期に承認フローと決裁者を明確化
経営層への説明や承認を後回しにすると、計画完成間際に差し戻され、全体を再調整する事態になりかねません。
一方で、承認を段階的に得て計画を固めておくと、本稼働までの期間短縮につながります。
定期棚卸を組み込んだ運用開始後の継続サイクル
カレンダーとウィンドウを設計して運用を始めたあとも、計画は一度作って終わりではありません。
運用後は、継続的に見直すサイクルを組み込みます。その予定には、棚卸と計画改訂があります。
アカウント・資産棚卸のスケジュール設計
計画には、点検やパッチ適用に加えて、アカウント、機器・ソフトウェア資産、ライセンスの定期棚卸も組み込みます。
棚卸は障害対応ほど急を要しません。ただし放置すると、退職者のアカウントや、EOL後も使われている機器を見落とします。
ライセンスを超えて使うと、契約違反につながるおそれがあります。そこで、棚卸は対象ごとに周期を分けて行います。
- アカウント：四半期に1回
- 機器・ソフトウェア資産：半期に1回
- ライセンス：年1回
棚卸予定は、カレンダーとパッチ計画の段階と並行して、2〜4週間程度で策定できます。通常は独立した工程として、期間が大きく延びることはありません。
対象のアカウントや資産が多い大企業では、棚卸の実施そのものに時間がかかります。そのため、専用の実施体制とチェックリストに工数を確保しておきます。
計画の見直し・改訂サイクル
計画の見直しでは、確認項目と実施時期、所要期間をあらかじめ決めておきます。
- 見直し内容：システム追加やEOL機器の更新、運用で分かった停止時間の過不足
- 時期：年1回程度が目安です。決算期や年度替わりに翌年度のカレンダーを決める企業も多くあります。
- 期間と効果：初回より対象範囲が限られるため、通常は2〜4週間程度です。定例化すると、計画の形骸化を防ぎ、予防保守を続けやすくなります。
まとめ
定期メンテナンス計画は、点検時期と対象を事前に定めて進める取り組みです。
標準期間は、小規模で1〜1.5か月、中規模で2〜3か月、大規模で3〜6か月程度です。
工程別の期間、ウィンドウと年間カレンダーの設計、納期を左右する要因と遅延の典型例は、ここまで見てきたとおりです。
現状調査・要件定義、カレンダーとパッチ計画、運用手順とリハーサルの各段階には、2〜4週間を見込みます。
遅延を防ぐうえで最も重要な要点は、EOLを網羅的に確認することと、早い段階で合意しておくことです。
具体化する際は、まず対象システムを棚卸しします。そのうえで、複数の保守ベンダーやITSMツール提供会社に課題を示し、提案を比較します。
▼全体ガイドの記事
・ITシステム定期メンテナンスの完全ガイド
▼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を創業。