安達隆氏はチームラボにて受託開発のディレクターを経験後、株式会社Socketを共同創業。

EC向けのマーケティングツール『Flipdesk』を開発し、サービス開始から1年でKDDIグループへ売却。0→1のプロダクト開発経験をもつ人物だ。

その後、フリーランス期間を経てメルカリに入社し、顧客対応や違反検知などの業務システム開発を担当。2019年4月にSmartHR入社し、現在はVPoPを務め、同社のプロダクト開発をリードしている。

SmartHRのプロダクト開発に関するナレッジを中心に、PdMに関わる様々な情報を日頃より発信しており、これからPdMを目指したい方、既にPdMとして活躍している方はウォッチしておくと自身の学びに繋がるだろう。

SmartHRの受注理由で意外と多いのが「現状では足りない部分もあるが、アップデートの速度がすごいから今後に期待して導入する」というもので、これは開発側にとって誉れでもあり、いい意味でのプレッシャーでもある。
あとセールスがすごい。

— Takashi Adachi (@asanebo_) March 15, 2021

SmartHRが、どのような流れでプロダクトを作っているのかをまとめた「図説：SmartHRのプロダクト開発サイクル 2021 ver.」は、顧客から上がってきた要望をプロダクトに反映されるまでの詳細なプロセスを知ることができる図解記事だ。自社のプロダクト開発サイクルとはどのような違いがあるか、自分たちの開発にも反映できる部分はどこか、を考えながら読むと、とても参考になるのではないだろうか。

おすすめの1記事、安達氏のマスターピース

図説：SmartHRのプロダクト開発サイクル 2021 ver.

続いて紹介するのは、delyでPdMを務める奥原拓也氏。奥原氏は大学から始めたプログラミングがきっかけとなり、在学中はRuby on Railsを主にした受託会社で約4年勤務。また、フットサルのマッチング&コミュニティサービス『ソーサル』の立ち上げを行った。

大学院へ進学したが、delyより誘いを受け、即日退学を決意し、ジョインすることとなる。同社にてクラシルのサーバーサイドのリードエンジニア、プロダクトマネージャーを歴任してきた。

自身が駆け出しPdMのとき、「こんな記事があったら良かったのに」と思えるような教科書を目指して執筆した「プロダクトマネージャー1年目の教科書」はPdMに必要なマインドセットから、PdMに必要なマインドセット、キャリア論などを包括的にまとめた傑作だ。

全部読んだ、教科書という表題に相応な内容でした。
そして、自分はまだまだだなとも思った。。。、
プロダクトマネージャー1年目の教科書｜奥原拓也 / クラシルPdM @okutaku0507 #note https://t.co/IFqk93Zn1d

— yamakazu (@yamarkz) December 7, 2019

また、その続編とも言える「プロダクトマネージャー3年目の教科書」では、1年目から3年目で何が変わって何が変わっていないか、直近のプロダクトマネジメントを取り巻く環境の変化などについて言及されており、日々現場で意思決定を行う現役PdMの方々への学びに溢れる内容だ。

おすすめの1記事、奥原氏のマスターピース

プロダクトマネージャー1年目の教科書

小城久美子氏はソフトウェアエンジニア出身のプロダクトマネージャー。ミクシィ、LINEでソフトウェアエンジニア、スクラムマスターとして従事したのち、BtoCプロダクトを中心にいくつかの新規事業にPdMとして携わる。そこでの学びを活かし、Tably社にてプロダクトマネジメント研修の講師、登壇などを実施。現在はLuupにてPdMを務め、プロダクトのUX改善を牽引している。

ロードマップでは、「数字」と「どの時期にどんな状態をつくるのか（アウトカム）」を示し、そのためのHowとなる機能については仮説検証を繰り返して作っていくのがよい、と主張する「ロードマップに機能を書くべからず」はPdMなら一読しておきたい。機能だけが書かれたロードマップを作成し、機能開発が遅延したり、差し込みタスクに溺れ、いつのまにかロードマップが陳腐化してしまう事態を防ぐことができるだろう。

・ロードマップとバックログは役割が違う
・ロードマップには機能ではなく期待されるアウトカムを書くべき

といういい話だった…自分も徹底していこう。

ロードマップに機能を書くべからず｜小城久美子 / ozyozyo @ozyozyo #note https://t.co/qgd16iSB7u

— 広野 萌 (@hajipion) June 10, 2021

「Runnnig Lean」の著者として知られるアッシュ・マウリャ氏が提唱するビジネスモデルを9つの要素に分けて考えるフレームワークである「リーンキャンバス」。新しいビジネスを企画する際によく使われるフレームワークだが、要点を押さえなければペラペラで意味のないモノとなってしまう。

価値のあるリーンキャンバスの作成方法についてまとめた、「肉厚なリーンキャンバスを書くには」は新規事業の立ち上げに携わる方や、プロダクトの全体像を整理したいPdMにもおすすめのnoteだ。

おすすめの1記事、小城氏のマスターピース

ロードマップに機能を書くべからず

「テクノロジーで人々を適切な医療に案内する」というミッションを掲げ、2017年に創業したヘルステックスタートアップの「Ubie（ユビー）」。2019年からの2年間で社員数5倍以上と急成長を遂げ、エンジニア採用環境が厳しい昨今の状況に反し、経験豊富なエンジニアを続々と採用している。そんな注目を集めるスタートアップでプロダクトオーナーを務めるのが敷地琢也氏だ。

新卒ではリクルートに入社。当時から医療業界の非効率性に問題意識を感じていたという敷地氏。そのような背景からUbieに入社し、現在は『ユビーAI受診相談』のプロダクトオーナー兼エンジニアを務める。

エンジニア出身のPdMならではの強みを活かし、プロダクトを急成長させたプロセスをまとめた「エンジニアの僕が強みを活かして施策推進したら、異次元の角度で数字が伸びちゃった話」はPdMのみならず、エンジニアとして日々開発を行う方も学びに溢れる内容だ。ダッシュボードの作成や、既存のアセットを活かしたコスパの良い施策の立案など、自身が持つ強みの活かし方が得られるだろう。

また、プロダクトを高速で改善していくためにのTIPSをまとめた「毎週10個以上の施策を実現するための主体的開発チーム作り」にも目を通しておきたい。施策の出す量がボトルネックとなってしまい、開発スピードが遅くなってしまうことはPdMなら誰しも経験したことがあるだろう。それを防ぎ、高速でプロダクを成長させていくための具体的な知見が集約されている。チーム内の情報格差を埋めるには？、チーム全体で施策の量を増やすには？など、気になる疑問に事例を交えて応えている。

1人に依存しない、開発メンバー全員から施策が出る環境づくり。これがなかなか難しく楽しい社内で参考している内容でとても参考になります！

毎週10個以上の施策を実現するための主体的開発チーム作り｜敷地 琢也 / Ubie Discovery @shikichee #note https://t.co/uiYFRT4Yom

— Masanori 3284 (@3284_m) May 6, 2021

おすすめの1記事、敷地氏のマスターピース

エンジニアの僕が強みを活かして施策推進したら、異次元の角度で数字が伸びちゃった話

最後に紹介するのは、ディー・エヌ・エー（DeNA）、メルカリなどのメガベンチャーでPdMを歴任してきた田辺めぐみ氏。NTTデータでKDDI情報系システムを担当後、DeNAではプロダクト責任者としてMAU数をモバゲー内で1位にまで成長させた。

その後、メルカリのプロダクトマネジャーを経て、子会社のソウゾウに立ち上げメンバーとして参画。メルカリアッテのプロダクトオーナーを経験し、メルペイではオンライン決済事業、OMO事業の事業責任者を担当してきた。

現在は、株式会社Sparkjoyを設立し、フリーランスやPMギルドにて新規プロダクトやプロダクトグロースの支援に従事している。

自身のメガベンチャーでの経験や、スタートアップでの新規プロジェクトの立ち上げ経験をもとに、プロダクトの開発フローごとに必要なことを俯瞰的にまとめた「メルカリなどメガベンチャーにありがちなプロダクト開発の企画フローと成果物」は、サービスの立ち上げに従事している人や、事業家を目指す読者の方が、0→1の全体像を把握するのを助けてくれるだろう。

めぐさんのnote、プロダクト開発のフローごとに必要なことが把握できて凄くわかりやすい！そして関係者にUXリサーチャーも入れてもらえてて嬉しい

メルカリなどメガベンチャーにありがちなプロダクト開発の企画フローと成果物｜田辺めぐみ @tanabemegumi #note https://t.co/nvgEBJXpnp

— mihozono (@mihozono) May 15, 2021

また、PdMであれば、日々仕様書を書くことが多いが、その中で他社の仕様書の書き方が気になったり、より良い仕様書の書き方について頭を悩ますことも少なくないはず。

そんな読者の方に手を差し伸べてくれるのが、仕様書の書き方についてまとめた「仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話」。ネット上には意外と具体的で実践可能な仕様書のイメージは落ちていないのが現実だ。

これから仕様書を書くことになる駆け出しPdMはもちろん、自社の仕様書をアップデートさせてたい方にも参考になるnoteだ。

おすすめの1記事、田辺氏のマスターピース

仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話

いかがだっただろうか？イノベーション・エコシステム発展のため、そしてベンチャーパーソンである皆さまに少しでも多く新しい学びをお届けするため、今後も「ベンチャーのプロフェッショナルから学ぶ」ことにフォーカスした情報を発信していく予定だ。

本稿でお届けした内容が、読者の皆さんの成長の一助となれば幸いである。