テキストコミュニケーションで意識したい5つのこと

ソフトウェアエンジニアの仕事では、Slack、GitHub、Issue、設計書など、テキストによるコミュニケーションが大きな割合を占める。

しかし、こんな経験はないだろうか。

質問したのに、知りたいことへの回答が返ってこない
言っていないことまで主張したことにされる
話しているうちに論点がずれていく
最終的に、何について議論していたのか分からなくなる

筆者は何度も経験してきた。一方で、こうした問題がほとんど起きない人もいる。その違いを考えていくと、テキストコミュニケーションにはいくつか基本的な能力があるように思う。

筆者自身が原因で、こうした行き違いを起こすこともある。自戒も込めて、テキストコミュニケーションで意識したいことを5つに整理する。

結論

先に結論から言うとこの5つだ。

（１）話題の幹と枝葉を見分ける
（２）質問に直接回答する
（３）論点を維持する
（４）事実・推測・意見を区別する
（５）相手の主張を勝手に拡張しない

ポイント1: 話題の幹と枝葉を見分ける

会話には、中心となる話題と、それに付随する話題がある。この記事では、中心を「幹」、付随する話題を「枝葉」と呼ぶ。

例えば、次の質問を受けたとする。

このAPIのレスポンスが遅いため、インデックスの追加で改善できるか確認してほしい。

この質問の幹は「インデックスの追加でレスポンスを改善できるか」である。APIの命名、レスポンスの型、ライブラリの古さなども検討対象にはなるが、現在確認している内容とは分けて扱う。

調査中に枝葉の問題を見つけると、そちらへ意識が移り、元の質問への回答が止まることがある。見つけた枝葉は補足や別件として整理し、幹の確認を続ける。

実行計画を確認したところ、対象カラムにインデックスが使われておらず、追加による改善が見込めます。
なお、レスポンス生成部分にも不要な処理がありました。こちらは別件として対応を検討した方がよさそうです。

ポイント2: 質問に直接回答する

質問に関連する情報を返していても、質問そのものへの回答になっていないことがある。

質問：この変更は今日中にリリースできますか？
回答：テスト環境では動いています。

これでは、今日中にリリースできるか判断できない。最初に結論を示し、その後に理由や条件を続ける。

今日中にリリースできます。テスト環境での確認は完了しており、残っているのは本番反映だけです。

難しい場合も同じ順番で答える。

今日中のリリースは難しいです。権限周りの確認が終わっていないため、明日の午前中に確認し、問題がなければ午後にリリースします。

すぐに判断できない場合は、現在の状況と確認方法を伝える。

現時点では判断できません。MongoDBのメトリクスと該当時間帯のクエリログを確認すれば切り分けられます。

ポイント3: 論点を維持する

議論の途中で別の話題が混ざると、最初の確認が未回答のまま残る。

例えば、コードレビューで次の指摘をしたとする。

この実装では、異なるユーザーのリクエストを並列に処理したときにデータが混ざる可能性があります。

これに対して「既存のテストはすべて通っています」と答えても、並列実行時の安全性は確認できない。「この処理を実装したのは私ではありません」と続ければ、論点が実装の安全性から責任の所在へ移ってしまう。

話がずれた場合は、現在の論点を明示する。

既存テストが通っていることは確認しました。現在確認したいのは、並列実行時にデータが混ざらないかです。このケースを検証するテストはありますか？

複数の論点を扱う場合は、番号を付けて分ける。

現在の論点は次の2点です。

並列実行時にデータが混ざらないか

追加テストを誰が担当するか

まず1について、現在の実装で安全だと判断できる根拠を確認したいです。

やり取りが長くなったら、論点を整理し直してから議論を続ける。

ポイント4: 事実・推測・意見を区別する

テキストでは、事実・推測・意見の境界が曖昧になりやすい。

例えば、次の文章だけでは根拠が分からない。

このAPIはデータ量が増えると遅くなります。

計測結果と推測を分けて書く。

現在の検証環境では、1万件のデータに対して平均200msで応答しています。
対象カラムにインデックスがなく、全件走査になっているため、データ量の増加に伴って遅くなる可能性があります。

必要に応じて、情報の種類を明示する。

事実：ログでは、実行に3秒かかっている
推測：外部APIの応答待ちが原因と思われる
未確認：外部API側の処理時間は確認できていない
意見：タイムアウト時間を延ばす前に、原因を切り分けた方がよい

障害調査や技術選定、見積もり、スケジュールなどの判断に関わる場面では、根拠と未確認事項を明確にする。

ポイント5: 相手の主張を勝手に拡張しない

相手が言っていない内容まで補って解釈すると、議論の対象が変わってしまう。

例えば、次の意見があったとする。

この処理にキャッシュを入れる必要はないと思います。

これに対して、

性能改善を一切しなくてよいということですか？

と返すと、「キャッシュの要否」が「性能改善全体の要否」に置き換わる。

意図が分からない場合は、考えられる選択肢を示して確認する。

キャッシュが不要と判断した理由を教えてください。

相手の発言は書かれている範囲で受け取り、判断に必要な情報が足りない場合は質問する。

実際に書くときの順番

ここまでの5つのポイントを実際の回答に落とし込むと、次の順番になる。

質問への回答
回答の根拠
未確認の事項
必要な次の行動
元の質問とは別の補足

例えば、次のように書く。

今日中のリリースは難しいです。
結合テストで権限設定に関する不具合が1件残っているためです。
修正後に権限設定が正常に動作するかは、まだ確認できていません。
本日中に修正し、明日の午前中に再確認します。問題がなければ、午後にリリースします。
なお、今回とは別に監視設定の不足も見つかったため、別Issueを作成します。

最初に質問へ回答し、根拠、未確認事項、次の行動を続けている。元の質問と異なる補足は最後に分けている。

毎回この形式に固定する必要はないが、回答が複雑になったときの基準として使える。

まとめ

今回の5つのポイントを基準にすると、回答の不足や論点のずれを見つけやすくなる。

文章を書くときだけでなく、受け取った内容を整理するときにも使える。やり取りが噛み合わない場合は、どこで認識がずれたのかを一つずつ確認する。