第９章 運用及び保守
デジタル・ガバメント推進標準ガイドライン 実践ガイドブック
第９章 運用及び保守
目次
Step.1 運用及び保守活動全体の流れ
Step.2 運用・保守を開始するための事前準備
１ 「運用と保守」の位置付けを理解する
A. サービス・業務をより改善するための活動を行う
B. 情報システムの運用と保守の活動を理解する
C. 運用・保守は他の様々な活動と連携し、並行で実施する
D. 運用・保守に、自動化の仕組みを取り入れる
E. システム間での運用統合を検討する
２ 作業責任を正しく理解しトラブルを防ぐ
A. 外部委託事業者へ依頼する作業の内容を明確にする
B. 指標の基礎データを誰がどのように集めるかを明確にする
C. 業務実施部門を含めた運用体制を確立する
D. 障害発生時の役割分担に注意する
Step.3 運用・保守の計画
１ 運用と保守の計画を作成する
A. システムプロファイルに応じた運用・保守レベルにする
B. セキュリティ関連作業を定期的に確実に実施する
C. プロジェクトの目標や指標の評価に必要なデータは必ず取得する
D. 非機能要件に関連するデータを網羅的に詳細に取得する
E. 会議体は目的を明確にして必要最低限に抑える
F. 定例会の報告フォーマットを指定して、効率性を上げる
G. 運用・保守の工数を把握し、人件費をモニタリングする
H. 運用・保守における変更管理を理解する
Step.4 運用・保守の定着と次への備え
１ 運用定例会議を有効活用する
A. 運用保守定例会議で確認する内容を理解する
２ 変更を管理し改善活動等の初動を楽にする
３ 情報システムで起こった事実を蓄積する
A. 運用・保守の範囲にとらわれず、意味のある情報を取得する
B. 情報システムの活用状況を詳細に把握し提供する機能を棚卸しする
Step.5 運用・保守の改善と業務の引き継ぎ
１ 適切な時期に的確に改善を実行する
２ 要員の交代で情報が欠落しないようにする
事例・参考の一覧
事例：調達要件に改善提案業務を明記し、運用開始後の改善活動を円滑に
事例：複数システム間でのシステム監視業務統合
参考：運用契約（要件・仕様検討時）の忘れ物チェックリスト
参考：主な指標とデータの関係例
参考：運用・保守だけでは指標を算出できないケース
様式例：運用計画書、運用実施要領、保守計画書、保守実施要領のひな形
事例：定例会の報告フォーマットを統一し報告内容の分析向上
事例：運用・保守の稼働工数を実績に基づいて分析し削減に成功
事例：ハードウェア保守費を実績に基づいて分析し削減を実現
事例：実際のＰＣ故障率を確認し保守コスト低減に成功
事例：評価指標の分析結果をユーザ満足度向上につなげる
事例：データの取得粒度を変更したら事象が異なって見えることもある
事例：業務運用に貢献するレポート機能の追加
事例：機能単位で情報システムの利用状況を可視化
参考：サービス・業務の視点で取得可能な指標の例
事例：インシデントの判断基準及び役割分担を見直し
事例：担当者の交代により次年度で必要な作業が漏れてしまった
Step.1 運用及び保守活動全体の流れ
運用・保守は、事業者に任せておけば大丈夫だと思っていませんか？
運用・保守の目的は、情報システムの安定的な稼働を維持していくことのみならず、利用者へのサービスを継続的に改善することや運用コストを低減していくことも含まれます。そのためには、運用・保守の個々のプロセスについて適切なモニタリングを行い、事業者と協働して見直すことにより、改善につなげていくとことが必要不可欠です。
ここでは、運用・保守の専門家ではない職員が、運用・保守を適切に管理し、より良いサービス・業務につながるように改善を推進していくために必要となる具体的な知識やノウハウを説明します。
本ドキュメントの構成は、次のとおりです。
Step.2 新しいサービス・業務に合わせた運用・保守を開始するための事前準備
より良いサービス・業務を提供していくために必要となる運用・保守の前提知識や心構えを説明します。
Step.3 運用・保守の計画
運用・保守を実施する事業者が決まったら、最初にすべきことは契約期間中の実施計画を立てることです。事業者はこの計画に基づいて作業を実施するため、計画が不十分だと後々問題となることがあります。ここでは、トラブルなく効率的に運用・保守を管理していくために必要な計画立案のポイントを説明していきます。
Step.4 運用・保守の定着と次の備え
運用・保守のほとんどの作業は事業者が実施することになりますが、ＰＪＭＯが適切な関与を行わなければ、より良い運用・保守に改善していくことはできません。ここでは、ＰＪＭＯが運用・保守の状況を効果的に確認し、適切な改善を推進していくためのポイントをお伝えします。
Step.5 運用・保守の改善と業務の引き継ぎ
運用・保守の実施中に判明した課題は、定常的な作業の中で改善ができるものは積極的に改善していきます。しかし、簡単に改善できない課題も少なくありません。ここでは、課題に応じた適切な改善を推進していくためのノウハウを、事業者の引継ぎに関する内容も含めてお伝えしていきます。
Step.2 運用・保守を開始するための事前準備
情報システムが完成したら、サービス・業務を滞りなく提供していくために情報システムをきちんと運用・保守していかなければいけません。しかし、情報システムの運用や保守は、専門的な内容が多いため、気が付いたら膨大な費用がかかり、プロジェクトの目標も未達成だった、ということもしばしばあります。
でも、安心してください。運用・保守を開始する前に、いくつかのポイントを押さえて事前に計画すれば、このような事態を防ぐことができます。
では、より良い運用・保守を行うための事前準備のポイントを、紹介していきます。
１ 「運用と保守」の位置付けを理解する
【標準ガイドライン関連箇所：第３編第９章第１節】
情報システムの「運用」と「保守」はよく耳にする言葉ですが、その目的や違いを知っていますか？また、運用・保守とよく混同する活動に「サービス・業務の運営」や「機能改修」もあります。これらの違いや関連性を理解していないと、責任範囲や実施内容が曖昧になり、効率的で効果的なプロジェクトの運営を行っていくことができません。
ここでは、運用・保守の位置付けを説明していきます。
A. サービス・業務をより改善するための活動を行う
情報システムの開発と移行が完了して新たなサービス・業務を開始した時点は、プロジェクト当初に掲げた目標・目的を達成するためのスタート地点に立ったにすぎません。また、サービス・業務を支援する情報システムも、その時点で100％の出来ではなく、発展途上の状態である場合もあるかもしれません。リリースまでは想定に基づき業務要件、機能要件を定めてきましたが、運用・保守フェーズに入った後は、実際の利用状況等を継続的にモニタリングして、利用者の行動等を把握することが可能となります。これらをしっかりと把握して、より効果的・効率的なサービス・業務に改善していくことにより、国民や業務実施部門をはじめとした政府職員にとって、よりメリットをもたらす情報システムに成長させることができます。
また、サービス・業務の効率化によるコスト削減は、関係する人員削減とイコールではありません。より人間にしかできない業務に人的リソースを振り分けることで、今まで手が回らなかった業務に対応できるようになるため、より良いサービス・業務を実現していくことができます。
運用・保守の心得
・運用も保守も、サービス・業務をより良くするための活動の一部。
・目標、指標に関連する情報をモニタリングして、改善につなげる。
・効率化は人員削減によるコスト削減につなげるだけなく、他の活動に活かしてさらなる価値を生み出す。
B. 情報システムの運用と保守の活動を理解する
情報システムの「運用」も「保守」も、根本となる目的は同じです。シンプルに表現すると、稼働している情報システムを「健全に保って活動を続けさせる」ことです。
運用と保守の目的
・サービス・業務の提供価値を高め、継続して行えるようにする。
・この目的を達成するために情報システムを安定稼働させ、一連の作業が滞りなく進むように維持する。
その共通の目的のもと、運用と保守には次のような違いがあります。
運用とは何か
運用とは、上記の目標を達成するための「情報システムの機能を利用者に提供し続けるための活動」です。情報システムの稼働状態を維持するための作業が主となりますが、情報システムを相手にするだけではなく、ユーザサポートのように「人」を相手にする作業もあります。作業を大きく分類すると以下に示すものがあります。詳細は、標準ガイドライン解説書「第９章 運用及び保守」の表9-1を参照してください。
| 作業分類 | 概要 |
|---|---|
| 定常時対応 | |
| 監視作業 | 情報システムの稼働状況や利用状況、情報セキュリティ、不整合なデータの有無等の監視を行います。異常の発生を即座に、又は事前に検知することで、安定的な情報システム稼働を維持するための活動です。 |
| 情報システム維持作業 | バックアップや計画停止、プログラムリリース、一括データ処理、不整合なデータの補正等の情報システム維持関連作業とそれらに係る管理を行います。情報システムを長期間安定して稼働させるために必要となる活動です。 |
| ユーザサポート業務 | ヘルプデスクやコールセンターの運営、操作研修、利用者の情報メンテナンス等の情報システムの利用者に対するサポートを行います。利用者が正しく情報システムを利用し、円滑にサービス・業務を遂行することに寄与する活動です。 |
| データの収集と報告 | 作業実績や障害実績等のデータを収集し整理し、ＰＪＭＯに報告する作業です。 |
| 障害発生時対応 | |
| 情報システム維持作業 | 不具合等のインシデントに対する受付、切り分け、報告等の一連の対応の管理、リリースやバックアップからのきり戻し等の復旧作業を行います。また、時には誤った情報が記録されたデータベースを修復することもあります。 |
表9-1 運用作業の分類
保守とは何か
保守とは、「情報システム（インフラ含む）が予定された機能・レベルを提供するように、情報システムそのものを維持するために情報システムに対して働きかける活動」です。作業を大きく分類すると以下に示すものがあります。詳細は、標準ガイドライン解説書「第９章 運用及び保守」の表9-2を参照してください。
| 作業分類 | 概要 |
|---|---|
| 定常時対応 | |
| ハードウェアの保守 | 定期点検、予防保守等、ファームウェアのアップデート等を行います。ハードウェアの異常の確認や予防を行う活動です。 |
| ソフトウェア製品の保守 | 製品のアップデートファイルの運用事業者への提供、製品への問合せの対応等を行います。 |
| システムリソース配分の調整 | 過去の業務処理記録やこれからの業務処理見通しに応じて、システムのハードウェア（論理的なハードウェアを含む）資源の稼働中プロセスへの配分を見直して、システムの処理能力を向上させます。 |
| 保守作業共通の作業 | システムの利用者と調整して保守作業計画を策定します。また、システム監査に対するヒアリングや情報提供等を行います。 |
| データの収集と報告 | 作業実績や障害実績等のデータを収集し整理し、ＰＪＭＯに報告する作業です。 |
| 障害発生時対応 | |
| アプリケーションプログラムの作業 | アプリケーションプログラムの不具合に対する原因調査、プログラムの修正・テスト等を行います。 |
| ハードウェアの保守 | ハードウェア異常に対する原因調査、ハードウェアの修理や交換等を行います。 |
| ソフトウェア製品の保守 | ソフトウェア製品の不具合に対する原因調査、ソフトウェア製品の修正・テスト等を行います。 |
表9-2 保守作業の分類
C. 運用・保守は他の様々な活動と連携し、並行で実施する
運用と保守の活動は他の活動のいろいろな作業と関係しています。最も関係性があるのは標準ガイドライン「第８章 サービス・業務の運営と改善」で、運用・保守とは表裏一体との関係にあります。これらの関係を図9-1に示します。
図9-1 運用及び保守活動と他の活動との関係
「サービス・業務の運営と改善」の活動で、ＫＧＩ・ＫＰＩがどの程度満たされたかを判断するための指標を算出する作業を行いますが、この作業に必要な根拠情報を提供するのが、「運用と保守」の重要な作業の一つです。根拠情報には、システムログやトランザクションデータ等の情報システムで取得可能なものと、サポートデスク等で人が介在して取得するものがあります。そのため、これらの情報取得作業は、運用保守作業の一つとして確実に作業に組み込み、必要な情報が必要なタイミングで取得できるように整備しておく必要があります。
事例：調達要件に改善提案業務を明記し、運用開始後の改善活動を円滑に ある府省では、管理している情報システムの一つで、運用保守業務の調達仕様に「年に２回の改善提案」を盛り込んでいます。具体的には、半年間の課題整理、今後の運用・保守業務改善の方向性（事業者の意思表示を含む）及び全体課題と個別課題に係る改善提案について、文書を作成してプレゼンテーションを求めています。 当初契約締結時には、運用保守事業者側に戸惑いも見られましたが、①提案内容のメリットの大小は問わないこと、②費用がかかる案件であれば別途予算化を検討すること、を確認して事業者側の理解を得て進めることとなりました。 改善提案制度の導入によって、職員と事業者に以下のような仕事への取り組み方の変化がもたらされました。 ・ 運用保守事業者の考え方が、利用者目線になっていった。すなわち、安定稼働、使いやすさ、丁寧な説明を重視するように変化した。 ・ 年２回の改善提案があることで、ＰＪＭＯ職員と事業者のコミュニケーションが活性化した。 ・ ＰＪＭＯ職員の業務と情報システム運用との関係に対する理解が深まったことから、仕事の計画と実施管理の水準向上につながり、情報システムそのものの機能改善や次期情報システムの企画業務に時間を割く余裕が生まれた。 この事例において、いわゆるＳＬＡ（サービス水準契約）に基づくペナルティやインセンティブは設けていませんが、年２回の改善提案業務をきっかけとして、事業者と職員の協働によるＳＬＭ（サービスレベルマネジメント）が行われています。 |
上記のような例もそうですが、運用・保守を実施していく中で発生した問題に対して、運用・保守の範囲だけでは解決できないこともあります。そのような場合は、標準ガイドライン「第８章 サービス・業務の運営と改善」に課題を集め、サービス・業務の内容も含めて改善を検討します。（※これはＩＴＩＬが定める問題管理に相当します。） (注記:ＩＴＩＬ（Information Technology Infrastructure Library）とは、1989年に英国政府のＣＣＴＡによって公表されたＩＴサービスマネジメントにおけるベストプラクティスをまとめたもの。2018年時点ではＶ３である。 )
また、「サービス・業務の運営と改善」で集めた課題に対して、既存の機能の修正や新たな機能の開発が必要になることがあります。これらは「機能改修」と呼ばれます。プログラムに修正が入る点では「保守」と似ていますが、保守における修正は、サービス・業務の開始時点で定められた設計どおりに動作させるためのものである点に注意してください。
D. 運用・保守に、自動化の仕組みを取り入れる
情報システムの運用・保守は、従来は人が目視確認や手作業で実施してきましたが、人による体制で運用・保守を行うと人件費がかさみ、運用保守のコスト増となります。
現在では、通常システム運用管理ツール等を導入して自動化による効率化を図っています。ただ、これらのツールを導入してライセンスを購入したにもかかわらず、実際にはこれらのツールの機能をほとんど使っておらず、結果として人手による運用作業が多く残っているケースも多くみられます。
以下に、より効率の良い自動化を進めるために検討すべきポイントと例をまとめます。
自動化を進めるためのポイントと例
手順が定まっている作業の自動化
セキュリティパッチアップデート、プログラム更新、データ更新等を自動的に行うプログラムや設定を準備しておく事で正確かつ実施効率を上げる方法です。
・定量的な監視設定と通知・連絡の自動化
アクセス量が制限値を超えた時や、サーバのメモリやディスク容量等があらかじめ設定した値を超えた時、あるいはネットワークや機器の故障があった際にメールやSMS、電話等で自動的に関係者に通知・連絡する方法です。従来はメールのみによる通知が主でしたが、SMSや電話での通知を取り入れることで、より素早い連絡とその後の対応ができるようになります。
・経験者の目視に頼っていた判断・制御の自動化
アクセス状況やサーバリソースのグラフの異常傾向の検知、不審な大量アクセス等の検知をAI等の機械学習を利用して実施し、初期判断（運用・保守担当者へのエスカレーション）に用いる方法です。上記「定量的な監視設定と通知・連絡の自動化」 のような設定値の超過ではなく、時間推移による急激な変化によるリスクを判断するという「経験者の暗黙知」を自動判断にすることで稼働時間を抑えられるようになります。また、検知後の制御・対応も自動実施することも可能になります。
E. システム間での運用統合を検討する
各プロジェクトで複数のシステムを運用している場合に、それらの運用業務には重複する作業が多数発生していることがあります。
このような場合に、複数システム間での運用を統合することも検討してみたいですね。
運用経費の総額を減らすということも一つの目的ですが、それだけではなく、個々の職員が運用作業に振り回されている現状を改善できるかもしれません。
運用業務の統合に際しては、なるべく統一したオペレーションが行えるように検討・調整することが大事です。たとえば、ハードウェア、ネットワーク、アプリケーションプログラム等のそれぞれの層毎に、発生している運用業務を把握してみましょう。
すると、監視内容については各システムでほとんど似通っている一方で、障害を検知した後のエスカレーション先はそれぞれ異なっているなど、共通点と相違点を区別して把握することができます。このように、運用業務の現状を把握できれば、統一したオペレーションへの第一歩を踏み出すことができるかもしれません。
また、統合運用を実現する際に、運用管理システム（ジョブ管理、システム監視、構成管理等）がばらばらだと共通化できる作業が少なくなってしまいます。運用管理システムを統一することもまた一つの検討事項です。
| 事例：複数システム間でのシステム監視業務統合
ある府省では複数のシステムを保有しており、それぞれ異なる事業者が同じような監視内容を異なる監視ツールで個別に監視していました。報告も個々の事業者から別々に受けており、同じような内容でありながらツールの違いから、情報の見え方もそれぞれ異なるため、報告を受ける職員の負担となっていました。また、システム毎にそれぞれの事業者から報告を受けていて効率的ではありませんでした。 こうした状況を改善するため検討を行った結果、監視ツールを統一し、まとめて監視することにしました。具体的には、それぞれのシステムに共通、固有の監視項目を抽出して網羅性を確保し、監視ツールをひとつの製品に統一しました。 その結果、課題となっていた職員の負担や非効率が改善されただけでなく、保有するシステム群全体の状況を横断的に監視できるようになったことで、府省全体のシステム最適化を進めるための基礎情報を得られるようになりました。 |
２ 作業責任を正しく理解しトラブルを防ぐ
【標準ガイドライン関連箇所：第３編第９章第１節】
運用・保守の活動やそれに係る「サービス・業務の運営と改善」等の活動には、様々な関係者が関わります。それぞれの作業内容や責任範囲が曖昧になってしまうと、作業が漏れや関係者間の意思疎通が不十分となることによる新たな問題が発生するリスクが増大します。悪くすると、情報システムの安定的な稼働への問題発生、改善活動の停滞などを招き、プロジェクトの目標達成に影響が出てしまいかねません。
ここでは、運用と保守に関係する関係者と各々の作業責任内容を定めて、円滑に作業を進めていくためのポイントについて、ご紹介します。
A. 外部委託事業者へ依頼する作業の内容を明確にする
「運用」及び「保守」に係る作業は、基本的に外部事業者に委託して実施します。その理由は、内容が専門的であることや、手順に沿った定型かつ大量な作業が多いため、ＰＪＭＯや業務実施部門の職員が実施すると、かえって非効率になる可能性があるためです。「餅は餅屋」の言葉どおり、外部事業者と役割を適切に分担することにより、発注者側の職員は、業務の質の向上やコスト削減等の、本来職員が行う事業者では実施できない作業に、より注力することができます。
外部事業者に依頼する作業や役割は、調達の段階で調達仕様書に明記しておく必要があります。事業者確定後にこれらの詳細を詰めようとすることは、トラブルの原因となりますので、注意してください。
それでは、調達仕様書にはどのような項目を定義すればよいでしょうか？
基本的には、定型的な作業は標準ガイドライン「第７章 設計・開発」において、運用設計・保守設計として洗い出されているため、それがそのまま調達仕様書の付属資料として、作業要件になります。しかし、次に示すような項目は、重要な内容にもかかわらず見落とされがちなため、明記されているかもう一度確認してみましょう。
参考：運用契約（要件・仕様検討時）の忘れ物チェックリスト
以下は契約時点で要件化が必要であれば記述を検討してください。 ・ ネットワーク増設・設定変更作業（技術支援、設計、設定工事） ・ 情報セキュリティインシデント時の役割（情報連携作業、ＣＳＩＲＴ報告・支援待機など） (注記:ＣＳＩＲＴとは、シーサート (CSIRT: Computer Security Incident Response Team) とは、コンピュータセキュリティにかかるインシデントに対処するための組織の総称。http://www.nca.gr.jp/ ) ・ ヘルプデスク、ネットワーク管理事業者、業務システム開発事業者との連絡関係 特に、構成管理については運用を積み重ねる中で、ドキュメント間の不整合が発生しがちです。大規模なシステムでは、このようなドキュメント管理に専門の要員（ライブラリアン）を配置して、ドキュメント管理ルールにのっとって正確な記載を保つ努力をすることもあります。 ドキュメント間で矛盾した記載にならないか、同じ用語が違う意味でつかわれていないか、それらは一見些細な事に見えますが、このような記載の「ゆれ」によって関係者が誤解をした結果、大きなシステム障害につながってしまう事例もあります。用語辞書を整備することがひとつの対策ですが、最初に作成してそれっきり放置されるということもあるため、メンテナンスを行う体制を維持することも重要です。 構成管理の品質を高めることに留意しましょう。 |
B. 指標の基礎データを誰がどのように集めるかを明確にする
指標に用いるデータ取得のための作業は、標準ガイドライン「第８章 サービス・業務の運営と改善」の作業と密接に関連します。サービス・業務の運営と改善では、プロジェクト計画書で定めたプロジェクトの目的・目標が実現できているかに関して、いくつかの指標（ＫＰＩ）を用いて判断し、業務の改善や見直しを行います。指標（ＫＰＩ）は、基礎値の組み合わせによって、表されます。
指標（ＫＰＩ）の例
指標の基となる各種データは、種類ごとに、取得先、取得手段、取得頻度等について詳細な検討が必要です。代表的なデータとして、情報システムが稼働している際に作り出されるログやトランザクションデータと呼ばれるものが挙げられます。これらは、職員が自ら取り出せるもの、運用事業者に依頼しないと取り出せないもの等、データの取得には制約が発生します。前者であれば、事前に技術的な経験のない職員でも容易に取得できるように、取得手段が機能化されている必要があり、後者は対象と取得手順が明確に定義されていなければ、定常的な運用作業として継続できません。
これらを踏まえて、取りこぼしが発生しないよう、必要なデータ項目を事前に把握するとともに、外部事業者に取得を求める場合は調達仕様書に明記しておきましょう。
|
指標は、いざ算出しようしたときに、算出根拠となる基礎情報が不足していることが判明し、その情報を追加入手するためには想像以上に困難であることに気付くことがあります。特に、ある分析結果からより多角的な分析が必要になった場合、特定の情報の付加情報として「区分」や「属性」等、より詳細な情報が求められることがあります。このような情報は、事前に取得・保管する仕組みが備わっていなければ、その時点から遡ってデータを取得することが不可能なこともあります。また、取得可能だったとしても、多くの手間を必要とする場合もあり、そのようなデータは頻繁なモニタリングが敬遠され、結果として指標が適切な時期に算出できず、対策が遅れてしまうことにもつながりかねません。
運用・保守を開始してからトラブルとならないよう、事前に具体的なモニタリングの方法や役割分担を検討し、事業者に依頼する場合は調達仕様書に作業内容を明記してください。
また、平均値を指標とするときは、集計対象の種類や内容が同種のもので平均値を算出するようにし、異なる性質のものを混合して値を算出しないようにしましょう。
| 参考：運用・保守だけでは指標を算出できないケース
設定した指標値
このように設定された指標では、申請全体に対するオンライン申請の割合が把握できます。一方で、効果的な改善活動に資する活動として例えばオンライン申請率を向上させようとした場合、このオンライン申請を実際に実施したユーザの区分（本人・代理人の区分、個人・法人の区分等。）ごとの割合を分析して、区分に応じた対策を講じる必要があります。 ユーザ区分ごとの申請件数は、「オンライン申請件数」は、申請情報にあらかじめユーザ区分を加えておけば、運用作業で取得できますが、「総申請等件数」は業務実施部門から取得するかもしれませんし、全ての申請を管理している別の情報システムから取得しなければいけないかもしれません。また、取得先全てにおいてユーザ区分の情報を持たせ、かつ、ユーザ区分の種類を統一する必要もあります。 |
C. 業務実施部門を含めた運用体制を確立する
情報システムの各種テストが完了し、後は本番リリースを迎えるだけという状態に準備が整い、運用・保守フェーズをお任せする事業者が確定したら、サービス・業務を利用者に提供するまであと一歩です。運用・保守フェーズでは、最初に司令塔となるＰＪＭＯを含んだ運用統制を行うチームを構築し、プロジェクトを管理していくことになりますが、円滑な運営を進めるための注意点があります。
それは、業務実施部門（主に当該情報システムの業務統括部門）とのコミュニケーションと役割分担です。
業務実施部門には、情報システムを用いて実際に業務を行う職員が集まっています。この多くの職員には、プロジェクトの目的・目標を理解してもらうことは、標準ガイドライン「第８章 サービス・業務の運営と改善」で触れたとおりですが、運営に入ってからは次の点に気を付けて実施してください。
業務実施部門との役割分担・コミュニケーションで気をつける点
ＰＪＭＯには、業務実施部門の担当者が参画するよう、組織を組成する。運用・保守に関わる定期報告会では業務実施部門の担当者（代表者）が参加した上で、常に情報を共有できるようにする。
・日常的に、現場業務で発生した問題や状況に関する情報がＰＪＭＯに伝わるよう業務実施部門の担当者とのコミュニケーションルールを明確にしておく。
業務実施部門とＰＪＭＯとの関わりについては、プロジェクト立ち上げ時のＰＪＭＯの組成にまで遡ります。そこでは、基本的にＰＪＭＯには制度所管部門及び情報システム部門とともに、業務実施部門の担当者が参画することが望ましいことが言及されています。
これまでは、新しいサービス・業務の要件を定めるために、業務実施部門の職員から意見・要望を収集することが主でしたが、サービス・業務の運営フェーズになると、コミュニケーションの流れが、収集だけではなく、業務実施部門からの情報提供が加わります。
利用者からの意見や要望を把握するためには、最も接点が多い業務実施部門の職員からの情報提供が欠かせません。また、運用・保守で発生した報告内容には、利用者からの問い合わせや発見した不具合、不具合修正に伴う情報システムの稼働停止連絡等、様々な情報が含まれます。これらを業務実施部門と共有することにより、業務実施部門の中で必要な調整や対策を行い、今後問題を引き起こすリスクを低減させることが可能となります。
そのためにも、プロジェクトの情報が集まるＰＪＭＯへの参画、定期報告会への必要な人員の出席、代表者から業務実施部門の関係者全員への情報伝達手段などを、運用及び保守が開始する前に取り決めておきましょう。
D. 障害発生時の役割分担に注意する
障害が発生しない情報システムは、ほぼありません。大切なのは、障害が発生した際に適切な対応を取ることで被害を最小限に留め、暫定対策から恒久対策を実施し、将来にわたって同じ又は同じような障害を発生させないようにすることです。そのためには、障害対応という急を要する状況の中でも、ＰＪＭＯ、運用の事業者、保守の事業者、その他の関係者が適切な役割分担の下に協働して対応を進めていくことが必要になります。運用と保守の事業者が異なる場合や運用・保守それぞれを複数事業者で分担して実施する場合もあり、役割や責任が曖昧になることで対応が遅くなってしまうことや被害が拡大してしまうことも少なくありません。
まずは、障害発生時における運用と保守の基本的な役割分担を理解しましょう。この考え方を踏まえた上で、プロジェクトの体制や特性を踏まえて、詳細を決めていきます。
極端な例ですが、ＰＪＭＯの体制が１名の場合は、24時間365日稼働するサービスへの対応は十分にできません。どのようなタイミングで障害が発生するかは予想できないからです。深夜や休暇取得中等、ＰＪＭＯが対応できない状況が存在することを前提に、運用事業者・保守事業者と役割分担を検討する必要があります。
図9-2 障害発生時の運用と保守の役割分担の例
Step.3 運用・保守の計画
運用・保守を担当する事業者が決まったら、事業者とともに調達仕様書で示した内容から、運用・保守の詳細な作業内容や実施方法等を検討し、計画書と実施要領として明文化します。これらは、運用・保守の作業はこの計画に基づいて実施することとなるため、作業が漏れたり不十分だったりすると後々問題を引き起こすこともあります。
ここでは、運用・保守をトラブルなく円滑に進めていくための計画策定のポイントを、紹介していきます。
１ 運用と保守の計画を作成する
【標準ガイドライン関連箇所：第３編第９章第１節2)】
この実践ガイドブックには、別添として、運用計画書、運用実施要領、保守計画書、保守実施要領のひな形を示しています。
| 様式例：運用計画書、運用実施要領、保守計画書、保守実施要領のひな形
運用計画書、運用実施要領、保守計画書、保守実施要領のひな形を本章別紙としてまとめています。     |
このひな形はあくまで例示ですので、運用の内容に応じて記載内容を個別に追加、変更してかまいません。ひな形を見ると、何をどのようなレベルで書くべきかの参考になると思います。
以降では、運用計画書・運用実施要領を作成するときに、特に注意が必要なポイントについて説明していきます。項目の詳細な説明は、ひな形を参照してください。
A.システムプロファイルに応じた運用・保守レベルにする
運用や保守の体制や作業は、サービス・業務の内容や重要度等によって、適切なレベルを設定し、適切な費用で効果的な運用・保守となるように心掛けましょう。しかし、適切なレベルとはなんでしょうか？
運用や保守のレベルの基準となるのは、要件定義書で定められた「システムプロファイル」です。 (注記:システムプロファイルとは、「標準ガイドライン 別紙５ システムプロファイルに係る定義について」に基づいて定義する情報システムの信頼性の水準のこと。)
サービス・業務を開始した直後から運用や保守が安定するまでの一定期間は、予期せぬ障害に備えて手厚い運用・保守体制をとることがしばしばあります。この手厚い体制を維持する期間は情報システムによって様々ですが、システムプロファイルで示した運用・保守レベルを維持できる最低限の体制を基準として、プロジェクトの状況に応じて定期的に見直しを行い、徐々に適切なレベルの保守・運用にしていくように調整していきましょう。
B. セキュリティ関連作業を定期的に確実に実施する
セキュリティ管理に関する要件は、非機能要件で示され、運用・保守フェーズでは、その方針に沿ってアプリケーションやインフラでの対策が講じられている状態にあります。昨今のセキュリティに対する脅威は日々増大しており、運用・保守フェーズでは、設計どおりの対策が維持できるよう、日々確実に作業を続ける必要があります。
以下に定期的に実施すべき作業の例を挙げます。
・セキュリティインシデント発生時の記録、対応、影響範囲の把握
・脅威と修正パッチ適用計画の立案・調整
・シグニチャ、ブラックリスト（ホワイトリスト含む）更新
・ＯＳ及びプラットフォーム等の緊急修正計画の立案・調整
・セキュリティ向上のための業務改善と利用規制検討
・中長期的プラットフォーム改善に向けた、システム構成要素のリスク評価
C. プロジェクトの目標や指標の評価に必要なデータは必ず取得する
Step.2-2の「指標の基礎データを誰がどのように集めるかを明確にする」のとおり、目標や指標値を定期的にモニタリングできるよう、運用作業として取得しなければいけないデータについては、以下の観点で運用の計画書と実施要領に明確に記載しましょう。
| 記載箇所 | 記載内容 |
| 運用計画書 | |
| １．作業概要 | データ取得作業として、取得するデータの種類、取得の条件、集計や加工の方法等を記載します。 |
| ３．スケジュールに関する事項 | いつ、どのタイミングでデータ取得作業を行うかを記載します。月次や四半期の期末月のように定期的に取得し、運用保守定例会議等で報告とデータの提出を求めます。 |
| 運用実施要領 | |
| ３．作業管理 | 報告の形式や報告の仕方を記載します。 |
表9-3 運用計画書、運用実施要領におけるデータ取得に関する記載内容例
運用作業で取得したデータは、標準ガイドライン「第８章 サービス・業務の運営と改善」で使用する以外にも、今後の機能改修やサービス・業務の見直し時の分析データとして使用できるよう、報告資料だけではなく、データ自体を加工や集計が可能な形式で受け取るようにしましょう。そのためには、運用計画書及び運用実施要領に記載された内容から、要員に依存せずにデータを取得できるよう、データ取得手順書の作成を運用事業者に求めてください。
また、これらのデータを保存する手段や期間に関する考慮も重要です。数年に渡る傾向分析等に必要な情報は長期間保存が必要ですが、週次で集計値を算出した後は不要となる詳細データは、無闇に保管するとストレージ等の無駄が生じます。クラウドサービスを利用している際はデータ保存量がコストに直結する場合もあるため、迅速かつ頻繁に参照したいデータは取り出しやすい媒体に保存し、緊急性のないデータは外部媒体に保管する等の工夫を行いましょう。
D. 非機能要件に関連するデータを網羅的に詳細に取得する
サービス・業務を円滑に運営するためには、標準ガイドライン「第５章 要件定義」で定めた非機能要件に従って、情報システムを安定的に稼働させ続けることが必要になります。
このためには、現時点で情報システムが非機能要件で定めた指標値を満たしているかを確認することはもちろんですが、将来的に要件を満たせない、維持コストが増大する等のトラブルが発生する予兆を捉えることが、とても大切です。また、日次や月次等の定点的な観測だけではなく、確認したい内容ごとにどのような間隔でデータを取得するかを検討し、取得できる仕組みを設け、必要な情報が必要な粒度で取得できるように備えておきましょう。
非機能面のチェックは様々な観点がありますが、次にあげるポイントはとても重要ですので、必ず確認できるように、運用作業に持ち込んでください。
非機能要件に関連するデータの確認ポイント
データ量データベースやファイルシステムの使用率等を時系列で確認し、傾向から将来容量が枯渇するおそれがないかを確認します。
・処理時間
機能単位、時間単位等の複数の視点からレスポンス時間等の処理時間を確認することにより、安定的に処理を行えているか、処理が遅くなる傾向等が見られないかを確認します。また、バッチ処理時間も時系列で確認し、将来的に完了予定時刻に遅れる予兆等がないかを確認します。
・リソース状況
ＣＰＵやメモリ等が異常な状態になっていないか（高負荷状態が続いている、ほぼ使用していない等）を確認します。これらも、サーバ単位、時間単位で詳細に取得して、傾向を確認します。
これらのデータを蓄積していくことで、情報システムを更改する際に、サーバの構成・スペック等の精査が簡単に行えるようになります。また、クラウドサービスに求めるサービスレベルの検討にも活用できます。これらの情報についても、報告資料だけではなく、データ自体の提出を求めるようにしましょう。
E. 会議体は目的を明確にして必要最低限に抑える
運用・保守フェーズは、複数の職員や事業者が関わるため、会議体の種類がどうしても多くなる傾向があります。中心的な役割を担うＰＪＭＯの職員や事業者の担当者は、会議出席に拘束されてしまい、本来行うべき作業に手が回らないという状況に陥りがちです。
そのような状況にならないために、会議体の目的を整理し、必要な出席者を事前に選抜するようにしましょう。以下に主要な会議体の種類と主な目的を示します。
| 会議名称 | 主な目的・内容 |
| 定例会議 | |
| 日次会議（朝会夕会を含む） | ・ 関係者同士の作業確認、段取り打ち合わせ ・ シフト間（夜間から日中等）引き継ぎを既定のシートをベースに行う |
| 月次会議 | ・ 事業者が発注者に対して行う報告など ・ 事業者同士の情報連携及び業務手順改善 （例：基盤運用事業者、ＡＰＰ保守事業者、センターオペレーション事業者、ヘルプデスク事業者及び発注者の５者運用調整会議） |
| セキュリティ対策会議（月次～四半期） | ・ インシデント発生状況の共有 ・ 脅威と修正パッチ計画の調整 ・ シグニチャ、ブラックリスト（ホワイトリスト含む）更新調整 ・ ＯＳ及びプラットフォーム等の緊急修正計画調整 ・ セキュリティ向上のための業務改善と利用規制検討・承認 |
| 業務・システム運用改善会議（１～２回／年） | ・ 上級マネージャ出席（発注者側、事業者側双方）の下で、業務及びシステム運用についての協議を行う。 ・ 業務仕様に「改善提案」を盛り込んであれば、この会議体で提案する。 ・ 職員側と事業者側の幹部を出席者とする「ステアリング・コミッティ」とすることも可能。 |
| 非定例会議 | |
| 個別課題について解決するための会議 | ・
一般的には発生都度開催することが多いが、当該業務及びシステムの価値に関わる重要テーマがあれば、そのテーマを冠として分科会形式で開催することが望ましい。 例）「システムサービス改善運動」を冠テーマとして、「利用者サービス向上分科会」、「業務ミス根絶分科会」、「マニュアル・手順書改善分科会」」等を適宜開催。 |
| システム移行会議 | 業務システム全体を改修する場合、基盤を乗せ換える場合、一部出先事務所（又は事業所）にシステムを導入する場合等で実施。 |
| 次年度リソース計画会議 | システム基盤リソース及び保守運用に係る人的リソースの検討を行う。利用実績や実測レスポンス、定例処理の時間等のエビデンス情報に基づき、今後の必要リソースを算出していく。 |
表9-4 会議体と主な目的・内容例
会議体選択の考え方
・ 日次会議は、情報や状況把握の正確性確保と関係者間の問題解決事案の引継ぎが主目的である。短時間で効率的に実施することが肝要である。この会議では、運用状況・保守作業状況及び問題解決の進行状況が取り上げられるので、できる限りＰＪＭＯが参加することが望まれる（毎日出席はできなくても週に１回ランダムに出席することを推奨する）。
・月次の定例会議 は、できる限り開催する。ＰＪＭＯ側と事業者側の双方の責任者が出席し、マネジメントレベルの状況判断、方針及び約束等をオーソライズする場とする。できれば、調達時点で必須報告事項を仕様として提示することが望まれる。
・セキュリティ対策会議 は、インシデント事案の最終評価・対応方針の周知、確実な脆弱性対策実施及び運用上の懸念事項の吸い上げが目的である。目安として利用者が数百人以上のシステムにおいては、四半期に１度程度は開催することが望まれる。
・業務・システム運用改善会議 は、運用関連業務の受託事業者が「仕様書：改善提案業務」の成果発表を行う位置づけとすることを推奨する。この会議では、事業者から出てくる改善提案にＰＪＭＯが誠実に対峙し、協働して前向きな改善に持ち込めるかどうかが重要。
・その他非定例会議 は、必要の都度開催することとなる。ポイントとしては、事前に会議の目的と到達目標、テーマ及び各参加者の役割を周知しておくとことが望まれる。
F. 定例会の報告フォーマットを指定して、効率性を上げる
運用や保守を行う事業者は、多くの場合、独自の報告フォーマットを持っています。「自社フォーマットを使用することで効率的に運用・保守の報告を行える」という主張は理解できますが、ＰＪＭＯが報告してほしい情報がそのフォーマットに含まれていなかった場合、その情報を把握できない可能性があります。また、複数の情報システムを有する大規模プロジェクトにおいて、複数の運用・保守事業者が活動を行う場合に、それぞれの報告フォーマットが異なったらどうなるでしょうか？横並びでの確認が困難になりますし、分析が非常に難しくなり改善の妨げになるかもしれません。
これらを防ぐために、事業者からの報告フォーマットはＰＪＭＯが指定したものを使用するよう、調達仕様書であらかじめ方針を示しておきましょう。運用・保守事業者の決定後、詳細な報告項目について更に調整を行います。この際、報告書作成に特定のツールを利用しているため、指定したフォーマットで報告することが著しく非効率になる等の場合は、ＰＪＭＯが求めた内容が必ず含まれるよう、事業者にフォーマットを確認し、盛り込むべき内容を合意してください。
| 事例：定例会の報告フォーマットを統一し報告内容の分析向上
ある府省の情報システムには、複数の運用・保守事業者が関わっており、効率的な運用保守定例会の運営が課題となっていました。 そこで、他の情報システムや過去の報告書等を参考に、発注者側で報告フォーマットを検討し、各事業者にはそのフォーマットに沿った報告を求めました。 一部の事業者は、既存の報告書を作成するツールが存在していたため、難色を示しましたが、報告項目や単位を揃える方針で調整を行い、合意しました。 その結果、各事業者からの報告内容が同じ軸で効率的に比較・分析できるようになりました。  |
G. 運用・保守の工数を把握し、人件費をモニタリングする
情報システムに係る経費は、情報システムを構築するまでの費用よりも、運用・保守フェーズ期間にかかる費用の方が多いことがよくあります。運用や保守のどの作業にどの程度の工数がかかっているかを定期的に把握していなければ、費用はかかったが求めた内容があまりできなかった、という結果にもなりかねません。
運用・保守フェーズの作業はとかく事業者にお任せになりがちで、報告内容もざっくりと「作業一式」で済まされてしまうこともありますが、管理に必要となる詳細な報告を求めましょう。事業者は個別のエンジニアの工数管理は労務管理上実施しているはずですので、求めれば応じられる管理情報は持っています。
実際の工数を正確に把握していれば、的外れな対策を行うリスクもなく、効率的にコスト削減を行うことができます。低コストで効果的な運用・保守に改善していくためにも、作業ごと、要員ごと等の詳細な工数データを取得できるよう、事前に事業者と調整し、運用の作業の一部として計画に盛り込み、運用保守定例会議で報告を受けるようにしましょう。
| 事例：運用・保守の稼働工数を実績に基づいて分析し削減に成功
ある府省で、情報システムの運用・保守費の見直しを行うことになりました。作業区分ごとに工数の確認を進めようとしたところ、運用報告書に記載されている作業内容は、記載レベルが大まかで計画値もなく、実績値との比較分析が困難な状況でした。 このため、運用報告書で報告する作業内容を詳細化し、それぞれ計画と実績工数を明示するよう変更しました。 この結果、項目ごとに実際に必要な工数が明らかになり、過剰な工数を削減することができました。 
運用・保守フェーズに入る前は、実績値がないため想定の値で工数を見積りますが、稼働２年目以降は実績値が取得できるため、計画工数と実績工数の比較を通して適切な工数を確保するよう調整しましょう。 |
事例：ハードウェア保守費を実績に基づいて分析し削減を実現 ある府省の利用者が全国にわたる大規模情報システムにおいて、業務・システムの見直しを行うプロジェクトを実施しました。このプロジェクトでは、見直しの目的にシステム経費の削減を掲げ、まずは現状調査を詳細に行いました。 従来のサーバ構成指針は以下に示す内容でした。 ・ 個別業務の継続性を重視し、サーバを機能ごとに分散させ、十分な冗長性を持たせる。 ・ 将来の大幅な需要拡大予測に基づきシステム規模を設計 ・ 業務ピーク時を含めた最大ＣＰＵ使用率が50%となるように設計 現状調査の結果、ＣＰＵ使用率が低調なサーバが存在することが明らかになり、保守ノウハウの蓄積により、一定程度のサーバ削減を行っても安定稼働が担保されると判断し、以下に示す対策により、サーバ台数の大幅削減を実現し、見直し後の情報システムにおいて大きな成果を上げました。   
この調査の過程で、メモリ使用率はピーク時に90%近くに達することがある一方で、CPUはピーク時でも10%台と低位にとどまっていることがわかりました。 そこで、システム更改後にサーバ構成を見直すだけでなく、現時点においても見直しが行えないか検討を行いました。具体的には、ほとんどのサーバは2CPU構成となっていたため、稼働中のサーバからCPUを１つずつ取り去ることのコストメリットを検討しました。 その結果、ソフトウェアの保守体系がCPU単位での課金となっており、CPUを撤去することで、撤去作業のための経費を考慮しても、現在の保守料金を大きく減額できることが判明しました。また、業務要件に照らし合わせてCPUを一部撤去しても業務上の影響は発生しないことが確認できたため、実際にCPUを一部撤去し、見直し後の情報システムの稼働を待たずに、稼働中の情報システムのソフトウェアの保守料金を削減することもできました。 |
H. 運用・保守における変更管理を理解する
運用・保守フェーズでは、基本的にはその時点で提供しているサービス・業務を変えることなく、情報システムを維持し続ける活動を行います。現状を維持するためには、変えないことが最も安全な方法で、何か変更するということは、何らかのリスクを伴います。現状維持するだけであっても、最低限必要となる変更作業は存在するため、その作業を適切に管理し、安定運用を継続する「変更管理」の活動は、とても重要です。
運用と保守で行う変更管理の対象は、大きく２種類に分かれます。
変更管理の対象の分類
・作業に係る情報への変更管理
運用の要件定義書、調達仕様書、運用計画書、運用実施要領、作業手順書等。
・ 情報システムを構成する資産等に対する変更管理
設計書、ソースコード、マニュアル等。ライブラリ管理と呼ばれることもある。
特に、後者については、運用と保守で管理する内容が重複することもあり、混乱しがちですが、以下のような違いがあります。
運用と保守の変更管理の違い
・運用の変更管理では、誰が修正するかに限らず、情報システムを構成する全ての資産とそれに対して行われる全ての変更を管理する
。つまり、これを確認すれば、情報システムに対して行われた全ての変更について、「いつ」「誰が」「何の理由で」「何を」変更したかを確認することが可能。
・保守の変更管理では、保守事業者の保守対象となる設計書やソースコード等に関する変更を管理する。
運用の変更管理は、情報システムの全ての変更情報を管理する必要があるため、保守事業者が複数いる場合であっても、統一的に管理する必要があります。そのため、変更フローを明確に定めて、情報システムに変更を行う可能性のある全ての事業者に対して、周知徹底する必要があることに注意してください。
以下に、参考として、変更管理のフローの例を記載します。
図9-3 変更管理のフローの例
Step.4 運用・保守の定着と次への備え
運用・保守の事業者とともに計画の策定が終わりました。あとは事業者にお任せしていれば大丈夫。・・・ということはありません。運用・保守を行っていく中では、日々様々な問題が発生しますし、当初計画した内容では足りないことや改善が必要になることもあります。これらの情報を事業者から適時吸い上げ、改善につなげていくには、いくつかのポイントがあります。
このStepでは、運用・保守の作業を効果的に管理していくことで、サービス・業務をより良いものへ導いていくためのポイントについて解説していきます。
１ 運用定例会議を有効活用する
【標準ガイドライン関連箇所：第３編第９章第２節1)ア】
運用・保守フェーズで、ＰＪＭＯが情報システムの状況を確認・把握する場面は、主に運用・保守を実施する事業者が参加して状況を報告する運用保守定例会議が中心となります。しかし、会議に出席して漫然と事業者の報告を聞いているだけでは、事実を捉えて改善を推進していくことはできません。ここでは、運用保守定例会議を有効活用していくためのポイントを見ていきます。
A. 運用保守定例会議で確認する内容を理解する
運用保守定例会議では、運用・保守の計画で定めた報告フォーマットに従って、事業者から基本的には毎回同じ項目の報告を受けることになります。そこでは、外部委託事業者からの報告を受け取るだけではなく、その内容を把握・分析し、根拠が不明なもの、報告が不十分なものは、指摘・再提出も求め、改善活動に繋がる課題や改善点を報告内容から見出し、発注者側がプロアクティブに定点観測する事が大切です。
事業者が「問題なし」と報告している内容でも、「問題あり」に近い「なし」や、状況を把握していないために「なし」と報告しているような場合もあるため、少しでも疑問を感じたら事業者に説明を求めましょう。
また、毎回同じ項目が定期的に報告されるという特徴から、長期間にわたる推移を把握することも可能です。事業者はある時点で切り取った報告を行いますが、その情報を線でつなげて分析し改善に活用しましょう。
いくつかの事例を見ていきましょう。
| 事例：実際のＰＣ故障率を確認し保守コスト低減に成功
ある府省では、職員が使用するＰＣの故障に備えて、機器の保守事業者と高額な数年単位の定期保守契約を締結していました。 ある年度において、運用・保守コストの削減を行うため、ＰＣ故障時に保守事業者を利用した回数について運用保守定例資料を過去から遡って確認しました。その結果、故障率は低く、年間数回しか保守対応を利用していないことが判明したため、定期保守契約の終了を契機に、スポット対応の保守契約に変更し、大幅な保守費用の削減を実現しました。 
この事例では、定期保守に加入していた場合、保守事業者を利用する回数が多くても少なくてもコストには影響がないため、運用保守定例資料でその回数が報告されていたとしても、あまり注目はされません。しかし、別の視点でその数字を分析することにより、異なる目的で活用できることがわかります。 |
運用保守定例会議では、情報システムのハードウェア、ソフトウェアに関する報告だけではなく、ヘルプデスク等の「人」を対象にした運用に関する報告も行われます。
| 事例：評価指標の分析結果をユーザ満足度向上につなげる
ある府省の情報システムでは、ヘルプデスクの評価指標に従来の問い合わせ件数や期限内回答率に加え、回答に至る経緯をオペレーターがその場で即答した「自己解決」と管理者へのエスカレーションを経由した「折り返し連絡による回答」に分類して、サポートデスクの質の評価を行っています。 
サービス開始当初の運用保守定例会議で報告された自己解決率は60%程度でしたが、ヘルプデスクへその数値を共有し、エスカレーションされた40%の内容を分析した結果を基にマニュアルへの追記やＦＡＱへの掲載、オペレーターの教育等の対策を行うことにより、現在の自己解決率は90%程度まで向上しました。 
ヘルプデスクの自己解決率が向上したことで、利用者からの様々な問い合わせにも即時に回答できるようになるとともに、ヘルプデスクからのエスカレーションを受けて、調査等を行っていた職員の負荷も軽減することができました。 |
事例：データの取得粒度を変更したら事象が異なって見えることもある 日中はオンラインサービス、夜間はバッチ処理が中心というある省の業務システムにおいて、夜間のＤＢサーバとバッチ処理を行っているサーバのＣＰＵ使用率が、高い状態となる日が頻繁にあると報告されていました。（下図） 
この情報システムは、安定運用のために、十分な余力を確保して複数台のサーバを稼働させており、サーバのＣＰＵ使用率の報告からも、適切なサイジングがされているものと捉えていました。ただし、潤沢なサーバ構成としていたために、高い維持コストが課題となっており、見直しが可能か検討することとなりました。 そこで、日単位の平均とピークのみで報告されていたＣＰＵ使用率を、１分単位のヒートマップで分析を行ったところ、特定の時間で数分程度ＣＰＵ使用率が上昇しているものの、大半の時間の使用率は10%未満であることが把握でき、ピーク時の負荷の分散を検討しました。（下図） 
一分単位の詳細な単位でＣＰＵ使用率を把握した結果、ＣＰＵ使用率がピーク近くになるのは、ごく僅かな時間帯にすぎないことがわかりました。また、この時間帯に動いている処理は、運用等を目的としたバッチ処理であり、処理時間が多少長くなっても業務への影響が全くないことがわかりました。 この分析により、サーバ構成についてもっと踏み込んだ削減が可能であることが判明し、コスト削減に寄与することができました。 |
これらに共通していることは、「プロジェクトの目標を達成する」「サービス・業務をより良くする」という視点に基づいて、それらの判断や改善に必要となる事実を正しく理解する。という姿勢です。
以下に確認のポイントをまとめます。
運用保守定例会議での確認のポイント
・指標値等の基準を明確にし、基準を満たしているのか、満たしていないのか、今後どうなる見込みなのかを確認する。
・定常どおりの内容よりも、特筆すべき事項を事業者から引き出す。
・定点観測だけでは問題を見落とす可能性がある。時間軸を変えたり、集計の仕方を変えたりする等、様々な視点から状況を捉える。
・根拠が不明なもの、主観的なものには注意が必要。エビデンスを求める。
・ピーク性や今後のイベント等を踏まえて、リスクを確認する。
・発生した課題だけではなく、累積している課題に対する対応状況も確認する。
・ライセンスや保守期限等を確認し、次年度以降の予算要求に備える。
２ 変更を管理し改善活動等の初動を楽にする
【標準ガイドライン関連箇所：第３編第９章第２節】
情報システムを長期間運用していると、運用・保守の作業や機能改修によって、情報システムにたくさんの変更が行われます。これから改善活動や機能改修を検討しようとしたときに初めに行うことは、設計書等から現状の情報システムがどのようになっているかを確認することです。しかし、その設計書は本当に最新の情報システムを反映したものでしょうか？
Step.2-3「運用・保守における変更管理とは」で説明したとおり、最新の設計書や情報システムがどのような理由でいつ変更されたかは、運用の変更管理の作業で管理されます。
なお、変更管理の方法には様々なものがありますので、プロジェクトの事情に合わせて、効率的に管理できる方法を検討してください。
変更の管理方法に関する検討ポイント
・
設計書やソースコード等は変更管理ツールでバージョン等を一元管理することが一般的である。それらの変更管理ツールを、発注者側で管理するか、運用事業者が管理するかは検討する。ライブラリ管理チームを組んで管理することも効果的である。
・環境の事情等で発注者側が最新の変更管理ツールにアクセスできない場合、最新の設計書等の授受方法やタイミングを明確に定める。
・設計書やソースコード等のバージョンと変更の事由や本番環境への反映記録等の一貫して追跡できるように記録をつける。これらを一貫して管理するツール等も存在するため、導入を検討する。
３ 情報システムで起こった事実を蓄積する
【標準ガイドライン関連箇所：第３編第９章第２節】
運用・保守作業により事業者からデータを収集できました。そのデータを目の前にして、どうしたらよいか困っていませんか？改善を検討するに当たって、本当にその情報だけで十分でしょうか？ここでは、改善を検討する際のデータ収集に関するノウハウを見ていきます。
A. 運用・保守の範囲にとらわれず、意味のある情報を取得する
利用者からの問合せは、実際に対応する人やその結果も様々だと思いますが、どんな問い合わせが、いつ、どこから発生し、どのような結果となったかの一連の流れを記録することを推奨します。これにより、あとで集計したり、分析したりすることが可能となり、どういった問題・ニーズがあるのかを、アンケート等で再収集しなくても取ることができます。
これは、運用・保守業務として、運用・保守事業者に求める業務とは異なります。こちらはシステム側面での問い合わせ・問題・インシデント管理であり、先に挙げたものは業務側面でのものです。
相互に連携する部分もあるため、運用・保守業務の管理情報も併せて収集して、一貫して記録し、集計・分析することで効果をあげることができます。また、分析結果から得られた情報を、利用者が参照できるＦＡＱへ追加し、業務マニュアル等の改訂に活用することも可能です。改善を検討する際は、定点の情報だけでなく、一連の流れに沿った視点も分析してみてください。
| 事例：業務運用に貢献するレポート機能の追加
実践ガイドブック「第４章 Step.4 業務の現状把握」で、ある経費積算業務における時間を要している処理業務の、原因分析に関する事例で紹介した「へび図」の作成方法にも一工夫しています。 当初この情報システムには、分析するために必要なデータを抽出する機能が存在せず、職員が手作業で１件ずつ確認しながら資料を作っていたため、非常に煩雑で手間が掛かっていました。 そこで、業務の作業実績の分析は今後も継続的に必要と判断し、情報システムを改修して、必要な情報が記録され、かつ、１ボタンでデータが取得できる「へび図抽出機能」を追加しました。 その結果、この業務の一連の処理状況が、職員に負荷をかけることなく、ほぼ毎月正確に把握できるようになりました。  |
B. 情報システムの活用状況を詳細に把握し提供する機能を棚卸しする
情報システムは、提供する機能数が多く・複雑なほど、運用・保守コストが増大する傾向があります。特に、長く運用している情報システムでは機能の追加・改修を重ねられていることが多く、その傾向が顕著に現れます。
このことを防ぐためには、定期的に機能の棚卸しをすることにより、肥大化を防ぐことが有効です。
棚卸しをするに当たり、利用者へのアンケート等で業務における利用状況を把握する方法があります。さらに、機能ごとの利用ログを情報システムから取得し、分析することでより厳密に利用状況を把握することも可能です。
これらの情報を踏まえて、機能の廃止・縮小対象の検討がより具体的に行えるため、定期的な棚卸しを行うようにしてください。
事例：機能単位で情報システムの利用状況を可視化 運用フェーズにおける府省共通システムの機能が、実際の業務において、どの程度活用されているか把握し、情報システムの見直しを行うことになりました。 そこで、情報システムが提供している機能を全てリストアップし、府省ごとに利用状況の調査を行い、当該機能を利用して「業務を全て遂行」「他の手段も併用」「全く利用していない」の３段階で回答するよう依頼しました。 回答結果を、機能、府省単位で色分けして可視化したところ、全く利用されていない機能や、ばらつきのある機能などが明確になりました。 
この調査結果と、情報システムから取得した利用ログの集計結果の値を用いて、「全く利用していない」機能は廃止の検討を、「他の手段も併用」は、機能改善検討の対象として効率的に抽出することができました。 |
情報システムのログやトランザクションデータから改善のための情報を取得できるようにする
情報システムのログやトランザクションデータは、「情報システムが何をいつどのように処理したか」を記録として残すことに主眼がおかれがちですが、指標値や改善を検討するための情報を残すという視点も必要です。この視点がないと、運用や保守の作業で分析するための情報を取得することがとても大変になったりします。
しかし、要件定義や設計・開発の時点では、機能を提供することに目が行きがちで、実績に基づいたモニタリングまでを意識した検討ができている情報システムが多くないのが現実です。
運用や保守の作業でデータが取得できない場合やデータ取得に工数が膨大にかかるような場合、情報システムでデータ取得が容易にできないかを検討してみましょう。これらの検討は、標準ガイドライン「第８章 サービス・業務の運営と改善」での検討を踏まえて決定します。
情報システムから正確で詳細なデータを手に入れたことで、効果的な改善を行えた例がたくさんもあります。
なお、サービスや業務の目線で、ログから判別できる指標には、次のようなものがあります。これらを参考に、情報システムで取得できるデータがないかを見直してみてください。
| 参考：サービス・業務の視点で取得可能な指標の例
ログからデータ取得できるが、機能単位等の集計が難しいもの 。これらは、機能ＩＤ等の判別情報をログに付加することで、集計や分析が容易になる可能性があります。 ・ 期間（滞留状況） ・ 頻度（業務ピーク、業務効率） ・ 利用件数、利用率 ・ 情報提供数 嗜好等を含むため、通常の情報システムで取得が難しいもの 。これらを取得するためには、アンケート機能等のデータ取得用の機能が必要になります。 ・ 選好（Ａ/Ｂ分析） ・ ニーズ分析（相関） ・ 満足度 設計時に考慮が漏れがちなもの 。何をどのように記録するかを検討し、記録する機能を作成します。 ・ 不正防止（個人情報は指定された用途以外に記録してはいけません） ・ オープンデータ の利用数 |
情報システムを長期間運用していくと、データ量が増大したり、アクセス数が変化したりすることによって、情報システムのパフォーマンスが悪化することがあります。例えば、データベースの性能一つをとっても、チューニングの良し悪しでレスポンスは何十倍も変わることがあります。
このような場合に、日常的な保守業務の一環としてレスポンスやバッチ処理時間の性能指標を測定して、悪化傾向が見えた場合は、それがシステム障害として顕在する前に対策を行うことが重要です。
Step.5 運用・保守の改善と業務の引き継ぎ
運用保守定例会議等で出た課題や運用・保守事業者から取得したデータから見えてきた改善点は、運用・保守業務の範囲内で解決が可能なものは、積極的に改善を進めていきます。しかし、運用・保守が安定していれば改善を行う余裕があるかもしれませんが、リリース直後やサービス・業務が定着していない時期では、日々の作業が多く改善が難しいことも多々あります。
ここでは、事業者の引継ぎも含めて、改善に係るノウハウをお伝えしていきます。
１ 適切な時期に的確に改善を実行する
【標準ガイドライン関連箇所：第３編第９章第３節】
運用・保守の改善は、Step.3で把握した事実とその分析結果に基づいて、継続的に実施していきます。改善の内容には定常的な作業の範囲内で実施できるものもあれば、契約更新や事業者の交代、ライセンスの切れ目やハードウェアの交換でしか対応ができないもの等、様々なものがあります。
これらは、対応できるタイミングが同一にはなりませんので、以下の点に留意して、確実に改善につなげるようにします。
改善を管理するポイント
・
運用・保守の定常的な作業内で解決が難しい課題は、標準ガイドライン「第８章 サービス・業務の運営と改善」内の問題管理として、どのタイミングで対応するかを明確に管理する。
・事業者の交代やライセンスの切れ目で改善が可能なものは、それによって必要となる変更内容（受注者側の体制、作業項目、工数等）も記録しておく。
| 事例：インシデントの判断基準及び役割分担を見直し
ある府省では、この数か月に起きたシステム異常（いわゆるインシデント）において、見かけ上似たような状況にもかかわらず原因が全く異なるという状況に遭遇していました。これにどのような運用・保守態勢で対応していくかについて悩みを抱えていました。 具体的には、機器の障害が２件、ミドルウェアの不具合１件、情報セキュリティ上の問題２件、アプリケーションソフトのバグが１件。これらはいずれも業務処理性能を著しく低下させる現象を引き起こし、見かけ上はほとんど同じような状況を引き起こしていました。 基盤運用担当のチーフエンジニアにそれぞれのケースを分析させたところ、原因の切り分けには、いくつかの事業者に分かれた重要ポイントをチェック（システムリソース、ネットワーク、セキュリティシステムログ、アプリケーション実行状況等々）し、それらを統合的に把握・判断する必要があることが明らかになりました。 ＰＪＭＯと関係業者で協議した結果、夜間休日を含めて基盤運用担当事業者、セキュリティシステム運用事業者及び業務保守・運用事業者が協働してチェックする手順プロセスを確立しました。この過程において、各業者の役割分担の見直しも行い、オペレーション上の権限範囲も見直しました。合わせて「機器・ＯＳミドルウェア障害」「ネットワーク障害」「アプリケーション障害」「情報セキュリティインシデント」の監視と対応の態勢を見直して、以下の情報連携態勢を構築しました。 ・ インシデント共通の情報連携ネットワーク（運用状況ポータルＷＥＢ、電話、メール、ビジネスチャット）を構築した。これによりＰＪＭＯ、ヘルプデスク、基盤運用事業者、ネットワーク管理事業者、セキュリティシステム運用事業者、業務運用事業者及び業務システム保守事業者がインシデント情報を共有することが可能となった。 ・ 各インシデントの深刻度評価を動的に管理することとし、指示連絡ライン（一次対応指示のリーダーは24Ｈの基盤管理事業者のチーフエンジニア）を一本化した。また、原則として評価値によって行動優先度や夜間休日の対応をコントロールしていくこととした。評価値は、「０」、「０＋」、「１」、「２」、「３」の５段階 ※ とし、事態が流動的な状況では各関係業者のエンジニアが宣言した値のうち最大のものを採用することとした。（※おおよその目安として、「０」と「０＋」は被害なし。「１」はシステム被害、「２」と「３」は業務及び第３者被害発生。） ・ 緊急時（上記の評価値「１」以上の時）には、一定の範囲内で各業者担当範囲外の実施権限（抜線、コマンド投入など、ＰＪＭＯには事後報告で可）を付与することとし、順次担当業者から別の業者に実施方法を伝えていった。 ・ 四半期に１度、緊急性評価値の見直しや緊急対応手順の改善について、職員と関係業者で話し合って、継続的に対応力の強化を図っている。その結果、徐々に各業者エンジニアが判断可能な対応範囲が拡がってきている。 |
２ 要員の交代で情報が欠落しないようにする
【標準ガイドライン関連箇所：第３編第９章第４節】
運用・保守フェーズでは、人事異動による職員や様々な事情による事業者の交代が発生することがあります。交代が職員、事業者のいずれであっても、担当していた期間が短ければ、持っている情報も多くないため影響は少なくなりますが、特定の人物が長期間担当していた場合、ノウハウや情報がその担当者の頭の中だけに記憶され、引継ぐべき情報が欠落してしまうというケースが散見されます。
運用・保守作業には、数年先などの適切な作業時期が到来しないと実施できないものや、細かい作業のため見落としてしまうものもあります。運用・保守フェーズに発生する膨大なタスクを抜け漏れなく管理するためには、ツールの導入等も検討し、職員や運用・保守事業者が交代しても確実に継承されるような工夫が必要です。
| 事例：担当者の交代により次年度で必要な作業が漏れてしまった
ある府省の運用・保守フェーズにある情報システムの運用・保守定例会議において、運用・保守事業者より、あるサーバのＯＳのバージョンアップに伴い、ミドルウェアにパッチ適用が必要になるという報告がありました。ただし、そのＯＳのバージョンアップは次年度以降の予定という情報のみで、具体的な時期については未確定のため、パッチ適用の具体的な作業時期は確定できない状況でした。報告を受けたＰＪＭＯである職員Ａさんは、ＯＳのバージョンアップ時期が確定した段階で、改めて対応を検討することにしました。  その後、職員Ａさんは異動することになり、職員Ｂさんが後任となりましたが、年度が変わっても同一の運用・保守事業者が継続することになったため、職員ＡさんはＢさんへの引継ぎは重要なポイントに絞って行いました。 年度が変わってしばらく経過した後、あるサービスが停止してしまいました。そのサービスを提供しているアプリケーションが稼働しているサーバのミドルウェアが起動しなくなったのが原因でした。更に調査したところ、トラブルの前日にサーバのＯＳをバージョンアップする作業を行っていたことが判明しました。本来はこのバージョンアップに伴い、前任のＡさん担当時に報告されていたミドルウェアへのパッチ適応作業が必要だったのですが、対応が漏れてしまいました。  前任のＡさん担当時に報告された時点で、パッチ適用作業について、運用・保守事業者に継続調査事項として管理するよう指示し、作業が完了するまで関係者が認識できるように記録した上で状況を確認するようにしておけば、このような重要な作業の抜け漏れは発生しませんでした。 |
事業者が交代するとノウハウやドキュメント化されていない情報が抜け落ちてしまうことで作業効率が下がるリスクがあります。また、場合によっては、事業者が情報を持ち逃げするリスクもあり、持ち逃げされた情報を取り戻すために費用が発生するような事例すらあります。
このような事態を避けるためにも、職員や運用・保守事業者の交代時には、以下の点に注意して、情報が抜け落ちてしまうことを防ぎます。
職員や事業者の交代の際に気をつける点
・計画時点で作業に対する成果物を明確化する。作業を実施する場合は、基本的に作業手順書を作成し提出するよう、合意する。
・中間成果物となるようなドキュメント・コンテンツは、維持が必要なもの、維持が必要ないものを明確にしていく。
・運用・保守作業に関係する事項は、職員や事業者の特定の担当者が抱え込むことなく、必ずその作業を担当する事業者が管理するドキュメントに記載し管理する。