そもそも雑な相談とは

例えば

「注文確認画面で金額が1円ずれるんだけど、どう直したらいい？」
「本当は一度しか呼ばれないAPIが複数回叩かれてるっぽい。原因って何？」

みたいなもの。
相談者は該当処理のコードや仕様をある程度触っていて、受け手はほぼ初見。

こう言った状態を加味せずに同じ景色が見えていると思い込み、
情報の差分を埋める意識が抜け落ちた状態で相談することを
私は雑な相談と定義しています。

なぜ避けるべきか

まず、一番わかりやすいものとして時間の浪費があります。
情報が足りない相談が飛んできても、受け手は「何が起きているのか」を掘り起こすところから始める必要があるため

「フロントだけで起きる？」「再現は毎回できる？」「ログは仕込んだ？」と何往復も質問が
続くうちに、大きく時間を使ってしまいます。

次に品質面のリスクで、雑な相談は前提が共有されないまま議論が進むことがあり、
受け手が誤った仮説を立て、本質的な原因にたどり着くことがなく、誤った回答を行なってしまう可能性があります。

これでは相談した意味がありません。

雑な相談が生まれる仕組み

根本には前述した情報のギャップが大きく関わっていると思います。
相談者は目の前のコードと仕様が頭に入っていて、受け手も同じ景色を見ている（だろう）とつい錯覚する。

さらに人間なので、相談者と受け手で情報ごとの「重要度の判断」というものは多少異なります。
そこで省かれた情報の重みも食い違う。

また「詳しい人なら一発で答えが返ってくるだろう」という謎の幻想も拍車をかけていき
ギャップがギャップを呼び、雑な相談が誕生するわけです。

雑な相談を投げないためのコツ

私は脳内に仮想上司を置き、セルフ問答をしてから相談を持ち込むようにしています。

相談者「注文確認画面で金額が1円ずれるんだけど、どう直したらいい？」
仮想上司「それはフロントとバックエンドのどちらで起きている？　まずログは確認した？」
相談者「してない……ログを一度調べよう！」

ログを眺めて情報が増えると、次の問いが返ってくる。

仮想上司「具体的にどの処理が怪しそう？」
相談者「まだ分からない……じゃあその関数の実装を読もう！」

やり取りを繰り返してどこからが自分の限界で、
どこから先が他者の知恵を借りたい部分なのかを事前整理しておく
こうすることによって問いの解像度が格段に上がります。

最初の相談を例にすると

「注文確認画面で金額が1円ずれるんだけど、どう直したらいい？」

整理後 ↓

「注文確認画面で金額が1円ずれます。
リリースブランチのみ再現してフロントのネットワークタブでは計算結果が正しいです。
バックエンドのアクセスログには差分がありました。調査方針を一緒に詰めてください。」

みたいな。

後の方が仮説を立てやすいですよね。
相手の時間を使っているわけなのでこれくらいは欲しいところです。

慣れていない人だと、これを律儀に毎回フルコースでやると、
相談そのものが遅くなる危険性もあります。

この場合は「ここから先は一人でやっていたらコストがかかりすぎる」と
判断して途中で情報整理→相談に切り替えることもアリです。

限界に感じた段階で、今持っている情報整理に入り相談することも、重要なのです。

雑な相談を投げられたときのお作法

まず、嫌そうな顔をしない。

超大事です。私は二日酔いの時、あんまり守れてないかも。

それは置いておいて、雑でも「困ってる」事実は変わらないので
「いまの情報だと判断むずいかも。もう少し教えて～」と切り替えてあげる。

質問の仕方ですが、足りていない情報を少しずつ、小出しにして質問していきましょう。
小出しにする理由としてラバーダッキング法で、相手の頭を整理させつつ情報を拾う狙いがあります。

質問自体が調査ロードマップになるように投げるのがおすすめです。

相談中、色々なことを話してると相手の中で「結局なにがどうなったんだっけ？」となることもあります。
一度、伝えたとしても最後にもう一度「今わかってること」「仮説」「次にやるべきこと」を
サッとまとめて伝えてあげましょう。

情報が多いときはテキストで送ってあげると、相手もあとで確認しやすいし親切です。

おわりに

相談するなら、相談を受けるなら、互いの時間を尊重しつつ最短距離で「うまくいった！」に
たどり着きたいものです。いつでも建設的な対話を目指したいものですね。