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

Eye-catch Photo by Alex Andrews from Pexels

前回スライドの話から入り、今回はその続きの予定だったのですが、いろいろと課題意識を刺激されるような出来事があり、コミュニケーションが「ズレる」要因をみんなで考えてみたいと想います。このズレによる手戻りこそが、働く時間を伸ばしていきます。やればできるセルフ働き方改革、始めましょう!

【前回】 エンジニアのためのコミュニケーションTips ① そのスライド、要りますか?
https://tech-blog.cloud-config.jp/2019-11-08-communication-tips-for-engineers-01/

よくある風景

週次のクライアントミーティング、その前日に資料の社内レビューが行われました。自信なさげに話し始めるプロジェクトリーダー、曇っていくマネジメントの表情……。発せられる言葉は「先週に話した内容から、全然ずれてない?」そうやって、資料をみんなで修正するために、遅れる帰宅時間、削られる睡眠時間。ハッピー・エンジニアライフの実現のための本稿、今回はこうした「ズレ」に注目して、パターンと処方箋を示していければと思います。今回は前編として下図に示す「そもそもの理解のズレ」に注目して議論していきます。

「ズレる」ことはハイコンテクストサービスの宿命

多くのプロジェクトでは、PMOミーティングやWGといった、マイルストーンになるクライアントミーティングが、定期的に開催されます。いきなり最終成果物ドン! とならないのは「クライアントの欲しいもの」と「サービス提供者の作るアウトプット」が多くの場合一致しないことで辛酸を舐め尽くした、先人の知恵と言っても良いでしょう。

古き良き戦略コンサルティングのプロジェクトは、3ヶ月のプロジェクト期間に対して、クライアントミーティングが月1回程度だった、という話を聞いたことがあります。いわゆる”MBA的なビジネス知識”が一般的でなかった時代の、フレームワークに則った調査や分析ならあまり「欲しいもの」と「アウトプット」がズレることはなかったかもしれません。しかしビジネス知識が一般化した結果、クライアントの求めるアウトプットはよりクライアント固有のコンテクストに沿った高度なものになり、インパクトに直結するものになっていきました。この結果、最終成果物もムービング・ターゲットになりやすく、クライアントとの期待値のズレが広がるのを防ぐために、こうしたミーティングが週次やそれ以上になったり、より連続的な協働モデルへとビジネスが進化していきました。

ちなみに、クラウドベンダーであるFIXERは、コミュニケーションの頻度に加えて現地・現物・現実の3現主義を重視し、アウトプットのプロトタイプを早々に作るという、デザイン・シンキング的なアプローチを重視しています。プロトタイピングにかかるコストや、そこからプロダクトに進化させていく工数を小さくできるのが、クラウド活用のひとつの利点だからです。PowerPointやExcel上でこねくり回すより、実際に現物を見せながら進めていくのが、スレないための特効薬なのですが、構想・提案・計画のフェーズではそうもいかないこともあります。そんな状況をイメージしながら、以下を聞いて下さい。

ズレ方その1. そもそも(意味のある)メモを取っていない

メモ……? メモくらい取ってるよ、馬鹿にするなー! という方もたくさんいらっしゃると思います。でもそのメモ、後から見返して分かります? 半分寝ながら取った講義ノートみたいに、後から読み返せず苦戦……という人もいるかもしれません。

慣れないうちは、一言一句をメモするつもりの方が、間違いないです。トップマネジメントの短い言葉の魂は、助詞一つに込められることもあります。例えば、ある部下への指示について「指示した」と「指示した」の間には、深いミゾがあります。これを聞き逃してしまうと、その真意を見逃して、後の議論に全く付いていけなくなってしまうことさえあります。

視座が高まってくると、記憶を辿れるようなキーワードだけメモるとか、後から思い返すであろうフレーズだけ抽出するとか、そういうこともできるわけですが、まずはひたすらメモを取った方がいいと思います。余計なことを書いても消せばいいだけですが、書き損じたことを後から思い出せることはほとんどありません。ちなみに、コンサルティング会社に入ると、最初はさんざん「インタビューメモ」を書きます。ロジカル・ライティングについては後に話すと思うのですが、自分の場合はこう教わりました。

青いペンでひたすらメモを取る。生コメントが重要になることもあるので、一言一句逃さないつもりで書く

黒いペンでそれの構造を書く。線でロジックのピラミッドを書いたり、因果関係を矢印で結んだりする。サマリに含める要点に線を引いたり、キーワードを書く

・最後に黒で書かれたサマリーを基に、赤いペンで論点に答える「示唆」(これはインタビューのコメントには含まれていない)を書き、ネクストステップを書き出す

・メモはネクストステップ、それの根拠となる議論のサマリ、詳細メモの順番に書き、トップマネジメントが理解する手間をなるべく減らす

重要なのは最後です。ペンの色は趣味の世界ですが(そもそも最近はノートを持ち歩いていないですし……) とにかく「ネクストステップ」は明確にすべきです。手書きならノートに一本線を引いて右側に書くとか、PCやタブレットでタイプしているなら☆印を付けるとか。そして、帰りの道中で一緒にいる上司に「ネクストステップってこういうことですよね?」と確認することができれば、まず大きく手戻りが発生することはないはずです。

※ OneNoteやDropbox Paperなどで、コラボレーションメモを取るのも良いですが、得てして「誰かが取ってくれるだろう、ヨシ!」となり、 重要な情報が落ちがちなのでメイン担当者くらいはきちんと決めておきましょう。

ズレ方その2. 指示の背景が腹落ちしていない

ネクストステップ(その1で語った「赤いペン」の部分)が明確であっても、その決定背景となるロジック (同じく「黒いペン」の部分) の理解が浅い、もしくは腹落ちしていないと、コミュニケーションとアウトプットはズレていきます。

例を挙げましょう。2つの開発方式A・Bが検討されていたとします。それまでは開発方式Bで進められてきたのですが、ミドルマネジメント(チームリーダー)が参加した会議において、トップマネジメントが実現性の観点からこれまでのアウトプットを捨て、開発方式Aに転換することを決断しました。

会議に参加していたミドルマネジメントは、その議論の過程や判断のロジックを聞いていますから、開発方式Bを採用する必然性を「なんとなく」理解しています。でもそれをメンバーに、きちんと説明できないことによってズレが発生します。結果、現場は”慣性”が働いて開発方式Bを続けてしまい、気づかないうちにズレが大きくなる……そんなことが日々起こっています。

ミドルマネジメントが判断のロジックを正確に理解し、伝えることができればベストですが、トップの視座が高かったり、思考のスピードが早かったりする場合、それも簡単ではありません。こうした場合「判断のロジックをわかるまで確認する」か、そもそも「中間レイヤーを減らし、現場エンジニアまでミーティングに加える」といった方法によって対処していくことになるでしょう。

ズレ方その3. 定義・前提条件が違う/緩い

コミュニケーションを正しく理解できない要因として「そもそも言葉の定義が違う(ないしは、緩い)」ということがありえます。気をつけるパターンをいくつか挙げていきましょう。

ものすごく多いのが、同じものを違う言葉で書いたり、違うものを同じ言葉で書いたり。前者の例として、フェーズ名やドキュメント名が、ドキュメントによってバラバラになっていることがよくあります。一度、提案書の段階でスコープを合意できたら、進捗報告から納品物まで、可能な限りフレームワークを変えず、全体像として継続的に示していくことが大事です。

また、後者は「サービス」のような多義語に注意する必要があります。本来、サービスの定義だけで、サービス・サイエンスの学術書の1セクションくらいにはなってしまいます。Azureのサービスのようなシステムの部品の話なのか、そうしたシステムを通じて提供される付加価値創出活動なのか。可能な限り、わかりやすい言い換えが必要です。

よく使われるPoC (Proof of Concept; 概念検証) という言葉も、非常に曖昧です。単に小さな規模で動くものを作ってみるのか、実際のデータ流量に耐えられるように大規模に試験する必要があるのか。そして、全て完了させるのか、一つだけ例を示すのか。これがずれていると、コストが爆発してしまいます。可能な限り「納品物」の項目で、その規模感等を可能な限り具体的に確認しなければいけません。

こういうズレをなくすために「具体的なアクションを明記しよう!」となるのですが、悲しいかなここに緩さが潜んでいる場合もあります。システムトラブルの再発防止策のところに

・お客さまクレームの要因となっている応答時間を改善する
・発生している障害(チケットNo. XXX) に対応する
・緊急発報の見落としがないよう、部員の意識を高める

みたいなことが書いてあったらどうでしょう。個人的に三大アクションNGワードと呼んでいるのがこれらの「改善する」「対応する」「意識する」です。

・改善する: どの水準まで、どのような手法で改善するのか
・対応する: いつまでに、誰が、何をやることで対応するのか
・意識する: そもそも精神論とか聞いていない(笑)

といったあいまいワードたちであり、何も言っていないに等しいことがよくあります。こうした緩い言葉を使っていないかのチェックは、意外と大変です。自分なりに「NGワード」や「要チェックワード」を貯めていき、なるべくこんなズレは小さくしていきたいものです。

本日の提言

理解のズレをなくすためには、まずメモを取ろう。そしてなぜその結論になったのか、判断のロジックを自分なりに組み立てよう!

FIXER Inc. 岡安 英俊
  • FIXER Inc. 岡安 英俊
  • ボストン コンサルティング グループ (BCG)、東京工業大学特任講師を経て、FIXERに入社。戦略部門のGMとして、全国を走り回りつつ、戦略および計画の立案・新規事業立ち上げ等をリード。サービス・プロダクトを通じてクライアントのDigital Transformationの真の原動力となるべく、テクノロジーライフを日々楽しんでいる。2匹のねこ (みるく・くらうん) と楽しく暮らしています。

%d人のブロガーが「いいね」をつけました。