--- type: guideline title: Step.4 運用・保守の定着と次への備え 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.4 運用・保守の定着と次への備え 運用・保守の事業者とともに計画の策定が終わりました。あとは事業者にお任せしていれば大丈夫。・・・ということはありません。運用・保守を行っていく中では、日々様々な問題が発生しますし、当初計画した内容では足りないことや改善が必要になることもあります。これらの情報を事業者から適時吸い上げ、改善につなげていくには、いくつかのポイントがあります。 このStepでは、運用・保守の作業を効果的に管理していくことで、サービス・業務をより良いものへ導いていくためのポイントについて解説していきます。 ## 運用定例会議を有効活用する 【標準ガイドライン関連箇所：第３編第９章第２節1)ア】 運用・保守フェーズで、ＰＪＭＯが情報システムの状況を確認・把握する場面は、主に運用・保守を実施する事業者が参加して状況を報告する運用保守定例会議が中心となります。しかし、会議に出席して漫然と事業者の報告を聞いているだけでは、事実を捉えて改善を推進していくことはできません。ここでは、運用保守定例会議を有効活用していくためのポイントを見ていきます。 ### 運用保守定例会議で確認する内容を理解する 運用保守定例会議では、運用・保守の計画で定めた報告フォーマットに従って、事業者から基本的には毎回同じ項目の報告を受けることになります。そこでは、外部委託事業者からの報告を受け取るだけではなく、その内容を把握・分析し、根拠が不明なもの、報告が不十分なものは、指摘・再提出も求め、改善活動に繋がる課題や改善点を報告内容から見出し、発注者側がプロアクティブに定点観測する事が大切です。 事業者が「問題なし」と報告している内容でも、「問題あり」に近い「なし」や、状況を把握していないために「なし」と報告しているような場合もあるため、少しでも疑問を感じたら事業者に説明を求めましょう。 また、毎回同じ項目が定期的に報告されるという特徴から、長期間にわたる推移を把握することも可能です。事業者はある時点で切り取った報告を行いますが、その情報を線でつなげて分析し改善に活用しましょう。 いくつかの事例を見ていきましょう。 - 事例9-6 実際のＰＣ故障率を確認し保守コスト低減に成功

事例：実際のＰＣ故障率を確認し保守コスト低減に成功

ある府省では、職員が使用するＰＣの故障に備えて、機器の保守事業者と高額な数年単位の定期保守契約を締結していました。

ある年度において、運用・保守コストの削減を行うため、ＰＣ故障時に保守事業者を利用した回数について運用保守定例資料を過去から遡って確認しました。その結果、故障率は低く、年間数回しか保守対応を利用していないことが判明したため、定期保守契約の終了を契機に、スポット対応の保守契約に変更し、大幅な保守費用の削減を実現しました。

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

この事例では、定期保守に加入していた場合、保守事業者を利用する回数が多くても少なくてもコストには影響がないため、運用保守定例資料でその回数が報告されていたとしても、あまり注目はされません。しかし、別の視点でその数字を分析することにより、異なる目的で活用できることがわかります。
運用保守定例会議では、情報システムのハードウェア、ソフトウェアに関する報告だけではなく、ヘルプデスク等の「人」を対象にした運用に関する報告も行われます。 - 事例9-7 評価指標の分析結果をユーザ満足度向上につなげる

事例：評価指標の分析結果をユーザ満足度向上につなげる

ある府省の情報システムでは、ヘルプデスクの評価指標に従来の問い合わせ件数や期限内回答率に加え、回答に至る経緯をオペレーターがその場で即答した「自己解決」と管理者へのエスカレーションを経由した「折り返し連絡による回答」に分類して、サポートデスクの質の評価を行っています。

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

サービス開始当初の運用保守定例会議で報告された自己解決率は60%程度でしたが、ヘルプデスクへその数値を共有し、エスカレーションされた40%の内容を分析した結果を基にマニュアルへの追記やＦＡＱへの掲載、オペレーターの教育等の対策を行うことにより、現在の自己解決率は90%程度まで向上しました。

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

ヘルプデスクの自己解決率が向上したことで、利用者からの様々な問い合わせにも即時に回答できるようになるとともに、ヘルプデスクからのエスカレーションを受けて、調査等を行っていた職員の負荷も軽減することができました。
- 事例9-8 データの取得粒度を変更したら事象が異なって見えることもある

事例：データの取得粒度を変更したら事象が異なって見えることもある

日中はオンラインサービス、夜間はバッチ処理が中心というある省の業務システムにおいて、夜間のＤＢサーバとバッチ処理を行っているサーバのＣＰＵ使用率が、高い状態となる日が頻繁にあると報告されていました。（下図）

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

この情報システムは、安定運用のために、十分な余力を確保して複数台のサーバを稼働させており、サーバのＣＰＵ使用率の報告からも、適切なサイジングがされているものと捉えていました。ただし、潤沢なサーバ構成としていたために、高い維持コストが課題となっており、見直しが可能か検討することとなりました。

そこで、日単位の平均とピークのみで報告されていたＣＰＵ使用率を、１分単位のヒートマップで分析を行ったところ、特定の時間で数分程度ＣＰＵ使用率が上昇しているものの、大半の時間の使用率は10%未満であることが把握でき、ピーク時の負荷の分散を検討しました。（下図）

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

一分単位の詳細な単位でＣＰＵ使用率を把握した結果、ＣＰＵ使用率がピーク近くになるのは、ごく僅かな時間帯にすぎないことがわかりました。また、この時間帯に動いている処理は、運用等を目的としたバッチ処理であり、処理時間が多少長くなっても業務への影響が全くないことがわかりました。

この分析により、サーバ構成についてもっと踏み込んだ削減が可能であることが判明し、コスト削減に寄与することができました。
これらに共通していることは、「プロジェクトの目標を達成する」「サービス・業務をより良くする」という視点に基づいて、それらの判断や改善に必要となる事実を正しく理解する。という姿勢です。 以下に確認のポイントをまとめます。 運用保守定例会議での確認のポイント - 指標値等の基準を明確にし、基準を満たしているのか、満たしていないのか、今後どうなる見込みなのかを確認する。 - 定常どおりの内容よりも、特筆すべき事項を事業者から引き出す。 - 定点観測だけでは問題を見落とす可能性がある。時間軸を変えたり、集計の仕方を変えたりする等、様々な視点から状況を捉える。 - 根拠が不明なもの、主観的なものには注意が必要。エビデンスを求める。 - ピーク性や今後のイベント等を踏まえて、リスクを確認する。 - 発生した課題だけではなく、累積している課題に対する対応状況も確認する。 - ライセンスや保守期限等を確認し、次年度以降の予算要求に備える。 ## 変更を管理し改善活動等の初動を楽にする 【標準ガイドライン関連箇所：第３編第９章第２節】 情報システムを長期間運用していると、運用・保守の作業や機能改修によって、情報システムにたくさんの変更が行われます。これから改善活動や機能改修を検討しようとしたときに初めに行うことは、設計書等から現状の情報システムがどのようになっているかを確認することです。しかし、その設計書は本当に最新の情報システムを反映したものでしょうか？ Step.3-1-H．「運用・保守における変更管理を理解する」で説明したとおり、最新の設計書や情報システムがどのような理由でいつ変更されたかは、運用の変更管理の作業で管理されます。 なお、変更管理の方法には様々なものがありますので、プロジェクトの事情に合わせて、効率的に管理できる方法を検討してください。 変更の管理方法に関する検討ポイント - 設計書やソースコード等は変更管理ツールでバージョン等を一元管理することが一般的である。それらの変更管理ツールを、発注者側で管理するか、運用事業者が管理するかは検討する。ライブラリ管理チームを組んで管理することも効果的である。 - 環境の事情等で発注者側が最新の変更管理ツールにアクセスできない場合、最新の設計書等の授受方法やタイミングを明確に定める。 - 設計書やソースコード等のバージョンと変更の事由や本番環境への反映記録等の一貫して追跡できるように記録をつける。これらを一貫して管理するツール等も存在するため、導入を検討する。 ## 情報システムで起こった事実を蓄積する 【標準ガイドライン関連箇所：第３編第９章第２節】 運用・保守作業により事業者からデータを収集できました。そのデータを目の前にして、どうしたらよいか困っていませんか？改善を検討するに当たって、本当にその情報だけで十分でしょうか？ここでは、改善を検討する際のデータ収集に関するノウハウを見ていきます。 ### 運用・保守の範囲にとらわれず、意味のある情報を取得する 利用者からの問合せは、実際に対応する人やその結果も様々だと思いますが、どんな問い合わせが、いつ、どこから発生し、どのような結果となったかの一連の流れを記録することを推奨します。これにより、あとで集計したり、分析したりすることが可能となり、どういった問題・ニーズがあるのかを、アンケート等で再収集しなくても取ることができます。 これは、運用・保守業務として、運用・保守事業者に求める業務とは異なります。こちらはシステム側面での問い合わせ・問題・インシデント管理であり、先に挙げたものは業務側面でのものです。 相互に連携する部分もあるため、運用・保守業務の管理情報も併せて収集して、一貫して記録し、集計・分析することで効果をあげることができます。また、分析結果から得られた情報を、利用者が参照できるＦＡＱへ追加し、業務マニュアル等の改訂に活用することも可能です。改善を検討する際は、定点の情報だけでなく、一連の流れに沿った視点も分析してみてください。 - 事例9-9 業務運用に貢献するレポート機能の追加

事例：業務運用に貢献するレポート機能の追加

実践ガイドブック「第４章 Step.4 業務の現状把握」で、ある経費積算業務における時間を要している処理業務の、原因分析に関する事例で紹介した「へび図」の作成方法にも一工夫しています。

当初この情報システムには、分析するために必要なデータを抽出する機能が存在せず、職員が手作業で１件ずつ確認しながら資料を作っていたため、非常に煩雑で手間が掛かっていました。

そこで、業務の作業実績の分析は今後も継続的に必要と判断し、情報システムを改修して、必要な情報が記録され、かつ、１ボタンでデータが取得できる「へび図抽出機能」を追加しました。

その結果、この業務の一連の処理状況が、職員に負荷をかけることなく、ほぼ毎月正確に把握できるようになりました。

![](../assets/ds-120-ch09-image19.png)
### 情報システムの活用状況を詳細に把握し提供する機能を棚卸しする 情報システムは、提供する機能数が多く・複雑なほど、運用・保守コストが増大する傾向があります。特に、長く運用している情報システムでは機能の追加・改修を重ねられていることが多く、その傾向が顕著に現れます。 このことを防ぐためには、定期的に機能の棚卸しをすることにより、肥大化を防ぐことが有効です。 棚卸しをするに当たり、利用者へのアンケート等で業務における利用状況を把握する方法があります。さらに、機能ごとの利用ログを情報システムから取得し、分析することでより厳密に利用状況を把握することも可能です。 これらの情報を踏まえて、機能の廃止・縮小対象の検討がより具体的に行えるため、定期的な棚卸しを行うようにしてください。 - 事例9-10 機能単位で情報システムの利用状況を可視化

事例：機能単位で情報システムの利用状況を可視化

運用フェーズにおける各府省が共通で利用する政府情報システムの機能が、実際の業務において、どの程度活用されているか把握し、情報システムの見直しを行うことになりました。

そこで、情報システムが提供している機能を全てリストアップし、府省ごとに利用状況の調査を行い、当該機能を利用して「業務を全て遂行」「他の手段も併用」「全く利用していない」の３段階で回答するよう依頼しました。

回答結果を、機能、府省単位で色分けして可視化したところ、全く利用されていない機能や、ばらつきのある機能などが明確になりました。

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

この調査結果と、情報システムから取得した利用ログの集計結果の値を用いて、「全く利用していない」機能は廃止の検討を、「他の手段も併用」は、機能改善検討の対象として効率的に抽出することができました。
### 情報システムのログやトランザクションデータから改善のための情報を取得できるようにする 情報システムのログやトランザクションデータは、「情報システムが何をいつどのように処理したか」を記録として残すことに主眼がおかれがちですが、指標値や改善を検討するための情報を残すという視点も必要です。この視点がないと、運用や保守の作業で分析するための情報を取得することがとても大変になったりします。 - 図9-5 目標・指標・データの関係性のイメージ ![](../assets/ds-120-ch09-image21.png) しかし、要件定義や設計・開発の時点では、機能を提供することに目が行きがちで、実績に基づいたモニタリングまでを意識した検討ができている情報システムが多くないのが現実です。 運用や保守の作業でデータが取得できない場合やデータ取得に工数が膨大にかかるような場合、情報システムでデータ取得が容易にできないかを検討してみましょう。これらの検討は、標準ガイドライン「第８章 サービス・業務の運営と改善」での検討を踏まえて決定します。 情報システムから正確で詳細なデータを手に入れたことで、効果的な改善を行えた例がたくさんもあります。 なお、サービスや業務の目線で、ログから判別できる指標には、次のようなものがあります。これらを参考に、情報システムで取得できるデータがないかを見直してみてください。 - 参考9-5 サービス・業務の視点で取得可能な指標の例

参考：サービス・業務の視点で取得可能な指標の例

ログからデータ取得できるが、機能単位等の集計が難しいもの。これらは、機能ＩＤ等の判別情報をログに付加することで、集計や分析が容易になる可能性があります。

  • 期間（滞留状況）

  • 頻度（業務ピーク、業務効率）

  • 利用件数、利用率

  • 情報提供数

嗜好等を含むため、通常の情報システムで取得が難しいもの。これらを取得するためには、アンケート機能等のデータ取得用の機能が必要になります。

  • 選好（Ａ/Ｂ分析）

  • ニーズ分析（相関）

  • 満足度

設計時に考慮が漏れがちなもの。何をどのように記録するかを検討し、記録する機能を作成します。

  • 不正防止（個人情報は指定された用途以外に記録してはいけません）

  • オープンデータ の利用数
情報システムを長期間運用していくと、データ量が増大したり、アクセス数が変化したりすることによって、情報システムのパフォーマンスが悪化することがあります。例えば、データベースの性能一つをとっても、チューニングの良し悪しでレスポンスは何十倍も変わることがあります。 このような場合に、日常的な保守業務の一環としてレスポンスやバッチ処理時間の性能指標を測定して、悪化傾向が見えた場合は、それがシステム障害として顕在する前に対策を行うことが重要です。 ### 運用・保守実施記録を適切に保管する 発注者が運用・保守事業者に対して一定期間の運用・保守実施記録の保管を指示していない等、情報システムのアカウントの管理を運用・保守事業者に丸投げしている場合には、いざという時に必要な記録が参照できず、不正、障害等の原因が究明できない等の問題が生じる可能性があります。 上記のリスクを低減する方法として、情報システムのログやトランザクションデータを適切に取得・保管すること等が挙げられます。 - 注記 特権IDとは、 情報システムを運用・管理するために必要なすべての操作権限を持つ管理者用アカウントのこと。WindowsのAdministratorやLinuxのrootなどが該当する。悪意を持った人が特権IDを使用した場合、不正やセキュリティ上のリスク等が懸念されるため、発注者の責任の下、特権IDの取扱いには十分に注意が必要である。 機密性・完全性・可用性の観点から特に重要な情報を取り扱う場合においては、発注者が特権ID管理を適切に実施することが重要で、事業者の作業計画に基づいて作業の度に特権IDを発注者が事業者に付与する運用とするのが望ましいです。 アカウントの管理や情報の保管は、情報システムの特性に応じて、「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」や特定非営利活動法人日本ネットワークセキュリティ協会の「【改定新版】特権ID管理ガイドライン」を参考にしながら、事前に十分に検討した上で、実施してください。 - 注記 「【改訂新版】特権ID管理ガイドライン」