USDS Digital Service Playbook in JP
•
0 likes•345 views
USDS Digital Service Playbook in Japanese
Recommended
More Related Content
What's hot
Similar to USDS Digital Service Playbook in JP
Similar to USDS Digital Service Playbook in JP (9)
More from Hiroki Yoshida
More from Hiroki Yoshida (12)
USDS Digital Service Playbook in JP
- 1. USDS デジタルサービスプレイブック ー⽇本語訳版ー Translated by Hiroki Yoshida https://playbook.cio.gov CC0 1.0 全世界 (CC0 1.0) パブリック・ドメイン提供
- 3. • アメリカ国⺠は、ウェブサイト、電⼦メール、モバイルアプリケーションなど のデジタルチャネルを通じて政府とやりとりすることを期待している。 • 国⺠のニーズを満たすデジタルサービスを構築することで、政策やプロ グラムをより効果的に提供することができる。 • 現在、デジタルサービスプロジェクトの多くは、うまく機能しなかったり、納 期が遅れたり、予算オーバーになったりしている。 • これらのプロジェクトの成功率を⾼めるために、⽶国政府は新しいアプ ローチを必要としている。 • 我々は、⺠間部⾨と政府の成功事例から抽出した13の重要な「プレ イ」をまとめたプレイブックを作成した。
- 4. デジタルサービスプレイ 1. ⼈々が必要としているものを理解する 2. 最初から最後まで体験全体に対応する 3. シンプルで直感的なサービスにする 4. アジャイルかつ反復的⼿法でサービスを 構築する 5. 予算と契約を構造化しデリバリーを⽀援 する 6. ⼀⼈のリーダーを任命し、責任を任せる 7. 経験豊富なチームを招聘する 8. 現代の技術スタックを選択する 9. 柔軟なホスティング環境でのデプロイ 10.テストとデプロイを⾃動化する 11.再利⽤可能なプロセスでセキュリティと プライバシーを管理する 12.データを使って意思決定を⾏う 13.オープン化をデフォルトとする
- 5. プレイ1 ⼈々が必要としているものを理解する デジタルプロジェクトは、サービスを利⽤する⼈々のニーズを探り、ピンポイントで把握すること から始めなければならない。ユーザーが⼀般市⺠であろうと公務員であろうと、政策⽴案者 は最初から実際のユーザーを設計プロセスに巻き込まなければならない。政府の構造やサイ ロの制約なく、⼈々のニーズが技術や設計の決定に反映されなければならない。何が重要 なのかを正しく伝えるために、実際のユーザーと⼀緒に作った製品を継続的にテストする必要 がある。 チェックリスト o プロジェクトの初期段階で、サービスの現在のユーザーや⾒込 みのあるユーザーと⼀緒に時間を使う o ⼈々の⽬標、ニーズ、⾏動を特定するために、さまざまな定 性・定量的な調査⽅法を使⽤し、賢く時間を使う o 可能であれば、現場で実際のユーザーと⼀緒にソリューションの プロトタイプをテストする o ユーザーの⽬標、ニーズ、⾏動、嗜好に関する発⾒を⽂書化 する o 発⾒したことをチームや⾏政機関のリーダーと共有する o 「ユーザーストーリー」と⾔われるような、ユーザーが達成しようと しているタスクの優先順位付きリストを作成する o デジタルサービスを構築する際には、潜在的なユーザーと定期 的にテストを⾏い、⼈々のニーズを満たしているかどうかを確認 する 重要な質問 l 主な利⽤者は誰か l このサービスはどのようなユーザーのニーズに対応するのか l ユーザーはなぜこのサービスを必要としているのか l どのような⼈がこのサービスを利⽤する際最も困難になるのか l どのような調査⽅法を利⽤したか l 重要な調査結果は何か l 調査結果はどのように⽂書化されたか、将来のチームメンバー はどこでその⽂書にアクセスできるか l 実際の⼈が関与したテストはどのくらいの頻度で⾏っているか
- 6. プレイ2 最初から最後まで体験全体に対応する オンライン、モバイルアプリケーション、電話、対⾯など、ユーザーがどのように サービスを利⽤するかを理解する必要がある。オンライン、オフラインを問わず、 すべてのタッチポイントは、ユーザーをゴールに近づけるものでなければならない。 チェックリスト p オンラインと対⾯の両⽅で、⼈々がサービスを利⽤する さまざまなタッチポイントを理解する p ユーザーがサービスを利⽤する上での現在の⽅法での ペインポイントを特定し、ユーザーのニーズに応じて優先 順位をつける p ⼈々がサービスを利⽤する際に使⽤するオフラインのタッ チポイントと統合されるように、デジタルサービスをデザイ ンする p サービスの各段階で、サービスがどれだけユーザーのニー ズを満たしているかを測定するための指標を開発する 重要な質問 l デジタルサービスが⽀援しようと設計され、現在⼈々が 実施している業務にはどのような異なる⼿法（オンラ インとオフラインの両⽅）があるか l ⼈々がタスクを達成する現在の⽅法の中で、ユーザー のペインポイントはどこにあるのか l ⼿がけている特定のプロジェクトが、現在⼈々に提供 されているサービス全体のどこに当てはまるのか l サービスがユーザーのためにどれだけうまく機能している かを⽰すには、どのような指標が最適か
- 7. プレイ3 シンプルで直感的なサービスにする 政府のサービスを使⽤することは、ストレスや混乱、困難を伴うものであっては ならない。ユーザーが最初に何の助けがなくても利⽤できるように、⼗分シン プルで直感的なサービスを構築するのが我々の仕事である。 チェックリスト p シンプルで柔軟性のあるデザインスタイルガイドをサービ スに使⽤する、⽶国ウェブデザイン標準をデフォルトと する p 関連するデジタルサービスのデザインスタイルガイドを⼀ 貫して使⽤する p プロセスの各段階でどこを⾏なっているのか、ユーザー に明確な情報を提供する p アクセシビリティのベストプラクティスに従って、すべての ⼈がサービスを利⽤できるようにする p プロセスを完了させるために、ユーザーに離脱⽅法と後 から戻れる⽅法を提供する p ユーザーに親しみやすく、理解しやすい⾔葉を使う p オンラインとオフラインのタッチポイントを含め、サービス 全体を通して⼀貫した⾔葉とデザインを使⽤する 重要な質問 l ユーザーはどのような主要なタスクを達成しようとしてい るのか l ⾔葉は可能な限り平易で誰にでもわかりやすいか l サービスはどのような⾔語で提供されているか l ユーザーがサービス利⽤中に助けを必要とする場合、 どのようにして助けを得ることができるか l サービスのデザインは、どのように他の政府サービスと視 覚的に関連づけられているか
- 8. プレイ4 アジャイルかつ反復的⼿法でサービスを構築する 我々は、失敗のリスクを減らすために、継続的で速いペースのソフトウェア開発のスタイルを使 ⽤するべきである。設計・開発チームにサービスに関するユーザーからのフィードバックに基づい て調整するチャンスを与えるために、できるだけ早くソフトウェアをユーザーの⼿に渡すようにし たいと考えている。重要なのは、新機能を頻繁に追加、容易に開発できるようにサービスを、 ⾃動的にテストしてデプロイできるようにすることである。 チェックリスト p コアユーザーのニーズを解決する機能を持つ「実現可能な最低限の製品」 （MVP）を、プロジェクト開始から3ヶ⽉以内に、必要に応じて「ベータ」ま たは「テスト」期間を設け、できるだけ早くリリースする p ユーザビリティ・テストを頻繁に実施し、サービスがどの程度機能しているか を確認し、改善すべき点を特定する p サービスを構築しているメンバーがローンチ会議、ウォールーム、デイリースタ ンドアップ、チームチャットツールなどの技術を利⽤して密にコミュニケーション を取るようにする p デリバリーチームの規模を⼩さくして集中させる、ビジネスオーナーからこれら のチーム切り離し、組織階層を少なくする p 機能や改善を毎⽉複数回リリースする p 機能バックログや、バグバックログとして知られる機能とバグの優先順位リス トを作成する p ソースコードのバージョン管理システムを利⽤する p プロジェクトチーム全体にイシュー追跡とバージョン管理システムへのアクセ ス権を与える p コードレビューを通じて品質を確保する 重要な質問 l MVPのリリースにはどのくらいかかったか、まだリリースされていない場合、い つリリースされるか l 本番環境へのデプロイにはどのくらいの時間がかかるか l 各イテレーション/スプリントには何⽇、何週間かかるか l どのバージョン管理システムを使⽤しているか l バグはどのように追跡され、チケットは発⾏されるか、どのようなツールを使 ⽤しているか l 機能バックログはどのように管理されているか、どのようなツールを使⽤して いるか l 機能とバグのバックログをどのくらいの頻度で⾒直し、優先順位をつけ直し ているか l 開発中にユーザーからのフィードバックをどのように収集しているか、その フィードバックはどのようにしてサービスを改善するために使⽤されているか l ユーザビリティテストの各段階で、ユーザーのニーズに対応する上でどのよ うなギャップが特定されたか
- 9. プレイ5 予算と契約を構造化しデリバリーを⽀援する 開発業務を外部に委託する際に成功率を⾼めるためには、経験豊富な予算編成・契約担当者と協⼒する必要があ る。サードパーティを利⽤しサービスを構築する場合には、よく練られた契約を締結することで、調査やプロトタイピング フェーズの実施、サービスの構築に合わせた要件定義の精緻化、オープンソースの選択肢の評価、頻繁な納品のマイ ルストーンの確保、クラウドコンピューティングのリソースの柔軟な購⼊の確保など、優れた開発⼿法を取ることができる。 TechFARハンドブックでは、このプレイの実施に役⽴つ連邦調達規則（FAR）の柔軟性について詳しく説明している。 チェックリスト p 予算には調査、発⾒、プロトタイピングの活動が含まれている p 契約は複数⽉のマイルストーンではなく、頻繁に成果物を要求する構造に なっている p 契約はベンダーが成果物に責任を持つように構成されている p 契約はプロジェクトの進展に合わせて機能の優先順位と納期を調整する ための⼗分な柔軟性を政府のデリバリーチームに提供している p 契約は技術選択の際にオープンソースソフトウェアも評価対象となることを 保証している p 契約は第三者が⽣成したソフトウェアやデータは、⾏政側の管理下にあり、 法律に基づいて適切に再利⽤し、公開できることを明記している p 契約はベンダーからのツール、サービス、ホスティングを、固定料⾦や「使い たい分だけ⽀払う」サービスのような可変モデルなど、さまざまな価格設定モ デルで利⽤することができることを認めている p 契約は⼀般の⼈が発⾒したサービスの⽋陥をベンダーが政府に追加費⽤ なしで対処する保証期間を規定している p 契約にはサービス移⾏期間と移⾏完了計画が含まれている 重要な質問 l プロジェクトのスコープは何か、主要な成果物は何か l マイルストーンは何か、頻度はどのくらいか l 契約で定義されているパフォーマンス指標は何か (例︓応答時間、システム稼働時間、優先課題に対応する期間)
- 10. プレイ6 ⼀⼈のリーダーを任命し、責任を任せる タスクやビジネスモデル、製品内容、技術決定といった作業要素を割り当て、サービス全体の 成否について説明責任を負う権限と責任を持つ単⼀のプロダクトオーナーがいなければならな い。このプロダクトオーナーは、サービスがユーザーのニーズをどれだけ満たしているか、つまりサー ビスがどのように評価されるべきかに最終的な責任を負うことになる。プロダクトオーナーは、機 能を確実に構築し、機能とバグのバックログを管理する責任がある。 チェックリスト p プロダクトオーナーが特定されている p プロダクトオーナーがタスクを割り当て、機能や技術実 装の詳細を決定する権限を持っていることにすべての利 害関係者が同意している p プロダクトオーナーは、技術的な経験を伴うプロダクトマ ネジメントのバックグラウンドを持ち、代替案を評価し、 トレードオフを考慮できる p プロダクトオーナーは、予算⾒積を含む作業計画を持 ち、予算を特定する p プロダクトオーナーは契約担当者と強い関係性を持って いる 重要な質問 l プロダクトオーナーは誰か l プロダクトオーナーがプロジェクトに対して⼗分な権限を 持ち、⽀援を得るためにどのような組織変更がなされ たか l プロダクトオーナーがサービスから機能を追加したり削 除するには何が必要か
- 11. プレイ7 経験豊富なチームを招聘する 我々は現代のデジタルサービスを作った経験を持つ、政府機関で働く優秀な⼈材を必要として いる。これには、経験豊富なプロダクトマネージャー、エンジニア、デザイナーも含まれる。外部か らの⽀援が必要な場合は、サードパーティーの技術能⼒を評価する⽅法を理解している契約 担当者と協⼒して効果的なデジタルサービスの構築と提供の両⽅に⻑けた請負業者を⾒つけ、 チームを組む必要がある。チームの構成やメンバーの経験の⽔準は、プロジェクトのスコープに よって異なる。 チェックリスト p チームメンバーは⼈気の⾼い、トラフィックの多いデジタルサービスを構築した経験をもっている。 p チームのメンバーは、モバイルおよびWebアプリケーションの設計経験がある。 p チームのメンバーは、⾃動化されたテストフレームワークを使⽤した経験がある。 p チームのメンバーは、継続的インテグレーション(CI)や継続的デプロイメント(CD)のような最新のデブオプス （DevOps）技術の経験を持っている。 p チームのメンバーは、デジタルサービスを保守した経験がある。 p 開発作業に第三者を使⽤する場合は、内部チームに連邦契約担当者がいる p 連邦予算担当者は、内部チームに所属しているか、パートナーである p 部署または機関にとって適切なプライバシー、市⺠権、および／もしくは法律のアドバイザーがパートナーである
- 12. プレイ8 現代の技術スタックを選択する 技術選択は、開発チームが効率的に作業できるようにし、サービスを容易かつ費⽤対効果の⾼い形で拡 張できるようにする必要がある。ホスティングインフラ、データベース、ソフトウェアフレームワーク、プログラミン グ⾔語、およびその他テクノロジースタックの選択は、ベンダーロックインを避け、優れた現代のユーザーおよ びエンタープライズソフトウェア企業が選択するものと⼀致するようにする必要がある。特に、優れたユー ザーやエンタープライズテック企業によって⺠間ではオープンソース、クラウドベース、コモディティソリューション が⽀持され、幅広く活⽤されているため、デジタルサービスチームはこれらをテクノロジースタック全体で使⽤ することを検討すべきである。 チェックリスト p 似たようなサービスを作っている⺠間企業で⼀般的に 使われているソフトウェアフレームワークを選ぶ p 可能な限りソフトウェアを様々な種類のコモディティハー ドウェアで展開できるようにする p 各プロジェクトに、ローカル開発環境を設定するための 明確でわかりやすい指⽰書があることを確認し、チーム メンバーをプロジェクトから迅速に追加または退出できる ようにする p オープンソースのソフトウェアソリューションをスタックの各 レイヤーで検討する 重要な質問 l 我々の開発スタックは何で、それをなぜ選んだのか l どのデータベースを使⽤しており、なぜそれらを選んだの か l 新チームメンバーが開発を開始するにはどのくらいの時 間がかかるか
- 13. プレイ9 柔軟なホスティング環境でのデプロイ 我々のサービスは、トラフィックやユーザーの需要の急増に合わせてリソースをリアルタイムで提供 されるような、柔軟性の⾼いインフラ上に展開されるべきである。「クラウドホスティング」を謳いな がら、直接ハードウェアの管理と保守を⾏う必要があるデータセンターでホストしている場合には、 我々のデジタルサービスは不⾃由を伴う。このような時代遅れの慣⾏は、時間を浪費し、災害 復旧計画に弱く、結果としてコストを⼤幅に増加させる。 チェックリスト p リソースはオンデマンドで提供される p リアルタイムのユーザーの需要に基づいてリソースを拡張する p リソースはAPIを介して提供される p リソースは複数の地域で利⽤可能である p 我々が使った分のリソースにしかお⾦を⽀払わない p 静的な情報資産は、コンテンツ配信ネットワークを通じて提供さ れる p アプリケーションはコモディティハードウェアでホストされている 重要な質問 l サービスはどこにホストされているか l サービスの実⾏にはどのようなハードウェアを使⽤しているか l サービスの需要や利⽤パターンはどうなっているか l トラフィックや負荷が急増した場合、サービスに何が起こるか l ホスティング環境で利⽤できる容量はどのくらいか l アプリケーションサーバーのような新しいリソースの提供にはどのく らいの時間がかかるか l どのように需要に応じてサービスを拡張できるように設計されて いるか l ホスティングインフラの料⾦はどのように⽀払っているか（例︓ 分単位、時間単位、⽇単位、⽉単位、固定） l サービスは複数の地域、可⽤性ゾーン、またはデータセンター でホストされているか l データセンターに⼤規模な災害が発⽣した場合、サービスが稼 働するまでにどのくらいの時間がかかるか
- 14. プレイ10 テストとデプロイの⾃動化 今⽇の開発者は、数千ものシナリオを数分で検証できるよう⾃動化されたスクリプトを書き、更 新されたコードを⼀⽇に何度も本番環境にデプロイしている。また、トラフィックの急増を予測し てパフォーマンスのボトルネックを特定する⾃動パフォーマンステストを使⽤している。⼿動テスト と品質保証はまだ必要だが、⾃動テストは意図しないリグレッションに対する⼀貫性した信頼 性のある保護を提供し、開発者が⾃信を持ってサービスの頻繁なアップデートをリリースすること を可能にする。 チェックリスト p すべてのユーザーが接する機能を検証する⾃動テストを作成している p モジュールやコンポーネントを検証するためユニットテストや統合テストを作 成している p 開発プロセスの⼀部としてテストを⾃動的に実⾏している p デプロイスクリプト、継続的なデリバリーのサービス、または同様の技術を使 ⽤して、⾃動的にデプロイを実⾏している p ⼀般公開前を含め、定期的に負荷テストと性能テストを実施している 重要な質問 l コードベースの何パーセントが⾃動テストでカバーされているか l 典型的なバグ修正のビルド、テスト、デプロイにはどのくらいの時間がかか るか l 新しい機能のビルド、テスト、および本番環境へのデプロイにはどのくらい 時間がかかるか l ビルド作業はどのくらいの頻度で実施されるか l どのようなテストツールを使⽤しているか l どのようなデプロイ⾃動化ツールや継続統合ツールを使⽤しているか l システムの使⽤を希望する同時使⽤ユーザーの最⼤数はどれくらいにな ると予想されるか l 最新の容量テストによると、システムは何⼈の同時ユーザーを処理できる か l 予想された⽬標使⽤量を超えた場合、サービスはどのように動作するか、 緩やかに劣化するのか、それとも壊滅的に劣化するのか l 需要が急激に増加した場合のスケーリング戦略は何か
- 15. プレイ11 再利⽤可能なプロセスによるセキュリティとプライバ シーの管理 我々のデジタルサービスは、機密情報を保護し、システムを安全に保つ必要がある。これは通常、継続的な⾒直しと 改善のプロセスであり、サービスの開発と保守に組み込まれるべきである。新しいサービスや機能を設計する際には、 チームのリーダーは適切なプライバシー、セキュリティ、法務担当者を関与させ、収集されるデータの種類や、それらがど のように保護されるべきか、どのくらいの期間保管されるべきか、そしてどのように使⽤され共有されるべきかを議論する 必要がある。プライバシーの専⾨家が継続的に関与することで、個⼈データが適切に管理されていることを確認するこ とができる。さらに、安全なサービスを構築するための重要なプロセスは、セキュリティ上の脆弱性がないか技術スタックの 各層のコンポーネントを総合的にテスト、確認し、事前確認済みの同じコンポーネントを、複数のサービスで再利⽤す ることである。 チェックリスト p 部⾨または⾏政機関全体の適切なプライバシーまたは法務担当者と相 談し、記録システムからの通知（SORN）、プライバシー影響評価、また はその他のレビューを実施すべきかどうかを決定する p 記録担当者と相談し、どのようなデータが収集され、なぜ収集されるのか、 どのように使⽤または共有されるのか、どのように保存され、保護されるのか、 どのくらいの期間保存されるのかを決定する p プライバシーの専⾨家と相談し、個⼈情報の収集・利⽤⽅法について、プ ライバシーポリシーが必要かどうか、どこに表⽰すべきか、セキュリティ侵害が 発⽣した場合に利⽤者にどのように通知するかなどを決定する p ユーザーが⾃分の情報にアクセスしたり、サービスから削除したりすることが できるかどうかを検討する p “FedRAMP”を利⽤して、プロジェクトで使⽤するホスティングインフラストラ クチャを「事前認証」する p デプロイスクリプトを使⽤し、本番環境の構成が⼀貫性を保ち、制御可能 であることを確認する 重要な質問 l サービスはユーザーから個⼈情報を収集しているか、利⽤者にはどのよう に通知されるか l 必要以上の情報を収集していないか、⼀般的なユーザーが想定してい ない⽅法でデータが使⽤される可能性はあるか l 利⽤者はどのようにして個⼈情報にアクセスし、訂正、削除するのか l システムに保存された個⼈情報は、他のサービス、⼈々、またはパート ナーと共有されるか l サービスはどのように、どのくらいの頻度でセキュリティ脆弱性がないかテス トされているか l ⼀般の⼈はどのようにしてセキュリティの問題を報告することができるか
- 16. プレイ12 データを使って意思決定を⾏う プロジェクトのすべての段階で、サービスがユーザーのためにどれだけうまく機能しているかを測定しなければ ならない。これには、システムがどれだけうまく機能しているか、⼈々がリアルタイムでシステムとどのようにやり 取りしているかの測定も含まれる。チームと⾏政機関のリーダーは、これらの測定指標を注意深く観察して 問題を⾒つけ、バグ修正や改善にどのように優先順位をつけるべきかを特定する必要がある。モニタリング ツールに加えて、問題を直接報告できるようなフィードバックの仕組みを⽤意する必要がある。 チェックリスト p システムレベルのリソース利⽤率をリアルタイムでモニターする p システムのパフォーマンスをリアルタイムでモニターする（応答時間、レイテンシー、 スループット、エラー率など） p モニタリングで中央値、95パーセンタイル、98パーセンタイルのパフォーマンスを測 定できることを確認する p モニタリングに基づいた⾃動アラートを作成する p 同時使⽤ユーザーをリアルタイムで追跡し、ユーザーの⾏動を総合的にモニターし て、サービスがユーザーのニーズをどの程度満たしているかを判断する p 指標を内部で公開する p 指標を外部に公開する p 実運⽤で多変量検定を⽀援する検証ツールを使⽤する 重要な質問 l サービスの主要指標は何か l これら指標は、サービスのライフサイクルにわたってどのようなパフォーマンスだったか l どのシステムモニターツールを導⼊しているか l サービスの⽬標とする平均応答時間はどれくらいか、1 秒以上、2 秒以上、4 秒 以上、8 秒以上かかるリクエストの割合はどれくらいのパーセンテージか l 上位 10 トランザクションの平均応答時間とパーセンタイルの内訳 (1 秒、2 秒、 4 秒、8 秒以上かかるリクエストの割合) はどうなっているか l 各サービスの上位 10 トランザクションのボリュームはどれくらいか、開始されたトラ ンザクションと完了したトランザクションの割合はどれくらいか l サービスの⽉間稼働率⽬標はどれくらいか l サービスの⽉間稼働率（定期メンテナンスを含む）はどのくらいか、定期メンテナ ンスを除くとどれくらいか l インシデントが発⽣した場合、チームはどのようにして⾃動アラートを受けているか l インシデントにはどのように対応しているか、システムダウン後のプロセスはどのように なっているか l ユーザーの⾏動を測定するために、どのようなツールが導⼊されているか l A/Bテストにはどのようなツールや技術を使⽤しているか l 顧客満⾜度はどのように測定しているか
- 17. プレイ13 オープン化をデフォルトとする 我々はオープンな環境下で協⼒し、データを公開することで、⾏政をともに改善して⾏くことが できる。サービスをよりオープンな形で構築し、オープンデータを公開することで、政府のサービス や情報への⼀般市⺠のアクセスを容易にし、⼀般市⺠が簡単に貢献できるようにし、起業家 や⾮営利団体、他の機関、⼀般市⺠によるそれらの再利⽤を可能にする。 チェックリスト p ユーザーがバグや問題を報告する仕組みを提供し、これらの報告に対応で きるようにする p ⼀括ダウンロードやAPI（アプリケーション・プログラミング・インターフェース） を利⽤して、データセットを完全な形で⼀般に提供する。 p サービスからのデータがパブリックドメインであることを明⽰し、「クリエイティブ・ コモンズ・ゼロ」のような国際的なパブリックドメインの放棄を通じ、グローバ ルに権利が放棄されていることを確認する p ⾏政機関のデータ保存環境内のデータをカタログ化し、どんな公開データ セットも公開データセットリストに追加する p 第三者が開発したすべてのデータの権利について、⼀般の⼈が無償で再 利⽤可能な⽅法で維持することを確認する p 第三者が開発したすべてのカスタムソフトウェアの契約上の権利について、 公開可能、無償で再利⽤可能な形で維持することを確認する p 必要に応じて、サードパーティや内部ユーザーがサービスと直接やりとりでき るようにAPIを作成する p 必要に応じて、プロジェクトやコンポーネントのソースコードをオンラインで公 開する p 必要に応じて、開発プロセスと進捗状況を公開する 重要な質問 l バグや問題に対するユーザーからのフィードバックをどのように収集しているか l APIがある場合、それはどのような機能を提供しているか、誰がそれを使⽤ しているか、どのように⽂書化されているか l コードベースがオープンソースライセンスなのにリリースされていない場合は、 その理由を説明すること l どのようなコンポーネントが利⽤可能な形でオープンソースとして公開されて いるか l どのようなデータセットが利⽤可能な形で公開されているか