第２章 プロジェクトの管理
目次
第２章 プロジェクトの管理
ＰＪＭＯは、次のとおりプロジェクトの管理を行うものとする。
１. はじめにプロジェクトは、「第１章 ＩＴマネジメントの全体像」で示すとおり、長期間にわたり、様々な活動から構成され、それぞれの活動が相互に密接に関連する。これらの活動は、ＰＪＭＯがそれぞれ必要となる予算、人員や関係者、期間等が異なることを前提に進めることとなる。
一方で、その遂行に当たっては、政策目的やプロジェクトの目標の達成を阻害する多様な問題も発生する。
このため、ＰＪＭＯはプロジェクトの管理者として、政策目的やプロジェクトの目標を確実かつ高い費用対効果をもって達成できるよう、プロジェクト全体及び個々の活動を適切な資源配分を意識して計画し、遂行時に発生する事柄に対する管理方法を事前に定義する必要がある。
なお、計画策定当初にはプロジェクト全工程の全ての内容を想定できないため、プロジェクトの進行に応じて段階的に計画を具体化・詳細化する必要がある。また、ＰＪＭＯは、この活動の状況を監視・推進し、発生する問題に対して適切に対処していかなければならない。
本章では、ＰＪＭＯがプロジェクトの管理者として、プロジェクトの初動から完了までの間に行うべき管理作業を定義している。
１. プロジェクトの立ち上げ及び初動
1) 目標の明確化 プロジェクトの立ち上げに当たっては、プロジェクトの目標を明確に定めるものとする (1) 。目標の設定に当たっては、提供しているサービスや実施している業務の状況を詳細に把握した上で、国民や職員等の利用者視点から十分に効果を実感できるものとするように留意する。 また、 法令、政府戦略、政策方針・計画や、中長期計画等の上位計画に基づいてプロジェクトを立ち上げる際には、上位計画の内容を把握し、上位計画の目標に対してプロジェクトが達成する成果を明確にした上で、プロジェクトの目標を定義するように留意する (2) 。 2) 立ち上げの承認 府省ＣＩＯは、プロジェクトの新規立ち上げに当たって、目標設定及び、手段の妥当性、費用対効果を確認し、その承認を行い、プロジェクト推進責任者及び当該プロジェクトに関する情報システム責任者を指名するものとする (3) 。（「第２編第２章２．1) 府省内全体管理」参照） 3) 体制準備 プロジェクト推進責任者は、対象となるプロジェクトを統括し、推進するためのＰＪＭＯを組織する。 ＰＪＭＯの体制は、プロジェクトの成否に影響を与える重要なものであることから、情報システム部門だけでなく、制度所管部門及び業務実施部門が適切に参画するよう組織するものとする (4) 。 また、 プロジェクト推進責任者は、プロジェクトの主目的であるサービス・業務改革の要点について、ＰＪＭＯ及び関係者が充分に理解できるように努めるものとする (5) 。 4) 事前調整 プロジェクト推進責任者はＰＪＭＯ各担当と調整し、対象となるプロジェクトに関連する主要なステークホルダーを把握し、プロジェクトへの関与の仕方について、事前調整を行うものとする (6) 。 5) 複数プロジェクトの統括管理 府省ＣＩＯは、 複数のプロジェクトを統括して管理することにより、単独でプロジェクトを管理するよりも得られる効果が高いと判断したとき (7) は、複数プロジェクトの統括管理を導入する。 複数プロジェクトの統括管理は、原則として管理対象となるプロジェクトのうち、新しいサービス・業務を実現することで達成する目標や成果に対する中心的な役割を果たすプロジェクトのＰＪＭＯが行うものとする。統括管理を行うＰＪＭＯには、各プロジェクト間の調整を十分に行える体制を確保するとともに、 統括管理するＰＪＭＯが調整を実効的に行えるよう、情報共有方法や合意形成方法等について関係者間で事前に申し合わせておくものとする (8) 。 6) サブプロジェクトの導入 プロジェクトの管理、運営を効率的に行うために、ＰＪＭＯはプロジェクト内の活動のまとまりを単位として分割し、それぞれをサブプロジェクトとして扱うことができる (9) 。 サブプロジェクトを導入した際は、プロジェクト計画書を詳細化し、各サブプロジェクトの対象範囲や実施期間等を整理する (10) 。 |
プロジェクトは立ち上げに際して目標を明確にし、その目標を達成するためにプロジェクトに関与する様々な組織が、相互に連携することが不可欠である。
しかし、プロジェクトの立ち上げ時に、ごく少数の担当者が短い期間の中で関係者との調整が不十分なままプロジェクト計画を策定し、予算要求を行ってしまうケースも少なくない。このような場合には、プロジェクトの遂行過程で様々な問題が発生し、成果が十分に達成できないおそれがある。
このような事態を防止するためには、プロジェクトの初動時に十分な体制を確保し、事前に関係者との十分な調整を図ることが最重要である。ＰＪＭＯの体制例を、図2-1に示す。
図2-1 ＰＪＭＯの体制例
２. 解説
1） 目標の明確化
（1）「プロジェクトの立ち上げに当たっては、プロジェクトの目標を明確に定めるものとする」
「プロジェクトの立ち上げ」とは、今までに存在しないプロジェクト及び既存プロジェクトの完了に伴って後続プロジェクトを立ち上げる場合を指す。
既存プロジェクトの完了に伴って後続プロジェクトを立ち上げる場合には、プロジェクトの目標や実施方法に変更が無いかを確認し、大きな変更がある場合は目標を再度明確にする必要がある。
（2）「法令、政府戦略、政策方針・計画や、中長期計画等の上位計画に基づいてプロジェクトを立ち上げる際には、上位計画の内容を把握し、上位計画の目標に対してプロジェクトが達成する成果を明確にした上で、プロジェクトの目標を定義するように留意する」
「上位計画の目標に対してプロジェクトが達成する成果を明確にした上で、プロジェクトの目標を定義する」とは、ＰＪＭＯが立案するプロジェクトの方向性が上位計画で目指す方向とかい離することを防ぐために不可欠な作業である。
プロジェクトの目標は、上位計画の目標に紐づき具体化されたものであり、プロジェクトの目標達成は、上位計画の目標達成と言える必要がある。
なお、上位計画が改定又は廃止されたときは、その変更内容に応じてプロジェクト計画を適時に見直すことが必要である。
2） 立ち上げの承認
（3）「府省ＣＩＯは、プロジェクトの新規立ち上げに当たって、目標設定及び、手段の妥当性、費用対効果を確認し、その承認を行い、プロジェクト推進責任者及び当該プロジェクトに関する情報システム責任者を指名するものとする」
「目標設定及び、手段の妥当性、費用対効果を確認し、その承認を行い」とは、プロジェクトの目標とする成果を得るために必要となる経費や人的資源等を見積り、その費用対効果が適切であること、及び実現性のあるプロジェクトであることを、府省ＣＩＯが確認し、承認することである。
「プロジェクト推進責任者及び当該プロジェクトに関する情報システム責任者を指名するものとする」において、既存プロジェクトの完了に伴って後続プロジェクトを立ち上げる場合には、府省ＣＩＯは、改めてプロジェクト推進責任者等を指名しなおす必要はない。
3） 体制準備
（4）「ＰＪＭＯの体制は、プロジェクトの成否に影響を与える重要なものであることから、情報システム部門だけでなく、制度所管部門及び業務実施部門が適切に参画するよう組織するものとする」
「制度所管部門及び業務実施部門が適切に参画する」とは、プロジェクト推進責任者が、事業に直接的に関係する業務実施部門や制度所管部門をＰＪＭＯの体制に組み込み、検討や意思決定を円滑に行える状態にすることである。ただし、情報システム部門が制度所管部門及び業務実施部門の役割を全て兼ねているときはこの限りではない。
また、技術面の支援を得るため、原則、府省ＣＩＯ補佐官もＰＪＭＯに参画するものとする。
（5）「プロジェクト推進責任者は、プロジェクトの主目的であるサービス・業務改革の要点について、ＰＪＭＯ及び関係者が充分に理解できるように努めるものとする」
「サービス・業務改革の要点」とは、当該プロジェクトの政策目的やプロジェクトの目標、その実現すべき時期、対象業務の背景となる要請やニーズ、対象業務の範囲等である。
これらの事項について、ＰＪＭＯはプロジェクト計画書の冒頭に記載するとともに、今後プロジェクトに関与する関係者に対して要点を共有した上でプロジェクトを遂行することが重要である。
4） 事前調整
プロジェクト体制を組織した後で、想定していた特定の職員等がプロジェクトに関与できないと、プロジェクト活動が計画どおり進まない、既存業務と連携できず新しい業務が運用されない等、プロジェクト遂行の阻害要因になるおそれがある。
このため、ＰＪＭＯはプロジェクト計画を立案する前に、ＰＪＭＯの体制には組み込まれていないが、プロジェクトへの関与が必要となる組織・職員等と具体的な関与の内容について事前調整を行う。実際にプロジェクトへの関与が必要になった段階で協力が得られるよう、事前調整にて合意を得る（詳細は「２．2)ア ステークホルダー管理」参照）。
プロジェクト計画を策定するときには、合意した結果を基に作業計画を立てる。
（6）「プロジェクト推進責任者はＰＪＭＯ各担当と調整し、対象となるプロジェクトに関連する主要なステークホルダーを把握し、プロジェクトへの関与の仕方について、事前調整を行うものとする」
「主要なステークホルダー」とは、「２．2)ア ステークホルダー管理」で後述する者を指す。
「プロジェクトへの関与」とは、主要なステークホルダーがプロジェクト進行中に実施する具体的な作業について、情報共有を受けた上で意思決定に参画することを指す。例えば、プロジェクトの対象とするサービス・業務とつながりを持つ業務を所管する他府省の業務実施部門とＰＪＭＯとの間で、必要な情報の提供を相互に行いながら、今後のサービス・業務改革の内容を決定するという状況下で、部門間の情報共有方法、会議開催方法、意思決定方法等を事前に定めておくことである。
特に大規模なプロジェクトでは、多数のステークホルダーが存在するため、それぞれの主要なステークホルダーがプロジェクトに確実に関与できるよう、内容について十分な事前調整を行うことが重要である。
5） 複数プロジェクトの統括管理
複数のプロジェクトが相互に関連する際に、一方のＰＪＭＯが他方のＰＪＭＯに対して要件内容や発生問題について適切に連携することが非常に重要である。連携が十分に行われないままプロジェクトを進めると、サービス・業務を部分的にしか提供できず利用者の利便性を損ねたり、目的としていたサービス・業務自体を開始することができなくなったりするなど、各プロジェクトの目的・目標の達成に対して重大な影響を与えることがある。
このようなときは、複数のプロジェクトが効果的に連携・調整を行えるよう、各プロジェクトを統括管理する仕組みを導入することができる。連携・調整を行う際は、主となるプロジェクトのプロジェクト推進管理者が、プロジェクト間調整の役割を担う。
なお、統括管理とは、主たる目的を達成するために、複数のプロジェクトに発生する変更事項を整合的に管理するものである。統括管理の目的として、次の事項が挙げられる。
・上位計画と各プロジェクトの目的・目標を整理し、プロジェクト間で目的・目標が阻害し合わないようにする。
・プロジェクト間で互いに影響する成果物やスケジュールを共有し、プロジェクトの実施に悪影響を与えないようにする。
・複数プロジェクトに影響を及ぼす可能性のある課題及びリスクを調整し、対応策の漏れを防ぐ。
（7）「複数のプロジェクトを統括して管理することにより、単独でプロジェクトを管理するよりも得られる効果が高いと判断したとき」
「複数のプロジェクトを統括して管理することにより、単独でプロジェクトを管理するよりも得られる効果が高いと判断したとき」とは、例えば、次のような場合を指す。
・今までにない新たな制度の導入等、特定のプロジェクトが実現するサービス・業務内容、整備するシステム内容が、多数のプロジェクトに直接的又は間接的な影響を与える場合。
・サービス利用者の視点から既存の業務を横断的に改革することが求められる場合等、複数のプロジェクトが相互に密接に関連し、個々に調整を行うよりも統合的に管理したほうが効率的な場合。
プロジェクトの開始時又はプロジェクトの実施中に上記の事項が発生したときは、ＰＭＯと相談し、複数プロジェクトの統括管理を検討する。
なお、府省共通プロジェクトや府省重点プロジェクトが対象である場合は、中心的役割を果たすプロジェクトの認定に当たり、内閣官房が関与するものとする。
（8）「統括管理するＰＪＭＯが調整を実効的に行えるよう、情報共有方法や合意形成方法等について関係者間で事前に申し合わせておくものとする」
「調整を実効的に行えるよう、関係者間で事前に申し合わせておく」とは、調整に必要な会議等の召集や、プロジェクト間の情報共有に必要な作業の分担や役割を取り決めておくことを指す。
異なる府省のプロジェクトが統括管理対象に含まれる場合は、特に調整が複雑になるため、対象となるＰＪＭＯ及びＰＭＯに対して、統括管理するＰＪＭＯが事前に申し合わせを行い、統括管理の体制、ステークホルダー管理、コミュニケーション管理、課題管理、情報共有方法や合意形成方法等のルールと役割を明確にし、ドキュメント化することが必要である。
また、事前に決定したルールと役割については、プロジェクトの進行状況や課題発生状況等に合わせて、臨機応変にルールや役割を見直していくことも必要になる。そのために、ルールと役割自体の変更方法についてもあらかじめ定めておくことが重要である。
6） サブプロジェクトの導入
（9）「プロジェクトの管理、運営を効率的に行うために、ＰＪＭＯはプロジェクト内の活動のまとまりを単位として分割し、それぞれをサブプロジェクトとして扱うことができる」
プロジェクトは、関係者の範囲やサービス・業務の規模等が大きくなるに連れて、管理は複雑になり困難になる。
「管理、運営を効率的に行う」とは、プロジェクトの特定範囲をサブプロジェクト単位で階層化することによって、ＰＪＭＯを構成する各担当者がそれぞれの役割に応じて管理しやすくすることを指す。一般的に、サブプロジェクトの単位は調達単位を基準とすることが多い。
サブプロジェクトの組成においては、次の点に留意する。
・各サブプロジェクトの計画や状況等が他のサブプロジェクトを含めてＰＪＭＯ全体へ十分に連携・共有できる体制とする。
・サブプロジェクトを管理するために必要となる要員と稼働量を確保し、サブプロジェクトの計画策定・推進・監視が充分に行えるようにする。
・特定のサブプロジェクトでの成果物が他のサブプロジェクトに引き継がれるなど成果物の関係性に留意し、各サブプロジェクトでの主要成果物をまとめた全体スケジュールを作成することで、各成果物の完成時期が整合していることを確認する。
（10）「サブプロジェクトを導入した際は、プロジェクト計画書を詳細化し、各サブプロジェクトの対象範囲や実施期間等を整理する」
「プロジェクト計画書を詳細化」とは、各サブプロジェクトの対象範囲、実施期間、予算、目標、体制、実施計画、他のサブプロジェクトとの関係等について整理を行い、プロジェクト計画書の記載を詳細化することである。
なお、プロジェクト計画書を詳細化する方法としては、プロジェクト計画書の本紙に追加記載を加える形でも、プロジェクト計画書の別紙としてサブプロジェクトごとに「サブプロジェクト計画書」を作成する形でも、いずれでも構わない。プロジェクト管理要領についても同様である。
２. プロジェクト計画の策定
プロジェクト推進責任者は、プロジェクトを計画的に遂行するため、プロジェクトの実行に先立ち、プロジェクト計画書及びプロジェクト管理要領を作成するものとする。 プロジェクト計画書は、プロジェクトのライフサイクルを通じて達成すべき成果を明確にし、各工程における意思決定や関係者との合意における指針として参照することにより、プロジェクト本来の目的に対して最大の成果を発揮することを目指す。 |
ＰＪＭＯは、政策目的やプロジェクトの目標の達成に向けてプロジェクトを計画的に遂行することが求められる。そのため、プロジェクトの実行に先立ち、その政策目的やプロジェクトの目標、範囲、体制、全体スケジュール等をとりまとめたプロジェクト計画書及びプロジェクトを管理するためのプロジェクト管理要領を作成する。
プロジェクト計画書等は、作業の特性や期間の違い等に応じたものとするとともに、プロジェクトの進行等に合わせて段階的に詳細化し、適時に内容の改定を行う。
プロジェクト計画書等を作成する目的を次に示す。
・政策目的やプロジェクトの目標、規模概要、予算概要、体制等を明文としてまとめ、主要なステークホルダー間で、実施するプロジェクトの内容に関して共通理解を形成する。
・プロジェクトに課せられた政策目的やプロジェクトの目標を確実に達成するための管理方法や意思決定方法に関する基本的な指針とする。
・プロジェクトの遂行過程で問題が発生した際に、問題への対応方法を主要なステークホルダー間で検討し、決定する際の拠り所とする。
1） プロジェクト計画書の記載内容
プロジェクト計画書には、少なくとも次のアからクまでに掲げる事項について記載するものとし、プロジェクトの進捗に合わせ、その内容を具体化・詳細化していくものとする (1)。 ア 政策目的 業務の実施によって目指す政策上の目的・背景等について記載する (2) 。 イ 対象業務範囲及びサービス・業務企画の方向性等 上記アで記載した政策目的を達成するためにプロジェクトの対象となるべき事業のサービス・業務の内容について記載する。 また、サービス・業務企画の方向性、課題、効果等について構想段階のものを記載する。なお、「第４章 サービス・業務企画」を実施した後は、その結果をこの項目の記載内容に反映するものとする。 ウ 対象とする情報システム サービス・業務に用いる情報システムの名称、主な機能及びサービス・業務での利用方法について記載する。 エ 目標及びモニタリング プロジェクトを推進し、 新しいサービス・業務を実現することで達成する目標を、具体的な指標及びその達成目標年度等で記載する (3) 。 また、 プロジェクトの目標が達成されているかを判断するために実施する継続的モニタリングの方法について記載する (4) 。 プロジェクトの実施状況を判断するモニタリングの対象は、「2)ウ 工程管理」、「2)エ 指標管理」及び「2)ク 品質管理」に記載した項目とする。 オ 前提条件・制約条件等 プロジェクトを実施する上でＰＪＭＯ及び関係者が理解すべき前提条件、制約条件、リスク等の事項があれば記載する。 カ 実施計画 当該情報システムのライフサイクルを通して必要となる作業内容・スケジュール・調達計画の概要等について記載する。 法令改正を伴うときは、有識者会議における議論日程について記載する等、業務面に影響を与える全ての取組について記載すること (5) 。 キ 予算 業務を実施するために必要となる全ての経費項目を洗い出し、その金額を見積り、必要となる予算及び要求年度等を記載する。経費項目は「別紙２ 情報システムの経費区分」に基づき区分等して記載する。 ク 体制 ＰＪＭＯを含むプロジェクトを推進するための体制、役割等について「１．3) 体制準備」で把握した内容を基に記載する。 なお、プロジェクトの所管組織を変更するときは、変更後の体制や役割等を明確化するとともに、変更後の所管組織に対してプロジェクトを推進するための必要事項を全て引き継ぐものとする (6) 。 |
プロジェクトの成功に向けて、ＰＪＭＯのみならず、業務実施部門の担当者、情報システムの開発・運用に携わる者、工程レビューの関係者、ＰＭＯ等、全ての関係者がプロジェクトの遂行に関して理解すべき事項を把握し、共通認識を持って活動することが重要である。
このため、ＰＪＭＯは、プロジェクトが目指す政策目的やサービス・業務企画の内容、期間や体制等、ステークホルダーがプロジェクトに関与する上で理解すべき基本的な内容を整理したプロジェクト計画書を作成し、プロジェクト遂行上の指針として全ての関係者に共有する。
２. 解説（1）「プロジェクトの進捗に合わせ、その内容を具体化・詳細化していくものとする」
「プロジェクトの進捗に合わせ、その内容を具体化・詳細化していく」とは、当初計画段階でＰＪＭＯがプロジェクト計画書の全ての内容を具体化・詳細化できないことが多いため、各工程を実施して入手した詳細な情報をもとに、プロジェクト計画書に対して、段階的に内容を追記し詳細化することである。（「３．プロジェクト計画書等の段階的な改定」参照）
なお、プロジェクト計画書の作成に当たっては、ＰＭＯや府省内外のＣＩＯ補佐官、外部組織の有識者や専門的な知見を持つ職員の支援や助言を受けることが望ましい。
ア 政策目的
プロジェクトにより構築・運営されるサービス・業務の内容及び、それらがもたらすべき成果や達成すべき目標は、その根拠となる政策上の目的・目標に基づくものである必要がある。
このため、プロジェクト計画書にプロジェクト活動の前提となる、政策上の目的・背景等を詳細に記載する。
（2）「業務の実施によって目指す政策上の目的・背景等について記載する」
「政策上の目的・背景等について記載する」とは、プロジェクトの対象範囲とするサービス・業務を行う根拠となる政策の目的・目標だけでなく、それらが設定される要因となった社会経済環境に基づく要請や国の財政の健全化の要請等の背景を併せて記載することである。
背景を記載することで、政策上の真の目的を正しく理解し、プロジェクト方針の正しい理解を助ける。
政策目的やプロジェクトの目標やその背景については、サービス・業務を企画・運営する責任を担う立場から制度所管部門及び業務実施部門が中心となって内容の取りまとめを行い、プロジェクト計画書の他の記載事項との整合性の確認を行う必要がある。
イ 対象業務範囲及びサービス・業務企画の方向性等
対象業務範囲では、「ア 政策目的」で定義した政策目的やプロジェクトの目標を実現するためのサービス・業務の中で当該プロジェクトが果たす役割を明確にするために、当該プロジェクトの対象範囲を定義する。この定義により、サービス・業務企画の範囲、予算取得範囲、スケジュール等の前提が定まる。
対象範囲として具体的に記載する事項は、利用者へ提供する主要なサービスや実施する主要な業務範囲等である。
| 新たな制度に基づく業務の対象範囲を定義する際の留意点
新たな制度に基づく業務は、サービス・業務企画を経ないと具体化・詳細化することが困難であるため、構想段階で検討された内容を基に主要業務を定義し、その名称と内容を可能な限り詳細に整理してまとめる。 |
デジタル・ガバメント推進方針（平成29年5月30日高度情報通信ネットワーク社会推進戦略本部・官民データ活用推進戦略会議決定）では、デジタル技術を活用した利用者中心の行政サービス改革として、サービスデザイン思考に基づく業務改革の推進とデジタル技術に対応した情報提供の在り方の見直し行うことを掲げている。
サービス・業務企画の方向性等では、ＰＪＭＯはこの方針を十分に理解した上で、利用者側の立場を考慮した調査・分析を行い、利用者のニーズを把握した上でサービス・業務企画の方向性等を定義する。
プロジェクト計画書を新規に作成する段階では、その時点で把握しているサービス・業務の概要や全体的な傾向に基づいて、サービス・業務企画の方向性を記載する。その後に標準ガイドライン「第３編第４章 サービス・業務企画」を実施する中でサービス・業務企画の具体内容を詳細化し、その内容を基にプロジェクト計画書を更新する。
ウ 対象とする情報システム
対象とする情報システムとして具体的に記載する事項は、情報システムの利用範囲と主要機能、プロジェクトの主要成果物等である。
１つのプロジェクトの中で複数の情報システムを整備する場合は、それぞれの情報システム単位で対象範囲を記載する。
既存情報システムを更改する場合の対象範囲を定義する際の留意点 既存の業務及び情報システムの機能を基に、追加・変更・削除が明確になるよう情報をまとめることにより、対象範囲を特定し無駄な作業の発生を防ぐ。その際、既存情報システムを運用する中で整理された課題やリスク等の情報を参考にする. |
サブプロジェクトの対象範囲を定義する際の留意点 属するプロジェクトとサブプロジェクトの関係を理解した上でそれぞれの対象範囲が明確に区別できるよう整理する。 |
エ 目標及びモニタリング
プロジェクトが達成すべき目標については、現状においても達成可能な目標を安易に設定するのではなく、利用者視点から真に求められる姿を定義した上で、そのために必要となるサービス・業務改革やシステム整備を行うことで達成できる目標を設定することが重要である。
（3）「新しいサービス・業務を実現することで達成する目標を、具体的な指標及びその達成目標年度等で記載する」
「目標」とは、プロジェクトが目指す姿を簡潔な文章によって端的に表現したものである。
「指標」とは、設定した目標の達成程度を定量的に評価できるように定めたものであり、サービス・業務効果に関する指標と情報システム効果に関する指標の２種類が存在する。サービス・業務効果に関する指標については、行政内部の視点のみではなく、利用者がサービスを通じて享受する価値や効用を優先することに留意する。また、情報システム効果に関する指標は、サービス・業務効果に関する指標を踏まえ、情報システムが果たすべき効果を整理し設定する。
なお、目標達成の程度を定量的に評価し難い指標（定性的な目標等）については、政策目的やプロジェクトの目標との因果関係を分析した上で、事後に測定可能な定量的指標に代替することが望ましい。
「エ 目標及びモニタリング」で定義したプロジェクト全体の目標は、定期的に達成状況を確認し、目標達成を阻害する事象を把握・適宜対応することによって、プロジェクト成功に向けた阻害要因の排除が可能となる。
このため、プロジェクトの開始から完了まで、対象とする管理項目から提供される情報を基に、目標の達成状況を継続的にモニタリングする。
なお、モニタリングの前提として、「2) ウ 工程管理」、「2)エ 指標管理」、「2)ク 品質管理」で定める管理項目が存在する。これらの上位に「エ 目標及びモニタリング」が位置する関係となっているため、それぞれで定めた定量・定性目標値が変更された場合、関連する目標値にも変更が発生する可能性があることに留意すること。
（4）「プロジェクトの目標が達成されているかを判断するために実施する継続的モニタリングの方法について記載する」
「継続的モニタリングの方法」とは、ＰＪＭＯが「エ 目標及びモニタリング」で定義したプロジェクト目標の達成状況の実態を把握するために、「2)エ 指標管理」で定義した指標の達成程度を評価する手段と、評価を行う時期や頻度を明らかにすることである。例えば、少なくとも中長期計画を見直す時期で省内の全てのＰＪＭＯのモニタリングを実施する等の方法がある。
なお、評価した結果、目標を十分に達成できていないと判断したときは、「2)カ 課題管理」で定義する手順に従って対応方法を検討する。なお、効果的な対応方法が存在せずに、プロジェクトの推進において深刻な問題があると判断した場合は、標準ガイドライン「第２編第９章 プロジェクトの検証」で定める手順に基づき、プロジェクトの検証を行う。
オ 前提条件・制約条件等
プロジェクトを推進する上で、制約条件や留意事項があれば記載する。
カ 実施計画
情報システムの整備・構築には、プロジェクト開始から完了までの期間内に、多数の作業が存在する。ＰＪＭＯは、これら作業が効率的な順序になるように考慮した上で、構築した体制に含まれる担当者に漏れなく割り当て、妥当な期間内で完成させる必要がある。
このため、プロジェクトの実行可能性を担保するために、作業内容、スケジュール（作業量の概算見積り、担当者・担当部門、日程等）、調達計画（調達の範囲と内容、実施時期等）の概要を検討し、実施計画として記載し、全ての関係者間で共有する。
プロジェクトの実施期間は、当該プロジェクトが整備する情報システムのライフサイクル期間とすることを基本とする。なお、制度や業務等の中で数年単位のサイクルがある場合は、プロジェクトの期間をそのサイクルに合わせて設定することもできる（標準ガイドライン解説書「第３編第１章２．プロジェクトの全体像と流れ」参照）。
プロジェクトの実施期間の設定に当たっては、新たなサービス・業務の開始時期を先に設定するのではなく、予算要求、サービス・業務企画、要件定義、調達、設計・開発等の工程を確実に実行するための十分な時間を確保した上でサービス開始時期を定めることが必要である。このため、「イ 対象業務範囲及びサービス・業務企画の方向性等」の内容から、それらを実施するために必要となる作業と工程を特定し、各工程に必要な期間を積み上げたものをプロジェクトの実施期間として定義する。
なお、プロジェクト計画書を新規に作成する段階では、例えば月単位等の粒度で主要な工程を積み上げて実施期間を算出することが標準的である。そして、プロジェクトの進捗に応じて、各工程で必要となる作業を精査しながら内容を見直すことが重要である。
（5）「法令改正を伴うときは、有識者会議における議論日程について記載する等、業務面に影響を与える全ての取組について記載すること」
「業務面に影響を与える全ての取組」とは、ＰＪＭＯが実施計画を記載するために作業内容を抽出する際、情報システムの整備に関する作業のみならず、新たなサービス・業務を提供するために必要となる作業も、抜け漏れなく記載することである。
キ 予算
当該プロジェクトのライフサイクルコストに関する金額とその妥当性を判断することができる根拠を記載する。
プロジェクト計画書を新規に作成する段階では、ライフサイクル全体に係る概算を明らかにし、プロジェクトの進行に応じて、標準ガイドライン「別紙２情報システムの経費区分」に基づき予算を具体的に明らかにする。
予算要求が承認された段階で、確定した予算額をプロジェクト計画書に記載するとともに、調達手続を経て契約額が決定した際には執行額もプロジェクト計画書へ記載し、予算の計画と実績との対比ができるようにする。また、予算に比べて実績が大幅にかい離している場合は、その原因を記載することも重要である。
ク 体制
プロジェクトを円滑に遂行するためには、関係者が目的意識を共有し、最終目標に向けて相互の役割と責任を理解することが不可欠である。
このため、統括的な責任を担うＰＪＭＯを中心とした推進体制と、関係機関に求める役割をプロジェクト計画書に記載する。
具体的には、体制表及び業務分担表として整理を行う。
体制表には、ＰＪＭＯ内部における各部門や各担当者の役割を明示するとともに、密接に関係する他のＰＪＭＯ、ＩＴガバナンスの観点からの関係組織、システム構築や運用に関係する事業者等、プロジェクトの日常的な活動への直接的な関係者を記載する。次に、体制例等を示す。
図2-2 体制例
上記役割の定義については、標準ガイドライン「第２編第２章２．府省体制」を参照すること。
業務分担表については、体制表で示した個々の関係者の役割、承認・意思決定の方法、当該役割を実行する責任及び当該機関への支援の提供について記載する。
（6）「なお、プロジェクトの所管組織を変更するときは、変更後の体制や役割等を明確化するとともに、変更後の所管組織に対してプロジェクトを推進するための必要事項を全て引き継ぐものとする」
「プロジェクトの所管組織を変更するとき」とは、例えば情報システムを設計・開発する部分までを担当していた所管組織が、情報システムの運用段階になって変更になる場合等のことを指している。このような場合においても、主要なステークホルダーや各種事業者等との折衝経緯や合意形成内容等を含めて、変更後の所管組織に確実に引継ぎを行うことが重要である。
2） プロジェクト管理要領の記載内容
プロジェクト管理要領には、プロジェクトを遂行する際に、ＰＪＭＯがプロジェクトを管理する手法、手順、遵守事項等を明確に記載するものとし、少なくとも次のアからケまでに掲げる事項について記載するものとする。 ア ステークホルダー管理 「１．3) 体制準備」及び「1)キ 体制」の内容を参考に、プロジェクトに係る主要なステークホルダーを定義し、プロジェクトへの関わり方について記載する (1)。 イ コミュニケーション管理 ステークホルダーとの情報共有方法や合意形成方法等として、ステークホルダー間の連絡調整に関する方法、会議体の種類や開催頻度、合意形成手順、議事録管理等の具体的内容について記載する。 ウ 工程管理 「1)ク 実施計画」に定めた作業内容・スケジュールを所定の時期に完了させるために、作業管理方法、進捗状況の報告先、内容、頻度等について記載する。なお、 府省重点プロジェクトを実施するときは、ＰＭＯと調整の上、ＰＭＯが求める事項を回答・報告すべき旨を記載するものとする (2) （「第２編第４章２．府省重点プロジェクト」参照）。 エ 指標管理 「1)カ 目標」に定めたプロジェクトの目標の達成状況を適切に管理するために把握すべき指標項目、実績値の取得目的・取得手法・取得頻度、実績値の変動による対応策等について記載する。なお、本項目で定めた指標は、サービス、業務、情報システムの改善検討にも活用する (3)。 オ リスク管理 プロジェクトの遂行を阻害する可能性のあるリスクについて、リスク顕在時の報告先、報告内容、リスクの管理手法等を記載する。なお、情報セキュリティリスクについては、自府省の情報セキュリティポリシーを参照して記載内容を検討するものとする。 カ 課題管理 プロジェクトの遂行上発生する解決すべき課題について、その発生時の報告先、報告内容、課題の管理手法等を記載する。 キ 変更管理 プロジェクトの進捗により発生する変更について、管理対象、変更手順、管理手法等を記載する。 ク 品質管理 プロジェクトの各工程で実施する作業の品質を管理する手法及び改善する手法について記載する (4) 。 ケ 記録管理 プロジェクト実施中に作成する各種文書の保存期間について記載する。 |
プロジェクトを確実に遂行するためには、プロジェクトに係る関係者がプロジェクト計画書で定義された各項目を遵守するとともに、ＰＪＭＯは行うべき管理活動を明確にする必要がある。
このため、具体的にＰＪＭＯが管理すべき対象や管理手法等をプロジェクト管理要領として定める。
なお、プロジェクト管理要領は、管理要領全体での整合性を確保しつつ、プロジェクト計画書の各工程における具体化・詳細化の内容を反映させる必要がある。
また、プロジェクトの特性や工程により、管理すべき対象や適切な管理手法が変わることに留意する。
２. 解説ア ステークホルダー管理
プロジェクトには「1)キ 体制」において定義したプロジェクト推進体制に含まれる者以外に、当該プロジェクトのサービス・業務から影響を受ける者又は影響を与える者が存在する。これらステークホルダーのうち、特にプロジェクトへの影響力が大きいステークホルダーのプロジェクトへの関わり方を誤ると、プロジェクトの成否を分ける結果を招きかねない。
このため、ステークホルダー管理では、プロジェクトへのステークホルダーの関与を効果的に引き出すために、主要なステークホルダーを特定し、プロジェクトへの期待度合いや影響等を分析し、プロジェクトへの関わり方を定義する。
本ガイドラインで基準とするステークホルダーの管理対象を、図2-3に示す。
図2-3 ステークホルダーの管理対象範囲
（1）「プロジェクトに係る主要なステークホルダーを定義し、プロジェクトへの関わり方について記載する」
「主要なステークホルダー」とは、プロジェクトに対して直接的又は間接的に影響を受ける外部関係者や内部関係者を含めたステークホルダー全体の中で、ＰＪＭＯが会議出席やヒアリングを依頼するなど直接的なやりとりを行う関係者を指す。プロジェクトの推進に際しては、これらの主要なステークホルダーの意見が反映されるように、情報共有方法や合意形成方法を定めることが重要である。
原則として、プロジェクトに関わる制度所管部門や業務実施部門の職員等はＰＪＭＯ内の体制に組み入れることが望ましいが、ＰＪＭＯを構成する職員が日常的に連携しながら活動を行えるように、ＰＪＭＯの規模を適切に保つことも重要である。この観点から、プロジェクトを推進する中で日常的に密接なコミュニケーションをとる必要がない部門の職員については、ＰＪＭＯ内の体制ではなく、ステークホルダーとして定義することが一般的である。
| 小規模プロジェクトや実証実験のステークホルダー管理
短期間でサービス・業務を提供するプロジェクトや、目標に対する実現方法の検討範囲が広いプロジェクトは、検討や意思決定を効率よく進める必要があるため、ＰＪＭＯと主要なステークホルダーが定例的な会議の場だけでなく、日常的な業務として直接関わりあえるような積極的な関わり方を検討する。 |
イ コミュニケーション管理
プロジェクト活動中は、日々、様々な種類の情報が発生する。ＰＪＭＯは主要なステークホルダーに対し、これらの情報を選択し適時かつ適切な手段で情報交換（コミュニケーション）を行い、プロジェクトに関する認識や課題等の共有を図る必要がある。
このため、「ア ステークホルダー管理」の情報を基に、コミュニケーションの方法（会議等）及び周期・時期、議事録の管理等、具体的なコミュニケーションの計画について記載する。
特に、関係者が多い場合、合意形成の手続は複雑となるが、それらのステークホルダーが当該プロジェクトの提供するサービス・業務に対して求める事項やその背景を的確に把握できるようにコミュニケーション管理することに留意する。
ウ 工程管理
ＰＪＭＯは、「1)ク 実施計画」に定めた作業内容・スケジュールを予定した工数で所定の時期に完了させ、プロジェクトを計画どおりに進行させる必要がある。
このため、ＰＪＭＯは、プロジェクトの進捗状況を整理し、プロジェクト関係者間で共有し適正に管理する必要がある。具体的には、管理対象の情報を分析し、進行状況や職員及び事業者の投入工数が必要十分かを常に把握し、当初計画と比較して許容範囲を超えていると判断した場合は、原因の明確化及び分析を行い、その結果に基づき適切に対応する。この際、市販のプロジェクト管理ツールを活用することも有効である。
なお、移行判定及び稼働判定の実施時期は、判定のために必要な情報の提供期限や、後続の作業に影響を与えるため、留意すること。
（2）「府省重点プロジェクトを実施するときは、ＰＭＯと調整の上、ＰＭＯが求める事項を回答・報告すべき旨を記載するものとする」
「ＰＭＯが求める事項」とは、ＰＭＯが当該府省重点プロジェクトの進捗状況を把握するために追加すべき管理項目のことである。一般的には、実施計画に対する進捗状況を求めることが多いが、プロジェクトの特性に応じて、システムの利用状況、利用者要望の発生状況、課題発生状況等を管理項目として求めることがある。
エ 指標管理
「1)カ 目標」で定義したプロジェクト全体の目標及び目標達成状態を測定するための指標は、プロジェクトを構成する各活動において把握した実績値と比較し、プロジェクト活動期間中、定期的かつ定量的に管理する必要がある。
このため、ＰＪＭＯは、指標を構成する項目、その実績値の取得目的、取得手法、取得頻度や、実績値が基準値から外れた場合の対応策等を定義し管理する。ここで管理する指標には、業務効果に関する指標及び情報システム効果に関する指標だけでなく、サービス・業務改革の視点及びサービス・業務改革を実現するための情報システムの性能の視点からの指標を設定し管理する必要があるため、標準ガイドライン「第３編第４章 サービス・業務企画」も参照する。
なお、プロジェクト遂行中は、指標の目標水準と現状の水準との差異を客観的に把握し、水準の見直しや指標の追加・変更を検討するなど、常時適切な指標を管理することが肝要である。
（3）「本項目で定めた指標は、サービス、業務、情報システムの改善検討にも活用する」
「サービス、業務、情報システムの改善検討」は、ＰＪＭＯ（情報システム部門）が、サービス、業務、情報システムの改善を検討するために、稼働状況や提供するサービス、機能の利用状況を、指標を用いて評価することである。
指標管理は情報システムの整備中に注視しがちであるが、運用開始後に全ての関係者がサービス・業務の質をより高めるための活動を継続的に行うことが重要である。
オ リスク管理
本ガイドラインにおけるリスクは、プロジェクトの目標達成を阻害する要因を生み出す可能性がある事態を指す。リスクを事前に想定し、対応策を検討しておくことにより、プロジェクトへ与える影響を減らすことが可能となる。
このため、ＰＪＭＯはリスクについて、その顕在化前から発生の要因分析と影響、確率を評価するとともに、予防策や顕在化した際の原因追及、プロジェクトへの影響の把握、対応策の実施及び結果を評価するため、リスクの管理手法等を記載する。
リスクには、プロジェクトの計画段階で判断可能なもの、遂行中に新たに発生するおそれがあることが判明又は顕在化するもの、レビューにて判明するものがある。ＰＪＭＯはこれらを把握し、分析・評価結果を踏まえて適切な対応を指示する必要がある。
カ 課題管理
プロジェクトを遂行する過程で発生した多種多様な問題の根本原因を解消せずに対処すると、問題の再発や、別の問題が新たに発生するなど、プロジェクトの円滑な遂行を阻害する要因となる。
このため、ＰＪＭＯはプロジェクトを遂行する過程や目的達成を阻害する問題の発生状況を適時に把握するとともに、問題の解決方針等を定めて解決すべき課題として整理し、優先順位付け、対策の検討、実施等について課題管理として記載する。
具体的には、ＰＪＭＯは、上記事項をその都度統括して課題管理簿にまとめ、適切に管理するとともに、プロジェクト関係者間で常に共有する。特に、未解決な課題については、継続的に状況を把握し適時に対応状況の報告を得る。
キ 変更管理
プロジェクトの進行に伴い、プロジェクトの管理対象とする情報にも変更が発生することがある。個々の変更によるサービス・業務への影響を把握せずにプロジェクトを進めると、提供するサービス・業務の提供時期の遅延や質の低下を招くおそれがある。
このため、ＰＪＭＯは、各工程の成果物、プロジェクト計画書及びプロジェクト管理要領に係る全ての変更について、定められた手続に従って管理する。
変更管理の活動には、変更の手続、変更による影響の評価、変更要求に関する優先順位付けと承認、緊急時の変更手続、変更結果の評価と報告及び変更完了について、適切に文書化することが含まれる。変更の内容によっては、事業者との契約内容の変更が必要となることもある。その際には、適切に判断し、定められた契約変更手続等を行う。
なお、プロジェクト計画書又はプロジェクト管理要領の変更については、「３．プロジェクト計画書等の段階的な改定」の内容を踏まえる。
ク 品質管理
プロジェクト全体の目標を達成するためには、サービス・業務に関わる利用者・関係者の満足度を向上させる観点において、プロジェクト実施期間を通じて、品質管理を継続的に行う必要がある。そのため、プロジェクトの各種活動に合わせて、満たすべき品質基準を設定し、品質を管理する活動を定義する。
なお、プロジェクトの成功に向け、移行判定及び稼働判定は、特に重要な判断となるため、これらの判定基準の設定には留意すること。
（4）「プロジェクトの各工程で実施する作業の品質を管理する手法及び改善する手法について記載する」
「作業の品質を管理する手法」とは、ＰＪＭＯが各工程で実施している作業の品質を定量的に管理するために定めた取り決めのことである。これは、情報システムを構築する工程のみならず、運用保守工程も含む各工程に応じて個々に定め、管理対象、品質基準、確認サイクル等を明確にする必要がある。
ケ 記録管理
プロジェクト遂行中に作成する各種文書の保存期間は、原則として各府省における文書管理規則の文書保存期間に準拠することになる。しかし、実務上では、プロジェクト開始当時の経緯や根拠資料を確認することが必要になることもある。このため、文書管理規則の文書保存期間がプロジェクト期間より短い場合は、プロジェクトに関する重要な文書の保存期間を延長する等、文書の保存期間について適切に定めることが重要である。
なお、随意契約における交渉経緯や、要件変更における背景がわかる資料、意思決定の際に使用した資料等も記録管理の対象となることに留意する。
3） 作成時の留意点
プロジェクトの内容等に応じて、次の点に留意するものとする。 ア 府省重点プロジェクトの場合 プロジェクト計画書の作成、変更について、府省ＣＩＯ又は府省副ＣＩＯが関与するものとする。 イ 他のＰＪＭＯが実施するプロジェクトと相互に密接に関係する場合 プロジェクトの数、複雑さ、難易度及び管理労力を踏まえ、ＰＭＯと相談しながら、関係するＰＪＭＯ間で協議の後、これらプロジェクト間で管理すべき必要な措置をプロジェクト計画書又はプロジェクト管理要領に盛り込むものとする。 ウ サブプロジェクトを実施する場合 サブプロジェクトの管理作業を明確に定義するために、サブプロジェクト計画書及びサブプロジェクト管理要領を作成することが望ましい。なお、サブプロジェクト計画書及びサブプロジェクト管理要領は、プロジェクト計画書及びプロジェクト管理要領の内容を前提とし、差異やサブプロジェクト固有の詳細化された内容を記載する。 エ プロジェクト目標に対する具体的な実現方法が定まっていない場合 開発規模・期間を限定した試行版を提供し、効果検証を経て実運用に向けたプロジェクト計画を再度立案する等の、プロジェクトを段階的に進めていく手法（実証実験）を検討するものとする。 |
ＰＪＭＯが管理するプロジェクトは、規模、関係者数、背景等の様々な要因から一様とはならない（プロジェクトに差異を生む要因は、標準ガイドライン解説書「第３編第１章２．プロジェクトの全体像と流れ」の解説を参照）。本項目では、特性に応じた代表的なプロジェクトのプロジェクト計画書等作成上の留意事項を示す。
２. 解説
ア 府省重点プロジェクトの場合
府省重点プロジェクトは、標準ガイドライン「第２編第４章１．2) 府省重点プロジェクトの指定」に示された要件のいずれかに該当するプロジェクトである。また、府省重点プロジェクトにおいては、ＰＭＯは、標準ガイドライン「第２編第４章１．2) 府省重点プロジェクトの指定」に示されるとおり、ＩＴガバナンスとしてプロジェクトに対して適切な関与を行う必要がある。
このため、ＰＪＭＯは、ＰＭＯが適切な関与を行えるよう、プロジェクト計画書の作成、変更に際しては次の点に留意する。
なお、府省重点プロジェクトにおいては、府省ＣＩＯ又は府省副ＣＩＯがプロジェクト計画書の作成に関与する。
・ＰＭＯの関与に関する方法、手順等をプロジェクト管理要領にて定める。具体的には、ステークホルダー管理にてＰＭＯのプロジェクトへの係わり方を明記するとともに、リスク管理、課題管理、変更管理にて定義する各々の活動に対するＰＭＯの関与する基準及びその手順を定義し、コミュニケーション管理にてＰＭＯへの連絡・報告に関する事項を記載する。記載に当たっては、その内容についてＰＭＯに適宜相談すること。
・プロジェクトにおけるＰＭＯの関与する時期を明確にするため、プロジェクト管理要領の工程管理にて、ＰＭＯが求める事項を回答・報告すべき旨を記載するとともに、工程レビュー（「４．2) プロジェクトの工程レビュー」参照）も含め、プロジェクト計画書の実施計画に反映する。
・プロジェクト計画書等の内容についてＰＭＯに共有し、ＰＭＯから指摘、助言又は指導を受けた際は、必要な対策を講ずる。
イ 他のＰＪＭＯが実施するプロジェクトと相互に密接に関係する場合
ＰＪＭＯが管理するプロジェクトは、他のプロジェクトと相互に密接に関係する場合がある。例えば、他の情報システムと情報を連携する場合等がある。
このような場合において、プロジェクトの計画段階で要件やスケジュール等を他のＰＪＭＯと共有・調整を行わない場合、テスト等での手戻りやサービス開始後の不具合等につながり、プロジェクトの目標達成に大きな影響を与えかねない。
このため、ＰＪＭＯは、プロジェクト計画時又は他のＰＪＭＯとの関係が判明し次第、次の点に留意する。
・プロジェクト管理要領のステークホルダー管理にて、他のＰＪＭＯの関わり方について定義するとともに、コミュニケーション管理にて、情報共有の手段、方法、時期等について定義する。
・プロジェクト計画書の実施計画にて、他のＰＪＭＯとの関係が必要になる時期を確認する。特に、テストや移行が発生する場合等、予算や人員等の確保の必要性について事前に調整することが重要である。
・統括管理が必要となる各プロジェクトにおいては、統括管理に関するルール等を、プロジェクト計画書等に記載する。
・複数の府省プロジェクトが相互に密接に関係するプロジェクトの場合、システム連動テストや各システムが連動した総合運用テスト等の実施計画策定は、中心的な役割を果たす府省のＰＪＭＯが、関係府省のＰＪＭＯと連携・調整して策定する。
ウ サブプロジェクトを実施する場合
ＰＪＭＯは、サブプロジェクトの計画においては、プロジェクト計画書及びプロジェクト管理要領で記述すべき事項のうち、プロジェクトの計画と同一となる事項については内容を踏襲するが、次に挙げる事項についてはサブプロジェクト固有の内容として詳細化・具体化を行う。
・対象範囲
・予算（サブプロジェクト追加分の計画と実績）
・目標（サブプロジェクト追加分の計画と実績）
・体制
・実施期間
・実施計画
エ プロジェクト目標に対する具体的な実現方法が定まっていない場合
利用者の価値最大化を前提としたサービス・業務の企画に際しては、効果の実現性やその度合いについてサービス提供を開始するまで不確定であることが多い。大幅なコストをかけて情報システムを構築しても、サービス開始後に効果が十分に得られないと、プロジェクト目標が達成できず大きな問題となる。
このような場合、試行版を用いて本サービス開始前に効果検証を行う実証実験の手法の採用を検討する。実証実験については、標準ガイドライン解説書「第３編第１章２．プロジェクトの全体像と流れ」の解説を参照すること。
実証実験を行う場合は、プロジェクト計画書等にて、検証における効果指標及びモニタリングに関する事項を明確にし、期待する効果が得られない場合の対処についても事前に検討しておくことが重要である。
4） プロジェクト計画書等の案の調整等
プロジェクト推進責任者はＰＪＭＯ各担当と調整し、プロジェクト計画書の案及びプロジェクト管理要領の案を、関係機関と調整の上、確定するものとする (1)。 特に、 外部の情報システムと連携するときは、外部の情報システムを担当するＰＪＭＯ等と適切に調整を行うものとする (2) 。 なお、特に府省重点プロジェクトを実施するときは、ＰＭＯとも調整を行うものとする。 |
プロジェクトの円滑な推進と所期の目標を達成するためには、プロジェクトを推進する部門のみならず、当該プロジェクトに関係がある関係機関の間で、プロジェクトの目的・目標や相互の影響等について共通理解をし、合意を形成することが重要である。
このため、プロジェクト計画書等の確定に先立ち、その内容について、関係機関との調整及び合意をし、プロジェクト計画書等の確定を行う。
２. 解説（1）「プロジェクト計画書の案及びプロジェクト管理要領の案を、関係機関と調整の上、確定するものとする」
「プロジェクト計画書の案及びプロジェクト管理要領の案」とは、ＰＪＭＯが新規に作成したプロジェクト計画書及びプロジェクト管理要領で、正式に発行する前のものをいう。
「関係機関と調整の上」とは、ＰＪＭＯが、プロジェクト計画書の体制及びプロジェクト管理要領のステークホルダー管理にて特定した主要なステークホルダーに対して、そのステークホルダーが関係するプロジェクト計画書等の事項について確認、調整し、合意することを指す。なお、整備する情報システムが、民間企業、地方公共団体、独立行政法人等の外部関係者にも関係する場合は、それらの機関とも調整を行う。
「確定する」とは、プロジェクト計画書等を正式版として発行し、以降に発生するプロジェクト計画書等の変更をプロジェクト管理要領の変更管理の対象として扱うことを指す。
ＰＪＭＯは、主要なステークホルダーがプロジェクトの初期から適切に関与し円滑なプロジェクト運営及びプロジェクト目標の確実な達成が行えるよう、プロジェクト計画書等を確定する前に主要なステークホルダーと調整・合意を行った後、プロジェクト計画書等を正式に発行する。
| 府省重点プロジェクトのプロジェクト計画書等の案の調整
プロジェクト計画書等の正式発行に先立ち、主要なステークホルダーとその内容についてプロジェクト推進会議で確認・調整するとともに、ＰＭＯと確認・調整し合意を得たのち、正式版として発行する。 なお、プロジェクトの実行は、府省ごとで個別に管理する。 |
（2）「外部の情報システムと連携するときは、外部の情報システムを担当するＰＪＭＯ等と適切に調整を行うものとする」
「ＰＪＭＯ等」とは、外部の情報システムを担当するＰＪＭＯのほかに、政府外組織（地方自治体等）が含まれることを指す。
5） プロジェクトの計画内容や実施状況等の公開
多数の外部関係者が存在するプロジェクトにおいては、 (1) プロジェクトの計画内容、調達予定等を含めた全体スケジュール、プロジェクトの進捗状況及び目標の達成状況について、関係者へ適時に情報を共有することに努めるものとする (2) 。なお、プロジェクト計画書自体を公開する形式でなくとも、プロジェクトの主要な状況が公開されていればよい。 また、 プロジェクトの進捗状況及び達成状況に応じてプロジェクト計画書を変更したときは、外部に公開している内容も適時に変更することが望ましい (3) 。 |
外部関係者や他府省への影響が大きいプロジェクトにおいては、利用者のニーズの齟齬や影響範囲の不備等の発覚遅れを防止するためにも、プロジェクトの計画を適時に公開することが有効である。また、「デジタル・ガバメント実行計画」（平成30年7月20日デジタル・ガバメント閣僚会議決定）において、利用者中心の行政サービス改革を達成するためにも、全ての関係者に気を配るよう配慮が求められている。
このため、多数の外部関係者が存在するプロジェクトにおいては、プロジェクトの方針、具体的内容、実現時期等についてあらかじめ情報を公開して、早期から合意形成を図ることが望ましい。
２. 解説（1）「多数の外部関係者が存在するプロジェクトにおいては、」
「外部関係者」には、国民、企業、地方公共団体等が存在し、「多数の外部関係者が存在するプロジェクト」とは、これら外部関係者に対する影響が広範囲にわたるプロジェクトを指す。
（2）「関係者へ適時に情報を共有することに努めるものとする」
「関係者へ適時に情報を共有する」とは、各府省のＷｅｂサイト等で広く一般に公開することや情報共有Ｗｅｂサイトを設け特定の関係者が閲覧できるようにすることを指す。他府省へ影響を与えるプロジェクトのときは、府省間で適時情報を開示する。
（3）「プロジェクトの進捗状況及び達成状況に応じてプロジェクト計画書を変更したときは、外部に公開している内容も適時に変更することが望ましい」
「進捗状況及び達成状況に応じてプロジェクト計画書を変更したとき」とは、プロジェクトの目標及び指標、サービス・業務企画内容の変更、利用者への提供時期等、プロジェクト計画書に対して利用者に影響を及ぼしうる変更を行った場合を指す。
これらの変更によって、外部関係者や内部関係者に対して様々な影響を発生させる可能性があるため、変更内容を速やかに公開することが望ましい。
３. プロジェクト計画書等の段階的な改定
プロジェクト計画書は、プロジェクト開始時に全ての内容について具体化・詳細化することは困難であるため、プロジェクト推進責任者はＰＪＭＯ各担当と調整し、次に掲げる時期を参考に、プロジェクト計画書の改定（プロジェクト管理要領の改定を含む。）を実施する(1)ものとする。なお、これらの時期以外に必要に応じて適宜改定することを妨げない (2)。 |
1） プロジェクトの構想段階
ＰＪＭＯは、プロジェクトの構想段階において、プロジェクト計画の概要を整理し、プロジェクト計画書の素案を作成する (3) ものとする。
2） 当初計画段階
ＰＪＭＯは、プロジェクト計画書の素案が決定されてから、サービス・業務企画終了時までに、政策目的やプロジェクトの目標に基づき設定した業務効果に関する指標及び情報システム効果に関する指標、プロジェクトを推進する体制と各々の役割・責任、全体のスケジュール等について具体化・詳細化し、プロジェクト計画書に反映する (4) ものとする。
3） 調達及び設計・開発開始前
ＰＪＭＯは、調達及び設計・開発を開始する前までに、サービス・業務企画及び要件定義を基にして、当初計画段階のプロジェクト計画書に詳細な内容を盛り込み、設計・開発段階前のプロジェクト計画書を具体化・詳細化する (5) ものとする。
4） 運用及び保守開始前
ＰＪＭＯは、運用及び保守を開始する前までに、運用開始後の評価指標等を具体化・詳細化し、プロジェクト計画書に反映する (6) ものとする。
5） サービス・業務の運営段階
ＰＪＭＯは、サービス・業務の運営段階において、政策目的やプロジェクトの目標の達成状況、運用段階で必要となった改善点、発生した課題とその課題への対応、実施された改修、業務の状況の評価、業務の改善状況・改善計画及び実行結果等について具体化・詳細化し、プロジェクト計画書に反映する (7) ものとする。
6） サブプロジェクトの組成時
ＰＪＭＯは、当該プロジェクトに属するサブプロジェクトを組成する際、その内容を具体化・詳細化し、プロジェクト計画書に反映するものとする (8) 。
なお、サブプロジェクトに関する記載については、プロジェクト計画書に追記する形でも、サブプロジェクト計画書として独立した構成とする形でも、いずれでも差し支えない。
7） 工程完了時
工程が完了した時点で、工程で実施した作業の結果と次工程の内容を具体化・詳細化し、プロジェクト計画書に反映するものとする。既に記載されている内容についても見直しを行い、変更を検討するものとする。
１. 趣旨プロジェクト計画書等の各項目は、初回の確定時点では、その時点で入手可能な情報から検討した内容が記載されているため、概略のみが記載されている項目が存在している。
このため、工程が完了する時期で、工程で実施した作業の結果をその時点の最新の情報として、記載内容を検討し具体化・詳細化を行うことにより、プロジェクトの初期においてプロジェクト計画書の作成に係るＰＪＭＯの作業負荷を軽減するとともに、プロジェクトの進行に応じたプロジェクト計画書の内容となることを達成する。また、ＰＪＭＯの交代等が発生したときに、当該プロジェクトの引継ぎ資料として活用できるようにする。
２. 解説（1）「プロジェクト計画書の改定（プロジェクト管理要領の改定を含む。）を実施する」
「プロジェクト計画書の改定」とは、「２．2)キ 変更管理」で定義した変更プロセスに従い、プロジェクト計画書の内容を変更する作業である。
初版となる当初計画段階において、具体化・詳細化できない項目については、概略又は想定による記述内容で差し支えない。
「1) プロジェクトの構想段階」から「5) サービス・業務の運用段階」までの各段階において、検討結果から具体化・詳細化した項目を、プロジェクト計画書に追加又は更新し、新たな工程を開始する時点で、最新の状態となるように留意する。
段階的な詳細化では、プロジェクト計画書を直接書き換える、又は、具体化・詳細化した個別計画書等の文書をプロジェクト計画書に付属させる。
また、内容の見直しにおいては、その理由とともに改定内容を履歴として残すことが望ましい。
なお、段階的な詳細化に伴い、プロジェクト計画書の変更内容について府省ＣＩＯやＰＭＯへの報告が必要かどうかを含め、「２．2)キ 変更管理」で定義した変更プロセスに従う。
（2）「なお、これらの時期以外に必要に応じて適宜改定することを妨げない」
「これらの時期以外」とは、「1) プロジェクトの構想段階」から「6) サブプロジェクトの組成時」までを除く、例えば次に示すような事象が発生したときを指す。
・プロジェクトの根拠となっている制度が改定されたとき。
・各種要因によりスケジュールの大幅な見直しが必要になったとき。
・プロジェクトを推進する過程で重大な問題が発生したとき。
・指標の水準の見直しが必要になったとき。
・政府全体の方針や、中長期計画等の府省重要方針が変更されたとき。
これらの事象は、いずれもプロジェクトの存続に係る重要な内容であるため、ＰＪＭＯはプロジェクト計画書を改定し、関係者間に速やかに周知する必要がある。ＰＪＭＯは、改定の要否や時期、報告・承認が必要な関係者等の改定に伴う手続を「２．2)キ 変更管理」で事前に定める。
なお、改定に伴う手続を事前に定めるに当たっては、ＰＭＯや府省内外のＣＩＯ補佐官、外部組織の有識者や専門的な知見を持つ職員の支援や助言を受けることが望ましい。
また、府省共通プロジェクトのプロジェクト計画書の改定については、主管府省のＰＪＭＯが行い、その結果を関係府省のＰＪＭＯへ通知し、合意を得る。
府省重点プロジェクトの見直しについては、ＰＪＭＯからプロジェクトの状況に関する報告をＰＭＯが受け、ＰＭＯが情報化推進委員会に諮った上でプロジェクトの見直しの検討を行う。
1） プロジェクトの構想段階
（3）「ＰＪＭＯは、プロジェクトの構想段階において、プロジェクト計画の概要を整理し、プロジェクト計画書の素案を作成する」
「プロジェクトの構想段階」とは、プロジェクトを計画する前に、ＰＪＭＯが計画の概要等の素案を作成・整理し、プロジェクトの必要性を判断する段階を指す。この段階においては、プロジェクト活動の前提となる政策目的並びにプロジェクトによって目指す定性的な目標を明確にし、プロジェクトの対象となる業務内容や実施計画等については可能な範囲で概略を記載する。
この段階で作成・整理する項目を以下に示す。
・政策目的・概要
・プロジェクトの目標
・対象業務範囲及びサービス・業務企画の内容（概略）
・実施計画（概略）
・予算（概算）
・体制
ＰＪＭＯは、このプロジェクト計画書の素案を基に、プロジェクト開始の必要性を判断し、予算の確保に向けた活動を開始する。
2） 当初計画段階
（4）「ＰＪＭＯは、プロジェクト計画書の素案が決定されてから、サービス・業務企画終了時までに、政策目的やプロジェクトの目標に基づき設定した業務効果に関する指標及び情報システム効果に関する指標、プロジェクトを推進する体制と各々の役割・責任、全体のスケジュール等について具体化・詳細化し、プロジェクト計画書に反映する」
「プロジェクト計画書の素案が決定されてから、サービス・業務企画終了時まで」とは、プロジェクトの構想段階で作成したプロジェクト計画書の素案が決定されてから、サービス・業務企画にて政策目的やプロジェクトの目標を達成できる内容を確定するまでの段階を指す。ＰＪＭＯは、この段階において、様々な指標、推進体制と役割・責任、全体スケジュール等を詳細化しておくことで、次の段階においても手戻りなく進めることができる。
また、プロジェクトの特性に応じて、プロジェクトの実行方式や、要件定義に着手するための参考情報として、技術動向その他の市場情報をＲＦＩにより取得し、プロジェクト計画書へ反映する。ＲＦＩの実施等については、標準ガイドライン「第３編第５章１．要件定義の準備」を参照する。
また、次に示す当初計画の段階において把握可能なリスクの評価を行う。プロジェクトの進行中に予見されたリスクは、その都度リスク評価の結果に追加する。
・プロジェクトの管理及び実行に関わるリスク
・構築しようとする情報システムに関するリスク
・運用及び保守段階に想定されるリスク 等
この段階で、プロジェクト計画書に整理し記載する項目を、次に示す。なお、括弧書きがある項目は、プロジェクト構想段階におけるプロジェクト計画書の素案を詳細化したものである。
・政策目的・概要
・対象業務範囲及びサービス・業務企画の内容（詳細）【更新】
・プロジェクトの目標（具体化）【更新】
・前提条件【追加】、リスク【追加】
・実施計画（具体化）【更新】
・予算（詳細）【更新】
・体制【更新】
3） 調達及び設計・開発開始前
（5）「ＰＪＭＯは、調達及び設計・開発を開始する前までに、サービス・業務企画及び要件定義を基にして、当初計画段階のプロジェクト計画書に詳細な内容を盛り込み、設計・開発段階前のプロジェクト計画書を具体化・詳細化する」
「調達及び設計・開発を開始する前まで」とは、当初計画段階を経て、サービス・業務企画及び要件定義の内容を基にして、設計・開発するための調達準備及び設計・開発準備の段階を指す。
「業務企画及び要件定義を基にして、当初計画段階のプロジェクト計画書に詳細な内容を盛り込み」とは、当初計画段階で作成したプロジェクト計画書に対し、調達時に事業者が必要とする情報を加え、内容を具体化・詳細化することを指す。その際、適切な体系のサブプロジェクト群に分割を行い、サブプロジェクトごとの計画もプロジェクト計画書に反映する（「6) サブプロジェクトの組成時」を参照）。
具体化・詳細化したプロジェクト計画書及び要件定義を基に、調達仕様書案を作成する（府省重点プロジェクト等の場合、調達仕様書案の内容について「第一次工程レビュー」を受け、レビュー結果を反映する）。プロジェクトの特性や規模に応じて、意見招請を実施し、その結果を調達仕様書案に反映する。
その後、調達仕様書を確定させ、これに基づき調達を行う。
また、府省重点プロジェクト等の場合、調達時の要件定義の内容を更に精緻化・具体化し、プロジェクト計画書及び要件定義書について「第二次工程レビュー」(「４．2)プロジェクトの工程レビュー」参照)を受け、レビュー結果を反映する。
4） 運用及び保守開始前
（6）「ＰＪＭＯは、運用及び保守を開始する前までに、運用開始後の評価指標等を具体化・詳細化し、プロジェクト計画書に反映する」
「運用開始後の評価指標等を具体化・詳細化」とは、ＰＪＭＯが、運用計画書及び保守計画書の案（標準ガイドライン「第３編第７章４．5）運用・保守の設計」参照）を取りまとめるとともに、運用における評価指標等を決定することを指す。ＰＪＭＯは、具体化した指標等を、プロジェクト計画書に反映する。
府省重点プロジェクト等の場合、「第三次工程レビュー」(「４．2)プロジェクトの工程レビュー」参照) を受け、そのレビュー結果を反映する。
5） サービス・業務の運営段階
（7）「ＰＪＭＯは、サービス・業務の運営段階において、政策目的やプロジェクト目標の達成状況、運用段階で必要となった改善点、発生した課題とその課題への対応、実施された改修、業務の状況の評価、業務の改善状況・改善計画及び実行結果等について具体化・詳細化し、プロジェクト計画書に反映する」
「サービス・業務の運営段階」とは、情報システムの設計・開発が終わり、企画したサービス・業務を実施する段階を指す。この段階では、運用及び保守の開始前に改定したプロジェクト計画書を指針として、プロジェクトに課せられた政策目的やプロジェクトの目標の達成状況を確認するとともに、当該情報システムの運用及び保守並びに業務の運営と改善に関する管理を行う。
具体的には、政策目的やプロジェクト目標の達成状況、運用段階で必要となった改善点、発生した課題とその課題への対応、実施された改修、業務の状況の評価、業務の改善状況・改善計画及び実行結果等をプロジェクト計画書に反映して、少なくとも毎年１回改定する(標準ガイドライン「第３編第８章 サービス・業務の運営と改善」及び標準ガイドライン「第３編第９章 運用及び保守」参照)。
なお、運用及び保守は、政府共通プラットフォームや府省内の情報システム基盤との連携等、他の情報システムと統合して実施されることが多いため、当該プロジェクトに関係する事項を適切に把握することや、関係する情報システムの状況を把握すること等に留意し、適宜ＰＭＯの調整の下に整合性を確保することが重要である。
6） サブプロジェクトの組成時
プロジェクトの進捗に合わせた「1) プロジェクトの構想段階」から「5) サービス・業務の運用段階」までの項目以外に、当該プロジェクトにサブプロジェクトを組成したときは、当該プロジェクトのプロジェクト計画書等へ、サブプロジェクトに係る情報を反映する必要がある。
このため、当該プロジェクトのＰＪＭＯは、サブプロジェクトを組成することにより変更すべき内容を検討し、プロジェクト計画書等を改定する。改定の検討対象は、プロジェクト計画書及びプロジェクト管理要領のおおむね全項目にわたるが、特に予算、体制及び実施計画は重点的に検討が必要である。
（8）「ＰＪＭＯは、当該プロジェクトに属するサブプロジェクトを組成する際、その内容を具体化・詳細化し、プロジェクト計画書に反映するものとする」
「その内容を具体化・詳細化し、プロジェクト計画書に反映する」とは、当該プロジェクトのＰＪＭＯが、プロジェクト計画書にサブプロジェクトの組成に関連して発生した情報を反映するために、情報を整理し改定を検討することである。
改定の検討対象は、プロジェクト計画書及びプロジェクト管理要領のおおむね全項目にわたるが、特に予算、体制及び実施計画は重点的に検討が必要である。
４. プロジェクトの実施
1） プロジェクトの実施
ＰＪＭＯは、プロジェクト計画書の内容に従って、プロジェクトを実施する。 |
プロジェクトを実施する過程においては、プロジェクトの目標達成を阻害する様々な事象が発生する。
このため、ＰＪＭＯは、プロジェクト計画書及びプロジェクト管理要領に従いプロジェクトを運営するとともに、定期的に自己点検やＰＭＯ等の第三者によるレビューを行い、プロジェクト目標を確実に達成できるよう、必要な対策を講じて、プロジェクトの各活動を推進する。
各活動の詳細については、標準ガイドライン「第３編第３章 予算要求」から標準ガイドライン「第３編第１０章 システム監査」の各章で説明する。
2） プロジェクトの工程レビュー
ＰＪＭＯは、 プロジェクトを適切に実施し、プロジェクトの目標を達成するため、府省重点プロジェクト及び各府省ＰＭＯが指定したプロジェクトについて (1) 、実施要否、実施時期及び実施内容等を府省ＰＭＯと調整し、 内閣官房及び総務省が別途定める手順に基づき、それぞれの場面（以下「レビューポイント」という。）において、次のとおり工程レビューを実施する (2) ものとする。 なお、 工程レビューの前後でプロジェクトの所管組織が変更になるときは、原則として、移管先の府省も併せて実施する (3) ものとする。 [1] 調達仕様書に添付する要件定義書の作成終了前 [2] 設計・開発工程に入る前に要件定義の確定を行う前 [3] 総合テスト計画書の確定を行う前 上記[1]、[2]及び[3]における工程レビューをそれぞれ第一次工程レビュー、第二次工程レビュー及び第三次工程レビューと称する。 ア 自己点検 プロジェクト推進責任者は、レビューポイントにおいて自己点検を行い、その結果をＰＭＯに送付する (4)ものとする。 自己点検は、どのようなプロジェクトにあっても、プロジェクトを成功に導くために必要な留意点を点検するものであり、工程レビュー対象以外のプロジェクトにおいてもその実施が望ましい。 自己点検には、「3)ア モニタリング」の結果も加えるものとする。 イ ＰＭＯレビュー ＰＭＯは、ＰＪＭＯが行った自己点検を基に、ヒアリングを行った上でレビューを行い、ＰＪＭＯに指摘、助言又は指導を行う (5) ものとする。なお、府省重点プロジェクトにおいては、府省ＣＩＯ又は府省副ＣＩＯも積極的に状況を把握し、レビューに関与するものとする。また、ＰＭＯは、自己点検及びレビュー結果をＯＤＢに登録した上で、総務省及び内閣官房に通知するものとする。 ウ 内閣官房及び総務省による指摘、助言又は指導 内閣官房及び総務省は、自己点検及びレビュー結果を基に、必要に応じてヒアリング等を実施し、法令改正、予算措置の要否、調達スケジュール等も踏まえ、必要な指摘、助言又は指導を行うものとする。 エ レビュー対応 プロジェクト推進責任者はＰＪＭＯ各担当と調整し、ＰＭＯ、内閣官房及び総務省から指摘、助言又は指導を受けた際は、必要な対応策を講ずるものとする。 |
ＰＪＭＯを担う担当者のプロジェクト管理スキル不足や経験ノウハウが乏しいときは、プロジェクト内の課題の洗い出しや必要な対策を十分に講ずることができず、リカバリーが困難な状況に至ることもある。
特に、国民や関係機関への幅広い影響が想定される府省重点プロジェクト等においては、対応の遅れや誤った対策が大きな問題に発展するおそれがある。
このため、府省重点プロジェクト及び府省ＰＭＯが指定したプロジェクトのＰＪＭＯは、プロジェクトの進捗、品質等に影響する課題・不具合等を早期に発見し、必要な対策を講ずるために、ＰＭＯ、府省ＣＩＯ及び政府ＣＩＯ補佐官が関与する工程レビューを実施し、プロジェクトの運営状況を検証する。
２. 解説（1）「プロジェクトを適切に実施し、プロジェクトの目標を達成するため、府省重点プロジェクト及び各府省ＰＭＯが指定したプロジェクトについて」
「各府省ＰＭＯが指定したプロジェクト」とは、例えば次に示すようなプロジェクトを指す。
・府省重点プロジェクト以外で、中長期計画に記載されているもの
・費用対効果の観点で十分な結果が得られていないと考えられるもの
・情報システムの運用において、障害等のトラブルが頻発しているもの
（2）「内閣官房及び総務省が別途定める手順に基づき、それぞれの場面（以下「レビューポイント」という。）において、次のとおり工程レビューを実施する」
「内閣官房及び総務省が別途定める手順」とは、「工程レビュー実施手順書」において定める、工程レビューの詳細な実施手順を指す。 (参考:工程レビュー実施手順書 平成27年3月内閣官房情報通信技術（ＩＴ）総合戦略室)
「工程レビュー」とは、ＰＪＭＯがプロジェクトを健全に進行させるために、ＰＪＭＯ、ＰＭＯ及び府省ＣＩＯ補佐官がそれぞれの視点でプロジェクト状況を確認することである。
第一次・第二次工程レビューは、政府内及び一般的なプロジェクト管理における過去の実績や経験を活用しつつ、プロジェクトの企画段階及び設計・開発段階において、ＰＪＭＯによる自己点検並びにＰＭＯ及び府省ＣＩＯ補佐官による第三者チェックを経て、プロジェクトの進捗、品質等に影響する課題・不具合等を早期に発見し、必要な対策を講ずることを目的とする。
また、第三次工程レビューは、情報システムの品質や性能を十分検証せずに新サービス・業務に切り替えることで生じる問題を回避するため、総合テストのテスト計画・移行計画等を確認し、サービス開始に際する課題・不具合等を早期に発見し、必要な対策を講ずることを目的とする。
（3）「工程レビューの前後でプロジェクトの所管組織が変更になるときは、原則として、移管先の府省も併せて実施する」
「移管先の府省も併せて実施する」とは、当該プロジェクトの体制が変更となる際に、工程レビューにおいて生じた指摘や改善すべき事項についてコミュニケーション上の齟齬や欠落を防止するために、移管が実施される前であっても、移管先の府省のＰＪＭＯと移管元の府省のＰＪＭＯが協働して工程レビューを実施することである。
ア 自己点検
どのようなプロジェクトにおいても、作業内容や進捗状況が一切問題ないということは極めてまれであり、問題に気付かずにプロジェクトが進行すると、後の軌道修正に多大な労力が必要となる。
このため、ＰＪＭＯは、実施手順書で定める「チェックシート」を使用し、プロジェクト進捗状況の確認、プロジェクトで実施している作業内容等について点検を行うことで、円滑にプロジェクトを推進する。
なお、チェックシートは、適切にプロジェクトを遂行する上で特に留意が必要な事項に対する点検項目、当該項目を満たすための詳細な点検方法及び必要となる証跡の例を記したものである。点検項目には、過去の政府におけるプロジェクトの教訓も含まれており、政府全体でプロジェクト管理能力の向上を図ることを目的としている。
ただし、全てのプロジェクトはその特性によってリスク等が異なること、また、実施手順書で定めるチェックシートの点検項目は網羅性を担保しているわけではないことから、ＰＪＭＯは、適宜、プロジェクトの特性に応じて点検項目の修正・追加等を行うことを推奨する。
（4）「レビューポイントにおいて、モニタリングの結果を踏まえて自己点検を行い、その結果をＰＭＯに送付する」
「自己点検」とは、ＰＪＭＯが、実施手順書で定める「チェックシート」を使用し、プロジェクト進捗状況の確認、プロジェクトで実施している作業内容等について点検を行うことである。
「その結果をＰＭＯに送付する」とは、自己点検の実施に際してＰＪＭＯが使用したチェックシート及び証跡資料をＰＭＯに送付することをいう。
ＰＪＭＯは、円滑にプロジェクトを推進するために、プロジェクト進捗状況の確認やプロジェクトで実施している作業内容等について自己点検を行い、その点検結果をＰＭＯに送付する。
なお、第一次から第三次までの工程レビューのいずれにおいても、原則として、「工程完了見込み時の自己点検」と「工程完了時の自己点検」を行う。ＰＭＯレビューは「工程完了見込み時」の自己点検後に実施する。
イ ＰＭＯレビュー
プロジェクトを実際に推進しているＰＪＭＯが実施する自己点検のみでは、ＰＪＭＯが認識していない問題や、より良いプロジェクトの推進案は把握が困難である。
このため、ＰＭＯは、プロジェクトの成功がより確実なものとなるよう、第三者的な立場からレビューを行い、ＰＪＭＯの責任者が見落とす可能性のある事項について補完する。
（5）「ＰＭＯは、ＰＪＭＯが行った自己点検を基に、ヒアリングを行った上でレビューを行い、ＰＪＭＯに指摘、助言又は指導を行う」
「ＰＭＯは、ＰＪＭＯが行った自己点検を基に、ヒアリングを行った上でレビューを行い」とは、ＰＭＯがＰＪＭＯとは異なる視点からプロジェクトの評価を行うために、ＰＪＭＯが実施した自己点検結果を基に、確認・検証（レビュー）を行い、レビュー結果を「工程レビュー結果シート」に記入することである。レビュー結果は、「了承」「条件付き了承」「要改善」いずれかとし、その結果に基づいて、ＰＪＭＯに指摘、助言又は指導を行う。
ＰＪＭＯは直近の問題に注視しがちになるが、ＰＭＯはプロジェクト全体を俯瞰した視点での確認を行うことに留意する。
ウ 内閣官房による指摘、助言又は指導
府省重点プロジェクトにおいては、進捗や品質等に影響を与える不具合等を早期に発生し、プロジェクトの目標を確実に、かつ、円滑に達成する必要がある。
このため、プロジェクトの成功がより確実なものとなるよう、内閣官房が専門家としての立場及び第三者的な視点からレビューを行い、ＰＪＭＯ及びＰＭＯが見落とす可能性のある事項について補完する。
エ レビュー対応
ＰＭＯ又は内閣官房からのレビュー結果には、「了承」、「条件付き了承」及び「要改善」の３つの判断結果が指定されており、それぞれの結果で対応すべき事項が異なる。
このため、プロジェクト推進責任者は、レビュー結果に応じてＰＪＭＯ各担当者と調整し、工程レビュー実施手順書に基づいた対策を講ずる。
3） プロジェクトのモニタリング及び停止・改善
プロジェクトのモニタリング及び停止・改善については、次のとおり実施するものとする。 ア モニタリング プロジェクト推進責任者は「２．1)ケ モニタリング」で定めた方法に基づき、継続的・定期的にモニタリングを行うものとする (1) 。モニタリングにより各活動の品質状況を把握し、活動単位の影響に加え、プロジェクト全体視点での影響を検証し、適宜対策を講じる。モニタリングの内容は、「２．1)ケ モニタリング」の記載に従う。 イ プロジェクトの停止・改善 「2) プロジェクトの工程レビュー」等の結果から、内閣官房が次のいずれかに当てはまる状況であると判断したときは (2) 、府省ＣＩＯに対して「プロジェクト検証委員会」の立ち上げと検証結果を要請する。なお、b)に該当するプロジェクトについては、「プロジェクト検証委員会」が定期的にモニタリングの結果を把握するものとする（「第２編第９章２．プロジェクト検証委員会の設置」参照）。 a) プロジェクトの停止が必要な状況 設計、開発等の工程で重要な問題が発生し情報システムの完成が見込めない、又は情報システムの開発や運用を継続してもサービス・業務への効果が著しく低い等、当該プロジェクトを停止することが必要な状況 b) プロジェクトの抜本改善が必要な状況 社会的影響、業務継続の観点から当該プロジェクトを停止することができないが、プロジェクトの状況に抜本的な改善が必要な状況 |
プロジェクトが正しく進捗していることを正確に評価するには、日々のプロジェクト活動を一定の方式で把握（モニタリング）し、定期的にその結果を検証することが必要となる。
このため、モニタリングと検証及び確認結果に応じた対応について定義する。
２. 解説ア モニタリング
プロジェクト実施中は、同時期に複数の作業が進捗するが、各作業の担当者は個別の活動に注力するため、担当作業で問題が発生したとしても、プロジェクト全体への影響を十分に考慮することは困難である。
このため、プロジェクト推進責任者は、各活動の品質状況を把握し、活動単位の影響に加え、プロジェクト全体視点での影響を検証し、適宜対策を講じる。
（1）「プロジェクト推進責任者は「２．1)ケ モニタリング」で定めた方法に基づき、継続的・定期的にモニタリングを行うものとする」
「「２．1)ケ モニタリング」で定めた方法」とは、プロジェクト計画書のモニタリングの項で定めた内容を指す。モニタリングは、「２．2)ウ 工程管理」、「２．2)エ 指標管理」、「２．2)ク 品質管理」で定める管理項目との関連を検討した上で策定したモニタリング計画に基づき、計画内容を十分に理解した上で、着実に実施することが重要である。
イ プロジェクトの停止・改善
プロジェクトは政策目的やプロジェクトの目標を達成し、完了することが前提であるが、実施過程の様々な要因により、計画どおりに遂行できない事態に陥ることがある。その状況のままプロジェクト進行することにより、更に深刻な事態に発展する可能性があるプロジェクトは、早急に抜本的な見直しが必要となるが、ＰＪＭＯがその判断をすることは困難である。
このため、「2) プロジェクトの工程レビュー」の結果や「２．2)カ 課題管理」等から得られた情報を内閣官房が判断し、ＰＭＯにプロジェクト検証委員会（標準ガイドライン「第２編第９章２．プロジェクト検証委員会の設置」参照）を要請し、プロジェクトの停止・改善を検討する。
（2）「「2) プロジェクトの工程レビュー」等の結果から、内閣官房が次のいずれかに当てはまる状況であると判断したときは」
「「2) プロジェクトの工程レビュー」等の結果」とは、プロジェクトの「４．2)プロジェクトの工程レビュー」や「４．3)ア モニタリング」等により把握出来たプロジェクトの状況を表す結果を指す。
「次のいずれかに当てはまる状況」とは、上記の結果が「４．3)イ a) プロジェクトの停止が必要な状況」及び「４．3)イ b) プロジェクトの抜本改善が必要な状況」に該当する状況を指す。例を次に示す。
・設計・開発工程の途中で、何らかの問題によって開発が頓挫してしまい、完了の見込みが立たない。
・運用中ではあるが、利用が進まず業務の効率化等の成果を把握できないため、抜本的な見直しが必要な状況である。
・運用中ではあるが、多額の運用経費がかかっているにもかかわらず、当初の目的・目標に大幅に達していない。
・サービスの品質が低く、関係者に多大な迷惑を与えている。
なお、プロジェクトの停止・改善を実施するに当たり、契約の変更や解除等を行うときは、ＰＪＭＯは会計担当部門に相談する。
５. 政府ＣＩＯによるレビュー
府省重点プロジェクトのうち特に重要なプロジェクトその他の政府ＣＩＯが特に重要と認めるプロジェクトについては、中長期計画のフォローアップの結果等を踏まえ、政府ＣＩＯによるレビューを行うものとする。 政府ＣＩＯによるレビューを実施する際には、説明の前提として次の内容を明確にするように留意すること (1)。 ＜政府ＣＩＯによるレビューでの説明前提事項＞ [1] 目指す姿の明確化（長期的に目指す将来像と、中期的にプロジェクトで 取り組む事項との両方を明確化する） [2] 業務・システムの全体像の明確化 [3] プロジェクトの全体スケジュールの明確化 |
府省重点プロジェクトを含め、構築や運営が遅延することにより、社会的影響が大きいものや重要な政策に関わるもの、他の情報システム等へ広く影響するもの等については、問題が発生したときに多大な影響が想定される。
このため、そうしたリスクを最小限に抑えるために、政府ＣＩＯが持つ知見・視点により、政府ＣＩＯレビューとして、各工程を完了する前までに検証を実施する。
２. 解説（1）「政府ＣＩＯによるレビューを実施する際には、説明の前提として次の内容を明確にするように留意すること」
政府ＣＩＯによるレビューの際には、プロジェクトで発生している課題や対応方法等のみに焦点を当てて説明するのではなく、プロジェクトの目指す姿、業務・システムの全体像、プロジェクトの全体スケジュールを前提事項として明確にし、背景事象を含めた全体像を説明することが重要であることに留意する必要がある。
なお、これらの説明前提事項の記載例については、デジタル・ガバメント推進標準ガイドライン実践ガイドブック第２章の別紙「政府ＣＩＯによるレビューでの説明前提事項(サンプル）」として示しているので参考にすること。
６. 後続プロジェクトの策定
当該プロジェクトが完了する前に、関連する後続プロジェクトの実施が見込まれるときは「第２章 プロジェクトの管理」に定める作業を実施するものとする (1) 。 関連する後続プロジェクトが発生する場合は、次のとおりである。 [1] プロジェクトの対象とする事業が継続される場合、かつ当初計画した実施期間を終える場合（「７．1) 完了」参照）。 [2] プロジェクトで扱う情報システムを更改する場合（「第８章４．情報システムの改善」参照）。 |
プロジェクトの対象とする事業が継続され、当該プロジェクトが完了した後も、引き続きプロジェクトで扱う情報システムを利用する場合や、情報システムを更改する場合は、現在の情報システムが提供しているサービス・業務を滞りなく提供するための準備が必要となる。
このため、当該プロジェクトが完了する前に、必要な情報や資源の引継ぎを行うために、後続プロジェクトの活動を開始する。
２. 解説（1）「当該プロジェクトが完了する前に、関連する後続プロジェクトの実施が見込まれるときは「第２章 プロジェクトの管理」に定める作業を実施するものとする」
「「第２章 プロジェクトの管理」に定める作業を実施するものとする」とは、後続するプロジェクトのプロジェクト推進責任者が、当該プロジェクトの後続となるプロジェクトを開始するために、「１．プロジェクトの立ち上げと初動」から準備活動を行うことである。
後続プロジェクトの開始時期は、当該プロジェクトが完了する時期と後続プロジェクトの大まかな実施期間から逆算し、当該プロジェクトの対象事業に空白期間が生じないよう考慮する必要がある。
７. プロジェクトの終結
プロジェクト推進責任者は、 プロジェクト計画書の内容を全て実施し終えたときに、プロジェクトの終結としてＰＭＯにその旨を報告する (1) ものとする。 ＰＭＯは、府省重点プロジェクトが終結した場合は、内閣官房にその旨を連絡するものとする。 なお、情報システムを廃止又は更改する際、当該情報システムを構成するハードウェア、ソフトウェア製品等の利用を停止し、情報セキュリティ等の観点を踏まえ、廃棄又は再利用に取り組むものとする (2)。 1) 完了プロジェクトの対象とする事業が継続し、かつ当初計画したプロジェクトの実施期間が終了するときは、プロジェクトを完了させ、新しくプロジェクトを開始するものとする。 プロジェクトの完了前に、プロジェクト計画書に定めた目標の達成状況を評価し、その結果を踏まえて後続プロジェクトの計画を策定するものとする。 2) 終了プロジェクトの対象とする事業又は情報システムを廃止するとき (3) は、プロジェクトの終了前に、プロジェクト計画書に定めた目標の達成状況を評価し、その結果をＰＭＯへ報告するものとする。 |
プロジェクトは、プロジェクト計画書に定義された政策目的やプロジェクトの目標を達成するための活動を実施し、その達成をもって終結するよう実施計画を定義している。
このため、ＰＪＭＯは、次のような条件を満たした場合を契機として、当該プロジェクトを終結する。
・プロジェクト計画書であらかじめ定められた完了条件が満たされたとき。
・政策的判断により、プロジェクトの打切りが決定されたとき。
・「７．2) 終了」に基づいて情報システムの廃止が決定されたとき。
プロジェクトの手段としての情報システムがその価値を失ったときは、情報システムの維持コストの発生を無くし、情報セキュリティインシデントの発生を無くすために、速やかに情報システムの廃止を検討する必要がある。
２. 解説（1）「プロジェクト計画書の内容を全て実施し終えたときに、プロジェクトの終結としてＰＭＯにその旨を報告する」
「ＰＭＯにその旨を報告する」とは、プロジェクトが終結の条件を満たしたときに、ＰＪＭＯがプロジェクト計画書に終結を記録し、そこまでの経緯等を示す資料を取りまとめ、ＰＭＯに報告することを指す。
なお、府省重点プロジェクトが終結した場合、ＰＭＯは内閣官房に報告する。
（2）「情報セキュリティ等の観点を踏まえ、廃棄又は再利用に取り組むものとする」
「情報セキュリティ等の観点を踏まえ」とは、情報システムを構成するハードウェア、ソフトウェア製品等を廃棄又は他のＰＪＭＯ等による再利用に供しようとする場合には、自府省の情報セキュリティポリシーに基づき、復元困難な方法による電磁的記録の抹消・破壊等の適切な措置を講じることを指す。
ＰＪＭＯは、情報システムを構成するハードウェア、ソフトウェア製品等を廃棄しようとするときは、廃棄を行う事業者に対し、廃棄物、数量、所有形態、再利用の可否、廃棄方法等を記載した廃棄対象物リストの提出を求め、適切に廃棄されるようその内容を確認するものとする。
また、廃棄後、廃棄を行う事業者に対し、廃棄対象物リストどおりに廃棄したことを確認するものとする。
ＰＪＭＯは、特に再利用先にソフトウェア製品を引き渡す場合には、その購入の際に納品されたメディアやライセンス証書等、ライセンスの保有を証明するために必要となる部材も併せて引き渡すものとする。
1） 完了
プロジェクトの実施期間の終了時期において、プロジェクトの対象である情報システムを利用する事業が継続するときに、プロジェクト計画書等の内容を改定し終期を延長し続けると、終期の来ない計画となり、プロジェクトの達成目標に対する評価の実施時期が不明瞭となる。
このため、ＰＪＭＯはこの状態のプロジェクトは延長せず、資料の取りまとめ、プロジェクトの評価等のプロジェクト計画書の定義に従って完了する。
なお、継続する事業が利用する情報システムは、「６．後続プロジェクトの策定」で示す手順に従って、プロジェクト計画を策定する。
また、完了したプロジェクトに関するプロジェクト計画書等は、新たなプロジェクトの重要な参考資料として参照されるものとなる。
2） 終了
プロジェクトの対象とする事業が、何らかの理由で継続しないことが決定したときは、当該情報システムが不要になる可能性がある。
このため、プロジェクト推進責任者は、プロジェクトをプロジェクト計画に定めた完了時期が到来する前に、情報システムの廃止を行い、プロジェクトを終了させる。
（3）「プロジェクトの対象とする事業又は情報システムを廃止するとき」
「プロジェクトの対象とする事業又は情報システムを廃止するとき」とは、次のいずれかが生じた場合を指す。
[1] 情報システムの整備の根拠となった政策又は業務が廃止される場合
[2] 業務の縮小等により、手作業で業務を行ったり、他の情報システムを利用したりする方が経済的と考えられる場合
なお、[2]は標準ガイドライン「第３編第８章２．サービス・業務の運営」の結果を基に判断される。廃止に向けた作業として、例えば以下の作業が挙げられる。
・サービス・業務の停止や変更が行われるまでのスケジュール作成
・当該情報システムで使用していたクラウドサービス・ハードウェア・ソフトウェア等の廃棄、再利用又は契約手続
・利用者への周知
サービス・業務の停止や変更の時期については、関連する業務や、利用者への影響を十分に考慮し検討する必要がある。
情報システムを廃止する際は、当該情報システムで使用していたデータの取扱い方法の検討や検討結果の実施、廃止後においても一定期間ドメインを維持し第三者による悪用を避ける等について、運用事業者及び保守事業者と連携し、作業計画を検討することが重要である。
８. 一元的なプロジェクト管理
内閣官房、総務省及び各府省は、予算要求前から執行の段階まで年間を通じたプロジェクト管理（一元的なプロジェクト管理）を行うものとする (1) 。特に、以下の３段階については、主に次のとおり検証を行う。 [1] 予算要求前（プロジェクトの計画段階）クラウドサービスの利用の可否などプロジェクトの基本的な方向性や関連サービスとの連携、重複投資の可能性等について検証を行う。 [2] 予算要求時（プロジェクトの具体化段階）予算編成に向けた費用対効果等の検証を行う。 [3] 予算執行前（詳細仕様の検討段階）費用の妥当性や仕様の適正性、業務改革（BPR）等について検証を行う。なお、上記検証は、補正予算で情報システムの整備等が実施される場合も含む (2)。 |
デジタル・ガバメント実行計画（令和元年12月20日閣議決定）において、「全ての情報システムを対象として、予算要求前から執行の段階まで年間を通じたプロジェクト管理を、政府CIOの下で行う」とされていることを受けて、[1]予算要求前、[2]予算要求時、[3]予算執行前の各段階を中心に検証を実施する。
２. 解説（1）「内閣官房、総務省及び各府省は、予算要求前から執行の段階まで年間を通じたプロジェクト管理（一元的なプロジェクト管理）を行うものとする」
年間を通じたプロジェクト管理の対象となるプロジェクトは、全ての情報システムに係るプロジェクトであり、プロジェクト管理の主体が、内閣官房、総務省及び各府省であることを明記したものである。プロジェクト管理の主体は、政府重点プロジェクトや予算規模が大きいプロジェクトなど内閣官房及び総務省が中心となって行うものと、各府省（各府省CIO）が中心となって行うものに分けて行うものを指す。
各府省が中心となってプロジェクト管理を行う際には、内閣官房が別途示すチェックの観点に従い検証を行うものとする。
（2）「上記検証は、補正予算で情報システムの整備等が実施される場合も含む」
「補正予算で情報システムの整備等が実施される場合」とは、補正予算により情報システムの新規構築、改修、更改、運用等が実施される場合を指す。
年間を通じたプロジェクト管理の対象は全ての情報システムに係るプロジェクトであり、補正予算で情報システムの整備等が実施されるプロジェクトについても対象であることは自明であるが、補正予算によるプロジェクトの場合、予算要求から執行が完了するまでの時間が限られていることも多いことから、三段階の検証プロセスを限られた時間の中で行う必要があるため、特に以下の点に留意すること。
l 補正予算によるプロジェクトの場合、緊急的に予算が編成されることが多いことから、[1]予算要求前、[2]予算要求時の各検証に十分な時間を割くことができないおそれもある。そのため、[3]予算執行前のタイミングにおいて、[1]予算要求前、[2]予算要求時に検証すべき観点も併せて検証すること。
l 予算要求時点では見積もりの精査が難しい場合も想定されるため、[3]予算執行前のタイミングの検証においては、必要経費の精査の観点にも留意すること。