及川

御社が手がける事業やサービスについて簡単に紹介いただけますか。

山口

電話を起点として、オンライン商談につなげるSaaSを提供しています。直近では「リモートコントロール」という機能を新たに追加し、オンライン上での申し込みや契約手続きが可能になりました。特に、金融領域の顧客に注力しています。

及川

プロダクトマネージャー（以下PdM）組織の体制について教えてください。

山口

現在のプロダクト開発に関わる組織は、プロダクトグループとシステムグループから成り立っています。プロダクトグループにPdMとデザイナーが所属し、システムグループに開発と運用が所属。開発はプロダクトラインに対応する構成となっており、SRE、セキュリティ、品質管理などの運用はプロダクトを横断して担当しています。

この中でPdM業務を担当しているのは18名ほどとなり、大きく3つに分類できます。

プロダクトの全体的なマネジメントを行うのは、ユーザーの課題を定義し、それに対応するプロダクト要求を定義するストラテジ担当PdM、プロダクト要求に対し、要件や仕様を設計し、その開発プロジェクトの推進を担当するテクニカルPdM、プロダクトマーケティングを担当するPMMです。

及川

ストラテジとテクニカルのPdMを分けている理由を教えてください。

岩本

ベルフェイスの組織状態に適した体制をとっています。現在はストラテジを担当できるPdMが少ないため、テクニカルまでカバーするとストラテジフェーズが追いつかない状況です。そのため、役割を分けています。

また、ひとつのプロダクトの中に多くの機能があり、自分が担当する領域以外の細かい仕様を把握するのが難しい状況です。連携する機能は干渉しあうため、テクニカル担当PdMをおくことで、齟齬が起きないようにする目的もあります。

及川

PdMの責任範囲について教えてください。

岩本

PdMはPLの責任はもちませんが、機能追加や新しく作り出すプロダクトがどれだけ事業にインパクトをもたらすのかの見立てや調査、整理を深く行っています。
さらに、リリース後にどのくらいの価値を生み出せたかという評価も行っていますね。

プロダクトに対する要望や企画、事業上の新たな取り組みのアイデアは、ビジネスサイド・プロダクトサイド両方からあがってきます。

どちらか一方の要望だけで進めることはなく、事業上のインパクトや、ユーザーにどれくらい価値を与えられるかを戦略的に見立てた上で、会社として進めるべきかという意思決定をしています。

ビジネスサイドから要望があっても、プロダクトサイドが「やるべきではない」というフィードバックを行うこともあり、その逆もしかりです。

及川

PdMとシステムグループは、どのようにコミュニケーションをとっているのでしょうか。

岩本

弊社のプロダクトマネジメントについて補足しながらご説明します。
当社では、「Open Product Management Workflow」（以下OPMW）というプロダクトマネジメントプロセスを取り入れています。

OPMWは、上記のようにストラテジ、テクニカル、GO TO MARKETの3つの段階に分かれます。

ストラテジは、事業サイドとの関連性が強いフェーズです。ユーザーと課題を定義し、事業的な戦略意図やユーザーに届ける価値の見立てをした上で、プロダクトの戦略と要求を定義します。

テクニカルは、ストラテジで定義したWhyに対して、WhatやHowをつくっていく開発の工程です。プロダクト要求に基づき、価値が最大化される機能要件やUXを設計し、実装します。GO TO MARKETは、プロダクトを市場に送り出す工程です。戦略に基づき、ユーザーに対し、価値が最大限届くようなマーケティングプランを策定し、実行します。

このストラテジ、テクニカル、GO TO MARKETの工程を、ストラテジ担当PdMと、テクニカル担当PdM、PMMが連携しながら進めています。

プロダクトをリードするPdMが、ストラテジフェーズを担当します。テクニカルフェーズに移行すると、テクニカル担当PdMがスクラムなどの開発マネジメント手法を用いて、エンジニアやデザイナーを徐々に巻き込んでプロジェクトを組成。テクニカル担当PdMは開発プロジェクトのマネジメントも担当します。

及川

OPMWを導入した目的を教えてください。

山口

私が入社したときは、PdM組織がボロボロの状態でした。PdMの経験者もいなかったため、プロダクトマネジメントを型化したいという想いがあり、体系だったものを探してOPMWを見つけました。21年の2月からOPMWの導入を始めています。

導入を決めたポイントは、前職のDeNAで経験したり、見聞きしたりしたプロダクトマネジメントと同じプロセスを踏んでいると感じたからです。OPMWを導入することで、外しにくいプロダクトマネジメントができるのではないかと考えました。

OPMWは英文のBOOKがあるため、翻訳をNotionで共有し、社内で輪読会も行いました。

すべてを取り入れているわけではないですが、取り組む課題の大きさや明確さ、規模感などに合わせて、PdMが取捨選択して必要なプロセスを選んでいます。

及川

一体感をもってプロダクト開発を進めるために工夫していることはありますか。

山口

ストラテジフェーズではPRDを作成し、テクニカルフェーズでは仕様書やDesignDocなどを作成して開発を進めます。GO TO MARKETフェーズは営業資料やマーケティングサイトを作成します。それぞれのフェーズで成果物を残すことでプロダクトの一貫性をもたせていきたいと考えています。

また、上流のプロダクト戦略やブレイクダウンした価値提案についても、Notionでデータベース化しています。

及川

営業が強い組織だと、事業サイドや営業によってプロダクト開発が押しきられることがあります。こうしたハンディキャップのある状態からプロダクトを変えていく上で苦労はありましたか？

山口

ベルフェイスは社長と取締役の一人が営業出身であるため、以前はビジネスドリブンの会社でした。ビジネスドリブンの利点もありますが、いいものづくりができておらず、内製化もできていない状況でした。
私が入社後1ヶ月で社長を説得して、プロダクト主導で動けるように変えていきました。

及川

変革を起こせない会社も多いです。実現できた秘訣を教えてください。

山口

社長は聞く耳をもってくれる人なので、一歩も引かずすべて論破してきました（笑）。

及川

プロダクトで事業をつくってきた実績や知識があるから論破できたのですね。しかし、成し遂げたい強い意志や執着心が必要です。入社して間もないときに、なぜ思い入れをもてたのでしょうか。

山口

私は20年7月から技術顧問としてベルフェイスに関わり始め、12月に入社。
技術で事業に貢献したいという想いをもっていましたし、世間のベストプラクティスを取り入れることで、再現性の高い経営やプロダクトづくりはできると考えていました。

そのため、経営層のフィーリングや肌感覚でプロダクトの意思決定を行うことは、私には受け入れがたかったですね。実際に判断を誤っていることもありました。
数多くの著名サービスに対するシステム開発のバックボーンのある私を迎え入れたのだから、聞く耳をもってほしいという気持ちもありましたね。

岩本

現場レイヤーでいえば、ビジネスドリブンのプロダクト作りをしてきたんだなと感じました。ユーザーにどんな価値を届けるかを主体的に考えるというより、「顧客と折衝している事業サイドからの要望だから」という理由で仕事を進めている状況でした。

象徴的でびっくりしたのは、ある程度仕様や要件が固まってきたときに、メンバーから「社長に見せなくて大丈夫ですか？」と言われたことです。開発チームで設計した仕様や要件が「ユーザーに価値を届けられるか」をとことん突き詰めるわけではなく、ビジネスサイドの言うとおりに作れば問題ないというスタンスでプロダクトづくりをする文化が根付いているように感じました。

山口

オンライン商談のSaaSは、もともと社長がコールセンター業務をしていた原体験から生まれたプロダクトです。

以前は、「こういったものがほしい」というアイデアベースで機能追加をしていました。しかし、社長自身が考える最強のオンライン商談ツールであることを追求し続けたあまり、プロダクトをグロースさせたり、ユーザーの課題を特定した改善ができていない状況でした。

及川

プロダクトサイドが強くなったことを、セールス側はどう受け止めていますか。

山口

「返しきれていなかったクライアントからの要望にプロダクトとして答えられるようになった」とポジティブに喜んでくれる人が少しずつ増えてきています。

ビジネスサイドとは、営業課題とプロダクト課題について、毎週ディスカッションを重ねているため、コミュニケーションは深まってきていると感じています。

及川

最近機能追加されたリモートコントロール機能は、御社のプロダクトグロースにおいて、どうたどり着いたアイデアなのか教えてください。

山口

大口顧客である大手金融機関の顧客課題からのスタートでした。顧客課題をどう技術的に解決できるか、私が原案を考えました。限定的な企業向けのベータ版としてリリースした後、一般向けにも出していくことになりました。

及川

個社向けのプロダクトは個社に最適化しているため、汎用化すると誰にも刺さらない恐れがあります。しかし、特化しすぎるとスケール感がなくなってしまう。いいあんばいの粒度はどう判断しましたか。

大歳

個社の業務プロセスの課題にフォーカスしすぎるとスケーラビリティがなくなりますし、風呂敷を広げすぎるとコアバリューがわからなくなります。

そのため、ユースケースのパターンを洗い出し、こういった業種のこの業務プロセスで価値を提供できるという芯を見据えました。

ほかにも転用できそうなものもありましたが、ファーストタッチとしてはソリューションには手を入れず、コアを見極めた上で汎用性の粒度を設定していきました。

及川

組織面として、ビジネスドリブンからプロダクトドリブンの流れにある中、組織としてプロダクト力を高めるようなエピソードはありますか？

山口

ユースケースDBというものが社内にあります。セールスが顧客とのコミュニケーションによって集めてきた「リモートコントロール機能はこんな場面で活用できるんじゃないか」という情報を集めたデータベースです。こうした情報をプロダクトに反映していくために、活用しようとしています。

大歳

会社全体としてユースケースをためて、プロダクト開発に生かそうという動きが醸成されたことが大きな変化だと思っています。

プロダクト組織も顧客とのタッチポイントをもち、さまざまな顧客体験の情報を獲得し、なぜ作るのか、何を作るのかを行ったり来たりしながら、プロダクト・ビジネスサイド両面で情報連携ができるようになってきています。

及川

会社としてのコアと、プロダクトはどのように連携を取っているのでしょうか。

大歳

プロダクトのビジョンは、コーポレートのビジョン・ミッションと紐づく形で策定しています。そして、プロダクトの世界観を設定し、具体的な指針として3つのプリンシプルを設定しています。

これに2〜3年単位で策定した経営戦略、プロダクト戦略を紐付けて、さらに単年の単位でロードマップを策定しています。

プロダクトを取り巻く外部環境が変わったときは、プロダクトイニシアチブや経営戦略と結びつけながら、プロダクトの方向性が間違っていないかを確認して進めています。

及川

PdMの評価制度について教えてください。

大歳

「JRD(Job Role Description)」という等級制度に基づき、半期ごとに個人のミッションを立て、ミッションの達成度合いをプロダクトの担当役員やゼネラルマネージャーが複眼で評価します。評価の参考情報として匿名の360度評価も取り入れています。

また、アサインされるプロジェクトのレポートライン上の上司が組織上の上司ではなく評価の難しい場合には、別の部署の上司が評価することもあります。

今後はPdMの職務内容や責任の度合いによって再定義した役割に応じてJRDをより詳細に定義し、成果やプロセスの明確な評価基準を設定することで評価者と被評価者の認識ズレがおきないように取り組んでいく予定です。

また、来期からは「テクニカルに特化したい」などの個人のWillに広く応じられるキャリアパスを設定し、JRDと連動して伸ばすスキルをより明確にした育成の仕組みづくりも設計していきます。

及川

御社のPdMの醍醐味や魅力について教えてください。

大歳

醍醐味は大きく3つあります。1つめは当社の現在の事業フェーズに合わせて、プロダクトマネジメント体制を整備し、組織を変革させていく体験ができることです。

プロダクトカンパニーへの変容に向けて現在最も力を入れているところで、ここに携わって頂くのは大きな醍醐味であるとともに、PdMとして非常に価値のある経験を得られると思います。

2つめは、OPMWに合わせて、体系的にプロダクトマネジメントを実践する経験と、その中で獲得できるスキルや知見です。例えば、インタビュー等の顧客リサーチの設計手法や獲得した一次情報と当社で蓄積しているDB情報とを組み合わせた示唆の出し方などが挙げられます。

3つめは、セールスにおけるバリューチェーンの知見が深く得られることです。

岩本

セールスの領域において、デジタルやデータ分析によって起こせるイノベーションはたくさんあります。デジタルの力で、新たな価値を生み出すプロダクトを作りたい人が活躍できる会社です。

山口

いいPRDを作成できるPdMは少ないと感じています。しかし、当社ではストラテジフェーズを型化しているため、PRDのコンテキストにあたる部分を成果物で埋めることができる。こうした細かいレベルで、プロダクトマネジメントの型化を一緒に経験できることが、当社で働く面白さのひとつです。

さらに、セールステックはこれから伸びていく分野であり、ブルーオーシャンであることも醍醐味と言えます。


構成：久保 佳那
撮影：波多野 匠