この記事はbellFace Advent Calendar 2021 の21日目の記事です。

はじめに

こんにちは。ベルフェイス株式会社でPM(プロダクトマネージャー）をやっております岩本です。ベルフェイスでは、オンライン営業システム「bellFace」という1プロダクトを、複数のプロダクトラインに分かれて相互に連携しながら開発を進めています。私はその中でもプロダクトの中核を担うオンライン商談の機能を管掌するプロダクトラインでPMを担当しております。加えて、直近ではプロダクトライン横断で進めている大きなプロジェクトがあり、そちらのリードPMも担当しております。

本記事内で語ること

自己紹介はこれくらいにしておいて、本記事の内容に入っていきたいと思います。本記事においては、ベルフェイスのようにビジネスドリブンで一定の規模まで成長した会社に対してどのようにプロダクトマネジメントを取り入れていったか、という部分にスポットを当てて書いていきたいなと思います。尚、戦略編と開発編に分けて公開しており、本記事においては開発部分（OPMWというプロダクトマネジメントフレームワークにおけるTechnicalフェーズ、プロすべ本でいうところのWhatやHowの設計・実装に相当する部分）にフォーカスして書いていきます。戦略編の記事はこちらですのでお時間あればご覧ください。

ベルフェイスのプロダクト開発組織と体制について

まずは現状のベルフェイスにおけるプロダクト開発組織と体制について説明させていただきます。ベルフェイスでは下記の図のような形で組織が分かれており、、プロダクト開発にかかわるメンバーはProduct GrかSystem Grのどちらかに所属しています。（GrというのはGroupの略称で一般的な会社における部署くらいに相当します）。Product GrにはPM、PMM、PO（TPM）、Designerといったロールを担うメンバーが所属しており、System GrにはEngineer、QA、Security、SREといったロールを担うメンバーが所属しております。ベルフェイスでは、bellFaceという1つのプロダクトをいくつかのプロダクトラインに分かれて開発を行っており、下記の図の赤枠に囲まれたチームがプロダクトラインを担当するチーム、緑色で囲まれた枠が共通職能チームとなっております。会社の組織図上はProductとSystemで別れておりますが、プロダクトライン上、対となるチームがそれぞれのGrに存在し、1つの仮想組織的に動くような形で開発を進めています。

各プロダクトラインの中での開発は基本的にはプロジェクト単位で行われており、いくつものプロジェクトが並行して動いています。

ベルフェイスにおける標準的な開発フロー

次にベルフェイスにおける標準的な開発フローについて説明させていただきます。その説明の前に、ベルフェイスにおけるプロダクトマネージャーとプロダクトオーナー（Technical Product Manager)の違いを簡単に説明しておきます。OPMWのプロセスに則った説明となりますので下記のプロセス図をご認識の上でご覧ください。

プロダクトマネージャー/PM

OPMWにおけるStrategyフェーズを主領域として担当し、プロダクトのWhy〜Whatを考える。なぜどのようなプロダクトを作るべきかをPRDに定義する。そしてその開発プロジェクトの開発タイミングの調整や参画メンバーのアサイン調整を行う。

プロダクトオーナー/PO（Technical Product Manager)

OPMWにおけるTechnicalフェーズを主領域として担当し、プロダクトのWhat〜Howを考える。PMが定義したPRDの要件を満たすプロダクトを作るためのプロジェクトチームを組成し、PRDに基づいたHowを設計し、リリースまでの開発プロセスのマネジメントを担う。

ある程度オーバーラップする部分もありますが、ベルフェイスにおいてはPMとPOではおおよそ上記のような形で役割を分担してプロダクト開発を進めています。OPMWのプロセスに則った開発フローの全体感を示した図が下記のものになります。

まずPMがStrategyフェーズを遂行します。その中で市場やユーザーの持つ課題の調査・整理を進めながら解決すべき課題の特定を行い、その課題に対する解決案の方向性の定義を進めていきます。ここで場合によってはプレトタイプ（「プレトタイプ」についてはこちらの記事を参照ください）によるPoCを挟むことで、解決策の方向性のズレや実現可能性の検証を行い、確度を高めながら解決案の方向性を定義していきます。最終的にはPRD（Product Requirement Document）という形で誰のどのような課題をどのようなプロダクトによって解決すべきなのかを定義します。
次に、作成されたPRDを元に実際にプロダクトを開発していくTechnicalフェーズに移ります。POはPMから受け渡されたPRDを元にプロジェクトチームを組成します（この際、各プロダクトラインの管掌するPMとEMがリソース配分の調整を行います）。プロジェクトチームにはPO、Designer、Engineer、QAが配属され、PRDに基づいた要件の定義や仕様の作成を進めていきます。プロジェクトによって多少の違いはありますが、仕様書やソフトウェア設計が記述されたDesign Docといったドキュメントを用いて作るべきプロダクトのHowを定義し、プロジェクト毎に最適なプロジェクト管理手法と開発スタイルを用いて開発を進めていきます。この間、PMはプロジェクトの重要ステークホルダーの一人としてプロジェクトに関わりながらプロダクトの方向性のアラインを担います。
開発が進み、最後のQA検証期間を経てリリースができる段階になるとGo To Marketフェーズに進みます。こちらでは、PRDに記載されているマーケティングプランに基づいてPM・POがPMMと連携しながらリリースを進めていきます。リリース後は、プロダクトがユーザーに対して想定どおりの価値を創出できているかを、事前に設計したKPIを用いながら評価を行い、引き続きエンハンスを行うか、プロジェクトを終了するか意思決定を行うことで一連の流れが完結します。
まだまだ改善できる余地はありますが、現状はこのような開発フローとなっています。

入社当時のプロダクト開発の状況

ベルフェイスではここまでに説明した体制とフローでプロダクト開発を推進しているのですが、この体制とフローが施行されたのは本年の4月で丁度私の入社と同じタイミングでした。戦略編で話したように、プロダクトマネジメントプロセスを段階的に取り入れていこうという合意の元、それに合わせた組織体制と開発フローが整備されつつありました。一方で、これまでの開発方法からの大幅な変更をどのように開発現場に浸透させていくか、既に動き始めているプロジェクトをどのように適応させていくかといった部分は手探りしながら進めていくような状況でした。

このような状況下でプロダクトラインの運営をプロダクトマネージャーとして担当したわけですが、プロダクトマネジメントプロセスを整備していく上で下記のようなの課題にぶつかるようになりました。

• 社内受託開発的な文化の中でプロダクトのWhyを見据えたWhat/Howの検討ができていない

• アウトプット偏重で評価プロセスが機能していない

それぞれの課題に対する打ち手

上記のような課題に対し、それぞれ下記のようなアクションをとっていきました。

社内受託開発的な文化の払拭

一点目に関しては社内受託開発的な文化の払拭です。これまで長らくビジネスドリブンで開発を進めていたことや、急成長に伴ってかなりタイトな開発を続けていたこともあり、普段の開発の中でWhyを見据えたWhat/Howの検討をあまり行うことができていませんでした。「担当営業がこう言っているから〜」「社内の偉い人が〜」のような、ユーザーとは違ったところに目を向けた開発上の意思決定が行われていたため、まずはこういった文化を少しずつ払拭できるようにいくつかのアクションを実施しました。

・ユーザーだけを見てプロダクト開発をして良いという開発上の心理的安全性の担保
・ペルソナ・シナリオといったユーザーに関する情報の整理と社内データベース化

まず、初期の頃はなるべく各プロジェクトに密に関わるような動き方をすることで、各プロジェクトの肌感を探りつつ文化の払拭を図るよう努めました。組織体制や開発フローは変わっても、それに応じて文化という部分はすぐに変わるわけはなく、開発現場においてしばしば「偉い人に見せてから決めたい〜」と言ったような発言が目立つシーンがありました。そういった発言が出るたびに都度、「組織体制が変わりプロダクトマネジメントを取り入れてやっているんだから、自分たちが今作るべきプロダクトのユーザーは誰なのか、そのユーザーにとってどうあるべきなのかを判断基準として意思決定をしよう。その意思決定によって生み出されるプロダクトのステークホルダーとの調整はPMの仕事なので、開発に関わるメンバーはユーザーのためになにを作るべきか、にフォーカスして意思決定していいよ。」という趣旨の説明を徹底して行うようにすることで、ユーザーだけを見てプロダクト開発を行うための心理的安全性の担保を図るように動きました。その結果、上記のような発言は徐々になくなり、POやDesignerといった各メンバーが、ユーザーに取ってどうあるべきか、という観点でスムーズな意思決定ができる場面が徐々に増えてきたように感じています。プロダクトライン全体ではまだムラがありますが、徐々にそういった文化は薄れつつあるように感じています。
さらに、社内で散らばっていたStrategy〜Technicalフェーズのアウトプットであるペルソナやシナリオといったユーザーの情報を、改めて整備し社内の共通データベース化を図ることで、そういった情報へのアクセスを簡単にできる環境整備にも着手しはじめています。ここが整ってくるとPRDに記述されている要素以外の部分において、より深いユーザーの情報に簡単に開発メンバーがアクセスできる環境が整うようになり、よりユーザーの解像度を高めて意思決定ができる土壌が整います。そうなるとより自立した開発チームになっていけると感じています。

評価プロセスの設計・テスト導入

次に、アウトプット偏重で評価プロセスが機能していないという課題に対して取り組んでいったことを説明します。
こちらは戦略編の記事でも少し触れましたが、これまでの成長スピードや開発文化の兼ね合いもあって、リリースすることがゴールとなってしまい、リリースしたものが正しく価値創出できているかという評価を行わないまま次の機能開発に取り組むといった状況が多く見られました。そのため、まずは各プロジェクトにおいてはリリースすることがゴールではなく、リリース後に評価を行い正しく価値創出が確認できたときをゴールとしたプロジェクト運営を行うよう促しつつ、PRD作成時に定義したKPIによってプロダクトの評価を行うスタイルを取り入れていきました。その結果、少しずつ評価を行う事ができるプロジェクトが増えてきています。また直近のプロジェクトではPM同士でPRDのレビューを行う中でKPIの項のチェックも行われており、プロジェクト間でのKPIによるプロダクト評価のムラもなくなりつつ有り非常に良い傾向だと感じています。
また、プロダクトとしての評価だけではなくROIという観点でのプロジェクト評価にも着手をしはじめました。まずは、プロジェクトの推進者であるPOにプロジェクト運営時に持つべき観点とそれを支えるプロジェクト運営方法を知識として共有しつつ、プロジェクト評価計画書の設計を行い、一部プロジェクトでの段階的な導入を推進しました。
もうそろそろ終わりを迎える複数のプロジェクトにおいて、評価計画書に則ったプロジェクト評価が行われるので、その結果を踏まえさらなる改善に励みたいと思っています。

今後取り組んでいきたいこと

これまでの流れを踏まえて、今後取り組んでいきたいことを述べていきたいと思います。今後取り組んでいきたいことは下記の3点です。

• プロダクトマネジメントプロセスの型化と類型化

• プロジェクト計画の精緻化・評価制度の強化

• PjMスキルの社内資産化と形式知化

プロダクトマネジメントプロセスの型化と類型化

4月以降の取り組みでプロダクトラインを超えて様々なプロダクトマネジメントプロセスが整備されてきました。これによって一定プロセスの型化には成功していると言えますが、まだまだ部分的に弱いところがあると感じています。それらのプロセスのさらなる強化は引き続き取り組んでいきたいと考えています。
一方で、今後作るプロダクトの性質によっては現状のプロセスだとプロダクト開発が行いづらいものもあるなと感じています。本年は、性質上似通ったプロダクト開発が行われていたため、問題にはならなったとは思いますが、来年以降はそういった性質のプロダクトも作っていくことが予想されます。そのためプロダクトマネジメントプロセスの類型化を行い、いくつかのパターンを持ち合わせておくことで、作るプロダクトの性質に合わせて柔軟にプロダクトマネジメントプロセスを変更できるような組織的素地を整えて行きたいと考えています。

プロジェクト計画の精緻化・評価プロセスの強化

本年は一部プロジェクトに対して、ROI観点でのプロジェクト評価を取り入れることができましたが、まだまだ改善の余地が多くあると感じています。特にプロジェクトの計画フェーズにおける計画の精緻化には取り組んでいくべきだと感じています。そのためにも、本取り組みを継続し、社内のプロジェクト評価を情報資産としてストックしていくことで、POがプロジェクト始動時において、過去のプロジェクト評価を参考に、より精緻な計画やより良いプロジェクト運営手段の選択ができるような土壌を整えていきたいと考えています。

プロジェクトマネジメントスキルの社内資産化と形式知化

最後にプロジェクトマネジメントスキル（以下、PjMスキル）の社内資産化と形式知化です。ベルフェイスにプロダクトマネジメントが取り入れられて求められる役割が大きく変わった職種のうちの一つがPOだと感じています。大きく変化した役割を全うしようと頑張っているPOチームですが、プロダクトラインを超えたPOチームでの連携が現状行えていません。他POの業務上のつまづきや、効果のあったアクション等を知って自分のスキルとするという仕組みを整備することで、POチームのサポートができればと考えています。
プロジェクト評価という仕組みを導入し、少しずつプロジェクト運営の状況が可視化され情報として貯められるスキームはできたので、そこからPOチームにとって役に立つナレッジや事例を抽出し、彼らの形式知化を促すような定例イベントを設計し、定期的に実施することでプロジェクトマネジメントスキルの全体的な向上を促すようなスキームづくりを行っていきたいと考えています。

一緒にプロダクトを作っていける人を探してます

これまでに書いた通り、優秀で前向きなメンバーとともに、良いプロダクトを生み出すためのプロダクトマネジメントプロセスの整備をやってきた1年だったと思います。めまぐるしい市場の変化によって苦しんだ部分もありつつ、これから取り組んでいくべき市場課題を見定めることができた1年でもあったと思います。そんなベルフェイスでは、セールスという領域で新たな価値を創出していくためのプロダクトづくりに取り組んでくれるメンバーを募集しております。下記Meetyのリンクより気軽にご連絡いただけると嬉しいです。

もちろんプロダクトマネージャーだけではなく、デザイナー、エンジニア等幅広いポジションで絶賛仲間を募集中です！下記リンクをご覧になって、少しでも面白そうだと感じた人からの連絡をお待ちしております！

ネクストエントリ

よこえもんことベルフェイスの凄腕エンジニア横江さんのエントリです。最近ベルフェイスに入社したヨガファイターよこえもんがベルフェイスID基盤の設計に関して記事を書く予定となっております。お楽しみにお待ち下さい！