起票するAIと、直すAIの間に、台帳を1つ置く

一番飯店のセルフオーダーシステムを、作り直しています。開発は外部の開発パートナー、テストと引き継ぎは私。どちらも、手を動かしているのはAIです。

2つのAIの間に置いたのは、チャットでも共有ドキュメントでもなく、課題管理台帳「Baton Board」でした。自社で作った、顧客と共有する台帳です。片方のAIが課題を起票し、もう片方のAIが直して状態を変え、最初のAIが確かめて閉じる。人は、優先順位と仕様の判断だけをします。この回し方で決めたことと、なぜ既製の課題管理ツールを使わなかったかを書きます。

誰が何をするか

私の側のAIは、テストをして起票します。API層を叩くテスターと、ブラウザを実際に操作するテスターを回し、見つけたものを台帳に書きます。ある夜は8時間止めずに回し、朝までにエラーがゼロだったことと、既知の課題が安定して再現したことの両方を確かめました。画面写真は、自分で動かしたヘッドレスのブラウザで撮り、本文の途中に挟みます。

開発パートナーの側のAIは、台帳を読んで直します。直したら状態を「確認待ち」に変え、コメントに何をどう直したかを書きます。十数件をまとめて直して、まとめて確認待ちにした日もありました。

私の側のAIが、確認待ちを再テストします。通れば「完了」、通らなければコメントを添えて戻す。この往復が、台帳の上で回ります。

人がやるのは3つです。どれを先に直すかの合意、仕様の判断、最後のサインオフ。たとえば「予約の時間帯が重なったら弾くのか、警告だけにするのか」は、AIには決められません。人が決めて、台帳のコメントに仕様として残し、AIがそれを読んで実装しました。

状態は4つ、戻す道は1本

状態は、未着手、対応中、確認待ち、完了の4つに保留を足しただけです。誰がどの状態に動かすかを決めておくと、台帳を開いた瞬間に「いま球は誰の手にあるか」が分かります。

未着手にするのはテスト側。対応中と確認待ちにするのは開発側。完了にするのはテスト側。戻す道は、確認待ちのままコメントで差し戻す1本だけです。

差し戻しの例を1つ。一覧の表示が遅い課題を開発側が直して確認待ちにしましたが、テスト環境で測ると改善が届いていませんでした。「索引が本番のデータベースに当たっているかを確認してほしい」と書き添えて戻したところ、次の回で数分の1の時間になっていました。戻すときは、通らなかった事実だけでなく、次に見る場所を1つ書きます。

読むのがAIなら、根拠はファイルと行で書く

台帳を読むのがAIだと分かってから、起票の書き方を変えました。「たぶんこのあたり」ではなく、ファイル名と行番号で書きます。事実、推定、要確認を分けて書きます。人が読むなら文脈で補えますが、AIは書いてあることをそのまま根拠にします。

これは失敗から決めたことです。最初のテストで「提供済みにすると画面が固まる」と起票しました。実際には、確認ダイアログを自動操作が閉じられずに止まっていただけで、人が使えば固まりません。憶測で「フリーズ」と断定した課題が、相手のAIに渡っていました。訂正のコメントを書き、以後は自動テストで固まって見えたものは、まずダイアログを疑うことにしました。

起票する前に、相手の最新のコードを取り込んで読む。これも決めごとです。相手は同じ日に何度も改修しています。古いコードを根拠に書いた課題は、届いた時点で古くなっています。

前提として、プログラムと仕様は共有しておく

ファイルと行で書けるのは、相手のプログラムをこちらが読めるからです。この案件では、開発パートナーのリポジトリにこちらも入れてもらい、テスト環境も共有しています。起票の前に最新のコードを取り込んで読み、直したものを同じ環境で測る。この2つが無いと、課題は「画面でこう見えた」で止まり、相手のAIは原因を探すところから始めることになります。

仕様も同じです。作り直しの元になった旧システムの機能一覧と、打ち合わせで決めたことは、こちらの台帳に打ち合わせ記録として残っています。「仕様ではこうなっている」と書くとき、その仕様がどこにあるかを相手も見られる状態にしておく。共有されていない仕様を根拠にした課題は、相手にとっては新しい要望と区別が付きません。

このレベルで直し合うなら、課題管理台帳の前に、プログラムと仕様とテスト環境の3つを共有しておく。台帳は、その上で回るものです。

なぜ既製の課題管理ツールにしなかったか

Baton Board は自社で作ったものです。既製の課題管理ツールでも、課題を並べて状態を管理することはできます。使わなかった理由は機能ではなく、変える速さです。

開発者と、開発者のAIと、こちらのAIの三者がどう受け渡せば滞らないかは、やってみないと分かりませんでした。実際、回し始めてから台帳側を何度も変えています。AIから使う手順書とサンプルを1本にまとめる。画像を本文の順番どおりに挟めるようにする。状態を誰が動かすかを決める。Excelで読みたい人のために出力を付ける。書き込みは画面と同じAPIだけを通す、と決める。どれも、相手のAIが詰まった翌日に直したものです。

既製品なら、詰まった箇所は運用でよけるしかありません。自分の台帳なら、詰まった箇所を台帳の側で直せます。試行錯誤が要ると分かっていたので、試行錯誤できる台帳にしました。

開発側から見ると

開発パートナーには、手順書1枚と、通しで動くサンプル1本を渡しました。サンプルは追加のインストールが要らず、相手の環境がWindowsでもMacでも同じものが動きます。

回し始めてしばらくして、チャットで「AIに課題管理表を読み込んでもらう作戦、効率的でいいですね」と書いたところ、相手からは「ステータスも、コメントも勝手にやってくれるようになりました」「運用だいぶ楽です」と返ってきました。こちらの運用も、台帳の管理は全部AI任せで、出す前にAIが何を書いたかを確かめるだけです。

台帳を渡してしばらくして、相手が自分で1件、課題を足していました。こちらが起票したものではなく、相手の側で気づいたことです。台帳が「渡されたもの」から「使うもの」に変わった、と分かった瞬間でした。

お客様が触る段階では、人がテストする

ここまでは、テストする側もAIでした。この先、お客様が実際にテストする段階になると、触るのは人です。お客様は画面を操作して、気づいたことを台帳に書き、画面写真をCtrl+Vで貼ります。AIに書き方を合わせてもらう必要はありません。

人が書いた課題を読むのは、こちらのAIです。再現できるか、既に起票済みの課題と同じか、原因がどこにありそうか。人が書いた言葉と画面写真から、AIが判定して、ファイルと行を添えた形に書き直してから開発側に渡します。起票する側が人になっても、台帳の回し方は変わりません。変わるのは、最初の1件を誰が書くかだけです。

相手が変われば、台帳の使い方も変わる

ここまで書いた回し方は、開発者と検証者の間のものです。両方がプログラムを読め、両方の側でAIが動いている。この条件だから、ファイルと行で書き、状態をAIが動かす回し方が成り立ちます。

お客様と開発者の間では、条件が違います。お客様はプログラムを読みません。書くのは「こう操作したら、こうなった」と画面写真です。優先度も、お客様にとっての困り具合で決まります。ここで開発者向けの書き方を求めると、起票が止まります。

検証者とお客様の間も、また違います。お客様が書いた課題を検証者が引き取り、再現して、開発者向けの形に書き直す。この段階では台帳は翻訳の場になります。

同じ台帳でも、誰と誰の間で使うかで、書き方も状態の動かし方も変わります。1つの決まりを全部の相手に当てはめないこと。相手の組み合わせごとに、誰が何を書き、誰が状態を動かすかを決め直します。

まとめ

• 状態を誰が動かすかを決めておく。戻す道は1本、戻すときは次に見る場所を書く
• 読むのがAIなら、根拠はファイルと行で。事実、推定、要確認を分ける
• このレベルで直し合うなら、プログラム・仕様・テスト環境を先に共有する
• 既製品にしなかったのは機能ではなく、詰まった翌日に台帳の側を直せるようにするため
• 相手の組み合わせごとに、誰が何を書き、誰が状態を動かすかを決め直す

課題管理台帳の役目は、人が読むための記録として残ることでした。動かしているのはAIでも、読み返すのは人です。

一番飯店との取り組みは 導入事例 に。自社の業務アプリの話は 特設ページ にまとめています。

石井 亮介（りょうさん）

データパレード 代表取締役

XContact

㈱データパレードの代表取締役で、高田馬場の町中華「一番飯店」のChief Data Officerも務めています。BIツールのセールスエンジニア・システムエンジニア・カスタマーサクセス歴15年。大学のデータサイエンス教育で講師も担当してきました。現在は自社業務のほとんどをAIに移管し、AI10部署と50を超える自動処理が24時間動く「AI経営」を実践中。その実践知をこのブログで発信しています。