動く画面は、会議より速く仕様を決めた

前回、人の注意をどこに配るかの原則を書きました。今回は実録に戻ります。AIに動く画面を十数分で作らせ、会議の代わりに「動くもの」で要件を確かめた話です。

実際の案件の話なので、詳細は書けません。書籍と同じく、架空の小売チェーンの設定に置き換えて書きます。構造はそのままです。

紙の上では「たぶん、合っています」

題材は、会員ランク別の先行販売でした。特定の商品を、上位の会員から順に段階的に買えるようにする。上位会員には数日早く、次のランクにはその数日後、最後に全員へ。

この機能には、二つの画面が要ります。販売企画を登録して手入れする管理側の画面と、お客が見る販売サイトの画面。仕様は文書にしてあり、レビューもしてもらっていました。返ってきた言葉は「たぶん、合っていると思います」。

「たぶん」が消えないのには理由があります。段階開放は時間の業務です。ある日にはこのランクだけに購入ボタンが出て、翌々日には次のランクにも出る。その様子は、紙の上では想像するしかありません。担当者の頭の中には正解があるのに、紙はそれを引き出す形をしていない。

十数分で、動いた

そこで、動く画面を作ることにしました。作ったのは私ではなく、AIです。

渡したのは、企画登録画面と販売サイト画面の要件、そして開放のルール。会員ランクの順序、ランクごとの開放日、期間の重なり方。「今日」を動かせるつまみをつけること。最初の動く画面が返ってくるまで、十数分でした。データベースは使わず、登録したデータはメモリに置くだけの、いちばん軽い作りです。

その画面で、企画を登録します。商品を選び、ランクごとの開放日を入れる。次に販売サイトの画面に切り替えて、「今日」を一日ずつ進める。開放日の前は、誰の画面にも購入ボタンが出ない。上位会員の開放日になると、その会員の画面にだけ現れる。数日進めると次のランクにも。最後に全員に。

これを、担当者の目の前で動かしました。紙で「たぶん」と言っていた人が、日付を一日進めるたびに身を乗り出してくる。 登録した企画が、お客の側からどう見えるかを、実感を持って確かめてもらえた。ここが、この案件でいちばん手応えのあった瞬間です。もちろんその後、表示や動線の注文が何往復か続きました。それでよいのです。注文が出ること自体が、確認が始まった証拠でした。

効いたのは、指示文ではなかった

AIに頼んだ指示文が巧みだったから十数分で動いた、と思われるかもしれません。違います。効いたのは、渡した中身でした。

ランクの順序が決まっている。開放日の決め方が言葉になっている。「今日」を動かして確かめる、という検証の設計が先にある。渡したのは指示文ではなく、業務の言葉で書かれたルールそのものです。ここが曖昧なままAIに頼んでいたら、曖昧さが十数分で実装されただけだったでしょう。

以前「答案と採点表」の話を書きました。動く画面は答案です。採点表は、担当者の頭の中にある「こう開放されるはず」という判断でした。動く画面は、その採点表を引き出す最良の質問だったのです。

損益分岐点が動いた

立ち止まって、変化の大きさを測っておきます。この規模の確認用の画面は、以前なら作るのに数週間かかりました。数週間かかるなら、「作って確かめる」より「会議で議論して詰める」ほうが合理的な場面も多かった。仕様の確認がいつも紙の上で行われてきた本当の理由は、ここにあります。

AIはこの損益分岐点を壊しました。作るほうが、話し合うより速くて確かになった。動く画面は、会議より速く仕様を決めます。 ただし、何を確かめたいかが一つに絞れていて、そのルールが業務の言葉で書けている場合に限って。

正直な注意も添えます。動く画面のコードは、そのまま本番には使いません。確認のために作り、確認が終われば捨てる。残すのは、確かめられた仕様のほうです。動くことと、正しいことは別ですから。

ボトルネックはモデルにある。実装が十数分になった今、律速は「何を確かめるべきか」を言葉にする側に移りました。この案件で私が実感した、いちばん具体的な一枚がこれです。

次回は原則回に戻ります。要件を聞き出す仕事、つまり業務の人から知識を引き出す場で、AIに任せられる席と、任せられない席の話をします。

この連載の元になった書籍『モデルを育てる ― 要件を探り、MVPで確かめ、境界で分ける実践ドメイン駆動設計』(有原悠)では、ここで書いた「日付を動かすデモ」を、架空の小売チェーン「アオバ堂」の先行販売を題材に、要件の探り方からモデルの改訂まで一つの章で追っています。

※Kindle Unlimited読み放題対象です。

▼ 前の話

▼ 次の話