エンジニアのためのビジネスコミュニケーション技術入門
概要
プロジェクトマネージャーとして仕事をしていると、コミュニケーションの取り方1つで、その後数ヶ月に渡っての開発内容や開発効率に大きな影響が出ると強く感じます。
ここ数年、プロジェクトマネージャーとして他職種の人と会話する機会が多かったので、コミュニケーションを取る際に意識していることをまとめます。これからPMやリードエンジニアとしてのキャリアを考える人の参考になればと思います。
エンジニアの話はわかりづらい
誤解をおそれずに言えば、営業や企画の方（以降ビジネスサイドと記載します）はエンジニアと話が噛み合わないと考えています。
- いつできるか聞いているのに、仕様の確認ばかりされる
- 「技術的には可能です」の意図が不明（できるならやってくれと思ってしまう）
- etc...
これは極端な例ですが、ビジネスサイドの人がエンジニアと話が噛み合わないと思っていることはよくあります。
イマイチ会話が噛み合わないのは、職種によって前提条件と目の前のタスクの食い違いが出るためです。
ビジネスサイドはWhatを考え、エンジニアはHowを考える
ビジネスサイドの関心事は 「売上が上がる機能は何か」「その機能を作ることでどれくらいの売上を上げられるか」 です。一方、エンジニアの関心事は、 「ビジネスサイドから提案された機能をどのように実現するか」「エッジケースの仕様をどうするか」 です。
関心事の違いによって、コミュニケーションに齟齬が発生するのは容易に想像がつきます。
ビジネスサイドからエンジニアに期待することとしては、
- 自分たちの提案で抜け漏れている観点がないか
- 現状の実装を踏まえ、より機能をライトに実現する方法がないか
- それらを実現する工数はどのくらいか
といったことです。決して提案した仕様を決められたスケジュールで作りあげられることだけではないのです。
ビジネスサイドからエンジニアに寄り添うのが難しい理由
ビジネスサイドは、顧客の要望を通しておおまかな機能の方向性を考えますが、「作るプロ」ではありません。
したがって、
- 機能開発のために必要な情報を十分に提供できているのか判断できない
- 仕様をまとめるにしても、体系的なまとめ方を定められない
といった問題が発生します。（一部の事業会社では、仕様を上手くまとめられる人もいますが、経験上、数は多くありません）
なので、そうしたノウハウが十分に溜まっていない企業では、エンジニアからある程度ビジネスサイドの意図を汲み取りつつ仕様策定・開発を進めていくのが、上手くプロジェクトを回すための最適解になるケースも多いです。
補足：ビジネスサイドを考えるとはどういうことか？
先程、ビジネスサイドは作るプロではないという話をしましたが、エンジニアも事業を考えるプロではないため、ビジネスサイドの意見を十分汲み取ることは難しいのでは？と思われるかもしれません。
確かにそれは一理ありますが、 費用対効果 を上手く説明できると概ねビジネスサイドとのコミュニケーションが円滑になります。
例えば、ある機能開発でスケジュールに間に合わなさそうな仕様に決まりそうになったとします。
その場合、「単純にスケジュールが間に合わない」と提案を跳ね返すのではなく、「エンドユーザーに届ける価値（効果）に対してエンジニアの稼働工数（費用）が割に合わない気がするがどうか？」と伝えるだけで、ビジネス上ベストな選択を行う状況に一歩近づきます。
一般的にエンジニアの給料は安くありません。エンジニア経験5年程度のフリーランスで言えば、1日稼働をお願いするだけで3~5万円の費用がかかります。追加機能開発に1週間かかるとすれば、その機能開発には15~25万円のお金がかかるわけです。
それに見合うだけの機能なのか？を頭に入れた上で提案すると、話をスムーズに進められます。
良いコミュニケーションを取るTips
エンジニアがビジネスサイドの人と上手くコミュニケーションを取るtipsをいくつか紹介します。
ビジネスサイドの人は一緒にサービスを作る仲間
大前提ですが、エンジニアの人が勘違いしてはならないのは、私達の作ったものはエンドユーザーが利用するのであって、 ビジネスサイドの人に評価されるものではないということです。
営業 vs エンジニア や 企画 vs エンジニア となっている企業もありますが、そのような状況になっているプロジェクトは、ほぼ100%良いプロジェクトにはなりません。
ビジネスサイドの人は開発にあれこれ言ってくるかもしれませんが、エンジニアが作った機能に文句を言いたいのではなく、ユーザーに正しく価値が届かないと感じるために修正案を出すのです。
エンジニアとしても作るプロである以上、最終的にサービスを利用するエンドユーザーの価値に繋がるか？は考える必要があるでしょう。
機能提案・仕様提案を行うときは前提の説明から
コミュニケーションの苦手な人は、「なぜそのような提案をしているのか？」をすっ飛ばして、いきなり自分の考えを伝える傾向にあります。
当然、ビジネスサイドの人からすると寝耳に水なので受け入れがたい提案になってしまいます。
そのため、
- 提案の背景（技術的な課題、ビジネス的なメリット、UX、etc...）
- 提案の内容（どのような変更を加えるのか）
- 影響範囲（それによりエンドユーザーにどんな影響が出るのか）
をセットにして話を進めましょう。面倒に思われるかもしれませんが、これらを説明しないとSlackのやり取りが無限に増えて逆に時間効率が悪くなります。
仕様を伝えられた際は表現を変えて聞きなおす
意外と多いのが、ビジネスサイドから伝えられた内容を正しく認識できていない状態で開発を進めてしまったパターンです。
これを防ぐためには、面倒でも仕様についての相談を実施された後に「xxxという理解で合ってますよね？」と別の表現で聞き直しておくことです。
聞き直すことで伝えられた仕様に関する文章を書きなおすことになるため、曖昧な箇所があればすぐに気付けますし、ビジネスサイドの理解に誤りがあれば早期に気づけます。
一般的にソフトウェア開発は 後工程になるほど修正に工数がかかる ため、仕様が決まった時点で正しく理解しておくことが、プロジェクト全体の工数を小さく抑える鍵になります。
まとめ
ビジネスサイドとの基礎的なコミュニケーション手法について記載してきましたが、正直コミュニケーションが一朝一夕で上手くできるようになるものではありません。
ただし、プロジェクトに携わる全員がビジネスサイドとのコミュニケーションを上手くできるようになると、プロジェクト進行が格段に効率良くなります。
その結果、
- 計画通りにプロジェクトが進む
- 狙った顧客課題を解決する機能を作れる
- エンジニア・ビジネスサイド双方とも余計なストレスを抱えずに済む
- 残業が減る
などなど、自身の生活にも良い影響が出てきます。
なんとなくコミュニケーションが苦手だな…と思われている方も、コミュニケーション能力は後天的に身につけられるものと思って、これからの仕事を前向きに進めていただく一助となれば幸いです。
Discussion