【これから無職】新卒入社した会社のPO・PdMをする過程で退職までに考えたこと
田中です。「バイトル」を運営するディップにてPO・PdMをしており、2025年1月17日最終出社、1月末日で退職します。
商品開発本部バイトル部に所属し、「バイトル原稿の作成をアシストする生成AIプロダクトを作るぞー！伸ばすぞー！」ってやってきたのが2024年。
2025年からは無職（フリーランス）として独立し、引き続きPdMロールを続けます。守破離の「守破」までやって、物理的に「離」れたような…(？)
「バイトル原稿作成Copilot」のPO・PdMをする中で主にこのロールについて考えていたことを、退職という区切りで整理しようと思います。
2025/1/17で、dipを退職しました。 大学3年からインターンとしてお世話になりはじめ、4~5年もここの人達とやってきたんだなと思うと、社会人としての人格形成にもきっと大きな影響を受けているんだろうなと。 感慨深い気持ちがありつつ...
Posted by Takashi Tanaka on Saturday, January 18, 2025
本記事で取り上げる田中最後のプロジェクトの施策内容は、社内インタビュー記事である程度細かく話しているので、参考に載せておきます。
どういうPJやねん、という話はこのnoteではしません。
僕はPOとして、何がしたかったのか
PO（プロダクトオーナー）をやってみて感じるのは、ひたすら人のマネジメントの難しさでした。
僕はこのPJ（プロジェクト）で管理職として働いていたわけではない。メンバーの給与が決まるような、いわゆる縦割りのマネジメントは行っていません。
しかし、PJ体制は執行役員Sさんの直下であり、POが実質的にチーム全体への評価を決定づける最大要因だったと思います。僕が「うまくやればチームは評価される」かつ「ミスすればチームは叱責される」という気持ちの中で働いていました。
チームにPOの方針にしたがって動いてもらうので、最短距離を描くのか、n倍距離のルートを描くのかによって、メンバーのアウトプットが1/nになる。相対的に魅力的なチームであるために、遠回りは避けたかったです。
PJのスケジュールを守りたかった
POの責任範囲であり、自分の独断と責任で決定していたのは以下。
PJのロードマップ
スコープとする範囲
検証仮説と、そこから採用するインサイト
開発施策の着手優先度（バックログの並び順）
適切な判断をできるよう、社内のステークホルダーに意見を聞き回るが、皆々様からの意見はおおよそ食い違うため、最終的には自分が最適だと考える進め方でプロダクトの企画開発チームには進んでもらうことになります。
検証する仮説を間違えば1ヶ月、着手優先度を間違えば2週間… と、理想的なスケジュールと乖離が出るんですね。
（本来、仮説検証が間違うのは別に悪いことではない。が、一発目検証で当たる前提でスケジューリングしてPJの迅速化を図り、遅延バッファは開示しないため、ステークホルダーとの日程感再調整の労力を考えるとPO的には絶対遅延させたくない現象は、同業であれば共感してもらえると思います。）
設定した期限の中で、as-isとto-beの定義・勝ち筋の発見・概念検証・技術検証・プロダクトリリース・事業インパクト創出・効果検証 を行い、プロジェクト開始時のスケジュールとズレないことが理想的な運びです。
できる限りスケジュールを維持するのがPOのプロダクトをデリバリーする（納期に確実に納品する）業務と考えていて、バイトル原稿作成Copilotのプロジェクトでは、ほとんど完璧に遂行できたと振り返ります。
【プロジェクトを迅速に進めるために、やったこと】
プロトタイプは自作して説得材料にした
ステークホルダー全員で合意形成MTGを実施する前に、キーパーソンの合意はあらかじめできている状態をなるべく早く実現するようにした
初期議論のベースは実現可能性の検証だけに絞り、懸念事項の議論の前にフィジビリティテストを行って、懸念を解消していく順番・着手のマイルストーンを整理した
PJの投資対効果を高めたかった
プロジェクトが続くための必須条件はロードマップ完走時に回収できる利益に対して、投資額が許容範囲におさまっていることです。
プロジェクトの投資対効果を高めるのも、1~2番目くらいに大切な仕事だと考えています。
（事業的には投資対効果が最も大切だと思いますが、POは本来プロダクトのデリバリーに責任を持つ役割であり、実体験としてデリバリーに責任を持つだけで非常にハードだったため、エグゼクティブ側で責任を持つか、POとは別にPdMの責任範囲として分解しつつPOも理解して施策の着手順がチグハグにしないように気をつけるのがいいと思います。）
自分自身がPO・PdMとしての育成期間中なら、多少のことで何が言われることはないでしょう。
しかし、一人前の看板を背負うなら、背負い続けるなら、「投資に利益を還元する」のがPO・PdMの使命であると考えます。
【投資対効果を高めるために、やったこと】
プロジェクトのスコープに意見するようにした
最初のスコープの中で、核心部の検証 ＆ 投資対効果が最も高くなるように調整する
最初のPJで採算を取ってしまえば、同じスキームの施策は確度高いと判断できるので、投資対効果が多少低くても遂行されやすい
利益貢献性が高そうな施策から順に着手優先度を高くした
結果としてプロダクトには穴がある状態でリリースになった
「成熟期に入った」と判断されてから穴を埋めるリリースを増やした
POをやって「人がすべて」を実感した
プロジェクトの評価がチームメンバー評価の天井を決める
プロダクト開発は、評価を定量化するのが難しい領域です。前提チームワークであり、プロダクトが優れているから売上やコスト削減に直結するわけではありません。
ただ、会社としては利益貢献してくれた方が評価しやすいです。昇給原資も元を辿れば営業利益を人的資源に再投資した額となります。
評価は給料に変換されるため、メンバーの利益貢献性をみる指標としてプロジェクトの投資対効果と進捗から、評価が形成されます。
（利益貢献性ではなくスキルを評価することで納得感ある評価をする専門職が大半を占める企業もあるが、スキル評価だけだと営利組織である企業のビジョンに目線を合わせられないため売上貢献を評価基準に含む判断が行われていると感じていました。利益だけ見てしまうと収益事業に従事している人ばかり評価されて不健全であるため、両方から評価するのは妥当だったと思います。）
メンバーへの評価還元を考えると、プロジェクトをうまく進行させることで評価の土台ができます。プロジェクトの成果をつくり、メンバーの貢献をアピールしないと、評価されるメンバーになってもらえません。
評価されないとメンバーはプロジェクトから離脱していく
プロジェクトが続くためには、人がいることが必須。メンバーがいるというのは、会社のプロジェクトに対する投資です。
評価されていないメンバーには、プロジェクトへの貢献度を上げるか、収益性が高いプロジェクトに貢献することで評価を上げるよう、組織の力学が働きます。
人材を有効活用できる場所への配置転換が、長期的に行われていく感じ。
これは会社側が人事配置として行うこともあるし、個人が異動願を出したり転職といった方法で行うこともあります。
（企業の収益性に還元されるか、個人の収入額に還元されるかの違いで、資本の回転効率を上げるという意味では同じ）
ディップは人材流動性が高い環境だったので、プロジェクト進行における懸念事項として常に考えていました。
評価されないチームでプロジェクトが失敗する構造ができあがる
「仮説を実証できない」「いつまでもユーザーがつかない」「プロダクトから生まれる売上やコスト削減額が投資額に届かない」etc…
それは別に問題ないと思います。撤退ラインまでやったら諦めて次を目指して行けばいいし、たくさんの失敗の中からしか成功は生まれないはず。
最も良くないのは、やれば一定の利益を目指せるのに、メンバーやリソースがないせいでプロジェクトを進められなくなることです。
社内のリソースには限りがあるし、ポジションやスキルといった人材価値のフィットは長い時間を経て構築されるもの。一度失ってしまうと体制を立て直すのにはそれなりに時間がかかってしまいます。
するとスケジュール遅延・不具合が増加・要求漏れなど、プロジェクトの品質が下がりスケジュール感を守れなくなっていきます。僕は運良く、チームがすでにある状態から人を減らさずに進めることができましたが、一人でも欠けていたらQCD低下は免れず、成果実現は到底不可能だったと感じます。
心の底から「皆様のおかげです」と思います。
【チームメンバーの評価のために、やったこと】
社内の表彰プログラムに、メンバー全員の推薦文を書いた
そこから表彰者が二人出た
表彰者を決めている役職者にプロジェクト全体の進捗と、各個人の貢献を定量的に伝える機会になる
メンバーが表彰されると、プロジェクトも全体的に上手くいっていると認識されるようになる
メンバーのスキルをヒアリングし、それぞれの専門分野では意思決定でそのまま採用するようにした
POとしては安定的にPJが稼働し収益性を確保できれば、そこに至るアプローチはどんな形でも問題ない
ロードマップを満たせる提案であれば、HOWの部分はそのまま採用するようにして各施策の成果は本人に還元するようにした
会社を辞めるという選択に至るまで
なぜ今、このタイミングを区切りにしたのか
「PJは終わることが目的、プロダクトは続くことが目的」
こちらは仲良くして頂いた部長さんに教えてもらって知った言葉です。
この言葉は確かにその通りで、プロダクトとして考えたとき、持続性があるスキームを構築し今後とも広がっていくビジョンで意思決定をしていくことは、とても大切だと感じます。例えば、技術負債を残さないとか。
しかし、「バイトル原稿作成Copilot」は社内の解決を最大の目的としています。プロジェクトとしての側面が大いにありました。
特に初期であればあるほど、期日切ってプロダクトが社内で使われる状態を作り効果が出ている状態まで移行させていく、ということが求められる傾向が顕著です。
僕はこのように整理してみました。
プロダクトを作って導入し、一定効果を出すまでが前半戦（PJの戦い）
プロダクトを活用して広く展開していくのが後半戦（プロダクトの戦い）
この前半部分を1周やりきることが1つの”仕事”の区切りであり、後半部分は終わらないことを目的としてずっと続くため、区切りを決めるのが難しい気がします。
プロダクト型の業務は以前から経験がありましたし、プロジェクトな部分で自分を試したい気持ちもあったかもしれません。
勉強のつもりで入社したんだったな、と思い出した
そういえば、元々新卒で就活した時点で、起業したかったことをふと思い出したんですよね。
ただ、あまりに能力が足りず、社会への解像度は低く、挑戦して飛び込む前から詰みまでのルートが見えていました（見えてる分、逆に解像度高かったかも）。
それが、ディップで働かせてもらい、在籍中に副業も含めて現場を回り、実務と案件獲得ができるようになりました。大きな事業を作れた経験はないですが、事業を作る方法を飯のタネにして、自分一人が生きていく分には困らない仕事にありつけるようになりました。
このタイミングでなら、新卒で諦めた挑戦にもう一度トライできる、と確信したので、退職に至りました。
無職になったけど、エンジンはまだかからない
さて、退職を決めて実際に会社を辞めたわけですが、まだエンジンがかかっていません。もっとブルンブルンな予定だったのですが…。
「フリーランスはフリーターか無職みたいなもんだよ」と、先輩の起業した方に言われました。おっしゃる通りで、実態が担保されない不確実な存在になるということです。
僕は無職だ。それは忘れずに、リスクをとった分だけ得られるものを増やしていく覚悟に似た想いが必要だと思います。
間近では副業と同じ状態で、お世話になっている人・会社からのお仕事をこなしつつ頼らせて頂きつつ、エンジンふかしていきます。
ご迷惑をおかけしたB社のTさんにマジで申し訳ない気持ち
退職の少し前から本業と副業を逆移行していく期間があったのですが、このあたりで負荷かけすぎてしまい、思い返すと頭が変だったなと…。エンジンかからない原因もここにあります。
今ですら、まだ変な気がします。
テキストの書き味が違います、ポエムじゃないか、誰が書いているんだ。
「何社か仕事を掛け持ちしたらフリーランスでも安心だろう」と、気軽に参画しまくった結果、ご迷惑をおかけしてしまいました。大変申し訳ございませんでした。
生活のため、自己実現のため、一緒に働いてくれる皆さんのため、自立した大人になっていきます。
今後とも、よろしくお願いいたします。
＼ さぁ、いくぞ！／
