コードを頼むとき「一番良い方法」ではなく、選択肢を出させる

• 頼めば1つの方法が返るが、それが唯一ではない
• 選択肢と、それぞれの短所を出させる
• 自分の状況に合うかは、こちらしか判断できない

「こうしたい」と頼むと、方法が1つ返ってくる。動くので採用していたが、他に簡単な方法があったと後から知ることが続いた。

1つしか返らない理由

こちらが1つ求めているからだ。「方法を教えて」と聞けば、方法が1つ返る。

複数あることは示されない。聞かなければ、選択肢の存在自体が見えない。

選択肢を求める書き方

こう頼むようにした。

この目的を達成する方法を、3つ挙げてください。
それぞれについて、次を書いてください。
- どういう方法か（2行）
- 向いている場面
- 短所や注意点
- 実装の手間（軽い/普通/重い）

おすすめは最後に書いてください。

最後の1行を入れるのが要点だった。最初に結論を書かれると、残りを読まなくなる。

短所を聞くのが効く

一番役に立つのが短所の欄だった。

• 「後から変更しにくい」
• 「件数が増えると遅くなる」
• 「外部のサービスに依存する」

どれも、聞かなければ出てこない。提案する側は、提案したものの欠点を自発的には書かない。

手間の目安を聞く

実装の手間が分かると、判断しやすい。

• 軽い方法で足りるなら、それでよい
• 重い方法は、本当に必要か考え直す
• 手間と効果が釣り合うかを見る

2つ目で引き返したことが何度かある。立派な作りにする必要がない場面は多い。

自分で判断する部分

選択肢が出ても、選ぶのはこちらだ。見ている点を書く。

• 自分が理解できる範囲か。壊れたとき直せるか
• 後から変える可能性があるか
• 他の部分と作りが揃うか

1つ目を最優先にしている。理解できない方法は、優れていても自分には向かない。

比べたうえで聞き返す

選択肢が出た後、こちらから条件を足して聞き直すこともある。

• 「後から変更する可能性があるなら、どれがよいか」
• 「自分で保守する前提なら、どれがよいか」
• 「件数が10倍に増えたら、どれが耐えるか」

条件を変えると、おすすめが変わることがある。最初の提案は、こちらが言っていない前提の上に立っているので、前提を変えて聞き直すと見え方が変わる。

既存のやり方に合わせる

サイトに既にある書き方と揃えるよう頼んでいる。

既にあるコードと書き方を揃えてください。
参考として、既存のこの部分を貼ります。
（既存のコード）

揃っていないと、後から見たときに混乱する。最適な方法より、揃っている方法のほうが保守しやすい。

やらない選択も聞く

方法を聞く前に、そもそも必要かを問うこともある。

• 「この機能は本当に必要か、別の解決はあるか」
• 「既存の仕組みで代替できないか」
• 「作らずに済ませる方法はあるか」

3つ目で済むことがある。作らないのが一番安いという結論は、聞かないと出てこない。

提案が大げさなときの見分け方

必要以上に複雑なものが返ることがある。見分けの手がかりを挙げる。

• 自分が説明できない部品が、複数含まれている
• いまは使わない場合への対応が、先回りして入っている
• 設定ファイルや準備の手順が、本体より長い

2つ目がよくある。将来の拡張に備えた作りは、その将来が来なければ無駄になる。「いまの用途だけに絞って、最小限で」と頼み直すと、ずっと短いものが返ることが多い。

記録に残す

選んだ理由を1行書き留めている。

• どの方法を選んだか
• 他の選択肢は何だったか
• なぜそれを選んだか

数か月後に見直すとき、当時の判断基準が分かると、変えるかどうか決めやすい。

まとめ

• 1つ聞けば1つ返る。選択肢の存在は見えない
• 短所と手間を一緒に出させると、判断材料になる
• おすすめは最後に書かせる。先に読むと他を見なくなる
• 理解できない方法は、優れていても選ばない
• 「作らずに済む方法」も聞いておく