失敗から学ぶマネジメント〜コミュニケーションにおける伝え方の工夫〜
人と人が関わる全ての仕事において、コミュニケーションが非常に大切なのは言うまでもありません。
しかし、「しっかり伝える・聞く・配慮する」といった一見当たり前なことが上手く出来ていないがために、プロジェクトの失敗や人間関係の崩壊に至ってしまうことも少なくありません。
今回はマネジメントにおけるコミュニケーションの「伝え方」にフォーカスし、ソフトウェア開発の現場で筆者が見てきたことや、実際に体験した失敗を踏まえて、どうすれば相手に認識齟齬なく伝えることができるかを書きたいと思います。
ソフトウェア開発のみならず、普遍的なコミュニケーション全てに通ずることですので、マネジメントやコミュニケーション方法で悩んでいる方の参考になれば幸いです。
目次
メンバーとのコミュニケーションがうまくいかない最大の要因
仕事を円滑に進めるため、友達を作るため、恋人を作るため。コミュニケーションの目的は人それぞれにあると思います。
しかし、ソフトウェア開発のディレクターとして日々仕事を進めている中で、この「コミュニケーション」が勘違いされている事が多いと感じています。
私は最近、自分が担当しているプロジェクト以外で、PMOとして横断的に社内のプロジェクトマネジメントをする機会が増えました。そのため、担当しているプロジェクトのメンバーのみならず、普段あまり関わりのない他プロジェクトとの関わりができてきました。
注）PMO：経験を積んだPMやディレクターで組織されるPMO（プロジェクト・マネジメント・オフィス）によるチームが円滑に進んでいるかチェックする、いわばプロジェクトの健康診断を担う組織。
それもあってか、私自身も含め意外にも多くの人がコミュニケーションの罠に陥っている事に気がつきました。
私が気づいたコミュニケーションの罠というのは、「人に何かを伝える際に、ただ言うだけの一方通行になっていること」です。言い換えると、「相手に自分の思い、考えを言うだけでコミュニケーションが完結してしまっていること」です。
私はコミュニケーションとは、必ずインタラクティブ（双方向）でなければいけないと思っています。
伝えた後に相手がどのように理解したかを確認して始めて、コミュニケーションと言えるのではないでしょうか。
一見当たり前のように思えることですが、一方通行のコミュニケーションは業界や仕事・プライベート問わず、あらゆる人間関係において、多くの問題の原因となります。
それでは、コミュニケーションの問題による実際の失敗事例を見ていきましょう。
メンバーとのコミュニケーションが失敗したケース：ソフトウェア開発現場で起きた実例
認識齟齬が起きたケース①
とあるプロジェクトで実際に起きた出来事です。
チーム体制
・ディレクター：1名
・エンジニア：2名
小規模なプロジェクトで、加えて1名がマネジメントサポートとして入っていました。
私はマネジメントサポートからの報告を受ける立場でした。
プロジェクトが始まって４ヶ月目が経とうとしていた頃、1人のエンジニアがディレクターから突然、「チームから外れてほしい」と通告を受けてしまいました。
突然のことだったため、エンジニアは自分がなぜそのような通告を受けたのか分からず、ショックを受けてしまいました。
上記の報告を受けた私は事実確認のためにディレクター、エンジニア、マネジメントサポートの三者にヒアリングしました。
ヒアリングを重ねてわかったのですが、実は、ディレクターとエンジニアの間で認識齟齬が発生していたのです。
通告したディレクターは、通告前からそのエンジニアのパフォーマンスが気になっていました。そしてその不満を週一回、マネジメントサポート担当に伝えていたつもりでした。
一方、通告されたエンジニアはどうかというと、突然過ぎてディレクターに対する信用と尊敬の念を失っていました。「そんなに不満だったならなぜこれまで自分に言ってくれなかったのか！」と怒っていました。
では、報告を受けていたマネジメントサポート担当はどうかというと、多少不満は聞いていたが危機感は感じていませんでした。通告が必要だと思うほどの報告はディレクターからは受けていないという認識だったのです。
このように、とても小さなチームでありながら三者の認識に相違が発生していました。
色々と話を聞いていくうちに、ディレクターは通告直前までエンジニアに対する明確なクレームを挙げていなかったように感じられました。
私がそう感じた要因としては、「ディレクターの方からエンジニアに対する不満や要求を具体的に提示し、それらを実行してもらうといったアクション」が何も行われていなかったからです。
これは伝えていた「つもり」なだけで、コミュニケーションが正しく機能していなかった分かりやすい例かと思います。
認識齟齬が起きたケース②
もう一つの事例は、私自身がコミュニケーション不足を痛感した出来事です。
とあるプロジェクトでメンバーA（既にアサインされている）から、メンバーB（Aに変わってアサイン予定）を交代するための調整をしていました。
私はアサイン調整をメンバー2人と一緒に完了、クライアントにも連絡した後に、クライアントとの調整完了の旨もメンバー2人に口頭で共有し、その場で調整完了ということで合意したはずでした。
しかし次の日になって、私がクライアントに対して話したことと、メンバーの認識が完全にズレていたことが判明しました。
＜私の認識＞
メンバーAとメンバーBを完全に交代して、メンバーBをメインにし、メンバーAは徐々に抜けていくという提案。クライアントが受ける印象を含めて急な交代よりも段階的にという判断でした。
＜メンバー2人の認識＞
1ヶ月間はメンバーAがこれまでと同じくメインで稼働し、1ヶ月後にメンバーBがジョインする。（振り返るとそう考えた理由は理解できました。）
詳細は割愛していますが、メンバー2人と一緒にミーティングをしていながらもこれだけの認識齟齬が起きていました。
私は、メンバーとの口頭でのミーティングと軽い確認を行っただけでした。
つまり、ただ言うだけの一方通行になっていて、決定事項を伝えてコミュニケーションが完結したと錯覚していたのです。
結果的に認識齟齬が起きてしまっていました。
私は普段からリソース調整を多くこなしていましたが、このように少しでも油断をすると、誰でもコミュニケーションの罠にハマってしまうのだと痛感しました。
実例から学んだメンバーとのコミュニケーションを成功させる3つの心構
考えや思いを伝える際の具体化の重要性
前述の2つの事例をふまえ、私は下記の3つを終えてはじめてコミュニケーション完了と定義するべきだと考えています。
①まずは相手に伝えたいこと、期待することを具体的にして洗い出すこと
②そしてそれらを相手に言葉や文字に起こして伝えること
③相手の理解をヒアリングして同じ認識をもつこと
特にマネジメントする側の人間というのは、関わる人たちを引っ張っていってゴールを達成していかなければなりません。
付いていく側の人間が迷わずゴールに突き進むには、マネジメント側がゴールの方向や向かう上での期待をどれだけ明確にし、伝えることができるかが要であります。
伝える順序
相手にネガティブな影響を与える決断を下す際、伝える順序は大切です。特に相手の失敗やパフォーマンス不足を指摘する際は、相手のプライドや自尊心を傷つける恐れがあるので気をつけなければなりません。
その上でやはり、期待と実際のギャップを相手に把握してもらう必要があります。
従って双方でフェアな決断を下す為には、
①まずは期待を具体化して伝え、そこを理解して貰う
②そして相手に改善のための期間を与え、その期間を終えた結果をふまえて最終決断を下す
という流れが必要であると思います。
この流れであれば、最終決断がネガティブな方向でも両者が納得して次に進めるようになると考えています。
適した場面で丁寧な理解の確認
相手がどのように理解したかどうかは、確認しなければ絶対に分かりません。
「説明をしたのだから絶対に自分と同じ理解、解釈をしている」なんてあり得ないのです。
また、ただ確認すれば良いわけでもありません。
例えば相手が忙しい時に確認して、勢いよく「OK」と言っていても聞いてない可能性は高いです。確認を行う際の相手の状況もよく見ておく必要があります。
それらをふまえた上で一番効果的だと思ったのが、
「決定事項を文字に起こして、相手に時間をとって確認してもらった後、同じ認識かどうかの返信をもらう」
ということです。
これをコミュニケーションの最後のフローとして、自分としてもチームのルールとしても決めておけば、認識齟齬を減らすことができると思います。
まとめ
「ここに書いてあることって、仕事をする上で当たり前のことじゃん！！」と思った方もいらっしゃるでしょう。しかし、当たり前であればあるほど人は慣れてすぐに忘れたり、怠けたりしてしまいます。つまり、どんなに経験豊富で頭がキレる人にも、コミュニケーションの罠はつきまとうということです。
また、「阿吽の呼吸」と言われるように、普段仲の良い家族や友達と接する時「自分の考えや思いは伝わっている」と勝手に思っている節はあると思います。
その考えが仕事に出てしまうこともあるのではないでしょうか。
相手が自分が伝えたことをどのように理解したかを確認できるまでのインタラクティブ（双方向）な動きをして初めて、コミュニケーションと呼ぶことができると思うのです。
この記事が皆様にとって「コミュニケーションとは？」を見直す良いきっかけになれば幸いです。
Enlytについて
株式会社Enlytはベトナムに開発拠点SupremeTechを持ち、これまで50以上の開発プロジェクトを行ってきました。ベトナムと日本のグローバルなチームで、数多くのプロジェクトを成功に導いてきました。
Enlytのオフショア開発は、アジャイル・スクラム開発を採用しています。コミュニケーションの透明化を意識してそれぞれの役割で責任の範囲を明確化しています。クライアントも含めたワンチームとして、フラットな関係で開発を進めることができます。
お客様の納得のいくまで、共に開発させていただき、アイデアを最高のかたちにサービス化いたします。
オフショア開発についてのお悩みやご相談がございましたら、下記ボタンより気軽にお問合せください！
