さて、前回の記事 https://qiita.com/Econostasis/items/43217fb579cdecf27920
でデータサイエンス・コミュニケーションとは何かを考えました。次は具体的にどうやってコミュニケーションをとっていけばいいのかを考えてみます。
これは私自身が普段心に留めながら上長（やクライアント）とコミュニケーションをとっている内容です。
その1: 相手と自分の知識のバランスを意識
これは結構基本的で、かつ重要なことです。
先に書いた通りプロジェクトによっては説明して決裁を仰ぐメンバー側に情報の面での優位性が生まれ、リーダーは細かい内容までわかっていない状況は多いです。そこで細々と独自の用語を並べて説明してもリーダーはよく理解できずイライラ、みたいなことが頻発します。
説明する側の責任として、相手だけが理解していないこと、両方が理解していること、自分だけが理解していないことをできる限り考慮して話すことが重要です。
技術が絡む報告だとこういった細かい知識が膨大にあるので、それだけ摩擦も発生します。まずは時間をかけて知識の整理を行うのが良いです。
その2: MTG後の相手の姿をイメージする
これは話す内容を取捨選択しているときに効くのですが、何を伝えて何を伝えないのかは結構迷いどころです。
そんな時には、MTG後の相手にはどんな姿になってほしいか？をイメージします。タスクの概要を知ってもらいGOサインを出してもらいたいのか？起きている小さな問題点を報告して改善点が浮かぶようになっていてほしいのか？この後のお客様との打ち合わせで発表するため、経緯や結果を含めたストーリーを知ってもらいたいのか？
MTG自体の目的に応じて伝える内容は変わってきます。そして何より大事なのが
自分が逆の立場だったら、何をわかっていれば目的が達成されるか？というイメージです。
自分を俯瞰で見つめ、白紙の状態から目的達成のための知識をリストアップし、大から小に向かって説明するという動作こそ、取捨選択そのものになります。
大事なのはイメージです。
その3: 話し始めはタスクの「目的」から
これもよくあったのですが、リーダーは結構忙しい立場の人が多く、いろいろなプロジェクトを並行して束ねていることも珍しくないです。加えてマネジメント業務なども兼任しており、とにかく時間がないものという認識です。
そんな中でのレビューでは、「そもそも何やってたんだっけ？」が頻発するので、まずは今やっている作業の目的に立ち返って報告するのが親切です。
上流に行き過ぎると時間がかかりすぎるので、タスクの結果から何を見たいのか、くらいから話し始めるとお互いの認識がそろった状態で始められることが多いです。
その4: コードを画面共有しながらポイント解説
これは状況によりますが、今までの経験からクエリやコードを画面共有しつつ、前回調査との差分はどこか、（SQLなら）各一時テーブルの役割、単体テストの結果一覧などを見せて大まかな作業スキームを時間内に 説明するとすごく喜ばれます。（時間内に終わらせる必要があるので、クエリをいちいち全部は説明しません。まあ集計条件に直接絡んできそうなカラムのつくりや、レコードの絞り方などは口頭で触れるくらいです。）
自分の周りの環境だと、クエリやコードは投げて「あと見といて」な状態が結構あるようで、自分はなるべくそれをしないように心がけています。
口頭でイメージだけ伝えておけば、細かいところはあとで見てもらうことができるので結構効率的だったりします。
これはデータサイエンス分野にジョインして初めての経験でした。自分でクエリを説明する機会を作ると、構造やポイントを俯瞰で見ることになるので後々のコーディングにも役立つトレーニングになります。
まとめ
思いつくままにざっと書きましたが、これ以外にもまだまだあります。
どれも当たり前のことではありますが、いざという場面で結構抜けてたりします。
コミュニケーションをとる際は改めて思い出しておくとよいのではないでしょうか！