--- type: guideline title: Step.2 運用・保守を開始するための事前準備 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.2 運用・保守を開始するための事前準備情報システムが完成したら、サービス・業務を滞りなく提供していくために情報システムをきちんと運用・保守していかなければいけません。しかし、情報システムの運用や保守は、専門的な内容が多いため、気が付いたら膨大な費用がかかり、プロジェクトの目標も未達成だった、ということもしばしばあります。でも、安心してください。運用・保守を開始する前に、いくつかのポイントを押さえて事前に計画すれば、このような事態を防ぐことができます。では、より良い運用・保守を行うための事前準備のポイントを、紹介していきます。 ## 「運用と保守」の位置付けを理解する【標準ガイドライン関連箇所：第３編第９章第１節】情報システムの「運用」と「保守」はよく耳にする言葉ですが、その目的や違いを知っていますか？また、運用・保守とよく混同する活動に「サービス・業務の運営」や「機能改修」もあります。これらの違いや関連性を理解していないと、責任範囲や実施内容が曖昧になり、効率的で効果的なプロジェクトの運営を行っていくことができません。ここでは、運用・保守の位置付けを説明していきます。 ### サービス・業務をより改善するための活動を行う情報システムの開発と移行が完了して新たなサービス・業務を開始した時点は、プロジェクト当初に掲げた目標・目的を達成するためのスタート地点に立ったにすぎません。また、サービス・業務を支援する情報システムも、その時点で100％の出来ではなく、発展途上の状態である場合もあるかもしれません。リリースまでは想定に基づき業務要件、機能要件を定めてきましたが、運用・保守フェーズに入った後は、実際の利用状況等を継続的にモニタリングして、利用者の行動等を把握することが可能となります。これらをしっかりと把握して、より効果的・効率的なサービス・業務に改善していくことにより、国民や業務実施部門をはじめとした政府職員にとって、よりメリットをもたらす情報システムに成長させることができます。それでは、効果的なサービス・業務を実現するためにはどうすれば良いのでしょうか。効果的なサービス・業務を実現するためには、運用・保守フェーズにおけるヒヤリ・ハット（インシデント）を多く見つけ、改善を繰り返すことが重要です。労働災害の経験則として、ハインリッヒの法則があります。これは、1件の重大事故の背景には、重大事故に至らなかった軽微な事故が29件あり、更に事故には至らなかったが事故寸前の、ヒヤリ、又はハッとしたインシデント（ヒヤリ・ハット）が300件隠れているというものです。また、重大事故を防ぐための考え方として、ドミノ理論があります。ドミノ理論では、重大事故に至るまでの過程をドミノのように連鎖的なものとして考えます。その過程で発生するヒヤリ・ハットを見過ごすことなく、適切な対応策を講じることで、ドミノ倒しの連鎖を止め、重大事故を防ぐことができます。 - 図9-1

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

ハインリッヒの法則

これは情報システムの運用・保守作業においても同じです。例として、情報システムの改修等により操作手順に変更が生じたものに対して、政府職員の操作マニュアル等のドキュメントを適切に管理していなかったために、誤った作業を実施してヒヤリとしたインシデントを考えてみましょう。この時は、業務影響を及ぼすような事故はなかったかもしれません。しかしながら、国民へのサービス提供に関与する作業を実施していた場合は、提供しているサービスに不具合が生じる等、重大事故につながるかもしれません。ヒヤリ・ハットはそのままにせず、ドキュメントの構成管理の手順を見直し、類似のインシデントに繋がらないように再発防止策を講じることで、未然に重大事故を防ぐことができます。情報システムの運用・保守フェーズにおいては、設計・開発フェーズのテスト不足が原因でインシデントが起こることが多くあります。サービス・業務に影響を与えるような重大事故に繋げないためにも、発生したインシデントを記録し、将来的な機能改修やシステム更改に当たってテストシナリオ等を検討する際のインプット情報にし、テストの有効性を高めましょう。また、サービス・業務の効率化によるコスト削減は、関係する人員削減とイコールではありません。より人間にしかできない業務に人的リソースを振り分けることで、今まで手が回らなかった業務に対応できるようになるため、より良いサービス・業務を実現していくことができます。運用・保守の心得 - 運用も保守も、サービス・業務をより良くするための活動の一部。 - 目標、指標に関連する情報をモニタリングして、改善につなげる。 - ヒヤリ・ハットに着目し、改善を繰り返す。 - 効率化は人員削減によるコスト削減につなげるだけなく、他の活動に活かしてさらなる価値を生み出す。 ### 情報システムの運用と保守の活動を理解する情報システムの「運用」も「保守」も、根本となる目的は同じです。シンプルに表現すると、稼働している情報システムを「健全に保って活動を続けさせる」ことです。運用と保守の目的 - サービス・業務の提供価値を高め、継続して行えるようにする。 - この目的を達成するために情報システムを安定稼働させ、一連の作業が滞りなく進むように維持する。その共通の目的のもと、運用と保守には次のような違いがあります。運用とは何か運用とは、上記の目標を達成するための「情報システムの機能を利用者に提供し続けるための活動」です。情報システムの稼働状態を維持するための作業が主となりますが、情報システムを相手にするだけではなく、ユーザサポートのように「人」を相手にする作業もあります。作業を大きく分類すると以下に示すものがあります。詳細は、標準ガイドライン解説書「第９章運用及び保守」の表9-1を参照してください。 - 表9-1 運用作業の分類

作業分類		概要
定常時対応
	監視作業	情報システムの稼働状況や利用状況、情報セキュリティ、不整合なデータの有無等の監視を行います。異常の発生を即座に、又は事前に検知することで、安定的な情報システム稼働を維持するための活動です。
	情報システム維持作業	バックアップや計画停止、プログラムリリース、一括データ処理、不整合なデータの補正等の情報システム維持関連作業とそれらに係る管理を行います。情報システムを長期間安定して稼働させるために必要となる活動です。
	ユーザサポート業務	ヘルプデスクやコールセンターの運営、操作研修、利用者の情報メンテナンス等の情報システムの利用者に対するサポートを行います。利用者が正しく情報システムを利用し、円滑にサービス・業務を遂行することに寄与する活動です。
	データの収集と報告	作業実績や障害実績等のデータを収集し整理し、ＰＪＭＯに報告する作業です。
障害発生時対応
	情報システム維持作業	不具合等のインシデントに対する受付、切り分け、報告等の一連の対応の管理、リリースやバックアップからのきり戻し等の復旧作業を行います。また、時には誤った情報が記録されたデータベースを修復することもあります。

保守とは何か保守とは、「情報システム（インフラ含む）が予定された機能・レベルを提供するように、情報システムそのものを維持するために情報システムに対して働きかける活動」です。作業を大きく分類すると以下に示すものがあります。詳細は、標準ガイドライン解説書「第９章運用及び保守」の表9-2を参照してください。 - 表9-2 保守作業の分類

作業分類		概要
定常時対応
	ハードウェアの保守	定期点検、予防保守等、ファームウェアのアップデート等を行います。ハードウェアの異常の確認や予防を行う活動です。
	ソフトウェア製品の保守	製品のアップデートファイルの運用事業者への提供、製品への問合せの対応等を行います。
	システムリソース配分の調整	過去の業務処理記録やこれからの業務処理見通しに応じて、システムのハードウェア（論理的なハードウェアを含む）資源の稼働中プロセスへの配分を見直して、システムの処理能力を向上させます。
	保守作業共通の作業	システムの利用者と調整して保守作業計画を策定します。また、システム監査に対するヒアリングや情報提供等を行います。
	データの収集と報告	作業実績や障害実績等のデータを収集し整理し、ＰＪＭＯに報告する作業です。
障害発生時対応
	アプリケーションプログラムの作業	アプリケーションプログラムの不具合に対する原因調査、プログラムの修正・テスト等を行います。
	ハードウェアの保守	ハードウェア異常に対する原因調査、ハードウェアの修理や交換等を行います。
	ソフトウェア製品の保守	ソフトウェア製品の不具合に対する原因調査、ソフトウェア製品の修正・テスト等を行います。

- 参考9-1 クラウドサービス上のシステム運用において取得すべきデータ

参考：クラウドサービス上のシステム運用において取得すべきデータ

クラウドサービスを使ったシステム運用では、あらかじめ設定を行うことによって様々なログを取得できる仕組みが整備されています。また、クラウドサービスの各種リソースの使用状況等を把握するために、様々なメトリクスデータ（監視対象としての定量的データ）も取得できるようになっています。

そして、これらのデータを適切に取得することで、情報システムの稼働状況を的確に把握し、問題発生時に原因究明を効率的に行えるようになります。

どのようなログやメトリクスデータを取得するかは、各プロジェクトの状況やシステム特性によって異なります。一般的な例を示しますので、取得すべきデータが漏れていないか確認してください。

取得するログの例

ログの種類	説明
アクセスログ	Webサーバ等へのアクセスログ
アプリケーションログ	アプリケーションが出力するログ
OSログ／コンテナログ	OSやコンテナ等が出力するログ
ネットワークログ	ファイアウォール、ロードバランサ等が出力するログ
APIログ	公開APIへのアクセスログ
DBログ	データベースが出力するログ
ID管理ログ／認証ログ	ID管理や認証に関するログ
クラウドAPIログ	クラウドを操作するAPIの利用履歴のログ
クラウド設定履歴ログ	管理者等によるクラウド設定内容のログ
クラウド脅威検知ログ	クラウドに対する脅威検知のログ

取得するメトリクスデータの例

ログの種類	説明
CPU利用率	サーバ、コンテナ等におけるCPU利用率
メモリ利用率	サーバ、コンテナ等におけるネットワーク利用率
IOアクセスレート	サーバ、コンテナ等におけるIOアクセスレート
ストレージ利用率	サーバ、コンテナ等におけるストレージ利用率
リクエスト数	利用者からのWeb、APIリクエスト数
レスポンス	利用者からのリクエストに対するサーバ側レスポンス時間
ネットワークスループット	ネットワーク上でのスループット
ネットワークアクセス数	ネットワーク上でのアクセス数
DBアクセス数	データベースへのアクセス数
SQLパフォーマンス	SQL処理のレスポンス

当然のことながら、最初に設定を行っていなければ、後から遡及してログやメトリクスデータを取得することは困難です。システム障害が発生してからログ等のデータがないことに気づいても、後の祭りです。

運用設計時にこれらのデータ取得要否について十分検討するとともに、運用業務の中でも取得したデータ内容を確認しながら取得対象や取得方法（取得タイミング、保管期限等）を適宜見直してください。

　また、「第8章 4 業務改善に向け日常業務の事実を蓄積する」に記載したように、ログ等のデータから、情報システム利用者の特性やアクセス頻度、滞留時間や入力エラーの発生等を把握・分析し、サービス改善に向けた検討材料とすることも重要です。

システム運用で取得したデータに基づいて、システムの継続的な改善を行うとともに、サービス・業務改革（BPR）が行えるように準備を行ってください。

### 運用・保守は他の様々な活動と連携し、並行で実施する運用と保守の活動は他の活動のいろいろな作業と関係しています。最も関係性があるのは標準ガイドライン「第８章サービス・業務の運営と改善」で、運用・保守とは表裏一体との関係にあります。これらの関係を図9-2に示します。 - 図9-2 標準ガイドライン本編における運用及び保守活動と他の活動との関係 ![](../assets/ds-120-ch09-image2.png) 「サービス・業務の運営と改善」の活動で、ＫＧＩ・ＫＰＩがどの程度満たされたかを判断するための指標を算出する作業を行いますが、この作業に必要な根拠情報を提供するのが、「運用と保守」の重要な作業の一つです。根拠情報には、システムログやトランザクションデータ等の情報システムで取得可能なものと、サポートデスク等で人が介在して取得するものがあります。そのため、これらの情報取得作業は、運用保守作業の一つとして確実に作業に組み込み、必要な情報が必要なタイミングで取得できるように整備しておく必要があります。 - 事例9-1 調達要件に改善提案業務を明記し、運用開始後の改善活動を円滑に

事例：調達要件に改善提案業務を明記し、運用開始後の改善活動を円滑に

ある府省では、管理している情報システムの一つで、運用保守業務の調達仕様に「年に２回の改善提案」を盛り込んでいます。具体的には、半年間の課題整理、今後の運用・保守業務改善の方向性（事業者の意思表示を含む）及び全体課題と個別課題に係る改善提案について、文書を作成してプレゼンテーションを求めています。

当初契約締結時には、運用保守事業者側に戸惑いも見られましたが、①提案内容のメリットの大小は問わないこと、②費用がかかる案件であれば別途予算化を検討すること、を確認して事業者側の理解を得て進めることとなりました。

改善提案制度の導入によって、職員と事業者に以下のような仕事への取り組み方の変化がもたらされました。

運用保守事業者の考え方が、利用者目線になっていった。すなわち、安定稼働、使いやすさ、丁寧な説明を重視するように変化した。
年２回の改善提案があることで、ＰＪＭＯ職員と事業者のコミュニケーションが活性化した。
ＰＪＭＯ職員の業務と情報システム運用との関係に対する理解が深まったことから、仕事の計画と実施管理の水準向上につながり、情報システムそのものの機能改善や次期情報システムの企画業務に時間を割く余裕が生まれた。

この事例において、いわゆるＳＬＡ（サービス水準契約）に基づくペナルティやインセンティブは設けていませんが、年２回の改善提案業務をきっかけとして、事業者と職員の協働によるＳＬＭ（サービスレベルマネジメント）が行われています。

上記のような例もそうですが、運用・保守を実施していく中で発生した問題に対して、運用・保守の範囲だけでは解決できないこともあります。そのような場合は、標準ガイドライン「第８章サービス・業務の運営と改善」に課題を集め、サービス・業務の内容も含めて改善を検討します。（※これはＩＴＩＬが定める問題管理に相当します。）また、「サービス・業務の運営と改善」で集めた課題に対して、既存の機能の修正や新たな機能の開発が必要になることがあります。これらは「機能改修」と呼ばれます。プログラムに修正が入る点では「保守」と似ていますが、保守における修正は、サービス・業務の開始時点で定められた設計どおりに動作させるためのものである点に注意してください。 ### 運用・保守に、自動化の仕組みを取り入れる情報システムの運用・保守は、従来は人が目視確認や手作業で実施してきましたが、人による体制で運用・保守を行うと人件費がかさみ、運用保守のコスト増となります。現在では、通常システム運用管理ツール等を導入して自動化による効率化を図っています。ただ、これらのツールを導入してライセンスを購入したにもかかわらず、実際にはこれらのツールの機能をほとんど使っておらず、結果として人手による運用作業が多く残っているケースも多くみられます。以下に、より効率の良い自動化を進めるために検討すべきポイントと例をまとめます。自動化を進めるためのポイントと例 - 手順が定まっている作業の自動化セキュリティパッチアップデート、プログラム更新、データ更新等を自動的に行うプログラムや設定を準備しておく事で正確かつ実施効率を上げる方法です。 - 定量的な監視設定と通知・連絡の自動化アクセス量が制限値を超えた時や、サーバのメモリやディスク容量等があらかじめ設定した値を超えた時、あるいはネットワークや機器の故障があった際にメールやSMS、電話等で自動的に関係者に通知・連絡する方法です。従来はメールのみによる通知が主でしたが、SMSや電話での通知を取り入れることで、より素早い連絡とその後の対応ができるようになります。 - 経験者の目視に頼っていた判断・制御の自動化アクセス状況やサーバリソースのグラフの異常傾向の検知、不審な大量アクセス等の検知をAI等の機械学習を利用して実施し、初期判断（運用・保守担当者へのエスカレーション）に用いる方法です。上記「定量的な監視設定と通知・連絡の自動化」のような設定値の超過ではなく、時間推移による急激な変化によるリスクを判断するという「経験者の暗黙知」を自動判断にすることで稼働時間を抑えられるようになります。また、検知後の制御・対応も自動実施することも可能になります。 ### システム間での運用統合を検討する各プロジェクトで複数のシステムを運用している場合に、それらの運用業務には重複する作業が多数発生していることがあります。このような場合に、複数システム間での運用を統合することも検討してみたいですね。運用経費の総額を減らすということも一つの目的ですが、それだけではなく、個々の職員が運用作業に振り回されている現状を改善できるかもしれません。運用業務の統合に際しては、なるべく統一したオペレーションが行えるように検討・調整することが大事です。たとえば、ハードウェア、ネットワーク、アプリケーションプログラム等のそれぞれの層ごとに、発生している運用業務を把握してみましょう。すると、監視内容については各システムでほとんど似通っている一方で、障害を検知した後のエスカレーション先はそれぞれ異なっているなど、共通点と相違点を区別して把握することができます。このように、運用業務の現状を把握できれば、統一したオペレーションへの第一歩を踏み出すことができるかもしれません。また、統合運用を実現する際に、運用管理システム（ジョブ管理、システム監視、構成管理等）がばらばらだと共通化できる作業が少なくなってしまいます。運用管理システムを統一することもまた一つの検討事項です。 - 事例9-2 複数システム間でのシステム監視業務統合

事例：複数システム間でのシステム監視業務統合

ある府省では複数のシステムを保有しており、それぞれ異なる事業者が同じような監視内容を異なる監視ツールで個別に監視していました。報告も個々の事業者から別々に受けており、同じような内容でありながらツールの違いから、情報の見え方もそれぞれ異なるため、報告を受ける職員の負担となっていました。また、システムごとにそれぞれの事業者から報告を受けていて効率的ではありませんでした。

こうした状況を改善するため検討を行った結果、監視ツールを統一し、まとめて監視することにしました。具体的には、それぞれのシステムに共通、固有の監視項目を抽出して網羅性を確保し、監視ツールを１つの製品に統一しました。

その結果、課題となっていた職員の負担や非効率が改善されただけでなく、保有するシステム群全体の状況を横断的に監視できるようになったことで、府省全体のシステム最適化を進めるための基礎情報を得られるようになりました。

## 作業責任を正しく理解しトラブルを防ぐ【標準ガイドライン関連箇所：第３編第９章第１節】運用・保守の活動やそれに係る「サービス・業務の運営と改善」等の活動には、様々な関係者が関わります。それぞれの作業内容や責任範囲が曖昧になってしまうと、作業漏れや関係者間の意思疎通が不十分となることによる新たな問題が発生するリスクが増大します。悪くすると、情報システムの安定的な稼働への問題発生、改善活動の停滞などを招き、プロジェクトの目標達成に影響が出てしまいかねません。ここでは、運用と保守に関係する関係者と各々の作業責任内容を定めて、円滑に作業を進めていくためのポイントについて、ご紹介します。 ### 外部委託事業者へ依頼する作業の内容を明確にする「運用」及び「保守」に係る作業は、基本的に外部事業者に委託して実施します。その理由は、内容が専門的であることや、手順に沿った定型かつ大量な作業が多いため、ＰＪＭＯや業務実施部門の職員が実施すると、かえって非効率になる可能性があるためです。「餅は餅屋」の言葉どおり、外部事業者と役割を適切に分担することにより、発注者側の職員は、業務の質の向上やコスト削減等の、本来職員が行う事業者では実施できない作業に、より注力することができます。外部事業者に依頼する作業や役割は、調達の段階で調達仕様書に明記しておく必要があります。事業者確定後にこれらの詳細を詰めようとすることは、トラブルの原因となりますので、注意してください。それでは、調達仕様書にはどのような項目を定義すればよいでしょうか？基本的には、定型的な作業は標準ガイドライン「第７章設計・開発」において、運用設計・保守設計として洗い出されているため、それがそのまま調達仕様書の付属資料として、作業要件になります。しかし、次に示すような項目は、重要な内容にもかかわらず見落とされがちなため、明記されているかもう一度確認してみましょう。 - 注記ＣＳＩＲＴとは、シーサート (CSIRT: Computer Security Incident Response Team) とは、コンピュータセキュリティにかかるインシデントに対処するための組織の総称。 - 注記システムリストアとは、何らかの原因で不具合が発生した情報システムを、正常に稼働していたある時点の情報システムの状態に戻すこと。 - 注記ブラックリスト・ホワイトリストとは、フィルターをかける対象を「リストに記載されていたらＮＧとする」ものがブラックリスト、「リストに記載されているものだけをＯＫとする」ものがホワイトリスト。 - 注記シグニチャとは、ウイルス対策ソフトやファイアウォール等、コンピュータウイルスの進入を防ぐソフトウェアにおいて侵入を検知するために識別しているコンピュータウイルスなどに含まれる特徴的なデータの内容や、攻撃者が持つ特徴的な受信データのパターンのこと。 - 参考9-2 運用契約（要件・仕様検討時）の忘れ物チェックリスト

参考：運用契約（要件・仕様検討時）の忘れ物チェックリスト

大分類	中分類	作業項目
業務管理関係	報告内容と書式	日報、月報業務改善提案書インシデント（基盤・業務ＡＰ、セキュリティ）
業務管理関係	要員管理	入館証名簿と手続（名前、所属、住所など）体制表の提出（真の会社名必須）要員交代協議・承認手順
作業要件関係	情報セキュリティ関連作業	シグニチャ、パターンの更新（ウイルスソフトなど）ＯＳ、ミドルウェア、言語システムの脆弱性解消のためのアップデート（想定頻度も記述）ブラックリスト・ホワイトリスト登録（ＩＰ、ドメインなど）
	緊急対応	バックアップ情報からのシステムリストア定期作業以外の緊急セキュリティ作業（上述セキュリティ関連作業、ログ等の調査）
	ドキュメント保守	運用手順書関係のメンテナンス保守・修理作業結果と履歴管理基盤工事図書の最新化アプリケーション構成管理情報の最新化

以下は契約時点で要件化が必要であれば記述を検討してください。

ネットワーク増設・設定変更作業（技術支援、設計、設定工事）
情報セキュリティインシデント時の役割（情報連携作業、ＣＳＩＲＴ報告・支援待機など）
ヘルプデスク、ネットワーク管理事業者、業務システム開発事業者との連絡関係

特に、構成管理については運用を積み重ねる中で、ドキュメント間の不整合が発生しがちです。大規模なシステムでは、このようなドキュメント管理に専門の要員（ライブラリアン）を配置して、ドキュメント管理ルールに則って正確な記載を保つ努力をすることもあります。

ドキュメント間で矛盾した記載にならないか、同じ用語が違う意味で用いられていないか、それらは一見些細な事に見えますが、このような記載の「ゆれ」によって関係者が誤解をした結果、大きなトラブルにつながってしまう事例もあります。

なお、用語の意味や定義をそろえるために用語辞書を整備することもひとつの対策です。ただし、用語辞書を作成した後に内容の更新を怠ってしまわないように、メンテナンスを行う体制を維持することも重要です。

構成管理の品質を高めることに留意しましょう。

### 指標の基礎データを誰がどのように集めるかを明確にする指標に用いるデータ取得のための作業は、標準ガイドライン「第８章サービス・業務の運営と改善」の作業と密接に関連します。サービス・業務の運営と改善では、プロジェクト計画書で定めたプロジェクトの目的・目標が実現できているかに関して、いくつかの指標（ＫＰＩ）を用いて判断し、業務の改善や見直しを行います。指標（ＫＰＩ）は、基礎値の組み合わせによって、表されます。指標（ＫＰＩ）の例指標の基となる各種データは、種類ごとに、取得先、取得手段、取得頻度等について詳細な検討が必要です。代表的なデータとして、情報システムが稼働している際に作り出されるログやトランザクションデータと呼ばれるものが挙げられます。これらは、職員が自ら取り出せるもの、運用事業者に依頼しないと取り出せないもの等、データの取得には制約が発生します。前者であれば、事前に技術的な経験のない職員でも容易に取得できるように、取得手段が機能化されている必要があり、後者は対象と取得手順が明確に定義されていなければ、定常的な運用作業として継続できません。これらを踏まえて、取りこぼしが発生しないよう、必要なデータ項目を事前に把握するとともに、外部事業者に取得を求める場合は調達仕様書に明記しておきましょう。 - 参考9-3 主な指標とデータの関係例

参考：主な指標とデータの関係例

No	指標名	計算式	単位
1	利用者満足度	「「満足」とした回答数」／「全有効回答数」×100	％
2	相談窓口の平均対応時間	相談窓口の平均対応時間	分／回
3	相談窓口における苦情・相談解決率	「相談窓口で解決した件数」／「全苦情・相談件数」×100	％
4	相談窓口におけるエスカレーション件数の逓減率	(「前年度エスカレーション件数」－「当該年度エスカレーション件数」)／「前年度エスカレーション件数」×100	％／年
5	窓口申請に要する費用	窓口申請に要する費用	円
6	オンライン申請に要する費用	オンライン申請に要する費用	円
7	職員満足度	「「満足」とした回答数」／「全有効回答数」×100	％
8	職員苦情・相談件数	職員苦情・相談件数	件
9	職員苦情・相談解決までの平均時間	苦情・相談解決までの平均時間	分／回
10	削減業務処理時間	「現行業務処理時間」－「業務・サービス改革実施後の業務処理時間」	時間
11	削減経費	「業務・サービス改革実施前の経費」－「業務・サービス改革実施後の経費」	円
12	開発経費削減率	(「基準開発経費」－「当該開発経費」)／「基準開発経費」×100	％
13	運用経費削減率	(「基準年度年間運用経費」－「当該年度年間運用経費」)／「基準年度年間運用経費」×100	％
14	保守経費削減率	(「基準年度年間保守経費」－「当該年度年間保守経費」)／「基準年度年間保守経費」×100	％
15	業務・サービス委託経費削減率	(「基準年度年間委託経費」－「当該年度年間委託経費」)／「基準年度年間委託経費」×100	％

指標は、いざ算出しようしたときに、算出根拠となる基礎情報が不足していることが判明し、その情報を追加入手するためには想像以上に困難であることに気付くことがあります。特に、ある分析結果からより多角的な分析が必要になった場合、特定の情報の付加情報として「区分」や「属性」等、より詳細な情報が求められることがあります。このような情報は、事前に取得・保管する仕組みが備わっていなければ、その時点から遡ってデータを取得することが不可能なこともあります。また、取得可能だったとしても、多くの手間を必要とする場合もあり、そのようなデータは頻繁なモニタリングが敬遠され、結果として指標が適切な時期に算出できず、対策が遅れてしまうことにもつながりかねません。運用・保守を開始してからトラブルとならないよう、事前に具体的なモニタリングの方法や役割分担を検討し、事業者に依頼する場合は調達仕様書に作業内容を明記してください。また、平均値を指標とするときは、集計対象の種類や内容が同種のもので平均値を算出するようにし、異なる性質のものを混合して値を算出しないようにしましょう。 - 参考9-4 運用・保守だけでは指標を算出できないケース

参考：運用・保守だけでは指標を算出できないケース

設定した指標値

指標名	計算式	単位
オンライン利用率	オンライン申請件数／総申請等件数×100	％

このように設定された指標では、申請全体に対するオンライン申請の割合が把握できます。一方で、効果的な改善活動に資する活動として例えばオンライン申請率を向上させようとした場合、このオンライン申請を実際に実施したユーザの区分（本人・代理人の区分、個人・法人の区分等。）ごとの割合を分析して、区分に応じた対策を講じる必要があります。

ユーザ区分ごとの申請件数は、「オンライン申請件数」は、申請情報にあらかじめユーザ区分を加えておけば、運用作業で取得できますが、「総申請等件数」は業務実施部門から取得するかもしれませんし、全ての申請を管理している別の情報システムから取得しなければいけないかもしれません。また、取得先全てにおいてユーザ区分の情報を持たせ、かつ、ユーザ区分の種類を統一する必要もあります。

### 業務実施部門を含めた運用体制を確立する情報システムの各種テストが完了し、後は本番リリースを迎えるだけという状態に準備が整い、運用・保守フェーズをお任せする事業者が確定したら、サービス・業務を利用者に提供するまであと一歩です。運用・保守フェーズでは、最初に司令塔となるＰＪＭＯを含んだ運用統制を行うチームを構築し、プロジェクトを管理していくことになりますが、円滑な運営を進めるための注意点があります。それは、業務実施部門（主に当該情報システムの業務統括部門）とのコミュニケーションと役割分担です。業務実施部門には、情報システムを用いて実際に業務を行う職員が集まっています。この多くの職員に、プロジェクトの目的・目標を理解してもらうことは、標準ガイドライン「第８章サービス・業務の運営と改善」で触れたとおりですが、運営に入ってからは次の点に気を付けて実施してください。業務実施部門との役割分担・コミュニケーションで気をつける点 - ＰＪＭＯには、業務実施部門の担当者が参画するよう、組織を組成する。運用・保守に関わる定期報告会では業務実施部門の担当者（代表者）が参加した上で、常に情報を共有できるようにする。 - 日常的に、現場業務で発生した問題や状況に関する情報がＰＪＭＯに伝わるよう業務実施部門の担当者とのコミュニケーションルールを明確にしておく。業務実施部門とＰＪＭＯとの関わりについては、プロジェクト立ち上げ時のＰＪＭＯの組成にまで遡ります。そこでは、基本的にＰＪＭＯには制度所管部門及び情報システム部門とともに、業務実施部門の担当者が参画することが望ましいことが言及されています。これまでは、新しいサービス・業務の要件を定めるために、業務実施部門の職員から意見・要望を収集することが主でしたが、サービス・業務の運営フェーズになると、コミュニケーションの流れが、収集だけではなく、業務実施部門からの情報提供が加わります。利用者からの意見や要望を把握するためには、最も接点が多い業務実施部門の職員からの情報提供が欠かせません。また、運用・保守で発生した報告内容には、利用者からの問い合わせや発見した不具合、不具合修正に伴う情報システムの稼働停止連絡等、様々な情報が含まれます。これらを業務実施部門と共有することにより、業務実施部門の中で必要な調整や対策を行い、今後問題を引き起こすリスクを低減させることが可能となります。そのためにも、プロジェクトの情報が集まるＰＪＭＯへの参画、定期報告会への必要な人員の出席、代表者から業務実施部門の関係者全員への情報伝達手段などを、運用及び保守が開始する前に取り決めておきましょう。 ### 障害発生時の役割分担に注意する障害が発生しない情報システムは、ほぼありません。大切なのは、障害が発生した際に適切な対応を取ることで被害を最小限に留め、暫定対策から恒久対策を実施し、将来にわたって同じ又は同じような障害を発生させないようにすることです。そのためには、障害対応という急を要する状況の中でも、ＰＪＭＯ、運用の事業者、保守の事業者、その他の関係者が適切な役割分担の下に協働して対応を進めていくことが必要になります。運用と保守の事業者が異なる場合や運用・保守それぞれを複数事業者で分担して実施する場合もあり、役割や責任が曖昧になることで対応が遅くなってしまうことや被害が拡大してしまうことも少なくありません。まずは、障害発生時における運用と保守の基本的な役割分担を理解しましょう。この考え方を踏まえた上で、プロジェクトの体制や特性を踏まえて、詳細を決めていきます。極端な例ですが、ＰＪＭＯの体制が１名の場合は、24時間365日稼働するサービスへの対応は十分にできません。どのようなタイミングで障害が発生するかは予想できないからです。深夜や休暇取得中等、ＰＪＭＯが対応できない状況が存在することを前提に、運用事業者・保守事業者と役割分担を検討する必要があります。 - 図9-3

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

障害発生時の運用と保守の役割分担の例