プロダクトマネージャーとして「交渉」や「調整」で意識しているポイントあれこれ
LIFULLの諏訪です。LIFULL HOME'Sにおいて、プロダクトとビジネスの境界であれこれ調整する役割を担うことが多い人です。好きなアイドルマスターシンデレラガールズの楽曲は『私色ギフト』です。
本記事はQiitaでやっている 🎄LIFULL Advent Calendar 2022🎄 の16日目の記事です。一周回って干支が同じになるぐらいの後輩から「お前もなにか書け（大意）」という話を受けまして、noteからの特別参加という形で失礼いたします。
はじめに
先日、界隈で話題を集めていた『プロジェクトマネジメントの基本が全部わかる本』を私も読ませていただきました。本のタイトル通り「基本」が押さえられており、初めてプロジェクトマネージャー、もしくはそれに類する役割を任された人に特におすすめできる内容です。
特に印象深いのは、やはりこちらの件です。第2章の冒頭から「交渉はなぜ必要なのか」「交渉はなぜ難しいのか」ですからね。ちょっと興奮してきましたね。
ところで、「交渉」あるいは「調整」はプロジェクトマネジメントだけでなくプロダクトマネジメントにおいても非常に重要なタスクでありスキルです。
プロダクトマネジメントと「交渉・調整」
プロジェクトはその目標や進め方について様々な利害関係者と交渉・調整して合意に至る必要がありますが、これは当然ながらプロダクト（マネジメント）においても同様です。内製で開発・運用されている自社プロダクトであっても、以下のような理由から関係者間で利害が衝突し交渉・調整が必要になることは少なくありません。
エンジニアやデザイナー、その他のメンバーと意見が食い違うケース（プロダクト開発チーム内での交渉・調整）
プロダクトが他のプロダクトから完全に独立しておらず、プロダクトに手を入れることで他のプロダクトにマイナスの影響が発生するケース（プロダクト間・組織間での交渉・調整）
プロダクト観点で解決すべき課題の優先順位と、マーケティングや営業の観点から解決すべき課題の優先順位が異なるケース（職種間・ミッション間での交渉・調整）
プロダクト主導な会社・組織であり、かつプロダクトの独立性が高い場合は交渉や調整の機会は少なく難易度も小さいはずですが、実際には日々交渉や調整に苦心しているプロダクトマネージャーも多いのではないでしょうか。
というわけで大変前置きが長くなりましたが、私が普段プロダクトに関する交渉・調整で意識している（あるいはチームメンバーに意識してもらっている）ことを、弊社がプロダクトマネジメントの教科書としている『INSPIRED』の記載も参考にしつつご紹介したいと思います。
交渉や調整で意識しているポイント
以下のようなことを意識しています。
ビジョンを意思決定の指針にする
交渉・調整の相手のことを深く理解する
「最後は私が決める」に耐えうる信頼関係を築く
貸し・借りをつくらない
ビジョンを意思決定の指針にする
開発チーム内での交渉や調整であればプロダクトビジョンを、チーム外を含むものであれば組織のビジョンやガイドラインをもとに、交渉・調整の落としどころを決めましょう。意見 vs 意見のディベート状態になることを避け、ビジョンに向けて最適な着地点を一緒に探ろう、というスタンスを取ることが大事です。
言いかえれば、私が落としどころを決めているのではなくビジョンが落としどころを決めているのだ、というスタンスです。多少強引であっても「ビジョンで○○と言っているので、今回はこの方針で」といった決め方・言い方ができるのが望ましいです。（もちろん、言い方がそうなっているだけで、その決定の責任は当事者 - プロダクトでいえばプロダクトマネージャーにあります）
プロダクトビジョンについては、INSPIREDでは以下のように書かれています。
その主な目的は、ビジョンを伝え、製品開発チーム（そしてステークホルダー、投資家、パートナー、および将来の顧客）がそのビジョンの実現を手伝いたくなるように動機づけることだ。
チーム内外のステークホルダーに「ビジョンの実現を手伝いたい」と思ってもらうためにも、普段の交渉・調整からプロダクトビジョンを用いることでビジョン実現への本気度を示すことは大事です。ビジョンは額に入れて飾るのではなく（日々の交渉・調整・意思決定に）普段使いしていきましょう。
交渉・調整の相手のことを深く理解する
相手のビジョンはもちろん、現在進行形で何をやっているか、最も困っていることは何か、といった情報をインプットしておくことで、交渉・調整はとても容易になります。当たり前のことのように思えますが、これを怠って交渉・調整が自分たちの立場や意見の押し付けになってしまっているケースが、特にチーム外との交渉・調整において稀によく見られます。
例えば、弊社では理想とするエンジニアの在り方として「エンジニアとして経営をリードする」というエンジニア像を打ち出しています。この言葉とその意味合い、例えば「経営をリード」とはどういうことなのか？を理解しておくことで、チーム内外のエンジニアとのコミュニケーションは格段にスムーズになります。
上記note記事のように外部発信されている情報は、相手の人となりや組織の在り方について知る大きな助けになります。そうした情報がなくても、社内で公開・共有されている資料や議事録にサラッと目を通すぐらいのことは、交渉・調整の前にしておきたいところ。
また、INSPIREDには以下のような記載があります。
良い開発チームは、製品開発、デザイン、エンジニアリングの各担当者が並んで座っていて、職能間のギブアンドテイクや、ユーザーエクスペリエンス、実現技術を活用する。
並んで座ることは、記載されているような知識や技術の共有・活用だけでなく、相手の人となりや大事にしていること、今困っていることなどの理解によりチーム内の交渉・調整・意思決定を円滑にすることにつながります。
リモートワーク中心になる中では物理的に並んで座ることは難しいですが、朝会やチームの定例ミーティング、あるいは普段からのチャットのやり取り等で似た状況を作ることは大事でしょう。
「最後は私が決める」に耐えうる信頼関係を築く
交渉・調整と言っても、最終的には誰かが責任をもって決めるしかありません。プロダクトに関することであればプロダクトマネージャーがその役割を担うことになるはずです。しかしながら、どんなに相手の立場や意見を尊重していたとしても、誰もが100％満足する着地点を見いだせることは多くありません。
それでも必要十分に納得して動いてもらうためには、「あの人が言うことなら」という人望や信頼感が必要です。
人望や信頼感は、主に以下のような要素で成り立ちます。
礼節：攻撃的な言動をしない、正当な理由なしに否定しない、など
一貫性：言葉と行動の一貫性、会社や事業の戦略・戦術との一貫性、など
スペシャリティー：専門性、個性、アイデンティティ、など
ちなみにINSPIREDでは、プロダクトマネージャーについて以下のような記載があります。
プロダクトマネジャーは会社の中で、最も才能のある人材の1人であるべきだ。もしプロダクトマネジャーに、技術に関する高度な知識やビジネスの手腕、主要な幹部との信頼関係、顧客に関する深い知識、製品に対する情熱、製品開発チームへの敬意がなかったりすれば、間違いなく失敗する。
プロダクトマネージャーに求められるものとして最もよく挙げられるのは「顧客に関する深い知識」だと思いますが、それ以外に信頼関係や情熱、敬意といった要素が挙げられているのが印象的です。これはまさに、チーム内外の交渉・調整において必要となる要素でしょう。
特に、敬意・礼節をもって接することは「最も才能のある人材」でなくても誰でもすぐにできることなので、大事にしていきたいですね。
貸し・借りをつくらない
特に社内の交渉ごとにおいては、しばしば「今回は仕方なくこちらが譲歩するので、次回はそちらが譲歩を」といったやり取りが行われがちです。が、これはできる限り避けるべきです。
というのも、その貸しや借りを返すことが容易ではない、あるいは環境変化によって容易でなくなるケースが少なくないからです。そして、貸し借りの精算がスムーズに行われないことは、お互いの信頼関係を傷つけ、それ以降の交渉・調整難易度を大きく上げてしまいます。
相手に譲歩してもらう形で交渉・調整が行われる場合も、それが貸し・借りの関係にあるわけではなく、ビジョン実現に向けて最適な着地点であることや、現状のプロダクトの状況から判断したものであることを強調するようにしましょう。
おわりに
『プロジェクトマネジメントの基本が全部わかる本』で交渉について書かれた第2章の副題は「適切なパートナーシップを築こう」です。私が長々と書いてきたことが、1行で表現されている。。。
交渉や調整を、スポットで発生する作業・タスクとして考えるのではなく、継続的なパートナーシップの構築であると考えると、普段からの情報共有や相互理解がとても大事になってきます。交渉・調整にかかる精神的負荷を軽減するためにも、普段から様々な人とコミュニケーションを取っておくことが、プロジェクトマネージャーはもちろんプロダクトマネージャーにとってもとても大事なことですね。