Step.5 サービス・業務企画内容の検討

Step.５は、Step.４で可視化された現状の業務・システムに関する調査結果を基に、そこに存在する課題を分析し、新しい業務・システムの方向性を検討します。

Step.４でも書きましたが、現状の業務・システムの調査結果が、次の業務・システムの形（企画方針）を決める重要なインプットとなります。

課題を整理し、分析する

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

ここまでで集めた課題は、多岐にわたり大量なものとなっています。この中には、システムの操作がわかりにくいといったレベルの問題から、利用者にとって深刻なサービス低下を招きかねない課題もあり、同等には取り扱えません。目立つ課題が、必ずしも最優先で解決しなければいけないもの、とは言い切れないことが多いのです。

これらの課題を仕分けし、課題の関係性を明らかにしつつ、本質的な原因を探るための手法・ポイントについて、見ていきましょう。

優先順位・影響度・費用対効果による分析

課題を原因ごとにグルーピングした後は、それらの課題を利用者への影響度や費用対効果を基に優先順位付けし、主要課題を抽出していきます。

これらの関係性は以下のようになります。

• 図4-8

目標、個別の分析、課題の関係

優先順位付け時に気をつける点

• 利用者への価値最大化、及び、プロジェクト目標に対して影響度が高い課題を優先的に検討する。

• 対策の優先順位を検討する際は、影響度を鑑みて、費用対効果が高い対策を優先的に行う。

• 参考4-3

３Ｅの観点を踏まえた費用対効果の検討

企画案を作成する

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

現状把握を行う際には、あれこれと頭の中で考えることは後回しにして、まずは実際に発生している事実を詳細に把握することが重要と説明しました。

その現状把握が終わった今、これからはまさに頭を使って、企画案を練り上げるフェーズです。おっと、頭だけではありませんでした。足も使っていろいろな関係者の所へ出向きながら、企画の具体的な内容を調整していきましょう。

全ての関係者に気を配る

• 参考4-4

ウェブアクセシビリティ導入ガイドブック（https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook/ ）を参照の上、障害があるなど様々な状況にいる利用者や関係者へ配慮すること。

企画案を作成する人は、どうしても自分の視野に見える範囲で考えてしまいます。自分の視野、自分の組織だけでなく、サービスを受ける利用者、関係者全体を見渡して、特定の人に不便なことが発生しないように配慮しましょう。例えば、視覚や聴覚等に障害がある人が情報システムを利用する可能性があるので、サービス・業務の企画の段階からアクセシビリティの要件を検討することが挙げられます。

また、特に、企画案の方向性を決めるときには、発言力の強い人や現場経験の長い人の一言に左右されがちですが、客観的な調査の結果に基づき、関係者全体のニーズや困りごとを踏まえて決定することが重要です。

さらに、サービス・業務で用いる情報システムが、他の情報システムと新しく連携する際は、連携先に与える影響について企画案を作成する段階から十分に考慮してください。情報共有や影響度の調査が不十分な場合、連携先のサービス・業務に思わぬ改修が必要となり、連携先に多額の変更コストを発生させることがあります。

サービスは様々な関係者によって成り立っています。利用者だけでな く、全ての関係者についてどのような影響が発生するかを分析し、Ｗｉｎ-Ｗｉｎを目指すことが重要です。

• 事例4-9

利用者の状況の調査不足でシステム改善が迷惑化

利用者の日常体験に溶け込む

利用者の視点で考えると、行政サービスを受けるためだけにわざわざ行動するのは面倒ですね。利用者の日常の行動の中で何かのついでに行政サービスを受けることができると、とても便利になります。

企画案を作成する際には、利用者に新たな手間を増やすという方向でなく、新たに手間を増やさなくても既存の活動の中で完結できる方策を検討してみましょう。

• 事例4-10

利用者が日常的に使用するソフトウェアからのＡＰＩ申請

縦割り組織にやわらかく横串を刺す

他の行政機関や民間企業が担うサービスの利用まで含めて、利用者の行動全体を一連の流れとして考えることの重要性を前段で述べました。このようにエンドツーエンドの視野で分析を行うと、新しい企画案を作成するためには、他の行政組織や民間サービスとの連携が必要となることに気づきます。

さて、ここで大きな分岐点があります。あなたは、どちらの方向性で検討を進めていくでしょうか。

1. 他組織の所掌範囲に踏み込むことは越権行為になる。他組織へもこれまでの検討結果の情報提供は行うが、その上で自分自身は自組織の範囲内で検討を進める。

2. 自らが主体となり他組織を巻き込んで組織横断的な検討組織を立ち上げる。その検討組織で全体的な方向性や各組織の実施事項をまとめる。

残念ながら、実際の検討の現場の中では、(1)に近い発言をする人が目立ちます。もちろん、行政組織の成り立ち上、他組織の所掌範囲に踏み込んで指示をするようなことになれば確かに越権行為と言われかねません。

ただ、他組織の中の職員も、自発的に同じ方向性で検討を進めるようになったのならば、全く問題はありません。そういう状態になるように、周りを巻き込みながら調整を進めること、このことこそ縦割り組織の弊害が激しい現状の中で、一番求められている行動です。

言うまでもありませんが、このような調整に高圧的、感情的な発言は全く不要です。また、書面での一方的な連絡をもって他組織との調整を実施した証跡を作るといった小細工も全く不要です。縦割り組織の中に力ずくで横串を突き刺しても、組織にヒビが入るだけで組織の連携にはつながりません。

まずは、自らが調査、分析してきたこと、そして企画の方向性についてわかりやすく説明する資料を作成した上で、関係する組織の職員とフェースツーフェースで話をする。課題が出れば持ち帰って、また話をする。そうやって関係する組織の職員と方向性が合ってきた段階で、関係者を集めた会議を組織する。そのように、丁寧に時間をかけながら段階的に調整を進めていくというのが、調整巧者の王道であるように思います。

必要に応じて制度自体を見直す

サービス・業務を利用者視点で見直す際に、既存の制度やルールが制約になることがあります。

既存のルールを変えることには、大きな労力を伴います。組織内部で定めたルールであっても、変更する理由を関係者に理解してもらうには時間がかかるでしょう。まして、法律、政令、省令等の変更が必要とならば、改正に向けた体制を確立することから始めて相当な準備、調整を行うことが必要です。

そういったことが見えているので、多くの人は既存のルールには手をつけないでおこうと考えてしまいます。利用者に回り道のような面倒な手続をさせることで既存のルールを回避したり、利用者が不満に感じていることについてもルールがあるから仕方がないと諦めたりといった事態になりがちです。残念ながら時々耳にしてしまうのが、「私の仕事は定められたルールに則って実施するもの。ルールを決めるのは私の仕事ではない」といった開き直った言葉です。もちろん定められたルールにのっとることは大前提ですが、その業務の中で問題があることを把握したときに、どうすべきかを考えるのか、それとも考えるのを放棄してしまうのか・・・。先ほどの言葉は、後者を選んだ人の自己弁護のための言い訳のように聞こえます。

「でも、私だけではどうしようもできない」。業務実施部門の一担当者、情報システム部門の一担当者だけでルールを見直すことは確かに困難です。

まずは、問題を可視化することです。利用者に対してどのような不便をかけてしまっているのか、その問題はどれくらいの頻度で発生しているのか、利用者がそのためにどんな苦労をしてしまっているのか、事実に基づいて問題状況を可視化します。現実に発生している問題を端的に可視化することができれば、その資料は関係者の間に自然と伝播していきます。この資料は関係者の注意を引き付け、そして関係者を団結させて、意思決定に至るための重要なツールになります。

そして、問題が関係者で認識された後は、プロジェクトの体制を確立することです。本書の第２章（プロジェクト管理）でも三位一体の体制として、制度所管部門、業務実施部門、情報システム部門でPJMOの体制をつくることを挙げています。

現実社会において、制度が正しく運用されるようにするところまでが制度所管部門の重要な役割です。これらの部門が一体となり、真に必要性が高いのであれば法律、政令、省令等の変更も含めて対応を行っていくことが、利用者視点でのサービス・業務改革の真骨頂と言えます。

システムを作る前に、業務を標準化する

システムを作った後でよくトラブルになるのが、ローカルルールの存在です。

書類の審査１つをとっても、業務マニュアルに書いている審査手順や審査項目はあくまで基本形に過ぎず、いろいろな拠点で審査項目を追加したり審査手順すら変更されていたりします。このような状態のままで業務マニュアルを前提にシステムを作っても、うちの現場では使えないといった反発が多発してしまいます。

前段で説明したように、現場へ行き、現場の業務マニュアルや引継書等のドキュメントを入手すると、このようなローカルルールの実態をよく把握することができます。その上で、これらのローカルルールをそのままにするのではなく、業務を標準化することを検討します。

ただし、ここで注意すべきポイントがあります。「標準化」と、かたくなな「一本化」は異なるということです。標準化とは、何が何でも１つに統一することではありません。ローカルルールが発生した背景を調べた上で、それが組織全体に横展開すべき工夫であれば全体ルールに取り込むべきです。しかし、ローカルルールが発生した背景が、その現場でのサービス内容、地域特性、規模特性、利用者特性等、その現場だけの特性に基づくものであれば、それを無理やり全体ルールに合わせるとかえって不都合が発生してしまいます。そのような場合は、全体ルールだけでなく必要に応じた個別ルールも設定するといった複層的な対応を行います。これが、標準化の考え方です。

システム開発の工数、費用を抑制する観点からも、システムを導入する前には業務を標準化することが必要です。ただし、ここで標準化の意味を取り違え、何が何でも統一するという一本化の考えに立ってしまうと、現場に役立つシステムはできません。似て非なる両者の違いに留意して、本当の標準化を目指してください。

将来の業務フローには、効果を紐づける

企画案についてある程度の方向性が見えれば、その案をプロジェクト内外の関係者にわかりやすく説明して、さらに改善点等のフィードバックを受けたいですね。

その際の最も有用なツールが、将来（ToBe）の業務フローです。

前段の作業で、現行（AsIs）の業務フローについては準備ができています。この現行業務フローをベースにしながら、将来ではどこがどう変わるのか、その変更点を明確にプロットしていきます。システム化により業務効率の向上や負荷が軽減される、システム化により場所的な移動を伴わずに業務ができるようになる、システム化により事前準備していた添付書類が不要になる、このように業務フローの様々なポイントで、変更する点を記載できます。

このように将来の業務フローを作成する際には、変更点を淡々と記載するだけではなく、その変更によってどのような効果が生まれるかをわかりやすく記載することをお勧めします。以下のサンプルでは、吹き出しの形式で効果を示しています。このように想定効果を業務フローに紐づけることによって、効果積算の根拠が明確になるとともに、関係者に対しても目指す姿をわかりやすく共有することができるようになります。

• 図4-9

業務フロー(将来)の定義例

精緻に効果を積算し、主要な効果を実感可能なものとする

効果は業務フローに紐づけるとわかりやすくなると説明しました。

では、紐づけられたそれぞれの効果の大小を定量的に示すには、どのような積算を行えばよいでしょうか。

効果算定の基本となるのは、「１件あたりの効果」×「件数」という掛け算です。業務時間の削減効果であれば、「業務１件あたりの削減時間」×「業務件数」や、「職員１人あたりの削減時間」×「職員数」といった掛け算になるでしょう。また、国民の満足度向上など定性的な効果が見込める場合であっても、「満足度調査で大変満足と満足の合計の割合が8割以上」のように定量的な指標を設定することができます。

具体的に、国民の利便性向上や経済効果が見込まれる場合を考えてみましょう。事業者が製品を販売するために国の認可が必要となる場合のように、国に対する申請自体が事業者の売上や利益に直結する場合には、申請から認可取得までの期間の短縮により、事業者の販売の機会が増え、売上や利益の拡大に繋がります。 このような場合、「情報システムの利用によって短縮された期間に申請者が得られると推測される利益/件」×「情報システムを利用した申請件数」という掛け算により効果を算出できます。

また、別の例として、届出のワンストップ化など、国民及び利用者の負担軽減、又は行政事務の省力化等のように経費の削減を目的とした場合は、「デジタル化による削減効果/件」×「当該システムを利用した申請件数」という掛け算により効果が算定できます。

ただし、これらの掛け算を安易に実施してしまうと、積算された効果が過大（又は過小）になってしまうことがあるので要注意です。効果を積算する過程では、業務の全件を調査することは難しいので、サンプリングを行うことが多いでしょう。このとき、母集団を正しく分類しないままサンプリング対象を選ぶと、その調査で得られた効果想定（１件あたりの平均効果）は全体を正しく代表していません。その状態のままで「件数」を掛け算すると、調査で発生した誤差が大きく引き伸ばされることになり、結果として積算された効果が実態と大きくかい離してしまいます。

では、良い例は、どのようなものでしょうか。それは、効果積算に用いる原単位が、全体を正しく代表する単位となっていることです。業務の中で、効果の観点から特徴が大きく異なるグループがあるのであれば、それぞれのグループでサンプリング調査と効果積算を行い、それらの数値を合計することで正しい数値を積算します。

• 図4-10

このように、サービス・業務の処理単位、実施担当部門、処理する場所等で対象を分類した上で、可能な範囲で詳細な積み上げを行うようにしてください。例えば全国規模で多拠点の業務窓口を持っているところであれば、都市部、地方、山間離島等といったグループに分けて積算することが良いかもしれません。若しくは、利用者向けのサービスメニューで分ける方法もあるかもしれません。効果を積算するに当たって、条件がほぼ同じと考えられるグループに分けて、それぞれのグループで調査と積算を行うことが重要なポイントです。詳細な単位で効果を積み上げることによって、実際にサービスを開始した後のモニタリングにおいても、効果の計画と実績の差を精緻に管理することができるようになります。

また、もう１つ重要なことがあります。精緻に効果を積み上げていくと、効果の小さなものから大きなものまでが合わさり、複雑な計算過程を経て、第三者にわかりにくくなることがあります。

効果の積算結果を多くの関係者から理解してもらうためには、効果全体の中で特に大きな比率を占める主要部分について、その積算方法をわかりやすく示すとともに、確かにそれだけの効果が出そうであると実感できるような補強材料（別観点からの検証や実例等）を準備することが大事です。例えば、ある地方拠点では利用者が手続をするためだけに週１回、往復３時間をかけて施設へ来所する必要があり大きな負担になっているが、システムを整備することでそれが不要になるとすれば、利用者にとって大きな効果です。このようなリアルな実態を踏まえた事例を効果積算の説明として加えることで、関係者の理解をより深めることができます。

• 事例4-11

業務削減効果の積算方法の見直し

オープンにサービスを作る

内部の職員だけで企画案の全てをまとめ上げる必要はありません。むしろ、検討段階から積極的に利用者を巻き込んでオープンにサービスの在り方を議論した方が、内部職員だけでは気づけない利用者視点でのニーズを拾いやすくなります。

制度変更等も視野に入れた比較的大規模な検討を行う場合は、外部有識者を交えた検討会を開催する形が一般的な進め方です。検討会の資料や議事等を適時に公開することで、検討会の出席者以外にも広く検討状況を共有します。

また、パブリックコメントを実施することも一般的な進め方です。企画案がある程度まとまった段階で企画案を公開し、国民からの意見を募集した上で企画案を再検討します。

ただ、このような検討会やパブリックコメントといった進め方だけでなく、さらに現場に近いレベルで検討の早期段階から利用者の意見を取り入れる方法もあります。

その一例が、ワークショップの開催です。サービスに関係する様々な立場の利用者、関係者を集めて、現状の問題点を共有した上で、今後のサービス改善の方向性等について意見交換を行います。

ワークショップで参加者が意見を出しやすくするためには、ワークショップ開催までの準備も大切です。前述の利用者視点での分析（ペルソナ分析、ジャーニーマップ等）やサービス・業務の基礎的な情報（サービス概要、利用量等）をあらかじめ提示しておけば、基本的な前提を共有した上で現状の問題点等について効率的に意見の整理を行いやすくなります。

また、パブリックコメントといった正式な手続だけでなく、Webサイト等で適時に検討状況を公開している例もあります。検討案が固まりきった段階で初めて内容を公開するのではなく、検討を進める過程の中で段階的に内容を公開することで、検討経緯や方針決定理由が明確になりますし、利用者や関係者の意見を十分に取り入れることが可能になります。

このようにプロジェクトの状況を公開することは、企画時点だけでなく、システム開発を行っている時や、サービス開始後でも同様に重要になります。特に、国民全般、企業全般、自治体等の関係組織全般に関わるようなプロジェクトについては、プロジェクトの方針、進捗状況、サービス提供状況等について適時に公開するとともに、利用者や関係者の意見を収集できるように考慮してください。

• 事例4-12

案段階の企画内容をWebサイトで公開

企画案を客観的に見直してみる

企画案の骨子が固まってきたら、ここで一度、クールダウンしてみることも重要かもしれません。企画を作っている人は、どうしても企画への思い入れが強くなるため、多くの目的を一度に達成しようとしたり、自らの力で全てを作ろうとしたり、少し力みの入ったプランになることがあります。

外部のサービスもうまく取り入れながら、段階的にバランスよくサービスを作り出すために、次のような観点から企画案を眺め直してみて、改善の余地がないか検討してみてください。

サービスはシンプルにする

複雑なサービスは、利用者が理解できず、サービス利用への大きな障壁になります。既存の制度、ルール、業務分担がある中で新しいサービスを生み出そうとすると、既存の制度等を残存させながら新たなやり方を追加するといった屋上屋（おくじょうおく）を重ねる形になりがちです。前述の「縦割り組織にやわらかく横串を刺す」に記載したことと重複しますが、利用者の視点から極力シンプルにサービスを利用できるように、既存の制度等の見直しも含めて検討してみてください。

特に、利用者に提出や入力を求めるような「手間」が発生することについては、今の企画案で本当に「最小限」になっているか、逆に行政側から提供する情報が過多になっていないか、利用者にとって必要性の高い情報をわかりやすく提供できるようになっているかという観点で、確認してください。

また、システムの使い勝手についても同様です。システムを初めて利用する人やＩＴに詳しくない人でも、自力でサービスを利用して完結できる状態が理想的ですね。実際にシステムの画面等を考えるのは設計段階の話になりますが、企画段階においても利用者の操作性について必要な配慮が行われているか、今一度確認しましょう。

デジタル技術を徹底的に活用する

デジタル技術は日々進化しています。今までは手間を掛けなければできなかったことが、デジタル技術を活用することで飛躍的に効率的に実施する可能性があります。

例えば、このようなキーワードに該当する活動がないでしょうか。企画案や業務内容を見直してみて、デジタル技術をもっと活用できる余地がないか検討してみてください。

• 注記

IoTとは、「Internet of Things」の略称。従来のＩＴ関連機器のみならず、家電やセンサーなど、あらゆる物がインターネットにつながる仕組みのこと。

遠隔地からのモニタリングを人手で実施している → ＩｏＴ技術、センサー技術等を活用してモニタリングを自動化できないか

• 熟練者による目視点検で品質や老朽化状況の確認を行っている。 → ＡＩ、画像解析技術等を活用して、効率的かつ高度な確認が行えないか

• 申請内容の形式的なチェックを人手で実施している → ＡＩ等を活用して自動審査できないか

• 複数のシステムに同じ情報を再入力している → ＲＰＡ等を活用して、作業を自動化できないか

• 電話で問合せへの対応業務を行っている → 定型的な質問へはチャットボット（音声やテキストで自動応答する仕組み） 　　等で対応できないか

• 業務やシステムで収集したデータを十分に分析できていない → データ分析ツール等を使って、サービス改善への基礎分析を行えないか

また、情報セキュリティとプライバシーを確保する観点からも、ITマネジメント全体を通してリスク管理を適切に行い、情報セキュリティ対策を確実に行うデジタル技術の活用が重要ですし、自動運転、ドローン等、高度なデジタル技術を前提とした新しい仕組みも活用できる可能性があるかもしれません。

なお、各府省がデジタル技術を活用することも重要ですが、各府省が保有するデータをオープンデータとして活用し易い形で公開することによって、国民や民間企業等の外部関係者がデジタル技術を効率的に活用できるようにすることも重要です。このことについては、第５章「要件定義」のデータ・情報に関する事項と併せて十分に検討してください。

情報システムではなくサービスを作る

「システムを作ることが目的化する」という言葉がよく聞かれます。利用者が実感できる効果を達成するといった本来目的を達成するための手段としてシステムを作るはずだったのに、いつのまにかシステムさえ作ればよいと、システムの整備完了のみが目的化する状態です。

特にシステム整備の中でＡＩのような最新のデジタル技術を使うときには、注意すべきことのように思われます。前述したように、デジタル技術を徹底的に活用すると大きな効果を得ることができます。しかし、サービス・業務をどのように変えるかという明確な目的がなく、ただＡＩを導入すれば何とかなるだろうといった進め方では、効果がうまく得られません。ＡＩを入れれば業務課題が自動的に解決するわけではなく、ＡＩを適用すべき範囲に正しく導入してこそ効果を生み出すことができるからです。

むしろ、全ての範囲をシステムが担うのではなく、一部は人手による作業を交えた方が、サービスの品質を上げられることもあります。

システムを作ることも同じです。システムは、あくまで手段です。全てを情報システムで実現するのではなく、必要に応じて人手によるサービス等も組み合わせて、最良のサービスを利用者に提供するという本来の目的を最優先に考えましょう。

自分で作りすぎない

サービスを一から自分で作ることも選択肢ですが、もっと効率的に作る方法はないでしょうか。民間サービスで活用できるものがあれば、そのサービスを活用した方が良いかもしれません。職員採用のWebサイトを立ち上げるなら、民間の人材採用Webサイトのサービスを利用した方が良いかもしれません。

また、ＡＰＩ連携を使うことも有効です。前述の事例（利用者が日常的に使用するソフトウェアからのＡＰＩ申請）で説明したe-Govでは、利用者が日常的に利用する労務会計ソフトウェア等から電子申請が行えるようにしました。これを可能としたのが、ＡＰＩ連携です。

行政自らがサービスを作るだけではなく、過剰な機能や独自技術の活用を避け、多くの人から利用しやすくするように心掛けることが重要です。

外部に丸投げしない

自分で作りすぎないことを前述しました。一方で、自らが責任を持ってプロジェクトを運営することは最も基本的な大前提です。自分で作りすぎないという考え方を言葉尻だけで捉えると、必要な予算だけは確保し、あとは委託事業者や補助金分配先の関係機関が実施すればよいと強弁する人がいるかもしれませんが、これは全く推奨できない進め方です。

あくまで、サービス、業務、システムを作り運営する主体は、プロジェクトの運営を行うＰＪＭＯ自身です。もちろん、全ての作業を職員自らが行う必要はなく、委託事業者との契約や、補助金による関係機関主体での対応を依頼することもできますが、その際においてもプロジェクト全体としての目的達成のために、サービス・業務の改革方針を立て、システム整備の方針を立て、プロジェクトの進捗を管理し、サービス開始後も運営状況を確認し改善を続けていくのはＰＪＭＯ自身です。

そのため、複数の関係機関が連携して対応を行うプロジェクトについては、ＰＪＭＯ自身がプロジェクトの運営を確実に行えるという観点から、システム整備の形態（分散型、集中型等）、システム整備の進め方（仕様の共通化、スケジュールの全体整合等）を検討することが必要です。

• 注記

ユーザインタフェースとは、ユーザから見た「見た目」。アプリケーションの画面デザイン（色、情報の配置、操作ボタンの位置等）のこと。ＵＩとも呼ばれる。

• 事例4-13

個別管理システムを統合してサービス向上とコスト削減を実現