--- type: guideline title: Step.3 運用・保守の計画 source: デジタル庁 ds_code: ds-120 category: government-system updated: 2025-06-19 source_url: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/9ab95eed/20250619_resources_standard_guidelines_guideline_06.zip --- # Step.3 運用・保守の計画運用・保守を担当する事業者が決まったら、事業者とともに調達仕様書で示した内容から、運用・保守の詳細な作業内容や実施方法等を検討し、計画書と実施要領として明文化します。これらは、運用・保守の作業はこの計画に基づいて実施することとなるため、作業が漏れたり不十分だったりすると後々問題を引き起こすこともあります。ここでは、運用・保守をトラブルなく円滑に進めていくための計画策定のポイントを、紹介していきます。 ## 運用と保守の計画を作成する【標準ガイドライン関連箇所：第３編第９章第１節2)】この実践ガイドブックには、別添として、運用計画書、運用実施要領、保守計画書、保守実施要領のひな形を示しています。 - 様式例9-1 運用計画書、運用実施要領、保守計画書、保守実施要領のひな形

様式例：運用計画書、運用実施要領、保守計画書、保守実施要領のひな形

運用計画書、運用実施要領、保守計画書、保守実施要領のひな形を本章別紙としてまとめています。

![](../assets/ds-120-ch09-image4.png)　![](../assets/ds-120-ch09-image5.png)

![](../assets/ds-120-ch09-image6.png)　![](../assets/ds-120-ch09-image7.png)

このひな形はあくまで例示ですので、運用の内容に応じて記載内容を個別に追加、変更して構いません。ひな形を見ると、何をどのようなレベルで書くべきかの参考になると思います。以降では、運用計画書・運用実施要領を作成するときに、特に注意が必要なポイントについて説明していきます。項目の詳細な説明は、ひな形を参照してください。 - 注記システムプロファイルとは、「標準ガイドライン　別紙５　システムプロファイルに係る定義について」に基づいて定義する情報システムの信頼性の水準のこと。システムプロファイルに応じた運用・保守レベルにする運用や保守の体制や作業は、サービス・業務の内容や重要度等によって、適切なレベルを設定し、適切な費用で効果的な運用・保守となるように心掛けましょう。しかし、適切なレベルとはなんでしょうか？運用や保守のレベルの基準となるのは、要件定義書で定められた「システムプロファイル」です。サービス・業務を開始した直後から運用や保守が安定するまでの一定期間は、予期せぬ障害に備えて手厚い運用・保守体制をとることがしばしばあります。この手厚い体制を維持する期間は情報システムによって様々ですが、システムプロファイルで示した運用・保守レベルを維持できる最低限の体制を基準として、プロジェクトの状況に応じて定期的に見直しを行い、徐々に適切なレベルの保守・運用にしていくように調整していきましょう。 ### セキュリティ関連作業を定期的に確実に実施するセキュリティ管理に関する要件は、非機能要件で示され、運用・保守フェーズでは、その方針に沿ってアプリケーションやインフラでの対策が講じられている状態にあります。昨今のセキュリティに対する脅威は日々増大しており、運用・保守フェーズでは、設計どおりの対策が維持できるよう、日々確実に作業を続ける必要があります。以下に定期的に実施すべき作業の例を挙げます。 - セキュリティインシデント発生時の記録、対応、影響範囲の把握 - 脅威と修正パッチ適用計画の立案・調整 - シグニチャ、ブラックリスト（ホワイトリスト含む）更新 - ＯＳ及びプラットフォーム等の緊急修正計画の立案・調整 - セキュリティ向上のための業務改善と利用規制検討 - 中長期的プラットフォーム改善に向けた、システム構成要素のリスク評価 ### プロジェクトの目標や指標の評価に必要なデータは必ず取得する Step.2-2-Bの「指標の基礎データを誰がどのように集めるかを明確にする」のとおり、目標や指標値を定期的にモニタリングできるよう、運用作業として取得しなければいけないデータについては、以下の観点で運用の計画書と実施要領に明確に記載しましょう。 - 表9-3 運用計画書、運用実施要領におけるデータ取得に関する記載内容例

記載箇所		記載内容
運用計画書
	作業概要	データ取得作業として、取得するデータの種類、取得の条件、集計や加工の方法等を記載します。
	スケジュールに関する事項	いつ、どのタイミングでデータ取得作業を行うかを記載します。月次や四半期の期末月のように定期的に取得し、運用保守定例会議等で報告とデータの提出を求めます。
運用実施要領
	作業管理	報告の形式や報告の仕方を記載します。

運用作業で取得したデータは、標準ガイドライン「第８章サービス・業務の運営と改善」で使用する以外にも、今後の機能改修やサービス・業務の見直し時の分析データとして使用できるよう、報告資料だけではなく、データ自体を加工や集計が可能な形式で受け取るようにしましょう。そのためには、運用計画書及び運用実施要領に記載された内容から、要員に依存せずにデータを取得できるよう、データ取得手順書の作成を運用事業者に求めてください。また、これらのデータを保存する手段や期間に関する考慮も重要です。数年に渡る傾向分析等に必要な情報は長期間保存が必要ですが、週次で集計値を算出した後は不要となる詳細データは、無闇に保管するとストレージ等の無駄が生じます。クラウドサービスを利用している際はデータ保存量がコストに直結する場合もあるため、迅速かつ頻繁に参照したいデータは取り出しやすい媒体に保存し、緊急性のないデータは外部媒体に保管する等の工夫を行いましょう。 ### 非機能要件に関連するデータを網羅的に詳細に取得するサービス・業務を円滑に運営するためには、標準ガイドライン「第５章要件定義」で定めた非機能要件に従って、情報システムを安定的に稼働させ続けることが必要になります。このためには、現時点で情報システムが非機能要件で定めた指標値を満たしているかを確認することはもちろんですが、将来的に要件を満たせない、維持コストが増大する等のトラブルが発生する予兆を捉えることが、とても大切です。また、日次や月次等の定点的な観測だけではなく、確認したい内容ごとにどのような間隔でデータを取得するかを検討し、取得できる仕組みを設け、必要な情報が必要な粒度で取得できるように備えておきましょう。非機能面のチェックは様々な観点がありますが、次にあげるポイントはとても重要ですので、必ず確認できるように、運用作業に持ち込んでください。非機能要件に関連するデータの確認ポイント - **データ量** データベースやファイルシステムの使用率等を時系列で確認し、傾向から将来容量が枯渇するおそれがないかを確認します。 - **処理時間** 機能単位、時間単位等の複数の視点からレスポンス時間等の処理時間を確認することにより、安定的に処理を行えているか、処理が遅くなる傾向等が見られないかを確認します。また、バッチ処理時間も時系列で確認し、将来的に完了予定時刻に遅れる予兆等がないかを確認します。 - **リソース状況** ＣＰＵやメモリ等が異常な状態になっていないか（高負荷状態が続いている、ほぼ使用していない等）を確認します。これらも、サーバ単位、時間単位で詳細に取得して、傾向を確認します。これらのデータを蓄積していくことで、情報システムを更改する際に、サーバの構成・スペック等の精査が簡単に行えるようになります。また、クラウドサービスに求めるサービスレベルの検討にも活用できます。これらの情報についても、報告資料だけではなく、データ自体の提出を求めるようにしましょう。 ### 会議体は目的を明確にして必要最低限に抑える運用・保守フェーズは、複数の職員や事業者が関わるため、会議体の種類がどうしても多くなる傾向があります。中心的な役割を担うＰＪＭＯの職員や事業者の担当者は、会議出席に拘束されてしまい、本来行うべき作業に手が回らないという状況に陥りがちです。そのような状況にならないために、会議体の目的を整理し、必要な出席者を事前に選抜するようにしましょう。以下に主要な会議体の種類と主な目的を示します。 - 表9-4 会議体と主な目的・内容例

会議名称		主な目的・内容
定例会議
	日次会議（朝会夕会を含む）	関係者同士の作業確認、段取り打ち合わせシフト間（夜間から日中等）引継ぎを既定のシートをベースに行う
	月次会議	事業者が発注者に対して行う報告など事業者同士の情報連携及び業務手順改善（例：基盤運用事業者、ＡＰＰ保守事業者、センターオペレーション事業者、ヘルプデスク事業者及び発注者の５者運用調整会議）
	セキュリティ対策会議（月次～四半期）	インシデント発生状況の共有脅威と修正パッチ計画の調整シグニチャ、ブラックリスト（ホワイトリスト含む）更新調整ＯＳ及びプラットフォーム等の緊急修正計画調整セキュリティ向上のための業務改善と利用規制検討・承認
	業務・システム運用改善会議（１～２回／年）	上級マネージャ出席（発注者側、事業者側双方）の下で、業務及びシステム運用についての協議を行う。業務仕様に「改善提案」を盛り込んであれば、この会議体で提案する。職員側と事業者側の幹部を出席者とする「ステアリング・コミッティ」とすることも可能。
非定例会議
	個別課題について解決するための会議	一般的には発生都度開催することが多いが、当該業務及びシステムの価値に関わる重要テーマがあれば、そのテーマを冠として分科会形式で開催することが望ましい。例）「システムサービス改善運動」を冠テーマとして、「利用者サービス向上分科会」、「業務ミス根絶分科会」、「マニュアル・手順書改善分科会」」等を適宜開催。
	システム移行会議	業務システム全体を改修する場合、基盤を乗せ換える場合、一部出先事務所（又は事業所）にシステムを導入する場合等で実施。
	次年度リソース計画会議	システム基盤リソース及び保守運用に係る人的リソースの検討を行う。利用実績や実測レスポンス、定例処理の時間等のエビデンス情報に基づき、今後の必要リソースを算出していく。

会議体選択の考え方 - **日次会議**は、情報や状況把握の正確性確保と関係者間の問題解決事案の引継ぎが主目的である。短時間で効率的に実施することが肝要である。この会議では、運用状況・保守作業状況及び問題解決の進行状況が取り上げられるので、できる限りＰＪＭＯが参加することが望まれる（毎日出席はできなくても週に１回ランダムに出席することを推奨する）。 - **月次の定例会議**は、できる限り開催する。ＰＪＭＯ側と事業者側の双方の責任者が出席し、マネジメントレベルの状況判断、方針及び約束等をオーソライズする場とする。できれば、調達時点で必須報告事項を仕様として提示することが望まれる。 - **セキュリティ対策会議**は、インシデント事案の最終評価・対応方針の周知、確実な脆弱性対策実施及び運用上の懸念事項の吸い上げが目的である。目安として利用者が数百人以上のシステムにおいては、四半期に１度程度は開催することが望まれる。 - **業務・システム運用改善会議**は、運用関連業務の受託事業者が「仕様書：改善提案業務」の成果発表を行う位置づけとすることを推奨する。この会議では、事業者から出てくる改善提案にＰＪＭＯが誠実に対峙し、協働して前向きな改善に持ち込めるかどうかが重要。 - **その他非定例会議**は、必要の都度開催することとなる。ポイントとしては、事前に会議の目的と到達目標、テーマ及び各参加者の役割を周知しておくとことが望まれる。 ### 定例会の報告フォーマットを指定して、効率性を上げる運用や保守を行う事業者は、多くの場合、独自の報告フォーマットを持っています。「自社フォーマットを使用することで効率的に運用・保守の報告を行える」という主張は理解できますが、ＰＪＭＯが報告してほしい情報がそのフォーマットに含まれていなかった場合、その情報を把握できない可能性があります。また、複数の情報システムを有する大規模プロジェクトにおいて、複数の運用・保守事業者が活動を行う場合に、それぞれの報告フォーマットが異なったらどうなるでしょうか？横並びでの確認が困難になりますし、分析が非常に難しくなり改善の妨げになるかもしれません。これらを防ぐために、事業者からの報告フォーマットはＰＪＭＯが指定したものを使用するよう、調達仕様書であらかじめ方針を示しておきましょう。運用・保守事業者の決定後、詳細な報告項目について更に調整を行います。この際、報告書作成に特定のツールを利用しているため、指定したフォーマットで報告することが著しく非効率になる等の場合は、ＰＪＭＯが求めた内容が必ず含まれるよう、事業者にフォーマットを確認し、盛り込むべき内容を合意してください。 - 事例9-3 定例会の報告フォーマットを統一し報告内容の分析向上

事例：定例会の報告フォーマットを統一し報告内容の分析向上

ある府省の情報システムには、複数の運用・保守事業者が関わっており、効率的な運用保守定例会の運営が課題となっていました。

そこで、他の情報システムや過去の報告書等を参考に、発注者側で報告フォーマットを検討し、各事業者にはそのフォーマットに沿った報告を求めました。

一部の事業者は、既存の報告書を作成するツールが存在していたため、難色を示しましたが、報告項目や単位を揃える方針で調整を行い、合意しました。

その結果、各事業者からの報告内容が同じ軸で効率的に比較・分析できるようになりました。

![](../assets/ds-120-ch09-image8.png)

### 運用・保守の工数を把握し、人件費をモニタリングする情報システムに係る経費は、情報システムを構築するまでの費用よりも、運用・保守フェーズ期間にかかる費用の方が多いことがよくあります。運用や保守のどの作業にどの程度の工数がかかっているかを定期的に把握していなければ、費用はかかったが求めた内容があまりできなかった、という結果にもなりかねません。運用・保守フェーズの作業はとかく事業者にお任せになりがちで、報告内容もざっくりと「作業一式」で済まされてしまうこともありますが、管理に必要となる詳細な報告を求めましょう。事業者は個別のエンジニアの工数管理は労務管理上実施しているはずですので、求めれば応じられる管理情報は持っています。実際の工数を正確に把握していれば、的外れな対策を行うリスクもなく、効率的にコスト削減を行うことができます。低コストで効果的な運用・保守に改善していくためにも、作業ごと、要員ごと等の詳細な工数データを取得できるよう、事前に事業者と調整し、運用の作業の一部として計画に盛り込み、運用保守定例会議で報告を受けるようにしましょう。 - 事例9-4 運用・保守の稼働工数を実績に基づいて分析し削減に成功

事例：運用・保守の稼働工数を実績に基づいて分析し削減に成功

ある府省で、情報システムの運用・保守費の見直しを行うことになりました。作業区分ごとに工数の確認を進めようとしたところ、運用報告書に記載されている作業内容は、記載レベルが大まかで計画値もなく、実績値との比較分析が困難な状況でした。

このため、運用報告書で報告する作業内容を詳細化し、それぞれ計画と実績工数を明示するよう変更しました。

この結果、項目ごとに実際に必要な工数が明らかになり、過剰な工数を削減することができました。

![](../assets/ds-120-ch09-image9.png)

運用・保守フェーズに入る前は、実績値がないため想定の値で工数を見積りますが、稼働２年目以降は実績値が取得できるため、計画工数と実績工数の比較を通して適切な工数を確保するよう調整しましょう。

この事例のような考え方は、運用・保守フェーズで実施する機能改修にも応用できます。例えば、機能改修を行う際に、改修による影響度を調査した上で、発注者と受注者でテストのスコープや実施方法等の方針を協議することで、効率化又は削減できる作業を特定できるようになり、工数を削減することができる場合があります。特に、運用・保守フェーズでは、障害発生時に次回以降同じ障害を繰り返さないためにテスト項目が追加されたり、改修を行わない部分に対するリグレッションテストを大量に実施することでテスト項目が増加したりして、多大なテスト工数が必要となる場合があります。その対策として、過去のテストシナリオの再利用やテストの自動化等を行うことで、テストの効率性を高めることができます。加えて、機能改修の特性を踏まえて、見積りの精査、不要と思われるテスト項目の除外、機能改修による影響範囲の特定などを実施することで、過剰な工数を削減することができます。また、改修規模や機能改修にかかった実績工数を報告させるようにすることで、次回以降に同様の規模の機能改修を行う際に、その工数の妥当性を確認し、工数削減につながる場合があります。 - 事例9-5 ハードウェア保守費を実績に基づいて分析し削減を実現

事例：ハードウェア保守費を実績に基づいて分析し削減を実現

ある府省の利用者が全国にわたる大規模情報システムにおいて、業務・システムの見直しを行うプロジェクトを実施しました。このプロジェクトでは、見直しの目的にシステム経費の削減を掲げ、まずは現状調査を詳細に行いました。

従来のサーバ構成指針は以下に示す内容でした。

個別業務の継続性を重視し、サーバを機能ごとに分散させ、十分な冗長性を持たせる。
将来の大幅な需要拡大予測に基づきシステム規模を設計
業務ピーク時を含めた最大ＣＰＵ使用率が50%となるように設計

現状調査の結果、ＣＰＵ使用率が低調なサーバが存在することが明らかになり、保守ノウハウの蓄積により、一定程度のサーバ削減を行っても安定稼働が担保されると判断し、以下に示す対策により、サーバ台数の大幅削減を実現し、見直し後の情報システムにおいて大きな成果を上げました。

![](../assets/ds-120-ch09-image10.png)

![](../assets/ds-120-ch09-image11.png)

![](../assets/ds-120-ch09-image12.png)

この調査の過程で、メモリ使用率はピーク時に90%近くに達することがある一方で、CPUはピーク時でも10%台と低位にとどまっていることがわかりました。

そこで、システム更改後にサーバ構成を見直すだけでなく、現時点においても見直しが行えないか検討を行いました。具体的には、ほとんどのサーバは2CPU構成となっていたため、稼働中のサーバからCPUを１つずつ取り去ることのコストメリットを検討しました。

その結果、ソフトウェアの保守体系がCPU単位での課金となっており、CPUを撤去することで、撤去作業のための経費を考慮しても、現在の保守料金を大きく減額できることが判明しました。また、業務要件に照らし合わせてCPUを一部撤去しても業務上の影響は発生しないことが確認できたため、実際にCPUを一部撤去し、見直し後の情報システムの稼働を待たずに、稼働中の情報システムのソフトウェアの保守料金を削減することもできました。

### 運用・保守における変更管理を理解する運用・保守フェーズでは、基本的にはその時点で提供しているサービス・業務を変えることなく、情報システムを維持し続ける活動を行います。現状を維持するためには、変えないことが最も安全な方法で、何か変更するということは、何らかのリスクを伴います。現状維持するだけであっても、最低限必要となる変更作業は存在するため、その作業を適切に管理し、安定運用を継続する「変更管理」の活動は、とても重要です。運用と保守で行う変更管理の対象は、大きく２種類に分かれます。変更管理の対象の分類 - **作業に係る情報への変更管理** 運用の要件定義書、調達仕様書、運用計画書、運用実施要領、作業手順書等。 - **情報システムを構成する資産等に対する変更管理\** 設計書、ソースコード、マニュアル等。ライブラリ管理と呼ばれることもある。特に、後者については、運用と保守で管理する内容が重複することもあり、混乱しがちですが、以下のような違いがあります。運用と保守の変更管理の違い - 運用の変更管理では、**誰が修正するかに限らず、情報システムを構成する全ての資産とそれに対して行われる全ての変更を管理する**。つまり、これを確認すれば、情報システムに対して行われた全ての変更について、「いつ」「誰が」「何の理由で」「何を」変更したかを確認することが可能。 - 保守の変更管理では、**保守事業者の保守対象となる設計書やソースコード等に関する変更を管理する**。運用の変更管理は、情報システムの全ての変更情報を管理する必要があるため、保守事業者が複数いる場合であっても、統一的に管理する必要があります。そのため、変更フローを明確に定めて、情報システムに変更を行う可能性のある全ての事業者に対して、周知徹底する必要があることに注意してください。以下に、参考として、変更管理のフローの例を記載します。 - 図9-4 変更管理のフローの例 ![](../assets/ds-120-ch09-image13.jpg)