12:32 - 13:18
要件定義、設計、迅速なプロトタイピング
この章の流れ
前の章では、スタジアムから出る乗客のための乗車場所というアイデアを、類似するイベントや会場の調査につなげました。この章では、その調査結果を、実装に渡せる形へ変えていきます。
発表では、次の順番が示されます。
- 最初に扱う地域の範囲を決める
- 画面のモックアップを作る
- A/B実験の候補を作る
- デザインを既存のコードに対応づける
ここで大切なのは、これらが同じ成果物ではないことです。スコープは「どこまで扱うか」、モックアップは「どう見えるか」、実験案は「何を比べるか」、コードマップは「どこを変更するか」を表します。
調査結果を最初のスコープに変える
発表の例では、スタジアムの乗車場所機能について、北米を最初の対象地域にする案が出されます。これは世界中に一度に展開するという約束ではありません。調査をもとに、まず検討する範囲を決めるための作業です。
この段階でのスコープは、実装済みの機能でも、成功が証明された事業計画でもありません。チームが次に何を設計し、何を検証するかをそろえるための、作業上の仮説です。
例：調査からモックアップへ
たとえば、チームが「北米のいくつかのスタジアムで、混雑した出口から少し離れた乗車場所を案内する」という案を検討するとします。ここで北米を初期スコープにすれば、対象となる画面、データ、関係するチームを具体的に調べられます。
この案がそのまま本番機能になるわけではありません。調査で得た仮説を、デザインと実装の担当者が話し合える大きさにした、と考えると分かりやすいです。
モックアップは合意のための成果物
次にチームは、Figmaで画面のモックアップを作ります。モックアップ（mockup）は、完成したソフトウェアではありません。利用者の操作や画面の見た目を、実装前に確認するための設計資料です。
モックアップを使うと、調査で見つけた問題を、画面上の提案に変えられます。プロダクト担当者、デザイナー、エンジニアは、同じ画面を見ながら、必要な情報や操作を話せます。コードを書き始める前に、方向の違いを見つけられます。
つまり、モックアップの主な役割は、出荷を証明することではなく、要件の意味をそろえることです。画面がきれいに見えても、実際のデータやサービスが使えるとは限りません。
A/B実験の候補を作る
発表では、乗車場所を示すカードについて、行動を促す文言（call to action）を二つの候補で示します。これはA/B実験（A/B experiment）の準備です。A/B実験では、二つの案を同じような条件で比べ、あらかじめ決めた結果を確認します。
二つの乗車場所カードに、異なる行動喚起文を入れたモックアップです。横に並べることで、A/B実験で変える部分が分かります。動画の該当箇所（12:46）
例：二つの文言は結果ではない
たとえば、カードAが「ここを乗車場所にする」、カードBが「この場所で迎車する」だとします。二つの文言は、利用者にどの行動を期待するかを表す仮説です。どちらがよく使われるかは、実験を行って結果を測るまで分かりません。
したがって、デザインに二つの案があることは、Aが勝ったことを意味しません。プロトタイプは比較可能な候補を作りますが、実験結果や本番での効果はまだ示していません。
デザインを既存のコードへ対応づける
画面案ができると、チームはそれを実際のコードの構造と照合します。発表の画面では、影響を受けるiOS、Android、Goのリポジトリが示されています。これは、一つの画面変更が、一つのファイルだけで終わらないことを表します。
デザイン上の要求を、影響を受けるモバイルクライアントとGoのルーティング関連コードへ対応づけています。見た目の案を、変更すべきコードの範囲へ変換する段階です。動画の該当箇所（12:57）
ここでいうフロントエンド（frontend）は、利用者が見る画面や操作を担当します。バックエンド（backend）は、サービスやデータを提供します。スタジアムの乗車場所の流れが正しく動くには、モバイル画面だけでなく、経路案内などを担当するバックエンド側との接続も必要です。
例：コードマップが作る境界
たとえば、乗車場所カードをモバイルアプリに追加し、選ばれた場所をルーティングサービスへ渡すとします。この場合、デザイナーの画面案は、iOSとAndroidの画面変更、さらにGoで動くサービス側の変更に関係します。
コードマップは、すべてのリポジトリを変更するという意味ではありません。候補となるコードの場所と関係を先に示し、コーディング担当のエージェントやエンジニアが、限られた範囲で計画できるようにします。これは、視覚的な意図を、複数リポジトリにまたがる実装計画へ変換する作業です。
なぜ数週間の調整を短くできるのか
発表者は、この流れによって、以前は数週間かかっていた調整を圧縮できると説明しています。速さの理由は、単にモデルが速くコードを書くからではありません。調査、要件、デザイン、コードの関係を共有できるからです。
調査担当が得た仮説はスコープになります。そのスコープはモックアップに反映されます。モックアップから実験の候補が生まれます。そして、デザインとコードの対応づけによって、実装担当者は変更場所を探しやすくなります。役割ごとに情報が切れた状態で、同じ説明を何度もやり直す必要が減ります。
ここでの「圧縮」は、意思決定を省くことではありません。関係する人が同じ文脈（context）を見て、より早く確認や修正を行えるという意味です。スコープを決める判断、実験結果の評価、実装の承認は、依然として別の作業です。
この段階で分かること、まだ分からないこと
この章の成果物は、次のコーディング段階へ渡すための準備です。
- スコープ：最初に扱う地域や対象を仮に定めます。
- モックアップ：利用者向けの画面と操作の案を共有します。
- 実験の候補：比較する文言や画面の差分を明確にします。
- コードマップ：関係するフロントエンドとバックエンドの範囲を示します。
一方で、これらだけでは本番での品質や事業上の効果は証明できません。二つの文言のどちらが有効かは、実験の結果が必要です。モックアップが実際のクライアントやサービスで動くかは、実装と検証が必要です。北米という初期スコープが最終的に正しいかどうかも、後の判断と証拠にかかっています。
この区別があると、プロトタイピングを過大評価せずに済みます。プロトタイプは「すでに成功した機能」ではありません。次の担当者が、何を作り、どこを調べ、どの仮説を検証するかを理解できる、共有された出発点です。