ベルフェイス株式会社で取締役執行役員CTO兼CPOを行っている山口です。
ベルフェイスでは bellFace という主に電話起点でシームレスに視覚情報を付与するオンライン商談・接客ツールの開発・運営を行っています。
また自ら株式会社マギステルという会社も立ち上げて、アーリーステージのスタートアップから上場企業まで、技術顧問や経営顧問を幅広く行っています。
今回はベルフェイスが2021年5月ごろから本格的に取り入れ始めたOpen Product Management Workflow(以下 OPMW と略)についてお話していきたいと思います。
OPMWとはドイツの会社であるproProduktmanagement社が開発したプロダクトマネジメントのためのフレームワークです。
公式ウェブサイトの記述によれば以下のように説明されています。(日本語訳は筆者によるもの)
> Open Product Management Workflow™ は、プロダクトマネージャーのためのステップバイステップのガイダンスであり、以下のライセンスの下で無償で使用することができます。 このワークフローを私たちのコミュニティと一緒に開発することで、すべてのプロダクトマネジャーが世界的な知識から利益を得ることができます。
より具体的に言うと、OPMWではプロダクトマネジメントの業務を、
- Strategy Phase
- Technical Phase
- Go-To-Market (GTM) Phase
の3つに分けた上で、その3つのPhaseにステップを設け、ステップごとに実施すべきプロセスについて記載されたガイダンスになります。
引用：open-pmw.org
具体的には、顧客のペルソナや課題、シナリオを知り、マーケット分析を行い、収益性や新規性などを確認した上で、マーケットとどのように相対してビジネスプランに落とし込むかといったStrategy Phase(WhyからWhatへ)。
その後のプロダクト開発であるTechnical Phase (WhatからHowへ) 。
そして、マーケットにリリース・販売していくGTM Phaseなどに分かれています。
実際には英語とドイツ語のフリーブック(PDF)で説明がなされていますが、ベルフェイスでは2021年の2月頃から社内有志で和訳及び輪読会を実施し、最終的にこれらをNotionで社内の誰でも読めるようにしました。
ちなみに Notion 自体の導入は2021年5月から検討を開始し、8月からトライアル運用を始め、11月から全社員に開放しています。現在は社内ポータルや各組織のスペースや、全社会用のページ、全社員のプロフィールページといった会社組織に関わるスペースから、汎用的なプロジェクトテンプレートやプロダクトに関する情報など、様々な情報が整備されています。
顧客とマーケットを知ることから戦略策定を行う”Strategy”フェーズ、プロダクト開発の”Technical”フェーズ、マーケットにプロダクトを届ける”Go-to-market”フェーズの3つに分かれています。
数年前まではビジネス中心だった組織で、プロダクト中心の組織へと移行しようと試み、その中核を担う存在がOPMWです。
- ビジネスサイドとプロダクトサイドが分断されている
- プロダクト開発のフローがイマイチ整っていない
- プロダクトについて目線が揃っていない
などなど、プロダクト主導の組織づくりに悩まれている方々に参考になると幸いです。
今でこそ、OPMWによってプロダクトへの目線が揃ってきていますが、2、3年前は、「新たな機能や改善は、リリースされるまで何が開発されているか分からない」といった状況でした。
チームによって進め方も、全社への共有の仕方も違う状況で、かなり属人的なプロダクトマネジメントのフローになっていました。
他にも、ビジネスを中心に大きく成長してきた組織だったため、プロダクト自体もさまざまな課題を抱えていました。
- 過去にリリースされた機能が誰のために何故作られたのかが、ノウハウとして蓄積されていない
- エンハンスばかりで解消されない技術的負債・UX的負債
- 社内受託気質の開発で、アウトプット偏重な開発スタイル(典型的ビルドトラップ)
- 型化されず知見も貯まらずで、まったく成熟されていないプロダクトマネジメントプロセス
これについては、弊社VPoP岩本のnoteを是非ご覧ください。
会社としても、プロダクト主導の組織に移行することを経営方針として合意していたため、会社全体で共通のプロダクトマネジメントの型を持ちたいと考えていました。
そのような経緯があったため、ベルフェイスにおけるプロダクトマネジメントプロセスで参考になる型を作ろうとして取り入れたのがOPMWになります。
前述の通り、OPMWには大きく分けて3つのPhaseがありますが、それらを簡単に説明していくと、次のようになります。
- Strategy Phase
- Interview
- 顧客インタビューやアンケート、行動観察などを通じて顧客からの情報を得ます
- Identify
- 顧客のペルソナや課題、シナリオなどを特定します
- Analyze
- 多角的な分析により勝ち筋の分析を行います
- Check
- 収益性や新規性、プロダクトの提供手段の確認を行います
- Strategy
- マーケット展開やポートフォリオ、販売や価格、ポジショニング等を定めロードマップにしていきます
- Consolidate
- ビジネスプランとして整理し、Product Requirements Document(PRD)に落とし込んでいきます
- Technical Phase
- Delivery
- ユーザーペルソナやユースシナリオを具体的に定めて、プロダクトバックログに記載し、優先度を決めたり、スケジュールやコスト試算を行ったり、リリースプランを検討します
- Control
- 開発を行いながら、その都度に評価会議を行い、リリース判定を行います
- GTM Phase
- Plan
- マーケティング戦略や計画を定めたり、顧客とのコミュニケーションやリレーションを調整し、マーケットにどのようにプロモーションしていくかを検討していきます
- Prepare
- 購入してもらうための各種コンテンツの準備や、購買導線の設計、イベントの実施などを行っていきます
これらのステップに含まれるプロセスをいつでも理解できるように、弊社ではNotionのDatabase機能にあるBoard Viewを上手く使って、全社員がいつでもガイダンスを確認できるようにしています。
各Phaseのプロセスは、オリジナルの配色と同じように背景画像をつけているため、視覚的に分かりやすく整理されています。
また各プロセスは、原文の英文と共に和訳が付けてあります。
実際にStrategy Phaseを進める際に、一定のプロセスを実施した後で複数回のチェックポイントを設けています。
例えば、最初のチェックポイントまでに Interview と Identify を行い顧客の業務プロセスの全体像を把握し、そこに存在するペルソナや課題、シナリオを特定した上で、Analyze で競合分析やマーケットポテンシャルを調査した段階で、得られた情報と分析に基づいたインサイトをレポートしてもらっています。
OPMWという共通の型ができることで、自社のプロダクトや機能の開発が「今どのステップにいるのか」について共通認識を持てるようになり、チェックポイントとして機能しています。
このようなフレームワークは、浸透しないことには価値を発揮しないので、Job Definitionで使ったり、ロードマップで引用したりと、さまざまな場面でOPMWを使うことで浸透を図っています。
OPMWを導入したことによって、職種関係なくプロダクトに対して関われるようになりました。
そして元々あった課題はそれぞれ、次のようになってきたと思います。
- 過去にリリースされた機能が誰のために何故作られたのかが、ノウハウとして蓄積されていない
- PRDに何故作るか、何を作るかを整理しておくことで、プロダクトや機能が生まれた背景がきちんと分かるようになっています
- エンハンスばかりで解消されない技術的負債・UX的負債
- 過去に放置されていた技術的負債は計画を立てて一つずつ解消されるようになってきています
- 社内受託気質の開発で、アウトプット偏重な開発スタイル(典型的ビルドトラップ)
- 顧客をより知る事と、アウトカムの重要性を繰り返し伝えることで、顧客のエンゲージメントが着実に高まってきています
- 型化されず知見も貯まらずで、まったく成熟されていないプロダクトマネジメントプロセス
- OPMWを中心としてプロセスを型化する動きが出来ています
また、コーポレートチームなどでも輪読会が開催されたり、プロダクト中心の組織になりつつあることを実感しています（コーポレートチームで自主的に輪読会が開催されたのは僕も知らず、びっくりしましたw）。
一方で、OPMWには、アジャイルやスクラム開発の考え方は入っておらず、テクニカルフェーズがさらっとしか書かれていません。
そのため、『PMBOK』や『LeanとDevOpsの科学』などを参照しつつ、よりOPMWをベルフェイスに合うように厚みを持たせていけたらと思っています。
今後も、プロダクト主導な組織として、より良い仕組みをつくっていけたらと思います。