第1章 ITマネジメントの全体像

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

(第3編第1章 ITマネジメントの全体像)

2020年(令和2年)3月31日

内閣官房情報通信技術(IT)総合戦略室

〔標準ガイドライン群ID〕

1009

〔キーワード〕

ITマネジメント、プロジェクトの全体像、クラウドサービス、実証実験

〔概要〕

標準ガイドラインの下位文書として、標準ガイドラインの記載の趣旨、目的等を理解しやすくするため、逐条的な解説等を記載した参考文書。


改定履歴

改定年月日 改定箇所 改定内容
2020年3月31日 ・解説書全体に合わせ、日付のみ更新
2019年2月27日 ・初版決定

目次

第1章 ITマネジメントの全体像

1. ITマネジメントの位置付け

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


第1章 ITマネジメントの全体像

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

1. はじめに

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

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

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

1. ITマネジメントの位置付け

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

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

標準ガイドラインでは、PJMOによるITマネジメントが、政府CIOや府省CIOを頂点とするITガバナンスにより適正化されるよう、ITガバナンスとITマネジメント及びその各章を、図 3-1のように位置付けて規定している。

図 3-1 ITガバナンスとITマネジメント及びその各章の関係(イメージ)

図 3-1 ITガバナンスとITマネジメント及びその各章の関係(イメージ)


1. 趣旨

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

2. 解説

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

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

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

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

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

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


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

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

なお、検討に当たっては、PMOや府省CIO補佐官等の支援や助言を受けることが望ましい (6)

1. 趣旨

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

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

2. 解説
(1)「PJMOが管理するプロジェクトは、作業の特性や期間の違い等があるため、一様とはならない」

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

c 表1-1

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

要因の種類

具体例

サービス・業務の内容

運営するサービス・業務の内容、利用者の種類、利用量 等

実施環境や制約

構築する期間、予算、関係者及び経済情勢 等

プロジェクトの規模

ステークホルダーの範囲(利用者に国民を含む、職員のみ利用等)、処理件数、機能数、関係するプロジェクトの数、府省重点プロジェクトに指定されているか 等

情報システムの整備内容

新規開発、改修開発、再構築、運用、製品・サービス購入、移行 等

情報システムの整備方法

情報システムの開発形態(スクラッチ開発、パッケージ導入、クラウドサービス利用等)、開発手法(ウォーターフォール、アジャイル等)

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

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

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

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

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

設計・開発が複数年度にまたがり、かつ、クラウドサービスを用いる場合の例を図1-1に示す。


特徴及び留意点

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

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

[2] クラウドサービスは利用料が低下傾向にあるため、運用・保守の契約を短期に設定し、更新のタイミングで費用の見直しを検討することも効果的である。

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

図1-1 プロジェクトの全体像と流れ(設計・開発が複数年度かつクラウドサービス利用の例)

図1-1 プロジェクトの全体像と流れ(設計・開発が複数年度かつクラウドサービス利用の例)

実証実験の場合


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

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

図1-2 プロジェクトの全体像及び流れ(実証実験の場合)

図1-2 プロジェクトの全体像及び流れ(実証実験の場合)


特徴及び留意点

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

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

[1] プロジェクト効果の実現性や実現案の妥当性を検証すること等を目的とし、システム構築を複数の段階に分け、情報システムの効果を計るために必要な最低限の機能から構築し、効果のモニタリングを行う。

[2] [1]のモニタリング結果を踏まえて、サービス・業務企画や要件定義を見直し、本格的な情報システムの開発を行う。

設計・開発が単年度の場合

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

設計・開発が単年度となる新規サービスを構築する場合を図1-3に示す。

図1-3 プロジェクトの全体像及び流れ(設計・開発が単年度の場合

c 図1-3 プロジェクトの全体像及び流れ(設計・開発が単年度の場合)


特徴及び留意点

[1] 開発の規模が小さい場合、設計・開発と保守・運用を分割して調達することにより得られる効果が少ないため、費用対効果を踏まえて、設計・開発、運用・保守をまとめて調達することも検討する。

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

「情報システムのライフサイクル期間」とは、情報システムの計画・企画、構築から運用・保守を経て廃止するまでの期間を指す。この期間は、ハードウェア、ソフトウェア製品等の保守期間と国庫債務負担行為の期間を鑑み、サービス開始年度から5か年を超えない範囲の期間を目安とする。

なお、クラウドサービス利用の場合においても、定期的なサービス・業務の改善の必要性を鑑み、他の場合と同様にサービス開始年度から5か年程度をライフサイクル期間の目安とする。

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

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

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

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

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

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

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

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

(6)「検討に当たっては、PMOや府省CIO補佐官等の支援や助言を受けることが望ましい」

「府省CIO補佐官等」とは、自府省を担当するCIO補佐官以外に、他府省のCIO補佐官、外部組織の有識者や専門的な知見を持つ職員を含む。