MAに関する情報はこちら
2016 Dec
28

149 views

【これはやめて!】エンジニアが嫌がるマーケターのコミュニケーションスタイル


2016年12月26日

皆さん、こんにちは。

最近はウェブマーケティングやデータドリブンな施策の重要性が増してきて、
マーケターの皆様もデータに触れる機会が多いのではないかと思います。

そしてマーケターの方がデータを扱うにあたって、
エンジニアや情報システム部の方に協力をお願いする場面が増えてきました。

今回はエンジニアや情報システム部の人とうまく付き合うために
彼らが嫌がるコミュニケーションをご紹介していきたいと思います。

目次
エンジニアと話す上で大変なこととは
コミュニケーションの齟齬は考え方の違いから
依頼する側の心得とは
奥の手は第三者

エンジニアと話す上で大変なこととは

他部署の人と一緒に仕事をすることは案外多いものです。
自分の専門分野だけでは進められない場合は、
必要な専門分野の力を持つ人の助力を頼むことも大事です。

マーケターの皆様もウェブマーケティングなどでテクノロジーの知識が必要になった時に、
エンジニアや情報システム部の方にデータの抽出や加工を頼むこともあるでしょう。


そんな時に起こりがちな部署間トラブルとして、以下のようなケースをよく聞きます。
「エンジニアにシステムの機能の追加をお願いしたけれど、聞き入れてもらえなかった。」
「情報システム部の人にデータ抽出をお願いしたはずなのに、一向に作業してくれない。」
「使う側のニーズをわかっていないのではないか。アウトプットが要望と違う。」


これらのトラブルはコミュニケーション不全が原因です。
エンジニアや情報システム部など他部署の人とのコミュニケーションは、
考え方も違うなど難しい部分もあります。

ではマーケターは何に気を付ければ良いのか
実際にエンジニアの方に話を聞き、
エンジニア目線でやってはいけないコミュニケーションをまとめてみました。

コミュニケーションの齟齬は考え方の違いから

〇エンジニアがイラっとするコミュニケーション

考え方や捉え方の違いがコミュニケーションの違いを生み出します。
普段の仕事内容が違う人同士では必然的に考え方や捉え方も違ってきます。

そこでマーケターのコミュニケーションをどのように感じているのか、
実際にエンジニアの方に聞いた「ここが嫌だ」というポイントを
多かったものから6つ箇条書きでまとめました。

 1, 思い付きでシステムの要望を出す人
  自分が欲しいだけの機能だったり、この案いいんじゃない程度の案だったり、
  ろくに考えていない要望を出してくる人が多いそうです。

  当たり前ですが、あれもこれもやっていたら時間が足りません。
  エンジニアの方にも時間があり、その限られた時間の中で仕事をしています。
  それなのに思い付きでポンポンアイデアを持ってこられてもできるわけがないのです。

 2, 理由や背景もなく要望だけ伝えてくる人
  「お願いなんだけど、○○やってほしいからよろしく。」
  よくやってしまうコミュニケーションではないでしょうか。
  これが一番よくある嫌なコミュニケーションだそうです。

  先ほども書いた通り、
  エンジニアは限られた時間の中で仕事をするということが染みついています。
  なので、その要望はそもそも本当に必要なのか、
  タスクに落とし込んだ時にどんなイメージになるのか、をまず知りたがります。

  「なんで」「どうして」必要なのかが明確でない要望では、
  「どんな」機能をつくればいいかわからず、作るもののイメージがわきません。
  当たり前ですが本当に必要かどうかもわかりません。

  理由も背景も欠けた伝え方をされたなら、
  その要望に割く時間はありませんということです。

 3,「なるはやでお願い」と期限を言わない人
  エンジニアにもすでにある仕事があるのです。
  要望を言うだけ言って押し付けられても困ります。

  またエンジニアの方はミスが許されない仕事柄、責任感が強い人が多いです。
  なので、工数からしてまず無理なものは無責任に引き受けるわけにいかないので、
  期限は決めてもらわないと困るのです。

  あまりにも酷い時は
  「じゃあ今ある仕事が終わってからの6か月後でいい?」と言いたくなるとか。

 4, コードを読んでいる時に中断してくる人
  これはエンジニアに話しかけるタイミングの話です。
  皆さんもせっかく集中している時に話しかけられると嫌になりますよね。

  エンジニアの方はその仕事柄、
  プログラムのコードを書いたり読んだりすることが多いですが、
  プログラムのコードを読んでいる時、特に他人の
  書いたコードを読んでいる時に中断させられるとすごいイラっとするそうです。

  大きな仕事になると多人数で一緒にコードを書くこともよくあるので、
  他人のコードを読むこともよくあります。

  他人のコードを読むのは慣れない英語の論文を読むようなものだそうです。
  なので、途中で中断されるとどこまで読んだのか、どこまで理解したのか
  これを理解して何をしたかったのかが頭から飛んでいってしまうそう。

  「作業を中断したリカバーは大変だから、ホントにやめてほしい」

 5, 言葉が通じない。いちいち説明しないとわからない人
  専門用語で話ができないから嫌だというパターンです。
  全く事前知識のないままに話に来られるとコミュニケーションコストがかかりすぎて
  時間がもったいないと思うそうです。

  例えばスムーズではない具体例を挙げます。
  マーケター「イベントで使うお客さんの個人情報が欲しいので、個人情報の一覧作成を作ってほしいです。」
  エンジニア「個人情報って何人分?それはレコードを抽出すればいいのね?どのテーブルから?抽出条件は?」
  マーケター「イベントに使うからできるだけお願い。レコード?テーブルって?とりあえず個人情報がほしい。」
  エンジニア「・・・(顧客テーブル丸ごと渡してやろうか?)」

  一方、このやりとりがスムーズな例はこんな感じになります。
  マーケター「イベントで使うお客さんの個人情報が欲しいので、個人情報の一覧作成を作ってほしいです。」
  エンジニア「個人情報って何人分?それはレコードを抽出すればいいのね?どのテーブルから?抽出条件は?」
  マーケター「施策で使うターゲット分あればいいので、該当レコードの抽出をお願いします。
        イベントに使う情報は5つなので、抽出は顧客テーブルから5カラム分お願いします。
        イベントに来る人の属性は○○なので、抽出条件もそれでお願いします。」
  エンジニア「了解です。(実際の仕事内容もイメージしやすいし、分かりやすいな。)」

  そもそも話ができないから相手にならんと思う人もいるそうです。
  これはどの業界、部署でも同じですね。

 6, システムに夢を見がちな人
  最後に一番厄介だと言われたパターンです。
  システムをなんでもできる夢のツールだと思っている人がまだまだ多すぎるそうです。

  システムを少しでも知っていればありえない、
  無理な要望を出してくる人が後を絶たないとか。

  できないと知るや、あからさまに落胆してくる人がいるのも
  ほとほと嫌になるという話もありました。

〇エンジニアからの要望
以上を踏まえてエンジニアからの要望を箇条書きでまとめます。
 1, 本当に必要かどうか考えてから要望を持ってきて。
 2, 要望だけじゃなくて、理由と背景も教えて。じゃないと引き受けない。
 3, 期限はきちんと決めて。俺らにも工数があるの。
 4, 中断すると下手すれば時間が倍かかるので、重い作業のときは避けて話しかけて。
 5, せめて単語レベルくらいの知識は勉強してきて。
 6, システムはそんな夢のツールじゃないことは肝に銘じて。

依頼する側の心得とは

〇要望を考える時

 1, まず最低限の知識は勉強しましょう。
  単語レベルで構いません。
  話についていけるように何が何を表しているのかくらいは勉強しておきましょう。

 2, 要望のスクリーニングをしましょう。
  要望のスクリーニングは費用対効果を考えて行いましょう。

  まずその要望が叶ったときの効果を考えましょう。
  また叶わないときのデメリットを考えてもいいかもしれません。
  要望が本当に必要なのか、それによってどんな効果があるのか考えましょう。

  次に費用・コストを考えましょう。
  今回で言うとその要望を叶えるためにかかる工数がコストにあたります。

  なぜそれを考える必要があるかというと、
  えてして使う側からすれば簡単な小さい機能は開発も簡単だと考えてしまいます。
  しかし、こちらとしては「簡単な機能だしすぐに機能追加できるだろう」と
  思っていても、実際の作業としてはすごく大変なものになることも多いそうです。

  それだけの開発工数に見合う要望なのかを考え、
  優先順位を考える必要があるということです。
  要望をそのまま伝えることは避けましょう。

 3, 早めにエンジニアと一緒に考えましょう。
  要望を決めてからお願いするのではなく、
  この要望はどうなんだろうというスクリーニングの段階から
  エンジニアのかたと一緒に考えてみましょう。

  前項と矛盾するようですが、矛盾はしません。
  むしろ一緒に考えることで、背景やニーズについての理解を共有することができ、
  スムーズなコミュニケーションができるようになります。

  特に要望の工数を見積もる時は、エンジニアの方の意見を聞くとよいでしょう。
  またその要望が叶ったときの評価方法と基準を考えておくとベストです。
  そうするといざ機能ができた時に要望とずれたものができてしまった 
  ということを防げます。

〇要望を伝える時

 1, 要望を伝える時は、背景理由も伝えましょう。
  なんでその機能が欲しいのか、誰が使うのか、今どんな課題があるのか、など
  背景も含めて伝えましょう。

  この時、要望は機能ベースよりは、抽象度を高くして、
  ニーズベースで話した方がよいそうです。

  そうすればエンジニアの方も一緒に
  そのニーズを満たすための手段を一緒に考えることができ、
  ことによればマーケターが欲しいと思った機能よりも
  よりよい機能を実装できる可能性が増えるからだそうです。

  それを踏まえると要望を叶えて欲しいと伝えるよりは、
  こんなニーズを満たしたいけれどどうしたらいいだろうか、と
  相談するスタンスがちょうど良いでしょう。

 2, わからないことは質問しましょう。
  事前に勉強してこいとは言うものの、限界はあります。
  エンジニアとしてもそれは知っているので無茶は言いません。

  また相手は基本的にその道のエキスパートです。
  敬意をもってわからないことは聞きましょう。
  そうすることでコミュニケーションがスムーズになるだけではなく、
  お互いの関係を築くことができます。

 3, 詳細まで明確にしましょう。
  責任領域のグレーゾーンが「こんなはずでは」を生み出します。

  マーケター側からすれば要望を叶えてくれれば達成方法は任せる、と
  エンジニア側からすれば要望が多すぎるから言う通りにだけする、と
  その結果が結局使えるものができあがらないという結果につながるのです。

  どこまでが要望を出す側の責任なのか、
  どこまでがエンジニア側の責任なのかをすり合わせることが必要です。

  それがないとずれができてしまうので、詳細まで明確にすることを意識しましょう。

 4, 議事録を取りましょう。
  いくらコミュニケーションをうまくやって、認識をすり合わせても
  認識のずれがある可能性が全くないということはありません。

  なので、ずれがあると思って議事録を取るなど対策を取りましょう。
  このように何かしら対策を取った方がお互いのためです。

〇要望を伝えた後

  1, 感謝を伝えよう。
   とかく忘れがちになりますが、感謝を忘れないようにしましょう。
   打ち合わせ後には「ありがとう」を忘れずに。

奥の手は第三者

いかがでしたでしょうか。一言で要約してしまえば
相手のことを考えたコミュニケ―ションをとりましょうということです。

コミュニケーションとしては当たり前な話ですが、
考え方が違う人同士が話をするときはこれができているかどうかですごい違いがあります。

コミュニケーションのずれが常態化しすぎて
部署間に溝ができているという話も聞きます。
自分たちで解消できればよいですが、難しい場合は第三者を介在して話をしてもよいでしょう。
仲裁者がいるだけでも大きく前進することもあります。

MPの導入で情報システム部の協力が必要、だけど普段から仲が悪くて・・・
そんな場合は導入にあたって部署間の調整もしてくれる
フォローがあるところを選ぶのをお勧めします。


【この記事を読んだ人はこちらもチェックしています】

2016.12.28149 views
【これはやめて!】エンジニアが嫌がるマーケターのコミュニケーションスタイル
2016.12.1442 views
【ゴミ箱行きレポートを削減】分析を施策に活かせない理由
2016.11.02273 views
【MAの導入ってどれくらいかかるの?】スムーズにMAツールを導入するポイントとは
2016.10.06208 views
【あなたのデータは大丈夫!?】ツール導入の前に認識するべきデータの罠
2016.09.051,762 views
【知らなければ失敗する!!】MAで必須のCRM成功条件とは
2016.08.26181 views
B→Dash活用事例集「美容関係~WEB・店舗間の送客、休眠客の引き上げ~」リリース!

B→Dashの資料請求はこちら