ITシステム定期メンテナンスの開発期間・スケジュール・納期について

「ITシステム定期メンテナンス」とは、障害が発生してから対応する事後保守（是正保守）とは異なり、潜在的な不具合や機器の劣化が実際の障害として表面化する前に、あらかじめ定めたサイクルで点検・パッチ適用・部品交換などを計画的に実施する「予防保守（Preventive Maintenance）」の実務全体を指します。具体的には、月次・四半期・年次といった単位で点検項目を定める点検スケジュールの策定、OSやミドルウェアのセキュリティパッチをいつ・どの順序で適用するかを定めるパッチ適用計画、システムを意図的に停止させる時間帯を設計するメンテナンスウィンドウの設計、そしてアカウントや資産、ライセンスを定期的に棚卸しする予防保守サイクルの運用が中心的なテーマです。似た言葉である「保守運営」がチーム編成やシフトといった体制・人員の話、「保守監視」が異常検知とアラート対応という即時性の話、「保守管理」がSLAや変更管理委員会（CAB）といった統制の話であるのに対して、「定期メンテナンス」は「いつ・何を・どのサイクルで手当てするか」という時間軸・カレンダー設計そのものに焦点が当たる点が最大の違いです。

この定期メンテナンス計画は、新規にシステムを構築するプロジェクトとは性質が異なるため、「どのくらいの期間で年間保守カレンダーやパッチ適用計画を策定できるのか」「メンテナンスウィンドウの設計にはどんな工程が必要なのか」「納期が遅延しやすいポイントはどこにあるのか」といった疑問を抱く情報システム部門の担当者は少なくありません。本記事では、ITシステムの計画的・予防的な定期メンテナンス体制を新たに整備するプロジェクトに焦点を当て、開発期間の全体像、工程別スケジュール、メンテナンスウィンドウ・年間保守カレンダーの設計スケジュール、そして納期を左右する要因と遅延の典型パターンまでを体系的に解説します。

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

▼全体ガイドの記事
・ITシステム定期メンテナンスの完全ガイド

定期メンテナンス計画プロジェクトの開発期間の全体像

ITシステムの定期メンテナンス計画を新たに策定・導入するプロジェクトは、既存システムに対する年間カレンダーの策定、パッチ適用ルールの明文化、メンテナンスウィンドウの設計と業務部門への周知という3つの工程を積み上げて進めます。標準的な規模の企業であれば、現状調査・要件定義に2〜4週間、カレンダー・計画策定に2〜4週間、運用フロー・手順書作成とリハーサルに2〜4週間を要し、全体としては約1.5〜3か月程度が目安となります。ただし、これはあくまで「計画そのものの策定」にかかる期間であり、実際に自動化ツールの導入や既存の保守委託契約の見直しを伴う場合は、さらに長い期間を見込む必要があります。

システム保守の業務は、対応のタイミングによって大きく「事後保守（是正保守）」と「予防保守」に分けられます。事後保守は、稼働中に発見された不具合やハードウェアの故障を事後的に修復する受動的な活動であり、対応のタイミングを事前に計画することができません。一方で予防保守は、潜在的なバグや機器の劣化が実際の障害として表面化する前に検出・対処する能動的な活動であり、あらかじめスケジュールを組んで計画的に実施できる点が最大の特徴です。定期メンテナンス計画プロジェクトの期間を見積もる際には、この予防保守の性質を理解しておくことが重要です。つまり、事後保守のように「発生してから対応する」ものではなく、「いつ・どの頻度で・何を点検するか」を事前に設計し尽くす必要があるため、要件定義段階での対象システムの棚卸しと、点検項目の網羅的な洗い出しに相応の期間を要します。この洗い出しを甘くしてしまうと、後工程のカレンダー策定やメンテナンスウィンドウ設計の段階で抜け漏れが発覚し、計画全体の手戻りにつながる点に注意が必要です。

定期メンテナンス計画の策定にかかる期間は、対象システムの数と構成の複雑さによって変動します。単一システムを対象とし、標準的な点検項目とパッチ適用サイクルを設定する小規模なケースでは、既存の運用ドキュメントを流用できることが多く、約1〜1.5か月程度で計画策定が完了することもあります。複数の基幹システムを対象とし、システムごとに異なるベンダー保守契約やパッチ提供サイクルが存在する中規模のケースでは、各システムの担当者へのヒアリングや、既存の点検記録の突合に時間がかかるため、約2〜3か月を見込む必要があります。全社基盤やミッションクリティカルなシステムを対象とし、24時間365日稼働する複数システムを横断してメンテナンスウィンドウを調整する大規模なケースでは、業務部門ごとの利用状況の違いを考慮したうえで停止時間帯を段階的に設計する必要があり、3〜6か月程度を要することも珍しくありません。いずれの規模であっても、対象システムの棚卸しと既存ドキュメントの精度確認を最初に行うことが、後工程の期間見積もりの精度を高める鍵になります。

工程別スケジュール（現状調査から運用開始まで）

定期メンテナンス計画の策定プロジェクトは、大きく「現状調査・要件定義」「カレンダー策定・パッチ適用計画」「運用フロー・手順書作成とリハーサル」の3つのフェーズで進めます。各フェーズをそれぞれ2〜4週間で計画し、全体で1.5〜3か月というスケジュール感が標準的です。

最初のフェーズでは、対象システムのハードウェア・ソフトウェアの構成を棚卸しし、既存の保守契約書やベンダーが提供するパッチのリリースサイクルを確認します。あわせて、各システムを利用している業務部門にヒアリングを行い、繁忙期や決算期など「絶対にメンテナンスを避けるべき時期」を洗い出します。このフェーズで作成すべき成果物は、対象システム一覧、既存の点検・パッチ適用の実施状況、業務部門への影響調査結果の3点です。特に、複数の部門やグループ会社が同じシステムを共有している場合は、ヒアリング対象が増えるため、標準の2〜4週間よりも長めに見積もっておくことが望ましいといえます。この現状調査の精度が低いまま次のフェーズに進んでしまうと、カレンダー策定の段階で「実はこの時間帯は月次バッチが動いていた」といった想定外の制約が後から判明し、手戻りが発生する原因になります。

現状調査が完了したら、実際の年間保守カレンダーとパッチ適用計画を策定します。このフェーズでは、月次・四半期・年次それぞれの点検項目を確定し、たとえば「毎月第3水曜日の深夜1時〜3時をパッチ適用の定例枠とする」といった具体的なパッチ適用サイクルを決定します。あわせて、システムを意図的に停止させるメンテナンスウィンドウの候補時間帯を複数案作成し、業務部門と経営層への説明資料としてSLAへの反映案をまとめます。このフェーズの成果物は、年間保守カレンダー案、パッチ適用ルール、メンテナンスウィンドウ設計案の3点です。特に、複数システムを横断してカレンダーを組む場合は、システム間の依存関係（あるシステムのメンテナンス中は別のシステムからのバッチ連携が失敗する、など）を考慮する必要があり、この調整に想定より時間がかかるケースが多く見られます。

メンテナンスウィンドウ設計と年間保守カレンダーのスケジュール

定期メンテナンス計画の中核をなすのが、メンテナンスウィンドウの設計と年間保守カレンダーの策定です。この2つは密接に関連しており、それぞれに固有の工程とスケジュール上の注意点があります。

メンテナンスウィンドウとは、パッチ適用や点検作業のためにシステムを意図的に停止させる時間帯を指します。この設計には、業務影響の最小化、バッチ処理との競合回避、ロールバック時間の確保という3つのステップを踏むことが実務上のセオリーです。まず業務影響の最小化では、利用者の少ない深夜や休日を停止時間帯として設定しますが、グローバルに展開しているシステムや、海外拠点からのアクセスがある場合は、時差を考慮した時間帯選定が必要です。次にバッチ処理との競合回避では、夜間に実行される日次バッチ処理やバックアップ処理のスケジュールと重ならないよう、既存のジョブスケジューラの実行時刻を精査します。最後にロールバック時間の確保では、パッチ適用作業が失敗した場合に元の状態に戻す作業時間をあらかじめウィンドウ内に組み込んでおく必要があります。加えて、官公庁向けの維持管理業務委託仕様書などでは、計画点検等によるシステムの意図的な停止は事前に発注者の承諾を得ることが必須とされており、民間企業においても経営層や利用部門への事前説明と承認プロセスをスケジュールに織り込んでおくことが望ましいといえます。

年間保守カレンダーを策定する際には、まず自社が独自に定める定期点検（ハードウェアの定期保守など）のサイクルを組み込みます。実務では、ハードウェアの定期保守は年1回、維持管理業務に関する定期報告は年4回（3月・6月・9月・12月末など）といった頻度で設計されるケースが多く見られます。加えて、OSやミドルウェアの提供元がリリースするセキュリティパッチの提供サイクル（たとえば特定ベンダーが毎月第2火曜日にセキュリティパッチを公開するなど）に同期させて、月次のパッチ検証日と本番適用日をカレンダーに組み込むことが重要です。また、企業の決算期や月末・月初などアクセスが集中しやすい時期は、原則として定期メンテナンスの対象から外すようにカレンダーを設計する必要があります。このように、社内の業務サイクルと社外ベンダーのリリースサイクルという2つの時間軸を統合してカレンダーを組み立てる作業には、想定以上の調整期間がかかることを踏まえてスケジュールを組んでおくべきです。

納期を左右する要因と遅延の典型パターン

定期メンテナンス計画の策定プロジェクトには、新規システム開発とは異なる固有の遅延リスクが存在します。ここでは、代表的な2つの遅延要因とその対策を整理します。

定期メンテナンス計画の策定でもっとも見落とされやすいのが、OSやミドルウェアのEOL（サポート終了）の把握です。EOLを迎えた機器やソフトウェアは、メーカーのサポートが終了するため新たな脆弱性が発見されてもセキュリティパッチが提供されなくなり、故障時の部品調達も困難になります。現状調査フェーズでEOLの時期を正確に把握できていないと、パッチ適用計画を策定した後になって「実はこのミドルウェアは半年後にサポートが切れる」といった事実が判明し、計画停止のスケジュールを組み直す手戻りが発生します。対策としては、現状調査フェーズの初期段階で、対象システムを構成するすべてのOS・ミドルウェア・ハードウェアのEOL情報を一覧化し、計画的な更新サイクルとして年間保守カレンダーに組み込んでおくことが有効です。あわせて、要件定義・設計の段階から機能拡張や環境変更の影響を最小化する疎結合設計を意識しておくと、将来のバージョンアップ対応にかかる期間を短縮できます。

もう一つの典型的な遅延要因は、メンテナンスウィンドウの候補時間帯について業務部門との合意形成に想定以上の時間がかかるケースです。特に複数の業務部門が同一システムを共有している場合、それぞれの部門にとっての繁忙期や重要な業務タイミングが異なるため、全部門が納得できる停止時間帯を一本化するのに難航することがあります。また、経営層への説明・承認を得るプロセスを後回しにしてしまうと、カレンダー策定がほぼ完了した段階で「その時間帯は困る」という差し戻しが発生し、計画全体を再調整する事態にもなりかねません。対策としては、現状調査フェーズの時点で主要な業務部門の代表者を巻き込み、複数案のメンテナンスウィンドウ候補を早い段階から提示して合意形成を並行して進めること、そして承認プロセスのフローと決裁者をプロジェクトの初期に明確化しておくことが有効です。段階的な承認を得ながら計画を固めていくアプローチが、結果として最短の納期でカレンダーの本稼働にこぎつける近道になります。

定期棚卸を組み込んだ運用開始後の継続サイクル

年間保守カレンダーとメンテナンスウィンドウの設計が完了し運用が始まった後も、定期メンテナンス計画は一度作って終わりではなく、継続的に見直すサイクルを組み込んでおく必要があります。ここでは、運用開始後に発生する2つの継続的なスケジュール項目を解説します。

定期メンテナンス計画には、パッチ適用や点検作業だけでなく、アカウントの棚卸し、ハードウェア・ソフトウェア資産の棚卸し、ライセンスの利用状況の棚卸しといった「定期棚卸」のサイクルも組み込む必要があります。これらは障害対応のように緊急性は低いものの、放置すると退職者アカウントの残存や、EOLを迎えたにもかかわらず利用が続いている機器の見落とし、ライセンス超過による契約違反のリスクにつながります。実務上は、アカウント棚卸を四半期に1回、ハードウェア・ソフトウェア資産棚卸を半期に1回、ライセンス棚卸を年1回というサイクルで年間保守カレンダーに組み込むのが一般的な設計です。この棚卸スケジュールを策定するフェーズは、前述の工程別スケジュールにおける「カレンダー策定・パッチ適用計画フェーズ」と並行して2〜4週間程度で進めることができ、独立した工程として大きく期間が延びることは通常ありません。ただし、対象となるアカウント数や資産点数が多い大企業では、棚卸の実施そのものに時間がかかるため、棚卸専用の実施体制やチェックリストの整備にあらかじめ工数を確保しておくことが望ましいといえます。

定期メンテナンス計画そのものも、一度策定したら固定化するのではなく、年に1回程度は見直しのタイミングを設けることが望ましいといえます。見直しの主な観点は、新たに導入されたシステムの計画への組み込み、EOLが判明した機器・ソフトウェアの更新スケジュールへの反映、そして実際の運用を通じて判明したメンテナンスウィンドウの過不足の調整です。この見直しプロジェクトは、初回の計画策定に比べると対象範囲が限定的であるため、通常は2〜4週間程度で完了します。多くの企業では、決算期や年度の切り替わりに合わせて次年度の保守カレンダーを確定させるスケジュールを組んでおり、このタイミングを定例化しておくことで、計画の形骸化を防ぎながら継続的に予防保守サイクルを回すことができます。

まとめ

本記事では、ITシステムの計画的・予防的な定期メンテナンス体制を新たに整備するプロジェクトについて、開発期間の全体像、現状調査からカレンダー策定・運用フロー整備までの工程別スケジュール、メンテナンスウィンドウ設計と年間保守カレンダーの立て方、そして納期を左右する要因と遅延の典型パターンまでを体系的に解説しました。標準的な期間目安は、小規模で1〜1.5か月、中規模で2〜3か月、大規模で3〜6か月程度であり、現状調査・要件定義、カレンダー策定・パッチ適用計画、運用フロー・リハーサルという3フェーズをそれぞれ2〜4週間で積み上げていくのが基本の考え方です。定期メンテナンスは、事後保守のように発生してから対応するものではなく、あらかじめ「いつ・何を・どのサイクルで手当てするか」を設計し尽くすプロジェクトである以上、EOL情報の網羅的な把握と、業務部門・経営層との早期の合意形成が、遅延を防ぐ最大のポイントになります。自社の定期メンテナンス計画を具体的に検討する際は、まず対象システムの棚卸しから着手し、複数の保守ベンダーやITSMツール提供会社に現状の課題を提示して提案を比較することから始めることをお勧めします。

▼全体ガイドの記事
・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を創業。