最初は、どちらが優秀かを調べていた。AIの開発支援ツールをいくつか触りながら、比較記事を読み、どちらを使うべきかを決めようとしていた。
結局、その問いは自分の中で消えた。使っているうちに、効いているのはツールの性能差ではないと思うようになったからだ。効いていたのは、何をどちらにやらせるかを先に決めておくことのほうだった。
いまは、設計と作成をClaude Code、その設計に対するレビューをCodexに任せている。両方使っている。ただし、やらせていることが違う。
そうやって回しているうちに、思っていたのと違うことに気づいた。少なくとも自分の場合は、自分で考えた業務改善の案に、自分では見えない穴が残っていた。しかもそれは、自分でどれだけ念入りに点検しても出てこなかった。
1. 紙の上で18回レビューを受けている
いま、ある現場で毎日使う小さな業務システムを作っている。ただしまだ1行もコードを書いていない。
進め方はこうしている。
– 先に設計書を紙（ドキュメント）の上で作り切る
– 設計をいくつかのまとまりに分けて、1つずつ順番に固める
– 1つ固まるまで、次に進まない
このやり方にした理由は単純で、作ってから間違いに気づくと、直す場所がコードと設計書の2箇所になるからだ。紙の上なら1箇所で済む。
そしてこの設計書を、書いた側とは別のところへ出してレビューさせている。これまでに18回になった。
18回と書くと多く見えるし、実際、途中で「これは終わらないのでは」と思った時期がある。レビューを1回受けるたびに、守るべき条件が増えていったからだ。そのときに気づいたのは、条件が増え続けるのは前進ではなく、検討が発散しているサインだということだった。だから区切り方を変えた（→5章）。
2. 書く役と点検する役を分けた
やらせていることは、はっきり分けてある。
| | やらせていること |
|—|—|
| 書く役 | 設計書を書く。前提を集める。指摘を反映する。関連ファイルの整合を取る |
| 点検する役 | 出来上がった設計書を読んで、穴・矛盾・危ない挙動を指摘する |
これは「性能のいいほうに全部やらせる」の逆だ。分けた理由は、性能ではなく立場のほうにある。
大事なのは、点検する役に、書いた経緯を持たせていないことだ。渡すのは設計書そのものと、前回からの差分だけ。「こういう意図でこう書きました」という説明を渡さない。
説明を添えると、点検する側がこちらの前提ごと受け取ることがある。そうなると、前提そのものを疑う相手がいなくなる。
3. 自分の点検では出てこなかった穴
一度、こういうことがあった。
設計書には「ある操作をしたとき、新しい行を作る」と書いてあった。書いた側の頭では、新しい行なのだから、状態はまっさらな初期値で始まるのが自然だった。
ところが業務の前提を書き留めたメモには、別の場所に「ある条件のときは処理を止める」というルールが、現場に確認済みのものとして記録されていた。
この2つが噛み合っていなかった。止まっているはずのものが、その操作をした瞬間に黙って動き出す設計になっていた。エラーも出ない。誰も気づかない。現場で困ってから初めて分かる類の穴だった。
これを見つけたのは、点検する役のほうだった。
そして正直に書くと、その直前に、自分は32体の検証を並列で走らせていた。4つの観点で見させて、わざと反論させる役も入れていた。それでも1件も出てこなかった。
理由は後から分かった。自分が立てた検証の観点が、全部「文書の内側」で閉じていた。指示の反映漏れ、章と章の矛盾、数の食い違い、相互参照の正確さ。どれも設計書の中だけを見る観点で、設計書の外（業務の前提）と突き合わせる観点が1つも無かった。
自分が組んだ検証は、自分が指示した観点しか見ていなかった。だから盲点も、そのまま引き継がれていた。同じ盲点を32体に配っていただけだった。数を増やしても、観点が自分由来である限り、出てくるものは変わらなかった。
指摘を読んだとき、最初に出てきたのは驚きではなかった。32体が「問題なし」と返した直後だったから、まず浮かんだのは「見落としがあった」ではなく、自分が用意した確認項目そのものが、自分の考え方の範囲の中で作られていた、ということだった。
外から賢い答えが出てきた、という話ではないと思っている。確認の網の目をどこに置くかを、最後まで自分ひとりで決めていた。それだけの話だった。
4. 同じことが、別の場面でも起きた
外部のAIサービスに相談したいことがあり、そのための資料を作ったときのことだ。資料には、特定につながる情報を外し、相談に必要な業務の前提だけに絞って書いた。自分の判断では、出せる状態に見えていた。
渡す前に別役の点検を挟んだところ、3件差し戻された。渡す前に止まったので、外へは出ていない。
そのうち一番効いたのが、過去に自分が公開した文章を、そのまま引用していた箇所だった。情報そのものは既に公開済みだから問題ないと思っていた。ところが逐語で貼ると、検索1回で発信者本人にたどり着けてしまうことがある。そこに紐づいて、資料に書いた、まだ表に出していない検討の中身が、全部その個人の話になる。
「情報単体が公開済みか」と「匿名の前提が崩れるか」は、別の問題だった。
構造は3章とまったく同じだった。分野も作業もぜんぜん違うのに、詰まった場所は同じ。自分の場合、何を前提にしたかは、自分では見えなかった。
5. 試行錯誤の中で決めたこと
重要だったのはツールの数より、役割と視点を分けることだった。決めたのは、ほとんど順番と範囲のことでもある。
1. 書く役と点検する役を、違うところに置く。 自分の手元では、同じ相手の別チャットだと効きが弱かった。前提を共有していない相手のほうが効いている
2. 点検する側に、経緯を渡さない。渡すのは成果物と、前回からの差分だけ。「こう考えました」を添えない
3. レビューの範囲を毎回指定する。 「全部見て」は使わない。直近で渡したのは「前回の指摘が直っているかの確認だけ。全面レビューはしない」だった
4. 指摘は3つに仕分ける。 ①そのまま採用 ②原案は違うが論点は正しい（作り直して採用）③今回は不要（理由を残して却下）。却下した理由を残すと、次に同じ指摘が来たときに二度考えずに済む
5. 回数そのものは気にしない。 18回は多く見えるが、紙の上のやり取りだ。作った後に18回直すのとは、かかるものが違うはずだと思っている
3は、やらなかった時期の反動で決めた。範囲を切らずに回していた頃、レビュー1回ごとに守るべき条件が増え続けた。増えているあいだは前進しているつもりでいたが、実際には終わりが遠ざかっていた。だから「ここまでで凍結」の単位を先に決めることにした。範囲を絞らないと、毎回全部を蒸し返して終わらなくなる。
6. いま分かっていること
まだこのシステムは動いていない。設計が固まりきっていないので、現場で使われてもいない。だから「これで業務が楽になりました」とは書けない。
書けるのは、ここまでで分かったことだけだ。
自分で考えた改善案を、自分で点検しても、穴は出てこなかった。数を増やしても同じだった。出てきたのは、書いた経緯を知らない相手に渡したときだけだった。そしてそれは、道具を2つ用意したから起きたのではなく、役割を2つに分けたから起きたのだと思っている。
これが誰にでも当てはまる作法かどうかは、まだ分からない。稼働していない仕組みの話だし、自分の手元で1回そうだった、という以上のことは言えない。
最後に送ったレビュー依頼には、冒頭に「今回見るのは前回の指摘だけ、全面レビューはしない」と書いた。範囲を書いてから渡す。それが、18回かけてようやく身についたことだった。
AI活用や業務改善について、自社の場合はどこから整理すればよいか。相談をご希望の方は、支援の流れや料金目安をご確認いただけます。
コメント