Digital Services Playbook

アメリカの人々は、ウェブサイト、電子メール、モバイルアプリケーションなどのデジタルチャネルを通じて政府と対話することを期待しています。 彼らのニーズを満たすデジタルサービスを構築することにより、私たちはポリシーとプログラムの提供をより効果的にすることができます。

今日、私たちのデジタルサービスプロジェクトの多くはうまく機能していないか、納期が遅れているか、予算を超えています。 これらのプロジェクトの成功率を高めるために、米国政府は新しいアプローチを必要としています。 私たちは、民間部門と政府の成功事例から引き出された 13 の主要な「シナリオ」のプレイブックを作成しました。これらを一緒に実行すると、政府が効果的なデジタルサービスを構築するのに役立ちます。

PLAY 1

人々が何を求めているかを理解します

English

私たちは、デジタルプロジェクトを始める際に、サービスを利用する人々のニーズと、提供するサービスが彼らの生活にどのように適合するかを調査し、特定する必要があります。 ユーザーが公共の人か公務員かに関係なく、政策立案者は最初から設計プロセスに実在の人物を含める必要があります。人々のニーズは、政府の構造やサイロの制約にとらわれることなく、技術および設計を決定するための情報として提供される必要があります。 重要なことについて正直さを保つために、実際の人々と一緒にサービスを継続的にテストする必要があります。

チェックリスト

  1. プロジェクトの早い段階で、現在、または将来、サービスの利用者となる人々と一緒に時を過ごします。
  2. さまざまな定性的および定量的調査方法を使用して、人々の目標、ニーズ、および行動を決定します。 そして、この調査の過程についてよく考えます。
  3. 可能であれば、現場で実際の人とソリューションのプロトタイプをテストします。
  4. ユーザーの目標、ニーズ、行動、好みに関する調査結果を文書化します。
  5. 調査結果をチームおよび組織と共有する。
  6. ユーザーが実行しようとしているタスクの優先リストを作成します。これは、「ユーザーストーリー」とも呼ばれます。
  7. デジタルサービスが構築されている間に、定期的に潜在的なユーザーとテストして、人々のニーズを満たしていることを検証します。

キークエスチョン

PLAY 2

サービスの開始から最後までのすべての事に対処します

English

オンライン、モバイルアプリケーション、電話、または直接のアクションなど、人々がサービスを操作するさまざまな方法を理解する必要があります。 オンラインであろうとオフラインであろうと、すべてのサービスとの接点でユーザーを目標に近づける必要があります。

チェックリスト

  1. オンラインと対面の両方で人々がサービスと対話するさまざまなポイントを理解します。
  2. ユーザーがサービスを利用する中での問題点を特定し、ユーザーのニーズに応じて優先順位を決めます。
  3. 人々がオフラインで使う機能は、部分的なツール機能として設計し、サービスに統合します。
  4. サービスの各ステップでユーザーのニーズをどの程度満たしているかを計測、測定する指標を開発します。

キークエスチョン

PLAY 3

サービスをシンプルで直感的にします

English

政府のサービスを利用する上で、ストレスを感じたり、混乱させたり、気が遠くなるようではいけません。ユーザーが初回利用からサポートがなくても使えるように、シンプルで直感的なサービスを構築することが私たちの仕事です。

チェックリスト

  1. サービスではシンプルで柔軟なデザインスタイルガイドを使用します。 デフォルトのガイド:U.S. Web Design System
  2. 関連するデジタルサービスでは、一貫したデザインスタイルガイドを使用します。
  3. ユーザーが手続きのどのステップにいるか明確にわかる情報を提供します。
  4. すべての人がサービスを使用できるようにアクセシビリティのベストプラクティスに従います。
  5. ユーザーが手続きを終了する方法や、作業の途中でも後から完了できる方法を提供します。
  6. ユーザーが理解しやすい言葉を使用します。
  7. オンラインとオフラインの接点を含め、サービス全体で一貫した言語とデザインを使用します。

キークエスチョン

PLAY 4

アジャイルと反復的な手法でサービスを構築します

English

失敗のリスクを減らすためには、漸進的でペースの速いスタイルでソフトウェア開発が必要です。 設計および開発チームがサービスに関するユーザーのフィードバックに応じて対応できるように、動くソフトウェアをできるだけ早く、ユーザーに渡したいと考えています。 重要な機能は自動でテストをしてデプロイできるようにすることで、新しい機能を頻繁に本番環境へ導入することができます。

チェックリスト

  1. プロジェクトの開始から 3 か月以内に、コアユーザーのニーズをできるだけ早く解決する機能する「最小実行可能製品」(MVP)をリリースします。必要に応じて「ベータ」または「テスト」期間を設けます。
  2. ユーザビリティテストを頻繁に実行し、サービスがどの程度うまく機能しているかを確認し、改善点を特定します。
  3. サービスを構築するメンバーが、リリース会議、戦略室、毎日のスタンドアップ、チームチャットツールなどの手法を使用して緊密に通信できるようにします。
  4. サービス提供するチームを小さく保ち、目的に集中できるようにします。 また、組織構造によって、このチームを事業レイヤーから分離します。
  5. 毎月数回、追加機能と機能改善をリリースします。
  6. 「追加機能バックログ」と「バグバックログ」を用意し、各対応の優先リストを作成します。
  7. ソースコードのバージョン管理システムを使用します。
  8. プロジェクトチーム全員が課題管理システムとバージョン管理システムへアクセスできるようにます。
  9. 品質を担保するために、コードレビューを行います。

キークエスチョン

PLAY 5

予算と契約の内容を構造化します

English

開発作業を依頼する際に成功の確度を高めるためには、予算編成および契約に関する経験が豊富な担当者と協力する必要があります。 外部業者がサービスの構築をサポートする場合、明確に契約を定義することで、優れた開発プラクティスが促進されます。

例えば、調査およびプロトタイピングフェーズの実施、サービス構築時の製品要件の改善、オープンソースによる代替案の評価、リリースマイルストーンの頻繁的な確保や、クラウドコンピューティングリソースを購入する際の柔軟性といったポイントです。

TechFAR ハンドブック では、この手順の実施をサポートするために、連邦調達規則(FAR)での柔軟性について詳細に説明しています。

チェックリスト

  1. 予算には、調査、分析、およびプロトタイピングの活動が含まれます。
  2. 頻繁なリリースが実現するように契約内容は構成されています(数か月のマイルストーンといった大きな粒度ではありません)。
  3. 契約は、ベンダーが成果物のリリースに対して説明責任を負うように構成されています。
  4. 契約では、政府のチームが、プロジェクトの進展に応じて追加機能の優先順位付けとリリーススケジュールを柔軟に調整できるように明記されています。
  5. 契約では、技術選定時にオープンソースのソリューションが評価されることが保証されています。
  6. 契約では、外部業者によって生成されたソフトウェアとデータは、運営組織の管理下にあり、法律に従って適切に再利用および公開できることが規定されています。
  7. 契約では、ベンダーのツール、サービス、およびホスティングを使用する際に、固定料金制や従量課金制などの、さまざまな価格設定を使用することができます。
  8. 契約では、保証期間が設定されており、リリース後に一般の利用者によって発見された欠陥を追加費用なしでベンダーによって改修されます。
  9. 契約には、サービスへの移行と移行計画が含まれています。

キークエスチョン

PLAY 6

信頼できるリーダーを 1 人アサインし、詳細レベルの権限を委譲します

English

サービスには、プロダクトオーナー(PO)が 1 人必要です。PO はビジネス、プロダクト、および技術的な決定の権限と責務をアサインされます。

責務については、サービス全体の成功または失敗についての説明責任を負い、ユーザー視点でのサービス評価方法を決定する最終的責任者となります。

このため、サービスの機能が構築されているかを確認し、追加機能とバグのバックログの管理方法が適切かを確認する必要があります。

チェックリスト

  1. プロダクトオーナーがアサインされています。
  2. プロダクトオーナーにタスクの割り当て権限と、機能と技術的な実装の詳細に関する決定を下す権限を持つことに、すべてのステークホルダーが同意しています。
  3. プロダクトオーナーは、代替案を評価してトレードオフを検討するための、技術的な経験に基づいた製品管理のバックグラウンドを持ち合わせています。
  4. プロダクトオーナーにより、予算の見積もりを含む、プロジェクトの資金源を特定する作業計画が作成されています。
  5. プロダクトオーナーは、契約担当者と強固な関係を結んでいます。

キークエスチョン

PLAY 7

経験豊富なチームを採用します

English

政府のプロジェクトには、能力があり、モダンなデジタルサービスを構築した経験を持つ人材が必要です。この人材には、経験豊富なプロダクトマネージャー、エンジニア、デザイナーといった人たちが含まれます。

外部からのサポートが必要な場合は、外部業者の技術レベルを理解している契約担当者と協力して、効果的なデジタルサービスの構築とリリース経験のある請負業者をチームと協業できるようにします。

チームの構成と経験の要件については、プロジェクトのスコープによって異なります。

チェックリスト

  1. チームのメンバーは、一般的で、トラフィックの多いデジタルサービスを構築した経験があります。
  2. チームのメンバーは、モバイルおよび Web アプリケーションの設計経験があります。
  3. チームのメンバーは、自動テストフレームワークの使用経験があります。
  4. チームのメンバーは、継続的インテグレーションや継続的デリバリーなどの最新の開発および運用(DevOps)技術の経験があります。
  5. チームのメンバーは、デジタルサービスのセキュリティ対策をした経験があります。
  6. サードパーティが開発作業に使用される場合、連邦契約担当官が内部チームに所属します。
  7. 連邦予算担当官が内部チームに所属しているか、もしくはパートナーとして連携しています。
  8. プライバシー、市民的自由、および/または法律に関する顧問アドバイザーは、部門または機関のパートナーとして連携します。
PLAY 8

サービスには最新のテクノロジースタックを選択します

English

適切な技術選択により、開発チームの作業効率的を向上し、サービスをシンプルかつ費用対効果の高い方法で拡張できるようにする必要があります。

コンシューマーとエンタープライズソフトウェア企業が連携して、ベンダーロックインを回避できるように、インフラストラクチャ、データベース、ソフトウェアフレームワーク、プログラミング言語、および、その他のテクノロジースタックを利用する選択する必要があります。

特に、デジタルサービスチームは、テクノロジースタックを横断して、民間セクターで成功しているオープンソース、クラウドベース、および一般化されたソリューションの利用を検討する必要があります。

チェックリスト

  1. 提供するサービスと類似したサービスをを提供している企業で一般的に利用されるソフトウェアフレームワークを選択します。
  2. 可能であれば、ソフトウェアが様々な一般化されたハードウェアに展開できることを確認します。
  3. 各プロジェクトでは、ローカル開発環境をセットアップするための明確で理解しやすい手順があり、チームメンバーをプロジェクトにすばやく追加またはプロジェクトから除外できるようになっていることを確認します。
  4. スタックのすべてのレイヤーで オープンソースソフトウェアソリューションが利用可能かを検討します。

キークエスチョン

PLAY 9

サービスを柔軟なホスティング環境にデプロイします

English

サービスは、トラフィックとユーザーの需要の急増に対応するために、リソースをリアルタイムでプロビジョニングできる柔軟なインフラストラクチャに展開する必要があります。

市場で「クラウドホスティング」として売り出されているにもかかわらず、ハードウェアを直接管理および保守する必要があるデータセンターでホストしてしまうと、私たちのデジタルサービスは機能しなくなってしまいます。ハードウェアを直接管理するという時代遅れの慣行は、時間を浪費し、災害復旧計画を弱体化させ、結果として大幅に高いコストをもたらします。

チェックリスト

  1. リソースはオンデマンドでプロビジョニングされます
  2. リソースはリアルタイムのユーザー需要に基づいてスケーリングされます。
  3. リソースは API を介してプロビジョニングされます。
  4. リソースは複数のリージョンで利用可能です。
  5. 使用したリソースに対してのみ支払いが発生します。
  6. 静的なアセットはコンテンツ配信ネットワークを介して提供されます。
  7. アプリケーションは一般化されたハードウェアでホストされています。

キークエスチョン

PLAY 10

テストとデプロイを自動化します

English

開発者は、数千のシナリオを数分で検証し、更新されたコードを 1 日に複数回、本番環境にデプロイできる自動スクリプトを作成しています。 トラフィックの急増をシミュレートする自動パフォーマンステストを使用して、パフォーマンスのボトルネックを特定します。 手動テストと品質保証は依然として必要ですが、自動テストは意図しないリグレッションに対する一貫した信頼性の高い保護を提供し、開発者がサービスの頻繁な更新に自信を持ってリリースできるようにします。

チェックリスト

  1. すべてのユーザー向け機能を検証する自動テストを作成します。
  2. モジュールとコンポーネントを検証するためのユニットテストと統合テストを作成します。
  3. ビルドプロセスの一部としてテストを自動的に実行します。
  4. デプロイメントスクリプト、継続的デリバリーサービス、または同様の手法を使用して、デプロイメントを自動的に実行します。
  5. 一般公開前を含め、定期的に負荷テストとパフォーマンステストを実施します。

キークエスチョン

PLAY 11

再現可能なプロセスによってセキュリティとプライバシーを管理します

English

デジタルサービスは、機密情報を保護し、システムを安全に保つ必要があります。これは通常、継続的なレビューと改善のプロセスであり、サービスの開発と保守に組み込む必要があります。

新しいサービスまたは機能の設計を開始するとき、チームリーダーは、適切なプライバシー、セキュリティ、および法務担当者と協力して、収集される情報の種類、保護方法、保持期間、使用および共有方法について話し合う必要があります。プライバシースペシャリストの継続的な関与は、個人データが適切に管理されることを保証するのに役立ちます。

さらに、安全なサービスを構築するための重要なプロセスは、技術スタックの各層においてコンポーネントのセキュリティ脆弱性を包括的にテストおよび認証された、事前認証済みのコンポーネントを複数のサービスで再利用することです。

特定のサービスのニーズを満たすために、チームはプライバシースペシャリストおよびセキュリティエンジニアと緊密に協力する必要があります。次のチェックリストはその出発点となります。

チェックリスト

  1. 部門または機関の適切なプライバシーまたは法務担当者に連絡して、通知記録システム(SORN)、プライバシー影響評価、またはその他のレビューを実施する必要があるかどうかを判断します。
  2. 収集されるデータと収集する理由、データの使用方法または共有方法、データの保存方法と保護方法、および保持期間をデータ記録担当者と相談して決定します。
  3. プライバシーポリシーが必要かどうか、表示する場所を含め、個人情報の収集方法と使用方法についてユーザーに通知するかどうかを、プライバシースペシャリストと相談します。また、セキュリティ問題が発生した場合にユーザーへ通知する方法も相談します。
  4. ユーザーがサービスから自分の情報にアクセス、抹消、または削除可能にする必要があるかどうかを検討します。
  5. FedRAMP を使用して、プロジェクトに使用されるホスティングインフラストラクチャを「事前認証」します
  6. デプロイメントスクリプトを使用して、本番環境の構成の一貫性とコントロール性を維持します。

キークエスチョン

PLAY 12

データを使用して意思決定します

English

プロジェクトのすべての段階で、ユーザーに対してサービスがどの程度機能しているかを測定する必要があります。 これには、システムのパフォーマンスと、人々がリアルタイムでシステムとどのように相互作用しているかを測定することも含まれます。 私たちのチームと関係者は、これらの指標を注意深く監視して問題を見つけ、バグ修正と機能改善の優先順位を決定する必要があります。 監視ツールに加えて、人々が問題を直接報告するためのフィードバックメカニズムを導入する必要があります。

チェックリスト

  1. システムレベルのリソース使用率をリアルタイムで監視します。
  2. システムパフォーマンスをリアルタイムで監視します(応答時間、遅延、スループット、エラー率など)。
  3. 監視モニターで中央値、95 パーセンタイル、および 98 パーセンタイルのパフォーマンスを測定できることを確認します。
  4. 監視メトリクスの値に基づいて自動アラートを作成します。
  5. 複数のユーザーを同時にリアルタイムで追跡し、ユーザーの行動からサービスがユーザーのニーズをどの程度満たしているかを判断します。
  6. メトリクスを内部的に公開します。
  7. メトリクスを外部に公開します。
  8. 本番環境での複数の変数、数量でテスト可能な実験ツールを使用します。

キークエスチョン

PLAY 13

情報をオープンにすることを基本とします

English

私たちがオープンに協力し、データを公開するとき、私たちは一緒に政府を改善することができます。 サービスをよりオープンに構築し、オープンデータを公開することで、政府のサービスや情報への公共アクセスを簡素化し、一般の人々が簡単に貢献できるようにし、起業家、非営利団体、その他の機関、一般の人々が再利用できるようにします。

チェックリスト

  1. バグや問題を報告し、これらの報告に対応するメカニズムをユーザーに提供します。
  2. 一括ダウンロードと API を介して、データセット全体を一般に提供します。
  3. サービスからのデータが明示的にパブリックドメインにあること、および「クリエイティブコモンズゼロ」免除などの国際的なパブリックドメインの献身を通じて権利がグローバルに免除されることを確認します。
  4. 政府機関の企業データ目録にデータをカタログ化し、政府機関の公開データリストに公開データセットを追加します。
  5. 第三者が開発したすべてのデータに対する権利を、一般に無料でリリースおよび再利用できる方法で維持するようにします。
  6. サードパーティによって開発されたすべてのカスタムソフトウェアに対する契約上の権利を、無料で公開および再利用できる方法で維持するようにします。
  7. 必要に応じて、サードパーティおよび内部ユーザーがサービスと直接対話するためのバージョン管理された API を作成します。
  8. 必要に応じて、プロジェクトまたはコンポーネントのソースコードをオンラインで公開します。
  9. 必要に応じて、開発プロセスを共有し、公開して進捗状況を確認します。

キークエスチョン