AIに設計を頼んだら、立派な設計書が返ってきた。要求も、機能も、テスト項目も、一通り揃っている。自分で書いたら何日かかっただろうと思いながら読み始める。ところが、スクロールしても、まだまだ続く。途中から少しずつ読み方が粗くなり、最後には「まあ、大丈夫そうだ」で閉じてしまう…。
コーディングエージェントを使っていて、こんなことが増えてきました。。
AIによる自動的なアウトプットは、それ以前を思い返すと革命的な変化でした。コードだけでなく、要求の整理や設計の段階から手伝ってもらえる。これまで時間をかけて書いていたものが、短い時間で形になるのですから、使わない手はありません。
ただ、大量の設計書を書いてもらったあとには、読む仕事が待っています。内容は正しいか。作りたかったものになっているか。大事なことが抜けていないか。これを確かめるには、やはり人間が理解しなければなりません。
作る側が速くなったぶん、受け取る側の大変さが目立つようになってきた。いま起きているのは、そういうことなのだと思います。
「ちゃんと読んでください」で済むだろうか
設計書が長くなれば、読む時間がかかります。しかも、最初から最後まで目を通せば、それで確認が終わるわけではありません。
「この要求は、どの機能で実現するのか」「さっきの説明と、ここの条件は合っているのか」。そんなことを考えながら、前のページに戻ったり、別の資料を開いたりする。読んだ内容を覚えておき、それぞれを頭の中でつなぎ合わせる必要があります。
情報が増えるほど、この作業は苦しくなります。最初は丁寧に確かめていても、だんだん「そこまで読んでいられない」という気持ちになってくる。文章は整っているし、説明もそれらしい。ならば、いったん進めてしまおうか、と。
タイトルに「理解できない（しない）」と書いたのは、この二つが地続きだと感じるからです。理解するのに手間がかかりすぎると、そのうち理解しようとすることをやめてしまう。本人は読んだつもりでも、あとから説明しようとすると、何となくしか分かっていなかったことに気づきます。
この状態で開発を進めると、基本的な抜け漏れも、そもそもの前提の取り違えも見逃しかねません。とくに上流設計や評価・テストでは、何を作り、何を確かめるべきかを見誤ると、その後の工程にも響いてきます。
経験の浅いエンジニアであれば、何を疑って読めばよいか、その手掛かりもまだ少ないでしょう。AIが書いたものを受け入れ続けているうちに、自分で考え、判断する経験まで減ってしまわないか。育成という意味でも、気になるところです。
だからこそ、「AIの出力はちゃんとレビューしましょう」と呼びかけるだけでは、足りないのではないかと思っています。
人間が理解し、他の人と認知を合わせ、決めるために
では、AIに多くを任せられるようになったとき、人間は何を引き受けるのでしょうか。私は、次の三つが最後まで大事になると考えています。
- 理解すること
- 他の人と認知を合わせること
- 意思決定すること
AIに説明してもらうことはできます。でも、その説明を自分が理解したかどうかは、また別の話です。同じ説明をみんなが読んだからといって、同じように理解したとも限りません。そして、選択肢を比べてもらったとしても、どれで進むかは、自分たちで引き受ける必要があります。
ここでいう「認知を合わせる」とは、何が起きていて、何が課題で、どんな前提で考えているのかを、お互いに確かめることです。同じ言葉を使って話していても、頭に思い描いているものが違うことはあります。その違いに気づかないまま「これでいこう」と決めると、あとから「そういうつもりではなかった」が出てきます。
そう考えると、AIが何を出力するかと同じくらい、人間がそれをどう受け取るかが気になってきます。
大量の文章を渡されて、「あとは読んで判断してください」ではつらい。理解しやすく、お互いの捉え方も確かめやすく、そのうえで判断できる形があるのではないか。
コーディングエージェントのアウトプットと人間との間に、どんなインターフェースを用意するか。ここが、これからのソフトウェア開発で考えていきたいことの一つです。
読むときにはよくても、話し合うときには困る
たとえば、Markdownの仕様書に代えて、図や画像を含むHTMLを作ってもらう方法があります。画面のイメージや処理の流れが見えるだけでも、文章を追うより分かりやすくなることはあります。
ただ、見やすくなっても、確認する情報の量は変わりません。それに、読むために書き出された資料は、話し合いながら手を入れようとすると、案外扱いづらいものです。
一人で読んで判断するなら、それでもよいかもしれません。けれど、実際の設計では、プロダクトマネージャーやプロジェクトマネージャー、他チームのメンバーなどと相談しながら決める場面があります。
「この二つの要求は、まとめられそうですね」
「ここを変えるなら、あちらも見直さないと」
「今回はこの部分までにしましょう」
こんな話が出たとき、目の前の資料も、その場で変えられたらどうでしょう。まとめてみる。つなぎ直してみる。今回の対象を囲んでみる。変更したものを眺めて、「あ、それだと困ることがある」と気づいたら、また直す。
話がまとまってから誰かが資料を修正するより、その場で一緒に変えた方が、確かめられることは多そうです。「いまの話は、こういう意味ですね」と、目の前のものを使って確認できる。そうやって認知を合わせながら、最後に「では、これでいこう」と決められる進め方をしたいのです。
設計にも、地図のようなものがほしい
そこでいま取り組んでいるのが、構造化ツールを使うことで、理解の負担を減らせないか、ということです。
構造化では、情報を一つひとつ扱える形にして、関係のあるものをつなぎ、まとまりを作ります。細かな情報をまとめて、少し大きなくくりで捉えることもします。こうすることで、詳細を全部読まなくても、まず全体がどうなっているかを見渡せるようにしたいと考えています。
世界地図を思い浮かべると、近いかもしれません。
世界地図には、すべての道路や建物が描かれているわけではありません。それでも、どこに何があり、お互いにどういう位置関係にあるかは分かります。ある場所を詳しく知りたくなったら、その地域の地図を見る。最初から全部の細部を知らなくても、全体をつかむことはできるのです。
設計でも、まず「全体はこうなっていて、今回の話はここに当たる」と分かるものがほしい。そこから、必要なところを詳しく見ていく。そのように読めれば、頭の中だけで全体像を組み立て続ける負担は軽くなるのではないでしょうか。
そして、その地図をデジタルツール上で一緒に直せれば、自分が理解することも、他の人と認知を合わせることも、同じ場所で進められます。
「私は、この二つは同じまとまりだと思っていました」
「なるほど。私は別々に考えていました」
そんな捉え方の違いも、実際に動かしてみると話しやすくなります。言葉だけでは伝えにくかったことを、つなぎ方やまとめ方として表せるからです。
つなげる、まとめる、抽象化する。こうした操作は、人が頭の中で考えを整理するときのやり方に近いと感じています。自分がどう理解しているかを外に出せるからこそ、他の人との違いにも気づき、認知を合わせやすくなるのかもしれません。
このあたりは、いずれメンタルモデルに関する研究なども読みながら、掘り下げたいところです。いまはまだ、「構造化すれば認知負荷を下げられるのではないか」という仮説として取り組んでいます。
全体が見えたら、次は「どこを押さえるか」
ただ、全体を見渡せるようになれば、それで十分かというと、もう一つ考えたいことがあります。どこを重要だと考えて見るか、です。
経験のあるエンジニアと設計の話をしていると、「今回は、そこを外してはいけない」という勘所を押さえていると感じることがあります。細部を全部同じように調べるのではなく、そのシステムで何が問題になりそうか、どの前提が崩れるとまずいかを見極めている。
ここで大事になるのが、観点だと思っています。どんな点に着目して設計するのか、何を確かめるつもりでレビューするのか、ということです。
アウトプットが大量になるほど、この観点の持ち方が効いてくるはずです。重要な観点が分かれば、詳しく確かめるべきところも見えてきます。反対に、それが分からないままでは、長い設計書をどこからどう読めばよいか、途方に暮れてしまいます。
この観点を見つける作業にも、構造化を使えないでしょうか。
情報をつないでみたら、見落としていた関係に気づく。いくつかの懸念を並べてみたら、実は同じ問題を気にしていると分かる。全体を眺め直したら、「今回、まず確かめるべきなのはここだ」と絞れる。そういうことができそうだと考えています。
AIに観点をたくさん出してもらうのもよいでしょう。ただ、百個のチェック項目が並んで、また「全部は読めない」となってしまっては困ります。洗い出すところから、共通するものを取り出し、重要なものへ絞っていくところまで、扱いたいのです。
この過程を一緒にたどれれば、経験の浅いエンジニアにも、完成した設計書だけでは伝わらないことを共有できると思います。なぜそこが気になったのか。何と何を照らし合わせたのか。どうして、その仕様でよいと判断したのか。そうした考え方に触れることが、次に自分で判断するときの手掛かりになるはずです。
Balusで、これから確かめたいこと
私たちが開発しているBalusでは、こうした問題意識から、AIと構造化を組み合わせることに取り組んでいます。
AIが出した大量の情報を、まず全体としてつかめるようにする。それをみんなで触りながら、お互いの理解を確かめ、認知を合わせていく。その中で、大事な観点を見つけ、判断につなげる。そんな使い方ができないかと考えています。
もちろん、構造を作るにも手間はかかります。何でも図にすればよいわけではありませんし、図ができたことで、また分かった気になってしまう可能性もあります。どんな場面で、どのように使えば役立つのかは、具体的に確かめていく必要があります。
AIが書く量に合わせて、人間がいつまでも読む量を増やし続けるのは難しいでしょう。だから、理解し、他の人と認知を合わせ、意思決定するためのやり方を、道具も含めて考え直したい。
当面はこのテーマを、小さな設計の例も使いながら書いていくつもりです。なかでも、経験のあるエンジニアが押さえている「ここが大事だ」という観点を、どう見つけ、どう共有できるか。そこを、じっくり掘り下げてみたいと思っています。