2026年10月8日にGOV.UK Service ManualのDiscovery、Alpha、ユーザー調査計画、同意手順を再確認した。Discoveryは利用者の仕事、制約、政策・業務の文脈、代替を調べて進む価値を判断する段階で、Alphaは公開品質を作る段階ではなく、最も危険な仮説を試作して検証する段階である。MVPや試作品は機能数ではなく学ぶ問い、対象、品質、アクセシビリティ、データ・同意、停止条件で定義する。
30秒で要点
プロダクト開発は、仕様を書いて機能を積み上げる一本道ではありません。問題を調べ、仮説を小さく試し、利用者が安全に使える形へ近づけ、提供後の証拠で続けるか変えるかを判断するループです。
- Discovery: 利用者、問題、制約、達成すべき結果を調べる
- Alpha: リスクの高い仮説を試作し、捨てられる形で検証する
- Beta・提供: 運用、品質、サポート、アクセシビリティを含めて広げる
- 学習: 利用、失敗、問い合わせ、継続を見て次の判断を変える
1. 問題と利用者を先に理解する
GOV.UK Service ManualのDiscoveryは、作り始める前に利用者が何を達成したいか、現在の手段と障害、政策・技術・法令の制約を調べる段階です。Discoveryでいきなり本番コードを作らず、進む価値があるか、別の方法で解けるかを判断します。
表が収まらない場合は、横にスクロールできます
| 調べること | 例 | 証拠 |
|---|---|---|
| 利用者 | 初回設定をする担当者、支援者、管理者 | 観察、インタビュー、利用ログ |
| 仕事 | 何を達成したいか、どこで止まるか | 現行フロー、問い合わせ、失敗記録 |
| 制約 | 法令、契約、既存システム、予算 | 規程、API仕様、運用担当の確認 |
| 結果 | 完了、時間、品質、安心、安全 | 指標の定義と観測期間 |
一人の要望を全利用者の代表値にせず、利用頻度、支援の有無、アクセシビリティ、業務上の責任を含めて対象を分けます。
2. 仮説を分解する
「この機能を作れば使われる」は検証できる形になっていません。次のように、対象、行動、結果、条件へ分けます。
対象の利用者が、条件Aで、行動Bを行い、結果Cが、期間Dで変わる。
表が収まらない場合は、横にスクロールできます
| 仮説の欄 | 記入例 | 先に決めること |
|---|---|---|
| 対象 | 新規顧客の管理者 | 誰を含め、誰を含めないか |
| 行動 | 初回設定を完了する | 完了イベントと分母 |
| 結果 | 問い合わせを減らす | 主要指標と副指標 |
| 条件 | 既存データが整っている | 前提、除外条件、リスク |
| 反証 | 完了率が変わらない | 続ける・変える・止める基準 |
仮説は製品の価値を証明する宣言ではなく、次の調査で確かめる一時的な説明です。反証となる観測も先に書くと、都合の良い成功だけを拾うのを防げます。
3. Alphaでは最も危険な仮説を試す
GOV.UKのAlphaは、Discoveryで見つけた問題に対して複数の解決策を試し、最も危険な仮説をプロトタイプで検証する段階です。複雑な本番品質コードを最初から作るのではなく、捨てられる試作で学びます。
表が収まらない場合は、横にスクロールできます
| リスク | 試すこと | 成功・停止の条件 |
|---|---|---|
| 使われない | 代表利用者の課題シナリオ | 課題が実際に起きるか、対象を変更するか |
| 解けない | 主要タスクの試作 | 代替手段より改善するか |
| 作れない | API、データ、法令の接続 | 解除策があるか、範囲を縮小するか |
| 運用できない | 問い合わせ・権限・監視 | 支援手順と責任者が定義できるか |
試作の成功は、見栄えや完成度ではなく、重要な仮説を判定できる情報が得られたことです。失敗した試作を捨てる判断も、開発資産と同じように記録します。
4. MVPは「最小の学習可能な体験」
MVPを機能の少ない製品とだけ定義すると、検証に必要な品質やサポートを落とします。対象利用者が安全に目的を達成でき、結果を観測できる最小の体験にします。
- 対象: 最初に支援する利用者と、利用しない利用者
- 体験: 目的達成に必要な手順とエラー時の案内
- 品質: 可用性、性能、アクセシビリティ、データ保護
- 運用: 問い合わせ窓口、監視、ロールバック、停止条件
- 学習: 主要指標、観察方法、見直し日、次の分岐
「小さいから安全」とは限りません。課金、個人情報、医療・金融、外部への不可逆な作用を含む場合は、範囲が小さくてもレビューと段階的な公開が必要です。
5. 検証の方法を問いに合わせる
GOV.UKの調査ガイドは、各開発段階で研究の目的と問いを更新し、方法を問いに合わせることを求めています。
表が収まらない場合は、横にスクロールできます
| 知りたいこと | 方法の例 | 誤読しないこと |
|---|---|---|
| 困りごとの状況 | 観察、インタビュー、ログ | 発言と実行動を同じにしない |
| 使い方 | タスクテスト、プロトタイプ | 試作の理解を本番利用と呼ばない |
| 効果 | 比較、段階導入、前後測定 | 季節性・選択バイアスを確認する |
| 品質・運用 | エラー、問い合わせ、監視 | 平均だけで安全を判断しない |
| 継続 | 再利用、解約、コスト、支援 | 短期の反応と長期価値を分ける |
研究参加者の同意、収集するデータ、利用目的、撤回方法を説明し、観察結果と解釈を分けて保存します。
6. 提供後に学びを戻す
リリースは仮説の終点ではなく、より広い条件で確かめる入口です。提供後のレビューでは、次の4つを同じ期間で見ます。
表が収まらない場合は、横にスクロールできます
| 観測 | 例 | 次の判断 |
|---|---|---|
| 利用 | 到達、完了、再利用 | 対象・導線を修正する |
| 価値 | 時間、成果、継続、収益 | 価値の定義を更新する |
| 品質 | エラー、遅延、停止、問い合わせ | 修正や公開範囲を見直す |
| 公平性 | 支援の必要な利用者、端末差、言語差 | 追加調査・改善を行う |
指標が改善しても、別の利用者群へ負担を移していないか、運用コストに見合うか、長期に続くかを確認します。改善しない場合は、機能を足す前に問題・対象・測定のどこが違ったかを再検討します。
7. よくある失敗
- 顧客の要望を問題の調査なしにそのまま仕様化する
- Discoveryで本番コードを作り始め、問題の定義を固定してしまう
- MVPだからといって品質、アクセシビリティ、運用を省く
- プロトタイプでの反応を本番の継続利用と呼ぶ
- 主要指標だけを見て、問い合わせ、支援、エラー、継続を隠す
- 失敗した仮説や停止判断を記録せず、成功した学習だけを残す
8. 成果はリリース数ではなく、次に使える証拠
プロダクト開発の成果は、リリース数ではなく、利用者の問題を理解し、リスクを減らし、次の判断に使える証拠を増やすことです。段階ごとに問題、仮説、品質、運用、停止条件を見直します。
優先順位の付け方は 問題の優先順位付け、検証と意思決定の記録は データドリブン意思決定 と 意思決定フレームワーク も参照してください。