--- type: guideline title: Step.5 見落としがちな活動に注意 source: デジタル庁 ds_code: ds-120 category: government-system updated: 2025-06-19 source_url: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/9ab95eed/20250619_resources_standard_guidelines_guideline_06.zip --- # Step.5 見落としがちな活動に注意 設計・開発の活動は、情報システムを構築する作業だけではありません。本番の環境で情報システムを稼働するためには、データの設定、既存サービス・業務や情報システムからの切替え等や運用・保守の作業を行わなければいけません。これらは情報システム自体の設計・開発と同時に検討していくことがとても大切ですが、見落とされがちになってしまうと、後々大変な思いをすることになります。 ここでは、情報システム自体の設計・開発以外に必要な活動についての知識やノウハウについて、紹介していきます。 ## どのプロジェクトでも必ず移行を計画する 【標準ガイドライン関連箇所：第３編第７章第８節】 情報システムの移行は、どのようなプロジェクトでも必ず発生します。既存のサービス・業務や情報システムが存在しない場合でも、本番の情報システムの構築、データの設定、切替え、新規業務の開始に関わる業務の変更等は必ず必要です。 ここでは、これらの移行に関するポイントを見ていきます。 ### 移行の種類を理解する 「移行」と聞くと、データの移行や情報システムの切替えは思い付くかもしれませんが、移行はそれだけではありません。移行は、大きく分類すると「システム移行」「データ移行」「業務移行」の３種類があります。 - 表7-18 移行の種類
移行の種類 概要
システム移行

受入テストが終わったものを本番環境にリリースすることを指す。以下のような観点について検討し、検討結果から発生した必要なプログラムやツールに関して、設計・実装・テストを行う。

検討例

  • ネットワークやＤＮＳサーバの切替え方式

  • 外部情報システムと連携部分の切替え方式

  • 移行対象となっている設備（Ｈ/Ｗ等）の移行方式

  • 新旧のマスターデータの同期の仕組み

  • 移行失敗時の切り戻し方式

  • 端末又は端末上のソフトウェアの入れ替え方式
データ移行

既存情報システムから新情報システムへデータを適切な形で渡すことを指す。以下の観点について検討し、検討結果から発生した必要なプログラムやツールに関して、設計・実装・テストを行う。

－移行元データ

新規データ作成になるのか、又は現行に元データがあるか？

元データがある場合、どのような形式（ＤＢ、紙、テキスト等）で、どの部分が移行対象となるか？

－実施方法

手作業か又はツール（自動）による方法かどうか？ツールの場合、スクラッチで開発するのか又は既存の製品を利用するのか？

－データ移行処理（マッピング、変換処理、クレンジング）

データ移行を行う際の処理について、以下の観点で検討を行う。

  • テーブル定義（論理）の項目と移行元データの項目の対応（マッピング）

  • データ変換やクレンジングなどのデータ処理のロジック
業務移行

各種移行方式を検討した結果を踏まえながら、（所管の）業務や利用者において「移行時に発生する業務」「段階移行/並行稼働中の特殊な作業」について、洗い出しや検討を行う。

検討例：

  • 並行稼働中の業務データの手動保存/移行

  • アクセスＵＲＬの変更

  • 端末の入れ替え

  • 利用者のログインＩＤ/パスワードの変更　など
特に、業務移行は、ＰＪＭＯが主体となって業務実施部門と調整しながら、進めていく必要があります。また、業務移行は、事業者が検討するシステム移行やデータ移行の検討結果を踏まえて検討する必要があるため、検討が遅くなりがちですが、サービス・業務に関する新たな制約が後から発覚して、移行作業に大きな影響を与えることも多々あります。 したがって、設計・開発の早い段階から、業務移行も含めて移行の検討を行ってください。 ### リハーサルも考慮した移行計画書を立てる 本番移行は、限られた時間の中での完了が求められ、その結果には正確性が求められます。そのため、手順書を作成して実施に臨みますが、それでも不測の事態が発生することがしばしばあります。このような事態を極力減らし、問題なく本番稼働を迎えるためには、移行手順に則ったリハーサルの実施が必要不可欠です。リハーサルにおいてもシステム側面と業務側面の確認を行いますが、以下では、特に業務側面のリハーサルを行うに当たっての留意点を示します。 リハーサルの留意点 - シナリオは本番業務に係る全てを想定して作成する（以下の「シナリオを作る際の注意点」を参照）。 - 職員が積極的に関与する。 - できる限り本番と同等の環境・本番データを使用する。 - 時間の測定は必ず行う。 - リハーサルの結果から手順等に修正や改善を行う場合、その重要度に応じて、リハーサルで再度検証を行う。 - リスクの影響度合い等を踏まえて、切り戻し等の不測の事態に対する対応（＝コンティンジェンシー・プラン）のシナリオもリハーサルで確認する。 - 図7-21 シナリオを作る際の注意点 ![](../assets/ds-120-ch07-image27.png) シナリオを作る際の注意点 - 日々の業務だけでなく、月次、年次、例外時の業務パターンを網羅し、問題なく、かつ迷わず業務が進められるか。 - 繁忙期の業務量でも想定する作業時間内で実施できるか。 - 複数の情報システムと連携する場合、連携を含めて想定どおりに業務を進められるか。 ## 次の運用・保守は開発と並行して検討する 【標準ガイドライン関連箇所：第３編第７章第８節】 運用・保守の内容は、運用・保守事業者の調達に間に合うように検討を始めれば大丈夫だろう。そう思っていませんか？ 実はそうではありません。運用・保守を考慮せずに情報システムを構築することで、運用・保守に膨大な費用を要する情報システムやサービス・業務の指標値の取得すら困難な情報システムとなってしまうことは少なくありません。 ここでは、そのような状況を引き起こさないためのポイントを見ていきましょう。 ### 指標値を運用作業で取得できるように検討する 情報システムの運用を開始した後には、プロジェクトの目標、ＫＧＩ、ＫＰＩをモニタリングし、これらを達成できるように継続的な改善を行っていかなければなりません。しかし、情報システムの設計時には、この観点が抜け落ちてしまうことがよくあります。 継続的な改善を行い、プロジェクト目標を確実に達成するためには、指標値の評価を容易に行えるようにして定期的に確認していくことが必要不可欠です。また、指標値の取得だけでなく、分析のためのデータ取得・集計も必要になることも多くあります。設計・開発では、指標値や関連するデータをどのように取得し集計するか？作業にどれくらいの工数がかかるか？を確認し、必要な機能や運用作業を検討してください。 - 事例7-6 運用作業での指標値の取得に工数がかかってしまう

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

ある省で行われている業務において、個々の業務の処理時間が長い事が大きな問題となっていました。そこで、その業務で利用する情報システムを更改するプロジェクトでは、処理時間の短縮を目標として、業務ごとの処理時間の指標値を設けました。

プロジェクトでは、対策を検討して業務の見直しを行い、情報システムを刷新することとしました。しかし、設計・開発では、業務機能の構築に重点が置かれ、指標の取得方法や運用作業の詳細な検討は不十分な状態でした。

新しい情報システムの運用が始まり、いざ運用作業で指標値の評価のために業務の処理時間のデータ取得・集計を行ってみると、評価のたびに非常に多くの運用作業工数がかかってしまうことがわかりました。

結局、定期的な指標値評価が必要なことから、さらに新たな予算措置を講じ、データの取得・集計を容易に行うための新しい機能を追加で開発することになってしまいました。
サービス・業務の運営が始まり、モニタリングを行う際に困ることのないよう、設計の段階で以下の内容を確認しておきましょう。 指標に関する確認ポイント - 業務要件定義で定めた全ての「管理すべき指標」について、「誰が」「どのように」「どれくらいの工数で」取得できるように設計しているかを事業者に確認する。 - 取得するデータの形式が定められているか、加工・集計の要否、加工・集計が必要な場合は、誰がやるのか、データはどのように保管するルールとするかを確認する。 - 運用・保守の作業内容に、各種指標に係るデータの取得が漏れなく含まれているかを確認する。 #### 運用・保守の検討は、実務経験のある担当者と一緒に行う 意外に思うかもしれませんが、情報システムの設計・開発と情報システムの運用では、必要とする技術や知識が大きく異なります。また、設計・開発と運用の両方の経験を十分に持つ技術者は、そう多くはありません。こういった背景もあり、設計・開発を行う事業者が必ずしも良い運用を設計できるとは限りません。 このため、運用・保守計画の案を作成する際は、情報システムの運用・保守管理経験がある職員に参加してもらえるように調整しましょう。運用・保守の管理経験のある担当者からは、「情報システムを構築するときに、こういう点に注意しておけば良かった」「こういう運用・保守作業を最初から見込んでおけば良かった」という経験やノウハウを聞けるはずです。 もしも、運用・保守経験のある担当者の調整が難しい場合は、ＰＭＯに相談してみてください。 ### 運用・保守の計画を立てる この実践ガイドブックには、別添として運用・保守に係る計画書のひな形を示しています。 - 様式例7-3 運用計画書、運用実施要領、保守計画書、保守実施要領のひな形

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

運用計画書、運用実施要領、保守計画書、保守実施要領のひな形を第９章別紙としてまとめています。

![](../assets/ds-120-ch07-image28.png)　![](../assets/ds-120-ch07-image29.png)

![](../assets/ds-120-ch07-image30.png)　![](../assets/ds-120-ch07-image31.png)
あくまでこのひな形は例示です。移行の内容に応じて記載内容を個別に追加、変更して構いません。ひな形を見ると、何をどのようなレベルで書くべきかの参考になると思います。 なお、ここで作成した運用・保守の計画の案は、運用・保守事業者の調達仕様書の付属資料になり、運用・保守事業者の調達後に確定されることとなります。 - 参考7-6 設定と設計は異なる

参考：設定と設計は異なる

情報システムの構築では、ハードウェア、ミドルウェア、アプリケーションのフレームワーク等に対して様々な設定が必要となります。これらの設定には、設定値の決定に十分に検討や調査が必要なものから、他の設計により自明で決まるようなものまで様々な難易度のものがあります。

事業者に見積りを依頼すると、大量の設定に関する設計書が他の設計書の同じような工数で見積られていることがあります。このような場合は要注意です。たしかに設定に関する設計書は必要ですが、全ての設定に対して機能の設計等と同じだけ工数がかかることは稀です。

このため、見積り精査の際には、設定と設計を区別して、工数を確認するようにしましょう。設定に対する工数割合が大きい場合は、事業者に理由を確認するようにしてください。
## 種類を理解し揃えるマニュアルを厳選する 【標準ガイドライン関連箇所：第３編第７章第８節】 サービス・業務を開始するに当たっては、業務実施担当者や利用者向けのマニュアル等の教育資料が必要になります。実は、これらのマニュアルは、利用率、利用者の満足度、業務の浸透度等に大きな影響を与えます。 ここでは、情報システムに係るマニュアルに関する知識やノウハウについて、紹介します。 ### マニュアルの種類を理解する マニュアルと聞くと、情報システムの操作マニュアルはすぐに思いつくかもしれませんが、ほかにも様々な種類のものがあります。以下に、マニュアルの例を示します。 - 表7-19 マニュアルの種類
マニュアル名称 概要

業務マニュアル

業務手順書

 業務実施部門の担当者が業務を遂行する上で活用する統一的な手順について詳細に記載されたものであり、人事異動で配属された職員等がこれを読んで理解すれば業務を遂行できるような内容になっている。したがって、記載内容は情報システムの具体的な操作内容ではなく、また、業務のシーンごとに記載されていることが望ましい。
システム操作マニュアル（利用者向け） 情報システムにおいて情報入力や帳票出力等、業務遂行時における一連の操作手順が記載されたものである。役割別に分かれる可能性がある。
ＦＡＱ マニュアルを読んでもわからずに利用者からよく来る質問とそれに対する回答を、後から一覧等にまとめて公開している情報Webサイト。
システム操作マニュアル（管理者向け） 情報システムを管理するための機能について、機能及び一連の操作手順が記載されたものである。
（虎の巻レベルのもの） 情報システムが絡まない場合、統一的な手順が詳細に書かれたものは特になく、部分的な業務遂行ノウハウを記載している。
（ベンダーが作るシステムマニュアル） 情報システムの画面単位のマニュアル。業務遂行の観点では書かれていない。
（ローカルルール） 支所ごとに業務ルールカスタマイズされたもの。
ここで注意してほしいことは、「業務マニュアルとシステム操作マニュアルは異なる」ということです。業務マニュアルは、業務を遂行するために必要となる一連の作業（情報システムで行う業務以外も含む）の手順やルールを示すのに対して、システム操作マニュアルは、情報システムの操作に特化した手順やルールを示します。 - 図7-22 システムマニュアルと業務マニュアルの違い ![](../assets/ds-120-ch07-image32.png) 業務マニュアルは、一般的に職員が作成するものです。業務マニュアルの作成については、実践ガイドブック「第８章Step.2-2-A.業務マニュアルと他のマニュアルとの違いを理解する」を参照してください。 #### 役に立つシステム操作マニュアルを作成するには システム操作マニュアルの作成を事業者に依頼する場合も注意が必要です。事業者に対して、特に詳細を指定せずに「システム操作マニュアルを作成してください」と指示をした結果、現場になじまないマニュアルが出てきた、ということは少なくありません。事業者にマニュアルの作成を依頼する場合は、サンプル等も活用しながら、作成内容を詳細に指定する必要があります。 また、マニュアルの作成タイミングも気を付けなければいけません。実際にマニュアルを使用する部門が内容を確認しなければ、役に立たないマニュアルになってしまいます。システム操作マニュアルは、受入テストまでに作成し、それらを受入テスト内で一緒に確認します。 利用者視点のマニュアルを作成するためには、職員側がしっかりチェック（又は作成・修正）する必要があります。マニュアルに係る計画を立てる場合は、これらの点に注意してください。 マニュアル作成に関する検討事項 - 現場は、どのようなマニュアルを求めているかを、実際に使われているマニュアルを踏まえて確認する。使われるマニュアルを作る。 - マニュアル作成に関する職員の作業、事業者の作業を明確にする。 - マニュアルの作成タイミングに気を付ける。マニュアルはいつ、誰に確認（テスト）されるのか？それまでに、マニュアル作成が完了するように計画する。