コミュニケーション技法

ゴール

  • 各種コミュニケーションの技法・考え方の浅い紹介
    • 現場では技術的な問題と同等（あるいはそれ以上）にコミュニケーションの問題が発生する
    • よくある「顧客が本当に必要だったもの」などもコミュニケーション問題（それだけではない）

結論から伝える

まず簡潔な結論から伝える

  • 結論は文章であれば1-3行程度（できれば1行）
  • 説明は後回し
  • 結論から伝えるには結論を出してから再構成して伝える（話す/書く）必要がある
    • 考えながらだと結論からにならない

PREP法

PREP法とは、わかりやすい文章の構成例

  • Point (結論)
  • Reason (理由)
  • Example (実例)
  • Point (結論)

結論タイプ

結論の種類は多くはない

  • 例えば、はい/いいえ形式の質問であれば回答の本質は3種類に絞られる

    • はい / YES
      • できます/可能です/問題ありません、など
    • いいえ / NO
      • できません/無理です/問題があります、など
    • 回答できません
      • 質問の意味がよくわかりません/判断するための情報が不足しています/検討に時間がかかります、など

  • こちらから何か伝える結論の本質は以下に絞られる

    • 依頼
      • 相手に明確なアクションを求める情報伝達
      • 作業依頼、質問、確認依頼、承認依頼など
      • 「～お願いします」というかたちになることが多い
    • 条件付き依頼
      • 特定条件でのみアクションを求める依頼
      • 「もし知っていたら～教えてください」「手が空いていたら～してください」など
    • 周知
      • 相手に明確なアクションを求めない情報共有
      • ただし「知っていること」「覚えていること」は求められる

質問は何か？

相手に反応して結論を答えるためには依頼内容（質問内容）を把握する

  • 相手から来た文を読み直して依頼内容（質問内容）を明確にする
  • 最初に書く結論は主題となる表面上の依頼内容（質問内容）に対する回答をする
  • 本質的な問題を推測することも重要だが、まずは「聞かれていることの結論」を伝える
▼実例１（文章例） 
ユーザデータ移行プロジェクトでご協力をお願いしたい事項の一つとなります。
新アプリのリリース時に、ユーザに関するデータ移行を行う予定でおります。
キックオフ資料にございます通り、御社が管理されているデータベースのスナップショットをいただき、弊社AWSアカウント内に復元したデータベースから弊社管理のデータベースにデータを移行いたします。既に7月時点でのスナップショットはいただいておりますが、テーブル設計の変更やデータ量の変化を定期的に確認したいと考えております。キックオフにおいてはテーブル設計の変更の都度いただけないかご相談しておりましたが、定期的(1ヶ月ごと程度)にスナップショットをいただくことは可能でしょうか。難しい場合は時期や頻度等を含めましてご相談させていただきたいです。
  • 依頼内容はなに？ 回答例を考えてみよう！
▼実例２（文章例） 
本件、影響範囲の確認方法につきまして、確認用アプリですと、
・定期購読セクションの「定期購読キャンペーン」バナー表示
・期間限定初月￥0キャンペーン実施中
・「定期購読」ボタン
上記3点が確認可能かと認識しております。
「定期購読」ボタンを押した後のストア購入画面の定期購読購入価格も確認する必要がある場合は、バージョン3.0.58納品時にご対応いただいたような、キャンペーン確認版APKが必要かと思いますが、こちらにつきましては、ご対応いただくことは可能でしょうか。
  • 依頼内容はなに？ 回答例を考えてみよう！

ロジカルに伝える

結論に至る理由をわかりやすく理論的に説明する

雲雨傘

  • 何を提案するときは「事実」「推定」「提案」を明確化する
    • 『雲がでてきたので』（事実）
    • 『雨が降ってくるかもしれません』（推定）
    • 『傘を持っていきましょう』（提案）

数字を使う

  • 理由の説明として一番わかりやすい事実（根拠）は数字
    • 大きな作業工数見積もりなどは細分化して数字で表す
    • フェルミ推定を使う
▼実例３（見積報告） 
依頼されていた見積ですが開発期間は以下の通り約2か月になります。

仕様（iOS/Android共通）: 5人日
Androidアプリ開発 : 16人日
iOSも同等程度と想定 : 16人日
試験工数は開発工数と同程度 : 16人日
合計工数は53人日 (5+16+16+16)
iOSとAndroidは並行開発できるので開発期間は37営業日 (5+16+16) で約2か月

＜見積詳細＞
仕様調整（ iOS / Android アプリ共通）5
ディープリンクによる起動 0.5
サーバからの情報取得 1
各種表示 5
画面内アクション 0.5
ビューア起動時表示 1
完読時表示 1
既存ボーナスとの競合時処理 3
最終ページにスタンプカード画面への遷移ボタンを表示 1
開発者試験・コードレビュー・フィードバック 3

誰に説くのか？

  • 相手に応じて回答のレベルを調整する

    • 技術職でない相手（顧客など）に専門用語を使って技術詳細を披歴しても煙たがられる
    • 相手が理解できるレベルの説明に簡略化・抽象化して説明する

  • アウトプット（成果物・回答）の粒度の認識を合わせておく

    • 例えば「どのくらいでできますか？」という質問に対して
      • 「人月レベルのだいたいの見積」が必要なのか「人日レベルの見積」が必要なのか
      • 根拠となる見積詳細や正式な資料が必要か不要か
      • 「パッと見の感覚での温度感」や「次回のミーティングまでに出来る範囲での見積」などの期限

リアクション

ボールはどこにあるのか？

  • 依頼を受けて、すぐに回答できない場合は、まず依頼を受け取ったということを知らせる

    • 短い返答やスタンプなど
    • 回答時間の目安を知らせられるとなお良い

  • 依頼を受けたり動きがあったら TODO (TBD, 残作業, アクション) をまとめる

    • 「依頼」はボールがこちらにある
    • 「条件付き依頼」は（基本的に）ボールは来ていない
    • 「周知」はボールは来ていない

  • 回答をしたときにボールが相手に行ったかどうか意識する

    • 「一次回答」とか「継続して確認します」のような言い方だと相手は正式な報告を待っているかもしれない
    • 複数対複数のやりとりではボールが行方不明になることは珍しくない
    • 自分がボールを持っているか分からないときは確認する
▼実例４（文章例） 
> 弊社からのアプリ提供について、現在バージョンごとに DeployGate にて 運用会社様に提供しております。
> 御社にも DeployGate にて提供するのが良いと思いますが、こちら最大で20人までで残り枠は３人までとなっております。
> 追加の際は 運用会社様への相談の上追加となります。

上記承知いたしました。
残り枠を踏まえて一度社内確認した上で、運用会社様にもご相談を行わせていただければと存じます。
  • ボールはどちら？

results matching ""

    No results matching ""