Step.3 運用・保守の計画

運用・保守を担当する事業者が決まったら、事業者とともに調達仕様書で示した内容から、運用・保守の詳細な作業内容や実施方法等を検討し、計画書と実施要領として明文化します。これらは、運用・保守の作業はこの計画に基づいて実施することとなるため、作業が漏れたり不十分だったりすると後々問題を引き起こすこともあります。

ここでは、運用・保守をトラブルなく円滑に進めていくための計画策定のポイントを、紹介していきます。

運用と保守の計画を作成する

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

この実践ガイドブックには、別添として、運用計画書、運用実施要領、保守計画書、保守実施要領のひな形を示しています。

様式例9-1

運用計画書、運用実施要領、保守計画書、保守実施要領のひな形

このひな形はあくまで例示ですので、運用の内容に応じて記載内容を個別に追加、変更して構いません。ひな形を見ると、何をどのようなレベルで書くべきかの参考になると思います。

以降では、運用計画書・運用実施要領を作成するときに、特に注意が必要なポイントについて説明していきます。項目の詳細な説明は、ひな形を参照してください。

注記

システムプロファイルとは、「標準ガイドライン　別紙５　システムプロファイルに係る定義について」に基づいて定義する情報システムの信頼性の水準のこと。

システムプロファイルに応じた運用・保守レベルにする

運用や保守の体制や作業は、サービス・業務の内容や重要度等によって、適切なレベルを設定し、適切な費用で効果的な運用・保守となるように心掛けましょう。しかし、適切なレベルとはなんでしょうか？

運用や保守のレベルの基準となるのは、要件定義書で定められた「システムプロファイル」です。

サービス・業務を開始した直後から運用や保守が安定するまでの一定期間は、予期せぬ障害に備えて手厚い運用・保守体制をとることがしばしばあります。この手厚い体制を維持する期間は情報システムによって様々ですが、システムプロファイルで示した運用・保守レベルを維持できる最低限の体制を基準として、プロジェクトの状況に応じて定期的に見直しを行い、徐々に適切なレベルの保守・運用にしていくように調整していきましょう。

セキュリティ関連作業を定期的に確実に実施する

セキュリティ管理に関する要件は、非機能要件で示され、運用・保守フェーズでは、その方針に沿ってアプリケーションやインフラでの対策が講じられている状態にあります。昨今のセキュリティに対する脅威は日々増大しており、運用・保守フェーズでは、設計どおりの対策が維持できるよう、日々確実に作業を続ける必要があります。

以下に定期的に実施すべき作業の例を挙げます。

セキュリティインシデント発生時の記録、対応、影響範囲の把握
脅威と修正パッチ適用計画の立案・調整
シグニチャ、ブラックリスト（ホワイトリスト含む）更新
ＯＳ及びプラットフォーム等の緊急修正計画の立案・調整
セキュリティ向上のための業務改善と利用規制検討
中長期的プラットフォーム改善に向けた、システム構成要素のリスク評価

プロジェクトの目標や指標の評価に必要なデータは必ず取得する

Step.2-2-Bの「指標の基礎データを誰がどのように集めるかを明確にする」のとおり、目標や指標値を定期的にモニタリングできるよう、運用作業として取得しなければいけないデータについては、以下の観点で運用の計画書と実施要領に明確に記載しましょう。

表9-3

運用計画書、運用実施要領におけるデータ取得に関する記載内容例

運用作業で取得したデータは、標準ガイドライン「第８章サービス・業務の運営と改善」で使用する以外にも、今後の機能改修やサービス・業務の見直し時の分析データとして使用できるよう、報告資料だけではなく、データ自体を加工や集計が可能な形式で受け取るようにしましょう。そのためには、運用計画書及び運用実施要領に記載された内容から、要員に依存せずにデータを取得できるよう、データ取得手順書の作成を運用事業者に求めてください。

また、これらのデータを保存する手段や期間に関する考慮も重要です。数年に渡る傾向分析等に必要な情報は長期間保存が必要ですが、週次で集計値を算出した後は不要となる詳細データは、無闇に保管するとストレージ等の無駄が生じます。クラウドサービスを利用している際はデータ保存量がコストに直結する場合もあるため、迅速かつ頻繁に参照したいデータは取り出しやすい媒体に保存し、緊急性のないデータは外部媒体に保管する等の工夫を行いましょう。

非機能要件に関連するデータを網羅的に詳細に取得する

サービス・業務を円滑に運営するためには、標準ガイドライン「第５章要件定義」で定めた非機能要件に従って、情報システムを安定的に稼働させ続けることが必要になります。

このためには、現時点で情報システムが非機能要件で定めた指標値を満たしているかを確認することはもちろんですが、将来的に要件を満たせない、維持コストが増大する等のトラブルが発生する予兆を捉えることが、とても大切です。また、日次や月次等の定点的な観測だけではなく、確認したい内容ごとにどのような間隔でデータを取得するかを検討し、取得できる仕組みを設け、必要な情報が必要な粒度で取得できるように備えておきましょう。

非機能面のチェックは様々な観点がありますが、次にあげるポイントはとても重要ですので、必ず確認できるように、運用作業に持ち込んでください。

非機能要件に関連するデータの確認ポイント

データ量 データベースやファイルシステムの使用率等を時系列で確認し、傾向から将来容量が枯渇するおそれがないかを確認します。
処理時間 機能単位、時間単位等の複数の視点からレスポンス時間等の処理時間を確認することにより、安定的に処理を行えているか、処理が遅くなる傾向等が見られないかを確認します。また、バッチ処理時間も時系列で確認し、将来的に完了予定時刻に遅れる予兆等がないかを確認します。
リソース状況 ＣＰＵやメモリ等が異常な状態になっていないか（高負荷状態が続いている、ほぼ使用していない等）を確認します。これらも、サーバ単位、時間単位で詳細に取得して、傾向を確認します。

これらのデータを蓄積していくことで、情報システムを更改する際に、サーバの構成・スペック等の精査が簡単に行えるようになります。また、クラウドサービスに求めるサービスレベルの検討にも活用できます。これらの情報についても、報告資料だけではなく、データ自体の提出を求めるようにしましょう。

会議体は目的を明確にして必要最低限に抑える

運用・保守フェーズは、複数の職員や事業者が関わるため、会議体の種類がどうしても多くなる傾向があります。中心的な役割を担うＰＪＭＯの職員や事業者の担当者は、会議出席に拘束されてしまい、本来行うべき作業に手が回らないという状況に陥りがちです。

そのような状況にならないために、会議体の目的を整理し、必要な出席者を事前に選抜するようにしましょう。以下に主要な会議体の種類と主な目的を示します。

表9-4

会議体と主な目的・内容例

会議体選択の考え方

日次会議は、情報や状況把握の正確性確保と関係者間の問題解決事案の引継ぎが主目的である。短時間で効率的に実施することが肝要である。この会議では、運用状況・保守作業状況及び問題解決の進行状況が取り上げられるので、できる限りＰＪＭＯが参加することが望まれる（毎日出席はできなくても週に１回ランダムに出席することを推奨する）。
月次の定例会議は、できる限り開催する。ＰＪＭＯ側と事業者側の双方の責任者が出席し、マネジメントレベルの状況判断、方針及び約束等をオーソライズする場とする。できれば、調達時点で必須報告事項を仕様として提示することが望まれる。
セキュリティ対策会議は、インシデント事案の最終評価・対応方針の周知、確実な脆弱性対策実施及び運用上の懸念事項の吸い上げが目的である。目安として利用者が数百人以上のシステムにおいては、四半期に１度程度は開催することが望まれる。
業務・システム運用改善会議は、運用関連業務の受託事業者が「仕様書：改善提案業務」の成果発表を行う位置づけとすることを推奨する。この会議では、事業者から出てくる改善提案にＰＪＭＯが誠実に対峙し、協働して前向きな改善に持ち込めるかどうかが重要。
その他非定例会議は、必要の都度開催することとなる。ポイントとしては、事前に会議の目的と到達目標、テーマ及び各参加者の役割を周知しておくとことが望まれる。

定例会の報告フォーマットを指定して、効率性を上げる

運用や保守を行う事業者は、多くの場合、独自の報告フォーマットを持っています。「自社フォーマットを使用することで効率的に運用・保守の報告を行える」という主張は理解できますが、ＰＪＭＯが報告してほしい情報がそのフォーマットに含まれていなかった場合、その情報を把握できない可能性があります。また、複数の情報システムを有する大規模プロジェクトにおいて、複数の運用・保守事業者が活動を行う場合に、それぞれの報告フォーマットが異なったらどうなるでしょうか？横並びでの確認が困難になりますし、分析が非常に難しくなり改善の妨げになるかもしれません。

これらを防ぐために、事業者からの報告フォーマットはＰＪＭＯが指定したものを使用するよう、調達仕様書であらかじめ方針を示しておきましょう。運用・保守事業者の決定後、詳細な報告項目について更に調整を行います。この際、報告書作成に特定のツールを利用しているため、指定したフォーマットで報告することが著しく非効率になる等の場合は、ＰＪＭＯが求めた内容が必ず含まれるよう、事業者にフォーマットを確認し、盛り込むべき内容を合意してください。

事例9-3

定例会の報告フォーマットを統一し報告内容の分析向上

運用・保守の工数を把握し、人件費をモニタリングする

情報システムに係る経費は、情報システムを構築するまでの費用よりも、運用・保守フェーズ期間にかかる費用の方が多いことがよくあります。運用や保守のどの作業にどの程度の工数がかかっているかを定期的に把握していなければ、費用はかかったが求めた内容があまりできなかった、という結果にもなりかねません。

運用・保守フェーズの作業はとかく事業者にお任せになりがちで、報告内容もざっくりと「作業一式」で済まされてしまうこともありますが、管理に必要となる詳細な報告を求めましょう。事業者は個別のエンジニアの工数管理は労務管理上実施しているはずですので、求めれば応じられる管理情報は持っています。

実際の工数を正確に把握していれば、的外れな対策を行うリスクもなく、効率的にコスト削減を行うことができます。低コストで効果的な運用・保守に改善していくためにも、作業ごと、要員ごと等の詳細な工数データを取得できるよう、事前に事業者と調整し、運用の作業の一部として計画に盛り込み、運用保守定例会議で報告を受けるようにしましょう。

事例9-4

運用・保守の稼働工数を実績に基づいて分析し削減に成功

この事例のような考え方は、運用・保守フェーズで実施する機能改修にも応用できます。

例えば、機能改修を行う際に、改修による影響度を調査した上で、発注者と受注者でテストのスコープや実施方法等の方針を協議することで、効率化又は削減できる作業を特定できるようになり、工数を削減することができる場合があります。特に、運用・保守フェーズでは、障害発生時に次回以降同じ障害を繰り返さないためにテスト項目が追加されたり、改修を行わない部分に対するリグレッションテストを大量に実施することでテスト項目が増加したりして、多大なテスト工数が必要となる場合があります。その対策として、過去のテストシナリオの再利用やテストの自動化等を行うことで、テストの効率性を高めることができます。加えて、機能改修の特性を踏まえて、見積りの精査、不要と思われるテスト項目の除外、機能改修による影響範囲の特定などを実施することで、過剰な工数を削減することができます。

また、改修規模や機能改修にかかった実績工数を報告させるようにすることで、次回以降に同様の規模の機能改修を行う際に、その工数の妥当性を確認し、工数削減につながる場合があります。

事例9-5

ハードウェア保守費を実績に基づいて分析し削減を実現

運用・保守における変更管理を理解する

運用・保守フェーズでは、基本的にはその時点で提供しているサービス・業務を変えることなく、情報システムを維持し続ける活動を行います。現状を維持するためには、変えないことが最も安全な方法で、何か変更するということは、何らかのリスクを伴います。現状維持するだけであっても、最低限必要となる変更作業は存在するため、その作業を適切に管理し、安定運用を継続する「変更管理」の活動は、とても重要です。

運用と保守で行う変更管理の対象は、大きく２種類に分かれます。

変更管理の対象の分類

作業に係る情報への変更管理 運用の要件定義書、調達仕様書、運用計画書、運用実施要領、作業手順書等。
*情報システムを構成する資産等に対する変更管理* 設計書、ソースコード、マニュアル等。ライブラリ管理と呼ばれることもある。

特に、後者については、運用と保守で管理する内容が重複することもあり、混乱しがちですが、以下のような違いがあります。

運用と保守の変更管理の違い

運用の変更管理では、誰が修正するかに限らず、情報システムを構成する全ての資産とそれに対して行われる全ての変更を管理する。つまり、これを確認すれば、情報システムに対して行われた全ての変更について、「いつ」「誰が」「何の理由で」「何を」変更したかを確認することが可能。
保守の変更管理では、保守事業者の保守対象となる設計書やソースコード等に関する変更を管理する。

運用の変更管理は、情報システムの全ての変更情報を管理する必要があるため、保守事業者が複数いる場合であっても、統一的に管理する必要があります。そのため、変更フローを明確に定めて、情報システムに変更を行う可能性のある全ての事業者に対して、周知徹底する必要があることに注意してください。

以下に、参考として、変更管理のフローの例を記載します。

図9-4

変更管理のフローの例