プロダクトマネジメント研修で得たプロダクトビジョンの重要性
2022年3月25日、Tably株式会社の及川卓也さんを講師にお招きして「プロダクトマネジメント研修」を開催しました。
及川さんは日本国内のPdMコミュニティの中心人物であり、組織がIT活用をビジネス基盤とするための教科書とも言える「ソフトウェア・ファースト」（日経BP）やプロダクトを成功に導く牽引役のPM（PdM）という職種に必要な知見をぎゅっと詰め込んだ「プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで」（翔泳社）の著者としても広く知られたリビングレジェンドです。
講義自体は2時間。何度か及川さんの講演を聞いた経験上膨大な知見を２時間で共有されるとなると及川さんは相当な早口になるはず。ヒアリングの集中力が勝負だと身構えていました。 ところが開催日の約2週間前。本講義を企画したLegalForceの村田隆裕PdMが参加予定者に向けて事前課題を投下しました。
圧倒的ボリュームの事前課題
その課題とは合計7本総時間約2時間半強の講義動画、慣れていても1.5時間程度は要するであろう個人ワーク、さらに全体を通して3時間は議論が必要なグループワークの3部構成。 話を聞くだけでワンランク上のPdMの知見が得られると考えていた私は甘かったです。挑まなければ得られない。とはこのことだと反省し、当日を迎えるまで学習の日々をチームと過ごしました。
個人ワークはエレベータピッチ、リーンキャンバス、バリュープロポジションキャンバス（付随してペルソナ作成）の3つのフレームワークに従って担当している製品の情報をまとめることでした。まとめた内容を同じ製品を担当するチームで議論し、3つそれぞれをグループで作成したバージョンにまとめ直します。
言葉のブレは認識のズレ
このようなフレームワークの成果物は当然、言葉（文章）で構成されていますからほんの少しの認識のズレが選ぶ言葉の違いとなって如実に現れてしまいます。 最初から1つを作るのではなく個々人で作ったものを発表するという流れは、認識のズレの見える化ができてしまう発見の連続で、非常に有意義でした。
PdMという職務の難しい部分は、このように文章化した資料や言葉を駆使して物事を伝え、人を動かすところだなとつくづく思います。 逆に、だいたい意見が一致していそうな部分（例えばたまたま似たような表現を使って言い表した部分など）では「あー同じだね」といった具合に認識が雑になりがちなことも面白いところです。PdMなどの要件をまとめるフレームワークの存在意義は、そこに置いた情報からチームが新しい認識を発見すること。議論することだと及川さんは言いましたが、講義でフレームワークの「使いかた」と同時に「俯瞰のしかた」も指導してもらえた今だからこそ、そう思えるのかもしれません。
講義当日は持ち寄ったグループワークに対して及川さんが書きかたについてのアドバイスや俯瞰の方法を指南してくれるワークショップ方式の進行でした。加えて日頃の開発業務で抱いた様々な質問事項についてQ&A方式で答えてくださる機会でもありました。
本質を突く数々のアドバイスをご紹介
ここからは、講義中の及川さんの数々のアドバイスから、弊社製品に限らず幅広く示唆を感じていただけるのではないか？と感じた部分について抜粋してご紹介します。
Q＆Aより
改善系のタスクと新規開発での優先度でどちらが重要？
（弊社のように立ち上がって数年経ったベンチャーには非常に気になる内容です！）
実際にはプロダクトの成果指標（KPI）を作ることが重要で、事業としての成果は当然KGIであり収益。しかしそれだけでなく我々はプロダクト成功の3つの要素事業収益、顧客価値、ビジョンの達成に対して貢献する1つのKPIをNorth Star Metric（重要目標達成指標）で定義し、この中にKPIがサブツリーしていき、そのうえであるKPIを達成するためには、いまやってる施策を改善してやるか、あるいはそれはやりきった前提で新たな施策をつけるか、が見えてくる。 改善系と新規系。これらはあくまで手段であり、どちらが有益かを選択するのは無理な話で、これらは単なるアウトプットだ。その結果として成し遂げ得るアウトカムをNSM( North Star Metric)：プロダクトの方向性と成長を示す指標 から得たトップKPIをサブツリー化分解して今どのくらいの数値としてあげられるのか？挙げられるとすれば改善系なのか、新規開発なのかを見極めるのが良いだろう。
ワークショップより
言葉のあいまいさの排除について
例えば細かい部分で言うとアーリーアダプタを「月10件以上の案件を抱える企業」と定めた場合100件でもそれ以上でもその定義に入ってしまう。絞り込む意図で規定する場合正確には「10件程度」と書いたほうがよい。 また、アーリーアダプタという初期の制約が外れ顧客セグメントを広げる時、アーリーアダプタの定義から何を外すのか？をよく検討してみよう。 例えばITの導入が容易な、新規技術導入を好む層、部門規模が小さい、どれが外れるだろう？ 例えば部門規模が小さいという条件に注目すると、小さい、大きいという言葉も定義の共通認識を明確化すべきだ。規模は売り上げなのか、社員数で測るのか？部門の人員規模？あるいは月間の案件数か？ ドキュメントでは多義的な用語を排除して共通イメージを明確にしよう。
製品の圧倒的な優位性とは？
外の人に話さなくても構わない部分。なぜそのプロダクトが絶対成功すると思っているの？と訊かれた時に「なぜなら俺たちは！」と、（胸を張って）言えることである。他社があとから参入してきても、できないこと。やろうとしても無理だと考えていることを書くと良い。 また、ハイレベルコンセプトもパッと見た人がすぐ理解できるような内容である必要はない。自分たちはこういうものを作るんだ！という（気持ちの）ことが表されていることが重要。 逆に独自の価値提案についてはランディングページに書いてあることをそのまま書いてもよい。 （この部分数字に裏打ちされた事実を述べるというよりは製品に対する自信や意気込みが問われる部分なのだと理解して非常に腹落ちしました。）
GAINとPAIN
LegalForceが手がけている2つのプロダクトは、バリュープロポジションキャンバスの顧客のペイン、ゲインの枠を見る限りゲインを提供することが少なく、ペインを解決することに内容が偏っている。本当にそうか？と是非考えてみてほしい。粛々と仕事をこなすTO Bのターゲットユーザーがやりたいことは、それこそ粛々と仕事をし続けることがやりたいことだろうか？ミスがないようにすることだろうか？彼らもそのような仕事の中において、達成感を得たいと思うはずではないか？その仕事の達成感を高めることがゲインではないか？このように製品の価値を考えるにあたってはゲインのことについてもっと考えたほうが良いのではないだろうか。 なお、バリュープロポジションキャンバスの右と左はそれぞれ独立して書き出した後に優先度順重要度順で並べ、それぞれがフィットするかを確認することが重要だ。ペインを、ペインリリーバーが解決する構造で書くべきだ。製品とサービスの機能を細分化しただけになってしまうのは気をつけたほうが良い。対応関係をうまく洗い出そう。 また、ペインの逆がゲインであるとは必ずしもならない。何か起きるとやだな、が起きなかったら良い。これは自分ごとと考えると別にうれしくもなんともない。病気しなくて嬉しい〜！と（能動的に考えて）喜ぶ人は多分存在しない。具体的には、起きて欲しくないこと、起きてほしいこと、どちらかに寄せて検討した方がいい。
プロダクトビジョンの重要性
LegalForceが作り上げたい未来とは一体どういうものだろう？ 減点主義の評価にさらされひたすらミスなく仕事をしたいと願うユーザーを楽にすること？そうじゃないこと？重要なのは、今現在のユーザーに向けたものがプロダクトではないということだ。そのユーザーを育ててあるべき仕事の未来を作るのがプロダクトビジョンだ。今現実には9割のユーザーがミスなく仕事をしたいと思っているかもしれないが、無駄な時間を削減して攻めの業務に徹したいユーザーもいるはず。どんな未来社会を作りたいのかというプロダクトビジョンを持とう。こうなりたい、こうしたいという潜在意識を持ったユーザーに向けて考えることだ。今のユーザーの課題に合わせてしまうことは儲かるかもしれない。しかしそれは未来ではない。それはビジョンではない。
我々は製品によってどんな未来を作り上げようとしているのか
最後に及川さんはフレームワークを使うことの意義について触れました。マスを埋めることではなくて、そこから発見をすること。チームで議論するためのツールであるだけで、LegalForceが取り組む契約業務のありかたや未来をどう変えるかについて考える道具として欲しいと話しました。 プロダクトは世界を変えるもの。より高い視座に立って、より良い社会を作って下さい。という締めくくりにはプロダクト開発という仕事の本来の価値を大いに感じる時間となりました。
そして、やはりプロダクトにとって最も重要な要素は、製品によってどんな未来を作り上げようとしているのかという「プロダクトビジョン」の独自性と、その独自性を信じて支えるチームの（ノリも含めた）協調性であると感じます。それこそが、リバースエンジニアリングできないプロダクトのコアになるはずです。そう。ブログを書いていて気がつきましたが、プロダクトというものは顧客も含めたプロダクトチームそのものだったんですね。
これからまたチームでアウトプットをブラッシュアップして、デベロッパーチームを始め関連部門にこの観点を広く共有していきたいです。
LegalForceはPdMを募集しております！
チーム一同切磋琢磨しておりますのでぜひお声かけください🙇♂️
この記事が気に入ったらサポートをしてみませんか？