第４章 サービス・業務企画
デジタル・ガバメント推進標準ガイドライン
実践ガイドブック
第４章 サービス・業務企画
目次Step.1 サービス・業務企画活動全体の流れ
Step.2 サービス・業務企画の開始準備
１ サービスデザイン思考を理解する
A. 心構えと視点（サービス設計12か条）を理解する
Step.3 利用者視点でのニーズ把握
１ 利用者のことを知る
A. どんな利用者がいるかを調べる
B. 利用者の人数を把握する
２ 利用者のニーズを理解する
A. 利用者のニーズから出発する
B. エンドツーエンドで考える
Step.4 業務の現状把握
１ 業務を観察する
A. 事実を詳細に把握する
B. 推測ではなく、現場で発生している事実をみる
C. １か所だけの現場分析結果を全体に拡張しない
D. 日常的に業務の課題を収集し、分析に利用する
２ 実績データを分析する
A. 平均、合計ではなく、ばらつきを見る
B. 時間と期間を区別して滞留状況をつかむ
C. 業務量のピークを捉え、ピークの発生原因を把握する
D. 問合せや要望は、根本原因が同じになる粒度まで分類する
３ 業務を可視化する
A. 様々な立場の人が理解できる業務フローを作成する
B. 業務ルールや業務実施方法をまとめる
Step.5 サービス・業務企画内容の検討
１ 課題を整理し、分析する
A. 優先順位・影響度・費用対効果による分析
２ 企画案を作成する
A. 全ての関係者に気を配る
B. 利用者の日常体験に溶け込む
C. 縦割り組織にやわらかく横串を刺す
D. システムを作る前に、業務を標準化する
E. 将来の業務フローには、効果を紐づける
F. 精緻に効果を積算し、主要な効果を実感可能なものとする
G. オープンにサービスを作る
H. 企画案を客観的に見直してみる
Step.6 軌道修正
１ 軌道修正しやすい進め方にする
A. 一遍にやらず、一貫してやる
２ 柔軟に軌道修正する
A. 何度も繰り返す
B. 無理に継続しない
Step.7 新しい業務要件の定義
１ 業務要件をまとめる
２ 定義内容を関係者に共有する
【コラム】外部委託事業者の関わり方
A. 事業者と役割分担して作業を進める
事例：自動車登録検査業務における利用者分類
参考：ペルソナ分析
参考：ジャーニーマップ
事例：現場の業務と合わないサービスを提供し活用されなかったシステム
事例：１か所のみだった現場調査を改善
事例：１件１件の業務処理の滞留状況を可視化（ヘビ図）
事例：関係者間を往復する複雑な処理状況を可視化（シーケンス図）
事例：利用ピークの分析を活かして電子申請利用率を向上
事例：根本原因が特定できるまで詳細な分類を行う
事例：業務は複数の切り口で表現すると漏れなく可視化できる
事例：利用者の状況の調査不足でシステム改善が迷惑化
事例：利用者が日常的に使用するソフトウェアからのＡＰＩ申請
事例：業務削減効果の積算方法の見直し
事例：案段階の企画内容をWebサイトで公開
事例：個別管理システムを統合してサービス向上とコスト削減を実現
事例：一部地域で試行してから、サービスを全国へ展開
様式例：業務要件定義書のひな形
Step.1 サービス・業務企画活動全体の流れ
サービス・業務企画は、まさにプロジェクトが実現したい将来像を具体化する活動です。そして、その土台となるのは、利用者視点でのニーズ把握と業務の現状把握です。現状把握からプロジェクトを推進する上での制約条件、前提条件、リスク及び問題点を抽出してから分析の上、それらへの適切な対応の検討を怠った企画は、ほとんど失敗してしまいます。
政府の各種プロジェクトにおける過去の経験を踏まえ、サービス・業務企画を的確に行うための心構えと視点として「サービス設計12箇条」があります。本ドキュメントでは、このサービス設計12か条を具体的に実践するための作業の進め方やノウハウについて、事例を交えて説明します。
本ドキュメントの構成は、次のとおりです。
Step.2 サービス・業務企画の開始準備サービス・業務企画を開始する前に、理解すべき心構えと視点を説明します。後に続く全ての作業の前提となる内容になっていますので、最初に目を通してください。
Step.3 利用者視点でのニーズ把握利用者視点でのニーズを把握するためには、まずどのような利用者が存在するかを把握した上で、利用者の立場に立ってサービスの現状を考えることが重要です。そのような利用者についての分析手法について説明します。
Step.4 業務の現状把握何かを変えようとするときには、まず今がどうなっているかを正確に把握することから始めましょう。ですが、むやみに情報をかき集めても、整理しきれず、重要な情報の抜け漏れを招くおそれがあります。ここでは、現状の業務やシステムを理解するためには、どの情報をどのように集め、整理すればよいのかを説明します。
Step.5 サービス・業務企画内容の検討現状の業務・システムを調査した結果を基に、課題をどのように把握し分析するのか、さらに、その分析結果から次の業務・システムの方向性を決める過程で気をつけるべきポイントと、新たなサービス・業務に向けた企画案を作成する手順や注意点について説明します。
Step.6 軌道修正プロジェクトの方針は、把握した情報に応じてより良いものに見直されるべきものです。その見直しの判断条件をどのように定め、変更した場合の影響をどのように扱えばよいかを説明します。
Step.7 新しい業務要件の定義Step.２、３で把握した現状をベースに、Step.４、５で検討した次の業務・システムの方向性に則り、次の新しい業務に関する要件を定めていく過程を具体的に説明します。
Step.2 サービス・業務企画の開始準備
医師は、まず患者の話をよく聞き、どのような症状が出ているかをよく調べます。患者の症状をほとんど調べず、いきなり手術するような、そんな医師にはかかりたくないですね。システムを作るときも同じです。まず、今のサービスや業務の現状をよく調べます。そして、誰が何に困っているのか、その背景にどのような事象が発生しているのか、事実を正確に把握するのです。
今までの政府のシステム整備プロジェクトでは、往々にして事前調査のプロセスを簡略化し、システムを作ることが先行する傾向がありました。そのような進め方では、サービスの利用者がよくなったと実感できる効果を出すことはできません。そこで、「サービスデザイン思考」を導入しようという声が高まりました。サービスデザイン思考に基づいた活動の中では、利用者の立場になり利用者と協働しながら、実際に発生している事実を正しく把握した上で、段階的にサービスや業務を改善していきます。
この章では、サービスデザイン思考というものが何なのか、そしてサービスデザイン思考に沿って企画を行うためにどのような活動を行うべきかについて、具体的に解説します。
１ サービスデザイン思考を理解する
【標準ガイドライン関連箇所：第３編第４章第１節】
サービスデザイン思考とは何でしょうか。サービスデザインを進めていくに当たり、概念や方法論などを整理したものなのですが、言葉を２つに分けて考えてみましょう。
まず、行政による「サービス」についてです。簡単に言えば、国民生活の安定と向上のために、国や地方自治体等が国民や企業に対して何かをするといった行動そのものです。(注記:サービスとは、公共サービス基本法（平成21年法律第40号）第2条では、「公共サービス」について、「国民が日常生活及び社会生活を円滑に営むために必要な基本的な需要を満たすもの」と定義されたもの。)
次に、「デザイン思考（Design Thinking）」についてです。「デザイン思考」とは、デザイナーがデザインを行う際の進め方や考え方を適用して、利用者中心の視点からビジネス上の問題点を解決する方法です。この方法では、サービスの利用者がどのように振る舞い、どのように考えているかを理解した上で、利用者体験全体をデザインします。
言葉をつなげると、「サービスデザイン思考」とは「サービス」＋「デザイン思考」であり、「サービスの現状における課題を、デザイン思考を用いて解決しよう」という考え方や手法のことを表しています。
A. 心構えと視点（サービス設計12か条）を理解する
利用者中心の行政サービスを提供し、プロジェクトを成功に導くために必要となる重要な考え方については、デジタル・ガバメント実行計画において「サービス設計12箇条」としてまとめています。これらは、利用者中心としてサービスを設計するサービスデザイン思考を具体化したものであり、これまでのサービス・業務改革（ＢＰＲ）の取組から得られたノウハウをベースとしつつ、サービス改革に関する近年の国際的な動向を取り入れたものです。
本章では、このサービス設計12か条に示された心構えと視点を具体的に推進し、サービス・業務改革（ＢＰＲ）を実現するための実践的な解説を行っています。
図4-1 サービス設計12か条
まず最初は、利用者のニーズ把握から出発し、業務の現状把握を通して企画案を検討しますが、そのプロセスを何度も繰り返し、プロジェクト初期の想定と異なる結果になると判明した際は、計画全体を柔軟に軌道修正します。
なお、サービス設計12か条は、全工程を対象とした心構えと視点を表すものですが、とりわけ企画時点で重要になるポイントが多いこともあり、本章でまとめて解説を行っています。
また、本章の解説の中では、サービス設計12か条を補足する意味合いで、さらに注意すべき観点や参考にすべき考え方等を追記しています。
Step.3 利用者視点でのニーズ把握
利用者視点で考えるという言葉は、あまりにも当たり前のことのように思うかもしれません。
そこで、最初に簡単なテストをしてみましょう。あなたが現在担当している業務について、考えてみてください。
まず、利用者の顔が、何人分思い浮かぶでしょうか。窓口サービス等で日々利用者に接する業務に従事する人であれば、すぐに数十名の利用者の顔が思い浮かぶでしょう。一方で、間接的な業務が中心の人は、あまり具体的な顔が思い浮かばないかもしれません。
次に、そのうち１人の利用者を思い浮かべてみて、その人のことをどこまで知っているか考えてみましょう。名前、住所、家族構成、職業、勤務時間、通勤経路、趣味、・・・。利用者からの相談業務に従事する人は詳細な状況を知っているかもしれません。しかし、多くの場合は、利用者がサービスを受ける瞬間の状況しか見えないので、あまり詳細な状況を知るチャンスはないかもしれません。
テストはこの２問で終わりです。どうでしょうか。意外と利用者のことを知らないということに気づいたかもしれません。でも、心配はいりません。利用者のことを知っていると思い込むよりも、利用者のことを十分に知らないと認識した上で、利用者の状況をしっかり調査することの方が何倍も重要なことだからです。
それでは、利用者の状況を把握する方法を見ていきましょう。
１ 利用者のことを知る
【標準ガイドライン関連箇所：第３編第４章第２節】
民間企業が提供するサービスでは、利用者の人数を少なくても１日単位で把握し、週単位、月単位等で集計を行いながら利用者数の変化を機敏に察知しています。１日単位どころか、１時間単位、１分単位で利用者数を把握している企業も多いでしょう。例えばWebサイトで広告や販売を行っているサービスであれば、アクセスログを分析し、利用動向がすぐに把握できるように工夫しています。利用者数が、企業の収益に直結するからです。
行政機関が提供するサービスでは、利用者数を詳細に把握できているでしょうか。確かに窓口でのサービスであれば、１日ごとの利用者数を把握しているところも多いかもしれません。でも、システムの利用者数となると、アクセスログとしてシステム内に記録しているはずだけど、その集計結果を見たことがない、ということもありそうです。
しかし、行政機関においても利用者のことを知ることは不可欠です。民間企業であれば、サービスが悪い企業は自然淘汰されます。しかし、行政機関については基本的に他の選択肢がないので、サービスが悪くても利用者は使い続けるしかありません。だからこそ、行政機関は利用者の状況を知り、サービス内容が十分になっているか、改善すべき点がないかを自ら把握することがとても重要になります。
新しいサービス・業務を企画する際にも、まず利用者を知ることからスタートしましょう。
「どのような利用者が」「どこに」「どれくらい」いるのか、その利用者は「何のために」「どのように行動し」「何を求めて」いるのかを事実に基づいて把握し、情報を整理していきます。
なお、利用者とは、外部の利用者に限りません。内部の職員も利用者の１人です。職員自身が情報システムを利用してサービスを提供したり、様々な業務を実施したりするのであれば、その職員が業務を実施しやすいように十分な考慮を行うことが重要だからです。
A. どんな利用者がいるかを調べる
まずは、どんな利用者がいるのか、利用者の種類を調べるところがスタートです。一般的には、次のような分類から考え始めると考えやすいかもしれません。
利用者の分類の例
・ サービスの利用目的による違い
サービスの利用の仕方で分類します。例えば、行政機関に証明書発行を求める直接的な利用者がいる一方で、その証明書を確認することで業務を行う間接的な利用者がいます。
・本人か代理人かによる違い
実際に手続等を行うのが、手続の主体となる本人か、それとも本人から委任を受けた代理人であるかで分類します。代理人による申請の場合は、委任状が必要になるなど必要書類や事務手続が異なる可能性があります。
・個人か法人かによる違い
個人と法人では手続の目的、内容、手段が大きく異なる可能性があります。例えば、企業等の法人が日常的に申請を行っている場合は、１つの手続ごとに窓口に来るのではなく、まとめて一括で申請を行っているかもしれません。また、申請のためのシステムを企業内で整備しているかもしれません。
・詳細属性ごとの違い
上記の分類に加えて、さらに地域別、世代別、世帯構成別など、ニーズの特性が異なるグループがあれば、詳細に分類することで個々のニーズを捉えやすくなります。
| 事例：自動車登録検査業務における利用者分類
利用者の分類は、抽象的な表現だけでは実感しにくいので、具体例に基づいて考えてみましょう。 自動車の登録検査業務（新規登録、継続検査（車検）等の業務）について、様々な種類の利用者が関わっています。 まず、自動車の所有者自体が個人であることもあれば法人であることもあります。また、継続検査等の手続は、自動車所有者本人が直接行うこともありますし、自動車の販売事業者、整備事業者、行政書士等の代理人が行うこともあります。また、これらの手続は運輸支局で実施しますが、オンラインで行える仕組み（ＯＳＳ：自動車保有関係手続のワンストップサービス）でも実施できるので、ＯＳＳ経由で本人申請や代理人申請を行う利用者が存在します。これらが、直接的な利用者の代表例となるでしょう。 一方で、これらの利用者へのサービスを提供しているのは運輸支局等の職員です。職員が効率的に業務を行えなければ、直接的な利用者へのサービスの品質は低下してしまいます。よって、これらの職員についても、利用者として十分に考慮する必要があります。 また、間接的にサービスを受ける利用者も存在します。上記の手続完了後に自動車検査証（車検証）が発行されますが、その車検証は様々な人が様々な目的で確認します。例えば、警察による路上調査、損害保険会社による自動車損害保険加入時の確認、フェリー会社による自動車積載時の全長・車幅の確認等があるでしょう。車検証の形態や内容を変更することがあれば、これらの間接的な利用者にも十分に配慮することが必要となります。 このように、１つのサービスであっても、その利用者は多岐にわたることがあります。利用者を漏れなく把握して分類することが、利用者を理解するための第一歩となります。 |
利用者の種類を把握する手法には、以下のようなものがあります。
利用者の種類を把握する手法の例
・ 現在のサービス・業務を利用している現場での観察
・現在使用している業務マニュアル、手順書等の確認による利用者の洗い出し
・業務データや各種ログ等の分析による利用者の洗い出し
・想定する利用者に対するインタビュー、アンケート
利用者を把握した結果の整理方法としては、定量分析と定性分析があります。
利用者の定量分析は、利用者を洗い出し、種類ごとに量、利用時間帯、拠点等の情報をまとめたものです。これらは効果指標の基礎情報になりますので、正確で詳細な情報を収集してください。
利用者の定性分析は、利用者の種類、特徴、満足度、要求事項等を収集しまとめたものです。個々のサービス・業務ごとに一覧を作るのではなく、利用者から見たエンドツーエンドの範囲を網羅した一つの表でまとめると良いでしょう。基本的には利用者１種類を１行として整理しますが、年齢や性別、拠点等の特徴ごとに細分化して詳細を把握することを推奨します。
B. 利用者の人数を把握する
利用者の種類を把握することは比較的簡単ですが、利用者の人数を把握することは難しい場合があります。サービスの直接的な利用者であればまだ把握しやすいですが、間接的な利用者になると人数を正確に把握することは困難でしょう。しかし、正確でなくとも、大まかな規模感をつかむことは重要です。
利用者の人数を把握する手法には、以下のようなものがあります。利用者を十把一絡げにして合計人数を出すのではなく、利用者の種類ごとに人数を把握しましょう。
利用者の人数を把握する手法の例 （既存サービス）
・ 申請数、窓口対応数、問い合わせ件数等、業務で蓄積したデータからの推計
・システムに蓄積したデータに基づく統計情報からの推計
・現場での利用動向や業務状況のサンプリング調査に基づく推計
・上記手法が取れない場合には、 一般的な統計情報に基づいた推計
（該当地域の対象世帯人口に対して一定の利用比率を掛ける等）
さて、利用者が既に存在するサービスについては上述のように人数を把握することができますが、新規に立ち上げるサービスでは利用者の人数を「予測」しなくてはなりません。
このような場合は、サービスの想定利用者を種類ごとに区分した上で、それぞれの利用者層に対して次のような手法を活用して人数を見積りましょう。
利用者の人数を予測する手法の例 （新規サービス）
・ 類似するサービスの利用者数からの推計
・利用者の最大人数を把握した上で、段階的な利用率の推計
・利用者へのインタビューやアンケート調査に基づく推計
・上記手法が取れない場合には、 一般的な統計情報に基づいた類推
（該当地域の対象世帯人口に対して一定の利用比率を掛ける等）
ここで気を付けてほしいことは、多くの人が、利用者数を楽観的に「多め」に予想するということです。新しいサービスを立ち上げる際に、サービスを立ち上げる側の人はどうしてもサービス自体への思い入れも含めて、サービスが数多くの人に利用してもらえることを想定しがちです。想定する利用者数が多くなるほど、対応する職員側の人数もシステム費用も増えていきます。サービス開始当初から一遍に多数の利用者数を想定して投資するのではなく、利用者を段階的に増やすことも含めて、適切な水準で利用者数を見積もるように注意しましょう。
２ 利用者のニーズを理解する
【標準ガイドライン関連箇所：第３編第４章第２節】
利用者のニーズを理解するために必要なことは、想像や推測ではなく、調査です。
例えば、「利用者は、窓口へ来訪することを面倒に思っている」ことから、面倒ではなくしてほしい、というニーズがあるのではないでしょうか。本当にそのようなニーズが強いかもしれませんし、逆にそのようなニーズよりもっと本質的に困っていることがあるかもしれません。それは、調査をしてみないとわかりません。
実際に調査をしてみると、いろいろなことがわかります。例えば、窓口へ来訪することよりも、申請後の審査に長期間かかっていることに困っているかもしれません。この例については、実践ガイドブック「第２章Step．2-1 目標とする成果を見定める」で詳述しました。
現場を知らない人の推測のみで目標を設定するのではなく、現場の流れ、利用者の状況を調べて、利用者の本当のニーズを把握することが最初の一歩です。
A. 利用者のニーズから出発する
利用者のニーズを把握するには、具体的にどのような調査をすればよいでしょうか。サービスを提供する側は、どうしても「提供者側の視点」に立ちがちです。様々な利用者のそれぞれの立場でニーズを把握するための手法として、「ペルソナ分析」があります。
「ペルソナ」とは、サービスの典型的な利用者の、目的、意識、行動等のパターンを構造化し、利用対象者を仮想の人物として定義するものです。例えばサービスのターゲットを「会社員」と抽象的に定義すると、検討チームのメンバーそれぞれが思い描く「会社員」の姿が異なるため、チームとして判断する際にブレが生じてしまいます。ペルソナ分析ではもっと具体的に「氏名、年齢、性別、家族構成、勤務先、仕事内容、その他の詳細条件」等を設定します。このような具体的な利用者像をイメージしながら検討を行うことで、利用者が抱える課題や問題を浮き彫りにし、具体性の高いアイデアを創出しやすくなります。
「すべての人を万遍なく満足させようとすると、結局誰にも喜ばれない」という考え方があります。ペルソナ分析を使えば、具体的な利用者の具体的なニーズに基づいて、少なくともその利用者にとって喜ばれるサービスを検討することができます。
なお、ペルソナ分析も１つの手法に過ぎません。重要なことは、提供者側の視点ではなく利用者側の視点に立つことです。サービスを検討するための大前提として、利用者の立場でサービスを受けることを想像し、利用者のニーズがどこにあるかを考えてみてください。
参考：ペルソナ分析 「ペルソナ」とは、サービスの典型的な利用者の、目的、意識、行動等のパターンを構造化し、利用対象者を仮想の人物として定義するものです。ペルソナを作成して検討を行うことで利用者体験を洗い出すことができ、検討を行う関係者の間で共通認識を持って検討ポイントを具体化することができます。 例えば、引越しに関する手続きの改善を検討した際には、次のような家族をペルソナとして設定したうえで、この家族が引っ越すときに必要な手続きの内容やタイミング等について理解を深めました。 ＜ペルソナの作り方＞  以下に紹介する手順は一例です。検討対象や状況に応じて臨機応変に対応してください。 (1) ターゲットとなる利用者に関する情報を収集する ターゲットとなる利用者又は近い属性を持つ人について、情報を収集します。情報収集方法としては、インタビュー・アンケート、Web検索、公開されている調査データ、既存システムのログ等が挙げられます。 (2) 収集した情報を分析し、グルーピングする 収集した情報を、関連性が高いと思われるものごとにグルーピングして整理します。収集した情報全てが対象になりますが、自由回答のものからもパターンが見えてくること（サービスに関する調査方法、サービスを選択する際の判断基準、サービスとのタッチポイントで使用するツール、日常の行動パターン、等）があります。何の観点でグルーピングしたかがわかるように名前を付けておくと良いでしょう。(注記:タッチポイントとは、サービス提供者と利用者の間に存在するあらゆる接点のこと。サービスを申し込むWebサイト、サービスの受付窓口、コールセンター等がある。) (3) グルーピングした情報から利用者像を具現化、ペルソナを作成 グルーピングした結果から、最も典型的と思われる利用者の輪郭を浮かび上がらせます。この時、最初はぼんやりでも構わないので、ペルソナの骨格となるものを整理します。これを基に、性格や嗜好、考え方やライフスタイル等の情報を加味していくことでペルソナ像を明確にしていきます。 (4) 作成したペルソナの内容を見直す ペルソナの案を作成後、ターゲットとなる利用者と直に接している人等に、実際の利用者像とかけ離れたところがないか、ターゲットたる利用者としてふさわしいかを確認してもらいます。実際の利用者像と作成したペルソナにかい離が見られた場合は、随時内容を修正してください。 |
B. エンドツーエンドで考える
行政組織は縦割りです。新たなサービス・業務を企画する人も、どこかの行政組織に属している以上、所属する組織の所掌範囲を意識せざるを得ないでしょう。
ただ、利用者にはそんな事情は関係ありません。関係する組織が１つであるか複数であるかには関係なく、手間は最小限に、サービスは丁寧かつ迅速に受けたいというのが利用者のニーズです。
利用者のニーズ把握を行うためには、自らが所属する組織の所掌範囲だけで個々のサービスや手続のみを切り取って検討するのではなく、利用者がサービスを受ける必要が生じた時の最初の行動から最後の行動まで（エンドツーエンド）の視野に立ち、他の行政機関や民間企業が担うサービスの利用まで含めた利用者の行動全体を一連の流れとして考えることが重要です。
図4-2 サービス・業務企画の対象範囲の例
このような利用者の行動全体の流れを可視化するための１つの手法として、「ジャーニーマップ」があります。ジャーニーマップを用いることで、利用者の日常体験の中でどのように行政サービスが使われているかを可視化することができます。
参考：ジャーニーマップ ジャーニーマップは、利用者のサービス・業務に関わる一連の行動を旅になぞらえて可視化したもので、利用者とサービス提供者の関わりをストーリーとしてまとめたものです。 例えば、前述の引越し手続きの例では、ペルソナとして設定した家族を念頭に置いたうえで、この家族が引っ越すときに必要な一連の行動をジャーニーマップとして可視化しました。  ＜ジャーニーマップの作り方＞ ジャーニーマップの作成に確立された方法論があるわけではありませんので、以下の例の進め方にこだわる必要はなく、ジャーニーマップの作成目的や取り組みたい課題によって柔軟に項目を変えるなど対応してください。 なお、ジャーニーマップを作成する際は、ステークホルダーによるワークショップを実施するのが良いでしょう。ジャーニーマップの作成を通して、利用者体験のエンドツーエンドへの理解を深めることが期待できます。 (1) ペルソナの設定（誰が） 現状を調査した結果を分析してペルソナを設定します（「参考4-1ペルソナ分析」参照）。以降、このペルソナの体験としてジャーニーマップを整理していきます。ジャーニーマップは、ペルソナごとに作成することになります。ジャーニーマップは、一人のペルソナ分だけでなく、主要な利用者層にいる最優先のペルソナとサブ的な層にいる二番手以降のペルソナ等の複数のパターンに対して作成できると、より深い検討を行うことができます。 (2) 場面の設定（いつ） 利用者の行動をいくつかの場面に分けて設定します。例えば、サービスを受ける前、サービスを享受している最中、サービスを受けた後と分けたりします。それぞれの段階を更に細かく区切っても良いでしょう（例：サービスを認知する場面、それに関心を抱く場面、同様のサービスを比較し検討する場面、サービスを決定してそれを享受する場面、サービス享受後の場面、等）。 (3) 場所、タッチポイント、行動の整理（どこで、何を、どうした） 利用者がそれぞれの場面において、どこで何をどうしているかを整理します。 行動を整理する際は、タッチポイントを明確にすることも有効です。タッチポイントとは、サービス提供者と利用者の間に存在するあらゆる接点のことで、例えばサービスを申し込むWeb サイト、サービスの受付窓口、コールセンター等のようなものを指しています。また、タッチポイントにおける直接的な行動だけを整理するのではなく、その前後の行動にも課題が潜んでいることがあるので、併せて整理してください。 例示した引越し手続きのジャーニーマップではタッチポイントまでは詳細化していませんが、役所の窓口に何度行く必要があるか、郵送や電話での手続きを何度する必要があるかをタッチポイントとして明確化すると、利用者体験をさらに具体化することができます。 (4) 利用者の感情の整理（どう考えたか、どのような感情だったか） 利用者が行動する際に、利用者がどのように考えたのか（感覚、疑問、不満、満足等）を明らかにすることも有効です。 ポジティブなものだけでなくネガティブな感情も整理してください。ネガティブな感情を抱くポイントには、往々にして改善すべき内容が含まれています。例えば、ジャーニーマップの中に、「同じことを何度も伝えるのが面倒」、「必要な書類の一覧がわからない」等の言葉を吹き出しで入れることで、問題点を強調することができます。 (5) 課題、改善案等の整理（現状に対する課題、こうあるべきという意見） ここまでに整理された内容から浮かび上がってきた課題や、こうしたらもっと良くなるのではという意見、新しくこういうものを作ったら良いのではといった改善案等を整理します。既に顕在化している課題や、何かしらの基準を下回っているものがあればそれも記載しておきます。ここで挙げた情報を基に、実際の改善策を検討していきます。 |
Step.4 業務の現状把握
利用者のニーズ把握と並んで重要なことは、実際に発生している様々な事象をしっかり観察し把握することです。現状を正しく把握せずにサービス・業務企画を行うと、見た目としては新しいサービスが実現できたように見えても、実際にはサービスが使われなかったり、業務上大きな問題が発生したりするなど、様々なトラブルが発生する危険性をはらんでいます。
このStepでは、現状のサービス内容や業務内容を調査するに当たり、どのようなことに注意しながら、どのような調査をすべきかについて解説していきます。
１ 業務を観察する
【標準ガイドライン関連箇所：第３編第４章第２節】
業務を観察するということは、誰にでもできそうな簡単なことにも思えますが、観察者の経験によって見えてくるものは全く異なります。一般の人が工場見学に行った際に見える風景と、工場の生産性改善を専門とする人に見える風景は、全く異なるものでしょう。ですが、業務を観察する経験が少ない人であっても、これから説明するポイントを押さえれば十分に基本的な現状把握を行うことができます。
まず、一番に注意してほしいことは、先入観を持たずに観察するということです。
例えば、申請した案件に対する審査期間が長いという問題を調べることを想定してみましょう。この時、「審査職員の能力が重要」という先入観を持っていると、経験年数の異なる審査職員を比較して、審査の着眼点や審査方法に違いがないかという分析をしたくなります。しかし、先入観を持たずに実際に発生していることをよく観察していると、単純に審査に入るまでの待ち時間が長かったり、やっと審査に入っても、基本的な書類の不備が見つかって差戻しになったりといった、本質的な審査に関係のない部分で多くの時間を費やしていることがわかるかもしれません。
仮説を立てて検証するという手法は多くの面で有効なのですが、最初の現場観察の時点で仮説を持っていると、重要な事象を見落としてしまうことになりかねないということに注意が必要です。つまり、あれこれと頭の中で考えることは後回しにして、まずは実際に発生している事実を詳細に把握するという姿勢で臨みましょう。
A. 事実を詳細に把握する
事実を詳細に把握するということは、サービス・企画のプロセス全般を通じて根底となる重要な姿勢です。この章の以降の説明では、いろいろな視点や事例に触れながら、どのような進め方だと事実把握が十分ではなく、その場合はどのように改善すべきか、について説明します。
ただ、この先の解説を読む前に、ぜひ留意してほしいことがあります。事実把握の方法について解説すると、どうしても当たり前で一般的な事柄のように思えてしまうという点です。これから、「平均、合計ではなく、ばらつきを見る」、「推測ではなく、現場で発生している事実を見る」等、様々な考え方を説明しますが、あまりにも当然のことであるため、そんなことはわかっていると読み飛ばしたくなるかもしれません。
しかし、今までに数多くのプロジェクトでトラブルが発生したり失敗に終わってしまったりした原因を辿ると、最初の企画時点で事実を詳細に把握できていなかったことに帰結する例が本当に多いのです。
細かな粒度で一つ一つの事実を徹底的に把握していくと、今までに気づいていなかった物が見えてきます。実際に発生している事実に基づいて問題が可視化されれば、その問題に対して因果関係の整理を行った上で具体的な改善策を打つことができます。逆に本当の問題が可視化されなければ、思い込みや仮説に基づいてサービス・業務を設計することになり、その問題を解決することはできません。
図4-3 事実を詳細に把握する
また、特にプロジェクトの業務分野の経験が長い方にとっては、自分自身が現場のことも含めてよく知っているため、あえて事実関係を調査するまでもなく、問題点や背景事象を説明できるかもしれません。ですが、そういった「プロ」の人ほど、いろいろな事象に対して頭の中で説明をつけてしまうので、かえって事実を見過ごしてしまうこともあります。現場を観察し、業務で発生する実データを確認しながら、何が起きているかを先入観なく調べてみましょう。
B. 推測ではなく、現場で発生している事実をみる
政府のプロジェクトは、ボトムアップよりもトップダウンで立ち上がることが多いかもしれません。トップダウンで立ち上がるプロジェクトは、本省等の数名の職員がチームとなって企画内容をまとめあげるというような体制が典型的で、成果を達成する期限、そのための計画を作成する期限等が切られて、検討を短期間で完了させることも求められます。
このように少ない体制で多忙な中では、つい現場に足を運ぶことを省略しがちです。サービス・業務の概要は、既存のドキュメント（利用者向けの説明文書、内部の業務フローや業務手順書等）を読めば理解できるので、それらのドキュメントを穴が開くほど眺めながら、この業務に重複がある、この部分で利用者を待たせてしまっていると、問題点を指摘することができます。でも、このような進め方では、現場で本当に起こっている問題は見えませんね。
これはひどい例でしたが、実際にはもう少し丁寧なやり方になることも多いでしょう。現場にアンケート調査をかける形です。サービス・業務の流れや現状の問題点等について、書面でのアンケート調査を行い、その結果を整理します。そうすると、検討プロセスも外部に説明しやすく、現場の声を反映した企画案のように見えます。しかし、これでも本当に十分でしょうか。アンケートの取り方の巧拙にも大きく左右されますが、現場の声を聞いたという証拠作りのためだけのアンケートでは、本当の問題を浮かび上がらせることは難しいかもしれません。
まずは、とにかく現場に行ってみましょう。現場に行かずして、サービス・業務企画は成立しえません。数多くの異なる現場に足を運び、現場を見た上で、業務実施方法や処理時間を調べてください。現場に行かず、「このような業務が行われているはず」と推測した結果に基づいて情報システムを作ると、現場では使えないものになりかねません。
また、現場に行くだけでなくドキュメントを集めることも非常に有用です。業務マニュアル１つをとっても、組織全体で整備した標準的な業務マニュアルだけでなく、各拠点で独自の業務マニュアルを作成していることがよくあります。各拠点の業務マニュアルを入手し並べて比較してみると、標準的な業務マニュアルでは十分でなかった部分を補完したり、地域の実情に合わせた追加的な対応を行っていたり、様々に工夫していることがうかがえます。これらの工夫点は、今後のサービス・業務を企画するための貴重なインプットとなります。業務マニュアルだけでなく、前任者が後任者に引き継いだ際のドキュメントも有用です。このような様々な現物のドキュメントを集めることで、生々しい業務の実態を捉えやすくなります。
サービス・業務企画の段階で現場に調査に行くことは労力のかかることですが、プロジェクトがうまく行かなくなってから立て直すにはもっと労力がかかってしまいます。現場調査には、十分な期間を確保する価値があると考えて良いでしょう。
| 事例：現場の業務と合わないサービスを提供し活用されなかったシステム
あるプロジェクトでは、市町村が登録したデータを都道府県が審査して国へ送付する制度が新設されることに伴い、これらの情報を電子的にやりとりするシステムを整備することとしました。 このプロジェクトの企画段階では、一部の市町村を招へいして数回の検討会を開催しましたが、最終回の時点においても新制度での市町村等における業務の具体的な実施方法は決定しませんでした。また、新制度に関する情報をどのように分析し、活用し、公表するか、そのために収集する必要がある情報は何かといった点についても具体的な議論は行われていませんでした。 その後、システムを作ることが優先され、新制度の開始に伴いシステムの稼働が開始しましたが、結果としてこのシステムは非常に使いにくいものとなってしまいました。例えば、都道府県が審査するための帳票はＰＤＦしか出力できず、集計作業が行えませんでした。また、市町村が登録した情報は一般利用者が確認できるようになっていましたが、利用者が情報の検索を行おうとしても、必要以上に詳細な項目を羅列しているなど閲覧しづらく、利用者が検索を行う目的に資するとは考えられないものでした。このような理由から、システムを利用する自治体はかなり少数に留まり、システムの外で紙媒体や表計算ソフトを使って業務が行われることになってしまいました。 このプロジェクトは、会計検査院による検査を受けることとなりました。会計検査院の意見では、このような事態が発生した原因の１つとして、「システムの構築をするに当たり、市町村が通常の業務で使用し又は保有する情報の内容等の実態、交付申請等の手続の実施状況等を十分に把握していないこと」を挙げています。 |
なお、現場へのヒアリング等を行う際には、ヒアリングを受ける担当者への配慮が重要です。初対面の担当者にヒアリングするのであれば、その担当者も身構えてしまうのが自然なことでしょう。ともすれば、余計なことを口走って宿題をもらいたくない、業務が非効率になっていることへの責任を追及されたくないといった思いから、ヒアリングに非協力的になることもあるかもしれません。
まず、調査の目的がサービスや業務を改善することであり、問題の責任所在や犯人捜しをしているわけではなく、調査結果についても担当者や担当部署を特定できるような形での公表を行わないことなど、担当者が率直に回答しやすいための環境を整えましょう。
また、今回の取組みによって現場の担当者にもメリットとなることを、丁寧に説明することが重要です。例えば、業務やシステムの非効率で無駄な部分を取り除き、注力すべき本来的な業務に十分に時間を割けるようにすることを目標としているのであれば、その趣旨をしっかりと現場の担当者に伝えましょう。１回のヒアリングの場だけで調査を終えるのではなく、ヒアリングを契機として今後も継続的に意見交換を図れるように担当者間の関係性を構築できることが理想ですね。
C. １か所だけの現場分析結果を全体に拡張しない
さて、先ほどは現場へ行くことの重要性を説明しました。では、とりあえず１つの現場に行けば、それで十分でしょうか？
１か所ではやはり少なすぎるのではないでしょうか。多くの場合、サービス・業務を運営している現場は１つではないでしょう。全国に拠点があるような業務であれば、数百、数千か所といった多数の拠点があることもあるでしょう。１か所の現場分析結果にその現場のみの特性が含まれていると、それを全体に展開しても、他の現場には適合しません。
とは言え、全ての拠点に訪問して調査することも現実的ではありません。まずは、全体を正しく代表する拠点を探しましょう。都市部と地方でも利用者のニーズは大きく違うでしょう。拠点ごとに扱っているサービスも違うかもしれません。それぞれの拠点が様々な特性の違いを持つ中で、細かな差異は置いておいたとしても大きな特徴を持つグループに分け、それぞれのグループから現場調査の対象拠点を選ぶことが効率的です。選ぶ拠点数は、一概には言えません。都市部で２拠点、地方で３拠点という選び方で良いケースもあるでしょうし、数十拠点を調べないといけないケースもあるでしょう。
なお、最初から調査拠点を選んでしまうのではなく、全拠点を対象に簡易なアンケート調査を実施した上で、特性の違いを考慮しながら詳細な現場調査を行うべき拠点を選択するという手法もあります。
| 事例：１か所のみだった現場調査を改善
あるプロジェクトでは、特定条件に該当する施設利用者に対して支援金を支給する制度の開始に合わせ、各施設に必要となる事務作業を支援するシステムを整備することを計画しました。 全国に数千の施設が存在するのですが、当初の計画策定時には１施設だけに電話ヒアリングによる調査を行い、その結果に基づいて現行の業務フロー、サービス開始後の業務フロー等を作成していました。 しかし、ここでプロジェクトの進め方について見直しが入りました。本当にこのままシステム構築を進めて良いのだろうか、もっと施設の現場を調べるべきではないか、そのような観点から、計画の途中で軌道修正を行ったのです。 まず、施設の特性別、手続の種別、対象者の種別を基に、施設間の差異を洗い出しました。そして、支援金の支給対象地域における利用者層の人口や施設の規模により抽出基準を策定し、その基準に基づき、各特性を網羅するよう複数の施設を選定しました。つまり、施設ごとに様々に背景や業務実施方法が異なるため、各施設の特徴を「正しく対象として、現場調査を行うこととしました。調査方法も電話だけでなく、書面、現地調査等の様々な方法を複合的に用いました。 
調査方法の見直しにより、施設間の業務の違いを考慮した業務要件を定めることができ、早い段階で軌道修正することができました。 |
なお、多くの現場を調べることで、現場ごとの「ローカルルール」を把握することも重要です。ローカルルールを調べて業務を標準化することについては、「Step.5-2-D. システムを作る前に、業務を標準化する」で後述します。
D. 日常的に業務の課題を収集し、分析に利用する
サービス・業務企画を実施する時に初めて現場の課題を収集しようとしても、なかなか効率的には収集できないでしょう。そもそも現場の職員は忙しいので、過去の話を聞いてもそのことを覚えていないかもしれません。課題がないかと聞かれても、過去に何かがあったような気がするけど何だったかなと、曖昧な回答になってしまいがちです。
発生した課題を最も記録しやすいタイミングは、発生した直後です。記憶が新鮮なうちに、どのような事象が発生して何が課題になったのかを記録することが習慣化されていると、後々になって業務改善や新たなサービス・業務企画を行う際にとても有用なナレッジとなります。
では、どのような情報をナレッジとして蓄積すればよいでしょうか。一般的な例を見てみましょう。
日常的な課題収集手法の例
・ 現場の窓口等への問合せ、クレーム
組織に対する明示的な問合せ（公式の問合せ様式によるもの等）については管理しているものの、窓口に来訪した利用者からの口頭問合せや、電話での問合せについては、その場で職員が対応するだけで記録が残っていないケースが多くあります。窓口や電話についても対応記録を残すなど、組織全体でナレッジを蓄積できることが望ましいと言えます。
利用者からの問合せがあった都度、問合せ管理台帳のようなドキュメントに記録を行います。問合せ管理台帳は、表計算ソフトで作成することもできますし、問合せの種類や件数が多い場合は専用のツールやシステムを活用することもあります。
・ コールセンターやヘルプデスクへの問合せ
外部委託でコールセンターやヘルプデスクを開設している場合は、委託先の事業者が問合せ内容や対応履歴等を詳細に記録していることが一般的です。ただ、せっかくこれらの情報を蓄積していても、この情報を見るのが一部の職員に限られていて、サービス・業務企画時に活かされないというケースもあります。また、管理対象となる件数が多いため、適切に分類を行わないと重要な課題が埋もれてしまうことにもなりかねません。このことに注意しながら、管理方法自体も継続的に見直しを行うことが望ましいです。
・情報システムへの要望やインシデント
外部委託で情報システムの運用を実施している場合は、利用者からの情報システムに対する要望や、情報システム起因の課題（エラーの発生等）が、通常業務の中でも報告されやすく、情報として管理されていることが一般的です。ただし、上記と同様に管理対象となる件数が多いので、適切な分類を含めて、管理方法自体も継続的に見直すことが望ましいです。
なお、後段で説明しますが、これらの問合せ内容については根本原因が同じになる粒度まで分類を行っておくことで、サービス・業務改革のためのポイントを数多く把握できるようになります。
２ 実績データを分析する
【標準ガイドライン関連箇所：第３編第４章第２節】
業務の現状を把握する方法は、現場へ行って人の動きやドキュメント等の実物を見るだけではありません。業務の中で生まれているデータを収集し分析することで、業務の実態をつぶさに可視化することができます。
ただ、実績データを収集することには労力がかかります。そして、やみくもにデータだけを入手しても、その先の分析で困ってしまいます。業務で発生している問題に対する先入観を持つ必要はないのですが、どのようなデータを調べたいかについて基本的な方針を立て、その目的に沿ってデータを収集して分析することが必要です。この作業には、少しコツのようなものが必要です。
以下に、実際に様々なプロジェクトでデータを分析した事例に基づいて、コツとなる部分を例示します。
A. 平均、合計ではなく、ばらつきを見る
このサービスを利用する人は、何人くらいでしょうか？
このような質問を受ければ、１日平均で300人ですとか、１年間の合計で７万人ですとか、平均や合計で答えるのが一般的だと思います。もちろん、平均や合計で表される数値は、全体的な規模感をざっくりとつかむために大切な数値です。しかし、サービス・業務企画で調査する内容としては、さらに踏み込みが必要かもしれません。
例えば、１日平均で300人なので、余裕を見て400人分の対応ができるようにサービス・業務を設計しようと考えることがあるかもしれません。しかし、この考え方は少し安易すぎないでしょうか。なぜなら、平均や合計という代表値の裏に隠された、利用者ごとの違い、求めるニーズの違い、時刻や曜日ごとの違いといった様々な「ばらつき」を無視してしまっているからです。
ばらつきを注意深く見ていくと、サービスの中でもよく利用されるものとほとんど利用されないものの差が大きかったり、特定の利用者が何度も繰り返してサービスを利用している傾向が見えたり、時間帯や曜日によって利用方法にピーク特性があったりと、様々な実情が見えてきます。このようなばらつきをうまく捉えることができれば、単純に平均400名の対応量を確保するというやり方ではなく、特定の利用者向けの対応を別出ししたり、特定の時期のみに体制を強化したりといった対策を打つことができるようになります。また、ピークを分散させ平準化させることも、有効な手段です。
図4-4 ばらつきを分析する
このことは、様々な局面で注意してほしいポイントです。手続数、書類数、問合せ件数、業務処理時間といったサービス・業務面でも、アクセス数、画面レスポンス時間、夜間バッチ処理時間、障害発生件数といったシステム面でも、そのほかにも費用面、効果面、品質面など様々な指標を扱うときに、「平均」や「合計」といった言葉は頻出します。この言葉に出会ったときは、表面的な平均値や合計値だけを鵜呑みにせず、その陰に隠れているばらつきを捉えられているかどうか確認してみてください。
B. 時間と期間を区別して滞留状況をつかむ
業務フローを可視化すると、様々な問題点が見えてきます。しかし、業務フローだけでは見えない問題があるのも、また事実です。
その１つが、業務のどこで滞留しているかを探ることです。そのためには、業務フローに紐づいた計測ポイントを設定し、業務処理の１件１件の単位で、それぞれの計測ポイントを通過した日時を確認します。
この分析を行うときには、時間（実際の業務処理に必要な時間）と期間（開始から終了までの全体の時間）を取り違えないように注意する必要があります。最初の計測ポイントから次の計測ポイントにいくまで５日間かかったとすれば、これは「期間」の考え方です。でも、その５日間の間で、実際に確認や審査等の実業務に要したのは僅か30分だったかもしれません。これが「時間」の考え方です。時間と期間を区別して捉えることで、実際の業務処理に必要な時間と、単に処理待ちで放置されていた時間を明確にすることができます。
このような分析を行うと、業務処理の中のボトルネックを可視化することができます。可視化ができれば、大きなボトルネックが発生している箇所について、その原因を確かめてみましょう。現場にヒアリングに行く際も、何も準備をせずにヒアリングへ行くと一般的な回答しか返ってきませんが、実データで特定部分にボトルネックが発生していることを示した上でその時に何が発生していたかを確認するようにすると、具体的で本質的な回答を得ることができます。
| 事例：１件１件の業務処理の滞留状況を可視化（ヘビ図）
ある内部的な精算業務において、精算が完了するまでの期間が長いことが積年の問題になっていました。過去にも様々な問題提起がなされ、精算期間の目標日数を定めるとともに、業務を標準化するためのマニュアル等も整備しました。 その後、精算業務の開始から終了までの「平均」期間について測定を行っていましたが、状況はあまり改善しておらず、日数を集計して平均しただけの情報では、どこに原因があるのか見当がつきませんでした。そして、このように状況が改善しない理由としては、「他の業務が忙しい中で、精算業務は後回しになってしまう」、「最後は、担当者のやる気の問題」といったように、受け止められていました。 この状況に対して、まずは実際の決裁での滞留状況を可視化してみようということで検討活動がスタートしました。この精算業務では、複数の決裁者が内容の確認を行っているので、決裁者が確認を行い次の決裁者へ送るタイミングを計測ポイントとして、精算案件の１つ１つについて精算業務の際に利用するシステムのログを調べてみました。また、表形式でログを並べても滞留状況がわかりにくいので、次のような方法で決裁者ごとの処理期間を時系列に並べて可視化しました。 
この表の中では、決裁者が当日中に処理しなかった部分を赤色に着色しています。そして、赤色部分が極端に長くなっている部分を中心に、この記録を示しながら該当する決裁者に長期間かかった理由と当時の状況についてヒアリングを行いました。そして、その結果を「滞留・差戻し理由一覧表」にまとめました。 この分析の結果、様々なことがわかりました。精算時に計算方法が誤っていたり必要な資料が整っていなかったりすると差し戻し等で時間がかかるのですが、その前提となるルール自体が複雑でわかりにくく、部署間で統一もされていないことがわかりました。また、特定の人に業務が集中し、この精算業務が後回しになる実態も見えました。 実際の問題点がわかれば、その対策を行うことが可能になります。このケースでは、精算に係るルール自体を改めて見直すとともに、必要な資料の漏れを入力時に警告するようにシステムを改修し、精算処理の進捗状況もシステム上で可視化して、業務の集中状況を把握できるようにする等、制度（ルール）面、業務面、システム面でそれぞれ対策を行うこととしました。 対策実施後も、精算完了までの期間については定期的に分析を行っています。部署によって差はありますが、全体的には期間が短くなっており、目標としていた日数にほぼ近づいている状況です。 なお、この図については、関係者の間で「ヘビ図」と名前を付けていました。処理状況を示す形が、ヘビのように様々に形を変えながら長く伸びていたためです。元々はこの精算業務の分析に始まった「ヘビ図」ですが、他のプロジェクトでも応用され、サービス・業務改革（ＢＰＲ）の１つのツールとして使われています。 |
上記の例は、前の決裁者の処理が終われば次の決裁者へ移るという、基本的に一方向での業務処理でした。
一方で、業務の中には、複数の関係者間で処理が何度も往復するような複雑なものもあります。このような業務について滞留状況の分析を行う際は、次に示すシーケンス図が有効です。
U 事例4-5 関係者間を往復する複雑な処理状況を可視化（シーケンス図） |
事例：関係者間を往復する複雑な処理状況を可視化（シーケンス図） ある省で利用者向けに行われているサービスにおいて、利用者の申請を受け付けてから審査結果を返すまでの期間が長い事が問題となっていました。この業務では、利用者が申請書類を提出した後、書類を受け付けた担当者が内容に応じて様々な担当者に受け渡していくものであったため、関係する数多くの担当者のどの作業でどのくらいの時間が掛かっているのかがはっきりしておらず、対策を打つことができていませんでした。 そこで、業務処理の実態を正しく把握するための手段として、シーケンス図を用いて、分析を行うことしました。シーケンス図とは、業務に係る担当者を全て登場させ、担当者自身の作業と、担当者間のやり取りを区別できるように記載したものです。 
これらのやり取りをした日時は、システムのログ等には存在しなかったため、関係者間の電子メールや関連書類の記録等を基に洗い出しを進めることにしました。手作業での洗い出しであり全件を対象とした分析は困難であったため、審査期間が長引いている案件を中心に選択的に分析を行いました。 シーケンス図の分析結果を見ると、関係者間で頻繁にやりとりする期間もある一方で、待ちが中心となる期間も存在することがわかりました。頻繁にやり取りする期間については、なぜ何度も状況確認を行う必要があったのか、その都度ごとの確認内容や質問内容を確認し、審査の途中ではなく最初から必要な情報を得ることができなかったか等について検討を行いました。また、待ちが中心になる期間についても、待ちが発生している理由等を調査しました。 このように、シーケンス図を作成することによって、何に時間がかかっているかという全体的な問題構造を可視化することができ、関係者間でその内容を共有した上で、問題分析に当たることが可能となりました。 |
C. 業務量のピークを捉え、ピークの発生原因を把握する
業務フローだけでは見えてこないものは、ほかにもあります。それは、業務処理量です。
業務フローだけを眺めると、毎日、決まりに従ってスムーズに業務が流れていくように錯覚しがちですが、実際の業務では日々の業務量が大きく異なるので、繁忙期には処理が停滞しがちです。業務量に応じて、処理の方法まで変わることもあります。
このため、業務量の変化を捉えた上で、特にピークが発生するポイントを把握することが重要です。ピークが発生する例としては、年度末等の申請時期の区切りの直前、長期連休明けの営業日の午前中等が典型的ですが、業務の特性で様々な時期、時刻にピークが存在します。まずは、このようなピークがどこに発生しているかを把握しましょう。
業務のピークについては、サービス利用者側の要因で発生するものであり、サービス提供者側の工夫でピークを抑えることは難しいと考えてしまいがちです。しかし、まずは工夫できる余地があるかどうかを検討するためにも、ピークの時に実際に何が起きているかを調べてみましょう。どのような利用者がどのような目的でその時期に利用せざるを得ないのか、実際に発生している事象を確認すると、ピークが発生している理由を理解することができます。
ひょっとすると、とてもつまらない理由でピーク時期に余計な負荷がかかっているかもしれません。そういった一例を、参考として示します。
事例：利用ピークの分析を活かして電子申請利用率を向上 あるプロジェクトでは、ある免許の定期的な更新について、書面で行う方法だけでなく、電子申請でも行えるようにサービスを提供していました。この免許は、数年に１度の頻度で更新が必要であり、更新期限の３カ月前までに手続を終えることを規則で定めていました。 実際に電子申請のサービスを始めていくと、申請期限間際にサービスの利用が集中してしまうことが明らかになりました。そこで、その集中時における利用者のサービス利用状況等を調べてみました。 すると、少し不思議なことが判明しました。正常に更新申請を行っている利用者以外に、パスワードの再発行申請やログイン自体を諦めている利用者が、比較的多い割合で存在していました。この時期の申請内容を確認したところ、以前に電子申請を使った経験のある利用者が、また書類申請に戻っているケースが一定数存在していたのです。一度、電子申請を経験すれば、次回も電子申請を使った方が効率的なはずなので、この理由は調べてみる必要があります。 色々と周辺状況を調べてみた結果、これらの利用者はパスワードを忘れている可能性が高いことがわかり、サービス利用状況の分析結果と一致しました。更新手続は数年に１度しか利用しないので、電子申請を行おうとした際にＩＤやパスワード等がわからず、パスワードの再発行を待っていると申請期限である３か月前を超えてしまうため、やむなく書面での手続を行っているということでした。 
このようなケースが多くなると、せっかく整備した電子申請の利用が進みません。様々な検討の結果、規則自体を改正し、書類申請の期限は変更しない一方で、電子申請サービスの申請期限のみを１か月前まで延長するようにしました。 これにより、書類申請期限と電子申請期限に差ができ、業務上の利用ピークが分散されるとともに、パスワード忘れによる再発行が発生したとしても、それを待って電子申請が行えるようになりました。  |
既存の業務内容そのままに業務量のピークを想定とすると、業務に必要な職員体制を見直すことも難しいですし、情報システムの処理能力も大きなものが必要となってしまいます。当然ながら、情報システムのコストも上がってしまいます。
特にピーク時と平常時の業務量の差が極端に大きい場合は、ピーク自体を分散化させることを検討したいですね。そのためにも、いつピークが発生しているか、そのピークに何が起きているのか、よく調べてみると改善のヒントをつかまえることができます。
業務のピークが、利用者の行動の締切り直前の集中にある場合は、利用者を締切り以前から行動するように誘導することや、利用者を複数のグループに分けて締切り自体を分散化することを検討します。例えば、公共料金の支払いにおいても、利用者を複数のグループに分けてそれぞれ支払い期限を変えていることが一般的になっています。
なお、業務量のピークを抑えることが根本的に難しい場合においては、システム方式としてクラウドサービスを導入することも有効な選択肢になります。クラウドサービスでは、基本的にリソース（サーバ等の能力）を使用しただけ費用が発生するので、瞬間的なピークにも対応しながら全体的にはコストを抑えるといった使い方が可能になります。
D. 問合せや要望は、根本原因が同じになる粒度まで分類する
サービスを提供していると、様々な問合せ、要望等が寄せられます。ヘルプデスクとして電話で問合せを受けることもあるでしょうし、窓口で利用者から直接問合せを受けることもあるでしょう。毎日10件の問合せがあったとしても、１か月で200件、１年では2,000件を超える問合せを受けることになります。
さて、サービス・業務改革を進めるためには、このような問合せの履歴は「宝の山」になります。利用者が何に困っているのか、何を望んでいるのか、そこに利用者のニーズの原石が埋まっているからです。ただ、大きな山なので、なかなか掘り起こすのが大変ですね。年間数千件、場合によっては数万件にもなる問合せの履歴の山から、どのようにして宝となる原石を掘り当てればよいのでしょうか。
そのキーポイントとなるのが、分類です。多くの場合において、サービスの種類別や工程別に分類を行っていると思います。施設予約のサービスであれば、利用者登録、施設予約、抽選、料金支払いといった分類です。また、問合せ内容の原因別という観点もあるかもしれません。施設予約システムの操作方法、システムの動作環境、システムの不具合といった分類です。
しかし、いずれの例も、かなり大括りであることに気づかれたでしょうか。「利用者登録」の「システム操作方法」に関する問合せが今月20件あったとします。先月は30件でした。確かに合計数値では減少していますが、こういった数値を見て一喜一憂することに意味があるのでしょうか。この20件という数字は、内容の全く異なる問合せをその違いを考慮せずに単純に「合計」しています。これでは、どのような事象が利用者から問題にされていて、何を対策すればよいのか、何も探ることができません。
最初に少し手間はかかるのですが、利用者からの問合せが発生した根本原因が同じ所に行きつくまで、詳細に分類することが重要です。根本原因に行きつくまで分類を行った一例を、以下の参考に示しました。
U 事例4-7 根本原因が特定できるまで詳細な分類を行う |
事例：根本原因が特定できるまで詳細な分類を行う あるプロジェクトでは、ある資格の更新等をWebサイトで行える電子申請サービスを提供しています。しかし、申請の手順や操作方法等についてヘルプデスクへの問い合わせが多く、利便性が高いサービスとは言えない状態になっていました。 これまでも、ヘルプデスクに問合せ対応履歴を登録する際には、問合せ対象となった機能、問合せの原因等である程度の分類は行っていました。しかし、実際に問合せの内容として登録されている文章を読んでみると、同じ分類とされているグループの中にも、全く異なる内容が多く含まれていることがわかりました。一方で、いくつかの内容を読んでいくと、問合せの中に頻発する「キーワード」があることがわかりました。そこで、頻発するキーワードを頼りにしながら分類の詳細化を進め、問合せの根本原因が同じ粒度になるまで分類を行っていきました。 例えば、頻発するキーワードの１つに「ポップアップ」という言葉がありました。ポップアップとは、Webブラウザで画面遷移する際に新しく小さな子画面（ウインドウ）を出すことを指しているのですが、その子画面が出るはずのところで画面が出現しない（ブロックされる）という問合せのようでした。そこで、このキーワードが含まれる問合せを洗い出した上で、詳細な原因別に分類しました。いくつかの原因があったのですが、最も多かったのがブラウザの設定等でポップアップ画面を出すことを妨げていたので、設定を変える必要があるというものでした。 このように、内容がわかってしまえば対策が簡単な問題が多いのですが、利用者にとってはこのような問題が１つでも発生すると利便性が大きく低下してしまいます。この例ではWebサイトのＦＡＱ等のわかりやすい場所にポップアップに関する注意を載せるなど、問合せ内容の分析結果に応じて各種の対応を行いました。  |
同じ原因別に分類することができれば、その発生傾向を分析することができます。
例えば、参考に記載した例では、ＦＡＱにわかりやすく注意を載せる等の対策を打ちました。この対策に効果があったかどうかは、対策を打つ前後で同じ分類の問合せの件数を見るとわかります。対策を打った後でこの問合せが大幅に減ったのであれば効果があったと言えますし、対策を打った後もこの問合せの件数がほとんど減らなかったのであれば、何か別の対策を打つ必要があるということです。
このような詳細な分類を行うことは、確かに手間がかかります。ただ、全体的な分類を一度見直すことができれば、その後に発生する問合せに対しても発生の都度正しく分類しやすくなります。そして、何より利用者が感じている小さな不満から大きな苦情までを捉えることができ、同じ原因別での問合せ発生数を時系列で把握できるという点で、業務・サービス改革のために非常に有効な分析が行えます。
もし、利用者からの問合せのデータが大括りのままに眠っているとすれば、一度、職員の中で分析チームを作って分類を進めることにトライしてみてはどうでしょうか。
３ 業務を可視化する
【標準ガイドライン関連箇所：第３編第４章第２節】
業務を観察した結果、実績データを分析した結果は、様々な観点からまとめられた大量のドキュメント群となることがあります。分析を実施した当事者はこれらの内容をよく理解ができますが、これらの資料を初めて読む人にとっては、ポイントをつかむことが難しいでしょう。
業務の分析結果は、プロジェクト内部の職員（ＰＪＭＯ職員）、プロジェクト外部の利用者や関係者、システムを整備する際のシステム開発事業者等、様々な立場の人がその内容を確認する必要があります。これらの関係者に対して的確に業務の状況を伝えるためには、業務フロー等、業務を誰にとってもわかりやすく可視化した資料を作成することが重要です。
A. 様々な立場の人が理解できる業務フローを作成する
業務フローは、現在行っている業務を「誰が（どの組織が）」「いつ」「何を」「どの順番で」実施しているか、「どの範囲が情報システム化されているか」を可視化するものです。対策の検討や企画後の業務内容の変化箇所を特定するためにも有効です。業務フローには、現行（AsIs）と将来（ToBe）がありますが、ここで作成するのはまず現行の業務フローです。 (注記:AsIsとは、「現状」の意。「将来あるべき」のToBeとセットでよく使われる。 )
業務フローの書き方については、様々な表記方法があります。基本的には、関係者にとってわかりやすい表記であれば、どのような表記方法でも十分です。縦に流れるフローでも、横に流れるフローでも、どちらでもかまいません。
図4-5 業務フロー（現行）の定義例
なお、将来（ToBe）の業務フローについては、「Step.5-2-E. 将来の業務フローには、効果を紐づける」で後述します。
業務フローの表記方法には様々な手法がありますが、次のようなことに留意すると関係者が理解しやすいものとなります。
業務フロー作成時の留意点
・ 業務を実施する主体ごとに表記を分ける
業務を実施する主体を分けないと、誰が実施している作業なのか区別がつかなくなります。実施主体ごとに「レーン」を作成し、発生する業務をプロットします。
・ 業務単位を軸に体系化する
業務フローは、大きくなりすぎると読みにくくなるため、一定の業務単位にサブフローとして１つのフローを作成します。業務の単位は、業務一覧の階層と合わせることで整合性がとりやすくなります。
・ システムを利用して行う業務を明確にする
業務フローの中には、人が手作業等で実施する業務と、システムを利用する業務が入り混じります。システムを利用する業務については、色を変えたり、枠囲みによって利用するシステムを表したりすることで、区別できるようにします。
・ 帳票やデータの受け渡し内容を明確にする
やりとりする帳票やデータ等の起点と終点を明らかにするとともに、その内容（特にインプットとアウトプット）を明確にします。なお、インプットとアウトプットに関する情報は、帳票名やデータ名に留め、詳細な項目は後述の業務記述書や業務ルールに記載し、業務フロー上で詳細になりすぎないように注意します。
・ 業務の流れ方を一方向にする
横書きであれば左から右、縦書きであれば上から下の基本的な流れに沿って業務をプロットします。基本的な流れに沿わない業務の進み方が多くなると、理解しにくくなってしまいます。
・ 中心となる業務について記載する
実際の業務の中では様々な例外処理が発生しますが、それらを全て記載する業務フローが複雑になりすぎて理解できなくなります。中心となる業務について記載し、例外等については後述の業務記述書や業務ルールとして別に書き出した方がわかりやすくなります。
・ 業務のばらつきに留意する
業務フローを書くとすべての現場がこの標準的な業務フローで動いているかのように錯覚してしまうことがあります。実際には各拠点、各組織でそれぞれ工夫を行ったり独自の背景があったりするため、様々な業務のバリエーションが存在することが多くあります。確かに、これらのバリエーションをすべて業務フローとして可視化するのは煩雑です。しかし、業務のばらつきが存在することについて現地調査や担当者へのヒアリングを通じて十分に把握して、それらの業務も標準化するのか、または複数の業務実施パターンを許容したうえでシステムも各業務パターンへの個別対応を行うのかについて、業務要件作成時に方針を定めることが重要です。
前述の業務フローのイメージは、一般的なＰＣのプレゼンテーション・ソフトウェア等で作成することをイメージしたものです。なお、業務フローを効率的に作成するためのツールも多種存在しているので、必要に応じてそのようなツールを整備することも検討してください。
また、業務フローの表記についての国際的な標準として、ＢＰＭＮ（Business Process Model Notation：ビジネスプロセスモデリング表記法）があります。業務フローを作成するツールの多くは、このＢＰＭＮに準拠した表記を行うことができます。
図4-6 ＢＰＭＮ表記で書いた業務フロー図
B. 業務ルールや業務実施方法をまとめる
業務を可視化した文書は、関係者がサービス・業務や情報システムの目指すべき姿を共有するものであるため、誤った定義や曖昧な定義が行われると、後続の工程に重大な影響を与えます。
そのため、業務を可視化した文書を作成する際には、次に示す点を参考に、正確で一貫性のある記載となるようにしましょう。
・曖昧な用語や一般的な意味と異なる使い方をしている用語等は、プロジェクト関係者間の認識齟齬を防止するため、用語の定義及び機能を定義する粒度や深さについて統一する。
・サービス・業務企画内容の検討における作業のしやすさを考慮して、業務単位や区分、順番等を整理する。
事例：業務は複数の切り口で表現すると漏れなく可視化できる ある省の大規模な業務システムの刷新プロジェクトにおいて、システムリリース後の業務要件を漏れなく調達仕様書で示すために、従来の業務要件定義のやり方を改め、より要件を漏れなく記述し、可視化する資料を作成する取り組みを行いました。 対象となる業務は、業務実施部門職員向けの特定業務に特化したマニュアルしか存在しておらず、網羅的かつ業務知識のない第三者でも理解できるような内容の資料とはなっていませんでした。 このため、業務を「流れ、判断、内容」の３つの視点から表現し、業務を可視化するドキュメントとして業務フロー、ディシジョンテーブル（条件分岐表）、業務説明書を作成することとしました。（下図（「業務可視化資料の作成について」（特許庁ＰＭＯ 平成27年５月18日）を参照）） 
これらドキュメントを用いて、プロジェクト関係者間（業務実施部門、情報システム部門、外部事業者）の課題認識の共有や、開発工程の効率化、開発範囲に対する設計の網羅性確認に活用することができました。 さらに、各ドキュメントを組み合わせて、記述内容をチェックすることで、要件の抜け漏れを防ぐことができました。 |
C. 入出力情報や管理対象情報をまとめる
業務を構成する要素には、業務フローに代表される「プロセス」だけでなく、「情報、データ」があります。「プロセス」が業務の動的な側面（流れ、動き）を表すのに対し、「情報、データ」は業務の静的な側面（常に成り立つ相互の関係と、ある時点での状態）を表すといった特徴があり、いずれも業務（システム）を定義するために欠かせない要素となります。
「情報、データ」の現状を把握するには、「入出力情報及び取扱量」および「管理対象情報一覧」をまとめます。
「入出力情報」と「管理対象情報」の違いは、「入出力情報」が画面、帳票、CSV形式の一時ファイルなど、実際の業務でやり取りする単位の情報であるのに対し、「管理対象情報」はそれらの要素を管理しやすい単位に分解、集約した情報（将来のデータベースの元情報）となります。
一般的な「管理対象情報」の抽出方法は以下のとおりになります。（）内は、別紙「業務要件定義書テンプレート例」における図書貸し出しシステムの事例です。
① 「入出力情報」の項目を同じ単位の情報に分解する
ある入出力情報に記載されている項目を分析し、同じ単位で括れるものを抽出する。（例えば、「貸出申請書」の項目を、「書籍」「利用者」など単位が異なるものに分解する。）
② 「入出力情報」自体も、一つの「管理対象情報」として抽出する
入出力情報自身も、その事象自体を管理する場合は、管理対象情報となる。（例えば、「貸出申請書」という入出力情報について、一枚ごとの「貸出申請」という事象は業務上で通常は管理するものであり、管理対象情報になる。一方で、「貸出状況照会履歴」のように、貸出状況の照会を誰がいつ実施したかという情報までを業務上管理する必要がないのであれば、管理対象情報とする必要はない。）
③ 抽出した管理対象情報のうち、親子関係があるものをさらに分解する
抽出した管理対象情報の中で、合計と内訳のように親子関係を持っているもので、親子別々に管理する必要があるものは、別の管理対象情報とする。（例えば、上記の「書籍」をその本の基本情報（タイトルや著者など）と、実体（本一冊づつ）が持つ情報に分け、前者を「書籍情報」、後者を「書籍」と名づける。）例えば、貸出用に同じ本が３冊ある場合は「書籍」としては３つの実体があり、そのタイトルや著者などの「書籍情報」としては１つとなる。
図4-7 管理対象情報の抽出
既にシステム化されている業務においては、データベースの情報を参考に「管理対象情報」を作成することもできますが、ここでは、あくまでも業務視点で管理すべき情報を洗い出すようにしてください。（システムの都合で作られたデータや、業務のデータであっても管理単位や属性の持ち方がシステム処理上の都合によって変更されているものは「管理対象情報」としては使わないでください。）
Step.5 サービス・業務企画内容の検討
Step.４は、Step.３で可視化された現状の業務・システムに関する調査結果を基に、そこに存在する課題を分析し、新しい業務・システムの方向性を検討します。
Step.３でも書きましたが、現状の業務・システムの調査結果が、次の業務・システムの形（企画方針）を決める重要なインプットとなります。
１ 課題を整理し、分析する
【標準ガイドライン関連箇所：第３編第４章第３節1)】
ここまでで集めた課題は、多岐にわたり大量なものとなっています。この中には、システムの操作がわかりにくいといったレベルの問題から、利用者にとって深刻なサービス低下を招きかねない課題もあり、同等には取り扱えません。目立つ課題が、必ずしも最優先で解決しなければいけないもの、とは言い切れないことが多いのです。
これらの課題を仕分けし、課題の関係性を明らかにしつつ、本質的な原因を探るための手法・ポイントについて、見ていきましょう。
A. 優先順位・影響度・費用対効果による分析
課題を原因ごとにグルーピングした後は、それらの課題を利用者への影響度や費用対効果を基に優先順位付けし、主要課題を抽出していきます。
これらの関係性は以下のようになります。
図4-8 標、個別の分析、課題の関係
優先順位付け時に気をつける点
・ 利用者への価値最大化、及び、プロジェクト目標に対して影響度が高い課題を優先的に検討する。
・対策の優先順位を検討する際は、影響度を鑑みて、費用対効果が高い対策を優先的に行う。
２ 企画案を作成する
【標準ガイドライン関連箇所：第３編第４章第３節2)】
現状把握を行う際には、あれこれと頭の中で考えることは後回しにして、まずは実際に発生している事実を詳細に把握することが重要と説明しました。
その現状把握が終わった今、これからはまさに頭を使って、企画案を練り上げるフェーズです。おっと、頭だけではありませんでした。足も使っていろいろな関係者の所へ出向きながら、企画の具体的な内容を調整していきましょう。
A. 全ての関係者に気を配る
企画案を作成する人は、どうしても自分の視野に見える範囲で考えてしまいます。自分の視野、自分の組織だけでなく、サービスを受ける利用者、関係者全体を見渡して、特定の人に不便なことが発生しないように配慮しましょう。
また、サービス・業務で用いる情報システムが、他の情報システムと新しく連携する際は、連携先に与える影響について企画案を作成する段階から十分に考慮してください。情報共有や影響度の調査が不十分な場合、連携先のサービス・業務に思わぬ改修が必要となり、連携先に多額の変更コストを発生させることがあります。
サービスは様々な関係者によって成り立っています。利用者だけでな く、全ての関係者についてどのような影響が発生するかを分析し、Ｗｉｎ-Ｗｉｎを目指すことが重要です。
| 事例：利用者の状況の調査不足でシステム改善が迷惑化
利用者や関係者に十分に気を配れていないと、システムを改善することでかえって迷惑をかけてしまう結果になることがあります。 あるプロジェクトでは、マークシートを用いた申請受付業務を行っていました。ただ、利用者にそれぞれ鉛筆でマークシートを記入してもらうのも手間がかかるため、マークシートでの受付を廃止し、インターネット経由での電子申請により受付を実現することとしました。 システム改修が終わり、サービスの切り替えに伴う過渡期を十分に取らないまま、新しい機能をリリースしたところ、大量に申請を行う事業者からクレームが上がりました。この事業者は、自社内の情報システムから、既存のマークシート様式に自動出力できる機能を開発済みであり、マークシートであれば効率的に業務を実施することができていました。ところが、今回の電子申請への変更によってマークシートでの受付が廃止されてしまったため、電子申請で１件１件の入力を手作業で行わざるを得なくなり、業務効率が大幅に悪化してしまったとのことです。 マークシートを用いた申請業務が煩雑で手間がかかるということは、多くの利用者に該当することでしたが、一部の利用者には該当しなかったということです。企画案を作成する段階でこのような利用者の存在に気づけていれば、電子申請の開始後もマークシートでの受付も一定期間継続するなど、利用者の状況に合わせた対応を行うことができます。 |
. 利用者の日常体験に溶け込む
利用者の視点で考えると、行政サービスを受けるためだけにわざわざ行動するのは面倒ですね。利用者の日常の行動の中で何かのついでに行政サービスを受けることができると、とても便利になります。
企画案を作成する際には、利用者に新たな手間を増やすという方向でなく、新たに手間を増やさなくても既存の活動の中で完結できる方策を検討してみましょう。
| 事例：利用者が日常的に使用するソフトウェアからのＡＰＩ申請
電子政府の総合窓口（e-Gov）では、その機能の１つとして自宅や職場のパソコンから行政機関に対する申請・届出等の手続を行うことができます。 従来は、利用者がWebサイトを開いてそこで電子申請を行う方法しか提供していませんでした。そのため、多くの利用者は、日常的に利用している労務会計ソフトウェア等で計算等の業務処理を行った上で、その処理結果をe-GovのWebサイトに再度入力するという二度手間をかける必要がありました。 この二度手間をなくすために検討を行った結果、外部連携ＡＰＩを利用したオンライン申請を実現することとしました。ＡＰＩ(Application Programming Interface)とは、複数のアプリケーション等を接続（連携）するために必要なプログラムを定めた規約のことです。この規約に従うように作られたソフトウェアは、e-Gov電子申請システムと申請データのやり取りを直接行うことができるようになります。 外部連携ＡＰＩを利用したオンライン申請を行うことにより、申請データの作成から、申請、公文書取得までの電子申請に係る全ての機能について、利用者が日常的に利用する労務会計ソフトウェア等で一元的に操作を行えるようになるとともに、進捗管理も簡便に行えるようになり、利用者にとって効率的な申請・届出業務が行えるようになりました。 
|
C. 縦割り組織にやわらかく横串を刺す
他の行政機関や民間企業が担うサービスの利用まで含めて、利用者の行動全体を一連の流れとして考えることの重要性を前段で述べました。このようにエンドツーエンドの視野で分析を行うと、新しい企画案を作成するためには、他の行政組織や民間サービスとの連携が必要となることに気づきます。
さて、ここで大きな分岐点があります。あなたは、どちらの方向性で検討を進めていくでしょうか。
(1) 他組織の所掌範囲に踏み込むことは越権行為になる。他組織へもこれまでの検討結果の情報提供は行うが、その上で自分自身は自組織の範囲内で検討を進める。
(2) 自らが主体となり他組織を巻き込んで組織横断的な検討組織を立ち上げる。その検討組織で全体的な方向性や各組織の実施事項をまとめる。
残念ながら、実際の検討の現場の中では、(1)に近い発言をする人が目立ちます。もちろん、行政組織の成り立ち上、他組織の所掌範囲に踏み込んで指示をするようなことになれば確かに越権行為と言われかねません。
ただ、他組織の中の職員も、自発的に同じ方向性で検討を進めるようになったのならば、全く問題はありません。そういう状態になるように、周りを巻き込みながら調整を進めること、このことこそ縦割り組織の弊害が激しい現状の中で、一番求められている行動です。
言うまでもありませんが、このような調整に高圧的、感情的な発言は全く不要です。また、書面での一方的な連絡をもって他組織との調整を実施した証跡を作るといった小細工も全く不要です。縦割り組織の中に力ずくで横串を突き刺しても、組織にヒビが入るだけで組織の連携にはつながりません。
まずは、自らが調査、分析してきたこと、そして企画の方向性についてわかりやすく説明する資料を作成した上で、関係する組織の職員とフェースツーフェースで話をする。課題が出れば持ち帰って、また話をする。そうやって関係する組織の職員と方向性が合ってきた段階で、関係者を集めた会議を組織する。そのように、丁寧に時間をかけながら段階的に調整を進めていくというのが、調整巧者の王道であるように思います。
D. 必要に応じて制度自体を見直す
サービス・業務を利用者視点で見直す際に、既存の制度やルールが制約になることがあります。
既存のルールを変えることには、大きな労力を伴います。組織内部で定めたルールであっても、変更する理由を関係者に理解してもらうには時間がかかるでしょう。まして、法律、政令、省令等の変更が必要とならば、改正に向けた体制を確立することから始めて相当な準備、調整を行うことが必要です。
そういったことが見えているので、多くの人は既存のルールには手をつけないでおこうと考えてしまいます。利用者に回り道のような面倒な手続きをさせることで既存のルールを回避したり、利用者が不満に感じていることについてもルールがあるから仕方がないとあきらめたりといった事態になりがちです。残念ながら時々耳にしてしまうのが、「私の仕事は定められたルールに則って実施するもの。ルールを決めるのは私の仕事ではない」といった開き直った言葉です。もちろん定められたルールに則ることは大前提ですが、その業務の中で問題があることを把握したときに、どうすべきかを考えるのか、それとも考えるのを放棄してしまうのか・・・。先ほどの言葉は、後者を選んだ人の自己弁護のための言い訳のように聞こえます。
「でも、私だけではどうしようもできない」。業務実施部門の一担当者、情報システム部門の一担当者だけでルールを見直すことは確かに困難です。
まずは、問題を可視化することです。利用者に対してどのような不便をかけてしまっているのか、その問題はどれくらいの頻度で発生しているのか、利用者がそのためにどんな苦労をしてしまっているのか、事実に基づいて問題状況を可視化します。現実に発生している問題を端的に可視化することができれば、その資料は関係者の間に自然と伝播していきます。この資料は関係者の注意を引き付け、そして関係者を団結させて、意思決定に至るための重要なツールになります。
そして、問題が関係者で認識された後は、プロジェクトの体制を確立することです。本書の第２章（プロジェクト管理）でも三位一体の体制として、制度所管部門、業務実施部門、情報システム部門でPJMOの体制をつくることを挙げています。
現実社会において、制度が正しく運用されるようにするところまでが制度所管部門の重要な役割です。これらの部門が一体となり、真に必要性が高いのであれば法律、政令、省令等の変更も含めて対応を行っていくことが、利用者視点でのサービス・業務改革の真骨頂と言えます。
E. システムを作る前に、業務を標準化する
システムを作った後でよくトラブルになるのが、ローカルルールの存在です。
書類の審査一つをとっても、業務マニュアルに書いている審査手順や審査項目はあくまで基本形に過ぎず、いろいろな拠点で審査項目を追加したり審査手順すら変更されていたりします。このような状態のままで業務マニュアルを前提にシステムを作っても、うちの現場では使えないといった反発が多発してしまいます。
前段で説明したように、現場へ行き、現場の業務マニュアルや引継書等のドキュメントを入手すると、このようなローカルルールの実態をよく把握することができます。その上で、これらのローカルルールをそのままにするのではなく、業務を標準化することを検討します。
ただし、ここで注意すべきポイントがあります。「標準化」と、かたくなな「一本化」は異なるということです。標準化とは、何が何でも１つに統一することではありません。ローカルルールが発生した背景を調べた上で、それが組織全体に横展開すべき工夫であれば全体ルールに取り込むべきです。しかし、ローカルルールが発生した背景が、その現場でのサービス内容、地域特性、規模特性、利用者特性等、その現場だけの特性に基づくものであれば、それを無理やり全体ルールに合わせるとかえって不都合が発生してしまいます。そのような場合は、全体ルールだけでなく必要に応じた個別ルールも設定するといった複層的な対応を行います。これが、標準化の考え方です。
システム開発の工数、費用を抑制する観点からも、システムを導入する前には業務を標準化することが必要です。ただし、ここで標準化の意味を取り違え、何が何でも統一するという一本化の考えに立ってしまうと、現場に役立つシステムはできません。似て非なる両者の違いに留意して、本当の標準化を目指してください。
F. 将来の業務フローには、効果を紐づける
企画案についてある程度の方向性が見えれば、その案をプロジェクト内外の関係者にわかりやすく説明して、さらに改善点等のフィードバックを受けたいですね。
その際の最も有用なツールが、将来（ToBe）の業務フローです。
前段の作業で、現行（AsIs）の業務フローについては準備ができています。この現行業務フローをベースにしながら、将来ではどこがどう変わるのか、その変更点を明確にプロットしていきます。システム化により業務効率の向上や負荷が軽減される、システム化により場所的な移動を伴わずに業務ができるようになる、システム化により事前準備していた添付書類が不要になる、このように業務フローの様々なポイントで、変更する点を記載できます。
このように将来の業務フローを作成する際には、変更点を淡々と記載するだけではなく、その変更によってどのような効果が生まれるかをわかりやすく記載することをお勧めします。以下のサンプルでは、吹き出しの形式で効果を示しています。このように想定効果を業務フローに紐づけることによって、効果積算の根拠が明確になるとともに、関係者に対しても目指す姿をわかりやすく共有することができるようになります。
図4-9 業務フロー(将来)の定義例
G. 精緻に効果を積算し、主要な効果を実感可能なものとする
効果は業務フローに紐づけるとわかりやすくなると説明しました。
では、紐づけられたそれぞれの効果の大小を定量的に示すには、どのような積算を行えばよいでしょうか。
効果算定の基本となるのは、「１件あたりの効果」×「件数」という掛け算です。業務時間の削減効果であれば、「業務１件あたりの削減時間」×「業務件数」や、「職員１人あたりの削減時間」×「職員数」といった掛け算になるでしょう。
ただし、この掛け算を安易に実施してしまうと、積算された効果が過大（または過小）になってしまうことがあるので要注意です。効果を積算する過程では、業務の全件を調査することは難しいので、サンプリングを行うことが多いでしょう。このとき、母集団を正しく分類しないままサンプリング対象を選ぶと、その調査で得られた効果想定（１件あたりの平均効果）は全体を正しく代表していません。その状態のままで「件数」を掛け算すると、調査で発生した誤差が大きく引き伸ばされることになり、結果として積算された効果が実態と大きくかい離してしまいます。
では、良い例は、どのようなものでしょうか。それは、効果積算に用いる原単位が、全体を正しく代表する単位となっていることです。業務の中で、効果の観点から特徴が大きく異なるグループがあるのであれば、それぞれのグループでサンプリング調査と効果積算を行い、それらの数値を合計することで正しい数値を積算します。
図4-9 実態をつかむサンプリング調査
このように、サービス・業務の処理単位、実施担当部門、処理する場所等で対象を分類した上で、可能な範囲で詳細な積み上げを行うようにしてください。例えば全国規模で多拠点の業務窓口を持っているところであれば、都市部、地方、山間離島等といったグループに分けて積算することが良いかもしれません。若しくは、利用者向けのサービスメニューで分ける方法もあるかもしれません。効果を積算するに当たって、条件がほぼ同じと考えられるグループに分けて、それぞれのグループで調査と積算を行うことが重要なポイントです。詳細な単位で効果を積み上げることによって、実際にサービスを開始した後のモニタリングにおいても、効果の計画と実績の差を精緻に管理することができるようになります。
また、もう１つ重要なことがあります。精緻に効果を積み上げていくと、効果の小さなものから大きなものまでが合わさり、複雑な計算過程を経て、第三者に分かりにくくなることがあります。
効果の積算結果を多くの関係者から理解してもらうためには、効果全体の中で特に大きな比率を占める主要部分について、その積算方法をわかりやすく示すとともに、確かにそれだけの効果が出そうであると実感できるような補強材料（別観点からの検証や実例等）を準備することが大事です。例えば、ある地方拠点では利用者が手続きをするためだけに週１回、往復３時間をかけて施設へ来所する必要があり大きな負担になっているが、システムを整備することでそれが不要になるとすれば、利用者にとって大きな効果です。このようなリアルな実態を踏まえた事例を効果積算の説明として加えることで、関係者の理解をより深めることができます。
| 事例：業務削減効果の積算方法の見直し
あるプロジェクトでは内部事務のシステム導入を企画するに当たり、投資対効果を検討するために、導入後の業務削減効果について試算を行いました。 当初はサンプルとしてある組織を対象に調査を行い、大まかな業務単位で一人当たりの業務量を推算し、単純人数比で全組織の業務量として計算、全組織の業務量に一定削減率を乗じて効果を算出しました。その結果、業務に費やす時間は組織全体で約３/４に短縮されると試算されました。（下図） 
この情報システムを導入してから数年が経過し、業務削減効果について実態を踏まえた調査を行いました。 最初に組織ごとに異なる業務単位を詳細に把握した上で、組織ごとの件数、回数等を積算し、それらを合算して全組織の業務量として計算し、この情報システム導入前・導入済組織の実測により業務量を調査し、その差分で効果を算出しました。（下図） 
また、当初、業務処理時間として積算していた時間の中には、システムに馴染まない業務の時間を含めていたり、当該府省共通システムを導入する予定がない府省分を含めていたりしたことから、その分を差し引くと、業務処理時間は導入前に試算した値から大幅に減少し、それに伴い、業務削減効果も減少しました。その結果、大まかな積算では見えていなかった数字も明確になりました。 |
H. オープンにサービスを作る
内部の職員だけで企画案の全てをまとめ上げる必要はありません。むしろ、検討段階から積極的に利用者を巻き込んでオープンにサービスの在り方を議論した方が、内部職員だけでは気づけない利用者視点でのニーズを拾いやすくなります。
制度変更等も視野に入れた比較的大規模な検討を行う場合は、外部有識者を交えた検討会を開催する形が一般的な進め方です。検討会の資料や議事等を適時に公開することで、検討会の出席者以外にも広く検討状況を共有します。
また、パブリックコメントを実施することも一般的な進め方です。企画案がある程度まとまった段階で企画案を公開し、国民からの意見を募集した上で企画案を再検討します。
ただ、このような検討会やパブリックコメントといった進め方だけでなく、さらに現場に近いレベルで検討の早期段階から利用者の意見を取り入れる方法もあります。
その一例が、ワークショップの開催です。サービスに関係する様々な立場の利用者、関係者を集めて、現状の問題点を共有した上で、今後のサービス改善の方向性等について意見交換を行います。
ワークショップで参加者が意見を出しやすくするためには、ワークショップ開催までの準備も大切です。前述の利用者視点での分析（ペルソナ分析、ジャーニーマップ等）やサービス・業務の基礎的な情報（サービス概要、利用量等）をあらかじめ提示しておけば、基本的な前提を共有した上で現状の問題点等について効率的に意見の整理を行いやすくなります。
また、パブリックコメントといった正式な手続だけでなく、Webサイト等で適時に検討状況を公開している例もあります。検討案が固まりきった段階で初めて内容を公開するのではなく、検討を進める過程の中で段階的に内容を公開することで、検討経緯や方針決定理由が明確になりますし、利用者や関係者の意見を十分に取り入れることが可能になります。
このようにプロジェクトの状況を公開することは、企画時点だけでなく、システム開発を行っている時や、サービス開始後でも同様に重要になります。特に、国民全般、企業全般、自治体等の関係組織全般に関わるようなプロジェクトについては、プロジェクトの方針、進捗状況、サービス提供状況等について適時に公開するとともに、利用者や関係者の意見を収集できるように考慮してください。
事例：案段階の企画内容をWebサイトで公開 あるプロジェクトでは、国民全般が利用するサービスの改善方法について調査研究を行い、企画案としてまとめた段階でその結果を省のWebサイトで公開しました。 公開した内容は、制度やサービスの変更内容だけでなく、業務の要件がわかるもの（業務要件の一覧や業務フロー図等）、利用するシステムの機能の要件がわかるもの（機能の一覧や情報システムの構成図等）、非機能の要件がわかるもの等です。 
このことによりサービスの利用者の声だけでなく、業務を実施する上での関係組織やこの情報システムの構築を受託する可能性がある事業者を含めて、幅広い関係者から意見を集められました。 そして、実際に集まった意見を踏まえて、制度の内容や業務・システムに求められる要件を見直し、更新しました。 また、どのような制度がいつ頃開始するのか、情報システムの構築がいつ頃行われるのかといった情報を関係者に対して早めに周知することができたことで、プロジェクトを円滑に進めることができました。 |
I. 企画案を客観的に見直してみる
企画案の骨子が固まってきたら、ここで一度、クールダウンしてみることも重要かもしれません。企画を作っている人は、どうしても企画への思い入れが強くなるため、多くの目的を一度に達成しようとしたり、自らの力で全てを作ろうとしたり、少し力みの入ったプランになることがあります。
外部のサービスもうまく取り入れながら、段階的にバランスよくサービスを作り出すために、次のような観点から企画案を眺め直してみて、改善の余地がないか検討してみてください。
u サービスはシンプルにする
複雑なサービスは、利用者が理解できず、サービス利用への大きな障壁になります。既存の制度、ルール、業務分担がある中で新しいサービスを生み出そうとすると、既存の制度等を残存させながら新たなやり方を追加するといった屋上屋（おくじょうおく）を重ねる形になりがちです。前述の「縦割り組織にやわらかく横串を刺す」に記載したことと重複しますが、利用者の視点から極力シンプルにサービスを利用できるように、既存の制度等の見直しも含めて検討してみてください。
特に、利用者に提出や入力を求めるような「手間」が発生することについては、今の企画案で本当に「最小限」になっているか、逆に行政側から提供する情報が過多になっていないか、利用者にとって必要性の高い情報をわかりやすく提供できるようになっているかという観点で、確認してください。
また、システムの使い勝手についても同様です。システムを初めて利用する人やＩＴに詳しくない人でも、自力でサービスを利用して完結できる状態が理想的ですね。実際にシステムの画面等を考えるのは設計段階の話になりますが、企画段階においても利用者の操作性について必要な配慮が行われているか、今一度確認しましょう。
u デジタル技術を徹底的に活用する
デジタル技術は日々進化しています。今までは手間を掛けなければできなかったことが、デジタル技術を活用することで飛躍的に効率的に実施する可能性があります。
例えば、このようなキーワードに該当する活動がないでしょうか。企画案や業務内容を見直してみて、デジタル技術をもっと活用できる余地がないか検討してみてください。
・遠隔地からのモニタリングを人手で実施している
→ ＩｏＴ技術、センサー技術等を活用してモニタリングを自動化できないか(注記:IoTとは、「Internet of Things」の略称。従来のＩＴ関連機器のみならず、家電やセンサーなど、あらゆる物がインターネットにつながる仕組みのこと。)
・熟練者による目視点検で品質や老朽化状況の確認を行っている。
→ ＡＩ、画像解析技術等を活用して、効率的かつ高度な確認が行えないか
・申請内容の形式的なチェックを人手で実施している
→ ＡＩ等を活用して自動審査できないか
・複数のシステムに同じ情報を再入力している
→ ＲＰＡ等を活用して、作業を自動化できないか
・電話で問合せへの対応業務を行っている
→ 定型的な質問へはチャットボット（音声やテキストで自動応答する仕組み）
等で対応できないか
・業務やシステムで収集したデータを十分に分析できていない
→ データ分析ツール等を使って、サービス改善への基礎分析を行えないか
また、情報セキュリティとプライバシーを確保する観点からも、ITマネジメント全体を通してリスク管理を適切に行い、情報セキュリティ対策を確実に行うデジタル技術の活用が重要ですし、自動運転、ドローン等、高度なデジタル技術を前提とした新しい仕組みも活用できる可能性があるかもしれません。
なお、各府省がデジタル技術を活用することも重要ですが、各府省が保有するデータをオープンデータとして活用し易い形で公開することによって、国民や民間企業等の外部関係者がデジタル技術を効率的に活用できるようにすることも重要です。このことについては、第５章「要件定義」のデータ・情報に関する事項と併せて十分に検討してください。
u システムではなくサービスを作る
「システムを作ることが目的化する」という言葉がよく聞かれます。利用者が実感できる効果を達成するといった本来目的を達成するための手段としてシステムを作るはずだったのに、いつのまにかシステムさえ作ればよいと、システムの整備完了のみが目的化する状態です。
特にシステム整備の中でＡＩのような最新のデジタル技術を使うときには、注意すべきことのように思われます。前述したように、デジタル技術を徹底的に活用すると大きな効果を得ることができます。しかし、サービス・業務をどのように変えるかという明確な目的がなく、ただＡＩを導入すれば何とかなるだろうといった進め方では、効果がうまく得られません。ＡＩを入れれば業務課題が自動的に解決するわけではなく、ＡＩを適用すべき範囲に正しく導入してこそ効果を生み出すことができるからです。
むしろ、全ての範囲をシステムが担うのではなく、一部は人手による作業を交えた方が、サービスの品質を上げられることもあります。
システムを作ることも同じです。システムは、あくまで手段です。全てを情報システムで実現するのではなく、必要に応じて人手によるサービス等も組み合わせて、最良のサービスを利用者に提供するという本来の目的を最優先に考えましょう。
u 自分で作りすぎない
サービスを一から自分で作ることも選択肢ですが、もっと効率的に作る方法はないでしょうか。民間サービスで活用できるものがあれば、そのサービスを活用した方が良いかもしれません。職員採用のWebサイトを立ち上げるなら、民間の人材採用Webサイトのサービスを利用した方が良いかもしれません。
また、ＡＰＩ連携を使うことも有効です。前述の事例（利用者が日常的に使用するソフトウェアからのＡＰＩ申請）で説明したe-Govでは、利用者が日常的に利用する労務会計ソフトウェア等から電子申請が行えるようにしました。これを可能としたのが、ＡＰＩ連携です。
行政自らがサービスを作るだけではなく、過剰な機能や独自技術の活用を避け、多くの人から利用しやすくするように心掛けることが重要です。
u 外部に丸投げしない
自分で作りすぎないことを前述しました。一方で、自らが責任を持ってプロジェクトを運営することは最も基本的な大前提です。自分で作りすぎないという考え方を言葉尻だけで捉えると、必要な予算だけは確保し、あとは委託事業者や補助金分配先の関係機関が実施すればよいと強弁する人がいるかもしれませんが、これは全く推奨できない進め方です。
あくまで、サービス、業務、システムを作り運営する主体は、プロジェクトの運営を行うＰＪＭＯ自身です。もちろん、全ての作業を職員自らが行う必要はなく、委託事業者との契約や、補助金による関係機関主体での対応を依頼することもできますが、その際においてもプロジェクト全体としての目的達成のために、サービス・業務の改革方針を立て、システム整備の方針を立て、プロジェクトの進捗を管理し、サービス開始後も運営状況を確認し改善を続けていくのはＰＪＭＯ自身です。
そのため、複数の関係機関が連携して対応を行うプロジェクトについては、ＰＪＭＯ自身がプロジェクトの運営を確実に行えるという観点から、システム整備の形態（分散型、集中型等）、システム整備の進め方（仕様の共通化、スケジュールの全体整合等）を検討することが必要です。
| 事例：個別管理システムを統合してサービス向上とコスト削減を実現
あるプロジェクトでは、全国的に多数存在する関係組織がそれぞれ紙台帳による管理を行っていた情報を電子化してインターネット経由で検索できることを目指して、情報公開システムを開発することとしました。 当初の計画では、プロジェクトの中心となる業務取りまとめ組織（ＰＪＭＯ）から全国の関連組織に補助金を交付し、各々の組織が個別に情報システムを構築することを予定していました。 しかし、この計画のままプロジェクトを進めると、関係組織ごとに異なるシステムが存在するため、利用者は欲しい情報を一元的に検索することができません。 また、システムの操作方法等も異なってしまうなど、利便性の観点から問題がありそうでした。また、関係組織がそれぞれ独自にシステムを整備するため必要となるコストが増大することも懸念されました。 
さらに、このような関係組織が個別にシステムを整備する形態とすると、システムの内容や提供するサービスが各組織でそれぞれに決定されるため、業務とりまとめ組織であるＰＪＭＯが全体管理を十分に行うことができないことも懸念されました。 そこで、この業務に求められる要件を満たした上で、利用者視点の要件を実現するために再検討を行いました。その結果、この情報公開システムはクラウドサービスを利用して開発することとし、関係組織が必要な情報を登録する形態とすることで、１つの統合システムで全国の情報を一元的に管理することとしました。 
このような見直しを行ったことで、この情報公開システムでは正確で豊富な情報を全国一元的に検索することが可能となり、統一したユーザインタフェースにより使い勝手も向上した結果、稼働開始直後から多くの利用者が利用することとなりました。 さらに、法令・制度が改正された際のシステム改修コストの抑制、運用保守コストの抑制にも寄与することとなりました。 |
U 注記 ユーザインタフェースとは、ユーザから見た「見た目」。アプリケーションの画面デザイン（色、情報の配置、操作ボタンの位置等）のこと。ＵＩとも呼ばれる。 |
Step.6 軌道修正
プロジェクトを立ち上げた際に目標や実施方針を定めていますが、サービス・業務企画を詳細に進める中で、当初は見えていなかった様々な課題や制約条件等が明らかになるはずです。当初に考えていた進め方よりもっと良い進め方があれば、目標自体や実施方針を見直し軌道修正を行うことが重要です。
このStepでは、そのような軌道修正について解説していきます。
１ 軌道修正しやすい進め方にする
【標準ガイドライン関連箇所：第３編第４章第４節】
プロジェクトの目標は同じでも、その進め方によって成否は大きく異なります。
後から何度でも軌道修正を行いやすいようにするには、一度に全てを作り上げるのではなく、段階的にサービスを導入しながら細かく変更を行っていく進め方を採ることが望ましいと言えます。
A. 一遍にやらず、一貫してやる
今までにないサービスを始めたり、既存のサービスを大きく変えたりするような難しいプロジェクトほど、全てを一度に実施するべきではありません。このような「一遍」に新しいやり方に変える進め方は、利用者のニーズに十分に応えることが難しいためです。
民間企業で製品開発を行うときは、必ず試作を行い、機能、品質、費用等の様々な要素から検証を行い、修正を何度も行いながら、最終的に製品として成功できると実感を持てるものを製品化します。
プロジェクトも全く同じです。開発段階でプロトタイプを作って利用者によるテストを行ったり、本番運用も一度に行うのではなく一部の利用者を対象に実証実験を行ってから本格的に展開するなど段階的に整備することによって、利用者の声を取り入れながら軌道修正を積み重ねることができます。これが、「一貫」した進め方です。
２ 柔軟に軌道修正する
【標準ガイドライン関連箇所：第３編第４章第４節】
軌道修正しやすい進め方を採用したとしても、やはり軌道修正をすることに躊躇してしまうことは理解できます。しかし、軌道修正すべきタイミングで軌道修正しなければ、その後プロジェクトは十分な効果を達成できなくなります。
次に、実際に軌道修正を行う際の考え方を解説します。
A. 何度も繰り返す
行政の無謬性（むびゅうせい）という言葉があります。行政は絶対に間違いを起こさないという考え方です。この前提に立ってしまうと、仮にプロジェクトを進める中で修正すべき点に気づいても、修正を行うと過去の判断が間違いであることを認める形となってしまうため、修正することができないといった事態に陥ってしまいます。
行政は無謬ではありません。プロジェクトも無謬ではありません。限られた人数、時間制約の中で、もちろん可能な限り現状把握や分析を通してサービス・業務の企画を行いますが、実際の企画を実現に移す段階で修正すべき点が発生してくるのはむしろ当然のことです。修正すべき点が全く出てこないとしたら、恐らく修正意見の聞き方を間違えていると考えた方が良いでしょう。軌道修正を躊躇し、初期の決定に固執してプロジェクトを進めると、利用者がほとんどいないサービス・業務が出来上がり、運用保守経費だけが毎年計上されるような悲惨な事態を引き起こしかねません。
このような考え方を前提においた上で、プロジェクト初期に想定したサービス・業務企画の前提となる課題や仮説が、現状調査の結果と異なっていたことが判明したときは、プロジェクト計画全体の軌道修正を検討しましょう。 試行的にサービスの提供や業務を実施し、利用者や関係者からのフィードバックを踏まえてサービスの見直しを行うなど、何度も確認と改善 のプロセスを繰り返しながら品質を向上させることが重要になるからです。
この考え方は、サービス開始後も全く同じです。継続的に利用者や関係者からの意見を収集し、常に改善を図っていきましょう。
考え方のわかりやすい目安としては、「60点を目指す」ということかもしれません。最初から100点満点のサービスが提供できればよいですが、なかなかそうはなりません。まずは60点のサービスを提供することに注力します。60点のサービスが提供できれば、次に残りの40点に対しても改善を検討します。残りの部分についてさらに60点の改善を行えば全体で84点になります。もう一度改善を行えば93.6点となります。
それぞれの活動の目標は60点であっても、それを繰り返すことで高得点となります。ポイントは、改善のサイクルを早くすることです。まずはチャレンジし、次々に改善をしていくという姿勢を貫くことが、結果的には成功への早道です。
このような考え方に基づいて、サービス・業務企画の内容に軌道修正が必要かどうか、事実を積み上げて得られた内容に基づいて冷静に判断してください。
実施手順
・ 当初想定した内容と把握した事実との差異を客観的に分析し、軌道修正が必要な対象を明らかにする。
・軌道修正の方向性を、対象ごとに適切な関係者と検討する。
・検討した軌道修正の方向性をとりまとめ総合的に判断した上で、プロジェクト全体としての修正方針を検討する。
| 事例：一部地域で試行してから、サービスを全国へ展開
ある省では、対象者が全国規模となる調査業務を実施していました。 この業務では、回答率の向上と、大量データの集計作業を軽減することが重要な目標でした。そこで、調査回答を従来の紙様式だけでなく、オンラインでも受け付けられるようにするシステムを整備することとしました。調査対象者がデータを入力する手段については、パソコン用のWebサイトだけでなくスマートフォン用のWebサイトも用意し、極力簡単に登録が行えるように工夫を行いました。 
ただし、このオンライン回答については、全国で一斉にサービスを開始するのではなく、まずは一部の地域のみで先行的にサービスを開始することとしました。 試行的に実施を行うと、このサービス自体が回答率の向上と集計作業の軽減という目標にどの程度貢献できるかを、しっかり見定めることができます。また、施行実施の中で、どれほどの人数がオンラインでの回答を行ったかという実績値を取得することができるため、サービスを全国展開した際にシステムに必要となる能力を適切に見積もることもできます。 一部地域での試行の結果、当初の見込みどおりにパソコンとスマートフォンの両方から十分な数のオンライン回答があったことから、その後の調査では機能の拡充やインフラの整備を行った上で、このサービスを全国に展開することとしました。 
全国展開を行った結果、オンライン回答の割合は、当初見込んでいた予想を大きく上回り、約４割となりました。オンラインを利用した回答率が上がったことで、集計作業が軽減され、集計作業に要する時間を約３割削減することもできました。また、調査結果を今までより早く公開することも可能となりました。 |
B. 無理に継続しない
軌道修正の考え方の延長となりますが、軌道修正だけでなくプロジェクトの継続必要性自体を判断しなければならない局面もあります。
前述の行政の無謬性の観点からは、プロジェクトを中止することはなかなか判断に迷うことになるでしょう。特に既に予算をつけて契約をしてしまっている段階では、なおさら途中で中止することへの抵抗が大きいこともわかります。
しかし、費用対効果に乏しいと判明したプロジェクトをそのまま継続すると、この先もっと多くの経費が支出され、ほとんど効果が得られないこととなります。長期的な見地に立てば、いつか「あの時、中止判断をしておくべきであった」と振り返られることになるでしょう。「後悔先に立たず」です。後から振り返るのではなく、適切な時期に判断を行うことこそ、行政運営を担う者として最も重要な責務の一つです。
プロジェクトを中止にする理由には、様々なものがあるでしょう。外部環境や内部環境の変化、プロジェクト初期段階の検討不足、プロジェクト進行中に判明した重要課題の存在等です。プロジェクトを中止するためには、関係者にその理由を説明することが不可欠です。プロジェクトの企画運営に携わった当事者として、中止に至った背景や理由については十分に分析を行うとともに、今後同じような失敗を繰り返さないための教訓として整理し、後日参考にできる形にして残しましょう。
プロジェクトを中止するための実務的なプロセスについては、まず、ＰＭＯやＣＩＯ補佐官に相談してください。
判断時の留意点
・ 過去決定した方針を変えるためには、関係者に理解を得るための情報が必要となる。方針を変えずに継続した場合と軌道修正や中止した場合、双方の影響を客観的に整理し、可能な限り数値化する。
・特に連携するサービス・業務があるときは、連携先の影響も含めた説明資料を準備することが重要である。
・中止判断が遅れるほど、影響は深刻化する。ＰＭＯやＣＩＯ補佐官に相談して早めにアクションを取ることを心がける。
Step.7 新しい業務要件の定義
新しい企画方針が出来上がれば、この内容に基づき新しい業務要件を定義します。
現行の業務をベースに変更部分を明らかにしていく、全く新規にサービス・業務を作り上げるなど、様々な状況が考えられますが、いずれの場合も進める際に理解しておくべき手段やノウハウについて、解説していきます。
１ 業務要件をまとめる
【標準ガイドライン関連箇所：第３編第４章第５節】
新たなサービス・業務企画の方向性が固まってきました。あなたはその内容を正確に第三者に説明できますか？
ここでは、新たなサービス・業務企画の内容を、業務要件という形で要素を分解して、可視化を行います。「要件」という言葉から、情報システム寄りの印象を受けるかもしれませんが、「業務要件」は、業務フローや、業務をいつ、どういう役割の職員が行うのかといった、サービス・業務の姿そのものを整理したものが中心となるため、実際に業務を実施する職員の視点に立たないと定義できません。
車の購入に例えると、業務要件は「アウトドアでキャンプする」「子どもの送り迎えをする」といった具体的な利用シーンを表します。機能要件（要件定義以降で検討）は、「４ＷＤで８人乗れるワンボックス」「チャイルドシートを装着しても、買い物を入れるスペースがとれる軽自動車」となり、それぞれ排気量や搭乗人数等の詳細な仕様を決定していきます。機能要件については自動車ディーラーに相談することができますが、業務要件は車を利用したい当事者でしか定義できません。ここで作成する業務要件も、まさに当事者にしか作成できないものです。
業務要件には、新しい業務実施手順（業務範囲、業務フロー等）、業務の規模、時期・時間、場所、目標として管理すべき指標、システム化の範囲等を記載します。具体的な書き方については、別紙のひな形を参照してください。基本的には、サービス・業務企画で検討してきた様々な分析結果を総合的にまとめた資料となります。
業務要件で作成した資料は、後続工程となる要件定義のインプットとして利用できます。
| 様式例：業務要件定義書のひな形
業務要件定義書のひな形を本章別紙としてまとめています。  |
２ 定義内容を関係者に共有する
【標準ガイドライン関連箇所：第３編第４章第６節】
新しいサービス・業務を定義したドキュメントが出来上がることで、関係者にとって理解しやすくなり、これまでは意識していなかった考慮点や抜け漏れが発見できる可能性があります。
そのため、作成した業務要件の定義内容を関係者に確認してもらい、その結果明らかになった変更要望や新たな課題は、ＰＪＭＯ内で対応方針を検討し、業務要件に反映した上で、再度関係者と共有してください。これにより、業務要件をより精緻なものへと更新することができます。
また、関係者に説明することで曖昧な内容や難解な箇所を修正でき、後続工程で事業者を含む第三者が理解しやすい内容になります。
【コラム】外部委託事業者の関わり方
サービス・業務企画は、現状の調査から始まり、最終的には業務の要件を定義するまでの作業が含まれます。これらの作業には、多くの作業量が必要となったり、業務分析や情報システムに関する専門的な知識が求められたりします。その際に、これらの作業の一部についてコンサルティング等を専門分野とする事業者に委託することも選択肢の一つです。
ただし、外部委託事業者に作業を丸投げしてはなりません。作業を進める際に、発注者として気をつけるべきポイントについて見ていきましょう。
A. 事業者と役割分担して作業を進める
事業者にサービス・業務企画の作業を委託する場合、ＰＪＭＯと事業者とが「協働」して活動を進めていくことが重要です。事業者はサービス・業務企画を行うための知見を持っていますが、業務の実情を詳細に知っているわけではありません。また、ステークホルダーとの調整や作業の方針・内容の決定等、ＰＪＭＯにしかできない作業も数多くあります。
何より、成果物の内容を決定する責任は、ＰＪＭＯにあります。事業者が作成したドキュメントの内容で理解できないものがあれば、ＰＪＭＯから事業者に説明を求めましょう。
また、実際のプロジェクトでは、他の様々な事業者からの協力を得ながら作業を進めることになりますが、構築する過程における認識の相違や後から発覚する制約等によって、本来実現したかった理想と現実とにかい離が発生することが多々あります。
これらを防ぐために、ＰＪＭＯや関係職員がサービス・業務企画の各活動に細かく関与し、成果物（要件定義書や設計書等）をこまめにレビューしていく必要があります。ただし、ＰＪＭＯや関係職員のリソースに制限がある場合は、レビュー対象とする成果物や活動への関与を平準化し、一部の成果物や活動に偏らないバランスを取った関与の仕方を工夫することは有効です。
事業者に作業を委託する場合の留意点を以下に記載します。
委託時の留意点
・全ての作業を事業者に委ねないよう、役割分担を明確にし、事業者と合意する。
・優先順位付けや企画内容の決定等の意思決定は、発注者が責任を持って行う。
・事業者とこまめなコミュニケーションをとり、事業者が実施できない作業（ステークホルダーとの調整等）を把握し、実施する。
・事業者が作成する成果物をレビューし、不明点があれば事業者に対して説明を求める。
B. 発注者の、要件定義への関わり方
特に要件定義を行う際は、発注者側が積極的に関わっていく必要があります。業務要件は情報システム要件のインプットであり、対象システムに関わる全てのステークホルダーとの調整を経て確定するものです。そのため実情を把握していない外部委託事業者に丸投げすることは、論点が曖昧なまま要件が定まったように見える事態を発生させることにつながります。業務要件が定まっていないケースでは何度も情報システム要件に変更や追加が発生し、スケジュールやコストに大きなマイナスが発生します。業務要件がしっかり定まっているプロジェクトは、それ以上の手戻りが発生しないためスムーズに進行できます。
要件定義を外部委託する際の発注者としての留意点を以下に記載します。
要件定義を外部委託する際の留意点
・業務要件定義書は発注者が作るものです。発注者側が積極的に関わる体制を用意するよう意識して下さい。
・具体的な成果物の作成を役割分担も含めて調達仕様書に入れ込むことが最初の一歩として重要です。特に調達時に「支援」という言葉を使ったケースでは、原案を外部委託事業者が作成する認識がないケースがありますので、原案作成の役割について調達仕様書に明示することが重要です。
・要件定義において、選択可能な実現方式案を作成したうえで、各案のメリット・デメリットは外部委託事業者に明示させましょう。方式案採用の最終判断はリスクアセスメントを実施した上で発注側が行います。