仕事場のコミュニケーションにおける個人の方針

たまたま、コミュニケーション方法がいいように見える、自分もそういう能力をつけたいと言ってもらう機会があったのでまとめる。

免責

• ここに書く内容は体系化された知識に裏打ちされていません
• 書籍を読んで勉強した方がたぶんいいです
• ちょこちょこ聞きかじっていいなと思ったことを雰囲気で実践した経験則です
• ちゃんとした知識からみた場合にアンチパターンになっている可能性もあります
• 個人的な基本方針である一方、練度の不足などで出来てない場合もありますがそれはミスであり、この方針を否定する振る舞いではありません
• ご利用は自己責任でお願いします

意識してることとその背景

• 最後まで話を聞く
  • そもそもよくよく考えると相手の話を遮って自分の話をする理由って本来はないはずだが、過去の自分を振り返ると以下のようなことが理由に挙がる
    • 話の結論はみえた！もう続けなくていいです
    • あ、その前提全然ちがう訂正しなきゃ
  • 相手の話がどう展開するか私は正確に予測できません
  • 前提の間違いが話者の論法と結論に大きく影響しないことも多い
  • 本とか読むと帰属意識がどうのこうのと書いてあったりする気がする
  • MTGなどの時間的制約が厳しい場合遮る必要がある場合がある
  • その場合は「本来私はあなたの話を聞くべきだがあえて遮ります」ということを伝える
    • つまり「ごめんなさい」
• 説明を求められている人の代弁をしない
  • Diversityの観点でMansplainingとか言われるやつ
  • 性別は関係ない、本人がヘルプを出さない限り代弁すべきではない
  • MTG時間の問題はあるが、MTGの時間を守ることより適切な議論が行われる方が優先度は高い
• 相手の意見を理解する
  • 賛成か反対かは関係ない
  • 理解したつもりが確認すると理解できてなかったということも多々ある
  • 自分の能力を過信してはいけない
  • そもそも一度聞いただけで必ず理解できる能力があるわけではない
  • 「よくわからんけど、俺はこう思う」は議論にならないのでNG
• 理解したということを伝える
  • 「なるほど」
  • とくに、反対意見を表明する場合、相手が話を理解されていないと感じていると、話がループしたりする
  • 自分の言葉で言い換えたり要約して相手の意見を復唱する
• 反対・賛成かを明確にして意見を返す
  • 「いいとおもう」・「ちょっと気になる点がある」
  • 賛成の場合はとくに気を付けることはない
  • しいて言うならどういうところに共感したかを具体的に挙げると「賛成」の説得力が高まる
  • 反対の場合はもうちょっと繊細
  • ディベートではないので打ち負かす必要はない
  • 理解してもらう必要はある
  • なぜ違う意見になるのか？という点をしっかり伝える
    • 「Aさんの意見にはセキュリティ観点の考慮が抜けていたように思う、 そこを考慮すると～が～なので反対である」
  • 断固として反対！という前提にたたない
  • 自分の目線では反対だとしてもその時の組織の制約・優先順位・許容リスクなどでとるべき結論は容易にかわる
  • 正解だと思わないこと
  • 対案を出す必要ない
  • 反対理由が他の人に伝わればその検討はそのチームが検討すべきことになっているはず
• 不安・懸念の扱いかた
  • 反対とか賛成ほどの強い意見ではないが
  • 気持ちが反応する場合がある
  • 不安や懸念はチームに抜けている観点の可能性もある
  • ただ「伝えるだけ」はNG
  • 伝えた先の結論を作るところまで一緒にやる
  • 「不安だから反対」なのか「不安だけど賛成」なのか自問する
  • 不安・懸念から具体的なリスクが上がらなければ反対はやめとく
  • たとえ不安・懸念が現実のものになってもそれはしょうがない
  • その時の条件でできる判断をしただけで間違ってるかどうかは結果論
• 特定の人を孤独にしない
  • 責任を一身に背負うというのは少なくとも自分は嫌い
  • 出来るだけ強い表現で否定・肯定することで自分も責任を負う
    • 「いいと思う」より「それで行きましょう」
    • ここで言う強いは「攻撃的」という意味ではない
  • もちろんこれだけではなく困りごととその解決にも積極的になる振る舞いとセット
• 「思います」禁止
  • デザイナさんが「これで実装行けますか？」と聞いてきたり
  • マネージャーが「Ｘ日までにリリースできますか？」と聞いてきたり
  • サポートさんが「ここの仕様ってＸＸＸでしたっけ？」と聞いてきたり
  • エンジニアが「この表示ってＸＸＸＸが条件でしたっけ？」と聞いてきたり
  • よくある話だと思う
  • この話に肯定で返す場合
  • 「行けると思います」より「行けます」
  • 「できると思います」より「出来ます」
  • 「そうだと思います」より「そうです」
  • スケジュール系の文脈は補足が必要か
    • 予測が外れた場合のペナルティが強いとさすがにできない
    • 未来は不確定で、その不確定さの責任をだれか一人に背負わせない
    • 予定が狂った場合の説明責任をセットで負う
      • 逆に言えばちゃんと説明できれば許してもらえる環境が前提
  • 純粋な質問系は頼られたんだから応えるという観点
  • 手が離せないが記憶上Yesみたいな状況ならしかたないので
    • 「思う」+ 「忙しいのでちゃんと確かめられない」ことを伝える
  • 心が弱っていると「思う」になりがち、「思う」から「確定」に情報を更新するには何が必要か？
• 「どうするか決めてください」禁止
  • 要件上の未考慮事項
  • デザイン上の未考慮事項
  • などが実装時に発覚した場合
  • 「どうするか？」を丸投げしない
  • 前提として人間が作業する以上、確実に一定の割合で漏れる
  • ただし提供したい体験の観点ですごく重要なことが漏れているということは少なく
  • どちらかと言えばデータ制約や技術的制約の観点での漏れなことがおおい
    • ユーザが特定の状態のときになんかの問題があるとか
    • アプリでは簡単だがブラウザだとできない
  • 体験全体としてはある意味重要ではないので誰が考えてもいいはず
  • 「ＸＸＸが未考慮で決めなきゃいけないんですが、Aでいいですかね？他の案だとBかCとかもあります。BはUIとしてはよさそうですが実装が大変なので現実的ではないかも。全部ダメそうなら決めるか相談してください。」
• 精度100%を求めない
  • 自分も応えられないし
  • 他者も応えられない
  • 前述した不確実性やミスがあるから
  • 100%にするのはコスパがわるすぎる
  • 最終的に80%ぐらいあればコスパ十分だし、足りないところはみんなで埋める
    • とはいえ責任を持った人が60%とか70%とかはちゃんと達成してほしい
• 不確実性を前提にする / 情報の確度を気にしすぎない
  • 予知能力があるわけではないので基本的にどんな計画も変更される可能性がある
    • 取り組みにより可能性を減らすことはできるが0にはならない
    • コスパの折り合いがつくところで可能性を足切りしてるだけ
  • 直感だよりにはなるがよっぽど無理筋じゃない限り「なんとかなるやろ」の精神
  • 「なんとかする」とはちょっと違う。
  • Let it be
  • 何かあった時のことを考えすぎるよりすすめる一歩
  • 投機的な作業でもいいじゃない
• その他
  • VideoCall
    • こえでリアクションを取る
  • Text
    • 長い文章でやりとりしない
    • 人間は考えていることを「厳密にテキストで表現できません」
      • というか「言葉」は「人間が考えていること」を表現するには表現力が乏しすぎる
    • 人間は書いてあることを「厳密に理解できません」
    • 人間は「ちょっとした先入観で容易に誤解します」
    • 間違いも過不足もない文章が必ずしも伝わる文章ではないというジレンマ
    • たくさん書いて誤解されるより説明不足で質問される方がロスはすくない