第２章　プロジェクトの管理

第２章　プロジェクトの管理

目次
Step.1 プロジェクト管理活動全体の流れ
Step.2 プロジェクトの立上げ、初動
１ 目標とする成果を見定める
A. 現場で発生している事実をつかんだ上で今後の目標を定める
B. 上位計画の目標をブレークダウンし、プロジェクト目標と紐づける
C. 削減した業務時間をどこで活かすかを明確にする
２ プロジェクトへの投資判断を行う
３ 機能する体制を作る
A. 制度所管部門、業務実施部門等を含めたＰＪＭＯ体制とする
B. プロジェクトの規模に見合った体制を組む
C. 他組織と連携できる体制を作る
D. 先行経験を持つ人のノウハウを活用する
Step.3 プロジェクト計画書等の作成
１ プロジェクト計画書を作成する
A. プロジェクト計画書は段階的に詳細化する
B. 抜け漏れのない実施計画を作成する
２ プロジェクト管理要領を作成する
A. 問題に対処できる会議体を構成する
B. 本質的なリスクを事前に予見して、対応を準備する
C. 品質管理を事業者任せにしない
Step.4 プロジェクトのモニタリング
１ プロジェクトをモニタリングし・検証する
A. 目標、経費、進捗、品質等を中心にモニタリングする
B. モニタリングは適時に実施する
C. モニタリングと監査をうまく組み合わせる
D. プロジェクトは状況に応じて停止・改善する
Step.5 プロジェクトの終結
１ プロジェクトの終結を処理する
A. プロジェクトを完了する
B. プロジェクトを終了する
C. 後続プロジェクトを策定する
事例・参考の一覧 ポイント：利用者視点での目標設定には、サービスデザイン思考を！
ポイント：事実を詳細につかむことも忘れずに
事例：ＫＰＩトレーサビリティ・ツリーによる目標の紐付け
事例：事務作業を効率化し、国民向けの対応サービスを強化
事例：制度・業務・システムの三位一体のプロジェクト体制
参考：ＰＪＭＯの主要業務
事例：情報共有ツールによる関係者への情報共有
事例：府省を跨った特別移行支援チーム
様式例：プロジェクト計画書のひな形
参考：補正予算で開始するプロジェクト
様式例：プロジェクト管理要領のひな形
事例：業務実施部門が参加しなかったプロジェクト
事例：幹部職員への定期的な報告
事例：開発途中の機能追加による目標の形骸化
事例：抜本的な改善のために新たな体制を構築

Step.1 プロジェクト管理活動全体の流れ

情報システムの構築に関するプロジェクト管理には、一般的に様々な手法が存在し、たくさんの書籍や報告書等にも知識や経験則が示されています。確かに、専門性の高い知識やノウハウがあるに越したことはありませんが、全てを熟知しないとプロジェクト管理ができないわけではありません。

ここでは、プロジェクト管理の専門家ではない職員が、標準ガイドラインに沿ってプロジェクトを管理し、推進していくために必要となる具体的な知識やノウハウについて説明します。

本ドキュメントの構成は、次のとおりです。

Step.2　プロジェクトの立ち上げ、初動

プロジェクトの初動とは、プロジェクトが生み出され、スタートを切ろうとしている際のタイミングです。この出だしでいくつかの内容を理解し、行動しておくことで、プロジェクトの手戻りを大きく減らすことができます。

ここでは、これらの知識やノウハウについて、具体的に説明します。

Step.3　プロジェクト計画書等の作成

プロジェクトには必ず定めるべき事項が存在します。それは、プロジェクトスタート時点で決められるもの、プロジェクトが進むにつれて具体化されるもの、状況に応じて内容を見直すもの等、様々な情報で成り立ちますが、全てはプロジェクト計画書に記載され、関係者にて共有される必要があります。

ここでは、まずプロジェクト計画書とはどのような位置づけで、何に気をつけて作成していくのかについて、説明します。

また、具体的な活動方針であるプロジェクト管理要領の作成に関する要点についても説明します。

Step4　プロジェクトのモニタリング

プロジェクトは、プロジェクト計画書にのっとり実施されます。実施中、特に管理面で発生するイベントを中心にその内容と留意点を説明します。

Step.5　プロジェクトの終結

プロジェクトの実施期間が10年を超えるものも珍しくありませんが、期間の長短にかかわらずスタートしたプロジェクトはいずれ終わりを迎えます。

ここでは、プロジェクトの終了前後で何をすべきか、どんな終わり方があるのか、後続となるプロジェクトへのバトンの渡し方について、説明します。

Step.2 プロジェクトの立上げ、初動

プロジェクトを立ち上げることになってメンバーの１人に任命されたんだけど、いったい何をしたらいいんだろうか。新しいプロジェクトの立ち上げに携わる時には、誰もがうれしさ半分、とまどい半分という入り混じった気持ちになります。

実は、この実践ガイドブックを作成する前までの標準ガイドラインでは、プロジェクトを開始した後のことについては詳細に記載していましたが、プロジェクトを立ち上げる際にどのような検討を行って、誰が意思決定するかといった活動については書ききれていませんでした。でも、プロジェクトを立ち上げる際に、目標や方向性そのものが誤っていては、プロジェクトが成功するはずがありません。

そこで、今回の標準ガイドラインの改定では、「プロジェクトの立ち上げ、初動」について新たに記載を追加し、考え方や注意すべき点を強調しています。プロジェクトを立ち上げる際の動き方について、特に重要になる点を説明します。

１ 目標とする成果を見定める

【標準ガイドライン関連箇所：第３編第２章第１節1)】

今まで、いくつかの失敗プロジェクトがありました。

失敗プロジェクトについて後から振り返ってみると、プロジェクト開始当時に業務分析を軽視し、楽観的な推測を基に想定効果を過大に見積っていたという傾向が共通的に見られました。このような失敗を繰り返さないために、新しいプロジェクトを開始する際には、ぜひこれから説明する内容を意識してください。

A. 現場で発生している事実をつかんだ上で今後の目標を定める

このタイトルを読んだだけでは、当たり前のことのように思えるでしょう。ただ、一口に「事実をつかむ」と書いても、どの水準までつかむ必要があるのか、人によって理解は様々です。

そこで、ここでは１つの例を題材として、考えてみましょう。

紙の申請書を窓口で受け付けていた業務について、ＩＴを使ってサービスを改善するためのプロジェクトを立ち上げたとします。このプロジェクトの目標は何でしょうか。

まず、「申請者の利便性向上」といった言葉が思い浮かぶかもしれません。窓口に来るということ自体、申請者にとっては面倒なことです。電子申請を導入すれば、申請者の手間を減らすことができるかもしれません。ただ、電子申請を導入したとしても、窓口に来る方が便利という人もいるでしょう。まずは、全ての申請件数のうち、60%程度を電子申請経由とすることを目指すのが現実的な線でしょうか。

さて、これで目標設定が完了しました・・・。本当に、これで大丈夫でしょうか？

図2-1　目標設定の悪い例

実は、この例には目標設定に当たって決定的に抜け落ちている観点があります 。何が抜けているのか、順をおって説明しましょう。

誰が何に困っているのか

ここで原点に立ち返って、現場で発生していることをよく見てみましょう。

申請者は、本当に困っているのでしょうか。困っているとして、何に困っているのでしょうか。

現場に行って、実際に現場で発生していることを調べてみると、例えばこのような状況に気づくことができます。

・審査期間が長すぎる
ある業務では申請を受け付けてから審査結果を返すまでに１ヵ月程度の期間を要していました。申請者は、窓口へ来訪する手間よりも、審査結果が遅いことに対して大きな不満を持っていました。

・審査結果の回答期日が不明
ある別の業務では、審査の回答期限を定めていませんでした。申請者は、いつ申請結果が返ってくるかが全くわからず、何度も窓口に電話で問合せては、その度に「現在処理中です。回答できる期日はわかりません」と返答を受けて、困っていました。

・ 申請様式が拠点ごとにバラバラ
ある企業は全国的に事業を展開していますが、申請書を提出する地方拠点ごとに申請書の様式や記載項目が異なっていました。そのため、企業内では一元的にデータを管理しているにもかかわらず、各拠点の様式に合わせて手作業で申請書を書かなければならず、手間が発生していました。

これらの例では、窓口に来なければならないことよりも、さらに深刻に困っていること がありました。電子申請を進めるだけでなく、ほかにも対策を打つべきことがありそうです。

「申請者は窓口へ来訪する手間に困っている」というストーリーは、推測に基づくものでした。現場を知らない人の 推測のみで目標を設定するのではなく 、現場の流れ、利用者の状況を調べて、本当の「困っていること」を把握することが最初の第一歩です。

利用者にも、色々な種類があるのではないか

そもそも、利用者とは誰でしょうか。先の例では、「申請者」という１つの言葉で表現していましたが、申請者の中にも、様々な種類の利用者がいるのではないでしょうか。

・本人か代理人か
実際に申請を行うのは、手続の主体となる本人でしょうか、それとも代理人でしょうか。代理人による申請の場合は、委任状が必要になるなど必要書類や事務手続が異なる可能性があります。

・個人か法人か
企業等の法人が日常的に申請を行っている場合は、１つの手続ごとに窓口にくるのではなく、ある程度まとめて一括で申請を行っているかもしれません。
また、大量の申請を行っている企業は、紙の申請書を自動出力できるように独自の情報システムを整備済みかもしれません。この場合、拙速に電子申請を進めても、紙の申請書の方が便利であるため、電子申請が使われないことになりかねません。

そのほかにも、地域別、世代別、世帯構成別など、申請者を様々な観点から分類することができます。重要なことは、 「困っていること」が異なるグループ があれば、それらの個々のグループについて、それぞれの困りごとを把握するということです。また、独自の情報システムを整備済みの企業の例のように、「困っていない」グループを把握することも重要です。

なお、この例における「申請者」のような、複数のグループを包括する名詞には注意が必要です。このように十把一絡げの形で利用者像を捉えてしまうと、特定のグループが困っていることを見落とすことになりかねません。

申請内容にも、色々な種類があるのではないか

申請内容にも様々な種類があります。申請の種類ごとに、審査の内容や必要時間を調べていくと興味深いことがわかりました。

・形式的な内容確認のみを行うもの （大部分の申請）
必須記載事項が正しく記載されているかなど形式的な確認のみを行うものが、申請件数の大部分を占めていました。
なお、さらに実態を調べていくと、実質的な確認に要する時間は僅かであり、各部門を流れていく際の待ち時間が長いことがわかりました。また、窓口で申請書類を受領した際の確認が十分でなく後日に申請者へ再問合せを行うなど、再確認作業にも相当の手間が発生していることがわかりました。

・専門の審査官による実体的な審査を行うもの （一部の申請）
一部の申請については、審査官が専門知識と経験に基づいて各種資料を総合的に確認した上で審査を行っていました。ただ、上述の形式的な内容確認も同一の審査官が実施しているため、専門的な審査に十分な時間が割けない場合があることもわかりました。

エンドツーエンドの視野で、ほかに問題はないか

業務実施部門の視点で見ると、窓口で申請を受付け、審査を行うという業務は所管業務の重要な一要素です。一方で、利用者が申請の事前、事後で作業を行っていることについては、業務実施部門の「所管外」として意識されないことがあります。

しかし、利用者の視点で見ると、事前、事後に必要となる作業も同様に重要なプロセスです。そこに、困りごとは発生していないでしょうか。

(注記:エンドツーエンドとは、利用者が、ある目的を達成するためにサービスを受ける必要があると考えた時点から、当該サービスを受けたことにより目的を達成した時点、又はサービスを享受し終わった後の行動までに生じる、利用者の感情を含めた思考や一連の行動全体のこと。)

・利用者が申請を行う前に必要となる作業
代理人が申請するときに、本人からの委任状をどのように手配しているのか・申請可能な時期を確認する・申請後にどのような順番で処理されるのか（先着順、申請期間完了後一斉処理等）

・利用者が審査結果を受領した後に必要となる作業
審査結果を別の行政機関に提出している

◇ ◇ ◇

このように、利用者視点を重視して現場で発生していることを調べていくと、解決すべき課題に様々な種類があることがわかります。

ここで例示したプロジェクトについては、目標とする成果を次のように見直すこととしました。

プロジェクトには投資が伴います。投資を行ってまで得たい成果が何なのか。それを具体的な形で明確にすることが重要です。

図2-2　目標設定の改善例

ポイント：利用者視点での目標設定には、サービスデザイン思考を！ 抜けている着眼点として、４つの事例を紹介しました。実際のプロジェクトの立ち上げに際しては、このような着眼点を検証するための サービス・業務企画の活動を先行的に行いながら、同時並行でプロジェクトの目標を定め 、プロジェクト計画書等を作成することとなります。プロジェクトの目標を定めるためには、上の例で挙げたように利用者視点に基づいた現状の把握と分析が不可欠です。これらの具体的な検討方法については 「第４章 サービス・業務企画」で詳述 しています。特に、サービス・業務企画の活動の最初に掲げている「サービスデザイン思考」については重要な観点となりますので、ぜひ本章と併せてご確認ください。

ポイント：事実を詳細につかむことも忘れずに 先ほどの例では、審査期間の短縮として原則１週間以内にするという目標を立てました。ただ、まだこの時点では、審査期間がなぜ長くなってしまうのか、その原因をしっかりつかめているわけではありません。 サービス・業務企画の活動の中では、発生している事実を詳細につかむことも非常に重視しています。実際の１件１件の審査案件を調べてみて、どこで滞留が発生しているのか、その滞留が発生する背景にはどのようなことがあるのか、そのようなことを丹念に調べていくことで初めて本当の問題点をつかむことができます。このような事実のつかみ方についても、 「第４章 サービス・業務企画」で詳述しています。 プロジェクトの立ち上げ時には、利用者が困っていることを把握した上で、その困りごとを解消するための目標を立てます。その後に詳細な現状把握を行って問題の発生原因を突き止めていくので、場合によっては目標の修正が必要になることもあるでしょう。プロジェクトの立ち上げ後は、このように現状把握を進めながらプロジェクトの目標自体も正確に見定めていきます。そして、サービス・業務企画をまとめあげる頃には、設定した目標に対して関係者の合意もとりつけて、目標を確定します。

B. 上位計画の目標をブレークダウンし、プロジェクト目標と紐づける

前述の例は、現場のニーズや困りごとに基づいて、新規のプロジェクトを立ち上げる例でした。一方で、政策や施策等、上位に当たる計画があった上で、それを実現するために情報システムを活用したプロジェクトを立ち上げるという形も、実際によくみられる形態です。また、予定されている法改正等に伴い、情報システムの対応が不可欠になるという状況もよくみられます。

このような場合、どのようなことに留意すべきでしょうか。

上位計画の目標と、プロジェクトの目標を紐づける

上位計画が長期的視点で広範囲にわたる効果を目指している場合は、その目標設定も包括的で概括的なものとなる傾向があります。例で示す方が、わかりやすいでしょう。

・児童の学力向上

・過疎地域の若年人口拡大

・地域活動への多様な人材の参画

・助成制度利用企業の売上金額の拡大

・受給権者への確実な給付の達成

これらの上位計画を達成するために、その１つの施策として情報システムを活用したプロジェクトが必要になることがあります。この場合、上位計画の「大目標」とプロジェクトの「部分目標」が実体的に紐づくべきなのですが、その過程を省略して、プロジェクトの目標も「大目標」で置き換えてしまう例が見られます。しかし、そのプロジェクトが果たして「大目標」にどれほど貢献できるのか、その効果の程度がよくわからなくなってしまいます。

目標が紐づくとは、どのような状態を指すのでしょうか。

実際の例を見てみましょう。

事例：ＫＰＩトレーサビリティ・ツリーによる目標の紐付け あるプロジェクトでは、国民向けに実施しているサービスをさらに向上させるために、政策目標（ＫＧＩ）に対して、複数の重要成功要因（ＣＳＦ）を設定し、さらに個々の重要成功要因に対して、プロジェクトの目標（ＫＰＩ）と紐付けました。 このことにより、プロジェクトが実現する個々のサービスや業務の改善内容が、全体としてどのような効果につながるかをＰＪＭＯ職員や関係者が共通に理解することができました。利用者（求職者・求人者）と職員の双方にメリットがある有効な目標を設定することができました。実際に行った作業を紹介します。 (1) 業務要件定義時点でのＫＧＩ・ＫＰＩのトレーサビリティの確保 まずは調達時にＰＪＭＯで準備し、整理してまとめておく必要がある項目・内容を、次のとおり抽出しました。 【政策目標（ＫＧＩ）】 ・ 利用者からの電子申請率の向上による、申請処理の迅速化及び事務負担軽減 【重要成功要因（ＣＳＦ）】 ・ 電子申請ページを利用しやすくする（どこにあるか見つけやすくし、ページの中身自体もわかりやすくする） 【重要成果指標（ＫＰＩ）】 ・ 利用者が目的のページに達するまでの状態遷移数：a秒未満、n画面以下 ・ 検索機能の処理能力：適合率p%以上、再現率r%以上、検索速度s秒未満 ・ 電子申請ページでの入力が完了するまでの時間：m分未満 次に、これらの項目とＫＧＩを頂点とする紐づけを作成し、ツリー（木）の構造に似た形式で整理し、関係性を明らかにしました（下図）。これにより、情報システムの調達過程で「この機能（サービス）は何のために必要なのか？」「この機能の性能が不十分だった場合、どういった業務、ＫＧＩ/ＫＰＩに影響するのか？」などが把握しやすくなり、目の前の作業だけにとらわれてそもそものゴールを見失うことを防ぎ、価値を生み出すＩＴガバナンスの実行に寄与することができました。 (2) 設計・開発時点でのＫＧＩ・ＫＰＩのトレーサビリティ確保 設計・開発時点で詳細化されていく項目・内容について、要件定義時点でのＫＧＩ・ＫＰＩのトレーサビリティ・ツリーを土台にし、同様にしてＫＧＩを頂点とした紐づけを相互に行い、ツリー（木）の構造に似た形式で整理し、関係性を明らかにしました（下図）。 【要件定義書（情報システム要件定義書）】 ・ 要件定義書名：○○○要件定義書 ・ 業務カテゴリ、業務フローの名称：ＩＤ○○○ ・ 機能（サービス）詳細： ・ 画面・帳票・バッチの名称： ・ 画面・帳票・処理要件　　など： 【基本設計書】 ・ 基本設計書名：○○○基本設計書 ・ 基本設計書の記載箇所　　など 【詳細設計書】 ・ 詳細設計書名：○○○詳細設計書 ・ 詳細設計書の記載箇所　　など 【テスト計画書・仕様書】 ・ テスト計画書・仕様書名：○○○テスト計画書・仕様書 ・ テスト計画書・仕様書の記載箇所　など 【その他】 ・ 課題管理、修正（履歴）管理 このＫＰＩトレーサビリティ・ツリーを用いて管理することにより、情報システムの設計・開発過程で「何のためにこの機能（サービス）は設計・開発しているのか？」「この機能の性能が不十分だった場合、どういった業務、ＫＧＩ/ＫＰＩに影響するのか？」などが把握しやすくなりました。 また、目の前の作業だけにとらわれてそもそものゴールを見失うことを防ぎ、価値を生み出すＩＴガバナンスの実行に寄与することができました。特に開発スケジュールの中盤を過ぎると、各開発の現場は超近視眼的になり、周囲を考慮しない作業になりがちなため、トレーサビリティ・ツリーによって全体を俯瞰した視点で作業を実施できました。

C. 削減した業務時間をどこで活かすかを明確にする

プロジェクトの目標として、職員の業務時間削減を設定することがあります。

確かに、業務に非効率な部分があり、そこをシステム化によって改善することができれば、その部分の業務時間は減るでしょう。でも、減った時間はどこに行くのでしょうか。

１つの考え方は、時間外労働を減らすということです。定常的に時間外労働が発生している職場であれば、働き方改革を推進する面からも重要な目標になります。

もう１つの考え方は、減った時間を他の業務に有効活用するということです。今までは非効率な作業に忙殺されて手がつけられていなかった重要な業務を、今後はしっかり取り組めるようになるということです。この考え方に立つならば、非効率な業務を減らす部分を数値化するだけでなく、それによってどのような新しい業務を可能にするのか、そこまで踏み込んで考えていくと、本当に役立つ目標となります。

事例：事務作業を効率化し、国民向けの対応サービスを強化 ある業務では、窓口に来訪した国民向けに様々なアドバイスをしながら、その人に合ったサービスを探していくコンサルティングを実施しています。しかしながら、来訪者が最初に記載する紙書類の処理、応対記録の作成、様々な業務分担の職員間での情報連携等、事務的な処理に多くの時間を要していたため、来訪者１人１人に向き合って対応する時間が十分でなく、多くの来訪者を待たせてしまうことにもなっていました。 そこで、まずはシステム化等により煩雑な事務作業を効率化することにしました。そして、そのことによって浮く時間を、来訪者向けのコンサルティングサービスに振り向け、サービスを充実させることとしました。

２ プロジェクトへの投資判断を行う

【標準ガイドライン関連箇所：第３編第２章第１節1)】

プロジェクトへの投資判断と、予算要求（査定）との違いがわかるでしょうか。

プロジェクトへの投資判断は、プロジェクトの目標とする成果を明確にした上で、その成果を得るために必要となる経費や人的資源等を見積り、その費用対効果を踏まえた上でプロジェクトを開始することを責任者が意思決定することです。

一方で、予算要求とは、プロジェクトへの投資判断が行われていることを前提として、翌年度以降に必要となる所要額を見積り、所要額の妥当性の観点から査定を受けるものです。確かに、予算査定過程でもプロジェクトの目的や想定効果を確認しますが、これは予算要求部局内での投資判断がなされていることを前提に、その判断結果を第三者の観点から再確認するプロセスと言えます。

ただ、この点については政府の中では誤解されがちなポイントでもあります。とりあえず予算を要求してみて、予算が通ったらプロジェクトの進め方を考えるという人も少なくないかもしれません。また、実際に新規に立ち上げるプロジェクトでは、投資判断と予算要求のタイミングが重なることも多いため、これらの違いを明確に意識しないことが多いかもしれません。

しかし、これでは、あるべき順序が逆転しています。標準ガイドラインでも、「府省ＣＩＯは、プロジェクトの新規立ち上げに当たって、目標設定及び、手段の妥当性、費用対効果を確認し、その承認を行い、プロジェクト推進責任者及び当該プロジェクトに関する情報システム責任者を指名するものとする」としています。予算要求よりも前の時点でプロジェクトを立ち上げ、府省ＣＩＯが承認することをルールとして求めています。

プロジェクトの立ち上げに当たっては、目標とする成果、その達成方法（手段）、概算での費用に基づく費用対効果を明確にして、府省ＣＩＯの承認を通して投資判断を確実に行うようにしてください。

３ 機能する体制を作る

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

プロジェクトの体制構築は、プロジェクトの命運を分ける大事な準備事項です。プロジェクトの初期に十分な体制を構築できずに、結果としてプロジェクトの円滑な運営を行えないケースは残念ながら少なくありません。

プロジェクトの体制構築についてのポイントを見ていきましょう。

A. 制度所管部門、業務実施部門等を含めたＰＪＭＯ体制とする

「ルールは変えられないから、今のルールを前提にどう工夫できるか考えよう」、「業務実施部門に業務のやり方を変えてほしいと頼んでも、聞く耳を持ってくれない」。情報システムを主として担当する組織にいると、このような会話を耳にすることがあるかもしれません。

しかし、制度面でも業務面でも今のやり方を変えないのであれば、たとえ素晴らしいシステムを作ったとしてもその効果はかなり限定的になってしまいます。

情報システムを整備するプロジェクトでは、情報システム部門が中心となると捉えられがちです。しかし、利用者視点でサービス・業務改革を推進していくためには、制度設計の責任を持つ制度所管部門、業務の実施を行う業務実施部門もＰＪＭＯに参画し、それぞれが協働してプロジェクトを進めていく必要があります。

また、制度所管部門、業務実施部門、情報システム部門を含むＰＪＭＯを組織しても、それぞれがあまり連携せずに、別々に動いてしまうことも多々あります。互いが密接に連携しなければ、実態に沿ったサービス・業務を行うための制度設計や適した情報システムを構築することはできません。

そのため、それぞれの部門が適切に情報を連携できるよう、会議やコミュニケーションのルール等を整備することも重要です。また、政策目的やプロジェクトの目標・目的を踏まえて、各々の役割と責任を確認し、サービス・業務改革の意識を醸成するための活動として、最初にＰＪＭＯのメンバー全員を集めてキックオフを実施することも大切です。

事例：制度・業務・システムの三位一体のプロジェクト体制 ある省において大規模な情報システムを運用していましたが、情報システム部門と制度所管部門・業務実施部門とは異なるロケーションにあることもあり、双方の職員がコミュニケーションを行う機会は限定的になっていました。 そのような中で、情報システムの次期更改のタイミングに合わせて、一層のサービスの向上や運用コストの削減を目的として、業務・システムの見直しを実施することにしました。プロジェクトを立ち上げた当初は、情報システム部門が中心となって検討を進めました。しかし、全体をとりまとめて推進する役割や、業務について検討すべき項目ごとの担当が不明確であったため、制度所管部門や業務実施部門からの積極的な理解が得られないなど関係者の調整が難航し、プロジェクトがうまく進みませんでした。 そこで、プロジェクトの体制を大幅に見直すこととしました。制度、業務、システムが「三位一体」となってサービスを改革することを目指し、それぞれの部門の職員を含めて統合管理チーム、業務・機能検討チーム、アーキテクチャ検討チーム等のチームを結成し、局長をトップとした意思決定組織を作ることで全体を統括した意思決定を行えるようにしました。 このような三位一体のプロジェクト体制を構築したことで、各部門の職員がコミュニケーションを緊密に実施できるようになり、解決すべき問題が発生したときにも幹部まで問題内容がエスカレーションされて意思決定を行えるようになり、円滑にプロジェクトを運営できるようになりました。

B. プロジェクトの規模に見合った体制を組む

利用者や関係者が多いプロジェクトでは、情報システムの１つの機能を決めるに当たってもきめ細かな調整が必要になりますし、情報システムを運用する中で利用者からの問合せや要望等に応えながら情報システムを改善していく業務にも大きな労力が必要です。また、多額の経費を投資するプロジェクトでは、情報システム構築や運用が事業者任せにならないように、情報システムの構成や運用状況を常時把握して、課題への対応方針を決め、必要となる経費の妥当性を判断することが必要になります。

このような業務を円滑に実施していくためには、ＰＪＭＯに担当者を十分に配置することが不可欠です。

参考：ＰＪＭＯの主要業務 プロジェクトがどのような段階であるかによっても異なりますが、ＰＪＭＯには様々な業務に対応することが求められます。代表的な業務を例示します。 ＜総括＞ ・ プロジェクトの立上げ、体制確立、組織運営ルール作成、執務環境整備 ・ 調達計画作成、見積り依頼、見積り精査 ・ 予算要求資料作成、予算に関する関係者折衝 ・ 政府全体方針、各省方針等との整合確認、各計画のフォローアップ対応 ・ 監査等への対応 ・ プロジェクトのモニタリング ＜企画＞ ・ 利用者のニーズ把握、利用者調査、要望やクレーム等の分析 ・ 業務の現状把握と分析、業務フロー等の可視化、実績データ分析 ・ 利用者分析、業務分析結果を踏まえたサービス・業務企画 ・ 今後の改善内容について、他府省、他組織等との折衝 ・ 外部関係者を交えた検討会、内部職員での検討会議等、各種会議運営 ・ 企画内容のとりまとめ、関係者への説明 ・ 業務要件、機能要件、非機能要件等の各種ドキュメントの作成 ＜調達＞ ・ 調達仕様書等の作成、評価基準や評価体制の準備、会計担当部門との調整 ・ 提案評価、プレゼンテーションの審査 ＜開発管理＞ ・ 開発事業者の実施計画の確認・承認、スケジュール等の詳細調整 ・ 課題調整会議等での課題管理・調整、進捗報告会議等での進捗管理 ・ 設計等各種会議での検討、関係者の合意形成、設計書等各ドキュメントの承認 ・ 外部組織等との設計内容、連携方式、テスト方式等の調整 ・ テスト計画、テスト実施結果等の作成、確認 ・ 移行計画、移行作業等の実施、運用計画・保守計画の作成 ・ 利用者への事前連絡、マニュアル作成、研修等の実施 ＜業務運営、保守と運用＞ ・ 業務実施状況の確認、課題要望管理、プロジェクトの目標達成状況モニタリング ・ システムの運用（監視アラート対応、バッチ処理、バックアップ、定期作業等） ・ アプリケーション保守（要件確認、テスト結果確認、リリース管理等） ・ 利用者・関係者との調整、利用状況確認、利用上の問題発生対応 ・ システム障害への一次対応・根本対応、インシデント管理 ・ ヘルプデスク等での問合せ受付、ＦＡＱ等のとりまとめと更新 ・ アクセスログ等の分析、指標管理、改善点検討 ・ ソフトウェア等のサポート期限等の管理、パッチ等の適用 ・ コスト削減の検討、今後のシステム改修や次期システム更改に向けた検討 システムの規模にもよりますが、このような多種多様な業務をこなすには十分な数の職員を専任でＰＪＭＯに配置することが必要になります。

ＰＪＭＯに十分な数の職員を配置できないと、どのようなことが発生してしまうでしょうか。人数が少なかったり、他の仕事と兼任でＰＪＭＯの仕事に専念できないと、予算要求や調達等の必要不可欠な作業を実施するだけで精一杯となり、利用者分析、現状分析、要望分析、実績データ分析等の本質的な業務にまで手が回らなくなります。その結果、システムだけは出来上がっても、想定していた効果を出すことができません。

例えば、次のように「本末転倒な」事態が発生してしまいます。

・サービス利用者が不便を感じる
情報システムの画面構成がわかりにくく、ヘルプデスクに問合せを行っても混雑して電話がつながらず、申請した手続がいつ回答されるかがわからない・・・。ＰＪＭＯの体制が少ないと事前分析が不十分になるため使いにくい情報システムができてしまい、そのサポートも十分にできないといった形で、サービス利用者に大きなストレスをかけてしまいます。

・業務実施部門の業務効率が悪化する
情報システムに機能が不足していて、システム外の手作業で様々な追加作業を行う必要がある、情報システムにトラブルが頻発してなかなか解決されない・・・。現場で発生している課題を解決するための情報システムであるはずなのに、逆に業務実施部門の負担を増やしてしまいます。

・ＰＪＭＯの担当職員が疲弊する
利用者や業務実施部門からの要望や苦情に追われる一方で、システム関連事業者からは対応が難しいと主張される・・・。このように板挟みの状況の中で、仕事が山積みになり担当職員が疲弊してしまいます。

・使われない情報システムに、経費ばかりがかかる
システム関連事業者への依存体質が定着してしまい、小規模なシステム改修にも多額の経費を請求され、その経費妥当性を担当職員が判断できないため事業者の見積金額のまま予算要求をせざるを得ない・・・。利用者から業務実施部門から評判の悪い情報システムにもかかわらず、経費だけは膨らんでいくという事態になりかねません。

プロジェクトにトラブルが起こり始めてから担当職員を追加しても、なかなか本質的な解決はできません。例示したような事態を避けるためには、プロジェクトを立ち上げる当初からＰＪＭＯに十分な体制を準備することが不可欠です。

では、何人の体制を準備すればよいか。それは、関係者の多さやプロジェクトの特性によるので一概には言えません。実質的に１人の職員で回すことができる小規模プロジェクトもありますし、100名以上の体制を組む大規模プロジェクトもあります。

ただ、毎年数億円や数十億円といった経費を使う大規模プロジェクトにもかかわらずＰＪＭＯの人数が数名しかいないという体制も見受けられますが、それではさすがに人数が少なすぎるように思います。恐らく、このような体制ではシステムの運用維持や必要最小限の予算要求と調達を実施することで忙殺されてしまい、とても利用者の要望に応えながらサービス・業務の改善点を検討するような時間を捻出できなくなってしまいます。制度所管部門、業務実施部門等の職員を加えて、ＰＪＭＯの体制を強化することが望まれます。なお、内部人材で体制を確立するだけでなく、ＩＴ業界等での経験がある外部人材を任期付職員等の形で採用しているＰＪＭＯもあります。

プロジェクトの規模や特性によって差異はありますが、ＰＪＭＯに数名の職員を追加したとしても、業務実施部門の業務効率を考えるとその何倍もの効果があるはずです。また、情報システムの経費面でも大きな効果があるはずです。プロジェクトが目指す成果に応じて、その成果を達成するために十分な体制を組むことが、結果としてサービスの向上と行政の効率化につながるといえます。

また、ＰＪＭＯの体制を組む際には、ＰＭＯやＣＩＯ補佐官にも相談してみてください。重要なプロジェクトについては、ＰＭＯ職員やＣＩＯ補佐官も直接ＰＪＭＯ体制に含めて、定例会で情報を共有したり、課題への解決方法を一緒に検討したりすることもできます。また、大きな問題が発生しているときには、ＣＩＯ、副ＣＩＯへ相談を持ち掛けやすくなり、早期に問題への対応を行えるようになります。

C. 他組織と連携できる体制を作る

利用者視点、つまり利用者にとってエンドツーエンドの観点でサービスを改善するということは、裏を返すと多くの組織にまたがって業務を見直すことにほかなりません。

ＰＪＭＯには制度所管部門、業務実施部門を含めた体制としています。ただ、ここでいう制度所管部門、業務実施部門とは、あくまでプロジェクトの「中心」となる制度や業務を担当する部門です。利用者の視点でサービスを見渡すと、これらの部門以外にも様々な組織が直接的、間接的に連携していることがわかります。これらの関係者については、プロジェクト管理要領でステークホルダーとして定義した上で、プロジェクトへの関わり方を決めていきます。

さて、ステークホルダーと一口で言っても、同じ省内の他局である場合もあれば、他府省、他組織（民間企業、自治体、独立行政法人等）であることもあり、様々な関係者が存在します。実際には、これらの組織を横断して問題提起を行い、解決方策をまとめることは大変難しいものです。しかし、関係する組織間の調整や協力を行わずにプロジェクトを進めても、サービス・業務改革は成し得ません。

ステークホルダーの多いプロジェクトを円滑に進めるためには、次のことが特に重要となります。

・各組織の責任者の連携体制を作る
プロジェクトの普段の活動では、各組織の担当者間で調整を行います。ただ、調整が難航した際に、担当者レベルで検討が止まってしまうということが往々にして発生しがちです。
この点は重要なので、強調します。実際に多くのプロジェクトで、このような 担当者レベルでの検討停滞が頻発しています 。「うちは基盤システムだから、個々の情報システムへの個別対応は行わない」、「今回例外対応を認めると先例になるため、そのような対応は行わない」、「当方の所管範囲を超えることなので、何もできない」、このように様々な理由を述べながら、担当者レベルで検討が停止してしまうという事態は頻繁に発生します。
組織をまたいで業務改革を行うためには、このような停滞が発生したときに問題解決の場を一段、二段と上に上げて、各部門の責任者レベルで対応方法を検討できるようにすることが有効です。プロジェクトの体制として関係部門の責任者を明確に記載した上で、状況に応じて 責任者本人が会議に出席して調整や意思決定を行う場を作ることが重要です。

・発生した課題をエスカレーションできる仕組みを作る
上記のような責任者による連携体制を機能させるためには、プロジェクトの普段の活動の中で、以下の両方のルートを確立することが必要です。
１つ目が、ＰＪＭＯ自身の課題管理を起点とするルート です。各ステークホルダーとの折衝状況や発生課題を管理し、解決が困難な課題についてはＰＪＭＯからエスカレーション（上位者への情報連携）を行い、関係する組織の責任者との折衝を行います。
２つ目が、関係する各組織からの意見を起点とするルート です。プロジェクトの検討内容やＰＪＭＯのプロジェクト推進方法に課題があると認識した際に、各組織からＰＪＭＯやステークホルダー全体に対して意見提起を行えることが必要です。
特に、２つ目のルートについては明示的に設定されていない例も多く見られます。しかし、関係する各組織がプロジェクトに対して課題や不安を抱えたまま、その状況を正式に伝える窓口が存在しないと、その課題が解決されないままにプロジェクトが進行してしまいます。課題、要望、意見等について提起を行える連絡窓口や連絡方法について明示的に設定するとともに、集まった意見等については定例会議等の場で意見交換を行える仕組みを作ることが望まれます。

・状況を早期に関係者へ共有する
プロジェクトを推進するＰＪＭＯ側の立場では、様々な情報について検討段階で関係者へ共有するのではなく、正式決定後に初めて共有するというやり方になってしまいがちです。事前に共有した情報に変更が発生すると、変更内容の再連絡や意見調整に手間がかかるということが、その一番の理由でしょう。
一方で、プロジェクトの影響を受ける関係者側の立場では、 検討段階でも構わないので現時点の検討概要を早く知りたい と考えることが多くなります。「自身が管理する情報システムの改修が見込まれるため、影響範囲を調査するために現時点の要件定義内容を知りたい」、「テスト計画を作成するため、現時点のインタフェース設計内容を知りたい」、「体制を組むために、テストの実施時期や内容を知りたい」等、理由は様々ですが、検討中の内容を早く知りたいというのが関係者側の強い要望となることが多いです。
このような要望が発生することを踏まえて、関係者に影響を与える検討内容については、 この内容が検討中のものであるというステータス情報と今後の検討スケジュールを明確にした上で事前共有を行い 、関係者からの意見も取り込みながら最終的に正式内容を共有するといった形で、数度にわたって段階的に行うことが望まれます。
また、大規模なプロジェクトでは提供するドキュメントが多量になるため、ドキュメントを種類別、内容別等で検索しやすくするような情報共有ツールを活用することも有効です。

事例：情報共有ツールによる関係者への情報共有 あるプロジェクトでは、各府省に多数の利用者や関係者がいるため、情報共有ツールを導入しました。 このツールは、Webブラウザ上でファイルサーバのようにファイルを共有することができ、このツールのＩＤを持っている職員は各府省のＬＡＮ端末からすぐにアクセスすることができます。このツールに、関係者向けに開催する会議資料、設計書やマニュアル等のドキュメント、各組織とのやりとりに用いる連絡票や課題管理表など、関係者の権限に応じて様々なドキュメントを参照、検索できるようにしました。このツールによって、過去の資料でも簡単に検索することができ、関係者間の情報共有が非常に便利になりました。 また、ある別のプロジェクトでも、政府内部だけでなく民間企業、自治体等の多数の外部関係者に影響を与える大規模な計画内容であったため、ＩＤを持っている人はインターネット経由で同様に各種ドキュメントを検索できるツールを導入しました。 多くの関係者が存在するプロジェクトでは、会議の度にメール等で資料を送付するような方式では、資料を受領する側でも資料全体を管理しきれません。このような情報共有ツールは比較的安価に導入でき効果も大きいので、利用することを検討してみてください。

事例：原則にとらわれない環境作り インターネットを通じたコミュニケーションツールは、「約款によるサービス」にあたるため原則利用が禁止されています。しかし、目的に鑑み、リスクが少ないと情報セキュリティ責任者が判断できれば、ツールを利用することは可能です。 あるプロジェクトでアジャイル開発を推進するにあたり、複数の府省と民間企業十数社が参画する体制で、関係者間で密にコミュニケーションを図る必要がありました。特にこのプロジェクトではアジャイル開発を採用して短期間で機能開発や改善を進める必要があるため、職員と開発事業者が、柔軟にコミュニケーションをとれる体制が不可欠でした。そこで、このプロジェクトではコミュニケーションツールの利用目的を明確にした上でリスク評価を行い、情報セキュリティ責任者判断のもとでツールを導入し、アジャイル開発に求められる早いサイクルでの設計、開発、評価の繰り返しをスムーズに行うことができ、利用者の満足度が高いシステムを構築できました。 「原則禁止」、「前例がない」というだけで選択肢をせばめてしまうのではなく、目的達成のために有用な手段なのであれば、その手段を利用するリスクについて評価を行った上で、その利用について情報セキュリティ責任者の承認を得ることを検討しましょう。まずはサービス・業務目的をどうすれば効率的かつ効果的に達成できるかからはじめ、十分に検討したうえで「前例を作っていく」ことが重要です。

D. 先行経験を持つ人のノウハウを活用する

多くの人が同じ苦労をするというのは、とても非効率な状態です。

ただ、システムの導入順序や体制をうまく整備しないと、こういった無駄なことが起こってしまいます。なぜだかわかりますか。

例えば、全国100拠点に全く新しいシステムを一斉に導入するとします。各拠点で、今までは紙で事務処理していた作業を、今後は新しいシステムで実施することになりました。

ところが、現場には様々な例外処理があります。登録済の内容を過去に遡及して修正するにはどうすればよいか、月末までに処理を間に合わせてほしいという希望にどう対応するか、今までは紙処理で当たり前のように実施していた業務を、システムではどう実施すべきなのか、各拠点の職員はそれぞれが同じような問題に突き当たり、その解決策をそれぞれが苦労しながら考えます。その結果、拠点によって事務処理方法やシステム利用方法もバラバラになってしまい、拠点間を人事異動した職員が業務実施方法の違いに戸惑うような状態になってしまいます。

もちろん、システムの企画、要件定義、設計等の段階で、業務での例外処理も含めたあらゆる状況を想定してシステム機能を作り、業務マニュアル等を充実させるのが理想的な状態です。ただ、このようにあらゆる状況を想定し尽くせなかったとしても、体制面で工夫を行えるのです。

まず、先行的に数拠点の現場で、システム導入を実施します。そして、その拠点でシステムへの対応方法を経験して様々な例外処理等への対応方法にも知悉した職員のノウハウを、他の拠点でも活かすのです。他拠点の職員にとっては初めて遭遇する問題でも、最初の拠点の職員にとっては既に馴染みのある問題であることが多いでしょう。非常に効率的に、問題を解決し、対応方法を決めることができるようになります。

このような機動的な体制を組む際の障害は、人事面でしょう。地方拠点の職員を、システムの導入状況に合わせて次々に人事異動させていくのは現実的には困難かもしれません。ただ、人事異動までは行わなくても、短期間の出張での対応でもかまいませんし、電話やメールでの相談だけでも良いかもしれません。

重要なことは、組織の縦割りでの役割分担にとらわれず、先行経験を持つ人のノウハウを後続での作業に活かしていくことです。

事例：府省を跨った特別移行支援チーム ある府省共通システムでは、府省単位で移行スケジュールを決めて段階的に当該システムへの移行を進めていました。移行に際しては、移行計画の作成、データの整備、エラーへの対応など様々な作業が必要になりますが、初期の段階では各府省の担当者がそれぞれに苦労しながら移行作業を進めていました。しかし、このような体制では、各府省で苦労をした人の経験が今後移行をする府省には受け継がれません。 そこで、府省を横断した形での「特別移行支援チーム」を結成することとしました。このチームには、このシステムへの移行経験や業務実施経験が豊富なベテラン職員を十数名配置しました。なお、これらベテラン職員は、当然ながら各府省においても重要な戦力なので、移行支援だけに専念することも困難でした。そこで、各府省においては従来の業務も実施しながらこの特別移行支援チームの業務もできるように、体制を工夫しました。 この特別移行支援チームは、これから移行を行う組織の職員向けに何度も勉強会を開催したり、個別の相談に乗ったり、様々な支援を行いました。 その結果、短期間で効率的に、全府省がこのシステムへの移行を完了することができました。

Step.3 プロジェクト計画書等の作成

プロジェクトの目標とする成果や体制等を決めた後は、今後のプロジェクトの実施方法を検討し、プロジェクト計画書、プロジェクト管理要領として明文化します。プロジェクト計画書はプロジェクトで「実施する内容とその目的・目標」を記すのに対して、プロジェクト管理要領はその「実施に係るルール」を定義するものです。

プロジェクト計画書は、プロジェクトのライフサイクルを通じて達成すべき成果を明確にし、各工程における意思決定や関係者との合意における指針として参照することにより、プロジェクト本来の目的に対して最大の成果を発揮することを目指す上で欠かせないものです。

情報システムのプロジェクトは長期に渡り、また多くの組織や担当者が関わるため、実施するプロジェクトの目的や内容に関して明文化されたプロジェクト計画書を拠り所にすることで、主要なステークホルダー間で共通理解を形成することが必要です。またどのようなプロジェクトであっても、途中段階で要件変更等を余儀なくされることがありますが、そうした場合でもプロジェクト計画書に明記された本来の目的を見失わず、目標を達成できているかモニタリングと改善を繰り返すことにより、政策目的実現のために最大限の成果を発揮することが可能になります。このように、プロジェクトのライフサイクルを通してプロジェクト計画書を中心に据えた考え方に基づいてプロジェクト運営を推進することにより、手戻りを減らし、さまざまな制約がある中でも目的に対して最大の成果を発揮することを目指します。

プロジェクトには外部関係者（利用者、案連する公的機関や民間企業等）、内部関係者（システムの利用者となる職員、関連する各部門）、内部の推進体制（各省PMOや、内閣官房IT総合戦略室、総務省行政管理局等）、プロジェクトに関連する各種事業者等、様々なステークホルダが存在します（第2章プロジェクトの管理　３　機能する体制を作る　Ｃ．他組織と連携できる体制を作る　を参照）。これらの多種多様な関係者、そしてPJMO内部の職員も含めて様々な局面で合意形成を図る際に、プロジェクトの目標や推進状況を的確に説明するための中心となるのがプロジェクト計画書です。プロジェクト計画書の記載の中から、個々の関係者が知りたい内容を抜粋して伝えることができるように、原典となる方針や進め方をプロジェクト計画書に一元的に集約することで、プロジェクトの姿を矛盾なく効率的に説明できるようになります。

プロジェクト計画書及びプロジェクト管理要領の２つのドキュメントについて、記載項目やポイントとなる点を 見ていきましょう。

１ プロジェクト計画書を作成する

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

プロジェクト計画書を中心に据えたプロジェクト運営を推進するためには、プロジェクト計画書を適切に作成・更新していく必要があります。

この実践ガイドブックには、別添としてプロジェクト計画書のひな形を示しています。

様式例：プロジェクト計画書のひな形 プロジェクト計画書のひな形を本章別紙としてまとめています。

このひな形はあくまで例示ですので、プロジェクト内容に応じて記載内容を個別に追加、変更してかまいません。

以降では、プロジェクト計画書を作成するときに、特に注意が必要なポイントについて説明していきます。

A. プロジェクト計画書は段階的に詳細化する

プロジェクト計画書は定義する内容が多く、作るのが大変そうだという印象があるかもしれません。たしかに、プロジェクトは、長期間にわたって多数の活動を行うため、全ての活動を隅から隅まで定義するのは大変労力がかかります。

でも、安心してください。プロジェクト計画書は、最初から全ての計画の詳細を記載するものではなく、段階を踏んで徐々に詳細化していくものだからです。初期の段階のプロジェクト計画書は、各項目についての概要を記載した上で、各項目の詳細化を行うタイミングを計画します。

図2-3　プロジェクト計画書の段階的な詳細化のイメージ

なお、プロジェクト計画書を詳細化していくと記載量が増加していきますので、１つのドキュメントとして維持していくと、少し読みにくくなってしまいます。

そこで、詳細化を行う中では、別紙構成としたり、サブプロジェクト計画書を切り出したりといった形で、プロジェクト計画書の本体に追加していくことを推奨します。プロジェクト計画書の本体には、追加した記載内容の要点と別紙への参照を記載していきます。こうすることで、プロジェクト計画書は詳細化が進むにしたがってプロジェクト全体の概要を示す目次のようになっていきます。

図2-4　詳細化されたプロジェクト計画書のイメージ

ただし、詳細化の結果として、計画全体に係る変更がある場合は、変更管理の手順に従った上で、その内容を各項目に反映していく必要があることを忘れないでください。

また、プロジェクトの実務作業が忙しくなっていくと、プロジェクト計画書の更新がなおざりになってしまうこともあります。しかし、プロジェクト計画書が更新されていないと、人事異動等で新しい担当者が着任した際に現在の状況や正確な内容がわからず、その後のプロジェクト活動に影響を与えてしまいます。

プロジェクト計画書は詳細化や変更発生の都度更新していくことが望ましいですが、四半期や半期等の周期でも、プロジェクトの最新の状況が確実に反映されているかを確認するようにルール化しておくことも効果的です。

参考：補正予算で開始するプロジェクト 補正予算で新規に情報システムの構築を行うプロジェクトには注意を要します。 補正予算の場合、当該年度内で執行が完了することが必須となるため、プロジェクトの計画に大きく影響します。補正予算で新規に情報システムを構築することは推奨しませんが、実施する場合は以下の点に気をつけてください。 ・ 予算要求時点では見積りの精査が難しいが、可能な限り精査した上で要求する。 ・ 予算要求時点では見積りの精査が難しいため、予算執行時までに必要経費を精査できるように計画する。 ・ 補正予算で整備したハードウェア、ソフトウェア、アプリケーション等には、整備年度以降もランニングコストが発生することに留意し、ライフサイクルコスト全体で費用対効果を判断する。 ・ 要求内容の優先順位付けを事前に行い、問題が発生したときに対応できるように準備する。 ・ 設計・開発の期間が限られることから、サービス・業務企画や要件定義が十分に行われていないケースも散見されるため、サービス・業務企画や要件定義を行う体制、期間と時間等を十分に確保する。

B. 抜け漏れのない実施計画を作成する

プロジェクトの立ち上げ当初は、実施計画（スケジュール）についても概略でかまいません。プロジェクトで実現する事項も大きなカテゴリ単位となりますし、時間軸についても月単位や四半期単位等、概略での作業時期をプロットする形でかまいません。実施計画も、段階的に詳細化していくものです。

実施計画の例を図2-5に示します。

図2-5　実施計画の例

実施計画から漏れやすい作業に注意

実施計画を作成する際には、ＰＪＭＯが責任範囲を持つ部分のみで計画を立てがちですが、影響を受ける側（業務担当職員、連携先システム、移行元の既存システム等）も含めた全体的な計画が必要です。

実施計画から抜けやすい作業項目を次に示します。実施計画を段階的に詳細化する際に、このような作業が漏れていないか確認してみてください。

計画から抜けがちな作業項目

・

関係者との要件や仕様の調整、確定作業
システム連携等で影響を与える関係者に対して、要件定義内容や設計仕様を調整し、確定した要件、仕様として双方での合意を形成する作業
（マイルストーンとして、いつまでに「確定」するかを関係者で事前合意することが重要）

・ データ移行関連作業
既存情報システムからのデータ移行、既存データの整備（クレンジング）作業、紙にしか存在しないデータのパンチ入力作業
(注記:クレンジングとは、データベースのデータやファイル等に存在している、不要なデータの削除や、不整合なデータを整合性が合うように修正する作業のこと。 )
(注記:パンチ入力とは、データを情報システムに人の手で入力する作業のこと。（以前はコンピュータにデータを登録するためには、専用のカード（紙）に孔をあけて（パンチ）読み込ませていたことに由来する。）

・ テスト関連作業
現行システムと新システムで処理結果を比較する実データテスト、連携先情報システムとのデータ連携テスト、システムの性能を確認するためのストレステスト等（総合テスト、受入テストの中で、このようなテストが確実に含まれているかどうか）

・ 移行リハーサル
業務実施部門による業務移行リハーサル、情報システム部門によるシステム移行リハーサル（社会的な影響が多いシステムでは、数度のリハーサルを経た上で本番切替を行うことが多い）

・教育、研修、利用者サポート
利用者（国民等）への利用マニュアルの作成、職員向けマニュアルの作成（業務面、システム操作面）、職員向けの研修実施 （業務面、システム操作面）、ヘルプデスクの準備・運営

・利用者への連絡やプロモーション
新サービス開始についての利用者・関係者への事前連絡、自府省Webサイトや広報媒体を活用したプロモーション

・業務を実施する環境の変更
業務フロー変更に伴う窓口の配置変更や移転に伴う工事の調整

・運用段階での利用状況分析、効果測定
アクセスログや処理件数等から利用状況を把握し、業務・システムの改善を図る。また、プロジェクトが目標としていた成果に対して、実績としての効果を測定する。
（効果を測定するための分析機能を、システム開発範囲に盛り込んでおくことが重要）

２ プロジェクト管理要領を作成する

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

このステップの冒頭でも説明しましたが、プロジェクト計画書はプロジェクトで「実施する内容とその目的・目標」を記すのに対して、プロジェクト管理要領はその「実施に係るルール」を定義するものです。

この実践ガイドブックには、プロジェクト管理要領についても別添としてひな形を示しています。あくまでこのひな形は例示ですので、プロジェクト内容に応じて記載内容を個別に追加、変更してかまいません。ひな形を見ると、何をどのようなレベルで書くべきかの参考になると思います。

様式例：プロジェクト管理要領のひな形 プロジェクト管理要領のひな形を本章別紙としてまとめています。 様式例2-2　プロジェクト管理要領のひな形

以降では、プロジェクト管理要領を作成するときに、特に注意が必要なポイントについて説明していきます。

A. 問題に対処できる会議体を構成する

会議体の構成は、プロジェクトの工程によって変わっていきますが、基本的には次のような定例的な会議を主軸としながら進めていきます。

実際の会議体では、複数の会議機能を１つの会議で集約することも多いですが、会議の機能として次のようなものが漏れていないか確認してみてください。

会議体の構成例

・ 仕様検討会議 （要件定義、設計）
現場で業務を実施している職員等の意見を反映しながら、業務の改善ポイントやシステムに求める機能などを詳細に決める会議です。業務の種類やサブシステム単位で複数の会議を設定することもよくあります。名称については、検討ＷＧ（ワーキンググループ）、作業部会、分科会等の名称になることもあります。
重要なことは、これらの会議において業務実施部門の職員自らが仕様を決定することです。業務を実際に担当している職員の現場感覚がなければ、業務に役立つ良い情報システムは作れません。

事例：業務実施部門が参加しなかったプロジェクト あるプロジェクトでは、システム開発事業者が提示した設計内容案に対して業務実施部門の職員が形式的な確認しか行わず、システムのテスト時点で「こんなシステムは業務に合わない」と業務実施部門がクレームを行うということが発生しました。しかし、設計内容は既に確定しているため、業務実施部門の要求を実現するためには、さらに改修等が必要となってしまいました。 このような事態になってからでは、後戻りすることは困難です。情報システムの要件定義や設計内容（特に情報システムの機能に関わる部分）は、業務実施部門が責任を持って決定する必要があります。

・連携調整会議 （要件定義、設計）
システム連携等で他システムとの調整が必要な場合に、システムの連携仕様やテスト実施方法等を詳細に決める会議です。
システム連携の調整は、連携仕様そのものを決めるだけではありません。連携データの量（ピーク時の最大処理件数等）、連携データの種類（最新歴だけか、過去歴も含むか等）、連携エラー時の処理（代替処理、エラーメッセージの出し方等）、連携テストの実施時期、運用時の対応体制等、様々な調整事項を決める必要があります。また、一度決定した連携仕様を変更すると関係者への影響が大きいため、連携仕様の決定は慎重に行う必要があります。これらの点を考慮して、仕様調整会議では十分な調整期間と体制を確保することが望まれます。

・テスト調整会議、テスト確認会議 （テスト）
テスト工程では、テスト計画書の内容を確認した上で、各種テストを実施し、テスト結果に応じて対応を行います。また、総合テストまでの工程では、開発事業者が主体としてテストを実施しＰＪＭＯはテストの実施状況を確認しますが、受入テストでは業務実施部門を含めたＰＪＭＯの職員自身がテスト計画を作成してテストを実施します。
特に複数のプロジェクトにまたがるテストを実施する場合は、テスト内容、テスト実施時期、テスト実施環境、テスト体制等の調整を慎重に行う必要があるため、やはり十分な調整期間と体制を確保することが望まれます。

・進捗報告会議、定例報告会議 （全工程）
システム関連事業者の作業報告を含めて、プロジェクト全体の状況を確認する会議です。システムの開発工程では「進捗報告会議」、システムの運用工程では、「システム運用定例報告会議」、「アプリケーション保守定例報告会議」等の形で開催することが多いです。
システム関連事業者ごとに月１回程度の進捗報告を求めることが基本的な形ですが、多数の事業者が関係するプロジェクトでは、事業者単体での進捗報告会議に加えて事業者全体での「全体進捗定例会議」を開催することで、事業者間の情報共有を図ることもあります。

・課題調整会議 （全工程）
課題管理表をベースとして、課題の発生状況と対応状況を確認し、対応が停滞している課題に対してはシステム開発事業者の作業進捗状況を確認する会議です。
システム開発事業者ごとに月１回程度の進捗報告を求めることが基本的な形ですが、多数の事業者が関係するプロジェクトでは、事業者単体での進捗報告会議に加えて事業者全体での「全体進捗定例会議」を開催することで、事業者間の情報共有を図ることもあります。

・変更管理会議 （全工程）
確定した仕様に対する変更要求、実装済の機能に対する変更要求、システムの運用手順に対する変更要求等に対して、変更の可否を決定する会議です。
変更が発生した際に必要となる会議であるため、定例的な会議として運営するというよりは、臨時的な会議として開催することが基本的です。また、他の会議体（仕様調整会議、連携調整会議、テスト調整会議、課題調整会議等）で、この会議の機能を包括することもあります。

・ＰＪＭＯ情報共有会議 （全工程）
ＰＪＭＯの全職員を集めた全体定例会議、ＰＪＭＯの中でリーダーとなる職員を集めたリーダー会議等、ＰＪＭＯ内での情報共有を行う会議です。
プロジェクトの中では、特定の人しか状況を知らないという「情報の局所化」が発生しやすいので、月次、週次等で定例的に会議を開催することが有効です。

なお、プロジェクトで発生する問題の全てを、ＰＪＭＯの体制下で解決できるわけではありません。問題の大きさに応じて、自府省の幹部職員に状況を伝達し、幹部レベルでの問題対応を図ることが必要になります。また、問題が発生した時だけ幹部に相談する形では情報共有が不十分になりがちなので、常日頃からプロジェクトの計画内容、進捗状況、重要課題を関係する幹部職員が把握できるように進めていく必要があります。

プロジェクトの影響度や重要性に応じて、幹部職員への連絡会議を設定するなど、幹部から定期的な関与が得られるように調整を行うと良いでしょう。

事例：幹部職員への定期的な報告 あるシステムでは、システム稼働開始後に様々な問題点が発生したため、抜本的な改善を行うこととしました。この抜本改善の過程では、次のような形で幹部職員への情報共有を行っていました。 ・ ＰＪＭＯの担当参事官、当該府省の副ＣＩＯ、関係組織（内閣官房等）との情報共有 ・ 会議を実施（抜本改善の中心時期には毎週１回 、改善後の時期も月２回開催） ・ 上記打合せを開催した週のうちに、 事務次官、官房長（ＣＩＯ）にも直接状況を報告 このように頻繁に幹部職員への情報共有を行うことで、プロジェクトを推進する中で発生した問題を早期に幹部に伝え、対応を素早く行うことができるようになりました。

B. 本質的なリスクを事前に予見して、対応を準備する

リスク管理については、リスク管理表等のドキュメントは一通り作成しているものの、実際のプロジェクトの中で役立てているケースはまだ少ないようです。

しかし、実際にはプロジェクトを進める中で様々な問題が顕在化しています。問題が起こってしまってから対処方針を考えても、予算面や既存の契約条件面等から制約が大きく、抜本的な対応を行うことが困難になります。

やはり、それらの問題が発生しないうちに 事前にリスクとして認識し、必要な対応を準備しておくことが重要となります。

プロジェクトを進める中で発生しやすいリスクとその対応方法について、例を示します。わかりやすさのために、大きく「品質」、「コスト」、「納期」の観点で分類していますが、必ずしもこの分類で考える必要はありません。プロジェクトの特性、実状に応じて、本質的に対応が必要となるリスクを、事前に考えてみてください。

品質に関するリスクと対応方法の例

・ 多数の事業者間をまたいだシステム障害が発生するリスク
多数の事業者が参画する体制（マルチベンダー体制）においてシステム障害が発生した際に、各事業者が自身の責任範囲ではないことを主張し、問題を主体的に解決する主体が存在しないことによって、原因究明や対応実施が長期化するというリスク。

→リスクを軽減するためには、プロジェクト全体を統括する品質管理チームをＰＪＭＯ職員と特定事業者によって構成する等の対応が考えられる。プロジェクト内でシステム障害等の問題が発生した際には、この品質管理チームが問題解決を統括し、複数事業者をまたがる問題についても問題の切り分けと問題対応者（事業者）の決定を行う。また、各事業者が品質管理チームの指示に従って必要な対応を行うことをプロジェクトのルールとしても明示する。

・個人情報等の重要情報が漏えいするリスク
個人情報等の重要情報について、本来は参照権限がない利用者が参照してしまったり、外部へ流出してしまったりといった漏えいが発生するリスク。

→本番稼働前の段階においてリスクを軽減するためには、情報セキュリティの専門経験を持つ要員によるセキュリティ設計を行い要件定義で定めた情報セキュリティ対策要件の充足性を確認するとともに、実作業の中でも本番データを扱うテストにおいて氏名等の重要情報をマスキング（匿名化）した形で実施するなど、万一の情報流出時にも影響範囲を限定化する対応を行う。

→本番稼働後の段階においてリスクを軽減するためには、運用計画や運用実施要領等の中で重要情報を扱う際の手順を明確に示した上で、実際の実施状況について定期的に確認することや、セキュリティ監査の実施計画を立てて監査の実施とフォローアップを行う等の対応を行う。

コストに関するリスクと対応方法の例

・ システムの機能追加に関する要望が多発するリスク
開発段階や運用段階において、業務実施部門の職員等からシステム機能に対する改善要望が多発する一方で、予算範囲内では対応できる範囲が限定されるため、業務実施部門とシステム機能に対する合意が形成できなくなるというリスク。

→開発段階に入る前（調達を行うまで）の段階でリスクを軽減するためには、要件定義内容を詳細に業務実施部門に提示し、システム導入後の業務実施方法を具体的にイメージできる状況の中で、必要となる機能のフィードバックを受ける等の対応を行う。また、特定のユーザに固有の少数要望についてはシステム本体ではなく簡易な外部ツール等で対応できるようにして、そのための予算化も事前に行うことも考えられる。

→開発段階でリスクを軽減するためには、要件定義や基本設計段階においてプロトタイプを作成して業務実施部門の職員がシステムの動きを詳細に理解できるようにする等の対応を行う。また、一方で各職員の個別要望だけでシステム機能が増え過ぎないように、システムのコストや保守性等も勘案した上で機能要件を増やすことの判断を業務実施部門が組織的に行うルールを導入することも考えられる。

→運用段階でリスクを軽減するためには、毎年の予算要求に間に合うように改修要望のとりまとめ方法をルール化するとともに、改修対象の選定基準や選定結果について関係者全体へ説明することで、バランスのとれた合意形成が行えるようにする。

・本番稼働後に想定以上の利用があり、対応能力が不足するリスク
システムへのアクセス数が想定以上に増加し、システムのレスポンス遅延やアクセス不能状態が発生するため、ハードウェア等への追加投資が必要になるというリスク。又は、本番稼働後にシステムの操作方法や不具合に対する問合せが頻発し、ヘルプデスクの対応能力を超えてしまったため、ヘルプデスク体制の増強等に追加投資が必要になるというリスク。

→アクセス増加へのリスクを軽減するためには、本番稼働を段階的にすることで実際の利用規模を見定めながら必要な投資を行う、ピークを分散するように業務スケジュールを見直す、クラウドサービスを利用することで突発的なアクセス増加に対しても対応能力を高める等の対応を行う。

→問合せ増加へのリスクを軽減するためには、よくある質問（ＦＡＱ）をWebサイト等で公開することで問合せ件数を抑制する、ヘルプデスクに寄せらせる問合せを分析し、業務面やシステム面での必要な改善を細かなサイクルで回す等の対応を行う。

納期に関するリスクと対応方法の例

・ 必要資源の配備が遅延するリスク
ハードウェアの配備、ネットワークの開通、データセンターの供用開始、ＩＣカード等の必要備品の準備等、資源の配備が計画時期に間に合わないというリスク。

→リスクを軽減するためには、計画上のバッファ（余裕）確保、代替計画の準備（ネットワークが開通しない場合に、ネットワークを利用しないテスト工程等を先行開始する）、段階的配備（テストに必要な数枚のＩＣカードだけ先に供給を受ける）等の対応を行う。

・関係する他機関からの情報提供が遅延するリスク
制度変更が予定されている場合における変更の詳細内容、システム連携を行うための連携仕様書やテスト計画書等、他機関から提供される情報が期日に間に合わず遅延するというリスク。

→リスクを軽減するためには、計画の部分変更（変更影響を受ける部分の機能開発を後送りにする）、段階的開発（仮決めの仕様を基に開発を行い、仕様確定後に差分部分を再開発する）等の対応を行う。

また、リスクの内容によっては、回避、軽減することが難しく、リスクとして受容せざるを得ないものもあります。そのような場合においても、当該リスクを回避不能なリスク（受容するリスク）としてリスク管理表に記載し関係者の合意を形成しておくことで、実際にリスクが顕在化した場合でも、比較的円滑に対応を行うことができます。

C. 品質管理を事業者任せにしない

品質管理は、サービス・業務としての品質管理とシステムの品質管理に大別されます。

まず、サービスや業務自体に求める品質についてです。利用者に発行する証明書の内容に誤りがあったり、利用料金の計算にミスがあったりしては、利用者からの信頼を大きく損なってしまいます。サービス品質、業務品質として、品質目標を定めた上で実際の品質達成状況を確認していくことが重要です。

なお、サービス品質、業務品質は、プロジェクト管理要領で忘れられがちなポイントです。後述するシステムの品質だけでなく、サービス・業務の品質にも留意してください。

次に、システムの品質についてです。本来はハードウェア等の品質管理も重要なのですが、よく「ソフトウェア品質」という言葉もほぼ同じ意味で使われます。ソフトウェア品質には、機能性、信頼性、使用性、効率性、保守性、移植性といった特性が含まれます。また、「サービスレベル」という形で品質上の重要な事項を指標化します。

ここでは、これ以上詳細に踏み込みませんが、重要なことはシステムの品質についても事業者任せにしないということです。求める水準の品質を得るためには、発注仕様書の段階で具体的に品質水準を提示し、試験の過程で発注者側が品質について関与する内容を明確にし、品質における事業者と発注者側の役割を明らかにすることが必要です。また、事業者内での品質管理体制も確認する必要があります。

事業者の工程完了時に、検収を行う担当者以外にＰＪＭＯの中から成果物や品質報告に対する承認を行う担当者を設けて、工程完了時にこの担当者による承認を必須とするようなルールを作ることも有効です。このようなルールを設けることで、システムの品質達成状況の実態を把握している職員が確実にチェックを行えるようになるので、一定の品質を保つことができます。

Step.4 プロジェクトのモニタリング

プロジェクト計画書及びプロジェクト管理要領が出来上がりました。この内容に沿って、プロジェクトを実施する具体的な方法については、第３章（予算要求）から第９章（運用及び保守）で詳述します。このプロジェクトを実施する過程では、プロジェクトの進行状況や達成度合いについてモニタリングを行うことが重要になります。

特に府省重点プロジェクトト（及びＰＭＯがその他に指定したプロジェクト）については、工程レビューの仕組みが準備されています。プロジェクトが目標に向かって正しく進んでいるかをＰＪＭＯ自身でチェックした上で、ＰＭＯ等の第三者の視点でも確認しましょう。

また、どのプロジェクトにおいても、ＰＪＭＯ自身による定期的なモニタリングが必要です。様々な理由から、プロジェクトが目標どおりの成果を達成できないこともあるでしょう。今後も改善できる可能性が少なければ、予算がついているという理由だけでプロジェクトを延命するのではなく、早期にプロジェクトを終結させることも重要です。プロジェクトが生み出している成果について、定期的に確認を行いましょう。

１ プロジェクトをモニタリングし・検証する

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

プロジェクト実施中は、業務実施部門の職員や事業者との調整、ＰＪＭＯ内での調整や問題対応、関係者間の仕様調整等、様々な出来事で日々忙殺されがちです。そのような状況の中ででも、プロジェクト全体が意図した方向に進んでいるか、包括的な視点で確認することが必要です。

プロジェクトを船に例えましょう。船を進ませるために、船長、船員は様々な業務をしています。ただ、その結果として船が今どこにいるのか、航路からずれていないか、目的地に近づいているかを確認する必要があります。

それが、モニタリングです。モニタリングはＰＪＭＯ自身によって定期的に行われるプロセスです。モニタリングを行うことで、プロジェクトの状況を包括的に把握しましょう。

ポイント

・ 報告内容に「問題なし」が続くとモニタリングの実施間隔が伸びたり実施を取りやめたりしてしまうことがあるが、問題が発生していなくても、あらかじめ定めた内容を継続してモニタリングすることが重要。

・問題を把握したときは、定量的に事実を共有し、改善に向けて迅速に行動に移す。あらかじめ基準と対応手順を定めておけば、問題が発生したときに迅速に対応できる。

A. 目標、経費、進捗、品質等を中心にモニタリングする

モニタリングでは、主として目標、経費、進捗、品質等を確認します。もちろん、プロジェクトの特性によってモニタリングする項目も変わります。モニタリング対象項目をあらかじめ定めておくとともに、それらの項目を継続的に確認しやすいように測定方法を決めておいてください。

モニタリングの内容例

・ プロジェクトの目標の達成度合い
利用者へのサービス向上や業務効率向上等の観点から、プロジェクト計画書で定義した目標に対して、モニタリング実施時点での達成度合いを確認する。

→設計・開発等の段階においては、システムの機能等が目標を達成するために必要十分であるかを確認する。

→運用段階においては、実際のサービス・業務において目標が達成できていることを確認する。

事例：開発途中の機能追加による目標の形骸化 あるプロジェクトでは、業務を効率化するためのシステムを整備するとともに、この業務に関連する決済についても決済関連システムへ自動連携することで、業務担当者の作業負荷を減らすことを目標の１つとしていました。 しかし、システム開発を進める中で、ある部署の現場担当者から要望が出ました。現在は多数の拠点において紙帳票を出力して関係機関へ持ち込む形で決済業務を行っており、自動連携を行うと全拠点の情報のとりまとめが別途必要になるなど業務分担の追加や変更が発生するので、現状どおり紙帳票も出力できるようにしてほしいというものでした。 ＰＪＭＯの中では、担当者レベルの打合せの中でこの要望に対応することを決め、決済データを自動連携する機能と紙帳票を出力する機能の両方を選択できるようにしました。このような対応を行ってしまった結果、当初の目標の１つであった決済関連業務の効率化については、多くの担当者が紙帳票のまま業務を継続することとなり、達成できませんでした。 この事例の問題点は、目標の達成度合いに関わる重要な変更を、担当者レベルで勝手に決めてしまったことです。 まず、本来的には、システム開発に入る前の企画段階で様々な部署の決済業務の運用方法を調べ、自動連携できることを確認すべきです。ただ、開発に入ってから現場の業務実施方法に合わないという問題が顕在化してしまうことも、実際にはあります。この時に、当初決めた方針なので紙帳票の機能は追加しないと押し切ってしまうと、業務上で大きな不都合が発生しかねません。ですので、紙帳票の機能も追加したこと自体は、結果としては正しい判断だったのかもしれません。ただ、その判断の際に、プロジェクト推進責任者がプロジェクトの効果目標を修正することになると理解した上で、それでも機能追加を行うという責任を持った判断をすることが不可欠だったといえます。 このように、システム開発の過程では様々な要望や制約が判明する中で、実現機能を修正することが求められます。だからこそ、要所でモニタリングを行い、当初目指していた目標の達成度合いを確認することが重要になります。

・経費の計画と実績
プロジェクト計画書の中で定めた年度単位での予算額計画に対して、実績での経費を確認する。経費については、ＰＪＭＯが直接的に執行した経費だけでなく、業務実施部門等で移行や運用支援のために必要になる経費等を含めて、プロジェクトに関連して支出した経費の全体像を把握するようにする。

・作業進捗の計画と実績
システム開発等の作業について、計画したスケジュールに対する実際の進捗状況を把握する。

・品質の管理基準に対する実績
プロジェクト管理要領に定めた品質基準に従って、システム開発や運用等の各プロセスが実施されていることを確認する。

B. モニタリングは適時に実施する

モニタリングの実施頻度は、四半期に１度とすることや、半期に１度とすることを例示として挙げますが、プロジェクトの状況に応じて柔軟に設定してください。

C. モニタリングと監査をうまく組み合わせる

プロジェクトのモニタリングと、第１０章で後述する監査とが同一と誤解されることがありますが、そうではありません。モニタリングと監査は別のものです。モニタリングは血圧測定のような自分自身による日々の健康チェックで、監査は専門的な医師が行う人間ドックのようなものです。モニタリングは実施頻度を定めて継続して行い、監査は数年に１回等のタイミングで計画的に利用するという二本立てで、プロジェクトの健康を保持しましょう。

また、モニタリングやシステム監査の結果を、後続プロジェクトでも活用しましょう。過去に気づいたこと、指摘を受けたことを、今後は同じ誤りをしないように教訓としてためていき実際の案件で活かしていくことが、長期的にはとても重要なことです。

D. プロジェクトは状況に応じて停止・改善する

関係者と合意したプロジェクト計画どおりにプロジェクトが進行できないときは、正常な状態に戻すための活動を進めることになります。このような状況になったときは、ＰＪＭＯであるあなたは、客観的な資料を揃えて、関係者に正確な実情を共有してください。

資料を確認したＰＭＯ等が抜本的な見直しや、場合によってはプロジェクトの停止を判断し、更に深刻な事態に発展することを防ぎます。

事例：抜本的な改善のために新たな体制を構築 あるシステム（府省共通システム）では、システム稼働開始後に様々な問題点が発生したため、政府ＣＩＯへも状況を共有した上で、抜本的な改善を行うこととしました。 このシステムの利用については、府省単位で段階的に移行を行っていましたが、移行作業をいったん中断することとしました。その上で、システムの機能等の改善だけでなく、業務自体や背景にある制度自体の見直しも含めた抜本的な改善を行うために、各府省の事務次官をトップとする体制（推進会議）を立ち上げた上で、具体的な見直しを実施するための検討室を内閣官房の組織として設置しました。 その後、検討室がまとめた「改善計画」に基づいて制度、業務、システムの改善を実施し、利用を予定していた全府省がシステムを利用しています。

Step.5 プロジェクトの終結

プロジェクトの立ち上げは、新しいことへのチャレンジや変化への期待もあって注目されますが、終わる方は何となく存在が薄いように感じませんか？

そのようなことはありません。プロジェクトの終結は、これまでの活動を振り返り、活動の評価を行うことにより、新たなプロジェクトへの糧となる重要なプロセスです。

終結処理を確実に行い、気持ちよくプロジェクトを完遂しましょう。

１ プロジェクトの終結を処理する

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

プロジェクトを実行している間には、様々な要因で計画内容の追加や変更が発生します。その結果、プロジェクトの期間が延長され続けて、いつまでも終わらない状態になったという経験はありませんか？プロジェクトは「有期であること」と定義付けられています。終わりのないプロジェクトはプロジェクトではありません。

そのような状況とならぬよう、プロジェクトが対象とする業務の継続有無に着目して、終結する手順を確認しましょう。

プロジェクトを終結することにより、最終的なプロジェクトの達成評価とプロジェクト体制の要員を解放できます。

ポイント

・ プロジェクトの状況ではなく、プロジェクトが対象とするサービス・業務の継続に着目して、完了又は終了の処理を行う。

・特に問題なく運用しているプロジェクトでも、区切りをつけて達成評価し、継続する後続プロジェクトにその評価結果を活かす。

A. プロジェクトを完了する

プロジェクトが提供するサービス・業務が問題なく運用されている場合や、様々な問題で運用に入れず期間を延長して開発を続けているような場合は、定めたプロジェクト期間に従って、まずはプロジェクトの評価を行い、一旦完了させてください。

B. プロジェクトを終了する

何らかの理由でプロジェクトの対象となる事業が不要となることがあります。それに伴いサービス・業務を支援していた情報システムが不要になりますので、その場合はプロジェクトを終了させてください。

C. 後続プロジェクトを策定する

プロジェクトの対象とする事業が継続され、引き続きプロジェクトで扱う情報システムを利用するときは、後続プロジェクトについて策定しましょう。

現在のプロジェクトで運用している各種計画書等をそのまま引継いで利用できますので、プロジェクトを新規に立ち上げるときと比較すると、準備に必要な負荷は少なくなります。

ポイント

・ 情報システムの規模で異なるが、現プロジェクトの完了の３年前を目安に後続プロジェクトの策定を開始する。

・後続プロジェクトでより良い情報システムとするためには、現プロジェクトにおける課題や要望等を日常的に整理しておくことが重要。

【コラム】ＰＭＯの取り組み事例

個々のプロジェクト計画を定めるのはPJMOですが、府省単位でプロジェクトを束ねて、管理、支援するのが府省PMOの役割です。

PMOとは、Portfolio Management Office　の略称で、府省の全プロジェクトについて、計画管理、プロジェクト推進責任者等、ＩＴ人材管理、予算管理、執行管理、情報資産管理、ＰＪＭＯ支援、ドメイン管理、システム監査管理、プロジェクト検証委員会の運営、政府情報システムに係る文書管理、ＣＩＯ補佐官の環境整備、連絡調整窓口を行います。

各省PMOでは、プロジェクトの管理や支援を円滑に行うために、様々な工夫を行っています。その一例をご紹介します。

A. ＰＭＯの機能強化

(1) 「受け身のＰＭＯ」から「働きかけるＰＭＯ」へ

(ア) 新規システム構築時のＰＭＯへの事前相談

ＰＪＭＯが新規のシステム構築等を行う場合には、ＰＭＯが必要な助言・指導。

従来は、ＰＭＯは「ＰＪＭＯから相談があれば受け付ける」との受動的な対応。

事前・前広に必ずＰＭＯに相談をしてもらうように省内へ周知。

(イ) 主要プロジェクトの指定

ＰＭＯが支援する必要があるシステム案件を省内の主要プロジェクトとして指定し、

ＰＭＯが定例会の出席、レビューの対応等の支援。

従来は、ＰＪＭＯ側の要請があったものを主要プロジェクトに指定していたが、

ＰＭＯがプロジェクトの難易度やＰＪＭＯの体制等を踏まえて指定。

(ウ) ソフトウェア・サポート期限のチェック

ソフトウェアのサポート期限をチェックするルールを導入。ＰＪＭＯがソフトウェアのサポート期限等を管理しＰＪＭＯ、ＰＭＯ双方でチェック。

サポート期限切れが近いものはＰＭＯからＰＪＭＯへ予算要求等を行うよう指導。

(2) システム予算のチェック機能の強化　～予算査定との連携強化～

これまで６月（各局庁が予算課へ予算要求を提出した後）に行っていたＰＭＯによるシステム予算のヒアリングについて、予算課との連携を強化して以下を推進。

(ア) 新規システムの構築等を対象としたレビュー（２～３月）、全システムを対象とした詳細なヒアリング（４～６月）を実施する早期・詳細なヒアリング方式に見直し。

(イ) ヒアリング結果をまとめた意見書については、予算課での査定に明確に反映。

B. 省内共通基盤の整備

デジタル・ガバメントを効率的・効果的に推進するため、各ＰＪＭＯがばらばらで対応するのではなく、ＰＭＯが企画し、一元的な整備・運用を図る省内共通基盤を整備。

いずれも中長期計画にも位置付け、運用開始を目指して推進中。

(1) 行政手続等の共通申請システム　

利用者の利便性向上のため、当省所管の行政手続・補助金手続をオンラインで申請できる共通的なシステムを構築。

オンライン化に当たっては、利用者視点で、添付書類の削減など手続の改善も検討。

(2) クラウド・プラットフォーム基盤

クラウド・バイ・デフォルトに即するとともに、省内システムの基盤の集約を図るため、当省独自のクラウド・プラットフォーム基盤を構築。コスト削減、セキュリティや運用保守水準の向上のほか、ＰＪＭＯの負担軽減が期待。

C. 体制強化・人材育成

(1) ＰＭＯの体制強化　

　１名→３名に増員配置。ＣＩＯ補佐官からの指導・助言を仰ぎながら、業務経験を積ませる等より、属人的でなく組織として機能するＰＭＯ体制を構築。

(2) 計画的な人材確保・育成　

　特にＰＭＯを担え得る人材を統計組織出身者だけに頼らず、省内外から幅広く確保。

　システム業務だけでなく、政策の業務経験も積ませる等により、ＰＭＯとしての役割を担える人材を計画的に育成。

・ IT業務を担う職員を新卒で新規採用（一般職）

・ 若手職員の配置、ＰＭＯとＰＪＭＯの人事交流、独法との人事交流など省内外の人事交流を活発化

・ スキル認定、総務省統一研修など政府全体の取組を最大限に活用するほか、当省職員の能力のレベルに応じた独自の研修を実施。

・ ＰＭＯ・ＰＪＭＯ経験者や研修参加者の情報を集約。

表：府省ITガバナンス業務年間スケジュール俯瞰図（中～大規模府省モデル）