ソフトウェアエンジニアの仕事では、Slack、GitHub、Issue、設計書など、テキストによるコミュニケーションが大きな割合を占める。
しかし、こんな経験はないだろうか。
- 質問したのに、知りたいことへの回答が返ってこない
- 言っていないことまで主張したことにされる
- 話しているうちに論点がずれていく
- 最終的に、何について議論していたのか分からなくなる
筆者は何度も経験してきた。一方で、こうした問題がほとんど起きない人もいる。
（もちろん、私が原因でこのような問題が発生するケースも多くある。反省の毎日である。）
その違いを考えていくと、テキストコミュニケーションにはいくつか基本的な能力があるように思う。
本記事では、それを5つに整理する。
結論
先に結論から言うとこの5つだ。
- （１）幹と枝葉を理解する
- （２）質問に直接回答する
- （３）論点を維持する
- （４）事実・推測・意見を区別する
- （５）相手の主張を勝手に拡張しない
ポイント1: 幹と枝葉を理解する
会話には、中心となる話題と、それに付随する細かな話題がある。
例えば、次のような質問があったとする。
このAPIのレスポンスが遅いため、インデックスの追加で改善できるか確認してほしい。
この場合、幹は「インデックスの追加によってレスポンスを改善できるか」である。
一方、次のような内容は枝葉にあたる。
- APIの命名が適切か
- レスポンスの型を変更した方がよいか
- 使用しているライブラリが古いか
- コードの書き方に改善の余地があるか
もちろん、枝葉にも重要な問題はある。しかし、それを先に話し始めると、依頼した側は「インデックスで改善できるのか」という答えを得られない。
実際の開発では、調査中に別の問題を見つけることも多い。その場合は、まず幹について回答し、その後に別の問題として伝える。
実行計画を確認したところ、対象カラムにインデックスが使われておらず、追加による改善が見込めます。
なお、調査中にレスポンス生成部分でも不要な処理を見つけました。こちらは別件として対応を検討した方がよさそうです。
この順番なら、元の質問へ回答しながら、新しく見つけた問題も共有できる。
枝葉の話をしてはいけないわけではない。幹への回答を置き去りにしないことが重要である。
ポイント2: 質問に直接回答する
質問に関連する話をしていても、質問そのものに答えていないことがある。
例えば、次のようなやり取りである。
質問：この変更は今日中にリリースできますか？
回答：テスト環境では動いています。
テスト環境で動いていることは判断材料にはなるが、「今日中にリリースできるか」への回答にはなっていない。
回答するなら、最初に結論を置く。
今日中にリリースできます。テスト環境での確認は完了しており、残っているのは本番反映だけです。
難しい場合も同様である。
今日中のリリースは難しいです。テスト環境では動いていますが、権限周りの確認が終わっていません。明日の午前中までに確認し、問題がなければ午後にリリースできます。
「はい」「いいえ」で答えられる質問なら、原則として最初に「はい」「いいえ」を答える。その後に理由や条件を説明する。
質問の前提に問題がある場合も、回答を飛ばして前提だけを訂正すると話が噛み合わなくなる。
質問：この障害はデータベースの負荷が原因ですか？
回答：そもそも、このシステムではMongoDBを使っています。
これは用語の訂正しかしておらず、原因について答えていない。
いいえ、現時点ではデータベースの負荷が原因とは考えていません。MongoDBのCPU使用率とクエリ時間に大きな変化がないためです。
このように答えれば、質問への回答と根拠がセットになる。
すぐに判断できない場合は、無理に結論を出す必要はない。
現時点では判断できません。MongoDBのメトリクスと該当時間帯のクエリログを確認すれば切り分けられます。
「分からない」も、質問に対する有効な回答である。分からない状態を隠して周辺情報だけを返す方が、やり取りを長引かせる。
ポイント3: 論点を維持する
議論では、途中から別の論点が混ざることがある。
例えば、コードレビューで次の指摘をしたとする。
この実装では、異なるユーザーのリクエストを並列に処理したときにデータが混ざる可能性があります。
これに対して、
既存のテストはすべて通っています。
と返されても、並列実行時の安全性については確認できない。
さらに、
そもそも、この処理を実装したのは私ではありません。
となれば、論点は実装の安全性から責任の所在へ移っている。
テストが通っていることや、誰が実装したかが無関係とは限らない。しかし、最初に確認しているのは「並列実行時にデータが混ざるか」である。
論点を維持するには、現在何を確認しているのかを言葉にするとよい。
既存テストが通っていることは確認しました。ただ、現在の論点は並列実行時のデータ競合です。このケースを検証するテストはありますか？
話題を追加する場合は、元の論点と分ける。
並列実行時の安全性については、追加テストが必要です。
それとは別に、この処理の担当範囲についても整理したいです。
テキストでは、複数の論点を同時に扱うほど話が崩れやすい。長いやり取りになった場合は、論点を番号で分ける方法も使える。
現在の論点は次の2点です。
- 並列実行時にデータが混ざらないか
- 追加テストを誰が担当するか
まず1について、現在の実装で安全だと判断できる根拠を確認したいです。
議論が長引いているときほど、新しい説明を追加するより、今の論点を再確認した方が早く進むことがある。
ポイント4: 事実・推測・意見を区別する
テキストでは、書かれている内容が事実なのか、書き手の推測なのかが分かりにくい。
例えば、次の文章がある。
このAPIはデータ量が増えると遅くなります。
実測した結果なのか、実装を見たうえでの予想なのか、単なる懸念なのかが分からない。
事実と推測を分けると、次のようになる。
現在の検証環境では、1万件のデータに対して平均200msで応答しています。
対象カラムにインデックスがなく、全件走査になっているため、データ量の増加に伴って遅くなる可能性があります。
前半は計測した事実で、後半はその事実と実装に基づく推測である。
意見を述べる場合も、意見であることを明確にする。
現時点で障害は起きていませんが、本格利用前にインデックスを追加した方がよいと考えます。
ここで「追加した方がよい」は判断であり、事実ではない。
区別するときは、次のような表現が使える。
- 確認できている事実：ログでは、実行に3秒かかっている
- 推測：外部APIの応答待ちが原因と思われる
- 未確認事項：外部API側の処理時間は確認できていない
- 意見：タイムアウト時間を延ばす前に、原因を切り分けるべきだと考える
すべての文章にラベルを付ける必要はない。ただし、障害調査、技術選定、見積もり、スケジュールなど、判断に影響する場面では区別した方がよい。
推測を事実のように書くと、その推測を前提に次の判断が進む。後から間違いが分かっても、どこから見直せばよいのか分からなくなる。
ポイント5: 相手の主張を勝手に拡張しない
相手が言っていないことを補って解釈すると、議論が別の方向へ進む。
例えば、次の意見があったとする。
この処理にキャッシュを入れる必要はないと思います。
これに対して、
性能改善を一切しなくてよいということですか？
と返すのは、元の主張を拡張している。
相手が言っているのは「この処理にキャッシュは不要」であり、「性能改善は一切不要」とは言っていない。
正確に確認するなら、次のように聞く。
キャッシュ以外の方法で改善する想定でしょうか。それとも、現状の性能で要件を満たしているという判断でしょうか。
別の例を挙げる。
この機能は今回のリリース対象から外した方がよいと思います。
この発言に対して、
この機能自体が不要だと言っているのですか？
と解釈するのも拡張である。
「今回のリリースから外す」と「機能自体を廃止する」は別の主張だ。
相手の発言に曖昧な部分があるなら、自分で空白を埋めずに確認する。
「今回のリリースから外す」というのは、次回以降へ延期するという意味ですか？
テキストでは表情や声の調子が伝わらないため、書かれていない意図を推測しやすい。特に意見が対立している場面では、強い意味へ拡張して受け取ってしまうことがある。
しかし、推測した主張に反論しても、相手はその主張をしていない。議論が成立しないまま、訂正のやり取りだけが増えていく。
まずは、書かれている範囲をそのまま扱う。補足が必要なら質問する。それだけで、不要な対立の多くは避けられる。
5つは独立していない
ここまで5つに分けたが、実際には互いに関係している。
質問へ直接答えずに周辺の話を始めれば、幹と枝葉が入れ替わる。推測を事実として扱えば、その誤った前提から論点がずれていく。相手の主張を拡張すれば、実際には誰も主張していない内容について議論することになる。
やり取りが噛み合わないときは、文章の長さや言葉遣いよりも、次の点を確認した方がよい。
- 元の質問に回答しているか
- 現在の論点は何か
- 事実として確認できている範囲はどこまでか
- 相手が実際に書いた内容と、自分の解釈を混ぜていないか
- 新しい論点を追加する前に、元の論点を処理したか
丁寧な文章を書いていても、これらが崩れていれば意思疎通は難しい。反対に、短い文章でも構造が整理されていれば、必要な情報は伝わる。
実際に書くときの順番
SlackやIssueで回答するときは、次の順番にすると整理しやすい。
- 質問への回答
- 回答の根拠
- 未確認の事項
- 必要な次の行動
- 元の質問とは別の補足
例えば、次のように書く。
今日中のリリースは難しいです。
結合テストで権限設定に関する不具合が1件残っており、修正後に再確認が必要なためです。
修正自体は本日中に完了する見込みですが、確認は明日の午前中になります。
問題がなければ、明日の午後にリリースします。
なお、今回とは別に監視設定の不足も見つかったため、別Issueを作成します。
最初の一文で質問に答え、その後に理由と予定を説明している。最後の補足も、元の論点とは別であることが分かる。
毎回この形式に固定する必要はないが、回答が複雑になったときの基準として使える。
まとめ
テキストコミュニケーションでは、文章を丁寧に書くだけでは不十分である。
必要なのは、話の中心を捉え、聞かれたことへ答え、論点を保つことだ。そのうえで、確認できている事実と自分の推測を分け、相手が述べていない主張を付け足さない。
今回挙げた5つを改めてまとめる。
- 幹と枝葉を区別し、まず中心となる話を処理する
- 質問には結論から直接回答する
- 別の話題を混ぜず、現在の論点を維持する
- 事実・推測・意見を区別して書く
- 相手の発言を、書かれている範囲を超えて解釈しない
会話が噛み合わなくなったとき、相手の理解力や態度を原因にしても議論は進まない。まず、質問、回答、事実、推測、論点を分解する。
テキストには記録が残る。どこで話がずれたのかを後から確認できる点は、口頭よりも扱いやすい。
正確に書き、書かれた内容を正確に読む。この二つを揃えることが、テキストで仕事を進めるための基本になる。
コメントを残す