機関誌『行政＆情報システム』2015年6月号の特集記事「米国政府における電子行政サービスの提供―提供方法と多様な主体の関与―」において、政府が国民により良いサービスを提供するための原則についてまとめたデジタルプレイブックについてご紹介しました。
その際、紙幅の都合で各項目のチェックポイントについて記載できませんでしたので、当ページにてご紹介いたします。
米国政府は、電子行政サービスに関して、以下の原則に基づきサービスを提供すべきであると述べています。
※各項目の青色のリンクをクリックすると各原則を実施する際の詳細なチェックポイントがごらんいただけます。
(1)人々のニーズを理解する。
デジタルプロジェクトを開始するにあたっては、ユーザのニーズ、およびそのニーズを充足する方法を調査し明確にすることが最も重要であり、その際には当該サービスが民間企業の職員向けか行政職員向けかを問わず、ユーザをサービスの設計プロセスに参画させることが必要であるとしています。
(2)人々のサイトの利用実績を明確にする。
デジタルサービスの提供の際には、単純にデジタルサービスのみに着目するのではなく、窓口での対面でのやり取りも含む、サービスへの様々なアクセス手段についても注目すべきであるとしています。
(3)シンプルで直観的なデザイン、サイト構成にする。
連邦政府の提供するサービスがユーザにとって使いやすいものとなるよう(より具体的にはユーザが当該サービスを初めて利用する際に職員からの手助けがなくてもスムーズに利用できるよう)、シンプルかつ直感的なサービス提供の形に設計することが必要であるとしています。
(4)アジャイル型かつ反復的な流れでサービスを構築する。
ソフトウェアの開発にあたっては、失敗のリスクを減らすために漸進的かつ着実に行うことが重要であると同時に、当該サービスについてのユーザのフィードバックを迅速に活かせるような設計・開発が求められ、新たな機能を追加する際にはサービスを自動的に試験したうえでできるだけ早く組み込めるようなケイパビリティが必要であるとしています。
(5)サービス提供を支援する予算と契約を構造化する。
連邦政府は、サービス構築に当たってサードパーティを活用する場合には、綿密に内容を定義した契約を行うことが、調査とプロトタイプの作成の実施、成果物に関する要件の修正、オープンソースの選択肢の評価、サービス実施に関するマイルストンの変更可能性の保証、およびクラウドコンピューティングの購入に関する柔軟さの確保といった観点で重要になるとしています。
(6)1人のリーダを割り当て、常にそのリーダが説明責任を果たせる状態にしておく。
任務や作業要素の割り振り、および業務・成果物・技術に関する意思決定を行う1人のプロダクトオーナーを置き、当該人物がサービス全体の達成状況について説明ができることが望ましいとしています。
(7)経験を積んだ人材で構成されるチームを設置する。
連邦政府は、任期付きのプロダクトマネージャ・エンジニア・デザイナーの採用など、タイムリーなデジタルサービスを構築した経験を持つ人材との協働を必要としていますが、その方法については、サードパーティの技術面でのコンピテンシを熟知した契約担当官と協議の上で、これらサードパーティの主体との契約もあり得るとしています。
(8)最新の技術動向を取り入れる。
技術を選定し、導入を決定する際には、開発チームが効果的に作業を行え、サービスの規模を容易に捉えることができ、費用対効果が高いサービスとなるような決定をする必要があるとし、ベンダロックインを避け、民間企業や一般市民の選択とずれたものにならないよう留意すべきであると考えています。
(9)柔軟にホスティングできる環境を整備しておく。
連邦政府が提供するサービスは、リソースがトラフィックの増大、あるいはユーザの需要の変化に合わせてリアルタイムで提供されるような柔軟性に富んだインフラ上に配置されるべきとの考えを示しています。
(10)検証とデプロイメントを自動で行えるようにしておく。
人手を介したテストと、品質に関するアシュアランスは依然として必要である一方で、意図しない手戻りが起きないよう首尾一貫した信頼性の高い防御を行い、結果として開発者が安心してサービスのアップデートを行えるよう、自動化されたテストが必要であると主張しています。
(11)他でも利用可能なプロセスでセキュリティとプライバシーを管理する。
新たなサービスや機能の追加を検討する段階からプライバシー、セキュリティ、法律の専門職員と協力して、収集する情報の種類とセキュリティ確保方策について協議し決定する必要があると同時に、サービスの構築段階での継続的な検証とコンポーネントの認証を行い、認証を取得したものについては他のサービスでも再利用すべきとの方向性を示しています。
(12)プロジェクトに関する意思決定にデータを活用する。
連邦政府の提供するサービスがユーザにとって十分に機能しているかの測定が必要であるとの認識のもと、システムのパフォーマンスをリアルタイムで測定し、バグの修正や改善事項の優先順位付けを行う方向性を示しており、その際には、単にパフォーマンスの測定のみならず、市民に向けた報告、フィードバックの仕組みも合わせて整備することが必要であるとしています。
(13)デフォルトで公開する。
連邦政府は、自らの提供するサービスをよりオープンにし、データを公開することで市民が政府のサービスや情報へよりシンプルにアクセスできるようになるとともに、企業、非営利団体、他省庁、市民がデータをより一層再利用することが可能になると考えています。
◆人々のニーズを理解する。
・ プロジェクトの初期段階でサービスのユーザとのコミュニケーションを図る。
・ 人々が何を必要としているかについて、定性的、定量的調査を実施する。
・ 考えられるサービスの方策のプロトタイプについて実証実験を行う。
・ ユーザの目的、ニーズ、行動、選好について、実証実験から得られた知見を文書の形で記録する。
・ デジタルサービスチームおよび省庁のリーダが上記の知見を共有する。
・ ユーザが実現したいと考える課題 について、優先順位付けしたリストを作成する。
・ サービスの提供開始後も、当該サービスの潜在的なユーザを巻き込んだ形で定期的に検証を行う。
◆人々のサイトの利用実績を明確にする。
・ 人々が政府の提供するサービスを利用する際に使う様々なアクセスポイントを、オンラインかオフラインかにかかわらず理解しておく。
・ ユーザが現段階で利用している方法の問題点を明らかにするとともに、ユーザのニーズに即したものにするためにはどの問題点を優先的に解決するかを定める。
・ 人々が従来利用してきたオフラインのアクセスポイントとうまく組み合わさるように、サービスの電子的提供のあり方を設計する。
・ サービス提供の各段階において、サービスがユーザのニーズを十分に満たしているかを測定するための基準を確立する。
◆シンプルで直観的なデザイン、サイト構成にする。
・ シンプルで今後の修正にも柔軟に対応可能なサービスの設計指針を作成する(既存のものがある場合には流用可能)。
・ 関連するデジタルサービスと一貫したものとなるように設計指針を活用する。
・ ユーザに対して、今サービス利用手続のどの段階にいるのかを明確に示す。
・ アクセシビリティに関する官民のベストプラクティスを活用する。
・ サービスの利用手続を中断した場合でも、後に残りの部分の手続を再開できるような方法を確保する。
・ ユーザが理解しやすい用語を使用する。
・ オンライン、オフライン両方のアクセスポイントにおいて、サービス全体で一貫した流れとなるように設計するとともに、用語も一貫した意味合い、使用法となるように留意する。
◆アジャイル型かつ反復的な流れでサービスを構築する。
・ ユーザのニーズを満たすことができるような、実証に必要な最低限の機能を持つ成果物(MVP：minimum viable product)を、遅くともプロジェクト開始後3か月以内の早い時期に作成する。
・ サービスの動作状況と改善すべき事項を確認するために、ユーザビリティテストを頻繁に実施する。
・ サービス構築に関わっているメンバが十分に意見交換できるようなコミュニケーション手法 を活用する。
・ サービスの提供に携わるチームをできるだけ集約し、かつ小規模なものにしておき、業務の責任者と当該チームの間に何層も組織が置かれるような状況は避ける。
・ 新たな機能や改善点を毎月複数回出せるようにする。
・ 追加すべき機能や対処すべきバグについての優先順位付けしたリストを作成する。
・ ソースコードのバージョンコントロールを行う。
・ 課題解決とバージョンコントロールシステムへプロジェクトチーム全員がアクセスできるようにする。
・ 品質を保証するためにコードレビューを利用する。
◆サービス提供を支援する予算と契約を構造化する。
・ 調査研究やプロトタイプ作成にかかる費用も予算に見込んでおく。
・ 複数月にわたるマイルストンではなく、成果物を高頻度で出すよう要求することが可能な形の契約を結ぶ。
・ 政府のサービス実施チームが、プロジェクトの進捗に合わせて機能の優先順位付けや実施スケジュールを調整できるような柔軟性を持てるような契約にする。
・ 契約の中で技術選択を行う際にオープンソースのソリューションが評価されるように保障する。
・ サードパーティが作成したソフトウェアやデータが法律に従って適切な形で再利用、公表されるようにする。
・ ツールやサービス、ホスティングを様々な料金体系の中から選択して利用できるような契約にする。
・ 追加費用なしでベンダが脆弱性に対応する、保証期間を契約で定める。
・ 契約にサービス移行期間を含める。
◆1人のリーダを割り当て、常にそのリーダが説明責任を果たせる状態にしておく。
・ プロダクトオーナーを指定する。
・ プロダクトオーナーが任務の割り当てを行い、機能およびサービス実施に関する詳細について決定することに全てのステークホルダが同意する。
・ プロダクトオーナーが、選択肢を評価し、トレードオフ関係にあるものの重みづけを行うという技術面での経験を活かしてプロダクトマネジメントを行う。
・ プロダクトオーナーは予算の見積もりを含み、財源の調達先を定めるような作業計画を作成する。
・ プロダクトオーナーが契約担当官と密接な関係を保持する。
◆経験を積んだ人材で構成されるチームを設置する。
・ 一般に普及しており、トラフィックの多いデジタルサービスを構築した経験を有する。
・ モバイルあるいはウェブのアプリケーションを設計した経験を有する。
・ 自動化された検証フレームワークを使った経験がある。
・ 継続的インテグレーションや継続的デプロイメントといった最近の開発・運用技術を用いた経験を有する。
・ セキュリティが重要なデジタルサービスに関する経験を有する。
・ サードパーティが開発作業に携わる場合には、連邦政府の契約担当官が政府内部チームに参加する。
・ 政府の予算担当官が政府内部チームに加わるか、内部チームのパートナーとなる。
・ プライバシー、市民の自由、その他法律に関するアドバイザがパートナーとして加わる。
◆最新の技術動向を取り入れる。
・ 同種のサービスを構築する民間企業でも共通に用いるソフトウェアフレームワークを選択する。
・ 可能であれば様々なコモディティハードウェアタイプに合わせてソフトウェアが配置できるようにする。
・ 各プロジェクトに、ローカルでの開発環境構築を行う際の明快で容易に理解できる手引書を作成しておき、人事異動にも対応できるようにする。
・ あらゆるレイヤで、オープンソースソフトウェアのソリューションが活用できないかを検討する。
◆柔軟にホスティングできる環境を整備しておく。
・ リソースが需要に合わせて提供される。
・ リソースの規模はその時のユーザの需要に依拠する。
・ リソースはAPIを通じて提供される。
・ リソースは様々な領域で利用可能な状態にする。
・ リソースを利用した分だけ対価を支払う。
・ 静的なアセットはコンテンツデリバリネットワークを通じて提供する。
・ アプリケーションはコモディティハードウェア上で処理される。
◆検証とデプロイメントを自動で行えるようにしておく。
・ ユーザが利用する全ての機能が動作するよう確認するための自動化されたテスト環境を構築する。
・ モジュールとコンポーネントの動作を確認するためのユニットテスト環境および統合テスト環境を構築する。
・ 構築プロセスの一環としてテストを自動的に行う。
・ デプロイメントスクリプト、CDS(continuous delivery services)、その他同様の手法を用いて自動的にデプロイさせる。
・ 定期的に負荷テストおよび動作テストを実施する。
◆他でも利用可能なプロセスでセキュリティとプライバシーを管理する。
・ プライバシやその他の法律を担当する職員と連絡を取ったうえで、個人情報記録システムに関する告知（SORN：System of Records Notice）やプライバシインパクト評価（PIA：Privacy Impact Assessment）、その他のレビューを実施すべきかを決定する。
・ 記録管理を担当する職員と協議のうえ、収集するデータ、利用する理由、利用・蓄積・セキュリティ確保の方法および期間について定める。
・ プライバシに関する専門家と協議のうえ、個人情報の収集・利用方法についてユーザに告知するかどうか、およびその方法について決定する。
・ サービス利用によって得られたユーザの情報について、利用者がアクセスし、削除できるようにするかを検討する。
・ 当該プロジェクトに用いるインフラを、FedRAMP を使って事前認証する。
・ 成果物の環境設定が一貫しておりコントロール可能であることを保証するためにデプロイメントスクリプトを活用する。
◆プロジェクトに関する意思決定にデータを活用する。
・ システムレベルでのリソースの使用率をリアルタイムで監視する。
・ システムのパフォーマンス（レスポンスタイム・呼出時間・スループット・エラー率など）をリアルタイムで監視する。
・ モニタリングに基づき自動的なアラートを構築する。
・ 提供しているサービスがユーザのニーズを満たしているかを計測するために、同時間帯のユーザの動きをリアルタイムで追跡するとともに、ユーザの行動を集合として監視する。
・ 政府内部向けに基準を公表する。
・ 対外的に基準を公表する。
・ 成果物の多変量テストを支援するような実験ツールを用いる。
◆デフォルトで公開する。
・ バグや問題点についてユーザが報告できる仕組みをつくるとともに、それらの報告に対して責任を持って回答する。
・ バルクでのダウンロードやAPIでデータセットを一般向けに提供する。
・ 政府の提供するサービスから得られるデータはパブリックドメインに属するものであり、パブリックドメイン開放の国際的な仕組みに従って権利を放棄する。
・ 各省庁のデータ棚卸の際にデータカタログを作成するとともに、公表しているデータセットをリストに登録する。
・ 費用負担なしに公開、再利用可能となるような方法で、サードパーティが開発したソフトウェアに関する契約上の権利を維持することを保証する。
・ 適切と認められる場合には、提供しているサービスに関して直接やり取りできるようサードパーティ及び政府内部のユーザ向けにAPIを構築する。
・ 適切と認められる場合には、プロジェクトのソースコードとコンポーネントを公表する。
・ 適切と認められる場合には、開発プロセスと進捗状況を公開、共有する。
