11:34 - 12:32
アイデアからビジネス調査へ
この章のデモは、コードを書く場面から始まりません。出発点は、ワールドカップのスタジアムで乗車する人の問題です。話者が示す流れでは、まずアイデアを調べて、実際に検討する価値があるかを考えます。
スタジアムでの乗車場所という機会
混雑したスタジアムを出た乗客は、人が集まる出口の近くではなく、少し離れた場所で迎えの車に乗りたいかもしれません。この状況は、単なる機能の思いつきではありません。乗客の困りごと、場所の条件、そして実現する価値を一緒に考える必要があるビジネス上の機会です。
補足すると、アイデアをすぐ実装すると、重要な前提を確認しないまま作り始める危険があります。この例では、まず「どのスタジアムで問題が起きそうか」「似たイベントでどのような対応があったか」といった問いに分けられます。比較できる出来事（comparable events）を調べると、曖昧なアイデアを、範囲や前提を検討できる問いに変えられます。
図1：Slackでスタジアムの乗車場所を話し合い、Cortanaを呼び出している画面です。
この画面は、具体的な問題と、会話を調査へ進める操作を示しています。話者が示すデモでは、Slackでの議論からCortanaの呼び出しへ移ります。
会話から調査の成果物へ
Slackはアイデアを出す入口です。しかし、短い会話の返答だけでは、チームが後で比較したり、範囲を決めたりするには足りないことがあります。そこでCortanaは、グラフを使った調査をウェブ画面で進めます。
ここでいうグラフは、情報を単独の一覧としてではなく、イベント、会場、その他の関連する情報のつながりとして扱う仕組みです。関係を利用すると、スタジアムの候補や、似た会場イベントを調べる手がかりを見つけやすくなります。Cortanaは、その手がかりを使って、比較対象となる出来事と、可能性のあるスタジアムを調べます。
この流れの大切な点は、アシスタントが意思決定者ではないことです。Cortanaは情報を集め、比較し、検討材料を整理します。どの地域を対象にするか、機能を作るか、どの前提を採用するかは、チームが判断します。つまり、アシスタントは判断を支援しますが、判断の責任を引き受けるわけではありません。
この例では、Slackとウェブ画面が別々の仕事をしているわけではありません。同じ課題を、異なる深さで扱う入口です。Slackでは問題を共有して調査を始め、ウェブ画面では比較や図表を含む、より詳しい調査成果物を確認します。会話から成果物へ移ることで、アイデアがチームで検討しやすい形になります。
図2：比較対象となるイベントと、候補となる会場を示す調査結果です。
この結果画面は、広いアイデアが、比較できる情報と図表を持つ形へ整理される様子を示しています。一方で、この画面だけでは、使われたデータの元や調査方法までは分かりません。
調査結果を読むときの注意
比較対象や会場の候補が表示されたからといって、そのまま事実や正解になるわけではありません。このデモで確認できるのは、アイデアを調査し、比較可能な材料へ変える流れです。データの出典、対象期間、候補を選んだ基準は、示された情報だけでは特定できません。
したがって、次の段階では、チームが調査結果の出所と前提を確認する必要があります。調査の成果物は、開発を始める命令ではありません。何を追加で確かめるべきかを明らかにし、次の要件定義や設計の判断を支える材料です。