HR TechのPdMがプロダクトドリブンなBizDevコミュニケーションを実現するために取り組んだこと

## はじめに

この記事はHRBrain Advent Calendar 2023カレンダー1の25日目の記事です。

https://qiita.com/advent-calendar/2023/hrbrain

HRBrainでプロダクトマネージャーを担当しています[タナカ](https://twitter.com/arianasedai)です。
奇しくも2年連続クリスマスの担当になりました。
[去年はGASを書いてた](https://qiita.com/drafts/f15267fd4bc115dd8a70/edit)みたいで、今年はHR TechのPdMっぽいことを書いてみたいと思います。

:::note info
[Qiita Night～エンジニア×非エンジニアのコミュニケーション～](https://increments.connpass.com/event/297115/)にて登壇した内容の書き起こしになります。
:::

:::note warn
あくまでも弊社、弊チームの取り組みとなっており、リソースや組織の事情から参考にならない部分もあるとは思います。
すでに世の中にある理論や実際の取り組み事例としてご紹介させていただくため、何かヒントのようなものだけでも持ち帰っていただけると幸いです。
:::

## 本題の前の前提

### 簡単な経歴

![自己紹介](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2294641/95615b29-ce33-7bbf-d15d-d63c6da3cd2b.png)

テクニカルな雰囲気出していますが完全に技術弱者の非エンジニアです。（すみません）

ただ、HR Techの会社でカスタマーサクセスとしてお客様の組織課題を最前線で改善してきた経験がある自分だからこそ、何かプロダクトチームに対してできることはないか？という発想から行えたこともありました。今回はその一部を紹介したいと思います。

### そもそもプロダクトドリブンとは？

![プロダクトドリブンな状態](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2294641/d96e7682-d4cf-6609-ece7-bf0df358d739.png)

開発サイドとビジネスサイドが同じ目線・顧客解像度でプロダクトづくりに取り組めてる状態を作るのって難しく、むしろ対立が生まれやすい構造になることが多いんじゃないかと思っています。（かくいう私たちも最初から完全にできていたとは言えません）

現在、私のチームでは開発メンバーもビジネスメンバーも、気兼ねなくプロダクトづくりに関する議論ができるようになっています。
その中でビジネスメンバーが「目の前のお客様から言われることだけでなく、フロントに立っている自分たちが、お客様が見えていない課題を解決する考え方で要望を聞いていかないと唯一無二のプロダクトにはなれないよな〜」とプロダクトドリブンな思考に転換したような発言もしてくれるようになりました。

あくまで私の考えですが、ビジネスサイドのメンバーは求められる成果によるプレッシャーや日々対峙するお客様への情によって、「（お客様が言った通りの）この機能を作るべきだ」という表層的な要望にどうしても囚われやすくなると思っています。（仕方ないものでもあると捉えています）

そんな状態に至るまでの最初に乗り越えるべきコミュニケーションの設計について、過去カスタマーサクセス時代に勉強していたことが非常に参考になりました。

### 体制のご紹介

本題に入る前にもう少し前提の説明をさせてください。

![体制](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2294641/5ea46341-5c0f-0714-a811-e85a0f9155bf.png)

弊社ではエンジニア・デザイナー・QAエンジニア・PdMからなるプロダクトチームに加え、ビジネスサイドからドメインのエキスパートとして数名プロダクトチームに兼務する形での体制を取っています。
そして、プロダクトチームからテックリードとデザイナーをプロダクトボードメンバーとしてアサインをし、ドメインの解像度を高め、プロダクトの価値向上をリードする立場としての役割を担ってもらっています。

## HR TechのPdMとして取り組んだこと

### 体制の始動の前に

![懸念](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2294641/8e3b8e95-6124-6c85-f0b9-5c51c8381f4c.png)

自分はビジネスサイド・開発サイド両方の経験があるため、双方の思考特性については理解しているつもりでした。

もちろん、チームワークを重視する弊社では互いをいがみ合うコミュニケーションを取るメンバーはいませんが、少しの立場の理解の違いから少しづつ心の距離が離れ、プロダクトドリブンを目指す体制として最大の効果が得られない可能性を懸念していました。

### 自己を見つめ直す

カスタマーサクセス時代、顧客の組織課題を最前線で解決する立場としての経験や、現在プロダクトづくりに関わり開発側の視点もあることから、自分だからこそできる何かがあるのではないかと考えてみました。

![自分のルーツ](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2294641/f5e40fd4-be17-38a2-4aac-e3cc85e816c2.png)

カスタマーサクセス当時、お客様よりも深い知識で価値提供することに努めており、組織・タレントマネジメントに関する書籍や論文などを読み漁っていました。当時のメモをいろいろ読み返していったところタックマンモデルというモデルがあることを思い出したため、組織の状態を俯瞰して見るためのツールとして活用してみました。


![タックマンモデル](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2294641/01a755c9-b628-701f-8fe3-14b4304d4851.png)

:::note info
[タックマンモデル理論](https://www.hrbrain.jp/media/human-resources-development/team-building20190919#section-13:~:text=%E3%82%8F%E3%82%8C%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%80%82-,%E3%82%BF%E3%83%83%E3%82%AF%E3%83%9E%E3%83%B3%E3%83%A2%E3%83%87%E3%83%AB%E7%90%86%E8%AB%96,-%E3%80%8E%E3%82%BF%E3%83%83%E3%82%AF%E3%83%9E%E3%83%B3%E3%83%A2%E3%83%87%E3%83%AB)
参考：今さら聞けないチームビルディング。
具体例や参考書も紹介（HRBrainオウンドメディア HR大学より）
:::

### タックマンモデルで整理してみた

![状況整理](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2294641/e9c4b0f7-bcba-fd67-b845-d948a0fbbd0a.png)

開発サイドとビジネスサイドが融合したプロダクトドリブンな組織の効果を最大限発揮するために、理想と現在を自分なりに整理してみました。

組織が機能する状態＝機能期に向かうまでに、

- **形成期**
- **混乱期**
- **統一期**

といった特にチームの立ち上げ期、関係性構築のフェーズを丁寧に進めるべきだと改めて確信を持ちました。
コンサルタントほど組織構築のノウハウはありませんが、先人の理論を参考に現状認識と施策を検討していくことができたんじゃないかと思います。

#### 組織の成功循環モデルも参考に

マサチューセッツ工科大学のダニエル・キム教授の**組織の成功循環モデル**が頭の片隅に残っていたこともあり、特に関係構築フェーズを重視することを選択することができました。

![スクリーンショット 2023-12-20 23.48.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2294641/e7076adb-3c3e-7dcc-4b4b-724e841a4f8b.png)

:::note info
画像引用：ITメディアエグゼクティブ[「戦略を実行する第2ステップ―組織の成功循環モデルを知り、リーダーシップを強化する」](https://mag.executive.itmedia.co.jp/executive/articles/1112/05/news007.html)
:::

### 形成期の取り組み

![形成期](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2294641/b90ab66b-b9da-5c37-cc6a-626ae5e6b6de.png)

形成期はとにかくお互いを理解すること、同じ目的を持つ仲間であることを理解することに努めました。

職種が異なる中でのドラッカー風エクササイズでは、相互理解だけでなく、自身が他職種に対してどのような貢献ができるかどうかを認識できる時間になったのではないかと思っています。
（例：デザイナーはどのような情報を求めているから、営業である自分はお客様からヒアリングする内容を変えてみよう）

また、自分がアサインされたプロダクトやプロダクトボードエキスパートチームをどうしていきたいかという思いを共有することで、強い一体感が醸成されたと実感しています。
（エモめな時間になった）

### 混乱期、統一期に取り組んだこと

![混乱期、統一期](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2294641/5a58c498-2281-1b48-a1cd-a689ac769e4e.png)

混乱期、統一期は両方を行き来しながら進めていくことを意識しました。（アジャイルに進めていくイメージ）
同じ方向を向くためには一定の対立が生まれ、また健全な対立を通してさらなる組織の統一がされていくと思ったためです。

プロダクトビジョンの策定段階からプロダクトボード（テックリード、デザイナー）だけでなく、ビジネスメンバーも巻き込んでいきました。顧客の課題整理や将来どういう世界を作り上げていきたいか、そのようなビジョンの前提となるような議論から共に行っていきました。

また、建設的な対立を生み議論の質を高めていくためには、各職能が自らの立場での発言をしアイデアが融合しやすい状態が不可欠と考えてもいました。
そのため、各職能に対して、あえて自分のポジションを意識させ、「あなたの専門性から見てどう考えるか」という投げかけ方を意識しました。

形成期のドラッカーエクササイズを通して相互理解ができていると認識していたため、それぞれの職能の過度なポジショントークも生まれにくいという自信があったからできた問いかけ方でもあったかもしれません。
※チームメンバーの人間性にも恵まれていたと思います。

無事、当時設定しうるプロダクトビジョンが置けたのではないかと思っています。
また、結果としてビジネスサイドのメンバー（プロダクトエキスパート）にとってのプロダクトに対する当事者意識も高めることにもなったのではないかと感じており、今ではプロダクト開発に必要な情報連携を積極的に取ってくれたり、ビジネス組織に対する開発スケジュールの期待値調整を率先して行ってくれたりしています。
※ビジネスサイドのメンバーのオーナーシップに助けられている部分も大きいです。

:::note warn
プロダクトの未来を考えていく上で、多くのステークホルダーを巻き込むことは優れたプロダクトづくりをしていくための重要な要素であると思います。
しかし最終的にはプロダクトマネージャーが意思決定に責任を持つというリーダーシップは重要であると考えます。
:::

### まとめ

こうして、現在となっては開発のロードマップに対する議論を職能をまたいで気兼ねなく行える状態になり、また、プロダクトドリブンな思考をビジネスサイドのメンバーに対しても醸成していくことができたんじゃないかと思っています。

また、組織の問題は急に温度感が高まることが多く、直面したときのドキドキは本当に心臓に悪いと思いますが、ある程度事前に整理・設計しておくことで今後発生する問題の想定や心構えがしやすくなったんじゃないかと思います。

とはいえ、まだまだお客様に提供できる価値の余白は大きく、より一層プロダクトドリブンに行動できる文化を強めていく必要があると思っており、また1年後のアドベントカレンダーでは進化したプロダクト組織についての記事を書きたいと思っています。

## おわりに

つらつらと好きなように書かせてもらいましたが、ここまでの道のりは一緒に働くメンバーがいなければ辿ることができず、むしろ仲間の支えもあってこの記事のような書き方ができたと思っています。

そんなPower to the peopleな思い溢れる仲間が多くいる私の会社では積極的に新たな仲間を募集しています。まずはカジュアルにでも良いのでお話しましょ〜！

https://www.hrbrain.co.jp/recruit