--- type: guideline title: Step.2 プロジェクトの立上げ、初動 source: デジタル庁 ds_code: ds-120 category: government-system updated: 2025-06-19 source_url: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/9ab95eed/20250619_resources_standard_guidelines_guideline_06.zip --- # Step.2 プロジェクトの立上げ、初動 プロジェクトを立ち上げることになってメンバーの１人に任命されたんだけど、いったい何をしたらいいんだろうか。新しいプロジェクトの立ち上げに携わる時には、誰もがうれしさ半分、とまどい半分という入り混じった気持ちになります。 プロジェクトを立ち上げる際には、目標や方向性を適切に定めることが重要です。そこで、ここではプロジェクトを立ち上げる際の動き方について、特に重要になる点を説明します。 ## 目標とする成果を見定める 【標準ガイドライン関連箇所：第３編第２章第１節1)】 今まで、いくつかの失敗プロジェクトがありました。 失敗プロジェクトについて後から振り返ってみると、プロジェクト開始当時に業務分析を軽視し、楽観的な推測を基に想定効果を過大に見積っていたという傾向が共通的に見られました。このような失敗を繰り返さないために、新しいプロジェクトを開始する際には、ぜひこれから説明する内容を意識してください。 ### 現場で発生している事実をつかんだ上で今後の目標を定める このタイトルを読んだだけでは、当たり前のことのように思えるでしょう。ただ、一口に「事実をつかむ」と書いても、どの水準までつかむ必要があるのか、人によって理解は様々です。 そこで、ここでは１つの例を題材として、考えてみましょう。 紙の申請書を窓口で受け付けていた業務について、ＩＴを使ってサービスを改善するためのプロジェクトを立ち上げたとします。このプロジェクトの目標は何でしょうか。 まず、「申請者の利便性向上」といった言葉が思い浮かぶかもしれません。窓口に来るということ自体、申請者にとっては面倒なことです。電子申請を導入すれば、申請者の手間を減らすことができるかもしれません。ただ、電子申請を導入したとしても、窓口に来る方が便利という人もいるでしょう。まずは、全ての申請件数のうち、60%程度を電子申請経由とすることを目指すのが現実的な線でしょうか。 さて、これで目標設定が完了しました・・・。**本当に、これで大丈夫でしょうか？** - 図2-1 目標設定の悪い例 ![](../assets/ds-120-ch02-image1.png) 実は、この例には目標設定に当たって**決定的に抜け落ちている観点があります**。何が抜けているのか、順をおって説明しましょう。 #### 誰が何に困っているのか ここで原点に立ち返って、現場で発生していることをよく見てみましょう。 申請者は、本当に困っているのでしょうか。困っているとして、何に困っているのでしょうか。 現場に行って、実際に現場で発生していることを調べてみると、例えばこのような状況に気づくことができます。 - **審査期間が長すぎる** ある業務では申請を受け付けてから審査結果を返すまでに１ヵ月程度の期間を要していました。申請者は、窓口へ来訪する手間よりも、審査結果が遅いことに対して大きな不満を持っていました。 - **審査結果の回答期日が不明** ある別の業務では、審査の回答期限を定めていませんでした。申請者は、いつ申請結果が返ってくるかが全くわからず、何度も窓口に電話で問合せては、その度に「現在処理中です。回答できる期日はわかりません」と返答を受けて、困っていました。 - **申請様式が拠点ごとにバラバラ\** ある企業は全国的に事業を展開していますが、申請書を提出する地方拠点ごとに申請書の様式や記載項目が異なっていました。そのため、企業内では一元的にデータを管理しているにもかかわらず、各拠点の様式に合わせて手作業で申請書を書かなければならず、手間が発生していました。 これらの例では、窓口に来なければならないことよりも、**さらに深刻に困っていること**がありました。電子申請を進めるだけでなく、ほかにも対策を打つべきことがありそうです。 「申請者は窓口へ来訪する手間に困っている」というストーリーは、推測に基づくものでした。現場を知らない人の**推測のみで目標を設定するのではなく**、現場の流れ、利用者の状況を調べて、本当の「困っていること」を把握することが最初の第一歩です。 #### 利用者にも、色々な種類があるのではないか そもそも、利用者とは誰でしょうか。先の例では、「申請者」という１つの言葉で表現していましたが、申請者の中にも、様々な種類の利用者がいるのではないでしょうか。 - **本人か代理人か** 実際に申請を行うのは、手続の主体となる本人でしょうか、それとも代理人でしょうか。代理人による申請の場合は、委任状が必要になるなど必要書類や事務手続が異なる可能性があります。 - **個人か法人か** 企業等の法人が日常的に申請を行っている場合は、１つの手続ごとに窓口にくるのではなく、ある程度まとめて一括で申請を行っているかもしれません。 また、大量の申請を行っている企業は、紙の申請書を自動出力できるように独自の情報システムを整備済みかもしれません。この場合、拙速に電子申請を進めても、紙の申請書の方が便利であるため、電子申請が使われないことになりかねません。 そのほかにも、地域別、世代別、世帯構成別など、申請者を様々な観点から分類することができます。重要なことは、**「困っていること」が異なるグループ**があれば、それらの個々のグループについて、それぞれの困りごとを把握するということです。また、独自の情報システムを整備済みの企業の例のように、「困っていない」グループを把握することも重要です。 なお、この例における「申請者」のような、複数のグループを包括する名詞には注意が必要です。このように十把一絡げの形で利用者像を捉えてしまうと、特定のグループが困っていることを見落とすことになりかねません。 #### 申請内容にも、色々な種類があるのではないか 申請内容にも様々な種類があります。申請の種類ごとに、審査の内容や必要時間を調べていくと興味深いことがわかりました。 - **形式的な内容確認のみを行うもの （大部分の申請）** 必須記載事項が正しく記載されているかなど形式的な確認のみを行うものが、申請件数の大部分を占めていました。 なお、さらに実態を調べていくと、実質的な確認に要する時間は僅かであり、各部門を流れていく際の待ち時間が長いことがわかりました。また、窓口で申請書類を受領した際の確認が十分でなく後日に申請者へ再問合せを行うなど、再確認作業にも相当の手間が発生していることがわかりました。 - **専門の審査官による実体的な審査を行うもの （一部の申請）** 一部の申請については、審査官が専門知識と経験に基づいて各種資料を総合的に確認した上で審査を行っていました。ただ、上述の形式的な内容確認も同一の審査官が実施しているため、専門的な審査に十分な時間が割けない場合があることもわかりました。 - 注記 エンドツーエンドとは、利用者が、ある目的を達成するためにサービスを受ける必要があると考えた時点から、当該サービスを受け たことにより目的を達成した時点、又はサービスを享受し終わった後の行動までに生じる、利用者の感情を含めた思考や一連の行動全体のこと。 エンドツーエンドの視野で、ほかに問題はないか 業務実施部門の視点で見ると、窓口で申請を受付け、審査を行うという業務は所管業務の重要な一要素です。一方で、利用者が申請の事前、事後で作業を行っていることについては、業務実施部門の「所管外」として意識されないことがあります。 しかし、利用者の視点で見ると、事前、事後に必要となる作業も同様に重要なプロセスです。そこに、困りごとは発生していないでしょうか。 - **利用者が申請を行う前に必要となる作業** 代理人が申請するときに、本人からの委任状をどのように手配しているのか・申請可能な時期を確認する・申請後にどのような順番で処理されるのか（先着順、申請期間完了後一斉処理等） - **利用者が審査結果を受領した後に必要となる作業** 審査結果を別の行政機関に提出している ◇ ◇ ◇ このように、利用者視点を重視して現場で発生していることを調べていくと、解決すべき課題に様々な種類があることがわかります。 ここで例示したプロジェクトについては、目標とする成果を次のように見直すこととしました。 プロジェクトには投資が伴います。投資を行ってまで得たい成果が何なのか。それを具体的な形で明確にすることが重要です。 - 図2-2 目標設定の改善例 ![](../assets/ds-120-ch02-image2.png) - ポイント 2-1 利用者視点での目標設定には、サービスデザイン思考を！

ポイント：利用者視点での目標設定には、サービスデザイン思考を！

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

ポイント：事実を詳細につかむことも忘れずに

先ほどの例では、審査期間の短縮として原則１週間以内にするという目標を立てました。ただ、まだこの時点では、審査期間がなぜ長くなってしまうのか、その原因をしっかりつかめているわけではありません。

サービス・業務企画の活動の中では、発生している事実を詳細につかむことも非常に重視しています。実際の１件１件の審査案件を調べてみて、どこで滞留が発生しているのか、その滞留が発生する背景にはどのようなことがあるのか、そのようなことを丹念に調べていくことで初めて本当の問題点をつかむことができます。このような事実のつかみ方についても、「第４章 サービス・業務企画」で詳述しています。

プロジェクトの立ち上げ時には、利用者が困っていることを把握した上で、その困りごとを解消するための目標を立てます。その後に詳細な現状把握を行って問題の発生原因を突き止めていくので、場合によっては目標の修正が必要になることもあるでしょう。プロジェクトの立ち上げ後は、このように現状把握を進めながらプロジェクトの目標自体も正確に見定めていきます。そして、サービス・業務企画をまとめあげる頃には、設定した目標に対して関係者の合意もとりつけて、目標を確定します。
- 事例2-1 事務作業を効率化し、国民向けの対応サービスを強化

事例：事務作業を効率化し、国民向けの対応サービスを強化

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

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

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

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

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

そこで、まずはシステム化等により煩雑な事務作業を効率化することにしました。そして、そのことによって浮く時間を、来訪者向けのコンサルティングサービスに振り向け、サービスを充実させることとしました。
### 上位計画の目標をブレークダウンし、プロジェクト目標と紐づける 前述の例は、現場のニーズや困りごとに基づいて、新規のプロジェクトを立ち上げる例でした。一方で、政策や施策等、上位に当たる計画があった上で、それを実現するために情報システムを活用したプロジェクトを立ち上げるという形も、実際によくみられる形態です。また、予定されている法改正等に伴い、情報システムの対応が不可欠になるという状況もよくみられます。 このような場合、どのようなことに留意すべきでしょうか。 #### 上位計画の目標と、プロジェクトの目標を紐づける 上位計画が長期的視点で広範囲にわたる効果を目指している場合は、その目標設定も包括的で概括的なものとなる傾向があります。例で示す方が、わかりやすいでしょう。 - 児童の学力向上 - 過疎地域の若年人口拡大 - 地域活動への多様な人材の参画 - 助成制度利用企業の売上金額の拡大 - 受給権者への確実な給付の達成 これらの上位計画を達成するために、その１つの施策として情報システムを活用したプロジェクトが必要になることがあります。この場合、上位計画の「大目標」とプロジェクトの「部分目標」が実体的に紐づくべきなのですが、その過程を省略して、プロジェクトの目標も「大目標」で置き換えてしまう例が見られます。しかし、そのプロジェクトが果たして「大目標」にどれほど貢献できるのか、その効果の程度がよくわからなくなってしまいます。 目標が紐づくとは、どのような状態を指すのでしょうか。 以下では、目標設定において重要な概念であるＫＧＩ/ＫＰＩについて説明した後、目標の紐づけの方法を示します。 「ＫＧＩ」「ＣＳＦ」「ＫＰＩ」の定義と関係 - **重要目標達成指標（ＫＧＩ：Key Goal Indicator）\** 政策目標等、プロジェクトの最終目標を達成するために管理すべき指標 - **重要成功要因（ＣＳＦ：Critical Success Factor）\** ＫＧＩを達成する（成功させる）上で重要となる要因 - **重要成果指標（ＫＰＩ：Key Performance Indicator）\** プロジェクトを推進し、新しいサービス・業務を実現することで重要目標達成指標を達成するために管理すべき指標 ここで、資格試験に合格するために勉強するという場面を想定して、これらの具体例を考えてみます。 資格試験の合格、すなわち「試験で70点以上取得」がこの場合のＫＧＩとなります。 では、このＫＧＩを達成するためのＣＳＦは何でしょうか。まずは、「十分な勉強時間を確保すること」（リソースの確保）が挙げられます。他には、自分の周りでこの資格を既に取得している人やこの資格の分野に詳しい人を見つけて質問できるようにしておき、「わからないことがあっても解決できるようにすること」（協力体制の確立）、「周りから邪魔されずに集中して勉強できる環境を確保すること」（阻害要因の排除）などが挙げられます。このように、ＣＳＦは、これらが揃えば確かに成功（目標を達成）しそうだと思える要因であることが大切です。 そして、ＫＰＩとして、「1週間あたりの勉強時間：10時間以上」、仕事が忙しくて勉強できないということがないように「1週間あたりの残業時間：5時間未満」などといった指標を設定します。ＫＰＩは、これらが達成されればＣＳＦ（ここでは「十分な勉強時間を確保すること」）が実現できたといえるような指標を設定します。 ＣＳＦは抽象的であるため、具体的に何をすれば良いのかわかりにくい場合がありますが、このようなＫＰＩを設定することで、自由時間を勉強に当てるだけでは1週間あたり3時間ほど足りないので、さらに勉強時間を捻出するために通勤時間に電車の中でも勉強できるように準備をする、資格試験までの期間は業務量が多くなりすぎないよう上司や同僚に相談するといった具体的なアクションを考えることができるようになります。 このようなアクションを通じてＫＰＩが達成されると、「これらが揃えば確かに成功（目標を達成）しそうだと思える要因」であるＣＳＦが揃うので、ＫＧＩを達成できる可能性が高まります。 - 図2-3
![](../assets/ds-120-ch02-image3.png)

[「ＫＧＩ」「ＣＳＦ」「ＫＰＩ」の関係

ＫＧＩ/ＫＰＩは設定するだけでは意味がありません。モニタリングを実施し、プロジェクトの目標の達成度合いを評価することが重要です。そのためにも、ＫＧＩ/ＫＰＩはどのように測定するかについてもあらかじめ検討し、計測できる指標を設定しましょう。 また、モニタリングは、目標の達成期日になってから実施するだけでなく、継続的に実施して変化の度合いを把握し、それが不十分である場合は改善策を実施することが必要です。そのため、モニタリングの実施頻度（実施時期）、各時点での目標値をあらかじめ定めておくことが重要です。 KGI/KPIを策定する際に、将来の目標だけを設定するというケースがあるのですが、これに加えて現状（プロジェクト開始時点の状態）の水準も把握することが重要です。現状とのギャップが分かるように、目標を設定します。 そして、そのＫＧＩ/ＫＰＩの策定には様々な手法が存在します。以下では、その例として「ＫＰＩトレーサビリティ・ツリー」と「ＢＳＣ（バランスト・スコアカード：Balanced Score Card）」を用いてＫＧＩ/ＫＰＩを設定する手法を示します。 - 事例2-2 ＫＰＩトレーサビリティ・ツリーによる目標の紐付け

事例：ＫＰＩトレーサビリティ・ツリーによる目標の紐付け

あるプロジェクトでは、国民向けに実施しているサービスをさらに向上させるために、政策目標（ＫＧＩ）に対して、複数の重要成功要因（ＣＳＦ）を設定し、さらに個々の重要成功要因に対して、プロジェクトの目標（ＫＰＩ）と紐付けました。

このことにより、プロジェクトが実現する個々のサービスや業務の改善内容が、全体としてどのような効果につながるかをＰＪＭＯ職員や関係者が共通に理解することができました。利用者（求職者・求人者）と職員の双方にメリットがある有効な目標を設定することができました。実際に行った作業を紹介します。

  1. 業務要件定義時点でのＫＧＩ・ＫＰＩのトレーサビリティの確保

まずは調達時にＰＪＭＯで準備し、整理してまとめておく必要がある項目・内容を、次のとおり抽出しました。

【政策目標（ＫＧＩ）】

  • 利用者からの電子申請率の向上による、申請処理の迅速化及び事務負担軽減

    【重要成功要因（ＣＳＦ）】

  • 電子申請ページを利用しやすくする（どこにあるか見つけやすくし、ページの中身自体もわかりやすくする）

    【重要成果指標（ＫＰＩ）】

  • 利用者が目的のページに達するまでの状態遷移数：a秒未満、n画面以下

  • 検索機能の処理能力：適合率p%以上、再現率r%以上、検索速度s秒未満

  • 電子申請ページでの入力が完了するまでの時間：m分未満

次に、これらの項目とＫＧＩを頂点とする紐づけを作成し、ツリー（木）の構造に似た形式で整理し、関係性を明らかにしました（下図）。これにより、情報システムの調達過程で「この機能（サービス）は何のために必要なのか？」「この機能の性能が不十分だった場合、どういった業務、ＫＧＩ/ＫＰＩに影響するのか？」などが把握しやすくなり、目の前の作業だけにとらわれてそもそものゴールを見失うことを防ぎ、価値を生み出すＩＴガバナンスの実行に寄与することができました。

![](../assets/ds-120-ch02-image4.png)

  1. 設計・開発時点でのＫＧＩ・ＫＰＩのトレーサビリティ確保

設計・開発時点で詳細化されていく項目・内容について、要件定義時点でのＫＧＩ・ＫＰＩのトレーサビリティ・ツリーを土台にし、同様にしてＫＧＩを頂点とした紐づけを相互に行い、ツリー（木）の構造に似た形式で整理し、関係性を明らかにしました（下図）。

![](../assets/ds-120-ch02-image5.png)

【要件定義書（情報システム要件定義書）】

  • 要件定義書名：○○○要件定義書

  • 業務カテゴリ、業務フローの名称：ＩＤ○○○

  • 機能（サービス）詳細：

  • 画面・帳票・バッチの名称：

  • 画面・帳票・処理要件　　など：

    【基本設計書】

  • 基本設計書名：○○○基本設計書

  • 基本設計書の記載箇所　　など

    【詳細設計書】

  • 詳細設計書名：○○○詳細設計書

  • 詳細設計書の記載箇所　　など

    【テスト計画書・仕様書】

  • テスト計画書・仕様書名：○○○テスト計画書・仕様書

  • テスト計画書・仕様書の記載箇所　など

    【その他】

  • 課題管理、修正（履歴）管理

このＫＰＩトレーサビリティ・ツリーを用いて管理することにより、情報システムの設計・開発過程で「何のためにこの機能（サービス）は設計・開発しているのか？」「この機能の性能が不十分だった場合、どういった業務、ＫＧＩ/ＫＰＩに影響するのか？」などが把握しやすくなりました。

また、目の前の作業だけにとらわれてそもそものゴールを見失うことを防ぎ、価値を生み出すＩＴガバナンスの実行に寄与することができました。特に開発スケジュールの中盤を過ぎると、各開発の現場は超近視眼的になり、周囲を考慮しない作業になりがちなため、トレーサビリティ・ツリーによって全体を俯瞰した視点で作業を実施できました。
- 参考2-1 バランスト・スコアカードによる目標の紐づけ

参考：バランスト・スコアカードによる目標の紐付け

バランスト・スコアカード（ＢＳＣ）は、目的を達成するためには、顧客（国民・利用者）にどのような価値を届けるべきか、そのために設けるべき業務プロセスとは何か、その業務プロセスを行うために必要な人材・スキルとは何かというように｢成果の視点｣、｢顧客の視点｣、｢プロセスの視点｣、｢学習と成長の視点｣を段階的に整理することで、取りこぼしのないアクションにつなげるものです。

ＫＧＩ/ＫＰＩを設定する手法の例の1つとして、このＢＳＣを利用するイメージを以下に示します。この図のように段階的に整理することで、目的を達成するために行うべき重要な要因を浮き彫りにできます。これらの要因が、どの程度、達成できたかを計測する指標としてＫＧＩやＫＰＩを設けます。

![](../assets/ds-120-ch02-image6.png)

※1 本来のＢＳＣでは「成果」 ではなく「財務」の視点であるが、政府においては「財務」の視点が必ずしも正しくないため、便宜上「成果」としています。

※2 案件の特性により、顧客の視点での設定内容が、ＫＧＩになるケースと、ＫＰＩとなるケースがあるため、ＫＧＩ/ＫＰＩと記載しています。
- 事例2-3 トレーサビリティ・ツリー、ＢＳＣを利用したＫＧＩ/ＫＰＩ策定

事例：トレーサビリティ・ツリー、ＢＳＣを利用したＫＧＩ/ＫＰＩ策定

ある農業関連システムにおけるＫＧＩ/ＫＰＩ策定事例を示します。

これまで、農業に関連する情報は関係機関ごとにバラバラに管理されており、来訪に赴く農業従事者には大きな負担でした。

そこでデジタル技術を活用して農業関連情報を統合し、一元的に管理できる情報管理システムを設けて、申請の一元化・デジタル化により農業従事者が関係機関に来訪する負担を軽減しました。

![](../assets/ds-120-ch02-image7.png)

![](../assets/ds-120-ch02-image8.png)

![](../assets/ds-120-ch02-image9.png)

  • 当事例では、農業従事者の負担軽減には、当該システム・サービスの利用・普及が進まなければならないため、サービスの対象となる従事者が使いやすいユーザインタフェースを実装する必要がありました。そのためには、設計段階において農業従事者が利用しやすいユーザインタフェースの設計を行うとともに、達成度合いを測る指標（ＫＰＩ）を設けることが重要でした。
ＫＧＩ/ＫＰＩ策定にあたっての留意点 - **定量化できる指標であること\** 達成状況を正しく評価し、改善につなげるためＫＰＩは定量的な指標とする。 （「使いやすさ」といったあいまいで定量的ではないものは設定しない） 例） オンライン利用率、オンライン申請件数標 - **客観性のある指標であること\** 誰が見ても同じ内容で理解ができる客観的な指標とすること。 （ＫＧＩ/ＫＰＩを達成できるように、後から定義を変えないこと） 例) オンライン利用率、システム稼働率 - **計測できる指標であること\** 自動的に収集できるなど現実的な指標とすること。 例） ＷＥＢサイトのアクセスカウンターなど自動的に収集できるもの - **効果につながる指標であること\** ＫＰＩは効果を推計できる強い相関がある指標を選定すること。 （ＫＧＩが最終目標でＫＰＩがそれを測るための中間の指標となります。ＫＰＩの達成がＫＧＩの達成につながるかが重要です） 例） 業務実施部門の経費削減（ＫＧＩ）に対して、事務処理を自動化するシステム（ＲＰＡ等）の利用回数 ## 手段の妥当性を確認する プロジェクトの立上げに当たって、プロジェクトの目標とする成果を定め、その成果を得るための手段が妥当であることを確認します。以下では、手段の妥当性を確認する観点について、例を示します。必ずしもこの分類で考える必要はありません。プロジェクトの特性、実状に応じて、本質的に確認すべき観点を事前に考えてみてください。 - プロジェクト立上げ要否の検討 - 情報システムを整備する必要があるか。 例えば、現行の業務では、担当職員が国民からの問合せを属人的に管理する問合せ履歴に記録しており、部署内での情報共有がうまくいっていないという課題があるとする。 この業務を情報システム化するプロジェクトの立上げの妥当性を評価する場合、そもそも情報システムを整備する必要があるのかを評価する。問合せ件数が少ない場合、情報システムを整備するのではなく、問合せ履歴を記録したExcelファイルを部署内の誰もが参照・更新できるような運用 - 参考2-2 統計表における機械判読可能なデータ作成に関する表記方法 方法に変更する という選択肢もあり得る。なお、その際は、機械判読可能な表記方法とすることに留意すること。 また、業務によっては現行の業務から変更しないという選択肢も合わせて検討する。 - サービス・業務の見直し有無の確認 - サービス・業務改革（BPR）の実施を検討しているか。 プロジェクトのライフサイクルの中でも、新規のプロジェクトの立上げの段階は、サービス・業務の見直しを行う好機である。そのため、見直しに当たっては、現行の業務内容を踏襲するのではなく、サービス・業務改革（BPR）を実施することが重要である。 プロジェクトの妥当性の評価においては、サービス・業務改革（BPR）の実施にあたり、「第４章 Step. 2-1-A 心構えと視点（サービス設計12か条）を理解する」で示すサービス設計12か条の心構えと視点に基づいてサービス・業務企画を実施する計画となっているかを評価する。 - 政府・府省方針との整合性や利用する技術の妥当性の確認 - クラウド・バイ・デフォルトの原則に沿って検討しているか。 情報システムの整備に当たっては、クラウドサービスの利用を第一候補として検討する。プロジェクトの妥当性の評価においては、「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」に基づいて、適切にクラウドサービスの利用を検討する計画となっているかを評価する。 - 共通機能等の利用を想定しているか。 情報システムをすべて新たに構築するのではなく、デジタル庁で整備している共通機能や自府省で整備している省内共通基盤等 を利用することで、設計・開発期間を短縮し、整備経費を抑えられる可能性がある。 プロジェクトの妥当性の評価においては、これらの共通機能等の利用を検討する計画となっているかを評価する。 - 政府内の類似システムや民間サービスの活用を検討しているか。 情報システムを新たに構築しなくとも、政府内の既存の類似システムや民間企業が提供しているサービスをそのまま利用することができれば、設計・開発に要する時間やコストをなくすことができる。そのまま利用できないまでも、既存システムの機能拡張によって利用できるのであれば、設計・開発を最小化して、整備経費を抑えられる可能性がある。 プロジェクトの妥当性の評価においては、プロジェクトで実現しようとしている情報システムと類似の既存システムやサービスの有無を調査し、利用を検討する計画となっているかを評価する。 - 事業者の提案内容を鵜呑みにしていないか。 ＰＪМＯはシステム化の方法を事業者に相談する場合に、事業者は自社の機器やソリューション等の利用を前提とした提案をすることが想定される。1社の提案内容を鵜呑みにすると、他の事業者では実現できず競争を阻害したり、他の事業者からより良い実現方法の提案を受けられなかったりする可能性がある。 プロジェクトの妥当性の評価においては、特定の事業者の機器やソリューション等の利用を前提とした提案内容を鵜呑みにするのではなく、プロジェクトの目的を踏まえて、より良い実現方法を検討する計画となっているかを評価する。 - 技術的な実現可能性を考慮しているか。 これまで利用実績の少ない技術を用いて情報システムの整備を検討する際に、技術的な実現可能性を判断することが困難な場合がある。その場合、情報システムの設計・開発を行う前に概念検証（PoC）を実施するなどして、当該技術の実現可能性を評価することができる。 プロジェクトの妥当性の評価においては、技術的な実現可能性を考慮して、プロジェクトを推進する計画となっているかを評価する。また、技術的な実現可能性だけでなく、関係システムや関係者に対して導入する情報システムへ円滑に移行できるように、関係者への支援体制の確立、スケジュールの共有、説明資料の提供や問合せへの対応なども十分に考慮されている計画となっているかを確認する。 ## プロジェクトの費用対効果を算出する 【標準ガイドライン関連箇所：第３編第２章第１節1)】 標準ガイドラインでは、情報システムの整備を投資的整備と維持的整備に分けています。投資的整備／維持的整備と費用対効果の評価方法の詳細は、標準ガイドライン解説書「第2章　１．プロジェクトの立ち上げ及び初動　２）立ち上げの承認」を参照して下さい。情報システム整備のうち投資的整備に該当する案件は、国民・利用者の利便性向上・負担軽減等の効果を得ることを目的としているため、費用対効果をしっかりと精査・評価していくことが重要になります。費用対効果の精緻な算出は、「第４章 Step．5-2-G 精緻に効果を積算し、主要な効果を実感可能なものとする」で示した考え方に従い、プロジェクトを推進しながら、予算要求までに実施します。プロジェクトの立上げ時にも同様の考え方を踏まえるとともに、以下の留意事項に沿って、費用対効果の概算を見定めることが重要です。 **費用対効果の算出における留意事項** - **投資額の算出\** 費用対効果を算出するためには、情報システムに係る経費のうち、いくらが投資額となるのか算出する必要があります。 調達案件ごとに投資的整備のみに該当するか否かを分類できれば簡単なのですが、実際にはそうならず、一つの調達案件に投資的整備に当たるものと、それ以外に当たるものが混在していることが一般的です。 そのため、目的に応じて、経費を投資的整備に該当する経費と投資以外の経費へ分類することが必要となりますが、その分類が難しい場合は、以下の(ア)(イ)を参考に投資額の内訳を算出することを検討してみましょう。 1) 情報システムの特性等から分類します。 例えば、機能改修を行う際に、投資的整備に分類される改修は独立性の高いサブシステムに対するものに限定され、それ以外の整備と区別して見積りを取得できる場合などが該当します。サブシステム単位で投資的整備、維持的整備が分類しやすい場合は、サブシステムで分類する。このようにサブシステム単位で分類できない場合は、改修する機能の単位で分類する。 2) 見積もりの中で整備、維持を分けられない場合は、（ア）のように明確な区別ができない場合は、画面数、業務数、職員数、開発規模など、それぞれの実情に見合った数値を使って、全体に対しどれだけの比率を占めるか計算し、その比率で経費全体を按分して算出します。 例えば、投資的整備に該当する改修を行う画面数が40、維持的整備に該当する改修を行う画面数が60である場合、投資額は経費全体の4割とします。 - **ライフサイクル全体における経費の考慮** - **機能改修の考慮\** 情報システムを整備しても、予見していない環境の変化等により期待した効果が得られない場合もあります。 そのため、情報システム稼働後に、期待した効果が継続的に得られるよう、必要に応じて機能の追加や改修を行うことが重要です。 このような機能の追加や改修は当初のプロジェクト計画を補完するものと考え、それにかかる経費や効果を織り込んで費用対効果を算出してください。 - **情報システムの利用促進\** 情報システムの整備による効果を得るために、その情報システムの利用の普及が必要である場合は、十分な効果が現れるまでに時間がかかる傾向があります。そのような場合に高い費用対効果を得るには、情報システムの構築だけでなく、効果的な広報活動など、情報システムの利用を促進する施策を考慮する必要があります。 ## プロジェクトへの投資判断を行う 【標準ガイドライン関連箇所：第３編第２章第１節2)】 プロジェクトへの投資判断と、予算要求（査定）との違いがわかるでしょうか。 プロジェクトへの投資判断は、プロジェクトの目標とする成果を明確にした上で、その成果を得るために必要となる経費や人的資源等を見積り、その費用対効果を踏まえた上でプロジェクトを開始することを責任者が意思決定することです。 一方で、予算要求とは、プロジェクトへの投資判断が行われていることを前提として、翌年度以降に必要となる所要額を見積り、所要額の妥当性の観点から査定を受けるものです。確かに、予算査定過程でもプロジェクトの目的や想定効果を確認しますが、これは予算要求部局内での投資判断がなされていることを前提に、その判断結果を第三者の観点から再確認するプロセスと言えます。 ただ、この点については政府の中では誤解されがちなポイントでもあります。とりあえず予算を要求してみて、予算が通ったらプロジェクトの進め方を考えるという人も少なくないかもしれません。また、実際に新規に立ち上げるプロジェクトでは、投資判断と予算要求のタイミングが重なることも多いため、これらの違いを明確に意識しないことが多いかもしれません。 しかし、これでは、あるべき順序が逆転しています。標準ガイドラインでも、「デジタル統括責任者は、プロジェクトの新規立ち上げに当たって、目標設定及び、手段の妥当性、費用対効果を確認し、その承認を行い、プロジェクト推進責任者及び当該プロジェクトに関する情報システム責任者を指名するものとする」としています。予算要求よりも前の時点でプロジェクトを立ち上げ、デジタル統括責任者が承認することをルールとして求めています。 プロジェクトの立ち上げに当たっては、目標とする成果、その達成方法（手段）、概算での費用に基づく費用対効果を明確にして、デジタル統括責任者の承認を通して投資判断を確実に行うようにしてください。このうち費用対効果は、会計検査院の検査でも用いられている３Ｅ（経済性、効率性、有効性）の観点で確認することが重要です。３Ｅの観点を踏まえた費用対効果の確認については、「第4章 Step. 5-1-A.参考：３Ｅの観点を踏まえた費用対効果の検討」を参照してください。 ## 機能する体制を作る 【標準ガイドライン関連箇所：第３編第２章第１節３)】 プロジェクトの体制構築は、プロジェクトの命運を分ける大事な準備事項です。プロジェクトの初期に十分な体制を構築できずに、結果としてプロジェクトの円滑な運営を行えないケースは残念ながら少なくありません。 プロジェクトの体制構築についてのポイントを見ていきましょう。 ### 制度所管部門、業務実施部門等を含めたＰＪＭＯ体制とする 「ルールは変えられないから、今のルールを前提にどう工夫できるか考えよう」、「業務実施部門に業務のやり方を変えてほしいと頼んでも、聞く耳を持ってくれない」。情報システムを主として担当する組織にいると、このような会話を耳にすることがあるかもしれません。 しかし、制度面でも業務面でも今のやり方を変えないのであれば、たとえ素晴らしいシステムを作ったとしてもその効果はかなり限定的になってしまいます。 情報システムを整備するプロジェクトでは、情報システム部門が中心となると捉えられがちです。しかし、利用者視点でサービス・業務改革を推進していくためには、制度設計の責任を持つ制度所管部門、業務の実施を行う業務実施部門もＰＪＭＯに参画し、それぞれが協働してプロジェクトを進めていく必要があります。 また、制度所管部門、業務実施部門、情報システム部門を含むＰＪＭＯを組織しても、それぞれがあまり連携せずに、別々に動いてしまうことも多々あります。互いが密接に連携しなければ、実態に沿ったサービス・業務を行うための制度設計や適した情報システムを構築することはできません。 そのため、それぞれの部門が適切に情報を連携できるよう、会議やコミュニケーションのルール等を整備することも重要です。また、政策目的やプロジェクトの目標・目的を踏まえて、各々の役割と責任を確認し、サービス・業務改革の意識を醸成するための活動として、最初にＰＪＭＯのメンバー全員を集めてキックオフを実施することも大切です。 - 事例2-4 制度・業務・システムの三位一体のプロジェクト体制

事例：制度・業務・システムの三位一体のプロジェクト体制

ある省において大規模な情報システムを運用していましたが、情報システム部門と制度所管部門・業務実施部門とは異なるロケーションにあることもあり、双方の職員がコミュニケーションを行う機会は限定的になっていました。

そのような中で、情報システムの次期更改のタイミングに合わせて、一層のサービスの向上や運用コストの削減を目的として、業務・システムの見直しを実施することにしました。プロジェクトを立ち上げた当初は、情報システム部門が中心となって検討を進めました。しかし、全体をとりまとめて推進する役割や、業務について検討すべき項目ごとの担当が不明確であったため、制度所管部門や業務実施部門からの積極的な理解が得られないなど関係者の調整が難航し、プロジェクトがうまく進みませんでした。

そこで、プロジェクトの体制を大幅に見直すこととしました。制度、業務、システムが「三位一体」となってサービスを改革することを目指し、それぞれの部門の職員を含めて統合管理チーム、業務・機能検討チーム、アーキテクチャ検討チーム等のチームを結成し、局長をトップとした意思決定組織を作ることで全体を統括した意思決定を行えるようにしました。

![](../assets/ds-120-ch02-image10.png)

このような三位一体のプロジェクト体制を構築したことで、各部門の職員がコミュニケーションを緊密に実施できるようになり、解決すべき問題が発生したときにも幹部まで問題内容がエスカレーションされて意思決定を行えるようになり、円滑にプロジェクトを運営できるようになりました。
### プロジェクトの規模に見合った体制を組む 利用者や関係者が多いプロジェクトでは、情報システムの１つの機能を決めるに当たってもきめ細かな調整が必要になりますし、情報システムを運用する中で利用者からの問合せや要望等に応えながら情報システムを改善していく業務にも大きな労力が必要です。また、多額の経費を投資するプロジェクトでは、情報システム構築や運用が事業者任せにならないように、情報システムの構成や運用状況を常時把握して、課題への対応方針を決め、必要となる経費の妥当性を判断することが必要になります。 このような業務を円滑に実施していくためには、ＰＪＭＯに担当者を十分に配置することが不可欠です。 - 参考2-3 ＰＪＭＯの主要業務

参考：ＰＪＭＯの主要業務

プロジェクトがどのような段階であるかによっても異なりますが、ＰＪＭＯには様々な業務に対応することが求められます。代表的な業務を例示します。

＜総括＞

  • プロジェクトの立上げ、体制確立、組織運営ルール作成、執務環境整備

  • 調達計画作成、見積り依頼、見積り精査

  • 予算要求資料作成、予算に関する関係者折衝

  • 政府全体方針、各省方針等との整合確認、各計画のフォローアップ対応

  • 監査等への対応

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

＜企画＞

  • 利用者のニーズ把握、利用者調査、要望やクレーム等の分析

  • 業務の現状把握と分析、業務フロー等の可視化、実績データ分析

  • 利用者分析、業務分析結果を踏まえたサービス・業務企画

  • 今後の改善内容について、他府省、他組織等との折衝

  • 外部関係者を交えた検討会、内部職員での検討会議等、各種会議運営

  • 企画内容のとりまとめ、関係者への説明

  • 業務要件、機能要件、非機能要件等の各種ドキュメントの作成

＜調達＞

  • 調達仕様書等の作成、評価基準や評価体制の準備、会計担当部門との調整

  • 提案評価、プレゼンテーションの審査

＜開発管理＞

  • 開発事業者の実施計画の確認・承認、スケジュール等の詳細調整

  • 課題調整会議等での課題管理・調整、進捗報告会議等での進捗管理

  • 設計等各種会議での検討、関係者の合意形成、設計書等各ドキュメントの承認

  • 外部組織等との設計内容、連携方式、テスト方式等の調整

  • テスト計画、テスト実施結果等の作成、確認

  • 移行計画、移行作業等の実施、運用計画・保守計画の作成

  • 利用者への事前連絡、マニュアル作成、研修等の実施

＜業務運営、保守と運用＞

  • 業務実施状況の確認、課題要望管理、プロジェクトの目標達成状況モニタリング

  • システムの運用（監視アラート対応、バッチ処理、バックアップ、定期作業等）

  • アプリケーション保守（要件確認、テスト結果確認、リリース管理等）

  • 利用者・関係者との調整、利用状況確認、利用上の問題発生対応

  • システム障害への一次対応・根本対応、インシデント管理

  • ヘルプデスク等での問合せ受付、ＦＡＱ等のとりまとめと更新

  • アクセスログ等の分析、指標管理、改善点検討

  • ソフトウェア等のサポート期限等の管理、パッチ等の適用

  • コスト削減の検討、今後のシステム改修や次期システム更改に向けた検討

システムの規模にもよりますが、このような多種多様な業務をこなすには十分な数の職員を専任でＰＪＭＯに配置することが必要になります。
ＰＪＭＯに十分な数の職員を配置できないと、どのようなことが発生してしまうでしょうか。人数が少なかったり、他の仕事と兼任でＰＪＭＯの仕事に専念できないと、予算要求や調達等の必要不可欠な作業を実施するだけで精一杯となり、利用者分析、現状分析、要望分析、実績データ分析等の本質的な業務にまで手が回らなくなります。その結果、システムだけは出来上がっても、想定していた効果を出すことができません。 例えば、次のように「本末転倒な」事態が発生してしまいます。 - **サービス利用者が不便を感じる** 情報システムの画面構成がわかりにくく、ヘルプデスクに問合せを行っても混雑して電話がつながらず、申請した手続がいつ回答されるかがわからない・・・。ＰＪＭＯの体制が少ないと事前分析が不十分になるため使いにくい情報システムができてしまい、そのサポートも十分にできないといった形で、サービス利用者に大きなストレスをかけてしまいます。 - **業務実施部門の業務効率が悪化する** 情報システムに機能が不足していて、システム外の手作業で様々な追加作業を行う必要がある、情報システムにトラブルが頻発してなかなか解決されない・・・。現場で発生している課題を解決するための情報システムであるはずなのに、逆に業務実施部門の負担を増やしてしまいます。 - **ＰＪＭＯの担当職員が疲弊する** 利用者や業務実施部門からの要望や苦情に追われる一方で、システム関連事業者からは対応が難しいと主張される・・・。このように板挟みの状況の中で、仕事が山積みになり担当職員が疲弊してしまいます。 - **使われない情報システムに、経費ばかりがかかる** システム関連事業者への依存体質が定着してしまい、小規模なシステム改修にも多額の経費を請求され、その経費妥当性を担当職員が判断できないため事業者の見積金額のまま予算要求をせざるを得ない・・・。利用者から業務実施部門から評判の悪い情報システムにもかかわらず、経費だけは膨らんでいくという事態になりかねません。 プロジェクトにトラブルが起こり始めてから担当職員を追加しても、なかなか本質的な解決はできません。例示したような事態を避けるためには、プロジェクトを立ち上げる当初からＰＪＭＯに十分な体制を準備することが不可欠です。 では、何人の体制を準備すればよいか。それは、関係者の多さやプロジェクトの特性によるので一概には言えません。実質的に１人の職員で回すことができる小規模プロジェクトもありますし、100名以上の体制を組む大規模プロジェクトもあります。 ただ、毎年数億円や数十億円といった経費を使う大規模プロジェクトにもかかわらずＰＪＭＯの人数が数名しかいないという体制も見受けられますが、それではさすがに人数が少なすぎるように思います。恐らく、このような体制ではシステムの運用維持や必要最小限の予算要求と調達を実施することで忙殺されてしまい、とても利用者の要望に応えながらサービス・業務の改善点を検討するような時間を捻出できなくなってしまいます。制度所管部門、業務実施部門等の職員を加えて、ＰＪＭＯの体制を強化することが望まれます。なお、内部人材で体制を確立するだけでなく、ＩＴ業界等での経験がある外部人材を任期付職員等の形で採用しているＰＪＭＯもあります。 プロジェクトの規模や特性によって差異はありますが、ＰＪＭＯに数名の職員を追加したとしても、業務実施部門の業務効率を考えるとその何倍もの効果があるはずです。また、情報システムの経費面でも大きな効果があるはずです。プロジェクトが目指す成果に応じて、その成果を達成するために十分な体制を組むことが、結果としてサービスの向上と行政の効率化につながるといえます。 また、ＰＪＭＯの体制を組む際には、ＰＭＯにも相談してみてください。重要なプロジェクトについては、ＰＭＯ職員も直接ＰＪＭＯ体制に含めて、定例会で情報を共有したり、課題への解決方法を一緒に検討したりすることもできます。また、大きな問題が発生しているときには、デジタル統括責任者、副デジタル統括責任者へ相談を持ち掛けやすくなり、早期に問題への対応を行えるようになります。 ### 他組織と連携できる体制を作る 利用者視点、つまり利用者にとってエンドツーエンドの観点でサービスを改善するということは、裏を返すと多くの組織にまたがって業務を見直すことにほかなりません。 ＰＪＭＯには制度所管部門、業務実施部門を含めた体制としています。ただ、ここでいう制度所管部門、業務実施部門とは、あくまでプロジェクトの「中心」となる制度や業務を担当する部門です。利用者の視点でサービスを見渡すと、これらの部門以外にも様々な組織が直接的、間接的に連携していることがわかります。これらの関係者については、プロジェクト管理要領でステークホルダーとして定義した上で、プロジェクトへの関わり方を決めていきます。 さて、ステークホルダーと一口で言っても、同じ省内の他局である場合もあれば、他府省、他組織（民間企業、自治体、独立行政法人等）であることもあり、様々な関係者が存在します。実際には、これらの組織を横断して問題提起を行い、解決方策をまとめることは大変難しいものです。しかし、関係する組織間の調整や協力を行わずにプロジェクトを進めても、サービス・業務改革は成し得ません。 ステークホルダーの多いプロジェクトを円滑に進めるためには、次のことが特に重要となります。 - **各組織の責任者の連携体制を作る** プロジェクトの普段の活動では、各組織の担当者間で調整を行います。ただ、調整が難航した際に、担当者レベルで検討が止まってしまうということが往々にして発生しがちです。 この点は重要なので、強調します。実際に多くのプロジェクトで、このような**担当者レベルでの検討停滞が頻発しています**。「うちは基盤システムだから、個々の情報システムへの個別対応は行わない」、「今回例外対応を認めると先例になるため、そのような対応は行わない」、「当方の所管範囲を超えることなので、何もできない」、このように様々な理由を述べながら、担当者レベルで検討が停止してしまうという事態は頻繁に発生します。 組織をまたいで業務改革を行うためには、このような停滞が発生したときに問題解決の場を一段、二段と上に上げて、各部門の責任者レベルで対応方法を検討できるようにすることが有効です。プロジェクトの体制として関係部門の責任者を明確に記載した上で、状況に応じて**責任者本人が会議に出席して**調整や意思決定を行う場を作ることが重要です。 - **発生した課題をエスカレーションできる仕組みを作る** 上記のような責任者による連携体制を機能させるためには、プロジェクトの普段の活動の中で、以下の両方のルートを確立することが必要です。 １つ目が、**ＰＪＭＯ自身の課題管理を起点とするルート**です。各ステークホルダーとの折衝状況や発生課題を管理し、解決が困難な課題についてはＰＪＭＯからエスカレーション（上位者への情報連携）を行い、関係する組織の責任者との折衝を行います。 ２つ目が、**関係する各組織からの意見を起点とするルート**です。プロジェクトの検討内容やＰＪＭＯのプロジェクト推進方法に課題があると認識した際に、各組織からＰＪＭＯやステークホルダー全体に対して意見提起を行えることが必要です。 特に、２つ目のルートについては明示的に設定されていない例も多く見られます。しかし、関係する各組織がプロジェクトに対して課題や不安を抱えたまま、その状況を正式に伝える窓口が存在しないと、その課題が解決されないままにプロジェクトが進行してしまいます。課題、要望、意見等について提起を行える連絡窓口や連絡方法について明示的に設定するとともに、集まった意見等については定例会議等の場で意見交換を行える仕組みを作ることが望まれます。 - **状況を早期に関係者へ共有する** プロジェクトを推進するＰＪＭＯ側の立場では、様々な情報について検討段階で関係者へ共有するのではなく、正式決定後に初めて共有するというやり方になってしまいがちです。事前に共有した情報に変更が発生すると、変更内容の再連絡や意見調整に手間がかかるということが、その一番の理由でしょう。 一方で、プロジェクトの影響を受ける関係者側の立場では、**検討段階でも構わないので現時点の検討概要を早く知りたい**と考えることが多くなります。「自身が管理する情報システムの改修が見込まれるため、影響範囲を調査するために現時点の要件定義内容を知りたい」、「テスト計画を作成するため、現時点のインタフェース設計内容を知りたい」、「体制を組むために、テストの実施時期や内容を知りたい」等、理由は様々ですが、検討中の内容を早く知りたいというのが関係者側の強い要望となることが多いです。 このような要望が発生することを踏まえて、関係者に影響を与える検討内容については、**この内容が検討中のものであるというステータス情報と今後の検討スケジュールを明確にした上で事前共有を行い**、関係者からの意見も取り込みながら最終的に正式内容を共有するといった形で、数度にわたって段階的に行うことが望まれます。 また、大規模なプロジェクトでは提供するドキュメントが多量になるため、ドキュメントを種類別、内容別等で検索しやすくするような情報共有ツールを活用することも有効です。 - 事例2-5 情報共有ツールによる関係者への情報共有

事例：情報共有ツールによる関係者への情報共有

あるプロジェクトでは、各府省に多数の利用者や関係者がいるため、情報共有ツールを導入しました。

このツールは、Webブラウザ上でファイルサーバのようにファイルを共有することができ、このツールのＩＤを持っている職員は各府省のＬＡＮ端末からすぐにアクセスすることができます。このツールに、関係者向けに開催する会議資料、設計書やマニュアル等のドキュメント、各組織とのやりとりに用いる連絡票や課題管理表など、関係者の権限に応じて様々なドキュメントを参照、検索できるようにしました。このツールによって、過去の資料でも簡単に検索することができ、関係者間の情報共有が非常に便利になりました。

また、ある別のプロジェクトでも、政府内部だけでなく民間企業、自治体等の多数の外部関係者に影響を与える大規模な計画内容であったため、ＩＤを持っている人はインターネット経由で同様に各種ドキュメントを検索できるツールを導入しました。

多くの関係者が存在するプロジェクトでは、会議の度にメール等で資料を送付するような方式では、資料を受領する側でも資料全体を管理しきれません。このような情報共有ツールは比較的安価に導入でき効果も大きいので、利用することを検討してみてください。
- 事例2-6 原則にとらわれない環境作り

事例：原則にとらわれない環境作り

インターネットを通じたコミュニケーションツールは、「約款によるサービス」に当たるため原則利用が禁止されています。しかし、目的に鑑み、リスクが少ないと情報セキュリティ責任者が判断できれば、ツールを利用することは可能です。

あるプロジェクトでアジャイル開発を推進するに当たり、複数の府省と民間企業十数社が参画する体制で、関係者間で密にコミュニケーションを図る必要がありました。特にこのプロジェクトではアジャイル開発を採用して短期間で機能開発や改善を進める必要があるため、職員と開発事業者が、柔軟にコミュニケーションをとれる体制が不可欠でした。そこで、このプロジェクトではコミュニケーションツールの利用目的を明確にした上でリスク評価を行い、情報セキュリティ責任者判断のもとでツールを導入し、アジャイル開発に求められる早いサイクルでの設計、開発、評価の繰り返しをスムーズに行うことができ、利用者の満足度が高いシステムを構築できました。

「原則禁止」、「前例がない」というだけで選択肢をせばめてしまうのではなく、目的達成のために有用な手段なのであれば、その手段を利用するリスクについて評価を行った上で、その利用について情報セキュリティ責任者の承認を得ることを検討しましょう。まずはサービス・業務目的をどうすれば効率的かつ効果的に達成できるかからはじめ、十分に検討した上で「前例を作っていく」ことが重要です。
### 先行経験を持つ人のノウハウを活用する 多くの人が同じ苦労をするというのは、とても非効率な状態です。 ただ、システムの導入順序や体制をうまく整備しないと、こういった無駄なことが起こってしまいます。なぜだかわかりますか。 例えば、全国100拠点に全く新しいシステムを一斉に導入するとします。各拠点で、今までは紙で事務処理していた作業を、今後は新しいシステムで実施することになりました。 ところが、現場には様々な例外処理があります。登録済の内容を過去に遡及して修正するにはどうすればよいか、月末までに処理を間に合わせてほしいという希望にどう対応するか、今までは紙処理で当たり前のように実施していた業務を、システムではどう実施すべきなのか、各拠点の職員はそれぞれが同じような問題に突き当たり、その解決策をそれぞれが苦労しながら考えます。その結果、拠点によって事務処理方法やシステム利用方法もバラバラになってしまい、拠点間を人事異動した職員が業務実施方法の違いに戸惑うような状態になってしまいます。 もちろん、システムの企画、要件定義、設計等の段階で、業務での例外処理も含めたあらゆる状況を想定してシステム機能を作り、業務マニュアル等を充実させるのが理想的な状態です。ただ、このようにあらゆる状況を想定し尽くせなかったとしても、体制面で工夫を行えるのです。 まず、先行的に数拠点の現場で、システム導入を実施します。そして、その拠点でシステムへの対応方法を経験して様々な例外処理等への対応方法にも知悉した職員のノウハウを、他の拠点でも活かすのです。他拠点の職員にとっては初めて遭遇する問題でも、最初の拠点の職員にとっては既に馴染みのある問題であることが多いでしょう。非常に効率的に、問題を解決し、対応方法を決めることができるようになります。 このような機動的な体制を組む際の障害は、人事面でしょう。地方拠点の職員を、システムの導入状況に合わせて次々に人事異動させていくのは現実的には困難かもしれません。ただ、人事異動までは行わなくても、短期間の出張での対応でも構いませんし、電話やメールでの相談だけでも良いかもしれません。 重要なことは、組織の縦割りでの役割分担にとらわれず、先行経験を持つ人のノウハウを後続での作業に活かしていくことです。 - 事例2-7 府省を跨った特別移行支援チーム

事例：府省を跨った特別移行支援チーム

各府省が共通で利用する、ある政府情報システムでは、府省単位で移行スケジュールを決めて段階的に当該システムへの移行を進めていました。移行に際しては、移行計画の作成、データの整備、エラーへの対応など様々な作業が必要になりますが、初期の段階では各府省の担当者がそれぞれに苦労しながら移行作業を進めていました。しかし、このような体制では、各府省で苦労をした人の経験が今後移行をする府省には受け継がれません。

そこで、府省を横断した形での「特別移行支援チーム」を結成することとしました。このチームには、このシステムへの移行経験や業務実施経験が豊富なベテラン職員を十数名配置しました。なお、これらベテラン職員は、当然ながら各府省においても重要な戦力なので、移行支援だけに専念することも困難でした。そこで、各府省においては従来の業務も実施しながらこの特別移行支援チームの業務もできるように、体制を工夫しました。

![](../assets/ds-120-ch02-image11.png)

この特別移行支援チームは、これから移行を行う組織の職員向けに何度も勉強会を開催したり、個別の相談に乗ったり、様々な支援を行いました。

その結果、短期間で効率的に、全府省がこのシステムへの移行を完了することができました。