Step.5 見落としがちな活動に注意

設計・開発の活動は、情報システムを構築する作業だけではありません。本番の環境で情報システムを稼働するためには、データの設定、既存サービス・業務や情報システムからの切替え等や運用・保守の作業を行わなければいけません。これらは情報システム自体の設計・開発と同時に検討していくことがとても大切ですが、見落とされがちになってしまうと、後々大変な思いをすることになります。

ここでは、情報システム自体の設計・開発以外に必要な活動についての知識やノウハウについて、紹介していきます。

どのプロジェクトでも必ず移行を計画する

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

情報システムの移行は、どのようなプロジェクトでも必ず発生します。既存のサービス・業務や情報システムが存在しない場合でも、本番の情報システムの構築、データの設定、切替え、新規業務の開始に関わる業務の変更等は必ず必要です。

ここでは、これらの移行に関するポイントを見ていきます。

移行の種類を理解する

「移行」と聞くと、データの移行や情報システムの切替えは思い付くかもしれませんが、移行はそれだけではありません。移行は、大きく分類すると「システム移行」「データ移行」「業務移行」の３種類があります。

表7-18

移行の種類

特に、業務移行は、ＰＪＭＯが主体となって業務実施部門と調整しながら、進めていく必要があります。また、業務移行は、事業者が検討するシステム移行やデータ移行の検討結果を踏まえて検討する必要があるため、検討が遅くなりがちですが、サービス・業務に関する新たな制約が後から発覚して、移行作業に大きな影響を与えることも多々あります。

したがって、設計・開発の早い段階から、業務移行も含めて移行の検討を行ってください。

リハーサルも考慮した移行計画書を立てる

本番移行は、限られた時間の中での完了が求められ、その結果には正確性が求められます。そのため、手順書を作成して実施に臨みますが、それでも不測の事態が発生することがしばしばあります。このような事態を極力減らし、問題なく本番稼働を迎えるためには、移行手順に則ったリハーサルの実施が必要不可欠です。リハーサルにおいてもシステム側面と業務側面の確認を行いますが、以下では、特に業務側面のリハーサルを行うに当たっての留意点を示します。

リハーサルの留意点

シナリオは本番業務に係る全てを想定して作成する（以下の「シナリオを作る際の注意点」を参照）。
職員が積極的に関与する。
できる限り本番と同等の環境・本番データを使用する。
時間の測定は必ず行う。
リハーサルの結果から手順等に修正や改善を行う場合、その重要度に応じて、リハーサルで再度検証を行う。
リスクの影響度合い等を踏まえて、切り戻し等の不測の事態に対する対応（＝コンティンジェンシー・プラン）のシナリオもリハーサルで確認する。

図7-21

シナリオを作る際の注意点

日々の業務だけでなく、月次、年次、例外時の業務パターンを網羅し、問題なく、かつ迷わず業務が進められるか。
繁忙期の業務量でも想定する作業時間内で実施できるか。
複数の情報システムと連携する場合、連携を含めて想定どおりに業務を進められるか。

次の運用・保守は開発と並行して検討する

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

運用・保守の内容は、運用・保守事業者の調達に間に合うように検討を始めれば大丈夫だろう。そう思っていませんか？

実はそうではありません。運用・保守を考慮せずに情報システムを構築することで、運用・保守に膨大な費用を要する情報システムやサービス・業務の指標値の取得すら困難な情報システムとなってしまうことは少なくありません。

ここでは、そのような状況を引き起こさないためのポイントを見ていきましょう。

指標値を運用作業で取得できるように検討する

情報システムの運用を開始した後には、プロジェクトの目標、ＫＧＩ、ＫＰＩをモニタリングし、これらを達成できるように継続的な改善を行っていかなければなりません。しかし、情報システムの設計時には、この観点が抜け落ちてしまうことがよくあります。

継続的な改善を行い、プロジェクト目標を確実に達成するためには、指標値の評価を容易に行えるようにして定期的に確認していくことが必要不可欠です。また、指標値の取得だけでなく、分析のためのデータ取得・集計も必要になることも多くあります。設計・開発では、指標値や関連するデータをどのように取得し集計するか？作業にどれくらいの工数がかかるか？を確認し、必要な機能や運用作業を検討してください。

事例7-6

運用作業での指標値の取得に工数がかかってしまう

サービス・業務の運営が始まり、モニタリングを行う際に困ることのないよう、設計の段階で以下の内容を確認しておきましょう。

指標に関する確認ポイント

業務要件定義で定めた全ての「管理すべき指標」について、「誰が」「どのように」「どれくらいの工数で」取得できるように設計しているかを事業者に確認する。
取得するデータの形式が定められているか、加工・集計の要否、加工・集計が必要な場合は、誰がやるのか、データはどのように保管するルールとするかを確認する。
運用・保守の作業内容に、各種指標に係るデータの取得が漏れなく含まれているかを確認する。

運用・保守の検討は、実務経験のある担当者と一緒に行う

意外に思うかもしれませんが、情報システムの設計・開発と情報システムの運用では、必要とする技術や知識が大きく異なります。また、設計・開発と運用の両方の経験を十分に持つ技術者は、そう多くはありません。こういった背景もあり、設計・開発を行う事業者が必ずしも良い運用を設計できるとは限りません。

このため、運用・保守計画の案を作成する際は、情報システムの運用・保守管理経験がある職員に参加してもらえるように調整しましょう。運用・保守の管理経験のある担当者からは、「情報システムを構築するときに、こういう点に注意しておけば良かった」「こういう運用・保守作業を最初から見込んでおけば良かった」という経験やノウハウを聞けるはずです。

もしも、運用・保守経験のある担当者の調整が難しい場合は、ＰＭＯに相談してみてください。

運用・保守の計画を立てる

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

様式例7-3

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

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

なお、ここで作成した運用・保守の計画の案は、運用・保守事業者の調達仕様書の付属資料になり、運用・保守事業者の調達後に確定されることとなります。

参考7-6

設定と設計は異なる

種類を理解し揃えるマニュアルを厳選する

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

サービス・業務を開始するに当たっては、業務実施担当者や利用者向けのマニュアル等の教育資料が必要になります。実は、これらのマニュアルは、利用率、利用者の満足度、業務の浸透度等に大きな影響を与えます。

ここでは、情報システムに係るマニュアルに関する知識やノウハウについて、紹介します。

マニュアルの種類を理解する

マニュアルと聞くと、情報システムの操作マニュアルはすぐに思いつくかもしれませんが、ほかにも様々な種類のものがあります。以下に、マニュアルの例を示します。

表7-19

マニュアルの種類

ここで注意してほしいことは、「業務マニュアルとシステム操作マニュアルは異なる」ということです。業務マニュアルは、業務を遂行するために必要となる一連の作業（情報システムで行う業務以外も含む）の手順やルールを示すのに対して、システム操作マニュアルは、情報システムの操作に特化した手順やルールを示します。

図7-22

システムマニュアルと業務マニュアルの違い

業務マニュアルは、一般的に職員が作成するものです。業務マニュアルの作成については、実践ガイドブック「第８章Step.2-2-A.業務マニュアルと他のマニュアルとの違いを理解する」を参照してください。

役に立つシステム操作マニュアルを作成するには

システム操作マニュアルの作成を事業者に依頼する場合も注意が必要です。事業者に対して、特に詳細を指定せずに「システム操作マニュアルを作成してください」と指示をした結果、現場になじまないマニュアルが出てきた、ということは少なくありません。事業者にマニュアルの作成を依頼する場合は、サンプル等も活用しながら、作成内容を詳細に指定する必要があります。

また、マニュアルの作成タイミングも気を付けなければいけません。実際にマニュアルを使用する部門が内容を確認しなければ、役に立たないマニュアルになってしまいます。システム操作マニュアルは、受入テストまでに作成し、それらを受入テスト内で一緒に確認します。

利用者視点のマニュアルを作成するためには、職員側がしっかりチェック（又は作成・修正）する必要があります。マニュアルに係る計画を立てる場合は、これらの点に注意してください。

マニュアル作成に関する検討事項

現場は、どのようなマニュアルを求めているかを、実際に使われているマニュアルを踏まえて確認する。使われるマニュアルを作る。
マニュアル作成に関する職員の作業、事業者の作業を明確にする。
マニュアルの作成タイミングに気を付ける。マニュアルはいつ、誰に確認（テスト）されるのか？それまでに、マニュアル作成が完了するように計画する。