ビジネスドリブンで急成長してきたベルフェイスにプロダクトマネジメントを取り入れたお話（戦略編）
この記事はbellFace Advent Calendar 2021 の12日目の記事です。
もうすぐ2021年も終わりということで年末の業務の合間を縫って執筆しております。そもそも予定通り仕事を納められるだろうか。。。
自己紹介
こんにちは。ベルフェイス株式会社でPM(プロダクトマネージャー）をやっております岩本です。ベルフェイスの中核であるオンライン商談部分を管掌するプロダクトラインのPMとして、日々プロダクトに向きあっております。まずは、本題に入る前に簡単に自己紹介をさせてください。
ベルフェイスに入社するまでのお仕事
大学院を休学後（後に卒業しました）、創業直後のCtoCマーケットプレイスを運営するベンチャーでEngineer、PMとして働いたあと、数十名〜百名規模のスタートアップでPM→事業部長→執行役員CDOとして勤めたあとにフリーランスとして働いていたところ、ベルフェイスと縁があって入社をすることになりました。これまでは中古車産業や観光・宿泊産業、ファッション、メディア、toBヘルスケアSaaSといった領域でプロダクトを作ってきました。
ベルフェイスでやっていること
ベルフェイスでは、オンライン営業システム「bellFace」という1プロダクトを、複数のプロダクトラインに分かれて相互に連携しながら開発を進めています。私はその中でもプロダクトの中核を担うオンライン商談の機能を管掌するプロダクトラインでPMを担当しております。加えて、直近ではプロダクトライン横断で進めている大きなPjがあり、そちらのリードPMも担当しております。
2拠点生活でのワークスタイル
2020年のコロナ禍をきっかけに都内と石川県の2拠点生活を始めました。ベルフェイスではリモートワークでの勤務が可能なのでこのスタイルは入社後も継続しております。
石川県の家の目の前は海でとても癒やされます。
また最近はアオリイカを飼い始めました。このイカちゃんは、驚くと墨を吐いて海水を汚します。300Lの水槽の水換えが重労働過ぎてとても地獄です。
本記事内で語ること
自己紹介はこれくらいにしておいて、本記事の内容に入っていきたいと思います。本記事においては、ベルフェイスのようにビジネスドリブンで一定の規模まで成長した会社に対してどのようにプロダクトマネジメントを取り入れていったか、という部分にスポットを当てて書いていきたいなと思います。尚、戦略編と開発編に分けて書く予定であり、本記事においては戦略部分（後述するOPMWというプロダクトマネジメントフレームワークにおけるStrategyフェーズ、プロすべ本でいうところのCoreやWhyに相当する部分）にフォーカスして書いていきます。
入社当時のbellFaceの状況
まずは入社当時の状況をふりかえりながらプロダクトマネジメントにおいて抱えていた問題点を整理したいと思います。入社時期は2021年の2月となっており、2020年コロナ禍による市場環境の激変の煽りを受けているタイミングでした。
入社当時のプロダクトの状況
一言でいうと、コロナ禍による市場環境の激変によってプロダクトの現在地がどこなのかわからなくなってしまっている状態でした。
市場環境の激変によって世の中のITリテラシーがいきなり向上したこと
1万社を超える申し込みがあったコロナ対策支援でのbellFace無償提供によるユーザー層の多様化
ビジネスドリブンで開発を進めてきたため、「過去にリリースされた機能が誰のためになぜ作られたのか」がノウハウとして蓄積でてきていない
2016年のリリース以降、エンハンスに次ぐエンハンスで技術的負債・UX的負債がかなり溜まっている
ざっと思い返すだけでもこのような問題を抱えていたように思います。このような状況の中、注力顧客との新機能PoC-Prj（これは先日発表されたばかりのリモートコントロール機能のことです！）や既存機能の改善・不具合対応といった足元の開発は継続してやらなければいけない状況でした。
入社当時のプロダクト開発組織の状況
ビジネスドリブンで伸びてきた部分もあり、顧客と折衝しているBizサイドの言うとおりに開発を行う社内受託開発的な文化が根強く残っていました。また、明確なプロダクトマネジメントプロセスも存在せず、Prj毎にバラバラのプロセスによってプロダクトづくりが行われてるという状況でした。このような状況ですので、アウトプット偏重な開発が行われていて、誰のためになぜつくるべきなのか（まさしくPMのお仕事ですね）、作ったものはどれくらいのアウトカムにつながったのかといった点は、あまり意識されずに開発が行われていた状況です。
上記のような状況ではあったのですがCTO/CPOのZIGOROuのエントリにもある通り、ビルドトラップを避け、プロダクト主導型組織に生まれ変わるという強い意志の元、組織一丸となって「変わっていくぞ」というタイミングでの入社となったため、具体的にどのように変わっていくべきかをOPMWやビルドトラップ本、プロすべ本を参考に練り上げていきました。
さらに、同じタイミングで強い経験をもったPMが続々と入社したこと、開発に関わる既存メンバーにおいても現状のプロダクト組織やプロセスのあり方に課題を感じ、変えていきたいと思っている人がいたことを非常に心強く感じました。
入社前後でのギャップ
入社前後で感じたギャップという部分から、当時のベルフェイスの状況を振り返ってみようと思います。
入社前（採用プロセス前）のベルフェイスの印象
採用プロセス時にベルフェイスを知った時の印象は、
タクシーでよくCMを見るし、FBでもよく広告を出している会社。
プロダクト的にはZoomやGoogle Meetと何が違うんだろう。
フェーズと規模感的にはある程度体系的かつ組織的なプロダクトマネジメントの土台ができつつあるくらいの状況だろう。
コロナ禍でめちゃくちゃ追い風なのでは？
くらいの雑な印象でした。特に4つ目に関しては前職でホテルのレベニューマネジメント支援を行うSaaS事業を運営しており、観光産業のコロナ禍における凄惨たる状況を目の当たりにしていたため「この影響が追い風になっている事業だと成長率もすごいんだろうなぁ」くらいに考えていました。
入社後に実感したベルフェイスの印象
コロナ禍による市場環境の変化が、決して追い風だけではなく向かい風になる部分もあったこと、そしてそれを踏まえて新たな市場課題を見つけ適応しようと動いていることも入社後に感じた意外な一面ではあったのですが、一番強く印象に残っているのは事業のフェーズ感とプロダクト組織のフェーズ感の歪みの大きさです。事業の成長規模に対してプロダクト組織及びプロダクトマネジメントプロセスの成熟度が全く見合っていない状況下にあることに強く危機感を覚えました。
Startupとは基本的に急激な成長を狙って事業を生み出していく組織です。そのためビジネス的な成長に応じて、組織も拡大していかなければならないのですが、大きく成長しているStartupの大多数は事業の成長に応じた組織側の拡大や成熟が追いついていない場合が多いのではないかと思います。これはプロダクト組織やプロダクトマネジメントプロセスにおいて特に顕著だと考えており、プロダクトマネジメント自体の認知度や世間への浸透もここ数年のもので、まだまだベストプラクティスやナレッジが世間に浸透している状況とは言い難く、エンジニア組織における組織づくりのナレッジと比べると、まだまだ市場にノウハウが流通していない状況です。
上記の図は田所さんのStartup Science2020完全版で定義されているStartupの事業のフェーズ感に対して、それぞれのフェーズに応じたプロダクト組織とプロダクトマネジメントプロセスの成熟度合いをプロットしてみたものです。（※ここでいうプロダクト組織はPM,PO,ディレクター等のポジションのみを想定）
本来であれば、上記の図の通り事業の規模感に合わせたプロダクト体制とプロダクトマネジメントプロセスを作っていけると平和なプロダクトづくりができるのでしょうが、大多数のStartupは事業の成長度合いに組織側が追いついておらず、組織側は1歩手前のフェーズ感のまま、ということが多いのではないかと感じております。このギャップに苦しみながらなんとかより良いプロダクトを作ろうとしているPMの皆さんには頷いていただける内容ではないでしょうか。
もちろんこれが1フェーズ分のズレであれば、なんとかやりくりしながら凌いでいけるとは思うのですが、2フェーズ以上ズレてくると話は違ってきます。PMに届かなくなり管理もままならない顧客要望、誰のために作っているのかわからない機能、回らない開発現場、その先にはプロダクト組織の破綻というBAD SCENARIOが待っています。Startupにおいては、こういった組織的な負債ともいうべき部分を事業フェーズが変わるたびに適切に返済していくべきなのですが、これが中々うまくできず悩みのタネになっている会社も多いのではないでしょうか（私も過去に数十名〜百名超へとフェーズが変わっていくときに、苦労した経験があります）。
私がベルフェイスに入社した際に感じたのはこういったズレの部分で、2フェーズ以上の明らかなズレを感じて強い戸惑いと危機感を感じました。
ビジネスドリブンで急成長してきたことによる弊害・問題点
ここまでの話を一度まとめさせていただきます。ビジネスドリブンに急成長することを追いかけてきたため、事業規模に対してプロダクト組織としての成熟度合いが全然追いついていなかった。その結果として
過去にリリースされた機能が誰のためになぜ作られたのか、がノウハウとして蓄積できていない
エンハンスばかりで解消されない技術的負債・UX的負債
社内受託的開発でのアウトプット偏重なプロダクト開発スタイル（典型的なビルドトラップ）
型化されず知見も貯まらずで成熟していないプロダクトマネジメントプロセス
といった問題が積み上がっている状況でした。そこにコロナ禍という外的要因による市場の大変化が発生し、事業の変数が大きく変化し、プロダクトの現在地がわからなくなってしまうという2重苦状態だったと言えると思います。
プロダクトマネジメントの戦略観点で取り組んだこと
上記の問題を抱えている状況に対してプロダクトマネジメントの戦略観点で取り組んできたことをいくつか書いてみたいと思います。抜本的に取り組みたい部分も多々あったのですが、既に一定の規模で動いている事業であり、目の前にある各Pjを止めるわけにもいかないので、段階的かつ部分的に着手せざるを得ない要素も多々あり、バランス感のある判断が要求されました。
プロダクトの現在地わからない問題
プロダクトの現在地わからない問題とは、「誰のどのような問題を解決するためのプロダクトで、今それがどれくらいできているのか」がわからなくなっている状態を指しています。元々Whyをあまり考えない社内受託的文化があると書きましたが、そういった状況に加えてコロナによる市場の大変化によって、前段に記載した「誰のどのような課題を抱えているのか」という部分を再定義する必要が出てきており、この点については後述する「誰のなにを解決するべきかが管理されていない問題」の部分で説明します。
ここでは「どれくらいできているのか」、つまりプロダクトの評価という部分に焦点を当てたいと思います。
元々ビジネスドリブンな動き方で事業運営を行っていたため、最終的なビジネス指標（ARRやMRR、Churn Rate等）は追っていましたがそれ以外のプロダクトが追うべき指標やKPIは正しく設計されておらず各々がそれぞれ思い思いの指標を見ていました。加えて、BIもData Portal,Tableau,Redash等乱立しており、どこになにが可視化されているかの把握も難しいという状況でした。これだけ市場に大変化が起きた中でその変化を正しく把握するためにも、プロダクトの現状把握とKPIの設計及び定点観測は、いの一番に取り組むべきポイントだと判断しCPOのZiGOROuと相談して、数人ではありますが本Missionを遂行できるUnitを組成しました。そしてbellFaceというサービスのNSMは何かを考え、NSMからKPIを設計しそれを可視化していくPj、現行のプロダクトにあるデータを分析して示唆を抽出しプロダクトの現状把握を進めるPjと2つの動きを同時並行的に動かし始めました。
前者の方の動きは全員が兼務のため、緩やかではありますがNSMを定めそれに則ったKPIの設計を行い、BI上での可視化を進めているところです。また、リテンションレートの再定義も行い、N日リテンション、Gross Retentionの両軸からプロダクトの継続率を可視化・分析し始めているところです。
後者の動きはUnit内にいるデータサイエンティストの羽田さんと二人三脚で進めてきました。ここまでの流れでお察しの通り、綺麗に整備されたデータ基盤がないため、目的のデータが手に入らない場合も多いのですが、羽田さんが様々な手段を駆使しつつ様々な示唆を生み出してくれており、プロダクトの現状把握がかなり進んだと言える成果が出ています。
また中期的な観点でいうとAdvent Calendarにも登場していたSDPチームのぐっちさんが統合的なデータ基盤の整備に着手してくれており、来季以降はよりデータドリブンなプロダクトマネジメントが行える土台ができあがりそうです。
社内受託開発的にプロダクト作ってた問題
こちらはPj内の開発現場における受託開発的な文化やアウトプット偏重な文化を払拭するためにやったことを記載していきたいと思いますが、後ほど公開する別の記事の方でまとめていきたいと思います。
明確なプロダクトビジョンがなかった問題
こちらは表題の通りプロダクトビジョンを作ったお話です。詳しくはパリピなまじめなPMのかおしさんが執筆予定の記事で読んでほしいので詳細は割愛しますが、かなり迷いながらも皆で一つになって決めきっていった感覚が強く、良いプロセスを経て良いビジョンを決められたのではないかと感じています。入社したばかりのPM陣のそれぞれの志向性がよくわかったのもこの議論を通してだった気がしますし、プロダクトビジョンはPMにも一緒に決めさせてほしいとCPOを説得したり、プロダクトビジョンの策定プロセスに違和感を感じて、CPO抜きでこっそり話し合ったことがあったのも今となっては良い思い出です笑。そして前述したPMのかおしさんがHow警察と呼ばれ始めたのもこの時期だった気がします。
誰のなにを解決するべきかが管理されていない問題
こちらはプロダクトの現在地わからない問題で話した「誰のどのような問題を解決するためのプロダクト」なのかが複合的要因によりわからなくなっていた件です。データ分析によるプロダクトの現状把握とKPIの設計及び定点観測は先程説明させていただいたとおりですが、こちらでは「誰のどのような問題を」という課題に対してターゲットユーザー・ペルソナの再定義と管理フローの構築に取り組んだことを書いていきたいと思います。
アプローチとしては下記のような感じです。
インタビュー実施のための土台づくりとプロセス設計
インタビューから得られた知見を用いた開発プロセスづくりの浸透
組織全体での統一的な解釈と運用ルールに基づいたターゲットユーザー・ペルソナの定義と管理フローの設計
まず、インタビュー実施のために、予算取りやインタビュー機会の定常的な獲得と管理フローの設計を行いました。こちらは別の方がAdvent Calendarでまとめてくれると思うので詳細は省きます。このような動きによって定常的に顧客やターゲットユーザーになりうる人への接点を持つことで解像度を上げてプロダクトづくりができる土壌を作りました。そして、それを徐々に現在進行系で動いている開発Pjにも浸透させていく動きを行いました。既に動き出しているPrjかつそのような文化が弱い中で進めてきた開発スタイルだったので、Prj破綻のリスクや現場の変化に対する許容量を考慮し、いきなり大きく変えることはせず、インタビュー結果を元に少しずつプロダクトのWhyやWhatを元にしたHowの設計を進められるようなスタンスへの変更を促していきました。
そして、一部の個別Prjでそのような取り組みをしつつも、大きなPrjの開始を機にようやくターゲットユーザーやペルソナの再定義に着手しているところです。また、この機会にプロダクトグループ横断での市場課題の管理フロー構築にもチャレンジし、ターゲットユーザーやゲイン、ペインという概念を元にNotion上でデータベースを構築し、これらの情報が構造的に管理され、かつ定常的なインタビュー機会を元として定期的に更新されていく状態を作るための足がかりができたかな、と思っております。
またDoP溝口がManagerを兼務しているPMMチームの方でも全社における要望収集・管理フローを再設計しプロセスを整えてくれたおかげで、誰のなにを解決するべきかが管理されていない問題は整備されたプロダクトマネジメントプロセスの中でかなり解消されたんじゃないかなと感じています。
その他にも、中長期的なプロダクト戦略づくりのための市場調査・競合調査の仕組みづくりをはじめいくつかトライしてきた部分はあるんですが長くなりそうなので割愛させていただきます。
やってみた結果と所感
一定規模まで成長したStartupに対してプロダクトマネジメントを取り入れるために四苦八苦してみたわけですが、一定の成果は出せつつあるかなと感じています。とはいえ、まだまだ取り組めていないことも多いですし、プロダクトのアウトカムとして効果が出始めるのはもう少し先になるかと思います。
また、ある程度の規模感になってからの抜本的なプロダクトマネジメントプロセスの導入は非常にパワーがいるし時間もかかるということを痛感した1年でした。複数のプロダクトラインでそれぞれ別のプロセスで開発を行う数十個以上のPrjが動いており、これを止めるわけにはいきません。
どこから手をつけるべきか
取り組む難易度と効果を鑑みてどこから整備するべきか
どれくらいのスコープで取り組むべきか
1Prjだけ変えるのか、特定プロダクトラインでやるのか、プロダクトライン横断で整備していくべきか
どれくらいの深さで変えるべきか
業務遂行するメンバーが受け止めきれる深さの変更か否か
こういった観点を踏まえ、うまく落とし所を設計し段階的にプロセス整備を行ってきました。
とはいえ、1~2年前にやっておけば半分以下の時間とパワーでできただろうなと思うことも多く、事業のスケールに応じて適切なタイミングでの段階的なプロダクトマネジメントプロセスの整備は大事だなと改めて感じた次第です。
総括
こんなに長い記事を書くことになるとは思いませんでした笑
やってきたことは基本的なことばかりですが、改めてベルフェイスにプロダクトマネジメントプロセスの導入を行った実感をまとめてみたいと思います。
プロダクトマネジメントを取り入れる中で実感したこと
一定規模にまで成長したStartupにおいて、既に動いている業務と平行してのプロダクトマネジメントプロセスの変革にはパワーと時間がかかることを改めて実感しました。入社時点ではもっと大きな変革をやれるかなと思っていたんですが、結局基本的な部分への着手しかできなかったな、という印象です。これは「やってみた結果と所感」の部分でもお伝えしたとおり、現行業務と平行しつつ、どれくらいの粒度で変えていくべきかを意思決定し、関係各所と合意を取りながら落とし所を設計するという部分にかなり時間がかかってしまったと感じております。
本当はこのレベルまで変えてしまいたいが、現行業務とのバランス等を考えると2,3歩手前の落とし所を模索しなければならないということが多く、もどかしい部分がたくさんありました。やはり事業フェーズ毎での段階的なプロセスの整備は超大事だなと実感しております。
また、事業継続途中のプロダクトマネジメントプロセスの導入において、基本はベストプラクティスに則って順次導入していくのがやりやすいかなと感じました。チームもたくさんあり、それぞれ指向性の異なるPMが複数いる中で、同じ方向を向いて変革していくためにはわかりやすいベストプラクティスによって、変革の方向性の合意を取っていくことが大事かなと思います。ベルフェイスにおいてはOPMWをベースとしつつもビルドトラップ本やプロすべ本のエッセンスを取り入れつつ変革を進めてきました。入社当時にCPOを含むプロダクトマネージャ陣でOPMWの輪読会をやったのも良い認識のすり合わせ機会になったと感じています。
一方で、既に一定規模での開発が動いている状況なので、現場メンバーの業務プロセスの変革に対する許容量を考慮しつつ導入すべきベストプラクティスを柔軟に変更していく勇気も一定必要だと感じています。プロセスを遵守することがプロダクトマネジメントの目的ではなく、より良いプロダクトによってアウトカムを生み出すことが目的なので、変革するプロセスにこだわりすぎて現行業務がそもそも破綻してしまい、アウトプットすら出せなくなることは避けなければなりません。そのために組織の状況に応じて、段階的な導入による変化度合いの調整や、一部ベストプラクティスのチューニング等も必要だと感じています。
これから取り組んでいきたいこと
コロナ禍による市場環境の大変化によってプロダクトを取り巻く要因が大きく変化したベルフェイスですが、市場がそれだけ大きく変化したということは新たな市場課題もたくさん生まれているということです。2020年の春頃に新型コロナウイルスが猛威をふるい始めた頃は、プロダクト的には非常にハンドリングが難しい状況だったと思います。当時のメンバーが暗中模索しながら見出してくれたいくつかのヒントを元にして、新しく生まれた市場課題に対してどういう価値を提供していくべきかにおいて、解像度高くその輪郭を描けるような状況になりつつあります。ポストコロナを見据えたオンライン営業と営業DXという文脈において、「商談の数だけ世の中をしあわせに なめらかに価値がつながる世界を実現する」というプロダクトビジョンを達成するプロダクトづくりを推進していこうと思います。
一緒に働きたい人探してます
これまでに書いた通り、優秀で前向きなメンバーとともに、良いプロダクトを生み出すためのプロダクトマネジメントプロセスの整備をやってきた1年だったと思います。めまぐるしい市場の変化によって苦しんだ部分もありつつ、これから取り組んでいくべき市場課題を見定めることができた1年でもあったと思います。そんなベルフェイスでは、セールスという領域で新たな価値を創出していくためのプロダクトづくりに取り組んでくれるメンバーを募集しております。下記Meetyのリンクより気軽にご連絡いただけると嬉しいです。
もちろんプロダクトマネージャーだけではなく、デザイナー、エンジニア等幅広いポジションで絶賛仲間を募集中です！下記リンクをご覧になって、少しでも面白そうだと感じた人からの連絡をお待ちしております！
明日のエントリに関して
どうやら明日はまたCTO/CPO ZIGOROuのエントリのようです。しかもお題はプライシング。EVC Analysisという手法を使って実際にプライシングをやってみたよ、というお話です。SaaSにおいてプライシングは非常に重要な要素のひとつですが、どういう方法で決めるべきか悩んだ経験がある方はぜひ読んでみてください。
この記事が気に入ったらサポートをしてみませんか？