IT運用保守の進め方は、全体像の理解から始まり、内製か外注かの判断、ベンダー選定とSLA設計、引継ぎと運用開始へと進みます。
IT運用保守は、インフラからアプリケーションまでを対象に、システムを止めずに動かし続ける継続的な業務です。範囲が広いぶん、順序を決めて一つずつ進めることが大切です。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
IT運用保守の全体像と進め方の基本
IT運用保守を進めるうえで最初に押さえたいのは、「運用」と「保守」の違いと、インフラ領域まで含む広い業務だという点です。
ここを曖昧にしたままベンダーと契約すると、後になって「その作業は契約範囲外です」とトラブルになりやすくなります。だからこそ、対象範囲と業務の定義を正確に理解することが、進め方の出発点になります。
「運用」と「保守」の違いとIT領域での範囲
運用とは、システムを正常に稼働させ続けるための定常業務のことです。
- 運用：サーバーやネットワークの稼働監視、データのバックアップ、アクセス権限の管理、問い合わせ対応などの定常業務
- 保守：障害復旧、アップデート、改修などの変更対応
- インフラ管理：サーバー、ネットワーク機器、ミドルウェアなど基盤全体の維持
運用は、決まったオペレーションを淡々とこなし、システムを「止まらない」状態に保つ役割です。
一方の保守は、障害時の原因究明と、法改正や業務変更への対応を担います。突発的な事象に向き合うことと、システムを「変えていく」ことが中心になります。
IT運用保守では、運用と保守に加えて、インフラ層の維持管理まで対象に含まれます。そのため、アプリケーション単体ではなく、それを動かす基盤全体を視野に入れる必要があります。
この境界線を契約書で明確にしておくことが、トラブル防止の第一歩です。たとえば、「監視は運用の範囲だが、障害発生時の改修は別途見積もり」といった切り分けを最初に合意しておけば、追加費用をめぐる認識のずれを大きく減らせます。
進め方の全体ステップと所要期間
IT運用保守の進め方は、大きく5つのステップに分けて整理できます。具体的には、(1)現状把握と対象範囲の定義、(2)内製か外注かの判断、(3)ベンダー選定とSLAの設定、(4)業務の引継ぎ、(5)運用開始と継続的な改善、という流れです。各フェーズで決めるべき論点は異なるため、順を追って進めることが大切です。
特に外部ベンダーへ委託する場合、選定から契約までには全体で4〜6ヶ月程度かかるのが一般的です。目安は、要件整理に1〜2ヶ月、RFP作成と提案依頼に1ヶ月、評価・選定に1〜2ヶ月、契約調整に1ヶ月という配分です。現行契約の満了が見えているなら、少なくとも6ヶ月前には動き出さないと、選定が間に合わず不本意な契約更新を強いられることになりかねません。
運用開始後も、進め方は終わりません。SLAの達成状況をレビューし、定型作業の自動化や監視ツールの見直しを続けることで、運用品質とコストの両面を改善していくのが理想的な進め方です。
内製と外注の判断と対象範囲の整理
進め方の早い段階で必ず直面するのが、IT運用保守を社内で内製するか、外部に委託するかという判断です。
ここを曖昧にしたまま進めると、中途半端な体制になり、結局どちらのメリットも得られない結果になりがちです。そのため、自社のリソース状況とシステムの重要度を踏まえ、業務範囲を切り分けて判断することが求められます。
内製・外注を分ける判断基準
内製が向いているのは、システムが事業の中核に直結し、頻繁な改修が発生するケースです。自社の業務知識を持つ担当者が継続的に手を入れれば、スピードと柔軟性を確保できます。一方で、24時間365日の監視や夜間・休日の障害対応まで内製しようとすると、人員確保とシフト体制の負担が一気に膨らみます。
外注が向いているのは、定型的な監視・運用業務や、専門性の高いインフラ保守です。特にサーバーやネットワークの常時監視は、専用の運用センターを持つベンダーに委託したほうが、品質とコストの両面で有利になることが多くあります。
判断に迷う場合は、「業務知識が必要な改修系は内製寄り、定型的な監視・基盤系は外注寄り」という切り分けを起点にすると整理しやすくなります。
クラウド時代の責任分界点の決め方
IT運用保守がインフラを含む以上、クラウド利用時の責任分界点は、早い段階で整理しておく必要があります。AWSやAzureなどのパブリッククラウドでは「責任共有モデル」が採られ、事業者が物理基盤やデータセンターを担う一方、OS設定やアクセス権限、データ保護は利用者の責任です。そのため、利用者責任の部分を、自社の情報システム部門が負うか、保守ベンダーに委託するかを明確にすることが求められます。
ここが曖昧だと、障害発生時に「クラウド側の問題だ」「いや設定の問題だ」と押し付け合いが起こり、復旧が遅れます。
これを防ぐ実務的な方法が、RACIチャートの作成です。RACIチャートでは、監視、パッチ適用、バックアップ、障害一次対応といった作業項目ごとに、次の4つの役割を表に割り当てます。
- 実行責任者：作業を実際に行う
- 説明責任者：作業の結果について説明責任を負う
- 相談先：判断の際に相談を受ける
- 報告先：結果を知らされる
誰が何をどこまで担うかを一覧にしておけば、いざというときに迷わず動けます。契約段階でこの責任分界を文書にしておくことは、後々のトラブルを防ぐうえで欠かせません。特にインフラ層は責任の境界が見えにくいため、進め方の早い段階で書面に落とし込んでおくことを強くおすすめします。
ベンダー選定とSLA設計の進め方
外注を選んだ場合、進め方の核心はベンダー選定とSLA（サービスレベル合意）の設計です。ここを丁寧に進めるかどうかで、その後数年間の運用品質と費用が決まると言っても過言ではありません。
評価軸を定めて定量的に比べる手順を踏むことが重要です。「付き合いがあるから」という感覚だけで決めないようにします。
RFPと評価表によるベンダー比較
ベンダー選定は、要件定義からRFI（情報提供依頼）、RFP（提案依頼）、評価表による比較という順で進めます。
RFPには、対象システムの構成、求める監視・対応レベル、希望するSLA、報告体制などを具体的に書き、各社に同じ条件で提案を求めます。条件を揃えることで、提案内容を横並びで比べられます。
評価の際には、押さえておきたいコツが2つあります。
- 価格の配点：20点以下に抑えるのが有効です。比重が高いと、品質の低い安価なベンダーが上位に来て、障害対応の遅さで結局損をします。
- 点数の付け方：「○5点・△2点・×0点」のように差を付けると、評価のブレが減り、本当に差のある項目が見えてきます。
現行ベンダーがいる場合は、あえてそのベンダーもRFPに参加させると効果的です。競争原理が働くことで契約条件が見直され、結果として既存ベンダーが好条件で継続するケースが30〜40%程度の確率で発生します。乗り換えを前提にせず、健全な競争環境をつくること自体が交渉力になります。
SLAの具体値とペナルティ条項の設計
SLAは、サービス品質を定量的な指標で取り決める合意です。たとえば、次のような具体値を定めます。
- サーバー・アプリケーション：稼働率99.8%以上
- 基準応答時間：達成率93%（3秒以内）
- 重大障害：年2回まで
- 障害通知：遵守率100%（発生後30分以内）
- ヘルプデスクの電話応答：応答率97%以上（平均20秒以内）
これらは自治体のガイドラインでも採用されている水準で、民間システムの目標設定の参考になります。
SLAは、目標未達のときの対応まで設計して初めて実効性を持ち、具体的には、ペナルティや改善勧告のルール（SLM：サービスレベル管理）も含めます。ペナルティ条項をベンダーに受け入れてもらうには、達成時のインセンティブ報酬と組み合わせる方法が有効です。
ペナルティ条項の交渉では、次の3点が役立ちます。
- 減額と加算：「未達なら減額、超過達成なら加算」というアメとムチの構造にすると、交渉が前に進みやすくなります。
- 他社の契約事例：交渉の材料にするのも実践的で、「同規模の他社ではこの水準のSLAで合意している」と示せば、過度に緩い条件を防げます。
- 調整を前提にした設計：一度決めて終わりにせず、運用開始後のレビューで実態に合わせて調整する前提で設計するとよいでしょう。
引継ぎと属人化対策の進め方
ベンダーを選定して契約を結んだら、次は業務の引継ぎに入ります。引継ぎは軽視されがちですが、実は成否を分ける重要な工程です。
この引継ぎが雑だと、運用開始直後に障害が起きても誰も対応できないという最悪の事態を招きます。
スムーズな引継ぎのスケジュールと体制
引継ぎは、おおむね2ヶ月程度のOJT期間を設けるのが効果的です。新しい担当者は、現行の担当者が週2日程度サポートに入るなかで、徐々に業務を引き継いでいく形が理想です。工数の目安は、新担当が1.0人月で立ち上がり、現行担当者が並走して知見を伝えるイメージです。
引継ぎ期間中に必ず整備したいのは、運用手順書とシステム構成図です。加えて、障害対応の履歴や、各種パスワードとアクセス権限の管理表も欠かせません。これらのドキュメントが揃っていれば、引継ぎの質は格段に上がります。
逆に、ドキュメントが不十分なまま引継ぎを進めると、現行担当者の頭の中にしかない知識が失われ、後々の運用が立ち行かなくなります。
属人化・ブラックボックス化への備え
IT運用保守における最大のリスクの一つが、属人化です。特定の担当者しか触れないシステムは、その人が退職した瞬間にブラックボックス化し、誰も中身を把握できない状態に陥ります。ドキュメントが皆無のままキーマンが突然退職すれば、明日からのシステム維持すら危うくなります。
こうした事態に備えるには、平時からドキュメントを整備し、担当を二重にしておくことが基本です。それでも属人化したシステムを引き継がざるを得ない場合は、既存のコードや設定を解析するリバースエンジニアリングが必要になります。近年は、AIに既存コードを読み込ませて仕様を推定させる手法も現実的になっており、ブラックボックス化したシステムの解読を省力化できるようになってきました。
進め方の観点では、運用を外部に委託する場合でも、自社が最低限の構成把握とドキュメントの所有権を持ち続けることが肝心です。すべてをベンダー任せにすると、ベンダーへの依存という新たな属人化が生まれてしまうからです。
費用の妥当性と運用品質を高める進め方
進め方を考えるうえで避けて通れないのが、費用の妥当性です。運用保守費用は、システムのライフサイクル全体でみると非常に大きな割合を占めます。
ソフトウェア全体のコストのうち40〜80%、平均すると約60%が運用保守に費やされるとされています。経済産業省の調査でも、従来システムの運用に対する支出は新規構築の約2倍にのぼります。だからこそ、その費用が適正かを見極める視点が欠かせません。
保守費用の妥当性を見抜く監査の視点
「今の保守費用は高すぎるのではないか」という疑問は、多くの担当者が抱えるものです。相見積もりも一つの方法ですが、作業内容の実態は見えにくいままです。より踏み込んだ方法が、作業報告書やサーバーログから実際の稼働時間を割り出し、適正価格を逆算する監査の視点です。
毎月の保守報告書に記載された作業内容と、ログに残る実際のアクセスや作業の痕跡を突き合わせると、契約上の工数と実稼働の乖離が見えてきます。もし月額固定で契約しているのに実作業がごくわずかであれば、契約形態を見直す余地があるということです。こうしたITデューデリジェンスの発想を持つだけで、ベンダーとの費用交渉の説得力が大きく変わります。
なお、新しいベンダーの月額が安くても、移行コストが300〜500万円かかるようなケースでは、5年間のTCO（総保有コスト）で比べると逆転することもあります。目先の月額だけでなく、移行費用まで含めた総額で判断することが、賢い進め方です。
自動化とAIOpsによる運用品質の向上
運用開始後の進め方として重要なのが、定型作業の自動化です。日次のバックアップ確認やログのチェック、定型的なアラート対応などは、スクリプトや監視ツールの仕組みで自動化できる部分が少なくありません。人手を要する作業が減ることで、担当者はより付加価値の高い改善業務に集中できます。
さらに進んだ取り組みが、AIを運用に活用するAIOpsです。大量のアラートをAIに一次切り分けさせ、本当に対応が必要なものだけを人間に通知する仕組みは、運用負荷の軽減に効果があります。ただし、AIOpsはいきなりワークフロー全体を刷新すると現場が混乱するため、スモールスタートが鉄則です。
まずは、アラートの自動一次切り分けといった小さな業務から始め、誤検知のリスクや学習データ整備の手間を確かめながら、適用範囲を広げていくのが現実的です。自動化もAIOpsも、導入そのものが目的化しないよう注意が必要です。あくまで運用品質の向上とコストの見直しのための手段と位置づけ、効果を測りながら進めることが、失敗しない進め方につながります。
契約形態と関連情報・次のステップ
IT運用保守を進める最終段階では、契約形態の選択と契約書の精査が待っています。ここを丁寧に進めれば、運用開始後に「対象外」「追加費用」をめぐるトラブルを未然に防げます。
進め方の総仕上げとして、契約の論点を押さえておきましょう。
準委任と請負の選び方と契約の落とし穴
IT運用保守の契約は、準委任契約と請負契約のいずれかが基本になります。準委任契約は、継続的なサービス提供を約束する契約で、成果物の完成責任は負いません。その契約は、監視や問い合わせ対応など、終わりのない定常業務に向いています。
一方、請負契約は、明確な成果物の完成を約束する契約で、機能改修のように「何を作るか」がはっきりした作業に適しています。契約には、見落とされがちな落とし穴もあります。たとえば、ハードウェア保守でHDDを交換した場合、故障した部品の所有権は保守会社に帰属するのが一般的です。
機密データの確実な破棄を求めるなら、別途その旨を契約に盛り込む必要があります。そのほか、保守契約を準委任契約とすると、印紙税法上の第7号文書に該当せず、収入印紙が不要になるケースが多いという実務上のメリットもあります。こうした細部まで目を配ることが、トラブルのない運用につながります。
関連記事での詳しい解説
IT運用保守をさらに深く検討したい場合は、目的に応じて以下の関連記事もあわせてご覧ください。委託先の比較、費用の相場、発注の具体的な手順を、テーマごとに詳しく解説しています。
・IT運用保守でおすすめの開発会社・ベンダー6選と選び方
・IT運用保守の見積相場や費用・コスト・値段について
・IT運用保守の発注・外注・依頼・委託方法について
・IT運用保守の完全ガイドをご覧ください。
まとめ
IT運用保守の進め方は、全体像の理解から始まり、内製・外注の判断、ベンダー選定とSLA設計、引継ぎを経て、運用開始後の継続的な改善へと進みます。
インフラ層まで含む広い業務だからこそ、運用と保守の境界、そしてクラウド時代の責任分界点を最初に明確にしておくことが、トラブルを防ぐ鍵になります。
特に、ベンダー選定では価格の配点を抑えて品質を重視することが大切です。SLAはペナルティとインセンティブをセットで設計し、引継ぎは2ヶ月程度のOJTとドキュメント整備をセットで進めることも、実務上の重要ポイントです。
さらに、作業報告書やログから保守費用の妥当性を監査する視点を持てば、適正なコストで質の高い運用を実現できます。
本記事で示した手順を一つずつ進めることで、自社の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を創業。