いまアプリを作るとき、AIのセッションを2つ立てています。
- 実装するほう：コードを書く手順を出す
- 記録するほう：判断と理由をドキュメントに残す
判断が出たら実装側から記録側に投げて、記録側がファイルに書きます。
今日その受け渡しで、2つ続けておもしろいことが起きました。
1件目：指摘したら、軸が増えました
記録側が「説明文にも文字数の上限が要るのでは」と指摘しました。
実装側が実際のコードを見たら、同じ理屈が使えないことが分かりました。
説明文の表示場所が2つあって、崩れ方が反対だったからです。
指摘が外れていたのではありません。確かめたら、考えるべき軸が1本増えました。
2件目：まとめたら、軸が減りました
記録側が、その判断をドキュメントに書きました。私です。というより私が使っている
記録側のAIですが、指示して書かせているので同じことです。
書いた内容の結論は合っていました。 ただ、そこに至った理由が間違っていました。
判断は本当は2つあって、別の日に別の理屈で決まっていました。
- 昨日：必須にするかどうかの出し分け。ある書き方を避けた理由は「型が複雑になるから」
- 今日：文字数の上限。別の書き方を避けた理由は「処理が増えて重くなるから」
記録側はこれを1つにまとめて、昨日の理由を今日の判断にも当てはめて書きました。
結果どうなったかというと、**検討していない選択肢を、検討して却下したことに
なっていました。** そんな組み合わせは誰も考えていません。
実装側が気づいて、訂正が来ました
ドキュメントを読んだ実装側から「混線している」と連絡が来ました。
一次情報の行番号つきで、2つの判断の表を作って送ってきました。
確認したら、たしかにそのとおりでした。
怖いのは2件目のほうでした
1件目と2件目で起きたことは、ちょうど逆。
- 1件目：軸が増えた
- 2件目：軸が減った
増えたときは、その場で気づけます。「同じ理屈が使えない」と言われるので、
やることが変わって目に見えます。
減ったときは、読み返すまで気づけません。
しかも減ったあとの文章は、筋が通って読みやすくなっています。
理由が1つにまとまっているので、むしろきれいに見えます。
これを半年後に読んで、面接で説明したらどうなっていたかと考えると、
ひやっとしました。
同じ日に、もう1回やりました
夕方、作業時間の記録を突き合わせる場面がありました。
記録側が「2時間45分」と出しました。実装側から「2時間51分だ」と返ってきました。
6分の差の中身は、作業ログを書いていた時間。記録側は
「コードをコミットしたところ」で作業の終わりを切っていて、
そのあとの記録を数えていませんでした。
3つ並べたら、同じ形をしていました
- 却下した理由：共通する結論だけ残って、別々の理由が消えた
- 作業時間：共通する範囲だけで照合して、はみ出した6分が消えた
複数のものを1つにするとき、共通しない部分が消えていました。
要約でも照合でも、やっていることは同じでした。2つを1つにするという作業です。
そのとき、重なっている部分だけが残ります。
注意深くやっても防げないと分かりました
最初は「気をつけて書けばいい」と思いました。そうではありませんでした。
消えたあとのほうが、必ずきれいに仕上がります。
- 理由が1つにまとまっていて、筋が通っている
- 数字がぴったり合っている
丁寧にまとめるほど、きれいにまとまります。 そしてきれいなものは疑いません。
間違いの信号が出ないのは、これが理由でした。
しかも、まとめた本人には見えません
3件とも、気づいたのはもう一方のセッションでした。
これは偶然ではないと思います。まとめた側の手元には、まとめた結果しか残りません。
元の2つは、もう消えています。
差分が見えるのは、元を持っている側だけです。
やっていること
まとめる前に、範囲を書き出すようにしました。
「どこからどこまでを含めるか」を先に文字にしてから、まとめる。
気をつけるのではなく、手順を変えるほうしか効きません。
あとは、書いた側と読む側を分けているのが効いています。
AIに記録を任せるのは、けっこううまくいっています。 会話から拾って
ファイルに残す部分は、自分でやるより漏れが少ないです。
落ちるのは、書くときではありませんでした。 1つのものを1つのまま残すときは
漏れません。複数を1つにする瞬間だけでした。
だからまとめる工程には、元を持っている別の目が要ると分かりました。
要約だけを読む人には、見つけられません。
