ビジネスサイド出身のプロダクトマネージャー
吉本猛氏：では、私から発表します。よろしくお願いします。「ベルフェイスが脱ビルドトラップのためにやってきた3つのこと」というタイトルで話します。
（スライドを示して）簡単に自己紹介します。吉本と申します。今、Product GroupのSales Communications Product Divisionの商談アプリケーションのTeam Manager兼各機能のプロダクトマネージャーをしています。経歴は書いてあるとおりで、もともとビジネスサイドの出身です。
私は1年以上前にこんな投稿をしていました。今回のイベントのハッシュタグが「＃脱ビルドトラップ」で、まさかこのイベントの布石になるとは、自分も書いたことをぜんぜん覚えていなかったので、ちょっとびっくりしていて、ご縁を感じています。
（スライドを示して）今日は、プロダクトマネージャーの組織、プロダクト組織としての変遷の部分と、ビルドトラップというテーマにおいて抱えていた課題の部分を少し紹介した後に、そこから脱ビルドトラップをしていくためにやってきたことと、それがなぜできたのかと、最後に一言というところで、進めていこうかなと思っています。
オンライン営業システムのプロダクトを開発・提供するベルフェイス
会社紹介は本当にサラッとです。ベルフェイスは今新橋に本社を置いていて、会社名と同じ「bellFace」というオンライン営業システムのプロダクトを開発・提供しています。
コーポレートのビジョン・ミッションとして、「世界数十ヵ国で新たなビジネスを生み出すセールスプラットフォームをつくる」と「勘と根性の営業をテクノロジーで解放し、企業に新たなビジネス機会をもたらす」を掲げています。
（スライドを示して）オンライン営業システムとはなんやねんというところです。いろいろなWeb会議と何が違うのか。1、2、3とあるので全部は読み上げませんが、ここに書いてあるとおり、接続の簡単さ、安全性、オンライン商談データを活用することによって、営業での活用に特化したサービスです。いろいろなお客さんの特性や、コンプライアンス要件の厳しさ、営業活動の効率化課題を解決していくことで価値提供をしているプロダクトです。
国内シェアナンバーワン、累計3,600社突破の実績などいろいろありますが、おかげさまで、直近では特に金融業界での広がりもあり、いろいろ導入をいただいています。
プロダクト組織の変遷
本題に移っていきます。まずプロダクト組織の変遷を簡単に紹介します。（スライドを示して）こちらが今時点の、私が所属しているProduct Gr. の体制図です。
Product Gr. と対となる開発組織として 、エンジニアが所属しているSystem Gr. が存在します。
Product Gr. は、大きくSales Communications Product Div. という1つのプロダクトラインと、Sales Enablement PlatformというDiv. のプロダクトラインと、横断的に、デザイナーやプロダクトマーケティングマネージャーやテクニカルサポートが所属しているProduct Design and Ops Div. という3つで主に構成されています。
この左の2つに、いわゆるプロダクトマネージャーといわれるメンバーが所属している状況です。
私は初期に少しプロダクトマネージャーをやっていた時期があり、実はその時に森さん（森洋一郎氏）とお会いする機会があったので、先ほど森さんと「今回のイベントで何年ぶりですかね？」みたいな話をしていました。
プロダクトマネージャーの組織状況ですが、今は業務委託で入っている方もいて、その方も含めて約15名です。PM組織の中には、戦略面を考えるプロダクトマネージャーと、テクニカルフェーズを考えていくテクニカルプロダクトマネージャーもいます。
（スライドを示して）ちょうど1年半前ぐらいを境目に、2021年4月に向けて採用強化およびいろいろな動きをやってきたので、それまでをビルドトラップ期、それ以降を脱ビルドトラップ期と分けて、過去抱えていた課題とやってきたことを今から話せたらなと思います。
ビルドトラップに陥ってしまった原因
抱えていた課題の部分ですね。（スライドを示して）ここに書いてあるとおりです。もともと、ビジネスドリブンかつトップダウン型の意思決定によってプロダクトを作っていました。要は、アウトプット偏重になりがちなプロダクト開発スタイルで進めていました。
代表も私も営業出身で、最初はドメインのエキスパートと兼務という位置付けでやっていたこともあり、こうなってしまったというのが背景の1つとしてあります。
結果、プロダクト開発チームや全社から見た時に「誰の・何の解決をするのかがなかなか共通認識として持てない」という課題がありました。そのため、なかなかスケールしにくく、プロダクトマネジメントプロセスそのものもなかなか型化されず、知見も溜まらない、頭の中にはあるけれどそれを横展開しにくい、他の人に展開しにくい状況でした。
プロダクトマネジメントのプロセスが共通言語化されていなかったことや、誰の・何を解決するのかというそもそもの要望管理もきちんと仕組みとして管理しきれていなかったことが課題でした。
こういう状況なので、やはりアイデアを出す人や「これをやるんだ」と言う人の一言で開発する項目が決まってしまって、結果ビルドトラップの状態になってしまいました。
施策1 プロダクトビジョン・プリンシプルの策定
それに向けて「これじゃいかん」とやってきたことを紹介していきます。（スライドを示して）課題として挙げた3つに対して、それぞれ施策を打っています。だいたい2021年3月、4月ぐらいからやってきた内容です。
現在もまだまだやっている部分がありますが、「プロダクトビジョン・プリンシプルの策定」「プロダクトマネジメントのプロセスの導入」「顧客要望のマネジメントフローの再構築」が大きくやってきた3つです。1個ずつ紹介していきます。
プロダクトビジョン・プリンシプルの策定は、ここに書いてあるとおり、2021年のだいたい3月終わり、4月ぐらいから半年弱かけてやりました。CPOおよび当時の全プロダクトマネージャーを巻き込んで実行しました。
入社して間もない方々もいたので、ゼロから作っていく上でやはり認識を合わせていく必要があるよねと、最初は少人数でやろうと進めていたのですが、最終的には全員を巻き込んでやることになりました。
やった内容です。前半で紹介したコーポレートビジョンも含めて、まず概念構造みたいなものを少し整理して、「だからプロダクトビジョンとプリンシプルが要るよね」と認識を合わせました。コロナ禍ということもあり、オンラインで「Miro」を用いながら複数回議論しました。
（スライドを示して）どんなフレームワークを使ってやっていったか。1つは「Product Vision Board」です。みなさんももしかしたらこのあたりのフレームはご存じかもしれません。まずは各自が思っている・考えている「bellFaceってこうだよね」を書き出して、認識を表に出すところからスタートしました。
全員がどんなことを考えているのかがなんとなくわかってきた中で、Product Vision Templateに文章形式で、「誰の・何」をしっかり書き出していって、さらに細かい認識のFit&Gapを実施していきました。
そこからさらに調整されていくのですが、最終的にどの期間までを対象とするのか、どれくらいの粒度で全社展開していくのか、場合によっては社外にも展開していくのかというところで、期間や粒度を擦り合わせました。うちの場合は、最終的に5年を1つの期間として定めました。
要素や表現に関するワードがいくつか出てきたので、「こういった表現がいいんじゃないか」「それよりもこちらがわかりやすいんじゃないか」という議論を最終的に行って最終決定をさせていったというプロセスがあります。
（スライドを示して）その結果、プロダクトビジョンとして決めたワードがこちらです。「商談の数だけ世の中をしあわせに／なめらかに価値がつながる世界を実現する」ということを実現するために私たちは今やっているというのを、まずプロダクトグループ全員で認識を揃える、かつ、全社でも認識を揃えるというのを1つの意思決定としました。
目指す場所はわかった。では、それを実現するためにどういう原則に則って作っていくのかというところで、より良い商談機会、より良い商談環境、より良い商談遂行能力の獲得という3つのプリンシプルを定めることで、ブレることなく、要は私たちが何のためにやっているのか、誰の・何を解決していくのかの方向性、認識を合わせました。
施策2 プロダクトマネジメントプロセスの導入
（スライドを示して）次がプロダクトマネジメントプロセスです。ベルフェイスでは、標準のフレームワークとして「Open Product Management Workflow（OPMW）」を導入しています。各カテゴリーがだいたい40項目あって、それぞれの説明文が英語で書かれているホームページがあります。
当時のメンバーや、入社予定のプロダクトマネージャーを交え、2、3ヶ月ぐらいかけてそれの輪読会を毎週行い、その時のディスカッション内容も含めて全部をデータとしてNotionに格納しました。全社に浸透させていく上で誰でも見える場所に置こうと、Notionにまとめました。
少し細かい話です。OPMWには、Strategy、Technical、GTMというPhaseがあります。弊社の場合、ここにGrowth Phaseを独自に設け、4つのPhaseで運用をしています。それぞれのPMが「じゃあここの担当をする」「ここの担当をする」「ここの担当をする」みたいなかたちでです。
1つずつお話しすると、Strategy Phaseはユーザー・課題を定義した上で、より中長期的な目線で事業的な戦略意図、どういう価値を届けるのかを見立てて、戦略や要求定義を作っていきます。
（Technical Phaseでは）Strategy Phaseで定義されたWhyに対して、What、Howといわれる開発工程の部分を実際にプロジェクトとして回していきます。ここがテクニカルプロダクトマネージャーの方々のいわゆる主戦場となる場所です。
さらに、作ったものを送り出すというところで、どのようにやっていけば価値が最大限届くようになるのかというマーケティングプランを策定したり実行したりするのがGo To Marketです。
Growthは名前のとおり、その投下したプロダクトや機能をしっかり計測して分析・評価して、なにか改善するのであればアクションを繰り返して価値提供する、価値を最大化していく活動をし続けていくPhaseです。この4つを、プロダクトマネジメントの中で導入していきました。
施策3 顧客要望のマネジメントフローの再構築
最後に、顧客要望のマネジメントフローの構築のところですね。初期の頃は本当に「Slack」の投稿がポツポツあったり、スプシ（スプレッドシート）でアナログに管理されていたり、それぞれ声がバラついて管理されていたのですが、それをNotionに1箇所にまとめましょうという意思決定をしました。
（スライドを示して）フローは大きく4つあって、こういう流れになっています。まず、要望登録です。こちらはビジネスサイドの代表と、テクニカルサポート、要は顧客の問い合わせを受けている代表が基本的には起票をします。
どんなふうに起票をするかというと、Notionのプロパティ、データベースを組んでいるので、完全フリーテキストではなく、プロパティのところに決まった項目を埋めてもらいながら、プラス、右側のような1個1個の定性的な情報も含めて、起票する方から見た重要度合いですね。これをしなかったらどうなるのかとか、そういった部分も含めて定性的な情報を書いてもらいます。
この内容を基に、先ほど紹介した会議体の部分で議論をして、意思決定を行っていくというフローでやっています。
（スライドを示して）残りの会議体がこの3つで、棚卸、Biz-Prd連携会議、Product戦略会議があります。
要望棚卸は、PMM（プロダクトマーケティングマネージャー）がハブとなってビジネスサイドの代表者とコミュニケーションを取りながら、起票されたものが具体的にどういうシーンなのか、もう少し深く掘って、それはすぐ検討すべきなのか、いったんアイスボックスに置くべきなのかという棚卸を行っていきます。
Biz-Prd連携会議でもう1回きちんと意思決定、議論をしようとなったら、CPO、Strategyの担当のプロダクトマネージャー、技術的な観点もあるエンジニアリングのマネージャーもいる場で、しっかりやる・やら（やらない）判断するための議論を行います。
さらにもっと大上段で、そもそものプロダクトとしてやっていくか・やらないか、もしくはもっとリサーチがないと判断できないよねという場合に、Product戦略会議に持ち込んで、Strategy Phaseを踏むか・踏まないかも含めて判断していくのが、Product戦略会議です。
なので、起票されて、棚卸があって、やる・やら、パスするか・しないかの判断がされて、この連携会議で実際にやりましょうなのか、もっときちんとリサーチしましょう、揉みましょうなのかを判断し、そこから揉んだ結果やはり再検討しましょうだったり、やらないとなったりというフローが組まれています。
基本的にはこれはデータベース上で全部管理されていて、その議論の内容も議事録として残しているので、誰の・何を今解決するのか、逆に今はしないのかという情報が常に誰がどのタイミングで見ても把握できるという状態をNotion上で組んでいます。
なぜ3つの施策に取り組むことができたのか？
これは1年ちょっとの話で、すごくスムーズにいっているのではないかと思われるかもしれませんが、短期間で実行するのは本来なかなかハードだと思います。
（スライドを示して）それがなぜできたかというと、これは自社のことを上げているようで恐縮ですが、やはり代表の中島が「現状、ビルドトラップに陥っているんだ」と本当に真摯に受け止めてくれて、「これは変わらないといけないよね」と、変えていく上での権限委譲をきちんとして、あるべきプロダクト組織へ変革を推進するのを自らやってくれたというのが、非常に大きかったです。
また、経営・組織状況を考慮した上で最適な意思決定を行っていく上で、代表と対等に話していく経営メンバーとしてのCPO兼CTOのZIGOROuさん（山口徹氏）の存在も非常に大きかったです。この1番、2番でかなりいろいろなものが大きく動きました。
最後は、それを実際に実行する各メンバーが、「それをやることによって提供価値を高められるよね」ときちんと信じて推進して、それに対してビジネスサイドの方々も非常に協力してくれたのが、本当に大きな要素だったと思っています。
ここまでお話しして、順調にいっていて、もう土台もできているように見えたかもしれません。とはいえまだまだ、市況感を含めて、このプロダクトビジョンを実現していくためには引き続き難易度が高い、ハードルが高い状況です。それでも、プロダクト作りを推進していきます。
それを実行していくためには、やはり高いレベルでStrategyのPhaseを牽引できるようなプロダクトマネージャーや、Technical Phaseを牽引できるTPM（テクニカルプロダクトマネージャー）の力が必要です。この変革自体もまだまだ道半ばで、正直苦しみながら一歩ずつ着実に変革をしていくPhaseです。
逆にそういう環境だからこそチャレンジしたいという方は、ぜひともご連絡をいただけたらなと思います。ご清聴ありがとうございました。
