第１章　ＩＴマネジメントの全体像

ＰＪＭＯは、本編に規定されている手順に基づき、政府情報システムを用いるサービス・業務の企画、運営及び改善を計画的に実施するものとする。本編の位置付け及び全体像は、次のとおりである。なお、本編において、「政府情報システム」は「情報システム」と省略して記載する(1）。

  1. １. はじめに

本編は、ＰＪＭＯが政府情報システムの整備及び管理に係るプロジェクトを実施するに際し、サービス・業務の円滑な構築・運営を通じて利用者に価値を提供し、高い費用対効果をもって政策目的やプロジェクトの目標を実現できることを目的として、プロジェクトの実施に係る手順を定めるものである。

情報システムの整備及び管理は、多岐にわたる活動から構成され、専門的な内容が多く含まれるため、前提知識や経験のない職員にとって、全体像が理解しづらいものとなっている。

このため、本章ではＩＴマネジメントの活動の位置付け、全体構成及び流れについて概説し、以降の章における記載の前提となる条件や考え方を示す。

「政府情報システム」は「情報システム」と省略して記載する

本ガイドラインの対象は政府情報システムであるが、第３編においてこの用語が頻出するため、読みやすさのために省略した記載としている。

なお、「政府情報システム」には、例えば次のようなものが挙げられる。

  • スクラッチ開発により独自に構築した情報システム

  • パッケージソフトウェア製品やSaaSの標準機能を利用した情報システム

  • パッケージソフトウェア製品やSaaSの機能を前提に、必要なカスタマイズを行って構築した情報システム

  • 行政サービス等のために独自に構築したスマートフォン版アプリケーション

  • 広報等のために独自に構築したＷｅｂサイト

  • 概念検証（ＰｏＣ）を行うために構築した情報システム

政府情報システムに対しては、ＩＴガバナンスやＩＴマネジメントを包括的かつ一体的に行うことで、情報システムの価値（便益の実現、リスクの適正化、資源の適正化）を実現することを目的に、標準ガイドラインを適用するものである。

ＩＴマネジメントの位置付け

本ガイドラインにおいて、ＩＴマネジメントとは、情報システムを活用するプロジェクトの計画、整備、運営、状況把握の一連の活動のことである。

この活動の目的は、デジタル技術を活用して利用者中心のサービス・業務改革を推進するため、サービス・業務改革を支える情報システムの整備及び管理に係る各プロジェクトにおいて、利用者が実感できる効果を確実に達成することである(1)。

標準ガイドラインでは、ＰＪＭＯによるＩＴマネジメントが、デジタル庁やデジタル統括責任者を頂点とするＩＴガバナンスにより適正化されるよう、ＩＴガバナンスとＩＴマネジメント及びその各章を、図 ３-1のように位置付けて規定している。

図 ３-1　ＩＴガバナンスとＩＴマネジメント及びその各章の関係（イメージ）

  1. １. 趣旨

本節は、標準ガイドラインにおける「ＩＴマネジメント」を定義するとともに、ＩＴガバナンスとの関係性や「ＩＴマネジメント」に含まれる本編各章間の関係性を示したものである。

  1. ２. 解説

「サービス・業務改革を支える情報システムの整備及び管理に係る各プロジェクトにおいて、利用者が実感できる効果を確実に達成することである」

「サービス・業務改革を支える情報システムの整備及び管理」とは、サービス・業務及び情報システムの整備や運営等に係る直接的な活動及びプロジェクト全体を通した管理活動を指し、具体的には本編第２章から第１０章で定めるものである。

プロジェクトの資源（要員、時間、予算等）は有限であるため、すべての管理活動に対して万遍なく資源を充てるのではなく、プロジェクトが持つ特性や置かれている状況を踏まえて、便益の実現とリスク適正化の観点から重要な管理活動に重点的に資源を充てるよう優先順位を決めて資源適正化を行い、効果的かつ効率的に管理活動を実施することが重要である。

プロジェクトの標準的な活動スケジュール

ＰＪＭＯが管理するプロジェクトは、作業の特性や期間の違い等があるため、一様とはならない(1)が、プロジェクトの標準的な活動スケジュールの一例として、サービス・業務を新規に構築し事業を行うプロジェクトのイメージを、図 ３-2に示す(2)。

図 ３-2　プロジェクトの標準的な活動スケジュール

本ガイドラインにおける**プロジェクトの期間は、当該情報システムのライフサイクル期間とすることを基本とし、更改の場合は、後続プロジェクトとして当該プロジェクトと分けて管理するものとする(3)。なお、制度や業務の中で数年単位のサイクルがある場合は、プロジェクトの期間をそのサイクルに合わせて設定することもできる(4)**。

なお、情報システムが本番稼働を開始した後も、制度改正への対応、他の新たなサービスとの連携、業務内容の変更、利用状況の変化等、プロジェクト期間中に情報システムの状況に変化が生じ得る。外部環境・内部環境それぞれの変化やモニタリング結果等を踏まえ、図３-3に示すイメージのように、プロジェクトの期間を通じて何度も機能改修のサイクルを繰り返し、情報システムの有効性を高め続けることが重要である。

図３-3　プロジェクト期間を通じた機能改修のサイクル

ＰＪＭＯは、プロジェクトにおける各活動を実施するための体制、予算、期間等が十分に確保できるように考慮して、プロジェクトの全体像をとりまとめるものとする(5)。

  1. １. 趣旨

プロジェクトの活動は、それぞれが密接に関連している。例えば、予算要求の提出や調達の開始等の作業が遅延すると、プロジェクトの他の活動の遂行に影響が発生する。さらに、プロジェクトの特性や期間の違い等により、各活動の関係性は異なる。

このため、プロジェクトの進め方には様々なパターンが存在することを認識した上で、それぞれのプロジェクトの全体的な流れをつかみ、活動の順序や期間を踏まえ、いつ何をしなければならないかを把握することが重要である。

  1. ２. 解説

「ＰＪＭＯが管理するプロジェクトは、作業の特性や期間の違い等があるため、一様とはならない」

「作業の特性や期間の違い等」とは、例えば、表１-1に示すようなプロジェクトに違いを生む要因を指す。

  • 表1-1

プロジェクトに係る差異の例

要因の種類具体例
サービス・業務の内容運営するサービス・業務の内容、利用者の種類、利用量　等
実施環境や制約構築する期間、予算、関係者及び経済情勢　等
プロジェクトの規模ステークホルダーの範囲（利用者に国民を含む、職員のみ利用等）、処理件数、機能数、関係するプロジェクトの数　等
情報システムの整備内容新規開発、改修開発、再構築、運用、製品・サービス購入、移行　等
情報システムの整備方法情報システムの開発形態（スクラッチ開発、パッケージ導入、クラウドサービス利用等）、開発手法（ウォーターフォール、アジャイル等）

「プロジェクトの標準的な活動スケジュールの一例として、サービス・業務を新規に構築し事業を行うプロジェクトのイメージを、図 ３-2に示す」

「図 ３-2」で示したプロジェクトの標準的な活動スケジュールは、情報システムを新規に構築するときに、設計・開発期間が単年度となることを想定したものである。

設計・開発期間が単年度となるような規模が小さいプロジェクトでは、設計・開発と運用・保守を分割して調達することにより得られる効果が少ない場合があるため、費用対効果を踏まえて、設計・開発、運用・保守をまとめて調達することも検討する。なお、運用・保守の契約期間を短期に設定し、更新のタイミングで費用の見直しを検討することも効果的である。

「図 ３-2」以外にも、プロジェクトの標準的な活動スケジュールには様々なパターンがある。その他の代表的なパターンを、次に３例示す。

  • クラウドサービス利用の場合

例１　クラウドサービスを利用して新規サービスを構築する場合

設計・開発が複数年度にまたがり、かつ、クラウドサービスを用いて新規サービスを構築する場合の例を図1-1に示す。SaaSで提供されるアプリケーションを利用する場合も図1-1と同様である。

  • 図1-1

※ クラウドサービスをＰＪＭＯが個別に調達する場合

特徴及び留意点

クラウドサービスを利用することで、情報システムの利用量や処理量の増減等に合わせてハードウェア等の規模、処理性能、ライセンス数等を柔軟に調整することができる。

  1. クラウドサービスを利用する場合、様々な調達の方法が存在する。例えば、クラウドブローカーを通して、設計・開発又は保守・運用とクラウド環境をまとめて調達する等の方法では、ハードウェア等の賃貸借を行う場合と比較して予算要求や調達の単位が変わる。また、設計・開発、保守・運用、環境をまとめて調達する場合もある。

  2. クラウドサービス利用であっても、定期的にサービス・業務の改善が行われるよう、サービス開始から５か年での切替えを目安に後続プロジェクトの開始を計画する。

  • 実証実験の場合

例２　実証実験で新規サービスを構築する場合

実証実験で新規サービスを構築し、効果を確認後に本格的にサービス構築する場合の例を図1-2に示す。

  • 図1-2

特徴及び留意点

実証実験とは、全ての機能を一度に構築するのではなく、試行版（プロトタイプ）を先に構築・評価しながら、段階的に情報システム全体を構築していく手法を指す。検討段階で最適な要件や実現方式等が定まらない場合やプロジェクト効果に対する検証を事前に行う場合等にこの手法を用いることは有効である。

なお、実証実験の開発であっても、要件定義を曖昧にしたままプロジェクトを進めることは、許容されない。

  1. プロジェクト効果の実現性や実現案の妥当性を検証すること等を目的とし、システム構築を複数の段階に分け、情報システムの効果を計るために必要な最低限の機能から構築し、効果のモニタリングを行う。
  1. モニタリング結果を踏まえて、サービス・業務企画や要件定義を見直し、本格的な情報システムの開発を行う。
  • 設計・開発が複数年度の場合

例３　複数年度の設計・開発により新規サービスを構築する場合

設計・開発が複数年度にまたがり新規サービスを構築する場合を図1-3に示す。

  • 図1-3

プロジェクトの全体像及び流れ（設計・開発が複数年度の場合）

特徴及び留意点

  1. 開発の規模が大きい場合、複数の事業者を束ねる高度な開発管理能力が求められることが予想される。このため、「図1-3」には示していないが、設計・開発期間における職員側の業務支援を行うプロジェクト管理支援事業者を委託することも一般的な選択肢となる。

「プロジェクトの期間は、当該情報システムのライフサイクル期間とすることを基本とし、更改の場合は、後続プロジェクトとして当該プロジェクトと分けて管理するものとする」

「情報システムのライフサイクル期間」とは、情報システムの計画・企画、構築から運用・保守を経て廃止するまでの期間を指す。この期間は、オンプレミスの場合、ハードウェア、ソフトウェア製品等の保守期間等を考慮し、サービス開始年度から５か年程度の期間を目安とする。

一方、クラウドサービスの場合は、ハードウェア、ソフトウェア製品等による制約を必ずしも受けないため、オンプレミスのようにライフサイクル期間を５か年程度にする必要性は低く、ライフサイクル期間を柔軟に調整することができる。例えば、短期間で継続的な見直し※を行うことで、５か年を超えて一つのクラウドサービスの利用を継続することが考えられる。ただし、技術の進展や、定期的なサービス・業務の改善の必要性を鑑み、サービス開始年度から５か年程度を目安に更改（ライフサイクル期間の終了）の要否を検討する。

契約期間について、クラウドサービスの単年度契約を重ねる場合は、年間での利用実績を踏まえて翌年度の契約内容を定めることができるため、利用量に見合った契約額にでき、加えて、利用料が引き下げられるとコストの削減も可能となる。一方、複数年契約の場合は、複数年度にわたって複数年予約型割引を活用することで、さらに価格を引き下げられる可能性がある。これらを踏まえて、ＰＪＭＯは、プロジェクトの特性に応じて、契約期間を判断し、予算要求を行う。

なお、単年度契約、複数年契約いずれの場合においても、更改や継続的な改善に関する上述の考え方は変わらない。

「当該情報システムの更改の場合」とは、標準ガイドライン「第３編第２章６．後続プロジェクトの策定」及び標準ガイドライン「第３編第８章４．情報システムの改善」で示される場合を指す。

「分けて管理する」とは、更改に当たっては、通常のプロジェクトと同様に、プロジェクトが達成すべき目標を明確にし、プロジェクト計画やサービス・業務企画等のプロセスを適正に行う必要があるため、原則として当該プロジェクトとは別のプロジェクトとして扱うことを指す。ただし、後続プロジェクトへの情報提供や移行作業等、当該プロジェクトとして行わなければならない作業がある点にも留意する必要がある（標準ガイドライン解説書「第３編第９章４．運用及び保守の引継ぎ」参照）。

なお、負担を軽減する観点から、当該プロジェクトと後続プロジェクトの達成目標を明確にすることを前提とし、同一プロジェクトとして管理することも可能である。

※ 継続的な見直しには以下のようなものが挙げられる。

  • クラウドサービス提供者によりリリースされた新サービスの活用

  • 利用実績を踏まえたリソースのチューニング

  • 技術の進展を踏まえた小規模な業務の見直し

    一方で、更改には以下のようなものが挙げられる。

  • システムアーキテクチャの大幅な変更

  • 利用するクラウドサービスの変更

「制度や業務の中で数年単位のサイクルがある場合は、プロジェクトの期間をそのサイクルに合わせて設定することもできる」

「制度や業務の中で数年単位のサイクルがある場合」とは、例えば制度上で３年に１度の料率見直しが求められている場合や、業務上で５年に１度の大規模調査を行うことが定められている場合等、制度や業務に基づくサイクルが存在する場合を指す。このような制度・業務に基づくサイクルとプロジェクトの期間が異なると、サービス・業務の提供中にシステム更改を行う必要が発生するなど実務上で非効率になることが想定される。

そのため、制度・業務に基づくサイクルがある場合には、情報システムを構成するハードウェア、ソフトウェア等のサポート期限にも留意した上で、プロジェクト期間を制度・業務に基づくサイクルに合わせることができる。

「プロジェクトの全体像をとりまとめるものとする」

「プロジェクトの全体像をとりまとめる」とは、プロジェクト計画書・管理要領を作成した上で、プロジェクトの全体像を関係者にわかりやすく共有することを指す。詳細は第２章で詳述する。

プロジェクトを適切に推進するために留意すべき事項

1)　セキュリティ・バイ・デザインの実施

近年の大規模かつ高度なサイバー攻撃に対応するために、情報システムのライフサイクル全般を通じてセキュリティ確保に努めること(1)。

例えば、設計・開発段階でセキュリティ対策を実施するのみで完結するのではなく、技術やセキュリティ脅威等の外部環境や仕様変更等の内部環境の変化に応じて、継続的に対策を見直すことに留意すること。

2)　クラウドサービスの適切な利用

クラウドサービスを利用して情報システムを整備する際は、「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」の記載に従って、適切にクラウド移行を行うこと。

3)　情報システムの安定的な運用

プロジェクトの推進においては情報システムを整備することに着目しがちであるが、情報システムが本番稼働を開始した後も、日頃の運用・保守作業を確実に行い、利用者が情報システムを安定的に利用できるように努めること(2)。その上で、機能改修のサイクルを繰り返し、情報システムの有効性を高め続けることも重要である。

4）テーラリングの実施

標準ガイドラインでは、デジタル庁及び各府省のサービス・業務改革並びにこれらに伴う政府情報システムの整備及び管理の手続・手順に関する基本的な方針を示している。しかし、プロジェクトが持つ特性や置かれている状況は異なり、画一的に適用してもプロジェクトが目指す成果を達成できない懸念がある。そのため、プロジェクトへの適用に当たり、ＰＪＭＯは、本ガイドラインが示すＩＴマネジメントの内容をテーラリング注記）することが重要である(3)。

注記）テーラリングとは、個々のプロジェクトの特性等に応じて、手続・手順や成果物などを適切に調整して適用することをいう。

5)　非常時におけるプロジェクト推進

平常時のみならず感染症の拡大、大規模災害の発生等の非常時においても、ＰＭＯ等の支援や助言を受けるなど、適切なサービスを提供するために必要な開発プロセスを経るものとする(4)。

  1. １. 趣旨

本節は、ＰＪＭＯが適切にプロジェクトを推進するために、留意すべき事項を示したものである。

  1. ２. 解説

「情報システムのライフサイクル全般を通じてセキュリティ確保に努めること」

近年は、サイバー攻撃の大規模化/高度化に伴い、確実にかつ効率的に情報システムのセキュリティを確保するため、システム開発の企画工程からセキュリティを実装するセキュリティ・バイ・デザインの必要性が高まっている。

詳細は「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」を確認した上で、セキュリティ・バイ・デザインとして、組織にとって適切な実施プロセス、リスク評価、リスク管理体制を導入することで、企画段階からセキュリティリスクへの対応方針を定め、システム運用に至るまで一貫したセキュリティ対策及びセキュリティリスク管理を実施するように努めること。

「情報システムが本番稼働を開始した後も、日頃の運用・保守作業を確実に行い、利用者が情報システムを安定的に利用できるように努めること」

「情報システムが本番稼働を開始した後も、日頃の運用・保守作業を確実に行い、利用者が情報システムを安定的に利用できるように努めること」とは、情報システムを安定的に稼働させるためには、ＰＪＭＯと運用・保守事業者で協力し、運用作業にて稼働状態を維持することに加え、保守作業にて情報システムの脆弱性の解消、不具合対応等を実施する必要があることを指す。

なお、情報システムを継続的に利用するうちに、日頃の運用・保守作業だけではなく、利用している製品のサポート期間の終了に伴う更改等の対応が必要となる。更改等の対応に当たっては、検討に係る作業に加え、運用・保守作業に係る経費とは別に経費を要する場合があることに留意すること。

「プロジェクトへの適用に当たり、ＰＪＭＯは、本ガイドラインが示すＩＴマネジメントの内容をテーラリング注記）することが重要である」

本ガイドラインの「第３編 ＩＴマネジメント」では、多種多様なプロジェクトが存在する中で、多くのプロジェクトに共通する状況を前提として実施内容を示している。そのため、本ガイドラインを画一的に適用してもプロジェクトが目指す成果を達成できない懸念がある。ＰＪＭＯは、プロジェクトを主体的に推進する必要があるため、政府情報システムに関する法令や各府省で定められているルールを順守することを前提に、プロジェクトの目的や特性等を踏まえて、テーラリングを適切に実施するものとする。

なお、テーラリングの実施に当たっては、有識者等の支援や助言を受けるなど、プロジェクトを適切に推進するために必要な措置を講ずることが重要である。テーラリングの内容や実施する措置については、例えばプロジェクト計画書に記載する等、明確に記録する。また、テーラリングは、プロジェクトの開始時にのみ行うものではなく、プロジェクト期間を通して継続的に検討・実施する。

以下では、「テーラリング」の対象となるものを例示する。

  • 情報システムのライフサイクルや工程の進め方

    • 情報システムの開発手法を踏まえて、標準ガイドラインで示している工程や実施内容をテーラリングする。

例えば、アジャイル開発の場合、開発計画を策定後、スプリントのプランニング、開発、レビューというサイクルを繰り返し実施する。

  • 標準ガイドラインでは、 テスト工程は、単体テスト、結合テスト、総合テスト及び受入テストを実施する前提となっているが、必ずしも標準ガイドラインで示している工程でプロジェクトを推進するものではなく、情報システムの特性に応じて工程や実施内容をテーラリングする。テーラリングした内容は、全体テスト計画書へ反映する。 例えば、SaaSのサービスや機能をそのまま利用する場合、クラウドサービス提供者が品質を担保してリリースしているため、設計・開発事業者が単体テストや結合テストを実施する必要性が低く、SaaSの設定内容の確認を中心にテストを実施する。ただし、テストに際しては機能面の確認だけでなく、セキュリティ等を含めた非機能面のテストも重要であることに留意すること。

  • クラウドサービスを利用して情報システムを構築する場合に、オンプレミスのようにハードウェア等の定期的な更改が必要ではないため、更改のサイクルを長くして、更改にかかる費用を抑える。

  • プロジェクトの管理方法

    • アジャイル開発の場合、標準ガイドラインで示しているＰＪＭＯの体制を前提とした上で、プロジェクト推進責任者又はプロジェクト推進管理者がプロダクトオーナーの役割を果たし、機動的にアジャイル開発を推進できる体制を組成する。

  • サービス・業務改革並びにこれらに伴う政府情報システムの整備及び管理に関する手続・手順

    • サービス・業務企画では、現状の課題を基に、利用者のニーズを把握した上で、利用者の立場からの検討に基づいて業務要件を定義する前提となっているが、ＡＩなど応用範囲の広いデジタル技術を使って新規に情報システムの構築を検討する場合、先行してＡＩなどのデジタル技術を利用できる最小限の情報システムを調達した上で、利用者のニーズの現状把握に加えて、概念検証（ＰｏＣ）で当該技術を使いながら、当該技術の実現可能性の検証と潜在的な利用者のニーズの把握を実施して、サービス・業務企画を実施する。

    • サービス・業務企画は利用者の視点から実施することとしているが、ライフサイクルコストや運用・保守の効率性の視点からSaaSやパッケージソフトウェア製品の利用を検討する。その場合、現状のサービス・業務と合わない機能が出てくる場合があり得るが、SaaSやパッケージソフトウェア製品の標準的な機能に合わせて現状の業務の見直しを行う。

    • 業務分析を実施し、帳票は必要がないと判断した場合、機能要件定義対象要件のうち帳票に関する事項等の検討は実施しない。

    • 契約方式は、一般競争入札（総合評価落札方式を含む。）を原則としているが、例外的に随意契約を行う場合には、発注者と事業者間で一連の調達手続きが進められるため、「第６章　３．2）調達に関する公告」「第６章　５．入開札」等を実施しない。随意契約においては、発注者が事業者と作業内容や実現方法について適切に交渉を行って、コスト削減を図る。

    • 調達の際に事業者が業務や制度の特殊性を理解できるよう解説する資料を作成する。

  • 納品成果物

    • 設計・開発工程においてSaaSのサービスや機能をそのまま利用する場合、設計書の代わりに、当該サービスや機能の設定情報や設定情報を定めた根拠等を文書として取りまとめる。

    • スマートフォン版アプリケーションを利用者が直感的に操作できるように構築した場合、システム操作マニュアルは作成しない。

    • SaaSは、クラウドサービス提供者がサービス・機能を運用するため、発注者の運用の自由度が少ない場合がある。この場合においては、標準ガイドラインの記載どおりに運用計画書・運用実施要領・各種手順書を個別に作成するのではなく、必要な作業を網羅する形で一つの文書として作成する。また、運用報告書等の日常業務で使用する文書についても記載事項の絞り込みを検討する。

    • 運用事業者と保守事業者を分けない場合に、成果物の作成を効率化する観点から運用計画書と保守計画書を一つの計画書として作成する。

「平常時のみならず感染症の拡大、大規模災害の発生等の非常時においても、ＰＭＯ等の支援や助言を受けるなど、適切なサービスを提供するために必要な開発プロセスを経るものとする。」

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

なお、非常時においても、プロジェクトの新規立ち上げ時に確認する内容として示した、目標設定、手段の妥当性及び費用対効果等を重点的に確認することが重要である。

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

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

（第３編第２章 プロジェクトの管理）

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

デジタル庁

改定履歴

[１. プロジェクトの立ち上げ及び初動 3](#プロジェクトの立ち上げ及び初動)

[２. プロジェクト計画の策定 10](#プロジェクト計画の策定)

[３. プロジェクト計画書等の段階的な改定 29](#プロジェクト計画書等の段階的な改定)

[４. プロジェクトの実施 35](#プロジェクトの実施)

[５. デジタル庁によるレビュー 44](#デジタル庁によるレビュー)

[６. 後続プロジェクトの策定 45](#後続プロジェクトの策定)

[７. プロジェクトの終結 46](#プロジェクトの終結)

[８. 一元的なプロジェクト監理 49](#一元的なプロジェクト監理)