エンジニア女子の日常

エンジニア女子が本、映画レビュー、ダイエット、仕事、技術について書いているブログです。

エンジニアが交渉術を学んだら、要件定義が楽になった話〜「大学生のための交渉術入門」読んでみた〜

なぜ営業でもないエンジニアが、交渉術に興味持ったのか?

私が以前、自己紹介のブログでも書きましたが、WEBエンジニアとして働いています。

 自己紹介ブログ↓

reviews.hatenadiary.jp

 

WEBエンジニアの私がなぜ、交渉術に興味を持ったかというと

 

企画者(=依頼主)とのコミュニケーションをもっとうまく取りたいと思ったからです。

 

というもの、新しくアサインされたPJでは、企画者はいたのでですが、ほぼ仕様という仕様はなく

「〇〇みたいのを作って欲しい」

といった要望のみでした。

だからといって全てを仕様の決定を全て託されるわけではなく、、、。

エンジニア側が仕様を考えて、企画者に提案していかないといけませんでした。

 

そこで、少しでも企画者とのコミュニケーションを円滑にし、エンジニアとしてやりやすい形に持っていきたいと考えました。

 

そのため、交渉術を学ぶことにしました!!

ですが、交渉術を学んだことがなかったので

を読んでみることに。大学生向けだし、分かりやすいかなっと。

 

 

「大学生のための交渉術入門」の内容

先に、「大学生のための交渉術入門」の内容について軽く説明したいと思います。

交渉で目指す理想像とは?

交渉とは、何かしらの問題を解決するために行われます。

ですが、問題解決には、自分と相手の対立や衝突が起き、葛藤が生まれます。

 

その葛藤を理解するのに、「シュミットの葛藤処理モデル」がヒントをくれます。

コンフリクト対処モード, シュミットの葛藤処理モデル

引用:https://accreteworks.com/publicseminar-latestinformation/conflictpattern

シュミットの葛藤処理モデルでは

縦軸が、「どれくらい自分の利害を主張するか」、

横軸が、「どれくらい相手の利害を考えられるか」

を表しています。

 

シュミットの葛藤処理モデルからヒントを得ると

エンジニアと企画者共に、目指したい理想像は「協働」状態ですよね。

 

「協働」という交渉での理想状態になるには

「自分のことだけではなく、相手を考える」

が重要そうです。

 

交渉で具体的にどういうことをすれば、協働の状態になるのか?

相手のことを考えることが重要とわかったところで、

どうすれば、相手の利害も尊重をしながら、自分の利害も捨てないようにできるのでしょうか?

 

 

それは「協調する」ことです。

協調とは、利害が対立したもの同志が、穏やかに問題解決すること指します。

(以後、協調する交渉のことを、「協調交渉」と呼びます。)

 

協調交渉での重要なことは?

協調交渉では

  1. 相手の考えに同意をする必要はないが、相手を尊重し、相手の能力を認める
  2. 相手の考えや価値観を理解する
  3. 双方で協力して相違点を明らかにし、様々な見方・考えを統合して解決策を導く

がことが重要です。

そこで、協調交渉での取るべき具体的な行動は

  1. 友好的な雰囲気作り
  2. 争点を明確にする
  3. 問題を見直し、最優先事項を絞り込む
  4. 代替案を提示し、双方が合意する

です。

こうした協調交渉での具体行動をする時には

  1. 相手との信頼形成に不可欠となる相手の考えにノーと言うべきときは言い、しかも、相手の能力を認める
  2. 双方の問題を合意に導くプロセスで必要となる、相手の見方を理解しようとする
  3. 意思決定や問題解決に不可欠な相違点を明らかにし、双方の考えを統合する

を意識することが大切です。

 

「大学生のための交渉術入門」読んで、要件定義に生かしたこと

「大学生のための交渉術入門」の内容はなんとなくわかってもらえたと思います。

では、私はどうやって交渉術を生かして、要件定義をしていったのかを共有します!

 

1. 企画者からヒアリング

交渉では、相手を理解することが大切なため、ヒアリングをたくさん行いました。

ヒアリングでは、

「〇〇みたいのを作って欲しい」

という要望を噛み砕くため、「どうして〇〇みたいのが欲しいのか」「なぜ〇〇みたいのがいいと思ったか」など、細かくヒアリングを行いました。

 

その結果、「〇〇みたいのが欲しい」のではなく、「こういった機能があるツールが欲しい」という本質的なニーズを知ることができました。

 

本質的なニーズを知ると、必要な要件(=最低要件)が見えてくるだけではなく、企画者の価値観を理解することができました。

 

2, ヒアリング結果から要件をまとめて提案からの合意

ヒアリングから最低要件をドキュメント化を行いました。

ドキュメントにまとめることで、ヒアリングが不十分だったところが可視化することができました。

 

不十分だったところに関しては、

「争点」として定義し、交渉を行いました。交渉の中では、優先度を定め、優先度に沿った代替案を提案しました。

 

交渉をした結果、エンジニア側も企画者側も「この要件にしよう」といった感じで、合意することができました。

 

システム開発の外注なら、複数社を完全無料で比較できるシステム開発一括.jpで。

 

交渉術を使って、要件定義をしてみると、、?

最初に「〇〇みたいのを作って欲しい」と言われた時は、「まじか、、」と思いました。ʅ(◞‿◟)ʃ

ですが、交渉術を知ると、要件定義が楽に行うことができました。

 

エンジニア側の利害を無視し、企画者側の利害を優先し、「順応」することや

エンジニア側も企画者側の利益も中間をとって、どちらか「妥協」すること

は簡単ですが、お互いが「協調」を意識して、交渉していくことで、

コミュニケーション工数を減らすだけではなく、精神的なストレスの軽減に繋がったと思います。

 

サービス開発をするエンジニアの多くは、企画者との調整は必ず存在すると思います。調整する際は、交渉術を生かし、話し合ってみたらどうでしょうか?

 

エンジニアと企画者の要件についての交渉中の様子

エンジニアと企画者の要件についての交渉中の様子