AIを使えば、コードを書き、調べ、比較し、設計する作業を速く進められる。ところが、作業が速くなることと、完成が早まることは同じではない。作れるものが増えたせいで、調べすぎ、考えすぎ、広げすぎて、最初に欲しかったものがいつまでも完成しないことがある。
棚と、構造的diffツール
Kevin Lynaghの「Overthinking」 ↗を読んで、このずれを考えた。彼は、自分のプロジェクトには二つの進み方があると書いている。多少の手直しをしながら、そのまま作って満足する場合。もう一つは、先行事例を調べるうちに扱う範囲が広がり、元の問題を解決することも、作る楽しさを味わうこともできないまま時間を使う場合だ。
対照的なのが、友人と作ったキッチン用の棚と、構造的diffツールの調査である。棚作りの成功条件は、友人と木工を楽しみ、自分のキッチンに合う棚を作ることだった。ほかの家でも使えるように一般化する必要はなく、週末で完成した。
一方、diffツールは、LLMが生成したコードをEmacsでもう少し見やすく確認したい、という問題から始まった。調べるうちに、構文木、意味的diff、既存OSS、研究論文へと関心が広がる。そこで彼は、自分が欲しかったのは自分用の確認手順の改善だった、と思い出す。
何を作るべきかを調べていたはずが、いつの間にか、どこまで作れば価値があるのかを考え始める。拡張性、一般化、OSSとしての独自性、将来の保守。どれももっともらしい論点だからこそ、最初の小さな目的を見失いやすい。
成功条件が曖昧なままAIに相談する
このずれは、AIとの作業でも起きる。LLMに相談すれば、代替案、関連技術、将来の拡張、設計上の論点が次々に出てくる。選択肢を知るには便利だが、何をもって完成とするかが曖昧だと、提案のたびに作る範囲が広がってしまう。
AIは必要な実装を速くする。同時に、不要な実装や調査、過剰な設計も進めやすくする。着手の負担が小さいため、「ついでにこれも」が増えるのだ。個々の作業時間を短くしても、作業そのものが増え続ければ、完成には近づかない。
自分のための小さな道具なのか。他人にも使わせる必要があるのか。将来の機能を、今作る理由はあるのか。調べることで最初の問題に近づいているのか、それとも作り始めない理由が増えているのか。こうした成功条件を、提案を受け入れる前に確かめたい。
企業の構想が膨らむとき
企業のAI活用でも、同じことは起こりうる。特定の業務を少し楽にするエージェントを考えていたはずが、全社ナレッジ基盤、セマンティックレイヤー、権限管理、評価基盤、マルチエージェント構成、運用監視まで視野に入ってくる。
これらは、いずれ必要になるかもしれない。だが、「特定の判断を少し速くする」という最初の目的に対して、どこまでが今必要なのかは別に判断する必要がある。構想を大きくした結果、目の前の業務を改善するものが何も完成しないなら、その広がりを喜ぶことはできない。
だから、人間には構想を切る役割がある。LLMが並べた案から一つを選び、将来の要件は保留し、一般化の提案を今回の目的に照らして判断する。考え、調べたうえで、作り切れる大きさに戻す。その判断の重みが、AI時代には増していると思う。
自分のキッチンに合う棚
ときには、ただ棚が欲しいだけなのだ。自分のキッチンに合う棚。自分の仕事を少し楽にする道具。気になっていた使いにくさを直す小さな実装。それなら、初めから他人にも使える製品や、あらゆる用途を支える基盤にする必要はない。
構想を広げる楽しさはある。それでも、完成しない高度な構想より、完成した小さな道具の方が、今の仕事を変えられる。どこまで作れば十分かを見切り、十分に考えたら、馬鹿みたいに小さく作り始める。その勇気が要るのだと思う。