---
type: guideline
title: 第４章　サービス・業務企画
source: デジタル庁
ds_code: ds-110
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/d647a7ca/20250619_resources_standard_guidelines_guideline_04.zip
---

# 第４章　サービス・業務企画

ＰＪＭＯは、**<u>制度所管部門、業務実施部門及び情報システム部門が連携し、提供者の視点ではなく利用者の視点からの検討を通して、本章に規定された事項を実施する(1)</u>**ものとする。

また、**<u>情報システムの更改又は機能改修を行うときは、利用者のニーズ及び利用状況等に応じて、既存のサービス・業務の継続必要性についても判断するものとする(2)</u>**。

1.  １. はじめに

プロジェクトは、政策目的やプロジェクトの目標を達成するための活動であり、それらは業務の実施を通した行政サービスの提供によってなされるものである。今後、急速に変化する社会に対応しつつ、行政の費用対効果を高めていくには、これまでの提供者視点ではなく、利用者視点でサービス・業務をデザインし、利用者にとっての価値を最大化するサービス提供を行っていく必要がある。そのためには、既存のサービス・業務の枠内にとらわれず、利用者にとって「すぐ使えて」「簡単で」「便利」なサービス・業務を検討することが必要不可欠である。

本章は、このような問題意識に基づき、プロジェクトで実現すべきサービス・業務を企画するために必要な一連の活動を定めるものである。

2.  ２. 解説

#### 「制度所管部門、業務実施部門及び情報システム部門が連携し、提供者の視点ではなく利用者の視点からの検討を通して、本章に規定された事項を実施する」

「制度所管部門、業務実施部門及び情報システム部門が連携し」とは、情報システム部門の職員だけではなく制度所管部門や業務実施部門の職員も適切に参画してプロジェクトに直接的に関係する職員によってＰＪＭＯを構成するとともに、プロジェクトに間接的に関係する制度所管部門、業務実施部門、情報システム部門とも情報共有、調整を進めながら検討を行うことを指す。

「提供者の視点」とは、提供するサービス・業務を所管するＰＪＭＯがその枠内のみで検討を行い、利用者のニーズや他組織、他部門が所管するサービス・業務については感知しないという検討姿勢のことである。

「利用者の立場からの検討」とは、「提供者の視点」とは逆に、利用者がサービスを受ける必要が生じた時からサービスの提供後まで（エンドツーエンド）の行動全体を一連の流れとして考えた上で、関係する他組織や他部門とも相互に協力を行いながら利用者のニーズを考慮してサービス・業務の全体を改革するという検討姿勢のことである。

#### 「情報システムの更改又は機能改修を行うときは、利用者のニーズ及び利用状況等に応じて、既存のサービス・業務の継続必要性についても判断するものとする」

「利用者のニーズ及び利用状況等」とは、利用者の行政サービスに求める要望、行政サービスの利用頻度や利用方法等の実態、及び、そこから把握できる行政サービスの課題等を指す。

「既存のサービス・業務の継続必要性についても判断する」とは、プロジェクトの初期に計画した目的、目標に対する現時点での達成状況を確認した上で、利用者への提供価値や費用対効果を踏まえて、今後もプロジェクトを継続することが妥当であるかを判断することを指す。詳細は「４．軌道修正」を参照。

## 心構えと視点

デジタル技術を活用して利用者中心のサービス・業務改革を推進するためには、利用者のニーズを把握した上で、利用者の立場からの検討に基づいて業務要件を定義する必要がある。そのために、**<u>十分な検討期間と体制を確保した上で(1)</u>**、概念検証（ＰｏＣ）等も適切に活用し、**<u>サービス利用者の行動等に着目したサービスデザイン思考で、現状把握、分析、検討、調整等を実施する(2)</u>**ものとする。

利用者中心の行政サービスを提供するために必要となる心構えと視点を、「**<u>サービス設計12箇条(3)</u>**」（「情報システムの整備及び管理の基本的な方針」参照）として次に示す。

＜**<u>サービス設計12箇条(3)</u>**＞

1.  利用者のニーズから出発する

2.  事実を詳細に把握する

3.  エンドツーエンドで考える

4.  全ての関係者に気を配る

5.  サービスはシンプルにする

6.  デジタル技術を徹底的に活用する

7.  利用者の日常体験に溶け込む

8.  自分で作りすぎない

9.  オープンにサービスを作る

10. 何度も繰り返す

11. 一遍にやらず、一貫してやる

12. 情報システムではなくサービスを作る

<!-- -->

3.  １. 趣旨

従来のサービス・業務は、利用者にとっての効率性、即時性、簡便性等の観点ではなく、制度所管部門や業務実施部門等の管轄範囲に基づいた提供者視点から設計されることが多く、利用者のニーズに沿っているとは言い難い状況である。

サービス・業務が目的どおりに機能して利用者の価値を高めるためには、利用者に「使わせる」という従来の視点から、利用者に「使っていただく」という視点へと、抜本的に変えることが求められる。また、視点を変えるだけでなく、利用者視点でのサービス・業務企画に適した調査手法や検討手法も活用することが望ましい。

- 参考

デジタル社会の実現に向けた重点計画（令和３年12月24日閣議決定）

本節は、こうした前提を背景として、ＰＪＭＯがサービス・業務を企画する際に、現状把握、分析、検討、調整等の活動を通して一貫して利用者視点で企画を進めることができるよう、心構えと視点を改めて認識することを目的として記述したものである。

なお、サービス・業務の抜本的な効率化と利便性の向上を図るため、「デジタル社会の実現に向けた重点計画」（令和３年12月24日閣議決定）において示されている次の３原則に沿い、行政サービスの100％デジタル化を前提として検討する。

- デジタル・ファースト
  個々の手続・サービスが一貫してデジタルで完結する。

- ワンスオンリー
  一度提出した情報は、二度提出することを不要とする。

- コネクテッド・ワンストップ
  民間サービスを含め、複数の手続・サービスがどこからでも／一か所で実現する。

4.  ２. 解説

#### 「十分な検討期間と体制を確保した上で」

「十分な検討期間と体制を確保」とは、利用者中心のサービス検討に当たり、自部門だけでなく他組織や他部門の管轄業務との調整が発生することを想定した上で、現状把握、分析、検討、調整等のための十分な期間を確保するとともに、サービス・業務改革を行うための権限を持つ責任者を検討体制に組み入れ、検討の実務作業を実施するための十分な職員数と実稼働量を確保することを指している。

なお、検討の実務作業に対して、職員の実稼働量を十分に確保できない場合や専門的な知識を持つ外部の人材が必要となる場合等は、検討作業の一部について事業者への支援委託を行うこともできる。ただし、この場合においても関係者調整や検討内容決定の責任はＰＪＭＯにあることを認識し、検討自体を事業者に一任しないように留意すること。

#### 「サービス利用者の行動等に着目したサービスデザイン思考で、現状把握、分析、検討、調整等を実施する」

「サービス利用者の行動等」とは、サービスを利用すると考えた時点からサービスを受けたことにより目的を達成した時点、又はサービスを享受し終わった後までの一連の行動や行動に伴う感情を含めた思考、利用者のニーズや行動を決定する特徴や制約を指す。

#### 「サービス設計12箇条」

「サービス設計12箇条」とは、利用者の価値最大化を主眼としてサービス・業務企画を行うため、利用者中心の行政サービスを提供しプロジェクトを成功に導くために必要となるノウハウをまとめたものである。

- 参考

サービスデザイン実践ガイドブック

（平成30年3月19日内閣官房情報通信技術（IT）総合戦略室）

「サービス設計12箇条」の解説については、「サービスデザイン実践ガイドブック」を参照すること。

## 現状の把握と分析

ＰＪＭＯは、**<u>提供する範囲を含むサービス・業務全体を分析対象とし、例えば、次の1）から6）までに掲げる現状の把握と分析を行うことにより、利用者のニーズや現状のサービス・業務を把握し、制約条件、前提条件、リスク及び問題点を抽出する(1)</u>**ものとする。

なお、**<u>クラウドサービスを利用するときには、ＰＪＭＯは、次の2)及び3)に掲げる業務及びデータの把握と分析の結果を踏まえ、クラウドサービスで提供される機能の喪失、低下等によるサービス停止等発生時の機密性・完全性・可用性に対する影響度の評価を行う。（2）</u>**

情報システムの更改又は機能改修を行うときには、既存サービス・業務の継続性についても検討する。

1)　**<u>利用者の把握と分析(3)</u>**

サービス・業務を利用することで価値や効果を得られる者・組織のそれぞれの規模、拠点、特徴、行動、満足度、要求事項等

2)　**<u>業務の把握と分析(4)</u>**

サービス・業務の範囲、業務フロー、業務量、実施体制、実施時期・時間、実施場所等

3)　**<u>データの把握と分析(5)</u>**

業務において取り扱う情報資産の特定及び分析並びに情報システムのデータの一覧、定義、入出力、流れ、取扱量、処理件数、品質、標準の活用状況、保有形態の状況、管理ルール、管理プロセス、オープンデータとしての公開状況（「第８章　２．5)　データマネジメントの実施」参照）等

4)　**<u>既存の情報システムの把握と分析(6)</u>**

既存の情報システムの資料、残存課題等

5)　**<u>情報システム運用の把握と分析(7)</u>**

情報システムの運用実績、各種指標の状況、残存課題等

6)　**<u>関連調査(8)</u>**

類似するサービス・業務の存否、取り扱うデータに関する標準化状況、優良事例、失敗事例、その要因等

5.  １. 趣旨

利用者の価値を最大化するサービス・業務を企画するためには、多様な利用者のニーズやサービス・業務の提供状況を事実に基づいて的確に捉えることが必要不可欠である。

このため、現状の把握と分析に当たっては、まず現場へ行き、現物を見ることで、実際に発生している状況を捉えることが重要である。そして、把握した事実に基づいて利用者、サービス、業務、情報システム等の各観点から対応すべき利用者のニーズや改善すべき問題を抽出する。

これらの把握・分析活動が十分に行えていないと、仮説や推測に基づいてサービス・業務企画を行うこととなり、実際の運用段階になって様々な問題が露呈することになりかねない。プロジェクトの成否は、現状把握と分析の精度に大きく影響を受けるため、十分な期間と体制の下で現状の把握と分析を行うことが求められる。

6.  ２. 解説

#### 「提供する範囲を含むサービス・業務全体を分析対象とし、例えば、次の1）から6）までに掲げる現状の把握と分析を行うことにより、利用者のニーズや現状のサービス・業務を把握し、制約条件、前提条件、リスク及び問題点を抽出する」

「提供する範囲を含むサービス・業務全体を分析対象とし」とは、利用者がサービス・業務を利用する際には、自部門だけでなく他組織や他部門の管轄業務が提供するサービス・業務を含むことがあるため、利用者がサービスを利用する前からサービス利用後の行動までを含む利用者から見たエンドツーエンドの範囲を現状の把握と分析の対象とすることを指す。

「制約条件を抽出する」とは、プロジェクトに関連する法律による制約だけではなく、ステークホルダーや所属組織等から課せられた条件を明らかにし、プロジェクトのスコープの明確化に役立てることである。

「前提条件を抽出する」とは、プロジェクト計画を立てるに当たって、プロジェクトを取り巻く社会情勢、関係者の状況、過去の経緯等の前提となる事実を明らかにすることである。前提条件は、プロジェクトが進む過程で変化する可能性もあるため、前提条件のモニタリングが必要である。

「リスクを抽出する」とは、プロジェクトについてリスクアセスメント（リスク特定、リスク分析、リスク評価）のうちリスク特定を行い、プロジェクトに影響を与えるリスクを洗い出すことである。

「問題点を抽出する」とは、利用者のニーズや政策目的やプロジェクトの目標の達成を阻害する要因を明らかにし、その根本となる原因を特定し分類することである。

分析等で収集する情報、情報収集の手法、分析・可視化手法、分析内容の例を表4-1に示す。

なお、これらの情報収集や分析は、対象とするサービス・業務や情報システムの特性に応じて、収集する情報や手法を選択して実施する。

- 表4-1

把握する情報、情報収集の手法、可視化の手法、分析内容の主要な例

<table style="width:93%;">
<colgroup>
<col style="width: 14%" />
<col style="width: 32%" />
<col style="width: 26%" />
<col style="width: 20%" />
</colgroup>
<thead>
<tr>
<th>対象</th>
<th>収集する情報</th>
<th>情報収集の手法</th>
<th>分析・可視化手法</th>
</tr>
</thead>
<tbody>
<tr>
<td><ol type="1">
<li><p>利用者</p></li>
</ol></td>
<td><ul>
<li><p>利用者の種類</p></li>
<li><p>利用者の母数、利用者数</p></li>
<li><p>利用頻度</p></li>
<li><p>利用方法</p></li>
<li><p>利用する時間帯、場所</p></li>
<li><p>利用者の性別、年齢層</p></li>
<li><p>利用者の行動</p></li>
<li><p>利用者の満足度</p></li>
<li><p>利用者の要望</p></li>
</ul></td>
<td><ul>
<li><p>アンケート</p></li>
<li><p>インタビュー</p></li>
<li><p>観察</p></li>
<li><p>意見の公募</p></li>
</ul></td>
<td><ul>
<li><p>一覧化</p></li>
<li><p>ペルソナ</p></li>
<li><p>ジャーニーマップ</p></li>
</ul></td>
</tr>
<tr>
<td><ol start="2" type="1">
<li><p>業務</p></li>
</ol></td>
<td><ul>
<li><p>サービス・業務の内容</p></li>
<li><p>サービス・業務の流れ</p></li>
<li><p>サービス・業務量</p></li>
<li><p>実施体制</p></li>
<li><p>実施時期・時間・ピーク性</p></li>
<li><p>実施場所</p></li>
<li><p>運営実績</p></li>
<li><p>各種指標の状況</p></li>
<li><p>残存課題</p></li>
</ul></td>
<td><ul>
<li><p>ドキュメントの収集</p></li>
<li><p>既存情報システムからのデータ収集</p></li>
<li><p>インタビュー</p></li>
<li><p>観察・測定</p></li>
<li><p>アンケート</p></li>
</ul></td>
<td><ul>
<li><p>一覧化</p></li>
<li><p>ツリー図</p></li>
<li><p>業務フロー</p></li>
<li><p>滞留状況分析図（ヘビ図）</p></li>
<li><p>ユースケース</p></li>
</ul></td>
</tr>
<tr>
<td><ol start="3" type="1">
<li><p>データ</p></li>
</ol></td>
<td><ul>
<li><p>業務において取り扱う情報資産</p></li>
<li><p>データの内容</p></li>
<li><p>データの流れ</p></li>
<li><p>入出力</p></li>
<li><p>処理件数</p></li>
<li><p>データ量</p></li>
<li><p>データ品質</p></li>
<li><p>標準の活用状況</p></li>
<li><p>データの保有形態</p></li>
<li><p>データの管理プロセス</p></li>
<li><p>オープンデータとしての公開状況</p></li>
<li><p>情報セキュリティレベル</p></li>
</ul></td>
<td><ul>
<li><p>ドキュメントの収集</p></li>
<li><p>既存情報システムからのデータ収集</p></li>
<li><p>実績データの収集</p></li>
<li><p>ヒアリング</p></li>
</ul></td>
<td><ul>
<li><p>一覧化</p></li>
<li><p>クラス図</p></li>
<li><p>ＥＲＤ</p></li>
</ul></td>
</tr>
<tr>
<td><ol start="4" type="1">
<li><p>既存の情報システム</p></li>
</ol></td>
<td><ul>
<li><p>情報システムの内容</p></li>
<li><p>外部インタフェース仕様</p></li>
<li><p>残存課題</p></li>
</ul></td>
<td><ul>
<li><p>ドキュメントの収集</p></li>
<li><p>ヒアリング</p></li>
</ul></td>
<td><ul>
<li><p>一覧化</p></li>
</ul></td>
</tr>
<tr>
<td><ol start="5" type="1">
<li><p>情報システム運用</p></li>
</ol></td>
<td><ul>
<li><p>運用実績</p></li>
<li><p>運用・保守コスト</p></li>
<li><p>各種指標の状況</p></li>
<li><p>残存課題</p></li>
</ul></td>
<td><ul>
<li><p>ドキュメントの収集</p></li>
<li><p>実績データの収集</p></li>
<li><p>ヒアリング</p></li>
</ul></td>
<td><ul>
<li><p>一覧化</p></li>
<li><p>グラフ</p></li>
<li><p>ヒートマップ</p></li>
</ul></td>
</tr>
<tr>
<td><ol start="6" type="1">
<li><p>関連調査</p></li>
</ol></td>
<td><ul>
<li><p>類似サービス・業務の情報</p></li>
<li><p>過去の事例</p></li>
<li><p>関連法令</p></li>
<li><p>現在・将来の環境変化</p></li>
<li><p>取り扱うデータに関する標準化状況</p></li>
</ul></td>
<td><ul>
<li><p>ドキュメントの収集</p></li>
<li><p>ヒアリング</p></li>
</ul></td>
<td><ul>
<li><p>一覧化</p></li>
</ul></td>
</tr>
</tbody>
</table>

#### 「クラウドサービスを利用するときには、ＰＪＭＯは、次の2)及び3)に掲げる業務及びデータの把握と分析の結果を踏まえ、クラウドサービスで提供される機能の喪失、低下等によるサービス停止等発生時の機密性・完全性・可用性に対する影響度の評価を行う」

サービス・業務企画において情報システム化の手法にクラウドサービスを用いることが想定される場合は、クラウドサービス上で取り扱う事が想定される情報種別を整理・把握し、情報セキュリティ上の影響度の評価を行うことが望ましい。

- 参考

ISMAP-LIU業務・情報の影響度評価ガイダンス

<https://www.ismap.go.jp/sys_attachment.do?sys_id=1c4d42f5dbfad510d2b773f4f3961923>　

ISMAP ポータルサイト

<https://www.ismap.go.jp/>

ISMAP「制度規程等」

<https://www.ismap.go.jp/csm?id=kb_article_view&sysparm_article=KB0010007&sys_kb_id=e7c01d14db21d110d2b773f4f3961918&spa=1>

ISMAP「お問い合わせ」フォーム

<https://www.ismap.go.jp/csm?id=sc_cat_item&sys_id=c8586a16dbdfa010eeab7845f39619f7>

特に「政府情報システムのためのセキュリティ評価制度（ISMAP）」の枠組みのうち、リスクの小さな業務・情報の処理に用いるSaaSを対象とした仕組みであるISMAP-LIUにおいては、クラウドサービスの登録・利用にあたって、クラウドサービス上で取り扱う情報セキュリティ上の影響度評価が低位であることが条件とされており、「業務・情報の影響度評価」として影響度評価の結果を文書化することが規定されていることに留意すること。

また、「業務・情報の影響度評価」は、新規にISMAP-LIUの申請を行うクラウドサービス提供者が事前申請を行うにあたって必須の書類の一つであるため、評価結果をクラウドサービス提供者に提供しISMAP-LIUへの事前申請を促す。なお、業務・情報の影響度評価の判断は、ＰＪＭＯの責任で行われることに留意すること。

#### 「1) 利用者の把握と分析」

「利用者の把握と分析」とは、利用者となり得る具体的な対象者及び規模を特定した上で、利用者中心で行政サービスを検討する上で基礎となる利用者の拠点、特徴、行動、満足度、要求事項等を把握し分析する活動である。

#### 「2) 業務の把握と分析」

「業務の把握と分析」とは、分析対象範囲に含まれる既存の業務の内容や流れを可視化するとともに、業務量や処理時間等の実績情報の収集及びオフィス等の実施空間や業務の実施場所を把握し分析することである。

なお、新規にサービス・業務を企画するときは、類似する業務の情報を収集し分析する。

#### 「3)データの把握と分析」

「データの把握と分析」とは、業務において取り扱う情報資産の特定及び分析並びに情報システムのデータの一覧、定義、入出力、流れ、取扱量、処理件数、品質、標準の活用状況、保有形態の状況、管理ルール、管理プロセス、オープンデータとしての公開状況（「第８章　２．5)　データマネジメントの実施」参照）等を把握し分析することを指す。またデータそのものだけでなく、メタデータ（データ自身に関する構造、特性等を説明する情報）の整備状況等についても併せて把握する。

#### 「4) 既存の情報システムの把握と分析」

「既存の情報システムの把握と分析」とは、分析対象範囲に含まれる情報システムの全体像を把握し、その構成に関する情報を収集し分析することである。

なお、新規に情報システムを構築するときは、情報の連携が想定される外部システムや、類似する情報システムの情報を収集し分析する。

#### 「5) 情報システム運用の把握と分析」

「情報システム運用の把握と分析」とは、分析対象範囲に含まれる情報システムの運用・保守で実施している作業の実態を把握するとともに、モニタリング情報を収集し分析することを指す。

#### 「6) 関連調査」

「関連調査」とは、新たなサービス・業務を企画検討する際に考慮すべき前提や参考情報として、類似するサービス・業務の内容や過去の事例、関連法令、現在・将来の環境変化、及びデータの取扱いに当たって参考又は準拠すべき標準等についての情報を収集し整理することを指す。

## サービス・業務企画内容の検討

ＰＪＭＯは、サービス・業務を企画するために、次の事項を実施するものとする。

1） 課題整理

ＰＪＭＯは、「２．現状の把握と分析」により得られた制約条件、前提条件、リスク及び問題点から、**<u>利用者にとってより高い効果が見込まれる内容について、これを取り組むべき主要課題として整理する(1)</u>**。

2） 企画案作成

ＰＪＭＯは、取り組むべき主要課題を、利用者にとって有益かつ政策目的が実現可能な企画となるよう、**<u>具体的なサービス・業務内容とその結果から期待される効果について、多角的に検討し、適切な効果見積りに基づく企画案を作成するものとする(2)</u>**。**<u>なお、企画の内容について、情報システムの利用を促進するために、有効な施策を検討する(3)</u>**ものとする。その際、必要に応じデジタル庁の支援を得ながら、サービスデザイン思考を導入するものとする。

また、**<u>当該業務のみならず、関連する制度や関連組織の関係サービス・業務にも影響が及ぶと想定される場合には、ＰＪＭＯはＰＭＯの支援を受け、関連する制度所管部門、業務実施部門と調整・協議を行う(4)</u>**ものとする。

7.  １. 趣旨

「２．現状の把握と分析」で多くの問題点が収集されるが、優先順位を把握せず、問題を解決することは効率的ではない。また、検討した企画案がどの問題を解決するのかが不明確になり、十分な効果を得られないおそれがある。

このため、課題を整理し、課題の重要度や優先度を把握するとともに、課題の本質的な原因を特定した上で、それに対する有効性の高い企画案を作成することにより、高い費用対効果を得られるサービス・業務の提供を実現する。

8.  ２. 解説

### 課題整理

現状の把握と分析にて抽出した現状の問題点は、個々の視点から提起したものであるため、プロジェクト全体の目標達成に対する重要度を考慮する必要がある。

このため、ＰＪＭＯは、プロジェクト全体の観点で現状の問題点を精査し、重点的に取り組むべき主要課題として定義する。

#### 「利用者にとってより高い効果が見込まれる内容について、これを取り組むべき主要課題として整理する」

「取り組むべき主要課題」とは、解決することにより、利用者の利便性が向上し、ニーズを満たすことが期待できる課題をいう。

サービス・業務を提供する担当者や情報システムを管理する担当者が抱える課題は、解決した結果として利用者にもたらす効果を基に、対応の優先順位を付けることに留意する。

### 企画案作成

「1) 課題整理」で定義された主要課題は、根本原因の解決策、解決により達成が期待される効果、及び、企画として実現するための具体的な手段を具体化し、企画案として明らかにする。

なお、具体的な手段として、今後継続的にサービス・業務の提供が可能な新しい技術・手法を用いることに留意する。

#### 「具体的なサービス・業務内容とその結果から期待される効果について、多角的に検討し、適切な効果見積りに基づく企画案を作成するものとする」

「多角的に検討し」とは、業務手順や制度変更等の情報システム化以外の実現手段、新しい技術や開発手法を含む複数の実現方式、実現手段と実現方式を組み合わせた達成効果の試算等を比較し、検討することである。

#### 「なお、企画の内容について、情報システムの利用を促進するために、有効な施策を検討する」

「有効な施策」とは、利用者にとって有益かつ政策目的が実現可能な企画がもくろみどおりに効果を上げるよう、情報システムの利用者の数や利用頻度を増やすために行う活動及び仕組みを指す。利用促進のための施策は、情報システムの利用者の種類、特性及び利用において配慮すべき事項を考慮して検討する。

#### 「当該業務のみならず、関連する制度や関連組織の関係サービス・業務にも影響が及ぶと想定される場合には、ＰＪＭＯはＰＭＯの支援を受け、関連する制度所管部門、業務実施部門と調整・協議を行う」

「当該業務のみならず、関連する制度や関連組織のサービス・業務にも影響が及ぶと想定される場合」とは、当該サービス・業務と関連する制度自体を改正する必要がある場合や、関連組織の現行のサービス・業務の内容、役割分担、実施方法等を変更する必要がある場合等、何らかの影響を与えることが想定される状況を表す。

なお、関連する制度や関連組織のサービス・業務に影響を与えないと判断した場合にも、ＰＪＭＯは、関連する制度所管部門、業務実施部門に対し当該サービス・業務の変更内容に関する情報共有を行うことを推奨する。

## 軌道修正

ＰＪＭＯは、**<u>プロジェクト初期に構想したサービス・業務企画の方向性等が、「３．1) 課題整理」で得られた結果又は「３．2) 企画案作成」で作成した企画案とかい離がある場合、プロジェクト計画の修正を検討するものとする(1)</u>**。

9.  １. 趣旨

プロジェクト立上げ時において、新しいサービス・業務の企画内容・方向性を定義している。

その後、現状把握及び分析を経て、事実に基づきサービス・業務企画内容を作成するが、その結果と当初定義した内容と大きくかい離することがある。大きくかい離した状態を無視し、当初方針のままプロジェクトを続行した場合、利用者に使われないサービスの提供、プロジェクトの遅延、予算の超過等、プロジェクトの失敗を招く可能性がある。

これらプロジェクトの失敗を防ぐためには、当初の方針と新しく作成した企画案とのかい離内容を把握し、当初の方針に固執することなく、関係者との合意を経てプロジェクト計画を見直す必要がある。

10. ２. 解説

#### 「プロジェクト初期に構想したサービス・業務企画の方向性等が、「３．1) 課題整理」で得られた結果又は「３．2) 企画案作成」で作成した企画案とかい離がある場合、プロジェクト計画の修正を検討するものとする」

「プロジェクト計画の修正」とは、当初立案したプロジェクト計画の内容を見直しすることである。見直しの対象としては、例えばプロジェクトの体制、スケジュール、目標、企画の方向性等が挙げられる。見直しの方法としては、プロジェクト初期に定義したサービス・業務企画の方向性と、「３．1) 課題整理」で得られた結果又は「３．2) 企画案作成」で作成した企画案とを比較する手順とする。プロジェクト計画書の修正を行ったときは、その内容について、必ず関係者との合意を再度形成する。

「かい離がある場合」とは、比較の結果に相違点があることを指す。次に例として挙げる相違点が把握されたときには、プロジェクト計画の内容見直しのみならず、プロジェクト継続の必要性有無も含めて検討する。

- 作成した企画案に必要となる要員と当初予定した要員のスキル・経験がかい離し、必要となる要員が手配できず、体制が組めない

- 作成した企画案を実現するスケジュールが大幅に延び、サービス・業務が求められる提供時期を達成できない

- 目標にしていた主要な目標が達成できないか、想定している効果が大幅に得られない

- システム化を行う企画内容が業務フローの変更等によりシステム化以外の手段で実現可能となった

- 当初の想定に対して、大幅な予算超過が見込まれる

なお、「３．1) 課題整理」で得られた結果又は「３．2) 企画案作成」で作成した企画案とかい離がない場合は、プロジェクト計画に従って工程を進めることで構わない。

## 業務要件の定義

ＰＪＭＯは、作成したサービス・業務企画の内容を踏まえ、**<u>次の1）から8）までに掲げる事項を業務要件として定義するものとする（「第５章２．1)ア 業務要件の定義」も併せて参照）(1)</u>**。

また、業務要件のうち、既存の業務がある場合は、定義する業務要件と既存実施している業務との差異が、明確に把握できるよう留意するものとする。

なお、**<u>検討に当たっては、ＰＭＯ等の支援や助言を受けることが望ましい(2)</u>**。

1)　業務実施手順

1.  業務の実施に必要な体制、手順及びそれらを記載した業務フロー図

<!-- -->

13. 入出力情報及び取扱量、管理対象情報一覧　等

2)　規模

1.  サービスの利用者数及び情報システムの利用者数

<!-- -->

14. 単位（年、月、日、時間等）当たりの処理件数

3)　時期・時間

1.  業務の実施時期、期間及び繁忙期　等

<!-- -->

15. 業務の実施・提供時間　等

4)　場所等

業務の実施場所、諸設備、必要な物品等の資源の種類及び量　等

5)　管理すべき指標

業務の運営上捕捉すべき指標項目、把握手順・手法・頻度　等

6)　情報システム化の範囲

情報システムを用いて実施する業務の範囲及び情報システムを用いずに実施する業務の範囲

7)　業務の継続の方針等

情報システムの障害、災害等の発生時に維持すべき必須の業務について、その業務を継続させるための基本的な考え方。なお、業務継続計画を策定する必要がある業務にあっては当該計画の策定時に検討するものとする。

8)　情報セキュリティ

業務において取り扱われる情報の格付・取扱い制限等に応じた情報セキュリティ対策の基本的な考え方。業務において取り扱われる情報資産の特定及び分析を踏まえ、セキュリティ脅威を特定しリスク分析を実施する。分析の結果、個人情報等の高い情報セキュリティ対策が必要な重要な情報資産を含む場合には、通常に増してITマネジメント全体を通して情報セキュリティ対策を適切に行うものとする。

11. １. 趣旨

業務要件とは、サービス・業務企画の内容及び手順を具体化し、情報システムに求める要求を定めたものである。

情報システムを構築するために必要な機能要件及び非機能要件は、業務要件を基に定義されるものであり、曖昧な業務要件では情報システムを構築することはできない。

業務要件定義で明らかにする各項目は、最終的に目指すサービス・業務の基礎であり、業務実施部門及び制度所管部門が中心となって検討し、政策目的やプロジェクトの目標の達成とサービス・業務の円滑な運営が、バランス良く成立することに留意して検討する。

12. ２. 解説

#### 「次の1）から8）までに掲げる事項を業務要件として定義するものとする（「第５章２．1)ア 業務要件の定義」も併せて参照）」

業務要件は、サービス・業務に主眼を置いて情報システムに求める要求を定めるものであり、情報システムの機能を定義するものではないことに特に留意する。

なお、当項で定義した業務要件定義は、「第５章１．1) RFIの実施」の結果を受け、「第５章２．1)ア 業務要件の定義」にて、見直しを行う。

業務要件の定義対象事項を示せば、表4-2のとおりである。

- 表4-2

業務要件定義対象事項と定義内容

<table style="width:93%;">
<colgroup>
<col style="width: 10%" />
<col style="width: 20%" />
<col style="width: 25%" />
<col style="width: 36%" />
</colgroup>
<thead>
<tr>
<th colspan="2">定義する事項</th>
<th>記載事項</th>
<th>内容</th>
</tr>
</thead>
<tbody>
<tr>
<td><ol type="1">
<li><p>業務実施手順</p></li>
</ol></td>
<td><ol type="1">
<li><p>業務の範囲（業務機能とその階層）</p></li>
</ol></td>
<td rowspan="4"><p>業務の実施に必要な体制、手順及びそれらを記載した業務フロー図</p>
<p>入出力情報及び取扱量　等</p></td>
<td>プロジェクトの対象範囲において情報システム化されない業務を含めて、企画後の業務を構成する業務機能を階層的に整理し明らかにする。</td>
</tr>
<tr>
<td></td>
<td><ol start="2" type="1">
<li><p>業務フロー</p></li>
</ol></td>
<td><p>企画後の業務フローとして、「誰が（どの組織が）」「何を」「どのような手順で」実施するのか、また「どの部分をシステム化するのか」を明らかにする。</p>
<p>特に、作業が人手によるものか自動的に行われるのか、やり取りする情報が紙なのか電子データなのかについて、わかりやすく可視化する。</p>
<p>また、企画を実現することにより、どの業務が効率化等されるのかがわかるように、企画前の業務フローと企画後の業務フローをＡｓＩｓ（現状）／ＴｏＢｅ（将来）で比較できるように整理することが望ましい。</p>
<p>なお、業務フローの記載内容や粒度はその作成目的によって異なることに留意すること。現状の業務改革が目的であれば、現在の業務の滞留状況や利用者の利便性低下などに焦点が当たるように工夫することが重要であり、関係者が現状を理解しやすい適切な粒度で記載することとなる。</p>
<p>一方で、システムを構築するための業務要件を固める目的では、上記業務改革の視点はもちろんのこととして、さらに業務の全体範囲とシステムの対象範囲を明確にできるように、より細かな粒度で記載を行う必要がある。</p></td>
</tr>
<tr>
<td></td>
<td><ol start="3" type="1">
<li><p>業務の実施に必要な体制</p></li>
</ol></td>
<td>企画後の業務の実施に必要な体制を明らかにする。ここで定義した業務実施体制は、業務の運営開始までに、整備を行う必要がある。</td>
</tr>
<tr>
<td rowspan="2"></td>
<td><ol start="4" type="1">
<li><p>入出力情報及び取扱量</p></li>
</ol></td>
<td>企画後の業務の実施手順に沿って、入出力情報とその取扱量の見込みを明らかにする。情報システムで取り扱う情報及び情報システム以外で取り扱う情報の双方が対象である。</td>
</tr>
<tr>
<td><ol start="5" type="1">
<li><p>管理対象情報一覧</p></li>
</ol></td>
<td>管理対象情報名、管理単位、主たる用途、主な属性等</td>
<td>入出力情報から、対象業務で管理すべき情報を抽出し、その一覧を作成する。管理対象情報とは、情報システムを利用して把握、管理したい情報の基本単位のことを指す。管理対象情報は、業務観点での必要性によって細分化の粒度を決める。例えば、「申請者」という大きな粒度で管理することもできるが、業務上の必要性に応じて「新規申請者」と「更新申請者」を分けたり、さらに「法人申請者」と「個人申請者」に細分化することもできる。</td>
</tr>
<tr>
<td colspan="2"><ol start="2" type="1">
<li><p>規模</p></li>
</ol></td>
<td><p>サービスの利用者数及び情報システムの利用者数</p>
<p>単位（年、月、日、時間等）当たりの処理件数</p></td>
<td><p>企画後に想定する、サービス・業務の利用者の種類とその人数や単位当りの業務処理件数を明らかにする。</p>
<p>規模は、それを提供するために必要となる業務実施部門の組織や人数及び整備する情報システムのハードウェア台数や稼働環境等に影響を与えるため、過小や過大にならないよう適切な規模を想定することに留意する。</p></td>
</tr>
<tr>
<td colspan="2"><ol start="3" type="1">
<li><p>時期・時間</p></li>
</ol></td>
<td><p>業務の実施時期、期間及び繁忙期　等</p>
<p>業務の実施・提供時間　等</p></td>
<td><p>企画後に想定するサービス・業務の「業務を実施・提供する時期・期間・繁忙期はいつか」「業務の実施・提供時間はどの程度か」を明らかにする。ここで定義する対象は、業務に係る時間であり、情報システムを利用する時間ではないことに留意する。</p>
<p>また、例えば、繁忙期における業務量が、企画後のシステムのハードウェア台数や稼働環境に影響を与える場合は、繁忙期の業務量を平準化する等を検討し、2)で検討する「規模」について過大とならない工夫をする。</p></td>
</tr>
<tr>
<td colspan="2"><ol start="4" type="1">
<li><p>場所等</p></li>
</ol></td>
<td>業務の実施場所、諸設備、必要な物品等の資源の種類及び量　等</td>
<td><p>企画後に想定する業務の「実施場所」や、情報システム以外に必要な諸設備、物品等資源の追加・変更の見込みを明らかにする。</p>
<p>ここで定義した諸設備、物品等資源を踏まえ、調達等の必要な手立てを行う必要がある。</p></td>
</tr>
<tr>
<td colspan="2"><ol start="5" type="1">
<li><p>管理すべき指標</p></li>
</ol></td>
<td>業務の運営上捕捉すべき指標項目、把握手順・手法・頻度　等</td>
<td><p>企画後のサービス・業務の運営上、管理すべき指標を明らかにする。</p>
<p>プロジェクト計画書の目標及びプロジェクト管理要領の指標管理に記載している内容を、サービス・業務企画内容の検討結果に基づき修正し、整理する。</p></td>
</tr>
<tr>
<td colspan="2"><ol start="6" type="1">
<li><p>情報システム化の範囲</p></li>
</ol></td>
<td>情報システムを用いて実施する業務の範囲及び情報システムを用いずに実施する業務の範囲</td>
<td>企画後に想定する業務のうち、情報システムを用いて実施する範囲及び情報システムを用いずに実施する業務の範囲を明らかにする。<br />
なお、通常はこの時点で情報システム化の範囲はほぼ確定させることになるが、要件定義書を作成する過程で、最終的に決定することになる。</td>
</tr>
<tr>
<td colspan="2"><ol start="7" type="1">
<li><p>業務の継続の方針等</p></li>
</ol></td>
<td>業務の継続に伴うリスク及び基本的な考え方。なお、業務継続計画を策定する必要がある業務にあっては当該計画の策定時に検討するものとする。</td>
<td><p>業務実施部門等が定める業務継続方針を踏まえ、当該業務の停止原因となり得る要因と業務停止による影響を念頭に置き、当該業務の継続のための基本的な考え方を明らかにする。</p>
<p>継続の方針は、定常業務で想定される障害への対応と大規模災害等の発災時の対応を区別して、当該業務の継続を阻害する要因とその影響度を踏まえて、継続の方針を明らかにする。</p></td>
</tr>
<tr>
<td colspan="2"><ol start="8" type="1">
<li><p>情報セキュリティ</p></li>
</ol></td>
<td><p>業務において取り扱われる情報の格付・取扱制限等に応じた情報セキュリティ対策の基本的な考え方。なお、業務において取り扱われる情報資産の特定及び分析を踏まえ、セキュリティ脅威を特定しリスク分析を実施した結果、個人情報等の高い情報セキュリティ対策が必要な重要な情報資産を含む場合には、通常に増してITマネジメント全体を通して情報セキュリティ対策を適切に行うものとする。</p>
<p>セキュリティ脅威の特定やリスク分析については、「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」を参照すること。</p>
<p>＜参考＞</p>
<p>政府情報システムにおけるセキュリティ・バイ・デザインガイドライン（令和6年1月31日デジタル庁）</p></td>
<td><p>企画後の業務を実施する上で必要な、情報セキュリティ対策の基本的な考え方を明らかにする。</p>
<p>具体的には、情報セキュリティの対象となる情報を、本表「1)(2)業務フロー及び(4)入出力情報及び取扱量」で特定し、自府省の情報セキュリティポリシーに準拠した格付けの区分及び取り扱い制限を整理した結果である。</p></td>
</tr>
</tbody>
</table>

#### 「検討に当たっては、ＰＭＯ等の支援や助言を受けることが望ましい」

「ＰＭＯ等」とは、ＰＭＯ以外に、政府デジタル人材、高度デジタル人材、外部組織の有識者や専門的な知見を持つ職員を含むことを指す。

## 関係者への確認とプロジェクト計画書の段階的な改定

**<u>プロジェクト推進責任者はＰＪＭＯ各担当者と調整し、サービス・業務改革内容の検討結果について、関係者へ適時に情報を共有し、必要な意見を収集することに努めるものとする(1)</u>**。

また、適時、その結果をプロジェクト計画書に反映し、当該計画書の内容を更新する。

13. １. 趣旨

サービス・業務企画を確定するに当たり、利用者を含む関係者に対して幅広く企画を周知し、プロジェクト関係者以外の視点からの意見を集め、その意見を基に実現性や効果の高い内容に更新することは、利用者のニーズに合ったサービス提供をするために効果的である。

このため、企画内容が決定した時点で、具体案を関係者へ周知する。

また、周知により得られた意見を検討した結果、企画内容等への変更が必要と判断されたときには、企画内容等を見直し、プロジェクト計画の見直しも行う。

プロジェクト計画書への反映については、標準ガイドライン解説書「第３編第２章 プロジェクトの管理」を参照すること。

14. ２. 解説

#### 「プロジェクト推進責任者はＰＪＭＯ各担当者と調整し、サービス・業務改革内容の検討結果について、関係者へ適時に情報を共有し、必要な意見を収集することに努めるものとする」

「関係者へ適時に情報を共有し」とは、各府省のＷｅｂサイト等で広く一般に公開することや情報共有Ｗｅｂサイトを設け特定の関係者が閲覧できるようにすることを指す。これにより、ＰＪＭＯは企画内容に関する情報提供や意見交換を行い、サービス・業務企画内容の方向性を確認する。

「必要な意見を収集する」とは、関係者に対してあらかじめ意見収集の意図を説明した上で、意見を収集することを指す。特に多様な関係者が利用する情報システムの場合は、多様なニーズを効果的に収集するために、事前に関係者へ意見収集の意図を説明した上で実施することが重要である。

デジタル社会推進実践ガイドブック DS-110

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

（第３編第５章 要件定義）

2025年（令和７年）5月27日

デジタル庁

<table>
<colgroup>
<col style="width: 100%" />
</colgroup>
<thead>
<tr>
<th style="text-align: left;"><p>〔ドキュメントの位置付け〕</p>
<blockquote>
<p>Informative</p>
<p>参考とするドキュメント</p>
</blockquote>
<p>〔キーワード〕</p>
<blockquote>
<p>ＲＦＩ、ヒアリング、要件定義書、機能要件、非機能要件</p>
</blockquote>
<p>〔概要〕</p>
<blockquote>
<p>標準ガイドラインの下位文書として、標準ガイドラインの記載の趣旨、目的等を理解しやすくするため、逐条的な解説等を記載した参考文書。</p>
</blockquote></th>
</tr>
</thead>
<tbody>
</tbody>
</table>

改定履歴

<table>
<colgroup>
<col style="width: 17%" />
<col style="width: 17%" />
<col style="width: 65%" />
</colgroup>
<thead>
<tr>
<th style="text-align: center;">改定年月日</th>
<th style="text-align: center;">改定箇所</th>
<th style="text-align: center;">改定内容</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: center;">2025年5月27日</td>
<td>第５章２．</td>
<td><p>・標準ガイドラインからの引用箇所について、標準ガイドラインの改定に合わせて修正</p>
<p>・標準ガイドラインの改定に合わせて、表5-1（機能要件定義対象要件と定義内容）のデータに関する事項にデータマネジメントに関する記載を追加</p>
<p>・標準ガイドラインの改定に合わせて、表5-2（非機能要件定義対象要件と定義内容）に「l) データマネジメントに関する事項」を追加（それに伴い表内の項番を修正）</p></td>
</tr>
<tr>
<td rowspan="2" style="text-align: center;">2024年5月31日</td>
<td>第５章１．</td>
<td><p>・「無差別性」は「公平性」に含まれるため、削除</p>
<p>・「ベンダ」を「ベンダー」に修正</p></td>
</tr>
<tr>
<td>第５章２．</td>
<td><p>・文書全体の表記ゆれを修正するため、「無差別性」を「競争性」に修正</p>
<p>・政府機関等サーバーセキュリティ対策のための統一基準群の文書名と改訂日を修正し、ＵＲＬを追加</p>
<p>・情報システムに係る政府調達におけるセキュリティ要件策定マニュアルのＵＲＬを追加</p>
<p>・項番のズレを修正</p>
<p>・情報アクセシビリティ自己評価様式の名称を修正</p></td>
</tr>
<tr>
<td style="text-align: center;">2023年5月12日</td>
<td>第５章２．</td>
<td>・情報システム内で作成されるデータに対しての公文書管理法上の記載を追加</td>
</tr>
<tr>
<td rowspan="2" style="text-align: center;">2023年3月31日</td>
<td>第５章１．</td>
<td>・標準ガイドラインからの引用箇所について、標準ガイドラインの改定に合わせて修正</td>
</tr>
<tr>
<td>第５章２．</td>
<td><p>・標準ガイドラインからの引用箇所について、標準ガイドラインの改定に合わせて修正</p>
<p>・実現案について事業者の創意と工夫を提案として受けられるように配慮するよう記載を追加</p>
<p>・情報システム稼働環境に関する記載を修正</p>
<p>・教育に関する事項について、国民等の多数の利用者が参照するマニュアルを利用環境に応じて閲覧・検索しやすい形式で提供するよう努める旨の記載を追加</p>
<p>・システム方式に関する事項において、特にクラウドサービスについては極力クラウドネイティブな構成となるよう留意する旨の記載を追記</p>
<p>・システム方式の決定について、要件の記載の粒度に配慮するよう記載を追加</p>
<p>・「中央省庁における情報システム運用継続計画ガイドライン」を「政府機関等における情報システム運用継続計画ガイドライン」に修正</p>
<p>・「内閣官房情報セキュリティセンター」を「内閣官房 内閣サイバーセキュリティセンター」に修正</p>
<p>・政府相互運用性フレームワーク（ＧＩＦ）に関する記載を追加</p>
<p>・情報システム内で作成されるデータに関する記載を追加</p></td>
</tr>
<tr>
<td rowspan="2" style="text-align: center;">2022年4月20日</td>
<td><p>第５章１．</p>
<p>第５章２．</p></td>
<td>・標準ガイドラインからの引用箇所について、標準ガイドラインの改定に合わせて修正</td>
</tr>
<tr>
<td>第５章２．</td>
<td><p>・府省ＣＩＯ補佐官の記載を削除し、関連箇所を修正</p>
<p>・「齟齬」を「そご」に修正</p>
<p>・府省共通システムの記載を削除</p>
<p>・府省重点プロジェクトの記載を削除し、関連箇所を修正</p>
<p>・デジタル・ガバメント実行計画の廃止に伴い、関連箇所を修正</p>
<p>・文字情報基盤整備事業に関するＷｅｂサイトの所管団体及びＵＲＬを修正</p>
<p>・政府機関等における情報システム運用継続計画ガイドラインを最新版の名称に変更</p>
<p>・政府機関等の情報セキュリティ対策のための統一基準群を政府機関等のサイバーセキュリティ対策のための統一基準群に変更し、関連箇所を修正</p></td>
</tr>
<tr>
<td rowspan="2" style="text-align: center;">2021年3月30日</td>
<td>第５章２．</td>
<td>・体裁を修正</td>
</tr>
<tr>
<td>第５章２.</td>
<td>・データ利活用促進を含めたデータ要件を「データに関する事項」として集約して追加、及びデータマネジメント強化関連の修正・追加</td>
</tr>
<tr>
<td style="text-align: center;">2020年11月27日</td>
<td style="text-align: left;">第５章３．</td>
<td style="text-align: left;">・ODBに関する記載を削除</td>
</tr>
<tr>
<td rowspan="3" style="text-align: center;">2020年3月31日</td>
<td style="text-align: left;">第５章２．</td>
<td style="text-align: left;">・機能要件、非機能要件及び情報システムの実現案についてＰＪＭＯ全体で決定することの重要性について追加</td>
</tr>
<tr>
<td style="text-align: left;">第５章２．</td>
<td style="text-align: left;">・要件定義書の記載における機能要件の定義で踏まえるべき内容を追加</td>
</tr>
<tr>
<td style="text-align: left;">第５章２．</td>
<td style="text-align: left;">・機能要件定義対象要件と定義内容について一部追加</td>
</tr>
<tr>
<td style="text-align: center;">2019年2月27日</td>
<td style="text-align: left;">－</td>
<td style="text-align: left;">・初版決定</td>
</tr>
</tbody>
</table>
