AIによる不具合修正が終わらなくなる原因と、完了条件の決め方

不具合の修正が、いつまでも終わらない現場に立ち会いました。原因はAIの性能ではなく、終わりを決めていなかったことでした。

同じことは、文章の推敲でも資料作りでも起きます。AIは「もっと良くできますか」と聞けば、いくらでも答えを返します。止まるところを決めるのは、頼む側の仕事です。

この記事では、実際に終わらなくなった現場で何が起きていたか、どう立て直したかを書きます。

前提

対象は、1000ファイルほどの規模の業務システムです。公開前の最終確認として、AIに点検をさせていました。

このシステムには事情もありました。開発の途中で置き場所を3回変えていて、そのたびに古い書き方が残っています。指摘の多くは、その残りかすを拾ったものでした。

何が起きていたか

1周まわすと20件ほどの指摘が出ます。直す。もう一度まわすと、また新しい指摘が出ます。

出てくる指摘は、間違いではありません。もっとこう書けます、この書き方は将来困りますという、磨き込みの提案です。丁寧にやれと指示すれば、いくらでも出てきます。

やっているほうは、直しても直しても終わらないので消耗します。前に進んでいる実感がありません。

しかも、直すたびに別の場所が動くので、動作の確認もやり直しになります。1件直して、画面を開いて、データを用意して、動かして、戻す。この往復が積み上がると、直している時間より確認している時間のほうが長くなります。

人に頼むときは、相手が「これで十分では」と言ってくれます。経験のある人ほど、どこで手を止めるかを知っています。

AIは言いません。頼めば応えます。丁寧にと言えば、いくらでも丁寧になります。これは弱点というより性質です。分かったうえで使えば、条件さえ決めておけば疲れずに走り続けてくれる、という長所になります。

立て直した手順

着手する前に、どうなったら終わりかを1行で書きます。

このときの条件は「本番で人の手が必要になる不具合をゼロにする」でした。書き方の好みや将来の備えは、条件の外へ出します。

外に出したものは、消すのではなく別の一覧に移します。あとで手が空いたときに拾えるようにするためです。捨てると、また同じ指摘が出たときに判断し直すことになります。

次に、指摘を影響の大きい順に並べました。並べ方の基準もその場で決めます。

お客様のデータが失われるもの。お金の計算が合わなくなるもの。画面が開かなくなるもの。ここまでが本番の不具合です。それ以外は、表示が少しずれる、読み込みが遅いといった種類なので後回しにしました。

実際に上から片づけると、20件のうち本番に関わるものは5件でした。残りは急ぎではありません。この時点で、終わりが見えるようになります。

内容も具体的でした。

起動時の処理に、全部のデータを消して作り直す手順が混ざっていたこと。本番で使える簡単なパスワードの管理者を作れるテスト用の記述が残っていたこと。AIの利用回数を、処理が成功する前に数えていたこと。

どれも、放っておくと事故につながります。逆に言えば、この3つを直せば公開して構わない、という判断ができました。

もうひとつ変えたのは、1件直すたびに検証していたのをやめたことです。数件まとめて直してから、通しで確認します。

まとめて直すと、どれが原因で動かなくなったか分かりにくいのでは、という心配はあります。ただ実際には、5件程度なら切り分けられます。往復の回数が減るぶん、進みは明らかに速くなりました。

条件の外に出した指摘は、消さずに一覧へ移しました。この一覧が、次に手を入れるときの出発点になります。

実際、公開したあとの落ち着いた時期に、この一覧から3件を拾って直しています。急ぎではないと判断したものが、時間ができたときに片づく。この流れができると、指摘を外に出すことへの抵抗が減ります。

捨ててしまうと、次に同じ指摘が出たときに、また判断からやり直しになります。判断そのものを残しておくのが、あとで効きます。

一度書いた完了条件を、動かしてはいけないわけではありません。

このときも、途中で1件だけ条件に足しました。読み込みが極端に遅い画面が見つかり、これは本番で人の手が必要になる、と判断したためです。

大事なのは、条件を変えるときに「なぜ変えたか」を書き残すことです。書かずに増やしていくと、結局は終わりが無い状態に戻ります。

同じことは、開発以外でも起きる

この現象は、プログラムに限りません。

資料の推敲をAIに任せると、何度でも改善案が出ます。文章の言い回し、構成の入れ替え、図の追加。全部もっともらしく、全部やる必要はありません。

対処は同じです。着手前に「どうなったら出せるか」を書く。たとえば「社内の会議で使えれば十分。社外に出す体裁は今回は求めない」と決めておけば、そこで止まれます。

もうひとつ効いたのが、点検を頼むときに前提を渡すことです。

このシステムは公開前で、利用者はまだいない。データの移行はすでに終わっている。使うのは社内の10名ほど。こうした前提を最初に伝えると、返ってくる指摘が変わります。

大規模な同時アクセスへの備えといった、この段階では要らない指摘が減りました。前提を書く手間は5分ほどですが、そのあとの選別にかかる時間はずっと短くなります。

まとめ

終わらなくなる原因は、AIの側にはありません。終わりを決めずに「徹底的に」と頼んだことにあります。

先に完了条件を1行で書く。指摘は影響の大きい順に並べる。確認はまとめて行う。この3つで、20件の指摘は5件の実作業に変わりました。

いまAIに任せている作業について、どうなったら終わりかを1行で書いてみてください。書けないなら、着手はまだ早い段階です。