仕事で大事な能力はいろいろありますが、もっとも大事なことは相手が望むことをつかむ力です。
この人が実現したいことは何だろうか？
この人が大事にしているのは機能だろうか？コストだろうか？納期だろうか？
社内の説得に困っているのだろうか。
そういった、相手が解決して欲しいことを的確につかみそれを解決できるように進めて行くことは相手の信頼を得ることにつながります。
「あの人に頼んでおけば、私のやりたいことを実現してくれる」
そう思われたら勝ちです。
相手が望むことがつかめなければ仕事にならない
相手の望むことをつかむ、と聞けば、そんなの当たり前でしょう、と思うと思います。
ただ、本当に相手の望むことを聞き出してつかむ能力は一朝一夕には身に付きません。
それどころか、下手をすれば「あいつはわかってない」と思われかねません。
世の中には相手のことを敏感に感じ取って、それはこうやって解決できますとという提案をできる人たちがいますが、誰でもできるわけではありません。
特にエンジニアは、どうやって実現するかばかりを考えてしまって、本当にお客さんが望んでいることを見落としがちです。
どうやって実現するかはエンジニアの大事な仕事ではありますが、その前に相手の望むことに添えるような能力を身に付けましょう。
システムの都合を理由にしない
ITエンジニアはついついシステムのせいにして理由を言いがちです。
例えば、
OSが・・なので△△できません。
クラウドサービスが××なので、○○できないです。
こんなことを言っていませんでしょうか？
お客さんは「できない」理由を聞きたいわけではないのです。
どうしたらできるか知りたいのです。
ですので、できないことや懸念があるなら、「できます！ですが、こういう懸念があります」という風に制約や難しい理由をあとで付けるのです。
○○すればできます、ただし時間がかかります。
今使っているものだと××できませんが、△△に変更することでできるようになります。ただ、かなり手戻りになります。
といった感じです。
前提条件はに縛られすぎてはいけない
相手が望むことが「できる」か「できない」かを考えるとき、実現の前提条件が自然と頭の中にあります。
それには「リリース納期」「開発予算」「投入できるリソース」などがありますが、これらはプロジェクトにとってどうやっても変えられないものではありません。
エンジニアの立場で言えば、納期などは絶対に変更できないものだと思うことも多いのですが、立場が違う人から見るとそれは全く制約でなかったりします。
ましてやどんな技術を使うか、どんなサービスを利用して実現するか、といったことはエンジニアが勝手に思っていることも少なくありません。
一旦、自分の中に勝手に思っている制約を取っ払って、何が制約条件かを聞くところから始めることも必要です。
要求を確認しながら進める
相手が実現したいことに対し、自分の理解が正しいかをちょくちょく確認しましょう。
理解しているつもりでいても、細部で違うことがよくあるからです。
実現方法を少しずつ明らかにしていく過程で、開発にかかるコストやできあがる納期に加え、実運用にかかる費用なども少しずつ見えてきます。
開発費がこのくらいになりそうとか、Webサービスやアプリのイメージはこんな感じですとか、作った後もこのように改良していきますとか、いろいろなことを決めていきます。
その中で、自分が理解していてこの実現方法でいいと思っていても、具体的にすればするほど相手の理解とのずれが見つかってきます。
なぜかと言えば、これまで非常に簡単な言葉でしか相手の要求を聞いていないからです。
ところが、具体的に実現方法を決めていくと、「それは考えていることと違うなぁ」とか「それだとダメなんだよ」というような話がいろいろと出てきます。
これを適宜聞いて軌道修正していくことが欠かせません。
よくあるケースは、できあがってから「それは違う」と言われること。
こうなったらプロジェクトは大失敗です。
望まれていることと実現できたものにズレがあるのは避けられませんが、そのズレをいかに小さくするかが大事です。
そのためにも、都度確認していくことが欠かせない作業です。
そうやって相手の望みと自分の理解のズレを修正していくのです。