---
type: guideline
title: Step.８ その他の注意点について
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.８ その他の注意点について

実は今やっておくだけで後々発生するリスクや負荷を減らすことができる作業があります。

ここでは、それらの作業とポイントについて解説します。

## 人事異動時は確実に引継ぎする

【標準ガイドライン関連箇所：第３編第３章全般】

様々な検討と工夫をして予算要求をしても、プロジェクト推進責任者等のプロジェクトの中心となる職員が人事異動になってしまい、後任の職員がプロジェクトをうまく進められないことがあります。異動する当人が心残りであることは言うまでもありませんが、プロジェクトにとっても大きな痛手となります。

このような予期せぬ事態に備えて、予算要求にまつわる一連の作業は、複数名のグループで実施しましょう。これにより、多くの情報が常に共有できます。その上で、異動する職員は、まず後任の職員ではなくグループの他のメンバーへ引き継ぐことにより、引き継ぐ情報量が少なくて済み、円滑に引継ぎができます。

引き継ぐ内容は、実務的な内容はもちろんですが、なぜこのプロジェクトを進めるのか、どのようにサービスを向上するのか、といった熱い想いを引き継ぐことが重要です。

その後、後任の職員には、既存のグループメンバーが時間をかけて十分な教育ができます。

そのほか、１名でプロジェクトを任された場合には、後任に十分な情報を引き継ぐためにも、資料をしっかり作成し、引継ぎを実施しましょう。資料は、様々な決定事項に関する経緯がわかることが重要であり、それらは後任者の大きな手助けとなります。

ポイント

- 予算要求から執行までの間に、当該プロジェクトのＰＪＭＯを変更することは推奨しない。

- やむを得ず、異動が決定した場合は、十分な引継ぎを準備し、後任に引き継ぐ。引継ぎには、決定事項だけでなく経緯も伝達する。

<!-- -->

- 事例3-6

引継ぎ不足により、後日問題が顕在化した

<table style="width:96%;">
<colgroup>
<col style="width: 96%" />
</colgroup>
<thead>
<tr>
<th><p>事例：引継ぎ不足により、後日問題が顕在化した</p>
<p>ある省において、監査の結果、新たに機器・ソフトウェア等を購入しなければ情報セキュリティ対策ができないことが判明しました。その結果が判明した後、原課側担当者が人事異動で交替しましたが、新たな情報セキュリティ対策用の予算を確保しなければならないことについて、引継ぎが十分に行われていませんでした。</p>
<p>１年後、その原課で情報漏えい事案が発生し、原因究明や報道対応を含めた様々な対応業務が大量に必要となりました。このとき、監査結果を反映した情報セキュリティ対策が講じられていれば、情報漏えい事案が発生しなかった可能性が高いことが判明しました。しかしながら、原課の予算担当、会計課、ＰＭＯにおいても監査結果による新たな情報セキュリティ対策が必要なこと、そして予算要求が必要だったことを誰も知りませんでした。</p></th>
</tr>
</thead>
<tbody>
</tbody>
</table>

## プロジェクト計画書に反映して最新化する

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

ここまで予算要求の作業を進めてきましたが、見積りを入手した後、プロジェクトの目的・目標を達成するために、多岐にわたって調整や変更を行い、予算要求を行ったことと思います。

その結果、検討の過程でプロジェクト計画書に記載されていた内容とは、異なる方針に変更した項目があるのではないでしょうか。

予算にまつわる作業の最後の締め括りとして、変更内容をプロジェクト計画書に反映しましょう。プロジェクト計画書への反映に当たり、プロジェクトの開始時にテーラリングした内容の見直しも合わせて行いましょう。テーラリングの考え方は、標準ガイドライン解説書「第1章3．（3）プロジェクトへの適用に当たり、ＰＪＭＯは、本ガイドラインが示すＩＴマネジメントの内容をテーラリングすることが重要である」を参照して下さい。

今回実施した内容を基にプロジェクト計画書を最新化することにより、次回の予算要求のときは、プロジェクト計画書を見直すことなく、計画書の内容に沿って作業を進めることができるため、準備作業が減ります。

また、人事異動が発生しても、最新のプロジェクト計画書を使って引継ぎができます。

ポイント

- プロジェクト計画書に記載されている内容を、予算要求作業の結果から発生した変更を基にＰＪＭＯ内で検討の上、修正し最新化する。

- 修正したプロジェクト計画書を、関係者と共有し合意する。

プロジェクト計画書の各項目に対し、予算要求の活動から変更される頻度の高い内容を次の表に示します。

- 表3-8

予算要求活動後に修正が必要となるプロジェクト計画書の変更内容の例

| No. | 項目 | 変更例 |
|---:|----|----|
| 1 | 政策目的 | 当項目はプロジェクト全体への影響が大きいため、基本的には変更しない。例外的に政策の方針転換等があったときのみ変更する。 |
| 2 | 対象範囲 | 整備する情報システムが提供するサービス・業務の範囲が変更されたときは、その内容に修正する。 |
| 3 | 実施期間 | 期間延長や短縮が発生したときは、その内容に修正する。 |
| 4 | サービス・業務企画の方向性等 | 当初想定していた予算内でサービス・業務企画内容を実現することが困難であると判明し、企画の方向性等の変更を検討したときは、決定した内容に修正する。 |
| 5 | 予算 | プロジェクトの構想段階に記載されていた年度ごとに見積った経費区分ごとの概算予算を、当初予算が承認された段階で、初年度分については、作成した予算に係る各種資料を基に修正する。また、次年度以降の予算見積りを見直した結果を記載する。 |
| 6 | 目標 | 主にサービス・業務企画の方向性等の変更とともに、達成目標とする指標及び達成目標年度等の変更する必要有無を検討し、その結果を反映する。 |
| 7 | 体制 | 見積りの結果、人件費が当初想定よりも増減したときに、体制の増強又は縮小を検討し、その結果を反映する。 |
| 8 | 実施計画 | プロジェクト計画書に記載されている他の項目（特に実施期間、対象範囲）に変更が発生したときに、あわせて当項目も整合性が取れるよう検討した上で変更する。 |
| 9 | モニタリング | 目標が変更されたときは、モニタリングで定義している内容の変更もあわせて検討し、変更する。 |
| 10 | その他 | 見積りの際に事業者から得た情報や、省内・省外調整の過程で把握したプロジェクト運営上の課題やリスク等を追記・更新する。 |

デジタル・ガバメント推進標準ガイドライン

実践ガイドブック

（第３編第４章　サービス・業務企画）

目次

[１ サービスデザイン思考を理解する [6](#サービスデザイン思考を理解する)](#サービスデザイン思考を理解する)

[A. 心構えと視点（サービス設計12か条）を理解する [6](#心構えと視点サービス設計12か条を理解する)](#心構えと視点サービス設計12か条を理解する)

[１ 利用者のことを知る [8](#利用者のことを知る)](#利用者のことを知る)

[A. どんな利用者がいるかを調べる [9](#どんな利用者がいるかを調べる)](#どんな利用者がいるかを調べる)

[B. 利用者の人数を把握する [10](#利用者の人数を把握する)](#利用者の人数を把握する)

[２ 利用者のニーズを理解する [11](#利用者のニーズを理解する)](#利用者のニーズを理解する)

[A. 利用者のニーズから出発する [11](#利用者のニーズから出発する)](#利用者のニーズから出発する)

[B. エンドツーエンドで考える [13](#エンドツーエンドで考える)](#エンドツーエンドで考える)

[１ 業務を観察する [16](#業務を観察する)](#業務を観察する)

[A. 事実を詳細に把握する [16](#事実を詳細に把握する)](#事実を詳細に把握する)

[B. 推測ではなく、現場で発生している事実をみる [17](#推測ではなく現場で発生している事実をみる)](#推測ではなく現場で発生している事実をみる)

[C. １か所だけの現場分析結果を全体に拡張しない [19](#か所だけの現場分析結果を全体に拡張しない)](#か所だけの現場分析結果を全体に拡張しない)

[D. 日常的に業務の課題を収集し、分析に利用する [20](#日常的に業務の課題を収集し分析に利用する)](#日常的に業務の課題を収集し分析に利用する)

[２ 実績データを分析する [21](#実績データを分析する)](#実績データを分析する)

[A. 平均、合計ではなく、ばらつきを見る [21](#平均合計ではなくばらつきを見る-1)](#平均合計ではなくばらつきを見る-1)

[B. 時間と期間を区別して滞留状況をつかむ [22](#時間と期間を区別して滞留状況をつかむ)](#時間と期間を区別して滞留状況をつかむ)

[C. 業務量のピークを捉え、ピークの発生原因を把握する [25](#業務量のピークを捉えピークの発生原因を把握する)](#業務量のピークを捉えピークの発生原因を把握する)

[D. 問合せや要望は、根本原因が同じになる粒度まで分類する [26](#問合せや要望は根本原因が同じになる粒度まで分類する)](#問合せや要望は根本原因が同じになる粒度まで分類する)

[３ 業務を可視化する [28](#業務を可視化する)](#業務を可視化する)

[A. 様々な立場の人が理解できる業務フローを作成する [28](#様々な立場の人が理解できる業務フローを作成する)](#様々な立場の人が理解できる業務フローを作成する)

[B. 業務ルールや業務実施方法をまとめる [30](#業務ルールや業務実施方法をまとめる)](#業務ルールや業務実施方法をまとめる)

[C. 入出力情報や管理対象情報をまとめる [31](#入出力情報や管理対象情報をまとめる)](#入出力情報や管理対象情報をまとめる)

[１ 課題を整理し、分析する [34](#課題を整理し分析する)](#課題を整理し分析する)

[A. 優先順位・影響度・費用対効果による分析 [34](#優先順位影響度費用対効果による分析-1)](#優先順位影響度費用対効果による分析-1)

[２ 企画案を作成する [36](#企画案を作成する)](#企画案を作成する)

[A. 全ての関係者に気を配る [36](#全ての関係者に気を配る)](#全ての関係者に気を配る)

[B. 利用者の日常体験に溶け込む [37](#利用者の日常体験に溶け込む)](#利用者の日常体験に溶け込む)

[C. 縦割り組織にやわらかく横串を刺す [38](#縦割り組織にやわらかく横串を刺す)](#縦割り組織にやわらかく横串を刺す)

[D. 必要に応じて制度自体を見直す [38](#必要に応じて制度自体を見直す)](#必要に応じて制度自体を見直す)

[E. システムを作る前に、業務を標準化する [39](#システムを作る前に業務を標準化する)](#システムを作る前に業務を標準化する)

[F. 将来の業務フローには、効果を紐づける [39](#将来の業務フローには効果を紐づける)](#将来の業務フローには効果を紐づける)

[G. 精緻に効果を積算し、主要な効果を実感可能なものとする [40](#精緻に効果を積算し主要な効果を実感可能なものとする)](#精緻に効果を積算し主要な効果を実感可能なものとする)

[H. オープンにサービスを作る [43](#オープンにサービスを作る)](#オープンにサービスを作る)

[I. 企画案を客観的に見直してみる [44](#企画案を客観的に見直してみる)](#企画案を客観的に見直してみる)

[１ 軌道修正しやすい進め方にする [48](#軌道修正しやすい進め方にする)](#軌道修正しやすい進め方にする)

[A. 一遍にやらず、一貫してやる [48](#一遍にやらず一貫してやる)](#一遍にやらず一貫してやる)

[２ 柔軟に軌道修正する [48](#柔軟に軌道修正する)](#柔軟に軌道修正する)

[A. 何度も繰り返す [48](#何度も繰り返す)](#何度も繰り返す)

[B. 無理に継続しない [50](#無理に継続しない)](#無理に継続しない)

[１ 業務要件をまとめる [52](#業務要件をまとめる)](#業務要件をまとめる)

[２ 定義内容を関係者に共有する [52](#定義内容を関係者に共有する)](#定義内容を関係者に共有する)

[A. 事業者と役割分担して作業を進める [53](#事業者と役割分担して作業を進める)](#事業者と役割分担して作業を進める)

[B. 発注者の、要件定義への関わり方 [53](#発注者の要件定義への関わり方)](#発注者の要件定義への関わり方)

事例・参考の一覧

※事例には当時の役職名やシステム名を使用しているため、現在使用されていない名称が記載されている場合があります。

##