AIの叩き台は、壊されるためにある
前回、AIが十数分で作った動く画面で要件を確かめた実録を書きました。今回はその原則です。業務の人から知識を引き出す場で、AIに任せられる席と、任せられない席の話をします。
先に結論を言うと、AIは「叩き台を出す席」には理想的で、「叩き台を壊す席」には座れません。そしてこの区別を曖昧にしたとき、要件定義は静かに壊れます。
人は白紙からは語れない
要件を聞き出す仕事には、昔から知られた癖があります。「仕様を教えてください」と聞くと、一般論が返ってくる。「たとえば直近の実物は?」と聞いて初めて、構造と例外が一緒に出てくる。「対象の店を指定できる」だと思っていた要件が、実例を一つ聞いただけで「ブロック指定に、例外の店を足したり外したりする」という形に化ける。
もう一つの癖。人は白紙からは語れませんが、間違った案には即座に反応できます。 ラフな図や画面の下書きを見せると、「違う、そうじゃない」が出てくる。この「違う」が、聞き取りの最上の収穫です。だから叩き台の完成度は低くていい。低いほうが、遠慮なく壊してもらえます。
要件を引き出す仕事の正体は、聞き役ではなく試作者です。開発者が叩き台を作り、業務の人がそれを現場の知識で壊し、生き残った部分だけが仕様になる。
AIは、理想の叩き台係
この構図に、AIはぴたりとはまります。
叩き台は無尽蔵に出せる。壊されても傷つかない。会議の録音から「起きた出来事」の候補を書き出させる。古いシステムのコードを読ませ、条件分岐を「仕様の候補一覧」として洗い出させる。合意した実例を、テストに写せる形に整形させる。人が数日かけていた下ごしらえが、数分で終わります。
前回の動く画面も、この席の仕事でした。十数分で作られた画面は、担当者に壊してもらうための叩き台です。壊される前提で作るから、速さが価値になる。
判定の席には、座れない
では、任せられないのは何か。判定です。
洗い出された分岐のうち、どれが意図で、どれが化石か。「入荷した」という言葉が二つの部署で違う意味に使われていたとき、どちらが正か、それとも両方が別の概念か。「基本はこう。ただし……」の、ただし以降にこそ本体があるとき、その例外を残すべきかどうか。「予約……っていうか、取り置きなんですけど」という言い直しの奥に、概念の境界線が走っているかどうか。
これらは、現場の人の頭の中にしかありません。学習元の世界中のコードには、この会社の業務の意思は一行も書かれていない。AIは候補を増やす係であって、検証者にはなれない。判定とは、業務との合意のことであり、合意は業務の人としか結べないのです。
混ぜると、壊れる
この二つの席を混ぜたときに起きる事故を、二つ挙げます。
一つ目。AIは物わかりが良すぎます。こちらが仮説を口にすると、もっともらしい賛成を返してくる。以前「答案と採点表を同じ受験生に書かせるな」と書きましたが、要件の場でも同じです。叩き台を出した本人に「これで合っていますか」と聞いても、壊してはくれない。壊す係は、必ず業務の側に置く。
二つ目。AIの叩き台が上手すぎて、そのまま仕様になってしまうこと。「AIも言っているし」は合意でも検証でもありません。昔からある「言われた画面をそのまま作る」型の失敗の、新しい姿です。叩き台は壊されてはじめて価値を持つのに、壊す工程を飛ばしてしまう。
そしてもう一つ、成果の置き場所を間違えないこと。AIとの長い会話ログは、成果物ではありません。成果は、更新された用語集とシナリオに移して初めて残ります。会議の記録は残るのにモデルが更新されない、という失敗を、AIとの会話でも繰り返さないでください。
律速は、壊す側にある
まとめます。叩き台の生産は、いくらでも速くしていい。AIはその席の最良の相棒です。ただし、叩き台を壊す側、つまり現場の判断を引き出す仕事は、人にしかできません。
ここでボトルネックの話に戻ります。叩き台が無限に湧く時代、要件定義の速度を決めるのは、壊す側の注意と時間です。前回まで「人の注意をどこに配るか」と書いてきたのは、このためでした。業務の人の注意を、叩き台を壊す仕事に集中させる。それ以外は、AIに出させる。ボトルネックはモデルにあり、モデルは壊されながら育ちます。
次回は実録回です。本を一冊書くあいだ、AIの書いた章を読者役の私がどう壊したか。全面撤回になった章の話を含めて、壊す側の仕事の中身を書きます。
この連載の元になった書籍『モデルを育てる ― 要件を探り、MVPで確かめ、境界で分ける実践ドメイン駆動設計』(有原悠)では、この「叩き台と検証」の技法を、架空の小売チェーン「アオバ堂」の企画担当者との対話を題材に、聞き方の技法から探索の道具立てまで展開しています。
※Kindle Unlimited読み放題対象です。
▼ 前の話
▼ 次の話
