最近はウェブマーケティングやデータドリブンな施策の重要性が増してきて、マーケターの皆様もデータに触れる機会が多いのではないかと思います。
そしてマーケターの方がデータを扱うにあたって、エンジニアや情報システム部の方に協力をお願いする場面が増えてきました。
今回はエンジニアや情報システム部の人とうまく付き合うために彼らが嫌がるコミュニケーションをご紹介していきたいと思います。
〇エンジニアと話す上で大変なこととは
〇コミュニケーションの齟齬は考え方の違いから
〇依頼する側の心得とは
〇奥の手は第三者
エンジニアと話す上で大変なこととは
他部署の人と一緒に仕事をすることは案外多いものです。
自分の専門分野だけでは進められない場合は、必要な専門分野の力を持つ人の助力を頼むことも大事です。
マーケターの皆様もウェブマーケティングなどでテクノロジーの知識が必要になった時に、エンジニアや情報システム部の方にデータの抽出や加工を頼むこともあるでしょう。
そんな時に起こりがちな部署間トラブルとして、以下のようなケースをよく聞きます。
「エンジニアにシステムの機能の追加をお願いしたけれど、聞き入れてもらえなかった。」
「情報システム部の人にデータ抽出をお願いしたはずなのに、一向に作業してくれない。」
「使う側のニーズをわかっていないのではないか。アウトプットが要望と違う。」
これらのトラブルはコミュニケーション不全が原因です。
エンジニアや情報システム部など他部署の人とのコミュニケーションは、考え方も違うなど難しい部分もあります。
ではマーケターは何に気を付ければ良いのか。
実際にエンジニアの方に話を聞き、エンジニア目線でやってはいけないコミュニケーションをまとめてみました。
コミュニケーションの齟齬は考え方の違いから
エンジニアがイラっとするコミュニケーション
考え方や捉え方の違いがコミュニケーションの違いを生み出します。
普段の仕事内容が違う人同士では必然的に考え方や捉え方も違ってきます。
そこでマーケターのコミュニケーションをどのように感じているのか、実際にエンジニアの方に聞いた「ここが嫌だ」というポイントを多かったものから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の導入で情報システム部の協力が必要、だけど普段から仲が悪くて・・・
そんな場合は導入にあたって部署間の調整もしてくれるフォローがあるところを選ぶのをお勧めします。
弊社が提供している マーケティングツール『b→dash』 は、マーケティングプロセス上に 存在する全てのビジネスデータを、ノーコードで、一元的に取得・統合・活用・分析することが可能なSaaS型データマーケティングプラットフォームであり、BtoC業界を中心に、様々な業種・業態のお客様にご導入頂いております。
