当社では、何を作るかを人が決めて文章に残し、作る作業は AI に任せ、出来上がったものの採否はコードではなく「決めたこととの照合」で判断しています。採否を決める人がコードを読まなくても責任を持てるように、分担の形そのものを設計しています。
採否を決める人は、コードを読みません
開発は、設計役・実装役・点検役の3つに分けています。何を作るかは人が決め、設計役がそれを1枚の文書に書き起こします。実装役の AI がそれを形にし、点検役の別の AI が出来上がりを確かめます。
採否を決める人が読むのは、次の3つだけです。
- 設計の文書
- 実装役が返す「自分で決めたことの一覧」
- 実物(画面の写真と、試験の結果)
コードを読むのは点検役です。人の仕事は、決めることと、決めたとおりになっているかを照らすことに絞っています。
設計の文書は「どこまで」と「しないこと」で書きます
このサイトの問い合わせフォームを例にします。設計の文書は40行ほどで、手順は書いていません。書いたのは、目的、その目的を妨げるもの、どこまでできたら終わりか、しないこと、の4つです。
目的は「送られた問い合わせが、取りこぼし無く社内に届くこと」。妨げるものの筆頭には「送信が黙って消える」を置きました。送った側には「送りました」と出るのに、こちらには届いていない状態です。
そこから「どこまで」が決まります。たとえば、結果を4つに分けて画面に出すこと。成功、入力の誤り、ロボット判定(自動送信を防ぐ仕組み)の失敗、送信の失敗です。失敗したときは、メールの窓口を案内します。「しないこと」には、見た目を変えない、公開はしない、などを並べました。
手順を書かないのは、どう作るかが実装役に任せてよい部分だからです。何を満たせば終わりかさえ決まっていれば、作り方は問いません。
実装役は、自分で決めたことを一覧で返します
作り終えた実装役には、設計の文書に書かれていなかったことを自分でどう決めたか、一覧で返させます。このフォームでは14件ありました。
- 画面の動きを止めたブラウザ(JavaScript を切った状態)ではロボット判定を通れないので、送信は受け付けず、メールの窓口を案内する
- 人には見えない入力欄を1つ置き、そこが埋まった送信は機械からのものとみなして、成功したふりをして捨てる。相手に見分ける手がかりを渡さないため
採否を決める人は、この一覧を1件ずつ読んで、受けるか戻すかを決めます。1つめは、判定を飛ばす抜け道を作らないという判断で、そのまま受けました。どちらも業務の判断で、コードを読まなくても決められます。
あわせて、成功・入力の誤り・送信の失敗の画面を、パソコンとスマートフォンの2つの幅で実際に送信して撮った写真が付いてきます。試験は18件で、すべて通っていました。
点検役は、報告ではなく差分と実物を見ます
点検役は、実装役の「できました」という報告を根拠にしません。何が変わったか(差分)と、実際のファイルから読みます。見つけたものは3段階に分けます。
- 取り返しのつかない欠陥(データの形や、外から見える約束の誤り)は、差し戻します
- 後から返せる負債は、直さずに記録して持ち越します
- 表記の揺れや直し漏れは、点検役がその場で直します
問い合わせフォームでは、差し戻しは0件、負債が5件、揺れが4件でした。負債のうち1件、機械からの送信を捨てたときに記録を残していなかった点は、すぐに直しました。残り4件は、たとえば「絵文字を2字と数える」「画面の幅を変えても、判定の枠の大きさが追いかけない」といったもので、設計の側が「いまは残す」と決めました。
物差しは完璧さではなく、設計の文書の「どこまで」です。点検は1回で、直ったかどうかは設計役が確かめます。
数字で見る分担
当社のサイトを AI に作らせたとき、AI に渡した文章の量は約1,600万トークン(トークンは AI が文章を数える単位)でした。そのうち98.0%は、前のやりとりと同じ部分の再送で、使ったモデルの側で使い回し(キャッシュ)が効いていました。使い回しの分は、新しく読ませる分より安く済みます。設計の文書を1本に固め、同じ前提で何度も渡す形は、費用の面でも理にかなっています。
捨てた案
- 実装役に点検も任せる。自分の報告を自分で確かめても、根拠になりません
- 点検を、通るまで何度でも回す。費用と時間が伸び続け、物差しがいつのまにか完璧さにすり替わります
- 人がコードを読んで承認する。コードを読まない人が採否を持てなくなり、「設計は人が決める」が成り立ちません
任された方が持ち帰れること
この分担で人に残る仕事は、何を作るかを文書に書くことと、AI が自分で決めたことの一覧に答えることです。どちらもコードを読む力は要りませんが、業務を知っている人にしかできません。