「クライアントやビジネスサイドが開発コストを理解していない」「納期が短過ぎる」など、調整すべき事柄が生まれやすいのが開発の現場。そんな時も「コストがなかなか理解してもらえないから…」などと諦めていないだろうか。こうしたときに身に付けると強いのが「交渉力」だ。
この連載はビジネスナレッジの動画学習サービス「グロービス学び放題」などを提供するグロービス・デジタル・プラットフォームの開発マネジメント責任者の末永昌也氏が、プロダクトマネージャー（PdM）・エンジニアがいま学ぶべきビジネス知識を紹介していく。第2回は、エンジニアが身につけるべき交渉術について解説する。（前回の記事はこちら）
交渉は何気ない普段の会話から始まっている
ユーザーが本当に欲しいものを作り上げるためにも、エンジニア側は交渉力・調整力を持つことが必要だ。
ウォーターフォール型の開発現場では、エンジニアに最後の工程で依頼をされるため、交渉余地がなくなってしまっていた。しかし、これからのエンジニアは企画段階など、前段の工程で意見を伝えるべきだ。開発者の観点から、しっかりとプロダクトに対する意見を伝えることで、ユーザーニーズに沿ったものづくりができる。
とはいっても、「伝える機会がない」「どう伝えていけばよいか分からない」という課題を抱えている読者の方も多いのではないだろうか？実は普段のコミュニケーションからできることがある。
例えば、クライアントやビジネスサイドから「〇〇という機能が欲しい」という要望が出た場合、「その機能はないとだめですか？」「その機能とは、さらに具体的に言うと何ですか？」という視点を変える質問を返すことがお勧めだ。往往にして「こういう機能がないといけない」という思い込みに陥っている可能性もある。「あった方がいい」という程度の機能であれば基本的にいらない。過去の調査で64%の機能はほとんど使われないというデータもある。
開発側とビジネスサイドの双方が普段から、「なぜそのプロダクトや機能が必要なのか？」という問題意識を持つことで、チームでよりユーザーにとって役立つプロダクトを開発することができる。「Aという機能とBという機能がある場合、どちらが大事ですか」など、相手が選択できるように問いかけをしていくと、実現したいことの意義が明確になっていくだろう。
実は、このような交渉の考え方はフレームワーク化されている。交渉が妥結できる範囲を「ZOPA（ゾーパ）」、交渉が妥結しなかった場合の次善の策のことを「BATNA（バトナ）」と呼び、交渉が妥結する範囲を探りながら調整していくという交渉のビジネスフレームワークだ。ビジネスサイドと議論を積み重ねることで、相手が許容できる範囲をクリアにしていくことにもつながる。
単に機能を開発するのではなく、「品質とスピード、要件のなかで何を大切にするか？」など、ビジネスサイドが見えていない論点を示すことも開発者の役割だ。
