第８章　サービス・業務の運営と改善

デジタル・ガバメント推進標準ガイドライン実践ガイドブック

第８章　サービス・業務の運営と改善

Step.1 サービス・業務の運営と改善の流れ

Step.2 新しいサービス・業務の事前準備

１運営と改善は、職員主体の作業である

A. 『サービス・業務の運営と改善』を外部の事業者に丸投げしない

B. 『サービス・業務の運営と改善』は他工程の作業と並行で実施する

C. 関連する業務実施部門との責任分担を意識する

２業務手順書は様々な用途に有効活用できる

A. 業務マニュアルと他のマニュアルとの違いを理解する

３リハーサル計画・シナリオは職員目線で

A. 移行リハーサルを計画・実施する

B. 業務リハーサルを計画・実施する

C. サービスの開始や変更を利用者に確実に周知する

Step.3 業務の定着と次の備え

１職員に継続的な教育を行う

A. 研修・教育の準備を十分に行う

B. 研修・教育は１回では定着しない

２定着には利用者への働きかけが必要

３業務で扱うデータの品質を確保する

A. 計画どおりにデータを入れないと情報システムの価値はない

B. 分析しやすいデータ構造でないと、何かするにもカネがかかる

４業務改善に向け日常業務の事実を蓄積する

A. ＰＪＭＯ・職員が様々な情報を収集し、定常的に管理する

B. 情報システムのログ等、運用活動に関わる情報を取得可能にする

C. 効果測定ができるように、ＫＰＩを自動的に取れるようにしておく

D. 多数のインシデントや要望等の対応の優先度を付ける

Step.4 業務の改善

１日常業務中でも改善できることを理解する

２検討の進め方を理解する

事例一覧

事例：外部委託で業務効率が向上

事例：外部委託でトラブルが発生

事例：利用者への周知が不十分なプロジェクトの顛末

事例：プロモーション実施・モチベーション向上策の例

事例：データの信頼性が低いためにシステムが信用されない例

事例：データを出力するだけなのに時間とカネがかかる例

事例：詳細な調査・分析により運用業務の無駄を削減

事例：アンケートだけで情報システムの改修要件を定めて無駄な改修となるおそれがあった例

事例：インシデントの分析結果を利用者へ公開して、利便性を向上

Step.1 サービス・業務の運営と改善の流れ

サービス・業務の運営と改善で行う作業の実施時期や内容をご存知ですか？

サービス・業務を運営することは、職員の皆さんにとって日常的なものであり、イメージが付きやすいと思います。それでは、新しい情報システムを利用することを想定した場合、どのような作業が新たに発生するでしょうか？

ここでは、新しい情報システムを利用するに当たり、準備の段階から利用開始後を含めて、作業を推進していくために必要となる具体的な知識やノウハウについて説明します。

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

Step.2　新しいサービス・業務の事前準備

新しいサービス・業務を始める前に、業務を円滑に進めるために意識しておくべき心構えや注意すべき点をいくつか説明します。

Step.3　業務の定着と次の備え

新しい業務を開始すると、その業務をできるだけ早く現場に定着させ、業務の効率を上げることが求められます。利用者に積極的に使ってもらうための工夫も、定着に向けたカギとなります。

また、データマネジメントの観点を意識しながら、業務で取り扱うデータの品質を維持していかないと、肝心なときに必要な情報が取得できなくなり、業務を効率化できない割に運用・保守コストだけがかかるような、使えない情報システムになりかねません。

それらを意識しながら、日々の業務における様々な情報を把握・分析し、総合的に検討して業務を改善するための進め方について説明します。

Step.4　業務の改善

業務の改善は、日常的に改善できるものと、情報システムや業務そのもの等、時間をかけて見直すものがあります。ここでは、日常的な改善についてポイントを説明します。

Step.2 新しいサービス・業務の事前準備

今まで行っていたサービスや業務を改め、新しいサービス・業務を開始する前に、理解しておくべき前提知識や心構えについて説明します。

１運営と改善は、職員主体の作業である

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

新しい情報システムを利用してサービスや業務を実施する際、ＰＪＭＯの職員は情報システムを構築することに意識が行きがちです。一方、利用者にとっては、情報システムが構築直後に「満足な出来」であることは少なく、大なり小なり期待値とのギャップがあります。これを解消するため、利用者からのフィードバックを得ながら、業務と情報システムの双方を改善していく活動を継続していくことが重要です。

この仕事は、職員が主体となって実施していくこととなります。仮に外部の事業者が極めて優秀かつ良心的であったとしても、やはり業務と情報システムの両輪を相互に調整しながら改善していくマネジメントは、業務を熟知した職員がリードしていくほかありません。

これらの点について、以下に解説していきます。

A. 『サービス・業務の運営と改善』を外部の事業者に丸投げしない

サービス・業務を運営する中では、業務・サービスに関連する日常的なオペレーションはもちろんのこと、問合せや要望への対応、利用促進のための周知や広報活動等、様々な活動を職員が主体的に実施します。

ただし、一部の作業については、職員が正しく作業を切り出し指示や管理をすることを前提に、外部の事業者に作業を委託できるものがあります。例えば、業務で発生するデータの入力業務や、帳票の仕分け業務等です。

では、どのような業務が事業者への委託に向いているでしょうか？一般的には、次の図のような考え方ができるでしょう。

図8-1　外部委託の向き／不向きの判断例

ただ、事業者にサービス・業務を一度委託すると、委託を止めて職員が実施する状態に戻すことは難しくなります。業務実施場所、関連機器等を再度確保する必要がありますし、何より体制を作り直して実際に業務をする職員のスキルを元通りに戻すことに相当の時間がかかるためです。

そのため、外部委託をする場合は、職員による業務実施への回帰や事業者の変更に備え、業務ノウハウが職員にも残るような工夫をすることが重要です。また、事業者に対して適切な指示ができるように、業務概要を理解し、日常的な報告・記録を確保することが重要です。

業務を外部委託する際の注意点

・外部委託する業務は、職員が主体的に行う業務に対する支援や補助となる作業であり、それを行うことで職員の業務効率が向上するものであること。

・外部委託した業務成果の正誤や品質状況を職員が判断できるように、プロセスの透明化と必要十分な報告・記録を確保すること。

・外部委託した業務の実施方法や、事業者が作成する業務マニュアル等の内容を適宜確認し、職員自身も業務の概要を理解し続けること。

・特定のサービス・業務について、異なる作業範囲や役割を複数の事業者に外務委託する場合は、緊急時（システム故障やセキュリティインシデント等）に備えて、できるだけ特定の事業者に業務統制的な役割を定義しておくこと。

事例：外部委託で業務効率が向上

ある府省では、業務の運営上、日々収集される書類や記録等を、情報システムにデータとして入力する作業が存在していました。この作業は、特別な業務のノウハウが必要ではなく、入力作業の手順さえ守れば、だれでも行うことができる内容でした。

そのため、職員は入力手順を定めた作業手順書を作成し、このデータ入力業務を外部の事業者に委託することとしました。さらに、作業の実施状況を把握し、作業上の不明点に答えられる管理体制を構築しました。

これにより、外部委託前に比べ、業務の効率を向上させることができました。

事例：外部委託でトラブルが発生

ある府省では、新しい情報システムの運営を開始するに当たり、新しく業務の実施手順をまとめたドキュメント（業務手順書）を作成する必要が発生しました。

そのため、業務手順書の作成を外部の事業者に委託しました。作業するに当たり、新しいサービス・業務の内容がわかるように要件定義書を渡しました。

しばらく後、出来上がった業務手順書を見ると、内容は情報システムの使い方が中心となっており、業務の担当者が意識すべきルールや制約事項等を読み取ることができないものとなっていました。現場の業務担当者からも、利用できないという不満が上がってきました。

結局、業務手順書は改めて、職員が主導で作り直すことになってしまいました。

B. 『サービス・業務の運営と改善』は他工程の作業と並行で実施する

次の図（図8-2）をご覧ください。これは、標準ガイドライン第３編の各章で規定した作業が実際のプロジェクトが９年程度の期間でどう位置づけられるかを表したものであり、第８章の範囲を強調しています。

図8-2　サービス・業務の運営と改善とその他の工程の関係

これまで紹介してきた、「第４章サービス・業務企画」から「第７章設計・開発」までの流れは、サービス・業務を企画・設計し、必要となる情報システムをどう構築していくか、という作業が中心となっており、この後の章で紹介する、「第９章運用及び保守」は、新しい情報システムがリリースされた後、どう運用していくか、という作業が中心となっています。

それらを踏まえて、第８章の位置づけを見ると、その全ての期間を通じて作業が発生しています。また、情報システムが構築される前からリリースされた後まで、全ての範囲に関係しています。

第８章で定義した作業と他の工程との関係を、第８章を中心に書いた図で紹介します。個々の作業の定義は標準ガイドライン解説書を見ていただくとして、ここでは、第８章が１つの作業プロセスとして独立して進められるものではないことを理解しておきましょう。

図8-3　サービス・業務の運営と改善とその他の工程の関係（詳細）

『サービス・業務の運営と改善』作業と他の工程との関係

第８章１．サービス・業務の運営開始」は、サービス・業務をリリースするまでの準備作業であるため、主に「第７章設計・開発」で実施される作業と依存関係があり、時間的にも並行で作業を実施します。作業は、「第２章プロジェクトの管理」や「第４章サービス・業務企画」の作業の結果を踏まえて行う必要があります。

・「第８章２．サービス・業務の運営」は、サービス・業務を継続的に運営する作業であるため、主に「第９章運用及び保守」で実施される作業と依存関係があり、時間的にも並行で作業を実施します。これ以外にも、運営中に発生する課題や要望を集約し、その対応を判断し、その結果によってその他の章で定義されている作業に振り分けます。（※これはＩＴＩＬが定める問題管理に相当します。）
(注記:ＩＴＩＬ（Information Technology Infrastructure Library）とは、1989年に英国政府のＣＣＴＡによって公表されたＩＴサービスマネジメントにおけるベストプラクティスをまとめたもの。2018年時点ではＶ３である。)

・「第８章３．サービス・業務の改善」は、他の章で定義された作業とは関係しません。「第８章２．サービス・業務の運営」で集約された様々な課題や要望は、その解決のために様々な作業に振り分けられますが、軽微な改善はここで定義された作業で行います。

C. 関連する業務実施部門との責任分担を意識する

複数の組織や情報システムをまたがってサービス・業務を運営する場合は、関連する組織と、業務の責任範囲を明確にしておく必要があります。これを怠ると、トラブルの発生時に誰がどこまで対応を行い復旧の責任を持つかといった問題がこじれてしまう可能性があるからです。

特に情報システムが関係するトラブルの場合は、発生してから一定時間は、真の原因が不明であったり、本質的な問題解決方法が見いだせなかったりすることがあります。このため、単に責任分界点を定めただけでは「責任の押し付け合い」を招き、解決を遅らせる懸念もあります。

例えば、次の図で示すようなケースを考えてみましょう。１つの情報システムをＡ、Ｂの２つの組織が利用しています。Ａ組織はデータを入力する業務を行っていますが、そこで誤ったデータを入力してしまいました。しかし、そのデータを使うＢ組織は、データの誤りに気付かず、そのデータを使って業務を実施してしまいました。そして、Ｂ組織で不具合として顕在化してしまいました。

このケースの場合、不具合の責任がA、Bのどちらにあるのか、一概には判断することができません。データの正確性を確認する責任が、Ａ、Ｂ、どちらの組織にあったのかが判断のポイントになるでしょう。しかし、あらかじめこのような事態を想定した責任分担を行っていないと、トラブルが発生した後で議論や調整に時間を取られてしまい、速やかな対応ができません。

図8-4　複数の組織が関係するトラブルの例

このような事態を未然に防止するために、サービス・業務の運営を開始する前には、業務実施分担や責任分担等について、関係する組織と十分に事前調整を行ってください。

２業務手順書は様々な用途に有効活用できる

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

業務手順書の作成を外部委託しトラブルが発生した事例を前に触れましたが、業務手順書は、その認識の仕方が人によって異なっていることも多く、同じ名称でも中身が異なることが多くあります。

ここでは、業務手順書を作成することの目的や効果、業務手順書と類似のドキュメントの違い等を説明し、認識を合わせます。

A. 業務マニュアルと他のマニュアルとの違いを理解する

情報システムを用いてサービス・業務を運営するために、様々なマニュアルが存在します。

マニュアルに関する全体的な解説は、実践ガイドブック「第７章Step.5－3．種類を理解し揃えるマニュアルを厳選する」を参照してください。

業務マニュアル作成時の注意点

業務マニュアルは、同じ業務に携わる担当者が共通の理解を持つために有効ですが、組織や取り扱う情報の種類によっては、同じ業務でも異なるルールが存在する場合があります。いわゆる、ローカルルールと呼ばれるものです。これを全て業務マニュアルに記載しようとすると、膨大な量となり、マニュアルの更新が追いつかず、現場とのかい離が発生するおそれがあります。同じ業務内で共通化するものと、組織ごとに個別に定めるものとで分けて業務マニュアルを作成することで、その後の保守性を向上させることができます。

図8-5　業務マニュアルに載せる範囲

・業務マニュアルは、そのまま職員向けの教育資料の一部とすることができます。そのことを念頭に、業務マニュアルの内容・構成を検討してください。

・業務マニュアルには、具体的なシステムの操作手順にとらわれず、業務の流れや手順を中心に記述してください。その流れの説明において、情報システムのどの機能を使うのか、がわかれば、使いやすいものになります。情報システムの操作手順や画面説明の詳細はシステムマニュアルに任せることで、マニュアルの品質を上げることができます。

・業務マニュアルは業務全体の業務フローを理解している職員が作成、又はレビューしてください。そうすることで、マニュアル上の業務説明が途中で途切れたり、内容の重要性に偏りが出たりすることが防げます。マニュアルが出来上がったら、業務に初めて携わる職員がそのマニュアルを読んで業務が行えるか、という観点でチェックしてください。

３リハーサル計画・シナリオは職員目線で

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

リハーサルとは、新しい情報システムがリリースされる前に、業務の切り替え（移行）時の手順や切り替え後の作業内容を職員目線で確認する行為です。業務の切り替え（移行）時の確認行為を移行リハーサル、業務切り替え後の作業内容の確認行為を業務リハーサルと呼びます。

A. 移行リハーサルを計画・実施する

移行リハーサルでは、現行の業務で使用していた情報を、あらかじめ設計した方法で新しい情報システムに取り込み、想定どおりに動作することを確認します。それに向け、リハーサルの実施計画や実施手順を作成し、計画に基づいて、手順どおりにリハーサルを実施します。

移行リハーサルの計画立案は、情報システム構築事業者に依頼します。ただし、計画上の実施時期や回数、位置づけ等に関するチェックは、ＰＪＭＯが中心になって行います。

また、移行に際し、気を付けるべきポイント等、職員しか判断できないものについても、ＰＪＭＯ及び業務実施部門が事前にチェックしてください。チェックの内容には、新しい情報システムに移行する情報について、現行のどの情報をいつのタイミングで抽出するのか。また、例外的な情報等は、事前に決めたとおりに扱うことになっているか等があります。

B. 業務リハーサルを計画・実施する

業務リハーサルでは、新しい情報システムをリリースした後に、切り替え後の業務を円滑に遂行できるよう、職員が主体となって、業務内における職員の役割分担や、情報システムを含む業務の実施手順を確認します。例えば、今までの業務にて担当者間で書類を手渡ししていたような場合、オンライン化によって、誰がどこまで書類のデータをシステムに入力するのか、といった観点の確認や、記載された手順だけで業務が過不足なく実施できることを確認します。

業務リハーサルの手順や実施スケジュールの作成は、業務実施部門の職員が行います。ただし、職員のみで実施が難しい日次処理や月次処理等のバッチ処理の実施タイミングの検討や、それらの処理に伴う実施スケジュールの調整、業務リハーサルの実施等については、情報システム構築事業者や工程管理事業者等に支援を依頼して進めます。

業務リハーサルの内容（作業の内容・流れをまとめたもの。シナリオと呼ばれることもある。）は、ＰＪＭＯ及び業務実施部門が中心となってレビューし、過不足が無く、現実的なものかをチェックします。例えば、業務リハーサルを実施する時期と業務の繁忙期との関係や、業務リハーサルを実施する業務実施部門における職員の異動の有無、休日に実施する場合の対象職員の確保等、様々な要素があります。

また、業務リハーサルの実施そのものも、職員が主体となって行うことが重要です。職員が業務リハーサルを実施することで、移行時に発生すると致命的となる問題を発見することができます。これにより､業務ピーク時にも所期の時間内で業務遂行が可能か､移行後の業務運用において考慮漏れがないか等の検証ができます。

事例：利用者への周知が不十分なプロジェクトの顛末

あるプロジェクトでは、業務効率改善のために、業務担当者が今までは情報システムに書類の内容を手入力していた作業を、今後はＯＣＲ（文字認識）ツールを用いて自動読み取りすることで業務担当者の手間を軽減する検討を進めていました。

この情報システムは、構築事業者により順調に改修が進み、機能面についても一部の業務担当者がテストや確認を実施し、問題がないことを確認できました。

しかし、現場を巻き込んだ全面的な業務リハーサルは行いませんでした。情報システム担当が業務担当者の代わりに簡単なリハーサルを行い、業務担当者にはアナウンスのみを行った上で業務の切り替えを実施しました。

その結果、リリース直後に業務担当者から、従来の業務の進め方との違いやＯＣＲ読み取り対象外となる書類の取り扱い等の問い合わせが殺到し、一時的に業務が滞る事態となりました。

その後、業務担当者に対して改めて業務の研修を行い、なんとか混乱を収束することができました。

C. サービスの開始や変更を利用者に確実に周知する

ある日突然、システムの利用方法や画面操作が変更されていると、利用者は戸惑ってしまいます。リリース直前に連絡しても、十分に周知が間に合わないこともあります。利用者に対しては、計画的にサービスの開始や変更内容を伝えるように留意してください。

Step.3 業務の定着と次の備え

新しい情報システムがリリースされると、サービス・業務の運営が始まります。新しいサービス・業務が今までのものと違いがあればあるほど、リリース直後からしばらくの間は様々な問題が発生するかもしれません。業務に関わる職員は、できるだけ早く業務を現場に定着させようと悪戦苦闘しますが、それ以外にも、より良いサービス・業務となるような活動を併せて行う必要があります。

１職員に継続的な教育を行う

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

ＰＪＭＯは、情報システムの設計・開発のリリースが近づいたところで、それまで準備した研修教育資料を用いて、実業務を担当する職員に対して教育を実施します。

それではどのような点に注意して進めて行けばよいか、見て行きましょう。

A. 研修・教育の準備を十分に行う

ＰＪＭＯは、研修資料として、ＰＪＭＯ主導で作成した業務マニュアルや、事業者主導で作成した情報システムの操作マニュアル、それらをまとめた研修用資料等を準備します。

また、可能であれば、デモ環境や研修環境なども用意し、情報システムを実際に触ることができる環境を提供することも効果的です。

府省内の広範囲の職員が利用する情報システムにおいては、ＰＪＭＯやヘルプデスクを担当する事業者も、研修・教育の準備期間中に、一般職員と同じ研修を受講しておくことが望まれます。これにより、研修カリキュラムの改善につながることはもちろん、利用者からの問い合わせに的確に対応できるようになります。

情報システム構築の作業進捗状が遅延すると、研修や教育の回数制限、期間の短縮や、現場担当者が新しい情報システムに触れられる環境の準備が遅れる可能性が出てきます。ＰＪＭＯは研修や教育に最低限必要な期間は必ず確保できるように、構築事業者の進捗管理をチェックし、安易な計画変更を起こさないようにしてください。

B. 研修・教育は１回では定着しない

通常、新しい情報システムのリリース前に行う教育は、開発実施計画を立てる時点でしっかり盛り込まれていれば、作業が抜け漏れることなく実施できます。

ただし、この研修や教育は、どのぐらいの頻度で実施すればよいのでしょうか？計画を立てる際に気にしておくべき注意点を以下に挙げます。

現場への研修・教育を計画する際の注意点

大規模システムの場合、全国各地に業務担当者が散らばっていることが多く、実施回数が少ないとそのタイミングで教育を受けられない担当者が発生する可能性が出てくる。

研修・教育の回数が制限されていると、情報システムリリース後、新しく人事異動で配属された職員が、正しい情報を把握することができなくなる。

教育資料や教育の内容が不十分な場合、そのまま同じように全職員に情報が伝達されても、全体のレベルが上がらない。

この懸念点を払拭するには、次の対策をとることが効果的です。

懸念点への対策

研修を実施した後、受講者にアンケートを配布し、研修の内容・難易度に関する意見をもらい、それを基に研修のカリキュラムや資料の内容を見直す。

・研修に用いた教材を関係者が閲覧できるようにする、電子ファイルをダウンロードできるようにするなど、研修に出られない人にも研修の内容が伝わるように工夫する。

・研修そのものを撮影し、オンラインにてストリーミング配信できるようにする、ＤＶＤに焼いて配布する等の対策を検討する。

図8-6　研修・教育の定着化に向けた取り組み

２定着には利用者への働きかけが必要

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

新しいサービス・業務は、利用者に使ってもらい初めて価値が生じます。

ただし、適切な説明がなされないと、利用者は新しいサービス・業務に気が付かずに、従来どおりの振る舞いをしてしまい、せっかく構築した情報システムも宝の持ち腐れになりかねません。

したがって、ＰＪＭＯは、利用者には新しいサービス・業務の提供を始めたことを周知するプロモーション活動及び新しいサービスを使いたいという気持ちになってもらうために、利用者のモチベーションを向上させる活動を行う必要があります。

次にあげる事例は、利用者のモチベーション向上を行ったプロジェクトの例です。

事例：プロモーション実施・モチベーション向上策の例

【プロモーションの未実施が招いたサービスの利用率低下】

ある省では、新しいサービスを国民向けに提供できるように情報システムの整備を進めましたが、サービスの周知はリリース直前のプレス発表のみであったため、利用者がサービスの存在を認識するに至らず、利用率が伸び悩んでいました。

そのため、プロモーションの実施を検討することになったものの、当初に予算措置をしていなかったため、すぐには効果的な対策を打つことができず、サービスの利用率が向上するまでに時間がかかってしまいました。

【報奨金・補助金を活用した利用者拡大の成功例】

一方で、ある省で提供する電子サービスでは、電子申請を実現するにあたり、電子申請を利用するために利用者がICカードリーダーを購入する必要があったため、そのための費用を賄えるように、利用者に金銭的なメリットが発生するように制度自体を再設計しました。

さらに、キャッシュレスサービスの推進において利用者へのポイント還元などの施策を展開した事例もあります。

このように、新サービスの利用率を高めるために利用者のメリットを積極的に訴求する施策も効果的です。

利用者への伝達方法としては、利用者向けWebサイトでのアナウンスや、窓口に来た利用者に対して窓口職員が新しいサービス・業務のメリットを説明する等があります。いずれの場合も、利用者にとって、どんな価値向上があるのかを正しく説明することが大切です。併せて、業務担当者に対しても自分達にどのようなメリットがあるのか、理解してもらうことも重要です。

また、中長期視点では本質的に価値が向上するとしても、新しいやり方への抵抗から移行してもらえないこともあります。そういったときは、事務効率化に見合った利用料の低減や入力支援機能の充実等により直接的な利用者への利益提供を行うことで利用率を向上させ、定着を推進しましょう。

利用者のモチベーションを向上させるための工夫例

・窓口より申請時間や申請期間を長くする（土日や夜間等）。

・手書きでの申請よりも記入（入力）項目を減らす。（例えば、郵便番号から住所の一部を自動入力できる機能を付ける等。）

・前年の申請データを再利用できるようにして、入力の手間を減らす。

・キャッシュレス決済に必要な機器の導入費用を国および決済事業者で負担することで店舗の費用負担を無くした。

３業務で扱うデータの品質を確保する

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

データマネジメントとは、データをサービスや業務の効率化、高度化のために活用できる状態で維持し、継続的に改善していく組織的活動を指します。

(注記:「行政におけるデータマネジメント実践に関する調査研究」報告書および「行政機関向けデータマネジメント導入ハンドブック」 https://www.iais.or.jp/reports/labreport/20171201/datamanagement2017/ )

データマネジメントの不足は、様々な問題を引き起こす可能性があります。

ここでは、そういった問題の発生例をいくつか見て行きましょう。

A. 計画どおりにデータを入れないと情報システムの価値はない

事例：データの信頼性が低いためにシステムが信用されない例

ある省で、過去の契約実績をデータベース化し、今後の調達を検討する上での基礎情報とするための情報システム整備を実施することになりました。

情報システムの構築は問題なく進み、予定どおり現場にリリースされ運用が開始されました。

ある程度運用後、データを点検したところ、基礎情報として取るべき項目が任意入力項目となっており、異なる部署のデータが並列で比較できないことがわかり、目的としていた省内で共通利用可能な契約実績データとはなっていなことがわかりました。

また、項目は決まっていたものの、職員によって入力するデータの精度が不明確で、同じ意味ではあるものの、同列に扱えないデータがデータベースに蓄積されていました。

そのため、情報システムが保持すべきデータ項目やデータの構造について、再度見直しのための改修を行うことになりました。

上記のような事例を引き起こす原因は、情報システムの機能的な問題だけではなく、情報システムの中身であるデータの品質にも問題がある場合があります。データ品質が悪く、利用者の目的に沿った分析や活用ができないと、利用者からのシステム離れが発生します。

この状態を改善していくためには、情報システムを構築したからといって、自ずと活用目的に足る品質の高いデータが入ってくる訳ではない事実を認識し、目的に沿ったデータ品質を維持していく持続的な活動と組織的に利活用を定着化させていくための推進キャンペーンの企画・実行や説明会・ユーザーサポートなどの継続的な活動に取り組むことが必要となります。

B. 分析しやすいデータ構造でないと、何かするにもカネがかかる

事例：データを出力するだけなのに時間とカネがかかる例

ある省で、業務で利用している情報システムに蓄積されたデータを基に、業務分析を実施することになりました。

データを取り出す機能が無かったため、保守事業者にデータの出力を依頼したところ、想定を超える費用と作業期間を提示されました。

見積りの根拠を確認したところ、もともとやりたいと考えている業務分析ができるようなデータの構造をしておらず、それを達成するには様々なデータの変換を含むプログラムの開発が必要との回答を受けました。

上記のような事例を引き起こす原因は、データとアプリケーションが適切に分離されていないという情報システムの構造的な問題であると同時に、データの状態遷移や静的・動的データの取り扱いなどを適切に定義できていないという、“データ”アーキテクチャの問題に起因していることが少なくありません。

既存の大規模システムにおけるアーキテクチャの抜本的な見直しなどはそう簡単には解決できない重いテーマですが、システム更改等のタイミングで、データの構造と振る舞いに着目し、見直しを図ることが解決策の第一歩となります。

４業務改善に向け日常業務の事実を蓄積する

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

業務の改善は、業務を運営しながら継続的に実施する必要がありますが、事実を正しく把握した上で問題点を抽出し、解決案を考えた上で適用を行わないと、効果的な改善につながりません。

運用当初は問題が無くても、時間の経過とともに利用者のニーズの変化に業務・システムが対応できなくなったり、当初想定していた業務量の予測が大幅に上回ったり（又は下回ったり）する等の事象が発生します。

これらをしっかり把握し、効果的な改善を行う上で注意すべき点をみて行きましょう。

A. ＰＪＭＯ・職員が様々な情報を収集し、定常的に管理する

業務を運用している間、ＰＪＭＯには日々様々な情報が集まってきます。この情報には、利用者からの問い合わせや要望、運用・保守事業者から報告される突発的に発生した障害、定常的な監視活動から取得した情報（インシデント記録含む）があります。

これらの情報からは、情報システムが安定稼働しているかどうかを判断することになりますが、少し視点を変えて、情報システムの改善余地を探す手掛かりとしても見てみましょう。

例えば、利用者のサービス利用状況等から、利用者の動向を把握し、窓口への訪問やＷｅｂサイトの利用時間帯に対する人数の偏りを把握することで、サービス改善のきっかけをつかむこともできます。

また、大きなプロジェクトでは、専用のコールセンターや問い合わせ窓口から、小さなプロジェクトでは、ＰＪＭＯに直接行われる問い合わせ等からも、利用者の動向やニーズを把握することもできます。

これらは、事業者がまとめた２次資料だけでなく、ＰＪＭＯがそれぞれの内容を具体的に把握し、理解することも重要です。特別なアンケートを改めて取らなくても、既に集まっている情報の分析や追加調査で、サービス・業務にどういった問題・ニーズがあるのかを把握することができます。

図8-9　ＰＪＭＯに集まる情報の把握・理解

把握した結果に応じて、様々な対応策を考えてみましょう。全てが業務の変更や情報システムの改修で対応するのが最善とは限りません。例えば、問い合わせが多いものは、ＦＡＱやマニュアルの改訂等で対応できるかもしれませんし、毎年発生する恒常的な業務イベントについては、過去の事例を参考にして事前に関係者にアナウンスすることで改善するかもしれません。

B.情報システムのログ等、運用活動に関わる情報を取得可能にする

前出のとおり、業務運営中の情報把握は重要ですが、どうやって情報を集めるのが良いでしょうか？

業務運営中に発生する業務・情報システムに関連する情報は数多くあるため、これらを活用しやすくするためには、可能な限り自動的に情報を取得できる仕組みを作っておきましょう。

対象とする情報源の一つは、情報システムのログやトランザクションデータです。これらのデータから、情報システム利用者の特性やアクセス頻度、滞留時間や入力エラーの発生状況等を把握・分析し、サービス改善に向けた検討材料として、ユーザの動向やニーズが、データの積み上げ・根拠に基づいて導き出すことができます。

(注記:ログとは、情報システムを利用する際に自動的に作成される動作の記録データであり、トランザクションデータとは、情報システムで日々蓄積される業務に係るデータ（○○申請データ、××決裁結果、等）。)

図8-10　ログ等から特性等を把握

また、データが自動的に取得できない場合でも、様々な活動の記録はデータとして保存し、後で調査・分析ができるよう復元可能にしておくことも有効です。

そのような場合の具体的な事例として、以下をご紹介します。

事例：詳細な調査・分析により運用業務の無駄を削減

ある省で、運用中の情報システムについて、運用作業の一つである設定変更作業が依頼から実施されるまで時間がかかることが課題として取り上げられました。

原因を特定するため、一連の作業フローを可視化しました。

その結果、依頼を受けた担当者が、依頼に基づいた設定書を作成した後、チームリーダーによるレビューを受け、最終的に会議体において再度レビューされ、承認されるまでの作業の流れが確認できました。レビューには、チェックリストを用いていることも把握できました。

より詳細な分析を行うため、次の２点の観点で調査を勧めました。

１．作業時間や作業着手までの滞留時間を詳細化する。

２．レビュー内容（チェックリスト）の内容を確認する。

１．では、関係者へのヒアリングだけではなく、作業の申請・承認をやり取りしていたメールの送受信履歴を取り寄せ、分析を行いました。

２．では、チェックリストを取り寄せ、項目レベルで内容の把握を行いました。

その結果、一連の作業の流れで一番時間がかかっているところは、会議体での承認待ち時間であること、チームリーダーが使うチェックリストと会議体が使うチェックリストの項目が30%程度同じものであること、がわかりました。

これらの分析結果を基に、チェックリストの項目が重複しないように見直し、会議体の開催頻度を週２日からチームリーダーチェック後の翌日に実施できるようにしました。

これにより、設定作業に要する時間を大幅に短縮することが達成できました。

C. 効果測定ができるように、ＫＰＩを自動的に取れるようにしておく

前で述べたとおり、分析には様々な情報を収集する必要があります。情報システム構築後に必要なデータを手作業で集める労力を減らすためには、どういった情報を日頃蓄積しておくべきかを、サービス・業務企画から要件定義の間に検討し、情報システムの運用上必要な機能として盛り込んでおく必要もあります。まだ、それらの機能がない現行の情報システムに対しても、同じ観点で情報が取得できないかは、現行の情報システム事業者に、運用保守の一つとしてデータを取得できないか、相談してみてください。

また、集めるべき情報は、プロジェクト計画時に検討したＫＧＩやＫＰＩを意識すると特定できるものもあります。ＫＰＩを把握するために必要な情報は、１つとは限りません。そのことを踏まえて、収集すべき値を設定しましょう。自動化ができると、モニタリングも容易に行うことができます。

サービス・業務企画や要件定義の段階で、どのような値が必要となるかを限定することは困難です。実践ガイドブック「第９章Step.2-2-A.参考9-1」等に記載された指標例を基に、取得できそうな値、取得したら意味がありそうな値は取得対象とし、あとで容易に取り出せるように機能化を検討してください。これは、検討範囲外の値を後から取得しようとすると、最悪の場合、改修などの追加コストが発生するおそれがあるためです。

なお、行政評価等では、評価指標を表す言葉として『アウトカム』や『アウトプット』があります。これらとＫＧＩ／ＫＰＩとの関係は以下のとおりです。

アウトカム/アウトプットとＫＧＩ／ＫＰＩの関係

・ＫＧＩ　＝　アウトカム

・ＫＰＩ　＝　アウトプット

したがって、サービス・業務の目標・目的（ＫＧＩ・アウトカム）の達成状況は、実際に数値として捉えることができるＫＰＩ・アウトプットを測定して、判断することになります。

D. 多数のインシデントや要望等の対応の優先度を付ける

業務に関する問い合わせやインシデント、要望等を取りまとめていくと、膨大な量になり、全てを対応するのは時間もコストも足りません。そのため、それぞれを整理した上で、優先度をつけて、優先度の高いものから対応していく必要があります。(注記:インシデントとは、正常なサービス提供を阻害する事象を指す。代表的なものにセキュリティインシデントがあるが、利用者の経験不足から発生した操作ミスなどもインシデントに含まれる。)

優先度は、業務遂行上で重要かどうかを判断してつけてください。例えば、画面を複数切替えないと関連する情報が確認できず件数が多くて作業が非効率ということであれば、情報システムの改善による業務の効率化を検討すべきかもしれませんが、単純に画面レイアウトや操作性等についての要望は、個人の好みに依存することが多く、改善効果は見込めません。また、利用者側が業務を遂行できない、又は多大な事務作業が発生する不具合に対応できないような場合は、そもそも情報システムの利用を推奨するべきではなく、業務の見直しも含めた検討が必要になります。

インシデントの優先順については、過去のインシデント分析にて、起こっている問題を詳細に分析することで、クリティカルな部分を優先して対策することが効果的です。インシデント分析としては、一部をサンプリングして全体を理解するのではなく、全数を調査・分析して全体を捉えることが重要です。サンプリングして行う調査・分析は、コストをかけず実行することができますが、サンプリングから漏れる少数の事実が全体に影響を与える場合があるからです。

優先度をつけた結果、対応できないと判断する要望については、ＰＪＭＯ側の都合ではなく、当該業務のステークホルダー（国民、利用者側、法令の主旨等）の立場で納得がいくような、代替案や不採用となった理由を説明できるようにしてください。また、不採用とした要望については、今後の対応予定があるのか、基本的に対応予定がないかといったステータスを明確にしましょう。

事例：アンケートだけで情報システムの改修要件を定めて無駄な改修となるおそれがあった例

ある省で、複数の組織で利用される情報システムについて、要望に基づき改修の検討に着手しました。要望はアンケート形式で集計したものであり、金額計算に関わる同じ機能に対しての改修要望が多く、改修対象としました。

事例8-8　アンケートだけで情報システムの改修要件を定めて無駄な改修となるおそれがあった例

改修された機能をリリースしたところ、複数の組織から問題点を指摘されました。詳細を聞くと、組織ごとに金額計算時の端数処理のルールが異なり、同じロジックでは対応できないことがわかりました。

ＰＪＭＯは、当初それぞれの組織に対応すべく、機能改修を検討しようとしましたが、一旦作業をストップし、対処案を検討することにしました。

その結果、組織ごとにばらばらなローカルルールを無くすよう、制度改正を行うこととし、情報システムへの改修は行わずに対処を終えることができました。

Step.4 業務の改善

業務の改善を進める中で、日常的な改善と、情報システムや業務そのものを見直す場合とがあります。ここでは、日常業務で改善できるポイントを説明します。

１日常業務中でも改善できることを理解する

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

第８章の活動では、サービス・業務を運営していく中で発生する様々な情報を集め、改善に向けた取り組みに繋げていくことを紹介しました。

その結果、情報システムの見直しが必要なものは、第４章「サービス・業務の企画」に立ち戻り、運用保守の見直しが必要なものは第９章「運用及び保守」に立ち戻ります。

改善として、これに該当しないものは、日常的な改善として対応していく必要があります。それらは具体的には次のようなものに該当します。

日常的に実施する改善事項の例

・業務の見直しは、情報システムに影響を与えない範囲であれば、日常的に実施可能なものです。特に、定期的な改善を検討し、その結果は業務手順書などに反映させましょう。

・教育・訓練の見直しは、具体的には教育資料の改訂やカリキュラムの改訂に相当します。現状の分析結果を踏まえて、より職員に遡及できるような教育内容に作り替えを行ってください。

・モニタリングの見直しは、日常的に把握すべき指標とその仕組みの見直しに相当します。前出のとおり、ＫＰＩで取るべき指標値は、業務の状況に応じて変更してもかまいませんので、それに応じて値の取得方法や内容を見直し、現状を正確に把握できるようにしましょう。

・そのほか、利用者からの問い合わせが多い機能や操作等については、マニュアルの改善やＦＡＱに情報を追加・更新することで改善が図れますので、適宜改善を検討してください。

事例：インシデントの分析結果を利用者へ公開して、利便性を向上

あるプロジェクトでは、多くの職員が利用する内部事務向けの情報システムを運用していました。

数年間にわたってこの情報システムを運用する中では、利用者から様々な問い合わせを受けたり、システムの不具合や誤操作等による多種多様なインシデントが発生したりします。それぞれの問い合わせやインシデントについては一次的な対応は完了しているのですが、人事異動等で利用者が変わると、また同じ問い合わせが発生することもありました。

そこで、今までに蓄積した問い合わせを再分析してみました。すると、この内部事務は特定の時期に特定の業務処理を行うという定期的なイベントが多いこともあり、問い合わせの発生傾向に季節特性が見えました。

このことを受けて、１～２か月に１回程度の頻度で、利用者向けにメールマガジンを発行することとしました。そして、そのメールマガジンの中で、その時期に実施する業務処理や、過去に多く発生したインシデントを紹介しました。また、メールマガジンの内容や体裁についても、どのようにしたら多くの利用者に参照してもらえるかを第一義に考え、アクセシビリティ等の観点から随時改善を行っていきました。

さらに、インシデントを分析した結果を、利用者向けに公開することとしました。それまでも、よくある質問についてはＦＡＱとしてWebサイトで公開していたのですが、ここにインシデントとして分析した内容についても掲載することとしたのです。従前のＦＡＱの掲載件数は1,000件程度でしたが、段階的にインシデントの掲載を増やしていき、１年後には約7,000件にまで掲載件数が増えました。また、FAQのWeｂサイト自体についても、多量の情報から目的の情報を探しやすくするため、検索の利便性の向上等の工夫を行いました。このような取り組みの結果、ＦＡＱのＷｅｂサイトへのアクセス数も大幅に増加し、１年後には３倍以上のアクセスが集まるようになりました。

このように、インシデントの内容に基づいてメールマガジンの発行やＦＡＱ掲載を進めていくことによって、利用者の利便性を向上させると同時に、ヘルプデスクへの問い合わせ件数も減少する傾向となりました。

このプロジェクトでは、今でも継続的にインシデントの分析と公開を続けています。

２検討の進め方を理解する

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

利用者視点でサービス・業務を企画するためには、既存のサービス・業務や初期の構想で検討した内容にとらわれず、フラットな視点で事実を把握することから始めることが重要です。この進め方に関して、サービスデザイン思考に則った考え方に「ダブルダイヤモンド」があります。この考え方をサービス・業務企画の活動を当てはめると図8-12のようになります。

図8-12　ダブルダイヤモンド

サービス・業務企画の活動に当てはめると、「把握」→「分析」→「企画内容の検討」の作業を順番に実施して終わりではなく、「把握」→「分析」→「企画内容の検討」を1つのサイクルとして繰り返しながら、徐々にサービス・業務の内容を固めていくことになります。

始めは幅広い視点で事実情報を収集し、集まった情報から全体を俯瞰して優先順位を決めながら、さらに詳細な事実を収集して企画内容を詳細化していくという進め方をすることで、事実に基づいた、利用者に寄り添ったサービス・業務を企画することができます。

第７章　設計・開発

第９章　運用及び保守

第８章 サービス・業務の運営と改善