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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

懸念点への対策

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

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

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

  • 図8-6

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

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

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

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

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

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

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

  • 事例8-5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 事例8-6

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

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

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

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

  • 事例8-7

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 図8-7

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

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

  • 注記

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

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

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

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

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

  • 図8-8

ログ等から特性等を把握

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

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

  • 事例8-8

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

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

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

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

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

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

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

  • ＫＧＩ　＝　アウトカム

  • ＫＰＩ　＝　アウトプット

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

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

  • 注記

インシデントとは、正常なサービス提供を阻害する事象を指す。代表的なものにセキュリティインシデントがあるが、利用者の経験不足から発生した操作ミスなどもインシデントに含まれる。

業務に関する問い合わせやインシデント、要望等を取りまとめていくと、膨大な量になり、全てを対応するのは時間もコストも足りません。そのため、それぞれを整理した上で、優先度をつけて、優先度の高いものから対応していく必要があります。

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

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

  • 図8-9

インシデント悉皆分析

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

  • 事例8-9

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