エンジニアのためのコミュニケーションTips ② なぜコミュニケーションが「ズレる」のか【前編】

【前回】 エンジニアのためのコミュニケーションTips ① そのスライド、要りますか? https://tech-blog.cloud-config.jp/2019-11-08-communication-tips-for-eng…
よくある風景
週次のクライアントミーティング、その前日に資料の社内レビューが行われました。自信なさげに話し始めるプロジェクトリーダー、曇っていくマネジメントの表情……。発せられる言葉は「先週に話した内容から、全然ずれてない?」そうやって、資料をみんなで修正するために、遅れる帰宅時間、削られる睡眠時間。ハッピー・エンジニアライフの実現のための本稿、今回はこうした「ズレ」に注目して、パターンと処方箋を示していければと思います。今回は前編として下図に示す「そもそもの理解のズレ」に注目して議論していきます。
「ズレる」ことはハイコンテクストサービスの宿命
多くのプロジェクトでは、PMOミーティングやWGといった、マイルストーンになるクライアントミーティングが、定期的に開催されます。いきなり最終成果物ドン! とならないのは「クライアントの欲しいもの」と「サービス提供者の作るアウトプット」が多くの場合一致しないことで辛酸を舐め尽くした、先人の知恵と言っても良いでしょう。 古き良き戦略コンサルティングのプロジェクトは、3ヶ月のプロジェクト期間に対して、クライアントミーティングが月1回程度だった、という話を聞いたことがあります。いわゆる"MBA的なビジネス知識"が一般的でなかった時代の、フレームワークに則った調査や分析ならあまり「欲しいもの」と「アウトプット」がズレることはなかったかもしれません。しかしビジネス知識が一般化した結果、クライアントの求めるアウトプットはよりクライアント固有のコンテクストに沿った高度なものになり、インパクトに直結するものになっていきました。この結果、最終成果物もムービング・ターゲットになりやすく、クライアントとの期待値のズレが広がるのを防ぐために、こうしたミーティングが週次やそれ以上になったり、より連続的な協働モデルへとビジネスが進化していきました。 ちなみに、クラウドベンダーであるFIXERは、コミュニケーションの頻度に加えて現地・現物・現実の3現主義を重視し、アウトプットのプロトタイプを早々に作るという、デザイン・シンキング的なアプローチを重視しています。プロトタイピングにかかるコストや、そこからプロダクトに進化させていく工数を小さくできるのが、クラウド活用のひとつの利点だからです。PowerPointやExcel上でこねくり回すより、実際に現物を見せながら進めていくのが、スレないための特効薬なのですが、構想・提案・計画のフェーズではそうもいかないこともあります。そんな状況をイメージしながら、以下を聞いて下さい。ズレ方その1. そもそも(意味のある)メモを取っていない
メモ……? メモくらい取ってるよ、馬鹿にするなー! という方もたくさんいらっしゃると思います。でもそのメモ、後から見返して分かります? 半分寝ながら取った講義ノートみたいに、後から読み返せず苦戦……という人もいるかもしれません。 慣れないうちは、一言一句をメモするつもりの方が、間違いないです。トップマネジメントの短い言葉の魂は、助詞一つに込められることもあります。例えば、ある部下への指示について「指示をした」と「指示はした」の間には、深いミゾがあります。これを聞き逃してしまうと、その真意を見逃して、後の議論に全く付いていけなくなってしまうことさえあります。 視座が高まってくると、記憶を辿れるようなキーワードだけメモるとか、後から思い返すであろうフレーズだけ抽出するとか、そういうこともできるわけですが、まずはひたすらメモを取った方がいいと思います。余計なことを書いても消せばいいだけですが、書き損じたことを後から思い出せることはほとんどありません。ちなみに、コンサルティング会社に入ると、最初はさんざん「インタビューメモ」を書きます。ロジカル・ライティングについては後に話すと思うのですが、自分の場合はこう教わりました。 ・青いペンでひたすらメモを取る。生コメントが重要になることもあるので、一言一句逃さないつもりで書く ・黒いペンでそれの構造を書く。線でロジックのピラミッドを書いたり、因果関係を矢印で結んだりする。サマリに含める要点に線を引いたり、キーワードを書く ・最後に黒で書かれたサマリーを基に、赤いペンで論点に答える「示唆」(これはインタビューのコメントには含まれていない)を書き、ネクストステップを書き出す ・メモはネクストステップ、それの根拠となる議論のサマリ、詳細メモの順番に書き、トップマネジメントが理解する手間をなるべく減らす 重要なのは最後です。ペンの色は趣味の世界ですが(そもそも最近はノートを持ち歩いていないですし……) とにかく「ネクストステップ」は明確にすべきです。手書きならノートに一本線を引いて右側に書くとか、PCやタブレットでタイプしているなら☆印を付けるとか。そして、帰りの道中で一緒にいる上司に「ネクストステップってこういうことですよね?」と確認することができれば、まず大きく手戻りが発生することはないはずです。 ※ OneNoteやDropbox Paperなどで、コラボレーションメモを取るのも良いですが、得てして「誰かが取ってくれるだろう、ヨシ!」となり、 重要な情報が落ちがちなのでメイン担当者くらいはきちんと決めておきましょう。ズレ方その2. 指示の背景が腹落ちしていない
ネクストステップ(その1で語った「赤いペン」の部分)が明確であっても、その決定背景となるロジック (同じく「黒いペン」の部分) の理解が浅い、もしくは腹落ちしていないと、コミュニケーションとアウトプットはズレていきます。 例を挙げましょう。2つの開発方式A・Bが検討されていたとします。それまでは開発方式Bで進められてきたのですが、ミドルマネジメント(チームリーダー)が参加した会議において、トップマネジメントが実現性の観点からこれまでのアウトプットを捨て、開発方式Aに転換することを決断しました。 会議に参加していたミドルマネジメントは、その議論の過程や判断のロジックを聞いていますから、開発方式Bを採用する必然性を「なんとなく」理解しています。でもそれをメンバーに、きちんと説明できないことによってズレが発生します。結果、現場は"慣性"が働いて開発方式Bを続けてしまい、気づかないうちにズレが大きくなる……そんなことが日々起こっています。