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

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

プロジェクトを立ち上げる際には、目標や方向性を適切に定めることが重要です。そこで、ここではプロジェクトを立ち上げる際の動き方について、特に重要になる点を説明します。

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

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

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

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

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

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

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

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

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

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

  • 図2-1

目標設定の悪い例

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

誰が何に困っているのか

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 注記

エンドツーエンドとは、利用者が、ある目的を達成するためにサービスを受ける必要があると考えた時点から、当該サービスを受け

たことにより目的を達成した時点、又はサービスを享受し終わった後の行動までに生じる、利用者の感情を含めた思考や一連の行動全体のこと。

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

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

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

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

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

◇ ◇ ◇

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

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

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

  • 図2-2

目標設定の改善例

  • ポイント 2-1

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

  • ポイント 2-2

事実を詳細につかむことも忘れずに

  • 事例2-1

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

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

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

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

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

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

  • 児童の学力向上

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

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

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

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

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

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

以下では、目標設定において重要な概念であるＫＧＩ/ＫＰＩについて説明した後、目標の紐づけの方法を示します。

「ＫＧＩ」「ＣＳＦ」「ＫＰＩ」の定義と関係

  • *重要目標達成指標（ＫＧＩ：Key Goal Indicator）* 政策目標等、プロジェクトの最終目標を達成するために管理すべき指標

  • *重要成功要因（ＣＳＦ：Critical Success Factor）* ＫＧＩを達成する（成功させる）上で重要となる要因

  • *重要成果指標（ＫＰＩ：Key Performance Indicator）* プロジェクトを推進し、新しいサービス・業務を実現することで重要目標達成指標を達成するために管理すべき指標

ここで、資格試験に合格するために勉強するという場面を想定して、これらの具体例を考えてみます。

資格試験の合格、すなわち「試験で70点以上取得」がこの場合のＫＧＩとなります。

では、このＫＧＩを達成するためのＣＳＦは何でしょうか。まずは、「十分な勉強時間を確保すること」（リソースの確保）が挙げられます。他には、自分の周りでこの資格を既に取得している人やこの資格の分野に詳しい人を見つけて質問できるようにしておき、「わからないことがあっても解決できるようにすること」（協力体制の確立）、「周りから邪魔されずに集中して勉強できる環境を確保すること」（阻害要因の排除）などが挙げられます。このように、ＣＳＦは、これらが揃えば確かに成功（目標を達成）しそうだと思える要因であることが大切です。

そして、ＫＰＩとして、「1週間あたりの勉強時間：10時間以上」、仕事が忙しくて勉強できないということがないように「1週間あたりの残業時間：5時間未満」などといった指標を設定します。ＫＰＩは、これらが達成されればＣＳＦ（ここでは「十分な勉強時間を確保すること」）が実現できたといえるような指標を設定します。

ＣＳＦは抽象的であるため、具体的に何をすれば良いのかわかりにくい場合がありますが、このようなＫＰＩを設定することで、自由時間を勉強に当てるだけでは1週間あたり3時間ほど足りないので、さらに勉強時間を捻出するために通勤時間に電車の中でも勉強できるように準備をする、資格試験までの期間は業務量が多くなりすぎないよう上司や同僚に相談するといった具体的なアクションを考えることができるようになります。

このようなアクションを通じてＫＰＩが達成されると、「これらが揃えば確かに成功（目標を達成）しそうだと思える要因」であるＣＳＦが揃うので、ＫＧＩを達成できる可能性が高まります。

  • 図2-3

ＫＧＩ/ＫＰＩは設定するだけでは意味がありません。モニタリングを実施し、プロジェクトの目標の達成度合いを評価することが重要です。そのためにも、ＫＧＩ/ＫＰＩはどのように測定するかについてもあらかじめ検討し、計測できる指標を設定しましょう。

また、モニタリングは、目標の達成期日になってから実施するだけでなく、継続的に実施して変化の度合いを把握し、それが不十分である場合は改善策を実施することが必要です。そのため、モニタリングの実施頻度（実施時期）、各時点での目標値をあらかじめ定めておくことが重要です。

KGI/KPIを策定する際に、将来の目標だけを設定するというケースがあるのですが、これに加えて現状（プロジェクト開始時点の状態）の水準も把握することが重要です。現状とのギャップが分かるように、目標を設定します。

そして、そのＫＧＩ/ＫＰＩの策定には様々な手法が存在します。以下では、その例として「ＫＰＩトレーサビリティ・ツリー」と「ＢＳＣ（バランスト・スコアカード：Balanced Score Card）」を用いてＫＧＩ/ＫＰＩを設定する手法を示します。

  • 事例2-2

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

  • 参考2-1

バランスト・スコアカードによる目標の紐づけ

  • 事例2-3

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

ＫＧＩ/ＫＰＩ策定にあたっての留意点

  • *定量化できる指標であること* 達成状況を正しく評価し、改善につなげるためＫＰＩは定量的な指標とする。 （「使いやすさ」といったあいまいで定量的ではないものは設定しない） 例） オンライン利用率、オンライン申請件数標

  • *客観性のある指標であること* 誰が見ても同じ内容で理解ができる客観的な指標とすること。 （ＫＧＩ/ＫＰＩを達成できるように、後から定義を変えないこと） 例) オンライン利用率、システム稼働率

  • *計測できる指標であること* 自動的に収集できるなど現実的な指標とすること。 例） ＷＥＢサイトのアクセスカウンターなど自動的に収集できるもの

  • *効果につながる指標であること* ＫＰＩは効果を推計できる強い相関がある指標を選定すること。 （ＫＧＩが最終目標でＫＰＩがそれを測るための中間の指標となります。ＫＰＩの達成がＫＧＩの達成につながるかが重要です） 例） 業務実施部門の経費削減（ＫＧＩ）に対して、事務処理を自動化するシステム（ＲＰＡ等）の利用回数

手段の妥当性を確認する

プロジェクトの立上げに当たって、プロジェクトの目標とする成果を定め、その成果を得るための手段が妥当であることを確認します。以下では、手段の妥当性を確認する観点について、例を示します。必ずしもこの分類で考える必要はありません。プロジェクトの特性、実状に応じて、本質的に確認すべき観点を事前に考えてみてください。

  • プロジェクト立上げ要否の検討

    • 情報システムを整備する必要があるか。 例えば、現行の業務では、担当職員が国民からの問合せを属人的に管理する問合せ履歴に記録しており、部署内での情報共有がうまくいっていないという課題があるとする。 この業務を情報システム化するプロジェクトの立上げの妥当性を評価する場合、そもそも情報システムを整備する必要があるのかを評価する。問合せ件数が少ない場合、情報システムを整備するのではなく、問合せ履歴を記録したExcelファイルを部署内の誰もが参照・更新できるような運用
  • 参考2-2

統計表における機械判読可能なデータ作成に関する表記方法 https://www.soumu.go.jp/main_content/000723626.pdf

方法に変更する という選択肢もあり得る。なお、その際は、機械判読可能な表記方法とすることに留意すること。 また、業務によっては現行の業務から変更しないという選択肢も合わせて検討する。

  • サービス・業務の見直し有無の確認

    • サービス・業務改革（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

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

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

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

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

  • 参考2-3

ＰＪＭＯの主要業務

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 事例2-5

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

  • 事例2-6

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

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

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

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

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

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

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

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

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

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

  • 事例2-7

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