IT運用保守の期間は、選定、引き継ぎ、定常運用の順に進みます。開発と違い、バックアップやバッチ監視、障害復旧が続くうえ、セキュリティパッチや月次報告も必要です。
選定から契約更新までの流れと、移行計画や納期管理の勘所を確認できます。全体像はIT運用保守の完全ガイドもご覧ください。
▼全体ガイドの記事
・IT運用保守の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
IT運用保守における「期間」の全体像
選定では、ベンダーを選んで契約を締結します。立ち上げでは、現行体制から新体制へ、品質を保ちながら引き継ぎます。そして定常運用では、その後も保守を続けます。
見落とされがちなのが立ち上げです。翌日から完璧に回る前提で進めると、引き継ぎ不足で初動が遅れ、ユーザーへの影響が広がるおそれがあります。そのため、各局面に現実的な期間を見込み、全体のロードマップを描いておくことが欠かせません。
新規開発と運用保守における「期間」の考え方の違い
新規開発は、要件を期日までに作り切るプロジェクト型の営みで、要件定義からリリースまでの工程を計画します。
一方、運用保守は、稼働中のシステムを止めずに維持し、変化に追従し続ける継続型です。この違いは、期間や日程の組み方に影響します。
- 立ち上げ期間：新しい体制へ集中的に引き継ぐ期間です。
- 定常対応：継続して行う対応の速さです。
- 更新サイクル：数年おきの契約更新や乗り換えの検討時期です。
運用保守では、立ち上げの期間と定常的な対応の速さという、性質の違う2つを同時に管理します。また、選定から立ち上げ、定常運用、更新や乗り換えまでを一連のライフサイクルとして捉える視点も欠かせません。
選定・立ち上げ・定常運用の3層構造
選定、引き継ぎを含む立ち上げ、定常運用の3層に分けると、スケジュール全体を見通しやすくなります。
- 選定：RFI・RFPの作成から、評価、PoC、契約までを含みます。
- 立ち上げ：契約後に、システムと運用を引き継ぐ局面です。
- 定常運用：月次契約のもとで続く保守対応です。
選定フェーズは、一般に4〜6ヶ月かかります。
立ち上げでは、ソースコードとインフラ構成に加え、運用手順と障害履歴も引き継ぎます。自力で保守を回せるようになるまでの助走期間にあたります。
立ち上げには約2ヶ月（8週間）が推奨されます。1ヶ月で終えようとせず、初期の集中的な工数と、定常運用の負荷を分けて見積もります。
定常運用では、期間よりも応答時間や復旧時間などの対応スピードが管理の中心になります。
ベンダー選定〜契約締結までのスケジュール
新規選定でも既存ベンダーからの乗り換えでも、標準的な選定から契約までの流れを把握しておくと、余裕をもって計画できます。RFI・RFPから評価、PoC、契約までのリードタイムと、契約前に確認する項目を整理します。
RFI・RFP作成からベンダー評価・PoCまでのリードタイム
ベンダー選定から契約締結までは、全体で4〜6ヶ月が標準的です。満了間近になってから始めると期間を確保できず、比較が足りないまま契約を急ぐおそれがあります。
- 要件整理：運用課題と求める保守範囲をまとめる段階です。
- 提案依頼：整理した内容をRFPにまとめて、提案を依頼します。
- 提案評価：複数社の提案と技術検証を比較する段階です。
目安として、要件定義に2〜4週間、RFP作成に6〜8週間、PoCに4〜6週間程度を見込みます。
この期間には、RFIによる市場調査と、提案書の受領・評価が含まれます。プレゼンテーションや質疑応答、価格交渉も、この期間に入ります。
評価基準は、対応範囲やSLA水準を中心に、実績や体制、価格まで先に整理しておくと、選定の長期化を防ぎやすくなります。
契約前に確認すべき契約形態とSLAのポイント
締結直前には、契約形態とSLA（サービス水準合意）を確かめます。継続運用は準委任契約、バグ修正や機能改修のように完了の形がはっきりした作業は請負契約が一般的です。
- 契約期間：1年、3年、5年などの長さ。
- 更新・解約：解約通知の条件。
- SLA：サービス水準の合意内容。
契約には自動更新条項が含まれる場合が多いため、更新時期を締結前に把握しておくことが欠かせません。
特に、月次・障害対応時の稼働率や通知時間、復旧時間といった指標と、未達時のペナルティ条項が明記されているかを確かめます。数値目標やペナルティが契約書にない場合は、実質的にSLAがない状態になり得ます。
保守体制の立ち上げ・引き継ぎスケジュール
契約後は、現行体制から新しい保守体制へ引き継ぎます。1ヶ月程度で済ませると品質を保った移管が難しくなるため、約2ヶ月（8週間）を確保し、4つの段階に分けて進めることが推奨されています。
1〜4週目：システム全体像の把握と保守運用業務の習得
まず、システム全体像を把握することが先決です。全体像が見えないままだと、後半の作業の意味がつかみにくくなります。
- 1〜2週目は、インフラや技術スタックを確認し、環境へのアクセス方法と既存資料を押さえます。
- 3〜4週目は、保守手順や監視ツール、障害対応フローを習得します。
- 過去の障害と対処を調べ、再発時に素早く動ける材料にします。
最初の4週間でシステムの全体像を正確に把握できるかが、後半の実務OJTの質を左右します。
資料が整っていないシステムでは、聞き取りや現地確認に時間がかかりがちです。そのため、余裕を持った日程を組むことが望まれます。
5〜8週目：実務OJT・共同対応から独立運用へ
実務OJTの段階では、新しいチームが現行の担当者と共同で作業に入ります。座学や資料の確認だけでは見えてこない運用の進め方を、実際の作業を通じて身につけます。
- 5〜6週目は、現行担当者の監督のもとで、軽微な障害対応やデプロイを共同で行います。
- 7〜8週目は、監督なしの独立作業をテストする段階です。
- マニュアルを整え、緊急連絡体制の最終確認まで進めます。
8週間の長さは、システムの規模や複雑さ、資料の整備状況によって前後します。属人化が進んで資料が乏しい場合は、長めに見込みます。
引き継ぎ後も、初回の月次定例レビューなどで運用を振り返ります。そのうえで、手順やSLA水準を現実的な内容に調整することが望まれます。
月次・定期保守のスケジュールとSLA・障害対応の時間の設定
立ち上げ後の定常運用では、期間管理の中心が「いつ終えるか」から「どれだけ早く対応できるか」へ移ります。そのため、月次・定期保守の予定を立てるとともに、障害時に許容する対応時間の目安も決めておきます。
月次・定期保守のスケジュール管理
SLAで定めた定常作業には、予定と完了の目標を明確にし、実施状況を管理します。
- バックアップ：日々の定時実行の対象。
- バッチ・帳票：完了時間と配信日程の管理。
- 定期報告：月次の稼働報告。
たとえば、定時バックアップでは完了率100%、バックアップ間隔24時間が基準の例です。バッチ完了や帳票配信については、93〜95%以上の遵守率を指標にします。
停止を伴う保守は、実施のサイクルと時間帯を決め、十分な期間をおいて利用者に通知するルールを設けます。
稼働状況の月次レポートは、翌月月初10営業日以内に提出する日程が一般的です。こうした日程を契約に明記すると、発注者は作業内容、期限、実施水準を把握でき、ベンダーとの認識違いを防げます。
障害対応・緊急対応時のSLA/対応時間の目安
緊急対応の時間目標は、システムの重要度に応じてSLAに定めます。ただし、実際の基準は重要度や契約内容によって変わります。
- 検知・初報：障害発生後30分以内の通知が目安。
- 着手・復旧：応答と復旧の目標時間。
- 窓口・セキュリティ：応答、通知、更新の時間の定め。
初報は、遵守率100%を目指す水準が一例です。自動検知からの通報は、10〜60分以内が目安になります。
着手有無の回答は、1時間以内から翌日までの幅で設定される例があります。復旧時間は、1回の障害につき6時間以内、または4時間以内の復旧率95%以上が目安です。
部品交換は翌営業日〜2時間以内の基準が設定される場合があります。電話の平均応答待ちは20秒以内、保留は1分以内が目安です。
問い合わせの問題解決率は、24時間以内に95%以上が一例です。ウィルス情報の通知は発生後1時間以内、パターンファイルはリリースから6時間以内の更新が目安です。業務への影響に見合う水準を、契約時にすり合わせます。
契約更新・引き継ぎの期間と納期遅延のリスク・対策
保守契約は数年おきに、更新するか乗り換えるかを判断する時期が来ます。現場では、想定外の要因で日程が遅れることもあるため、更新や乗り換えに必要な期間と、遅延の典型的な要因、その対策を押さえておきます。
保守契約の更新サイクルとベンダー乗り換えのタイムライン
保守契約は1年、3年、5年などが一般的で、自動更新条項を含む場合が多くあります。そのため、内容を見直さないまま契約を続けるリスクもあります。
- 契約満了の6ヶ月前には、新しいベンダーの選定を始めます。
- 契約満了の90〜120日前までに、解約通知を行う時期にあたります。
- 選定と契約後の引き継ぎに必要な期間を、あらかじめ確保しておく必要があります。
現体制に不満があっても、満了直前では必要な期間を確保できません。その結果、不本意なまま自動更新を迎える場合があります。
契約内容と満了日はカレンダーで管理し、余裕をもって乗り換えの是非を検討します。
納期遅延の主なリスク要因と対策
運用の立ち上げや保守改修では、遅延につながる典型的な要因を想定し、対策を事前に計画しておきます。
- 資料の不足・不一致：初期のサンプリング調査で確かめる。
- 作業超過：週次定例での進捗の見直し。
- 一斉移行：段階を分けた移行の計画。
設計書や手順書が不足していたり、改修履歴とコードがずれていたりすると、解析や業務の把握が長引きます。その結果、引き継ぎや改修も遅れるおそれがあります。そのため、見積もりや引き継ぎの初期（1〜2週目）に、ソースコメントや修正履歴の有無を確かめておきます。
作業超過が見込まれる場合に備えて、時間単位の精算や日程調整を柔軟に行えるルールを、事前に決めておきます。
範囲の広いシステムを一斉に切り替えると、共通モジュールへの影響調査が漏れることがあります。移行後に障害が多発して、対応に追われるおそれがあります。
契約条件には移行の進め方も含め、部分的なPoC（概念実証）やテストを重ねます。リスクを計画に織り込むことが、納期と品質を守るうえで欠かせません。
まとめ
IT運用保守の期間は、選定4〜6ヶ月、立ち上げ約2ヶ月、定常運用の3層で考えます。それぞれに現実的な期間を見込んで、全体のロードマップを作ります。
選定から契約、引き継ぎ、定期保守までを順に見てきました。障害対応や契約更新、遅延リスクと対策も、あわせて解説しています。
引き継ぎは、1〜2週目の全体把握から7〜8週目の独立準備まで、8週間を4段階で進めます。SLAでは、初報30分以内や復旧4〜6時間以内などを数値で定めて、対応品質を担保します。
契約満了の6ヶ月前から選定を始め、資料不足や一斉移行のリスクも計画に含めます。体制づくりや乗り換えを検討する場合は、契約内容と満了時期、資料の整備状況を点検し、複数の保守パートナーに相談します。
▼全体ガイドの記事
・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を創業。