Step.4 運用・保守の定着と次への備え

運用・保守の事業者とともに計画の策定が終わりました。あとは事業者にお任せしていれば大丈夫。・・・ということはありません。運用・保守を行っていく中では、日々様々な問題が発生しますし、当初計画した内容では足りないことや改善が必要になることもあります。これらの情報を事業者から適時吸い上げ、改善につなげていくには、いくつかのポイントがあります。

このStepでは、運用・保守の作業を効果的に管理していくことで、サービス・業務をより良いものへ導いていくためのポイントについて解説していきます。

運用定例会議を有効活用する

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

運用・保守フェーズで、ＰＪＭＯが情報システムの状況を確認・把握する場面は、主に運用・保守を実施する事業者が参加して状況を報告する運用保守定例会議が中心となります。しかし、会議に出席して漫然と事業者の報告を聞いているだけでは、事実を捉えて改善を推進していくことはできません。ここでは、運用保守定例会議を有効活用していくためのポイントを見ていきます。

運用保守定例会議で確認する内容を理解する

運用保守定例会議では、運用・保守の計画で定めた報告フォーマットに従って、事業者から基本的には毎回同じ項目の報告を受けることになります。そこでは、外部委託事業者からの報告を受け取るだけではなく、その内容を把握・分析し、根拠が不明なもの、報告が不十分なものは、指摘・再提出も求め、改善活動に繋がる課題や改善点を報告内容から見出し、発注者側がプロアクティブに定点観測する事が大切です。

事業者が「問題なし」と報告している内容でも、「問題あり」に近い「なし」や、状況を把握していないために「なし」と報告しているような場合もあるため、少しでも疑問を感じたら事業者に説明を求めましょう。

また、毎回同じ項目が定期的に報告されるという特徴から、長期間にわたる推移を把握することも可能です。事業者はある時点で切り取った報告を行いますが、その情報を線でつなげて分析し改善に活用しましょう。

いくつかの事例を見ていきましょう。

  • 事例9-6

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

運用保守定例会議では、情報システムのハードウェア、ソフトウェアに関する報告だけではなく、ヘルプデスク等の「人」を対象にした運用に関する報告も行われます。

  • 事例9-7

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

  • 事例9-8

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

これらに共通していることは、「プロジェクトの目標を達成する」「サービス・業務をより良くする」という視点に基づいて、それらの判断や改善に必要となる事実を正しく理解する。という姿勢です。

以下に確認のポイントをまとめます。

運用保守定例会議での確認のポイント

  • 指標値等の基準を明確にし、基準を満たしているのか、満たしていないのか、今後どうなる見込みなのかを確認する。

  • 定常どおりの内容よりも、特筆すべき事項を事業者から引き出す。

  • 定点観測だけでは問題を見落とす可能性がある。時間軸を変えたり、集計の仕方を変えたりする等、様々な視点から状況を捉える。

  • 根拠が不明なもの、主観的なものには注意が必要。エビデンスを求める。

  • ピーク性や今後のイベント等を踏まえて、リスクを確認する。

  • 発生した課題だけではなく、累積している課題に対する対応状況も確認する。

  • ライセンスや保守期限等を確認し、次年度以降の予算要求に備える。

変更を管理し改善活動等の初動を楽にする

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

情報システムを長期間運用していると、運用・保守の作業や機能改修によって、情報システムにたくさんの変更が行われます。これから改善活動や機能改修を検討しようとしたときに初めに行うことは、設計書等から現状の情報システムがどのようになっているかを確認することです。しかし、その設計書は本当に最新の情報システムを反映したものでしょうか？

Step.3-1-H．「運用・保守における変更管理を理解する」で説明したとおり、最新の設計書や情報システムがどのような理由でいつ変更されたかは、運用の変更管理の作業で管理されます。

なお、変更管理の方法には様々なものがありますので、プロジェクトの事情に合わせて、効率的に管理できる方法を検討してください。

変更の管理方法に関する検討ポイント

  • 設計書やソースコード等は変更管理ツールでバージョン等を一元管理することが一般的である。それらの変更管理ツールを、発注者側で管理するか、運用事業者が管理するかは検討する。ライブラリ管理チームを組んで管理することも効果的である。

  • 環境の事情等で発注者側が最新の変更管理ツールにアクセスできない場合、最新の設計書等の授受方法やタイミングを明確に定める。

  • 設計書やソースコード等のバージョンと変更の事由や本番環境への反映記録等の一貫して追跡できるように記録をつける。これらを一貫して管理するツール等も存在するため、導入を検討する。

情報システムで起こった事実を蓄積する

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

運用・保守作業により事業者からデータを収集できました。そのデータを目の前にして、どうしたらよいか困っていませんか？改善を検討するに当たって、本当にその情報だけで十分でしょうか？ここでは、改善を検討する際のデータ収集に関するノウハウを見ていきます。

運用・保守の範囲にとらわれず、意味のある情報を取得する

利用者からの問合せは、実際に対応する人やその結果も様々だと思いますが、どんな問い合わせが、いつ、どこから発生し、どのような結果となったかの一連の流れを記録することを推奨します。これにより、あとで集計したり、分析したりすることが可能となり、どういった問題・ニーズがあるのかを、アンケート等で再収集しなくても取ることができます。

これは、運用・保守業務として、運用・保守事業者に求める業務とは異なります。こちらはシステム側面での問い合わせ・問題・インシデント管理であり、先に挙げたものは業務側面でのものです。

相互に連携する部分もあるため、運用・保守業務の管理情報も併せて収集して、一貫して記録し、集計・分析することで効果をあげることができます。また、分析結果から得られた情報を、利用者が参照できるＦＡＱへ追加し、業務マニュアル等の改訂に活用することも可能です。改善を検討する際は、定点の情報だけでなく、一連の流れに沿った視点も分析してみてください。

  • 事例9-9

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

情報システムの活用状況を詳細に把握し提供する機能を棚卸しする

情報システムは、提供する機能数が多く・複雑なほど、運用・保守コストが増大する傾向があります。特に、長く運用している情報システムでは機能の追加・改修を重ねられていることが多く、その傾向が顕著に現れます。

このことを防ぐためには、定期的に機能の棚卸しをすることにより、肥大化を防ぐことが有効です。

棚卸しをするに当たり、利用者へのアンケート等で業務における利用状況を把握する方法があります。さらに、機能ごとの利用ログを情報システムから取得し、分析することでより厳密に利用状況を把握することも可能です。

これらの情報を踏まえて、機能の廃止・縮小対象の検討がより具体的に行えるため、定期的な棚卸しを行うようにしてください。

  • 事例9-10

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

情報システムのログやトランザクションデータから改善のための情報を取得できるようにする

情報システムのログやトランザクションデータは、「情報システムが何をいつどのように処理したか」を記録として残すことに主眼がおかれがちですが、指標値や改善を検討するための情報を残すという視点も必要です。この視点がないと、運用や保守の作業で分析するための情報を取得することがとても大変になったりします。

  • 図9-5

目標・指標・データの関係性のイメージ

しかし、要件定義や設計・開発の時点では、機能を提供することに目が行きがちで、実績に基づいたモニタリングまでを意識した検討ができている情報システムが多くないのが現実です。

運用や保守の作業でデータが取得できない場合やデータ取得に工数が膨大にかかるような場合、情報システムでデータ取得が容易にできないかを検討してみましょう。これらの検討は、標準ガイドライン「第８章 サービス・業務の運営と改善」での検討を踏まえて決定します。

情報システムから正確で詳細なデータを手に入れたことで、効果的な改善を行えた例がたくさんもあります。

なお、サービスや業務の目線で、ログから判別できる指標には、次のようなものがあります。これらを参考に、情報システムで取得できるデータがないかを見直してみてください。

  • 参考9-5

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

情報システムを長期間運用していくと、データ量が増大したり、アクセス数が変化したりすることによって、情報システムのパフォーマンスが悪化することがあります。例えば、データベースの性能一つをとっても、チューニングの良し悪しでレスポンスは何十倍も変わることがあります。

このような場合に、日常的な保守業務の一環としてレスポンスやバッチ処理時間の性能指標を測定して、悪化傾向が見えた場合は、それがシステム障害として顕在する前に対策を行うことが重要です。

運用・保守実施記録を適切に保管する

発注者が運用・保守事業者に対して一定期間の運用・保守実施記録の保管を指示していない等、情報システムのアカウントの管理を運用・保守事業者に丸投げしている場合には、いざという時に必要な記録が参照できず、不正、障害等の原因が究明できない等の問題が生じる可能性があります。

上記のリスクを低減する方法として、情報システムのログやトランザクションデータを適切に取得・保管すること等が挙げられます。

  • 注記

    特権IDとは、 情報システムを運用・管理するために必要なすべての操作権限を持つ管理者用アカウントのこと。WindowsのAdministratorやLinuxのrootなどが該当する。悪意を持った人が特権IDを使用した場合、不正やセキュリティ上のリスク等が懸念されるため、発注者の責任の下、特権IDの取扱いには十分に注意が必要である。

機密性・完全性・可用性の観点から特に重要な情報を取り扱う場合においては、発注者が特権ID管理を適切に実施することが重要で、事業者の作業計画に基づいて作業の度に特権IDを発注者が事業者に付与する運用とするのが望ましいです。

アカウントの管理や情報の保管は、情報システムの特性に応じて、「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」や特定非営利活動法人日本ネットワークセキュリティ協会の「【改定新版】特権ID管理ガイドライン」を参考にしながら、事前に十分に検討した上で、実施してください。