【資料公開】pmconf 2022 で「日々の意思決定で使うB2Bプロダクトマネジメントサイクル」のタイトルで発表しました

介護事業者向けの経営支援プラットフォーム「カイポケ」で、プロダクトマネージャー兼アーキテクトを務めている三浦です。

11月2日にオンラインで開催された、プロダクトマネージャーカンファレンス 2022(pmconf 2022)で、「日々の意思決定で使うB2Bプロダクトマネジメントサイクル」のタイトルで発表しました。

発表要旨は以下のとおりです。

プロダクトマネージャーの重要な仕事の一つに意思決定があります。ユーザー価値を生み出すために、プロダクトマネージャーはプロダクトマネジメントトライアングルそれぞれの観点から次に作るものは何か?要件は何か?作っているものはユーザー価値があるのか?など様々なイシューに対して開発チームとして日々、意志決定をしなければなりません。さらにB2Bプロダクトの場合は法令や行政、マーケット、プロダクト導入決定者の観点が加わり、プロダクトマネージャーにとって意思決定は難しいものになります。

このセッションでは、B2Bプロダクトマネジメントにおいて必要な観点が何かを整理し、どうやってプロダクトマネジメントトライアングルを使って意思決定をしていくのか実例を交えて紹介します。

(セッション内容紹介より)

2022.pmconf.jp

この記事では、発表資料とともに、発表時に寄せられた質問の一部への応答・補足説明を公開します。

発表内容やカイポケの開発についてより詳しく聞いてみたいという方は、 ぜひカジュアル面談にお越しください!

open.talentio.com

資料

質問への回答・補足説明

Q:複数の介護形態でペインの発生場所も異なる中で、どのように優先度をつけてきたか、これまでとこれからの話も踏まえてお聞きしたいです。

前提として、介護業界は非常に広大な市場ですので、基本的には介護業態によって市場が細分化できます。その上で、優先順位は、マーケットの大きさ、エス・エム・エスの強みがフィットするかなどの要素を掛け合わせて決めています。まずは細分化した市場を選んで、特に注意すべきペインに取り組んでいくという形です。

Q:歴史の長いプロダクトだとは思うのですが、それならではのプロダクトマネジメントの難しさはありますか?

歴史が長いので、「どうしてこういう仕様になっているのか」という仕様がわからない箇所がどうしても出てきます。カイポケは18年以上の歴史がありますので、当初のメンバーは当然ほとんど在籍していません。そうすると、仕様の「なぜ」はもはやリバースエンジニアリングで解き明かしていく感覚になります。

Q:アクセスコントロールの例で、外側のトライアングルから具体化していくのが分かりやすくていいと思ったのですが、トライアングルのバランスはどんな感じで取っていくのでしょうか

まずはトライアングルの登場人物のペルソナを考えています。

  • 開発者の市場...エンジニア
  • 顧客(ユーザー)...介護事業、意思決定者(経営者)
  • 行政(GTM: Go To Market)...厚労省、財務省

三者が何を考えていて、今後何をしたいのか?を意識的に考えています。その上で、例えばAという要件に対して三者が「いいよね」って言ってくれるかどうかを考えて判断しています。

Q:トリプルトライアングルを用いて意思決定するときにバーティカル SaaS ならではのアプローチってありますでしょうか?よく使うパターンがあるのかどうか気になります!

前提として、個人的にトリプルトライアングルを使うのはtoB向けがメインだと思っています。

そしてVertical SaaSになると、「ペインの深さ」だとか、「業界にいかに深く入り込めるか?」がポイントになってきますので、トリプルトライアングルの三つの角をさらに分解する、例えば顧客(ユーザー)でも「経営者、管理職、従業員」とさらにトライアングルを作って考える、といったアプローチを行っています。

Q:法令対応はドメインエキスパートのような方がいるのでしょうか?難しそうです。。

もちろんいます。介護業界からドメインエキスパートとしてお越しいただいた方もいらっしゃいますし、おなじく介護業界出身の方がPdMをしているケースもあります。

業務上の細かなやり取りや、無数に種類がある帳票などについて、どういう目的で作っていて、次の工程は何か、などを把握して開発していくには、やはりドメインエキスパートの存在は不可欠です。

Q:トリプルトライアングルの導入について、どう使えばいいかわからない?という事がありそう…つまずいたポイントなどあれば教えて下さい

外側のトライアングルから考えることは大事だと考えています。

最初は内側のトライアングルから整理していました。しかしそうすると、例えば、アクセスコントロールについて足りない観点が出てきます。カイポケの場合であれば、行政の出しているガイドラインで遵守すべき項目が定められており、これは最初から要件として取り込んでおく必要があります。

外側のトライアングル(法令)から要件を抽出していかないと「蓋を開けたら法令遵守できてないかも?」みたいなことが起こるとわかってきたので、外側からトライアングルを作り始めるようになりました。