チームの生産性を底上げするコミュニケーション術
誰向けか、何がわかるのか
エンジニアやデータサイエンティストのプレーヤーや、マネージャー（EMもPMも）が、以下のような悩みを解決できる方法を紹介します。
文章やしゃべる量が多くて、何を伝えたいかわからないと言われてしまう、伝わってない感じがする。
逆に、何を伝えたらいいかわからず、後になってから問題が生じ、「報連相しっかりしよう」と言われてしまう。
いつも意図を汲み取るのに時間がかかってしまうメンバーがいるが、原因・対策がわからない。
主に、以下のコミュニケーションの形式についてとりあげます。
報連相、依頼
haddle や Discord などの音声チャット
会議
ドキュメント作成
あなたは誰？
半年前（2022年4月）からデータサイエンスチームのマネージャーになった者です。人数の少ないチームで成果を出すために、まず初めにチームの土台となるコミュニケーションに着目しました。そこで、私が新卒時代やマネージャーになって学んだことをチームのガイドラインとして導入しました。その結果、チームの生産性を底上げすることができました。
次の章から、その具体的な項目を紹介していきます。
質問・依頼・共有のどれかを先に伝える
報連相という言葉がありますが、コミュニケーションは以下の3つに分けられると考えています。
質問・相談：相手から情報を引き出したい場合。
依頼・お願い：相手に何かやってもらいたい場合。
共有・連絡・報告：相手からの返信は主に不要な場合。相手の意思決定や行動を左右する情報を与えたい場合。
まず先に、自分が伝えたいことは、上記のどれなのかを伝えます。口頭なら「質問なんですけど、…」「お願いなんですけど、…」「共有なんですけど、…」、文章なら「（質問）…」「（お願い）…」「（共有）…」と始めます。私のチームでは、以下のような Slack のスタンプを文頭につけます。
なぜなら、自分が相手に求めてる行動を伝えやすいからです。もし、これがないと以下のような問題が起きます。
複数の依頼と共有が混ざっていて、相手が何をしたらいいかがわからず、自分が求めてる行動をしてもらえない。
「〇〇があるといいですよね」と依頼のつもりで言ったが、相手は共有だと思っていて、やってくれてなかった。
「◯◯という新技術、うちでも使えそうですね」といった共有を、相手が依頼や質問だと思い、長文の議論が始まってしまう。
ただ、毎回やる必要はなく、伝えたいことが複数ある場合や長くなりそうな場合のみで十分だと思います。
結論を先に、詳細は後で
結論を先に、詳細（理由、経緯、意図、具体例、前提など）は後で伝えます。質問に答えるときとか特に。閉じた（Yes/Noで答える）質問なら、まず「はい or いいえ」で。開かれた（5W1Hを使う）質問なら、その疑問詞に当てはまる言葉を真っ先に。
逆に自分が質問するときは、相手が答えやすいよう、閉じた質問なのか、開かれた質問なら5W1Hのどれなのか、をハッキリさせます。
伝えたいことが複数あるなら個数と番号を
例えば、以下のように。
3点伝えたいことがあります。
（共有）…です。
（質問）①…ですか？
（質問）②…ですか？
なぜなら、相手の返答漏れを防いだり、相手が番号を引用して答えやすくするためです。
答えになっているかを確認する
相手からの質問に対し、回答が長くなったり、曖昧になったとき、「答えになってますか？」と、相手の求めていたものかを確認します。
特に相手が質問しづらい状況で有効です。例えば、面接・面談、後輩や質問が苦手な方と話す時、大勢の前での質疑応答など。
説明が長くなったら、こまめに質問がないか聞く
上記の項目と似てますが、会議や勉強会などで説明する際は、こまめに区切って、聴衆が理解できてるかを確認します。理解が追いついてないと、その後の説明は頭に入りません。
依頼は期限の設定をする
頼む側も、頼まれる側も期限を設定します。そうしないとタスクが宙ぶらりんになって絶対やらないからです。JIRAなどのタスク管理ツールがあるなら、すぐにタスクを追加します。
期限を設定すると、せっかちだと思われかねないので、「難しければ期限の調整可能です」と一言添えます。大事なのは期限の厳守より、やらなくなってしまうことの回避です。「いつまでにできそうでしょうか？」と相手に決めてもらうのもありです。
依頼は成果物をすり合わせる
「依頼者と議論になりそうな点」についてすり合わせます。例えば、
どのリポジトリの、どのファイルの、どのクラス・関数を、どういじるのか
関数の入出力は何か
PRはどう分けるのか（クソデカPRを防止できる）
ドキュメントは、ユーザー・開発者向け、それぞれ何を書くか
成果物をすり合わせる目的は、依頼者の期待と作業者の方針のギャップを事前に解消し、手戻りを防ぐことです。なので、もし依頼者と作業者が長年の仲で、互いの期待とやり方を熟知しており、やりなれた仕事・技術なら、毎回詳しく書く必要はありません。一方、新しく入ったメンバーや新しい仕事・技術では議論が多くなるので、詳しくすり合わせます。議論が多すぎる場合はペアプロという選択肢もあります。
ペアプロについては以下をご覧ください。
https://zenn.dev/hrsma2i/articles/effective-pair-programming
依頼は目的をすり合わせる
「成果物によって何の課題を解決したいか」という目的をすり合わせます。なぜなら、作業者が目的を理解してないと、迷ったときに自分で適切に判断できないからです。そうすると、依頼者への確認も増えてしまいます。また、目的を明らかにすることで視座やモチベーション、自走力も上がります。
アンチパターンとして「成果物を使うため」と成果物の言い換えになってしまう場合があります。目的を考えるコツは「その成果物がないと、どういった問題が起きるか」を考えます。UXや利益、自分の評価にどう影響が出るかまで考えます。その問題が、解決したい課題です。
依頼は動作確認をすり合わせる
「成果物が課題を解決できてるか確認する方法」をすり合わせます。なぜなら、TDDのように、手戻りを減らせたり、設計が綺麗になるからです。
アンチパターンとして「成果物が動くか確認する」だけだと雑すぎます。他人が再現できるような手順を記載します。特にテストケース（入力・期待する結果）について具体的にします。
テストケースの考え方は「どういった問題が起きるとまずいのか」を洗い出し、起きたらまずい順で、その問題を検知できるようなテストケースを作ります。
なるべく自動化します。例えば、CIで単体テストしたり、統合テスト用のスクリプトを用意したり。手動なら、動作確認手順をドキュメントにも残しておきます。そうしないと、成果物を継続的に改善・保守するのが難しくなるからです。
QCDに変更がありそうなら連絡する
マネージャーの悩みとして「どれくらいの頻度で報連相（質問・依頼・共有）をしてもうらか」があります。少ないと案件が炎上しますし、多すぎるとマイクロマネジメントでメンバーを疲弊させます。そこで、QCD（Quality, Cost, Delivery）に変更がありそう場合のみ連絡してもらいます。QCDの具体例は以下です。
Quality：仕様や設計が変わりそう
Cost：インフラコストが増えそう
Delivery：進行中のタスクが期限に間に合わなそう
連絡する内容としては
差分：仕様がどう変わりそうなのか。インフラコストがいくら増えそうなのか。何営業日伸びそうなのか。
全体影響：最終的なリリースに影響が出るのか、等。マネージャーが、調整に入ったほうがいいかを判断しやすくするため。細かい差分だけだと優先度をつけづらい。
理由：マネージャーが変更を受け入れるべきかを判断しやすいから。回避策や再発防止策を提案しやすいから。
連絡するタイミングは変更がありそうとわかった時点であり、変更があってからでは遅いです。例えば、期限前にビハインドを連絡できれば、マネージャーがサポートに入って期限内に間に合わせることも可能です。
また、マネージャー自身がさらに上のマネージャーに連絡する際は、全体影響があるもののみに絞ります。複数のチームを束ねるマネージャーは、細かい変更すべてを追う余裕はないからです。
ちなみに、粒度をQCDにした理由は、報連相の目的が「予定のQCDにズレが生じたときに、マネージャーがズレを解消 or カバーできるようにするため」だからです。定例などでよく見るDONE, DOING, TODOの報告には無駄があります。マネージャーにとって既知の情報や行動に繋がらない情報が含まれるからです。これらの情報はガントチャートで確認できればよく、予定通りに進んでいる=QCDに差分はないので連絡は不要です。ガントチャートに変更が入りそう＝QとDに変更が入りそうなら連絡します。
ヘルプを求めるときは試したことの手順・結果を伝える
ヘルプを求めるときは「試したことの手順と結果」を伝えます。「できないのですが、どうすればいいですか」だけだと、相手もどう助ければいいかわかりません。詳細は以下のペアプロの記事をご覧ください。
https://zenn.dev/hrsma2i/articles/effective-pair-programming
議論が長引きそう or 緊急なら音声チャット
議論が長引きそう or 緊急なら haddle や Discord などの音声チャットでサクッと話します。議論が長引いてる目安としては、4行以上の文が4レス以上続きそうなら。
haddle や Discord に常駐する方法もありますが、「いない間、仕事してないと思われたくない」「ずっとイヤホンしてるのが辛い」と常駐するのが嫌な人にも向いている方法です。後述しますが、「呼び出しても必ず出る必要はない」とメンバー間で合意をとっています。
音声チャットでも議事録を残す
音声チャットでも議事録はとります。haddle なら Slack スレッドで十分。言った・言わないのトラブルを避けるため。
「音声チャットお願いします」は無駄、直で呼ぶ
「音声チャットお願いします」と文面で事前許可を取るのではなく、直で呼び出します。無駄だからです。ただし、以下のことに気をつけます。
まず、相手のカレンダーを見る。
相手が出れなくても、恨みっこなし。
いくら待っても来なければ、ここで初めて、文面で相手の時間を予約する。
さらに上記をガイドラインなどで明文化し、メンバー間で合意をとっておくと、トラブルが起きづらいです。
会議の前に議事録を作る
議事録があれば、答える側が用意でき、会議の時間を有意義に使えます。また、議論の脱線も防げます。「この会議では、あと〇〇について話さなければいけないので、一旦、この議題は保留にしませんか？」といったように。
議題も質問・依頼・共有にあたるので、上述のことを意識します。
議事録は直後に清書する
第三者が見てもわかるように清書します。もし清書されてないと、「あれって、どうなったんだっけ？」と同じ議論や説明を繰り返すハメになります。
第三者が見てもわかるレベルで整える理由は、
未来の自分が見返すから。今の自分がわかっても、未来の自分は忘れる。ほぼ他人。
会議にいなかった人に説明するとき、議事録を渡すだけで済むから。
議事録は見返すためのものなので、見返せなければ、ただの徒労です。
議事録のタイトルはメインの議題
上にも書きましたが、議事録は見返すために取るので、タイトルをメインの議題にすることで、「あれって、どうなったんだっけ？」となったときに議事録を探しやすいです。
事実と意見は分ける
事実なら「〇〇である/だ/です」と断定し、根拠（実験結果、参考情報のリンク）を添えます。意見なら「〇〇と思う/思われる/考えられる」。なぜなら、正しいかわからない意見を事実として読み手が受け取ってしまうと、誤った情報が蔓延り、誤った意思決定が行われるようになるからです。
「良い」「すべき」は客観的な表現に
「〜が良い」「〜すべき」は主観的な表現であり、読み手や状況によって良し悪しは変わります。また、「〜なときは、〜するのがいいと決まってるんだ！」と形式主義者を増やします。代わりに「〜すると・だと、（具体的にどうなるのか）」と客観的な表現にします。
言葉と意味は1対1にする
曖昧な表現（1つの言葉が複数の意味を表すの）も、表記ゆれ（1つの意味を複数の言葉で表すの）も避けます。なぜなら、ある言葉がどの意味を指すのか、複数の言葉が同じ意味なのか、読み手が判断・記憶しながら読み聞きしないといけず、理解に時間がかかるからです。
定義していない言葉は使わない
なぜなら、定義がわからないと読めなかったり、憶測で読んでしまったりするからです。代わりに以下の対策があります。
先に定義する
すぐ近くや※で定義を注釈する
用語に定義のリンクを貼る
ただ、すべての言葉を定義するわけにはいかないので、想定読者がわかる言葉なら不要です。想定読者は基本、「今一緒に開発してるメンバー」ではなく、「将来、引き継ぐ、ほぼ何も知らないメンバー」です。
短い記述で多くを伝える
なぜなら、効率的に読み手を動かせるからです。相手に見せる前に「同じ情報をもっと短く記述できないか」と推敲します。例えば、以下のような「アンチパターン → 対策」があります。
同じ意味の情報を、書き方を変えただけの文 → 文同士で重複してる内容を無くす
前提や修飾語が多い → 本当にないと相手に意味が伝わらないかを考え、不要なら削る
接続詞や修飾節などが多く、1文に3節以上含まれてる → 2文以上に分ける
ただし、定義や前提を削りすぎると読めないので、想定読者を意識して必要性を判断します。
まとめ
主に、以下のコミュニケーションの形式について、チームの生産性を上げる方法を紹介しました。
報連相、依頼
haddle や Discord などの音声チャット
会議
ドキュメント作成
コミュニケーションの最適な方法は組織や文化によるので、すべてが有効なものではないと思います。ただ、本記事の内容を少しでも普段のコミュニケーションに取り入れていただけたら幸いです。