こんにちは、Banking開発部 部長の秋葉瞬です。
金融案件やロジスティクス案件のプロジェクトマネジメントを主に担当し、社内では管理業務を担当しております。好きな色は濃藍（こいあい）色です。
Banking開発部には約30名程度のメンバーがおり、日々お客様とコミュニケーションをとっています。今回は、エンジニアである私自身が日々のコミュニケーションで感じている「IT人材に求められるコミュニケーションスキル」について書いてみたいと思います。
■コミュニケーションロスとは？
システム開発のプロジェクトは、多くの人達が携わることで遂行されます。プロジェクトでは、スケジュール、作業分担、仕様、ルール等、様々な決め事をする必要がありますが、関わる人達の立場がそれぞれ異なることで、納得しがたい場面も多く発生します。
関係者全員が同じベクトルで一致すれば、プロジェクトは円満に進むと思いますが、なかなかそう上手くはいきません。今回は、プロジェクトのスムーズな進行を阻害する「コミュニケーションロス」がなぜ生まれるのか、その要因を記事にします。
コミュニケーションロスとは、コミュニケーションの不足や認識差異により、意思疎通がうまく行かないことが原因で起きるトラブルや損失を指します。
■立場の違い
私自身の経験から、コミュニケーションロスが発生する大きな要因は、「立場の違い」によるものだと思います。下記は、プロジェクトに携わる要員Aさんがコミュニケーションを取る相手を「ざっくり」と書いたものです。
エンジニアであるAさんは、発注元、外注先、社内の人達とコミュニケーションを取っています。社内では、上司に対しては報告、部下に対しては指示、関連部門にはリソース確保などの依頼を行っていますが、それぞれの役割や立場、情報量が異なるため報告や指示、依頼をする際には、状況や目的を具体的に説明していると思います。
しかし具体的に説明したつもりでも認識のずれが起きたり、考え方が異なるためコンフリクト（対立や緊張状態）が起きることもあります。
発注元、外注先など別会社の人ともコミュニケーションを取る場合は、企業文化や業界中の常識、利益などが異なるため、さらに考え方が異なります。
発注者-受注者間の立場の違いについては、IT化の原理原則17ヶ条でも「ユーザとベンダの想いは相反する」という原理原則があり、行動規範として「お互いの責任、義務、想いを知る必要があります。」という記載があります。
IT化の原理原則17ヶ条はIPA（情報処理推進機構）が提言したもので、産業界の共通認識として「超上流」フェーズを発注側、受注側の双方がうまく進めるためのポイントをまとめたものとなります。
この、原理原則［1条］「ユーザとベンダの想いは相反する」を筆頭に、コミュニケーションに関連する原理原則が複数あります。先送りをしない、合意を取る、明確にする、漏れなく伝えるなど、コミュニケーションに関連する原理原則が複数ありますので、いくつか列挙します。
・原理原則［2条］取り決めは合意と承認によって成り立つ
・原理原則［3条］プロジェクトの成否を左右する要件確定の先送りは厳禁である
・原理原則［4条］ステークホルダ間の合意を得ないまま、次工程に入らない
・原理原則［5条］ 多段階の見積りは双方のリスクを低減する
・原理原則［12条］表現されない要件はシステムとして実現されない
・原理原則［13条］数値化されない要件は人によって基準が異なる
それぞれに対する行動規範もありますので、IT業務に携わる方は目を通しておくことをオススメします。（当たり前のことのようですが、大事なことが明記されています。）
■その他のコミュニケーションロスを招く要因
コミュニケーションは人間同士が行うため、個人の態度や応対によって、関係する人たちのモチベーションにも大きな影響を与えます。
場合によっては、信用できない、関わりたくないという感情が芽生え、コミュニケーションを取りたくないという状況が生まれる可能性があります。
下記の例は、チーム全体のモチベーションを下げる要因となりえるものです。
・態度
①高圧的、高慢な態度
自身を上に見せるパフォーマンスかもしれませんが、「こんなの知らないの？」という態度を取る人がいます。技術力や知識があると自負している人に多い傾向かもしれません。
高圧的な態度や高慢な態度は、周囲のモチベーションを下げさせたり、コミュニケーションを取りたくないという心理的な壁を作り、コミュニケーション不足が発生する要因になります。プロジェクトのメンバーに一人でもそのような人がいて、そのままにすると、周囲への悪影響を招くことが多いです。高圧的な態度や高慢な態度をする人は、技術的なスキルがどれだけ優れていてもチームモチベーションを下げるため、優秀な人材とは言えません。
②非協力的な態度
自分の負荷を下げるためか、「やる意味が分からない」と、作業を断ろうとする人もいます。過去に「エビデンスを取る意味が分かりません」と言うベテランエンジニアと同じ案件を担当したことがありました。
「証跡がなければ、やったかどうかが分からないですよね？」と説得しましたが、本当に「やる意味が分からない」のであれば、「なぜそう思うのか」、「何をやるべきか」を提示しないと、周囲からは単に非協力的な人とみられてコミュニケーションの障害となります。反対に、「自分はこうするべきだと思う」という考えを提示する人は、貴重な意見を提示してくれる人として重用されるはずです。
・曖昧な表現
自分の考えや意見に自信が無い時や先延ばしで考えている場合は、その旨を正直に伝えましょう。当初の計画が誤っていた場合や方針が変更されて手戻りが発生したり、変更が何度も続くとプロジェクトメンバー内に不信感が生まれてしまいます。
曖昧な表現には、責任回避のための保険として曖昧な表現をする場合や、だまそうと目論見があったり、過剰なサービスを期待するなど意図的な場合もあります。
そのため曖昧な表現をされた側は自身のみを守るためにも、意図や目的を正確に把握できるように明らかな回答を求めるようにしましょう。
・優先度
優先度が理解、整理できていないのか、本筋ではないものに執着し続ける人もいます。平仄が取れていないなど、本筋に進むレベルに達していないという気持ちも分かりますが、肝心の本筋についてのやり取りが遅れれば、本来進むはずだったものが進まないという状況を招きます。優先度を履き違えていないか今一度考えましょう。
・馴れ合い
長期間同じプロジェクトに関わっているメンバー間で起こりがちですが、「言わなくてもみんな分かってるよね」という前提で進めてしまうと、実はバラバラな考えだったりすることもあるので、本当に認識が一緒か確認するようにしましょう。
また、力のあるステークホルダーの意見に流されたり、経験の浅いメンバーや外注メンバーの意見をなかったことにするというパワハラ的な案件を経験したこともありますが、力のある者の意見しか採用されなければ、力のない者が良案を持っていても意見を出さなくなる可能性があります。平等に意見を聞き、尊重しあう関係でいることを心がけましょう。
■コミュニケーションロスを防ぐために
コミュニケーションロスにつながる要因について記載しましたが、上記以外にも様々な要因があると思います。
一方的なコミュニケーションにならないよう、私は以下の点に気を付けています。
・相手の立場を理解し、相手の意図を汲み取る（理解する）
・自分の考えを的確に伝え、相手の意図を明確にする（曖昧にしない）
・双方が納得をする部分に落とし込む（合意する）
コミュニケーションを良好に取ることで皆のモチベーションが上がりますし、ミスの防止や作業の円滑化、助け合いなどプロジェクトも円滑に進むようになります。
■コミュニケーションロスを防ぐための私の対策
私がコミュニケーションロスを防ぐために実践している方法の一部をシェアします。
・相手の立場を理解し、相手の意図を汲み取る（理解する）
プロジェクトに参加しているメンバーも、部署のメンバーもそれぞれ持っている情報や責任、決定権などが異なるため考え方も異なります。
「なぜ今この要望を出してくるのか？」、「なぜそこにこだわるのか？」、「言いたいことは本当にそれだけなのか？」など、会話の中で、疑問に思ったことを相手の立場になったつもりで考えるようにしています。相手はこの立場だから、これを優先させようとしている。この情報しか知らないからこの方針にしようとしている。相手先では、過去にこういった事情があったので今回も同様なのかな。など、相手の事情も考慮するように意識しています。自分なりに予想して、こういった事情によるものですか？と話すと、それが間違っていても、相手を理解しようとしている気持ちを伝えられ、相手も安心感を覚えてくれるのではと考えています。
・自分の考えを的確に伝え、相手の意図を明確にする（曖昧にしない）
認識に差異がある場合は、自身の認識がそうなったいきさつを示すようにしています。把握していない情報を互いに得ることもありますし、どこで認識差異が発生したのかが明確になるため再発防止にもなります。曖昧な表現で差異が起きそうな場合は、明確にするように心がけています。
・双方が納得をする部分に落とし込む（合意する）
合意が必ず必要なものもありますが、そうでない場合でも相互に納得するように合意のプロセスを設けるようにしております。守る前提で合意するものですので、互いの信頼関係も生まれると思います。作業レベルの合意だけでなく、「問題が起きた場合はこういう分担をしましょう。」というような、責任についての合意なども事前に取ると、問題発生時に役割が明確になっているため早急に対応することが可能になります。
■まとめ
コミュニケーションロスは、プロジェクトの進行に影響を与えたり、会社に損失を与えるだけでなく、システムによっては人命や災害に関する致命的なミスを招いたり、メンタル不調や退職などメンバーの人生にも影響を与える可能性もあります。
人間同士なのでコンフリクトが発生することは避けられません。
一方が気を付けていても、もう一方が考慮していないという場合もありますので、そういった際は、周囲の協力を得て改善されるように働きかけましょう。
みなさんの日々の業務の参考になれば幸いです。
あなたもAMBLで働いてみませんか？
AMBLは事業拡大に伴い、一緒に働く仲間を通年で募集しています。
データサイエンティスト、Webアプリケーションエンジニア、AWSエンジニア、ITコンサルタント、サービス運用エンジニアなどさまざまな職種とポジションで、自分の色を出してくださる方をお待ちしています。ご興味のある方は、採用サイトもご覧ください。
●AMBL採用ページ
-メンバーインタビュー （1日の仕事の流れ／やりがい／仕事内容）
-プロジェクトストーリー （プロジェクトでの実績／苦労エピソード）
●募集ページ
プリセールス/ エンジニア/ クリエイター/ データサイエンティスト /営業・コンサルタント /コーポレート /サービス企画 /教育担当
