三月四日 常務室

PoCの報告をした翌朝、瀬尾は倉田と一緒に常務室へ呼ばれた。大槻の机には、紙の束が2つ置いてあった。

「限定試行を回すにしても、問い合わせの記録がばらばらでは効果が測れんだろう。記録の入力画面を作る。黒江さんは、1週間で作れると言っている」

薄いほうの束は、クラウゼル・テクノロジーズの見積書だった。

クラウゼル・テクノロジーズ 御見積書(抜粋)

件名 問い合わせ記録入力画面の開発/作業期間 1週間
AIで開発するため、従来の工期を大幅に短縮いたします。仕様は貴社ご提示の要件定義書に準拠いたします。

厚いほうが、その要件定義書だった。40ページあり、目次が整い、入力項目の一覧と画面の遷移図まで付いていた。どこを開いても、抜けがないように見えた。

「私がAIに書かせた。項目も画面も全部入っている。他社はもう、こうやって作ってるぞ」

「村瀬課長のチームは、これをお読みになりましたか」

「まだだ。窓口は忙しい。できてから見てもらえばいい」

倉田が、見積書のほうを手に取った。

「1週間で作れる、は本当だと思います。ただ、何が1週間なのかを確かめさせてください。同じ画面を、こちらでも開発支援AIで作ってみます。2日ください」

「2日だな。結論から持ってきてくれ」

三月六日 情報システム課

二日後の夕方、倉田の端末で入力画面が動いていた。日時、取引先、型番、内容、対応の欄が並び、登録を押すと一覧に1行増えた。

「もうできてるじゃない」

「動くものはな。使い方を3つ変えて作った」

画面の骨組みは、目的を伝えるとファイルの作成からテストまで続けて進める「エージェント」の使い方に任せた。入力の検証は、やりたいことを説明してコードの塊を書かせる「対話」で作った。細かい手直しは、書いている途中に続きを出させる「入力補完」でやった。

「補完なら、一行ずつ俺が見て受け入れる。エージェントは結果しか見ない。いちばん速いけど、あとで読む量もいちばん多い。どの使い方で何を任せたかで、確かめる手間がまるで違うんだ」

郵便番号と法人番号の検証は、最初から正しかったという。桁数と確かめ方の計算が、世の中で決まっているからだ。

「問題はこっち」

倉田は、過去の問い合わせメールから抜き出した取引先の住所とメールアドレス300件を、AIが書いた検証に手元で流してみせた。住所で27件、メールアドレスで9件が「形式が正しくありません」と弾かれた。どれも、実際にやりとりしている取引先だった。

「ビル名の入った住所と、少し珍しい形のアドレスを落としてる。コードはもっともらしいから、読むだけじゃ気づかない。実データを流して、はじめて分かる」

倉田は、課のホワイトボードの空いている端に書き足した。

ホワイトボード(倉田の字)「試作に入っていないもの」

  1. 異常時 ― 登録の途中で通信が切れたら。同じ問い合わせを2人が同時に登録したら
  2. 権限 ― 顧客の氏名と電話番号を、誰が見られるか
  3. 整合性 ― 取引先は販売管理システムの顧客コードと、型番は型番マスタと合っているか
  4. 性能 ― 10件なら速い。3万スレッドを入れたら
  5. 保守 ― 半年後に、俺以外が読んで直せるか
  6. 運用 ― 止まったら誰が気づいて、誰が戻すか

「これ、AIに頼めば全部やってくれないの?」

「頼めばやる。でも権限のことは、俺が書かなかったら一行も出てこなかった。書けたのは、要ると知ってたからだ。AIは、知ってる人の作業を速くする道具なんだよ。知らないことを代わりに思い出してはくれない」

「それに、画面の中で閉じてるところは速いけど、販売管理とつなぐところは別だ。二十年前のシステムの仕様を、AIは知らない。あっちの仕様書を読んで実際につないでみるまで、誰にも見積もれない」

「じゃあ、1週間の見積もりって」

「要件定義書に書いてあるものを作る1週間だろ。書いてないものは、見積もりにも入ってない」

同じ日 カスタマーサポート課

瀬尾は、その足で要件定義書を村瀬のところへ持っていった。村瀬は電話を1本終えてから、ページをめくり始めた。10分ほどで、手が止まった。

「型番が、型番マスタから選ぶ必須の欄になってるわね。でも、お客さんは旧版の型番で書いてくるのよ。マスタにはもう載っていないの。型番が分からないまま電話してくる人もいるでしょう」

「それに、電話の記録はどこに書くのかしら。うちは4割が電話よ。この画面、メールしか考えていないみたい」

40ページのどこにも、旧版の型番のことも、電話のことも書いていなかった。AIは、頼まれた「問い合わせ記録システム」を、世の中によくある形で書いたのだろう。朝凪精機の窓口のことは、誰も書かせていなかった。

「きれいに書いてあるけど、うちの窓口の話じゃないのよ。過去のメールを何十件か一緒に見てくれたら、すぐ分かることなんだけど」

瀬尾は手帳に書いた。見積もりは、要件定義書に書いてあることしか見ていない。その要件定義書を、使う人たちは読んでいない。

「AIで作れば1週間」の見積もりに、何が入っていないのだろう?

三月九日 第二会議室

大槻との打ち合わせに、瀬尾は総務課の戸田美和を呼んだ。クラウゼルからは、見積書に続いて契約書の案が届いていた。戸田は検収の条項を指でなぞり、声に出して読んだ。

業務委託契約書(案) 検収の条項

乙は成果物を納入し、甲は納入後10日以内に、成果物が正常に動作することを確認のうえ検収する。

「検収の条件は……正常に動作すること、としか書いてないですね。何を何件入れて、いくつまで間違えてよいのか。成果物に何が含まれるのかも、ここ、書いてないです」

「動けばいいんだろう。倉田くんは2日で動かしたじゃないか」

「動いたものが、そのあとどうなったかの話をさせてください。前に総務の申請フォームを、当時の担当者が開発支援AIで3日で作りました。評判はよかった。担当者が異動したあと、承認者を1人足すだけの変更に2週間かかりました。仕様の資料がなくて、設定がコードの中に直接書いてあったからです」

「その2週間、私が紙で回していました」

「もう一つ。去年、外に頼んだ総務の規程Q&Aです。検収は通りました。規程が改定されたら答えが古くなって、参照する資料の更新手順が納品物に入っていなかった。結局、追加の見積もりを取っています」

「3日でできた、は社内で褒められました。2週間のほうは、誰も数えていません。AIで作ったものは、書いた量ではなく、動かしてからの障害の件数と、直すのにかかった時間で測るべきです」

大槻は腕を組んだ。

「結論から頼む。黒江さんに頼むのか、頼まないのか」

「頼むかどうかの前に、頼み方を変えさせてください。見積もりを取り直すときの条件です」

入力画面の発注条件(瀬尾の案)

  1. 要件定義と並行して、村瀬課長のチームと過去の問い合わせを現物で数十件見る工程を入れる
  2. 受け入れ条件は件数で書く。例「過去の問い合わせ100件を入力し、登録できない・誤って弾く件数が2件以下」
  3. 納品物に、設計資料と運用手順書(マスタの更新のしかた、止まったときの戻し方)を含める
  4. 追加要望は、窓口(瀬尾)と判断者(村瀬課長)を決め、無償と有償の境目を先に書く
  5. 実際に作業する人と再委託の有無、稼働後の保守の範囲と費用を、いま見積もってもらう

大槻は最後まで読み、紙を置いた。

「AIの話をしに来たと思ったら、普通の発注の話だな」

「はい。システムを頼むときに、いつも決める項目です」

それが答えだった、と瀬尾は思った。「AI」という言葉が出てきたとたん、いつも決めていることが、見積もりからも契約書からも消えていた。1週間は嘘ではない。作るところだけを数えた1週間だった。

「この条件で見積もりを取り直せ。1週間で済まなくてもかまわん」

会議室を出るとき、倉田が小さく言った。

「『で、それ誰が直すの』って、契約に書けるんだな」

瀬尾は手帳に書いた。

「『AIで作るから速い』と聞いたら、作る以外の工程が見積もりに入っているかを見る。受け入れは件数で書く」