個人的メモ(ナレッジ)その2

今回は個人的ナレッジの紹介パート2です!



この個人的ナレッジは2回目になるのですが、またやろうと思ったのは何故かと言いますと。

 

実は前回の記事で思いの外、嬉しい感想を沢山もらえたからなんです!

 

※前回の記事はこちらです。まだの方は是非読んでみて下さい!

個人的メモ(ナレッジ)

 

そこで調子にのって2回目をやろうと思った訳です!


ちなみに、今回のナレッジはエンジニアとのコミュケーションに特化してみました!

 

IT業界で営業をやられている人は、この辺苦労してませんでしょうか?

 

今回の記事は、そんな人たちの、何かヒントになれば良いなって思ってます。


 

エンジニアはどんな事が嫌なのか?この辺の話をランキング形式で紹介していきます!

 

何を考えてるのか?実際どうして欲しいと思ってるのか?

 

エンジニアの目線を知る事が、コミュニケーションの糸口になると思います。

 


 

第3位:メールをそのままエンジニアに転送

 

これはメールの内容を理解せず、お客様のメールをそのまま右から左へ流す事を指します。

 

よくあるのが「確認お願いします」だけ書いて、そのままお客様のメールをエンジニアに転送する事。

 

「FW:〇〇の件の質問」こういうの見るだけでイラっとする人多かったりするぞ

 

こちら普通にやってる方、多いかもしれません。

 

しかしこれをやると「この人は、質問を理解するつもりが全くない」と見なされてしまうんです。

 

でも、大体これをやる人は、本当に丸投げする気満々だと思う。

 

エンジニアができるのはあくまで「回答」

 

話の整理は、お客様に近いポジションの方が、行うのが適切です。

 

整理されていない質問は「何がしたいのか?」がよく解らないので、すごく回答に困ります。

 


例えば、お客様が製品の仕様を誤解していたら、質問の意図がよく解らない状態になっています。

 

それに、毎回丸投げメールだと、何度も同じ質問が飛んでくる事が予想されます。

 

質問には「知識」で回答してる訳ではありません。

 

どうすればお客様の不明点を解消できるか、毎回「知恵」を絞っています。


なので、適切な回答をするには、できるだけ状況をイメージしなければいけないんです。

 

そのためには「5W」の情報が可能な限り必要なんですよ・・。


 

ちなみに、この様に転送だけをする行為を【効率】というずるい言葉で片付けようとすると、対立が起きるので気を付けましょう!

 

これをやると、内部のエンジニアと、外部のお客様に挟まれる事になり、結果非効率になります。

 

コミュニケーションと効率化は別な話なんだと思う。

 

適切な回答が解らないのは、エンジニアだって一緒なんです。

 

なので、可能な限り「いっしょに考える姿勢」を忘れないであげて下さい。

 

これを意識するだけで、エンジニアとのコミュニケーションの質は、かなり変わると思います


 

第2位:具体性が無さすぎる相談

 

これは、エンジニアに相談をするとき、大事な注意点です。

 

特にお客様からの要望を、エンジニア伝えるとき重要になってきます。

 

例えばよくあるのが「こんな機能が欲しい!」を一言だけしか伝えない事。


今後の参考程度で共有します。って話なら、それだけでも良いです。

 

でも、本気で要望を通したいなら・・

 

  • どんな操作(運用)イメージなるのか?
  • 最終的に何をするためにそれが必要なのか?
  • 良い回避策は本当にないのか?

 


 

最低限ここまでの情報がないと、実現できなかった場合の代替え案の提案も難しくなります。

 

本気で実装するなら、可能な限りの具体化・可視化が必要です。

 

具体性がなく、自分でもボンヤリしたイメージしか持ててないと、相手に伝わりません(というか相手にされてないかもしれません)

 

システムはロジックで動いています。

 

ロジックが破綻している様なものは、残念ながら実装ができないんです。


 

ポイントは、具体的な利用イメージと、ゴールを自分の中でも、絵書けるようにしておく事です。

 

「そんな難しい事できないよ」って思う方いるかもしれませんが、慣れれば難しい話ではありません。

 

少しでも、具体性を持った相談ができれば、コミュニケーションも楽になるので、まずはやってみましょう。

 

 


 

第1位:お客様の意見は全て「正」

 

お客様のやりたい事ができれば、使ってもらえると思うのは、普通の事だと思います。

 

だからと言って、お客様の言う事を全て「正」とする考え方は果たして正しいのでしょうか?

 

例えば「お客様がこういったから正しい」という言い方をする人、よくいらっしゃいます。

 

これは別に間違ってませんが、この部分は、もう少し視野を広げ、俯瞰で考える必要があります。

 


製品やサービスには「仕様」というものが定義されています。

 

仕様は、ある程度汎用的に考えられていますが、全てのユーザーには合致しません。

 

従って、製品/サービスを利用するには、お客様の運用を、仕様に合わせてもらう必要があるんです。


 

A社は仕様の改善を強く要望しているが、B社は改善してほしくないケースだってあります。

 

この様な事もあるので、エンジニアは、常に以下の点に問題がないか考えて、改修を検討しています。

 

  • それで製品/サービスがよくなるのか?
  • 個別すぎる改修になってない?
  • 仕様変更したら問題は発生しない?

 


 

なので「お客様が言ってるんだから正しいでしょ!」←こう言い方をすると、実はすごく警戒されます。

 

では、どうすれば良いかと言いますと。

 

まずは、製品・サービスの仕様、動作、想定された利用方法を正しく理解して下さい。

 

そして、お客様の意見だけではなく、自社の事情や仕様を含め、俯瞰的に見れるようになりましょう。


お客様の「出来る/出来ない」だけを判断基準にしない事が、重要なポイントです。

 

「出来る/出来ない」だけで先行して判断すると、強引に「出来る」を実現しようとしてしまいます。

 

これは、無理なシステム連携や、強引な仕様変更の要求につながり、結果的にお客様の利便性を低下させる原因にもなります。

 

私の経験上、この行為は、最終的にエンジニアからだけではなく、お客様の信用もなくすので注意しましょう。

 


エンジニアは、こういう事も、実は論理的に予測した上で意見を言ってます。

 

製品・サービスをよく理解し、自分の目の前の話だけではなく、俯瞰的な目線を持てれば、適切な相談が可能となり、安全な導入に繋がります。

 

エンジニアを守る事が必要

 

RPGで表現しますと、現場のエンジニアは、魔法使いの様な「後衛職」

 

そして、営業は戦士の様な「前衛職」

 

セールスエンジニアは、魔法戦士とか赤魔導士の様な「中衛職」なのではないかと私勝手に思っています。


若かりし頃、炎上すると、強い語気でマウントをとって、エンジニアに丸投げして、お客に首を差し出す営業の方、よく見かけました。

 

これって「魔法使い」を盾にして戦う「戦士」と同じ行為なんじゃないかと、私は思うんですよね・・。

 

そんなPTの戦い方で、ラスボスに勝って結果を出せるのでしょうか?私は出せないと思います。


営業とエンジニアが、円滑に連携を取れている会社は、しっかりと前衛ポジションの人達がエンジニアを守っています。

 

エンジニアをちゃんと守れていない会社の製品/サービスは、質が悪くなる傾向があるのも、こういう背景があります。


エンジニアから信頼されていれば、先回りして、リスクを含め色々な情報を教えてくれるようになります。

 

こうやって、良い連携が生まれ、製品/サービスの質も向上していきます。

 

つまり、エンジニアとのコミュニケーションは、彼らの事情を知り、理解する事がとても重要なんです!

 


 

最後に

 

今回も余談で締めますが「よっしーTECH」なのに【Technology】の話があんまりないぞ?って思ってる方いませんか?

 

違うんです!うちが発信したいのは、テクノロジーじゃないんです!

 

よっしーTECHが発信したいのはテクニック【Technique】の方なんです!


 

うちは、IT業界の悩み多き「駆け出しエンジニア」と「非エンジニア」の人物像をこっそりペルソナに設定して作っています。

 

こういった人達をターゲットに「ちょっとした技術の話」「あるある話」「テクニックやヒント」を発信するのがうちのブログなんです!

 

なので難しい事を書くつもりはありません!


あなたの暇つぶしのお供に、これからも「よっしーテクニック」を読んでみませんか!

※2週に1回くらいのペースで更新してます

 

よっしーテクニックってダサっ・・
黙れ小僧
ブクマ・SNSのシェア・フォロー大歓迎だぞう

 

関連書籍(今回のテーマに近い書籍)

フォロー待ってます!
シェア大歓迎!

コメントを残す

メールアドレスが公開されることはありません。