電子政府サービスにおける開発手法のあり方（２）：今後の注目は「レンタルモデル」　の続きです。今回は、開発手法の一つである「プロトタイプモデル」を活用した場合の、電子政府サービスの作り方を整理してみたいと思います。

まだまだ発展途上の電子政府・電子申請サービスでは、

・良かれと思って付けた機能が利用してもらえない
・法令通りの杓子定規なシステムで、実務（紙申請）で不可欠な機能やサービスが欠けている
・使い勝手は悪くないけど、事前準備やパソコン等の設定が大変

といったことが起こります。

プロトタイプモデルを上手に活用することで、こうした問題を事前に（運用前の開発段階で）解決することができます。

海外においては、多くの電子政府プロジェクトでプロトタイプモデルが採用されています。

その全てが十分な効果を挙げているわけではありませんが、使いやすさ・アクセスしやすさ等の改善だけでなく、無駄な投資の抑制などの効果もあり、「ウォーターフォール型」の開発と比べてリスク分散の効果が高いと言えるでしょう。

NTTデータ社のDIGITAL GOVERNMENTに掲載されている「米国における電子政府利用促進(2)－代表的な取り組み事例－」を基に、プロトタイプモデルによる電子政府サービスの作り方を整理しておきましょう。

（１）利用者（個人、団体、コミュニティ等）に対するヒアリング調査

ヒアリング調査により、

・提供して欲しい機能
・従来の申請手続で煩雑だと感じる部分や問題点
・便利でよく利用する既存の民間サービス

などを明らかにしていきます。

「開発」というよりは、その事前段階にあたる「企画・マーケティング」と言えます。誰に対してヒアリングするかは特に重要で、漠然と「個人」や「企業」を対象にしたヒアリングだけでは、良いサービスは実現できません。

ヒアリングの対象としたグループは、試作品の利用や広報・普及活動等においても重要な役割を担いますので、単なる「利用者」と考えず、大切なパートナーと認識しましょう。

（２）試作したシステム（プロトタイプ）の提供

ヒアリング調査を踏まえて、プロトタイプを作り、実際に使ってもらいます。「小テスト」みたいなものですね。具体的には、

・実際に見て、触れて、体験してもらう
・利用者（国民、行政）から意見を聴く
・利用者を観察する（行動パターンやエラー原因の分析）

といった作業になります。

プロトタイプの完成度や提供回数は、予算やスケジュールに応じて調整することになりますが、お金がない場合は、せめて時間だけでも使って、利用者の意向をじっくり見極めるようにしましょう。

利用者については、国民だけでなく、現場で事務処理を担う行政職員等の関係者も含まれます。

関連＞＞ペーパー・プロトタイピング：実装前のユーザ・データ収集｜UCD＝利用者中心設計のプロセスとは？

（３）プロトタイプ利用者の意見等を踏まえた改善

改善は、技術的な問題だけでなく、心理的な面でも難しい作業となります。

その例として、利用者を限定してしまうことによる失敗があります。

例えば、行政手続の仲介者である士業に利用してもらった場合、手続について詳しい知識があることはもちろんですが、士業の中でも特にITリテラシーの高い人たちが参加するケースが多くなります。

その結果、多少の使いにくさや説明の難しさがあっても、あまり苦労せずに使いこなしてしまう可能性があります。

これでは、課題や問題点が見落とされてしまい、改善へと結びつきません。

一般利用者の視点を忘れないためにも、タイプの違う利用者グループを複数を用意したり、同じグループの中でも、あまりパソコン操作に慣れていない人たちを参加させたりするようにしましょう。

（４）２へ戻り、３の改善を繰り返す

改善したプロトタイプを利用してもらい、更なる改善を目指します。

基本的には、サービスが実利用に耐え得るレベルに達するまで行うようにしますが、予算や時間が限られているという現実もあります。

そこで必要になるのが、サービス運用の開始基準（評価基準）を事前に定めておくことです。例えば、

・利用者の満足度
・利用者が事前設定に要した時間
・利用者がタスク（申請等）完了までに要した時間
・行政が受付から結果通知までに要した時間
・エラーの発生率（国民側、行政側）

などについて、具体的な目標値を決めておきます。

（５）試験運用（パイロットテスト）の実施

サービス運用の開始基準を満たしたプロトタイプについて、パイロットテストを実施します。この段階で、「開発」から「運用」へ移行すると考えて良いでしょう。

パイロットテストは、対象者や地域等を限定しますが、それ以外は本番と同じ形で行います。

日本の電子政府施策で行われる「実証実験」に近いですが、日本の場合は、プロトタイプによる改善を経ていなかったり、「実証実験すること、したこと」が重視されるケースがあるように思います。

パイロットテストは、実際にサービスの運用を開始するかどうかを決める、まさに「最終試験」となりますので、いわゆる「見切り発車」は厳禁です。

ここで良い結果を得られなければ、「プロジェクトの中止」もあり得るので、パイロットテストに至るまでには、考えられる問題が全て解決されていることが条件と理解しましょう。

（６）パイロットテストの利用状況を踏まえた決定

パイロットテストの利用状況を踏まえて、今後の展開を決定します。

決定内容の例としては、

・利用状況が好調で評判も良い：本格稼動へ
・利用状況が予想を下回る：原因を調査し、改善が可能であれば、改善を経てから再びパイロットテストへ
・改善が困難、状況が変化してニーズがなくなった等：中止へ

以上が、「プロトタイプモデルによる電子政府サービスの作り方」です。

当たり前のことですが、開発手法としてプロトタイプモデルを採用したから良い電子政府・電子申請サービスが実現するわけではありません。

・事前のマーケティング調査
・利用者の絞込み（見極め）
・利用者意見の分析
・明確で適切な評価基準の設定

といった条件が揃って、初めてプロトタイプモデルの効果が期待できるのですね。

次回（最終回）は、ちょっと難しいですが、「今後どのような開発手法を選べば（使い分ければ）良いのか」について考えてみたいと思います。