エンジニアとディレクターとのミスコミュニケーション・話が通じないを解消するポイント６つ

エンジニアとディレクターとの間で起こりやすいミスコミュニケーションには、いくつか典型的なパターンがあります。

ミスコミュニケーションの原因や解決策を考える前に、まずは「あるある」のパターンについて見ていきましょう。

「自分も同じようなことを経験したことがある」と思ったら、そのときのやり取りをなるべく詳しく思い出してみてください。

後述する「注意するべきポイント」を自分の場合に置き換えて考えるヒントになるはずです。

急な仕様変更や機能追加が多い

すでに要件定義が完了し実装を進めているところへ「仕様の変更があった」「機能を追加してほしい」と言われて愕然とした経験はありませんか？

そんなとき、ディレクターがよく口にするセリフが「お客さんに言われた」「顧客の要望なので」というひと言です。

たしかに、顧客から要望されたのであれば受け入れざるを得ないこともあるでしょう。

しかし、エンジニアの立場としては「何でもお客さんに言われるがまま『分かりました』『変更できます』と言わないでもらいたい」と言いたいところです。

工程のやり直しや手戻りが発生し、ディレクターが思っている以上にスケジュールに大きな影響が及ぶことも少なくないからです。

後になって追加したいことが出てきたのなら、引き換えに何かを捨てなくてはならなくなる、ということを理解していないディレクターは困りものです。

仕様を口頭で伝えられ、仕様書をエンジニアが書くことになる

仕様について打ち合わせの席で口頭で伝えられたきり、「あとはよろしく」というスタンスのディレクターの場合、結局はエンジニアが仕様書を作成しなくてはなりません。

ディレクターとしては「仕様に関する重要な話なので直接伝えたほうがいいだろう」と判断したのかもしれませんが、これでは文字として残らないため、どのような仕様でフィックスしたのか確認できないという欠点があります。

結果、「言った・言わない」「聞いていた話と違う」といったトラブルに発展することもあり得ます。

そもそもディレクターの業務範囲として、企画や要件定義、全体設計が含まれているのであれば、本来ディレクターが担うべき仕事をエンジニアにやらせていることは明白です。

「きちんと仕事をして欲しい」という点に尽きるでしょう。

できるか分からないことが、説明なく決定事項になっていた

エンジニアの立場からすると本当に実現可能かどうか疑わしいことが、いつの間にか決定事項になっていた…という場面に遭遇することがあります。

できるかどうか分からないことには2種類あり、

といったパターンが考えられます。

後者は問題外ですが、前者のような事例はエンジニアにとって「あるある」のことではないでしょうか。

とくに技術的な知識が豊富でないディレクターの場合、「エンジニアに任せれば案外できてしまいそう」とイメージする範囲が異様に広く、「たいがいのことはシステムで実現できる」と考えている節があります。

少なくとも「本当に実現可能かどうか」を前もってエンジニアに確認したり、意見を求めたりするなど、何らかの段階を踏んだ上で決定してもらいたいところです。

目的を知らされずに仕事が振られる

「〜を追加したいから、やっておいてもらえる？」とだけ言われ、目的や背景となる情報を与えられないパターンです。こうした指示を出されると、大きく分けて2つの問題が生じます。

1つ目の問題点としては、たとえば機能の追加であれば「なぜ追加することになったのか」「その結論に至るまでにどのような議論があったのか」「顧客の要望の真意はどこにあるのか」かが分からないことです。

指示を言葉通りに表面的に受け取り、言われたことだけをこなすこともできますが、それで本当に目的を達成できているか怪しいところです。

もしかしたら、顧客が望んでいるのはもっと別のことかもしれないからです。

もう1つの問題点としては、エンジニア自身がプロジェクトメンバーの一員として扱われていないような印象を持ちやすいことです。

自分は単なる作業者でしかなく、言われた通りに仕事をするだけ、と考えるようになると、モチベーションが上がらないばかりか、本質から外れた仕事になりやすいのです。

よくあるミスコミュニケーションに思い当たる節があった人は、もう一歩踏み込んでこう考えてみてください。
「こんなミスコミュニケーションがなぜ起こるのだろう？」と。

一見すると理不尽にも映るこれらのミスコミュニケーションに共通する原因として考えられるのは、ディレクターとエンジニアの認識のずれです。

エンジニアにとってこれらの事項は極めて重要な意味を持ちますが、ディレクターにとってはその重要度が理解できていない可能性が高いと考えられます。

つまり、ディレクターとエンジニアの間に生じるミスコミュニケーションの最大の原因は知っていることの違いなのです。

業務が違えば、知っていることが違うのは当然です。
相手に前提知識を持ってもらうことを期待するよりも、そもそもの理解度に差があることを前提としてディレクターとコミュニケーションを図る工夫をしたほうが現実的でしょう。

ディレクターはプログラムの専門家ではありません。

技術的な知識については、エンジニアのほうがずっと高度なものを持っていると考えるのが自然です。

では、技術的な知識量に差異があるディレクターとどうコミュニケーションを図っていったらいいのでしょうか。

ここからは、ディレクターとのコミュニケーションで注意しておきたいポイントを挙げていきます。

「なぜ分かってもらえないのだろう」とネガティブに考えず、前向きにコミュニケーションを図る工夫をしてみましょう。

技術的な話は相手の理解度に合わせて説明する

ディレクターの仕事はプログラムを書くことではありません。

技術的な用語やその概念について、エンジニアと同じレベルで理解できている人はそういないと思っておいたほうが無難です。

技術的な話をするときには、ディレクターがどこまで理解しているのか確認しながら話を進め、できるだけ専門用語を使わないように心がけたり、噛み砕いて説明したりといった工夫をしましょう。

技術的な話に限らず、相手の理解度に合わせて伝えることはコミュニケーションを図る上で非常に重要です。

自分の知識レベルを基準に考えてしまうと、お互いに「何となく分かったつもり」「伝えたつもり」になってしまい、結果的にトラブルに発展するリスクもあります。

一方的に伝えることに終始せず、確認を入れたり質問を受けたりする時間を取ることも大切です。

ディレクターによって個々の理解度に差があるはずですので、会話を重ねる中で相手の理解度を推し量り、相手に合わせた話し方ができるようになると、ミスコミュニケーションのリスクを減らすことができます。

ディレクターとの「言葉のニュアンスの違い」に注意

ディレクターとエンジニアは担当する仕事の性質が異なります。
そのため、同じ言葉を使っていても微妙にニュアンスが違う場合があることに注意が必要です。

よくあるすれ違いの例として、「できます」という言い方があります。

ある機能を追加してほしいとディレクターがエンジニアに相談を持ちかけたとします。

エンジニアが「追加することはできます」と答えると、ディレクターは「これで仕事を依頼できた」と考えてしまうのです。

ところが、後日「例の機能は実装できた？」とディレクターが訊ねると、エンジニアからは「引き受けるとは言っていません」という言葉が返ってくるわけです。

エンジニアにとって「できます」は、あくまで「技術的に可能です」という意味なのですが、これをディレクターは「やります」「引き受けます」という意味で捉えていることがあります。

顧客の要望を具現化したいディレクターと、技術的な問題を軸に考えるエンジニアのすれ違いの典型例と言えるでしょう。

こうした言葉のニュアンスの違いは日常的によくあることと考え、「今言ったことの意味は正確に伝わっただろうか？」と振り返る習慣を身につけましょう。

要望をもらったときは、背景理由も確認する

ディレクターはエンジニアに対して、できるだけ具体的に説明したいと思っているはずです。
しかし、そのことがかえって裏目に出てしまう場合もあることを知っておきましょう。

たとえば、ある機能を実装して欲しいという要望があったとします。

ディレクターは、具体的にどんな機能なのか、何ができればいいのかを説明してくれます。

ところが、エンジニアとしては「なぜ今、その機能が必要なのだろう？」「どういう話の流れでその結論に至ったのだろう？」と、頭の中は疑問符だらけになっていたりするのです。 エンジニアとしては、技術的にどんな機能を実装して欲しいか、という伝え方よりも、顧客はどんなニーズがあってその機能を欲しているのか、という伝え方をしてくれたほうが助かるはずです。

そのニーズを満たすためにどんな機能を実装したらいいのかを考えるのは、技術的な知識の裏付けがあるエンジニアのほうが長けているからです。

そこで、ディレクターから要望があった場合は、「なぜ」その機能が必要なのか、背景理由を聞き出すようにしましょう。

「どんな機能か」ではなく「なぜその機能なのか」といったように、抽象度を上げて説明してもらうようにするのがコツです。

要件定義が曖昧なときは補足で確認する

ディレクターから仕事の依頼が来たとき、ゴールが明確になっていなければ要注意です。

たとえば「不具合が発生した」と言われても、どのような状況でその現象が起きたのか、なぜ不具合だと判断したのか、といった情報がなければ適切に対処することはできません。

エンジニアにとっては「原因が分からない以上、落としどころも一切不明」の状況なのです。

ところが、ディレクターとしては「不具合が発生した」「だからゴールは不具合を解消することだ」と考え、曖昧な点など全くなく明確に意図が伝わったと思い込んでしまうのです。

とくに要件定義に関しては、何らかの曖昧な点が残っていると開発途中やリリース後にお互いの認識がずれていることが発覚し、トラブルに発展することがあります。

曖昧なままになっていることがあると察知したら、補足で確認する習慣を身につけましょう。

必要に応じて議事録を残して共有するなどして、後になって行き違いが生じないようひと工夫を加えておくことが大切です。

できないときは、理由も説明する

ディレクターからの依頼に対してエンジニアが「できない」と返答するとき、その理由にはいくつかのパターンがあります。

エンジニアにとってはどれも合理的な理由なのですが、「それはできません」と言われたディレクターはそのように受け取っていないことがあります。

たとえば、

といった、いわば「自分本位な理由で断ろうとしている」と受け取られているケースが多々あるのです。

きちんと理由を伝えることで、少なくとも自分本位な理由で断っているわけではないことを理解してもらうことができます。

もしディレクターからの依頼内容を100％叶えるのが不可能だったとしても、即座に「できない」と断ってしまうのではなく、スケジュールの調整は可能なのか、技術的にどこまでなら実装できるのか、といった具体的な説明をひと言加え、「こちらも要望に沿えるよう努力はしている」という姿勢を見せることが重要です。

モヤモヤしたら、相手の立場になって考えてみる

エンジニアは論理的なコミュニケーションを好む傾向があります。

論理的に正しく、合理的に伝えることができていれば、コミュニケーションとして問題なく成立するだろう、と無意識のうちに思ってしまうところがあるかもしれません。

しかし、ディレクターも一人の人間ですので、感情面もコミュニケーションの一環であることを忘れてはいけません。

「こんなに論理的に説明しているのに、なぜ理解できないんだ？」とモヤモヤしたときは、ひと呼吸おいて相手の立場になって考えてみてください。

もしかしたら、ディレクター自身も顧客から無理難題を突きつけられて板挟みになっているのかもしれません。

「どうしてもこの機能が必要」と主張しているのではなく、「これに近いものならOK」と言っているのかもしれません。

エンジニアとディレクターでは仕事内容が異なりますので、抱える問題も違っています。

自分とは立場の違う相手と話していることに立ち返り、少しでも歩み寄ろうとすることが大切です。

そうすることで感情的なわだかまりが消え、コミュニケーションがスムーズに進むこともあるのです。

ディレクターとよくぶつかってしまう、なぜかディレクターが納得してくれない、といった場面が多いと感じている人は、もしかしたら自分が陥りやすいミスコミュニケーションのパターンを見落としているのかもしれません。

逆の見方をすれば、そのパターンを解消するコツをつかめば、自分にとってのコミュニケーションの「得意パターン」を確立することも可能です。

相手に原因があると決めつけず、自分の会話の傾向を振り返ってみることもコミュニケーションを円滑に進める上で大切な配慮です。

この記事で挙げたポイントに近い項目があった人は、ディレクターと会話を交わすときに「得意パターン」を見つけるつもりで言い方や聞き方を変えてみてください。

ミスコミュニケーションを解消するヒントがきっと見つかるはずです。

エンジニアのより良い職場環境探しの転職に、おすすめの転職エージェント