あなたたちはもっとたくさん質問すべきです
筆者は、誰かの説明を聞くとき平均 30 秒に 1 つ質問する。それで誤解を早く見つけられるからだ。頭の中で実装を予行演習するのも同じ理由で、書く前に設計の穴が見える。
日本語
コピー
人に何かを説明してもらっているとき、私は平均して30秒に1回は質問する。それがうっとうしいと感じる人もいるのは分かっている。でもこれは良い習慣だし、あなたもそうすべきだ。
理解しようと努める
私の質問のほとんどは短く、答えも短い。たいていは確認だ。「Xと言ったとき、Yのことですか」とか、「このXは、さっきZと言ったときのあれと同じものですか」といった具合に。こうした質問をするのは、自分が正しく聞き取れているかを確かめるためだ。
最初の小さな誤解は、後になるほど大きな誤解へと膨らんでいく。最初の誤解に基づいて読み違えたすべてが、それぞれ新たな誤解になり、それが幾重にも積み重なっていくからだ。だから相手が話し終えるのを待って、まとめて質問しようとしてはいけない1。
多くの人が質問しないのは、本当に理解したいと思っていないからだと思う。話し相手は自分が何を言っているか分かっているはずだと、信じていたいのだ。相手が尊敬すべき人物だったり、自分より年次の高いエンジニアだったりすると、この傾向は強くなる。しかし当事者意識を持った瞬間、話は変わる。成否の責任が自分にあり、話が終われば具体的な行動を山ほど実行に移さなければならない——そういう立場に立つと、聞きたいことが次々と出てくるのが分かるはずだ。
頭の中で組み立てる
仕事で誰かが私に設計案を説明するとき、私はたいてい頭の中でそれを組み立てる。実現するにはどんなコードを書く必要があるか、具体的な行を思い描くのだ。すでに解決済みの問題については、細部を省くこともある（たとえば「同じサービス内でメールも送っているXサブシステムと同じようにメールを送る」といった具合に）。それでも、少なくとも次の点ははっきりさせる。
- サービス間でデータがどう流れる必要があるか（どんなデータで、それがネットワークをどう通るか）
- サービス同士がどう通信するか（たとえば認証はどうやるのか）
- どのデータを永続化する必要があり、どこに置くのか
怪しいほど曖昧な説明を聞いたら（たとえば誰かがサービスXを「データを保存する」と説明したのに、私の知る限りサービスXは一時的なRedisストアしか扱っていない、といった場合）、すぐに聞く。「待って、それってどうやって動かすの？」たいていは依存関係の抜けが見つかる（たとえばサービスXはサービスYにRPCを投げる必要があり、永続化データベースを持っているのはサービスYだけ、といった具合）。そしてそれは往々にして設計の変更を意味する（機能の一部または全部をサービスYに移す、など）。
こうした質問が、設計の中の根本的に動かない機能を暴くこともある。よくあるのは、ある案が厄介な特性を考慮していない場合だ。何年も前のこと、隣のチームが複雑なイベント駆動システムを組んだ。とてもエレガントだったが、顧客データを単一のデータセンターに隔離することがまったくできなかった。我が社の看板機能は「あなたのデータはすべて同じ場所に保管されます」だったから、このシステムは使いものにならず、結局事実上お蔵入りになった。
何らかの形で技術的なリーダーの立場にいるなら、この作業はいずれやることになる。早ければ早いほどいい——つまり、誰かが案を説明しているその会話の中でやるのがいい——そうすれば何時間、ときには何日もの無駄な実装を省ける。多くの場合、それだけで失敗するプロジェクトを成功するプロジェクトに変えられる。
AI agent と協働する
信頼できるエンジニアとしか仕事をせず、正しい判断をすべて任せられるなら、話を最後まで遮らずに聞けばいい。自分が細部まで理解しているかどうかは、実は重要ではないからだ。それは素晴らしいことだ。だが今どきは、生まれつき信頼できない同僚もいる——AI agent だ。
私は主に GPT-6-Astra と Claude Opus 5.5 を使っている。どちらも優れたモデルで、コード のミスはあまりしない。やろうとしたことは、たいていやり遂げる2。だが設計のミスは繰り返す。2つのサービスが通信できると思い込むが、実際にはできない。自分のコードがクラウドでもローカルでも動く必要があるのを忘れる。などなど。主な原因は継続的な学習の欠如だ。こうしたことは、あなたも入社初日には分からなかったが、少しずつ学ぶ時間が山ほどあった。言語モデルは永遠に初日のままだ。
AI agent には容赦なく質問を浴びせるべきだ。私がよく聞くのはこういうものだ。
- このコードベースの他の場所で、Xをやっているところはある？
- サービスYは本当にこの認証方式をサポートしている？それとも、自分たちで一から作る必要があると仮定している？
- あなたが作ったこのサブシステムは、要件Zを満たすのに必要なもの？それとも、あなたが仮定した別の要件を満たしているだけ？
- なぜAのインターフェースを変える必要がある？
- なぜこのファイルに手を入れる必要がある？今回の変更とは関係ないのでは？
いつか、こうした質問すべてにまともな答えが返ってきて、モデルが何をしているか分かっていると信じられる日が来るかもしれない。だが今日ではない。私が聞く質問のおよそ半分は、モデルが間違っていると確信させる3答えを返してくる。Xの既存サブシステムを再利用すべきだったとか、Yの認証は別のやり方にすべきだったとか、Zの実装はもっとシンプルに保つべきだったとか。そうならなくなったら、私も質問をやめるだろう（そしておそらく、会社がもっとアーキテクト的な役割に金を払い続けるかどうか、考えることになる）。
最後に
あなたはもっとずっと多く質問すべきだ。言い換えれば、聞いたことを本当に理解しようと、もっと努力すべきだ。相手（あるいはAIモデル）が自分より賢いからといって、その人が何をしているか分かっていると信じてはいけない。複雑なソフトウェア製品を誰も本当には理解していない。コードベースのある領域について深い専門知識があれば、強力なAIモデルや principal engineer を自分が正す場面に、しょっちゅう出くわすはずだ。