Step.2 運用・保守を開始するための事前準備

情報システムが完成したら、サービス・業務を滞りなく提供していくために情報システムをきちんと運用・保守していかなければいけません。しかし、情報システムの運用や保守は、専門的な内容が多いため、気が付いたら膨大な費用がかかり、プロジェクトの目標も未達成だった、ということもしばしばあります。

でも、安心してください。運用・保守を開始する前に、いくつかのポイントを押さえて事前に計画すれば、このような事態を防ぐことができます。

では、より良い運用・保守を行うための事前準備のポイントを、紹介していきます。

１ 「運用と保守」の位置付けを理解する

【標準ガイドライン関連箇所：第３編第９章第１節】

情報システムの「運用」と「保守」はよく耳にする言葉ですが、その目的や違いを知っていますか？また、運用・保守とよく混同する活動に「サービス・業務の運営」や「機能改修」もあります。これらの違いや関連性を理解していないと、責任範囲や実施内容が曖昧になり、効率的で効果的なプロジェクトの運営を行っていくことができません。

ここでは、運用・保守の位置付けを説明していきます。

A. サービス・業務をより改善するための活動を行う

情報システムの開発と移行が完了して新たなサービス・業務を開始した時点は、プロジェクト当初に掲げた目標・目的を達成するためのスタート地点に立ったにすぎません。また、サービス・業務を支援する情報システムも、その時点で100％の出来ではなく、発展途上の状態である場合もあるかもしれません。リリースまでは想定に基づき業務要件、機能要件を定めてきましたが、運用・保守フェーズに入った後は、実際の利用状況等を継続的にモニタリングして、利用者の行動等を把握することが可能となります。これらをしっかりと把握して、より効果的・効率的なサービス・業務に改善していくことにより、国民や業務実施部門をはじめとした政府職員にとって、よりメリットをもたらす情報システムに成長させることができます。

それでは、効果的なサービス・業務を実現するためにはどうすれば良いのでしょうか。効果的なサービス・業務を実現するためには、運用・保守フェーズにおけるヒヤリ・ハット（インシデント）を多く見つけ、改善を繰り返すことが重要です。

労働災害の経験則として、ハインリッヒの法則があります。これは、1件の重大事故の背景には、重大事故に至らなかった軽微な事故が29件あり、更に事故には至らなかったが事故寸前の、ヒヤリ、又はハッとしたインシデント（ヒヤリ・ハット）が300件隠れているというものです。また、重大事故を防ぐための考え方として、ドミノ理論があります。ドミノ理論では、重大事故に至るまでの過程をドミノのように連鎖的なものとして考えます。その過程で発生するヒヤリ・ハットを見過ごすことなく、適切な対応策を講じることで、ドミノ倒しの連鎖を止め、重大事故を防ぐことができます。

• 図9-1

これは情報システムの運用・保守作業においても同じです。例として、情報システムの改修等により操作手順に変更が生じたものに対して、政府職員の操作マニュアル等のドキュメントを適切に管理していなかったために、誤った作業を実施してヒヤリとしたインシデントを考えてみましょう。この時は、業務影響を及ぼすような事故はなかったかもしれません。しかしながら、国民へのサービス提供に関与する作業を実施していた場合は、提供しているサービスに不具合が生じる等、重大事故につながるかもしれません。ヒヤリ・ハットはそのままにせず、ドキュメントの構成管理の手順を見直し、類似のインシデントに繋がらないように再発防止策を講じることで、未然に重大事故を防ぐことができます。

情報システムの運用・保守フェーズにおいては、設計・開発フェーズのテスト不足が原因でインシデントが起こることが多くあります。サービス・業務に影響を与えるような重大事故に繋げないためにも、発生したインシデントを記録し、将来的な機能改修やシステム更改に当たってテストシナリオ等を検討する際のインプット情報にし、テストの有効性を高めましょう。また、サービス・業務の効率化によるコスト削減は、関係する人員削減とイコールではありません。より人間にしかできない業務に人的リソースを振り分けることで、今まで手が回らなかった業務に対応できるようになるため、より良いサービス・業務を実現していくことができます。

運用・保守の心得

• 運用も保守も、サービス・業務をより良くするための活動の一部。

• 目標、指標に関連する情報をモニタリングして、改善につなげる。

• ヒヤリ・ハットに着目し、改善を繰り返す。

• 効率化は人員削減によるコスト削減につなげるだけなく、他の活動に活かしてさらなる価値を生み出す。

B. 情報システムの運用と保守の活動を理解する

情報システムの「運用」も「保守」も、根本となる目的は同じです。シンプルに表現すると、稼働している情報システムを「健全に保って活動を続けさせる」ことです。

運用と保守の目的

• サービス・業務の提供価値を高め、継続して行えるようにする。

• この目的を達成するために情報システムを安定稼働させ、一連の作業が滞りなく進むように維持する。

その共通の目的のもと、運用と保守には次のような違いがあります。

運用とは何か

運用とは、上記の目標を達成するための「情報システムの機能を利用者に提供し続けるための活動」です。情報システムの稼働状態を維持するための作業が主となりますが、情報システムを相手にするだけではなく、ユーザサポートのように「人」を相手にする作業もあります。作業を大きく分類すると以下に示すものがあります。詳細は、標準ガイドライン解説書「第９章 運用及び保守」の表9-1を参照してください。

• 表9-1

運用作業の分類

保守とは何か

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

• 表9-2

保守作業の分類

• 参考9-1

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

C. 運用・保守は他の様々な活動と連携し、並行で実施する

運用と保守の活動は他の活動のいろいろな作業と関係しています。最も関係性があるのは標準ガイドライン「第８章 サービス・業務の運営と改善」で、運用・保守とは表裏一体との関係にあります。これらの関係を図9-2に示します。

• 図9-2

標準ガイドライン本編における運用及び保守活動と他の活動との関係

「サービス・業務の運営と改善」の活動で、ＫＧＩ・ＫＰＩがどの程度満たされたかを判断するための指標を算出する作業を行いますが、この作業に必要な根拠情報を提供するのが、「運用と保守」の重要な作業の一つです。根拠情報には、システムログやトランザクションデータ等の情報システムで取得可能なものと、サポートデスク等で人が介在して取得するものがあります。そのため、これらの情報取得作業は、運用保守作業の一つとして確実に作業に組み込み、必要な情報が必要なタイミングで取得できるように整備しておく必要があります。

• 事例9-1

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

上記のような例もそうですが、運用・保守を実施していく中で発生した問題に対して、運用・保守の範囲だけでは解決できないこともあります。そのような場合は、標準ガイドライン「第８章 サービス・業務の運営と改善」に課題を集め、サービス・業務の内容も含めて改善を検討します。（※これはＩＴＩＬが定める問題管理に相当します。）

また、「サービス・業務の運営と改善」で集めた課題に対して、既存の機能の修正や新たな機能の開発が必要になることがあります。これらは「機能改修」と呼ばれます。プログラムに修正が入る点では「保守」と似ていますが、保守における修正は、サービス・業務の開始時点で定められた設計どおりに動作させるためのものである点に注意してください。

D. 運用・保守に、自動化の仕組みを取り入れる

情報システムの運用・保守は、従来は人が目視確認や手作業で実施してきましたが、人による体制で運用・保守を行うと人件費がかさみ、運用保守のコスト増となります。

現在では、通常システム運用管理ツール等を導入して自動化による効率化を図っています。ただ、これらのツールを導入してライセンスを購入したにもかかわらず、実際にはこれらのツールの機能をほとんど使っておらず、結果として人手による運用作業が多く残っているケースも多くみられます。

以下に、より効率の良い自動化を進めるために検討すべきポイントと例をまとめます。

自動化を進めるためのポイントと例

• 手順が定まっている作業の自動化

  セキュリティパッチアップデート、プログラム更新、データ更新等を自動的に行うプログラムや設定を準備しておく事で正確かつ実施効率を上げる方法です。

• 定量的な監視設定と通知・連絡の自動化

  アクセス量が制限値を超えた時や、サーバのメモリやディスク容量等があらかじめ設定した値を超えた時、あるいはネットワークや機器の故障があった際にメールやSMS、電話等で自動的に関係者に通知・連絡する方法です。従来はメールのみによる通知が主でしたが、SMSや電話での通知を取り入れることで、より素早い連絡とその後の対応ができるようになります。

• 経験者の目視に頼っていた判断・制御の自動化

  アクセス状況やサーバリソースのグラフの異常傾向の検知、不審な大量アクセス等の検知をAI等の機械学習を利用して実施し、初期判断（運用・保守担当者へのエスカレーション）に用いる方法です。上記「定量的な監視設定と通知・連絡の自動化」 のような設定値の超過ではなく、時間推移による急激な変化によるリスクを判断するという「経験者の暗黙知」を自動判断にすることで稼働時間を抑えられるようになります。また、検知後の制御・対応も自動実施することも可能になります。

E. システム間での運用統合を検討する

各プロジェクトで複数のシステムを運用している場合に、それらの運用業務には重複する作業が多数発生していることがあります。

このような場合に、複数システム間での運用を統合することも検討してみたいですね。

運用経費の総額を減らすということも一つの目的ですが、それだけではなく、個々の職員が運用作業に振り回されている現状を改善できるかもしれません。

運用業務の統合に際しては、なるべく統一したオペレーションが行えるように検討・調整することが大事です。たとえば、ハードウェア、ネットワーク、アプリケーションプログラム等のそれぞれの層ごとに、発生している運用業務を把握してみましょう。

すると、監視内容については各システムでほとんど似通っている一方で、障害を検知した後のエスカレーション先はそれぞれ異なっているなど、共通点と相違点を区別して把握することができます。このように、運用業務の現状を把握できれば、統一したオペレーションへの第一歩を踏み出すことができるかもしれません。

また、統合運用を実現する際に、運用管理システム（ジョブ管理、システム監視、構成管理等）がばらばらだと共通化できる作業が少なくなってしまいます。運用管理システムを統一することもまた一つの検討事項です。

• 事例9-2

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

２ 作業責任を正しく理解しトラブルを防ぐ

【標準ガイドライン関連箇所：第３編第９章第１節】

運用・保守の活動やそれに係る「サービス・業務の運営と改善」等の活動には、様々な関係者が関わります。それぞれの作業内容や責任範囲が曖昧になってしまうと、作業漏れや関係者間の意思疎通が不十分となることによる新たな問題が発生するリスクが増大します。悪くすると、情報システムの安定的な稼働への問題発生、改善活動の停滞などを招き、プロジェクトの目標達成に影響が出てしまいかねません。

ここでは、運用と保守に関係する関係者と各々の作業責任内容を定めて、円滑に作業を進めていくためのポイントについて、ご紹介します。

A. 外部委託事業者へ依頼する作業の内容を明確にする

「運用」及び「保守」に係る作業は、基本的に外部事業者に委託して実施します。その理由は、内容が専門的であることや、手順に沿った定型かつ大量な作業が多いため、ＰＪＭＯや業務実施部門の職員が実施すると、かえって非効率になる可能性があるためです。「餅は餅屋」の言葉どおり、外部事業者と役割を適切に分担することにより、発注者側の職員は、業務の質の向上やコスト削減等の、本来職員が行う事業者では実施できない作業に、より注力することができます。

外部事業者に依頼する作業や役割は、調達の段階で調達仕様書に明記しておく必要があります。事業者確定後にこれらの詳細を詰めようとすることは、トラブルの原因となりますので、注意してください。

それでは、調達仕様書にはどのような項目を定義すればよいでしょうか？

基本的には、定型的な作業は標準ガイドライン「第７章 設計・開発」において、運用設計・保守設計として洗い出されているため、それがそのまま調達仕様書の付属資料として、作業要件になります。しかし、次に示すような項目は、重要な内容にもかかわらず見落とされがちなため、明記されているかもう一度確認してみましょう。

• 注記

ＣＳＩＲＴとは、シーサート (CSIRT: Computer Security Incident Response Team) とは、コンピュータセキュリティにかかるインシデントに対処するための組織の総称。http://www.nca.gr.jp/

• 注記

システムリストアとは、何らかの原因で不具合が発生した情報システムを、正常に稼働していたある時点の情報システムの状態に戻すこと。

• 注記

ブラックリスト・ホワイトリストとは、フィルターをかける対象を「リストに記載されていたらＮＧとする」ものがブラックリスト、「リストに記載されているものだけをＯＫとする」ものがホワイトリスト。

• 注記

シグニチャとは、ウイルス対策ソフトやファイアウォール等、コンピュータウイルスの進入を防ぐソフトウェアにおいて侵入を検知するために識別しているコンピュータウイルスなどに含まれる特徴的なデータの内容や、攻撃者が持つ特徴的な受信データのパターンのこと。

• 参考9-2

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

B. 指標の基礎データを誰がどのように集めるかを明確にする

指標に用いるデータ取得のための作業は、標準ガイドライン「第８章 サービス・業務の運営と改善」の作業と密接に関連します。サービス・業務の運営と改善では、プロジェクト計画書で定めたプロジェクトの目的・目標が実現できているかに関して、いくつかの指標（ＫＰＩ）を用いて判断し、業務の改善や見直しを行います。指標（ＫＰＩ）は、基礎値の組み合わせによって、表されます。

指標（ＫＰＩ）の例

指標の基となる各種データは、種類ごとに、取得先、取得手段、取得頻度等について詳細な検討が必要です。代表的なデータとして、情報システムが稼働している際に作り出されるログやトランザクションデータと呼ばれるものが挙げられます。これらは、職員が自ら取り出せるもの、運用事業者に依頼しないと取り出せないもの等、データの取得には制約が発生します。前者であれば、事前に技術的な経験のない職員でも容易に取得できるように、取得手段が機能化されている必要があり、後者は対象と取得手順が明確に定義されていなければ、定常的な運用作業として継続できません。

これらを踏まえて、取りこぼしが発生しないよう、必要なデータ項目を事前に把握するとともに、外部事業者に取得を求める場合は調達仕様書に明記しておきましょう。

• 参考9-3

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

指標は、いざ算出しようしたときに、算出根拠となる基礎情報が不足していることが判明し、その情報を追加入手するためには想像以上に困難であることに気付くことがあります。特に、ある分析結果からより多角的な分析が必要になった場合、特定の情報の付加情報として「区分」や「属性」等、より詳細な情報が求められることがあります。このような情報は、事前に取得・保管する仕組みが備わっていなければ、その時点から遡ってデータを取得することが不可能なこともあります。また、取得可能だったとしても、多くの手間を必要とする場合もあり、そのようなデータは頻繁なモニタリングが敬遠され、結果として指標が適切な時期に算出できず、対策が遅れてしまうことにもつながりかねません。

運用・保守を開始してからトラブルとならないよう、事前に具体的なモニタリングの方法や役割分担を検討し、事業者に依頼する場合は調達仕様書に作業内容を明記してください。

また、平均値を指標とするときは、集計対象の種類や内容が同種のもので平均値を算出するようにし、異なる性質のものを混合して値を算出しないようにしましょう。

• 参考9-4

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

C. 業務実施部門を含めた運用体制を確立する

情報システムの各種テストが完了し、後は本番リリースを迎えるだけという状態に準備が整い、運用・保守フェーズをお任せする事業者が確定したら、サービス・業務を利用者に提供するまであと一歩です。運用・保守フェーズでは、最初に司令塔となるＰＪＭＯを含んだ運用統制を行うチームを構築し、プロジェクトを管理していくことになりますが、円滑な運営を進めるための注意点があります。

それは、業務実施部門（主に当該情報システムの業務統括部門）とのコミュニケーションと役割分担です。

業務実施部門には、情報システムを用いて実際に業務を行う職員が集まっています。この多くの職員に、プロジェクトの目的・目標を理解してもらうことは、標準ガイドライン「第８章 サービス・業務の運営と改善」で触れたとおりですが、運営に入ってからは次の点に気を付けて実施してください。

業務実施部門との役割分担・コミュニケーションで気をつける点

• ＰＪＭＯには、業務実施部門の担当者が参画するよう、組織を組成する。運用・保守に関わる定期報告会では業務実施部門の担当者（代表者）が参加した上で、常に情報を共有できるようにする。

• 日常的に、現場業務で発生した問題や状況に関する情報がＰＪＭＯに伝わるよう業務実施部門の担当者とのコミュニケーションルールを明確にしておく。

業務実施部門とＰＪＭＯとの関わりについては、プロジェクト立ち上げ時のＰＪＭＯの組成にまで遡ります。そこでは、基本的にＰＪＭＯには制度所管部門及び情報システム部門とともに、業務実施部門の担当者が参画することが望ましいことが言及されています。

これまでは、新しいサービス・業務の要件を定めるために、業務実施部門の職員から意見・要望を収集することが主でしたが、サービス・業務の運営フェーズになると、コミュニケーションの流れが、収集だけではなく、業務実施部門からの情報提供が加わります。

利用者からの意見や要望を把握するためには、最も接点が多い業務実施部門の職員からの情報提供が欠かせません。また、運用・保守で発生した報告内容には、利用者からの問い合わせや発見した不具合、不具合修正に伴う情報システムの稼働停止連絡等、様々な情報が含まれます。これらを業務実施部門と共有することにより、業務実施部門の中で必要な調整や対策を行い、今後問題を引き起こすリスクを低減させることが可能となります。

そのためにも、プロジェクトの情報が集まるＰＪＭＯへの参画、定期報告会への必要な人員の出席、代表者から業務実施部門の関係者全員への情報伝達手段などを、運用及び保守が開始する前に取り決めておきましょう。

D. 障害発生時の役割分担に注意する

障害が発生しない情報システムは、ほぼありません。大切なのは、障害が発生した際に適切な対応を取ることで被害を最小限に留め、暫定対策から恒久対策を実施し、将来にわたって同じ又は同じような障害を発生させないようにすることです。恒久対策の実施に当たっては、PJMOは事業者に対して以下の根本原因分析、横展開確認、再発防止を依頼し、報告を求めます。事業者から報告を受けたら、PJMOは当該報告について当該事業者へ疑問点を確認して、根拠に基づいた納得感のある報告となっているかを確認します。これは障害が発生した場合に限らず、プロジェクトの全工程を通じて求められます。なお、障害の原因がPJMO側にある場合（要件定義の不備、レビューの見落とし、情報資産管理の不備等）も、PJMO内で同様に根本原因分析、横展開確認、再発防止のプロセスを実施することが重要です。

• 根本原因分析 表層の理由だけでなく、深層の原因（真因）にまで深掘りして調査すること。

• 横展開 発生した障害や不具合等と同じ原因の、他の障害等が潜在していないかを確認し、是正すること。

• 再発防止 障害等自体に対策を行って終わりとするのではなく、根本原因に対し対策を行うことで、二度と同様の障害等が発生しないように解決すること。

上記のプロセスを適切に実施するためには、障害対応という急を要する状況の中でも、ＰＪＭＯ、運用の事業者、保守の事業者、その他の関係者が適切な役割分担の下に協働して対応を進めていくことが必要になります。運用と保守の事業者が異なる場合や運用・保守それぞれを複数事業者で分担して実施する場合もあり、役割や責任が曖昧になることで対応が遅くなってしまうことや被害が拡大してしまうことも少なくありません。

まずは、障害発生時における運用と保守の基本的な役割分担を理解しましょう。この考え方を踏まえた上で、プロジェクトの体制や特性を踏まえて、詳細を決めていきます。

極端な例ですが、ＰＪＭＯの体制が１名の場合は、24時間365日稼働するサービスへの対応は十分にできません。どのようなタイミングで障害が発生するかは予想できないからです。深夜や休暇取得中等、ＰＪＭＯが対応できない状況が存在することを前提に、運用事業者・保守事業者と役割分担を検討する必要があります。

• 図9-3