エンジニアのキャリアパスとして学ぶべきことの宝庫。株式会社タイミー・山口徹氏がすすめるCPOの仕事

皆様はじめまして。株式会社タイミーで執行役員CPO(Chief Product Officer)プロダクト本部本部長をしている山口 徹と申します。今回はエンジニアからのキャリアパスとして CPO という職種の魅力をお伝えしていきたいと思います。

• keyboard_arrow_down CPO になった経緯
• keyboard_arrow_down タイミーにおけるCPOの役割と業務
• keyboard_arrow_down CPO業務で活きるエンジニアリングバックボーンの優位さ
• keyboard_arrow_down エンジニアからCPO転身のために身につけるべきこと
• keyboard_arrow_down プロダクト戦略の楽しさ
• keyboard_arrow_down まとめ

私のキャリアは、前職ベルフェイスに入社するまでは一貫してソフトウェアエンジニア・ソフトウェアアーキテクトという職種でした。それ以前、長い間株式会社ディー・エヌ・エーで、ゲームプラットフォームの開発やスポーツ事業本部のシステム部門の立ち上げなどを行っていたため、よもや現在プロダクト部門の責任者になることなどは、当時思いもよらなかったと思います。

前職でCPOとなった経緯としては、スタートアップあるあるですが、CPOのロールをCEOが担っており、当然ながらそこまでの成長を牽引してきた原動力でもありました。しかし、レイター・ステージにもなってくると、プロダクトアウトで作り手がつくりたいプロダクトをつくっても顧客には全然刺さらず、顧客の声を聞き、顧客の課題を解決するようなソリューションにしていかなければならない。その過程の不確実性をできる限り減らすためにも組織にプロダクトマネジメントという概念を植え付ける必要がありました。

また当時は、経験豊富なプロダクトマネージャーが一人もいないということだったので、プロダクトづくりと同時に、組織づくりもやっていく必要性がありました。当初は執行役員CTOとして入社したのですが、入社2カ月後にCEOと話してCPOロールを兼務し、そこから二足のわらじを履くことになりました。

CPOロールはまったくの未経験なので、まずはプロダクトマネジメントの考え方や進め方を学ぶために、Open Product Management Workflow (以下 OPMW と略します)をベースに、フェーズごとにやらなければならない業務とその考え方を学習することから始めました。

努力の甲斐あって、OPMWは社内に共通言語として深く浸透するだけでなく、各プロセスにおける成果物を明確にしたり、PdM の採用や育成基準にも引用されるなど、さまざまな点で活用されました。当然ながらプロダクト戦略立案の骨組みとしても採用していました。

紆余曲折あり、新たなチャレンジをするためベルフェイスを去ることになり、充電期間を経て2023年5月に株式会社タイミーに入社することになります。このときはエンジニアリング軸で行くか、プロダクトマネジメント軸で行くか決めかねていたまま転職したため、入社して最初はエンジニアリング部門に関わることになりました。

転職して数ヶ月はエンジニアリング部門の組織強化に向けた動きに奔走する日々でした。しかし、当時のタイミーも前職同様にプロダクトマネジメント部門がほとんど組織化されておらず、その組織化を牽引する役割も重要ということで、2023年8月から事実上のCPOとして動き出し、同年10月から正式にCPOに就任しました。

というわけで、私のCPO就任に関しては2社いずれも、環境がそうさせたといっても良いかもしれません。

タイミーでは、現在「プロダクト本部」と「エンジニアリング本部」の形で部門分けされていますが、両本部で協力してプロダクト開発を行っています。我々はこの両本部を合わせて「プロダクト組織」と呼んでいますので、この記事でも「プロダクト組織」と呼びます。

CPOはプロダクト組織における最上位の戦略立案、推進が求められる役割です。そしてその戦略を戦術につなげていくこと、戦術を円滑に進めるための組織をつくっていくことに対してリーダーシップを発揮していく必要があります。

書籍『プロダクトマネジメント ビルドトラップを避け顧客に価値を届ける』の8章では、CPOは以下の割合で業務を行うとされています。

• ・戦略的な仕事 : 80%
• ・戦術的な仕事 : 0%
• ・運営 : 20%

ここで、プロダクトマネジメント関連職における戦術的な仕事とは、顧客の課題に基づいたソリューションを開発するための短期的な仕事を指します。戦略的な仕事とは、マーケットで勝利し、目標を達成するためのプロダクトや会社のポジショニングや方向性を指し示すことをいいます。運営とは、戦略を戦術的な仕事に円滑に進めていくための仕事だといえます。

戦略的な仕事の中ではさまざまな概念（ここでは詳しく言及しませんが、例えば戦略的意図やプロダクトイニシアチブなど）を共通言語にしていかなければならず、これらの概念を丁寧に説明していくことも必要な業務になります。

CPOは経営陣の一翼でもあるので、特にビジネス部門やマーケット部門などの責任者や、取締役陣との密なコミュニケーション、ネゴシエーションなども業務の一環になります。

プロダクトマネジメントはプロダクト組織全体で進めるべきものです。プロダクトマネージャーはその中で、中心的な役割を担うポジションにすぎず、プロダクト組織にはさまざまな役割の人が関わっており、チームで開発をしています。

従ってプロダクト組織をつくっていくという点において、プロダクト開発チームの中にいた経験はとても強力な知見であるといえます。

開発チームが抱える課題の中に技術的な課題があることもしばしばあります。課題のインパクトについて詳細な説明が無くともある程度想像し、見立てることができるアドバンテージは大きいです。

また開発メンバーの力量もある程度推測できるほか、チームのケイパビリティがどの程度あるかも想像がつくため、組織運営における強み・弱みを把握してアクションにつなげることも有利になります。特にプロダクト組織におけるマジョリティは、ソフトウェアエンジニアであることがほとんどだと思うので、この職種に土地勘があるということは大きなアドバンテージになります。

エンジニアリングバックボーンの優位性について述べてきましたが、当然ながら学ぶべきことはたくさんあります。
具体的に学ぶべきスキルについて述べる前に、大前提としてエンジニアとは担う役割が大きく異なる点を強調したいと思います。エンジニアはプロダクトをどのようにつくるか（How）が主たる役割であり、プロダクトマネージャーはなぜつくるか（Why）を見立てて定めることが主たる役割です。何をつくるか（What）は、チームによって誰がどのように担うかはさまざまです。

従って、まずはWhy・What・Howの違いを深く理解しておくことが必要です。エンジニア出身者だとすぐにHowが思いついてしまうため、解決策をベースにした会話をしがちですが、これは極めて慎まなければならない行為になります。

またプロダクトマネジメントには、ざっと思いつくだけでも以下のような知見が求められることが多いです。

• ・戦略とビジネス理解
• ・実行力 (ゴール、ロードマップ、プロジェクトマネジメントなど)
• ・プロダクトディスカバリー
• ・仮説検証、実験
• ・プロダクトマーケティング
• ・プロダクトグロース
• ・データ分析

これらは当然ながら普通にソフトウェアエンジニアをやっているだけでは身につかない知識なので、学習し実践しながら獲得していく必要があります。

CPOの最大の職責であるプロダクト戦略の立案とその推進ですが、この業務は学ぶことが多く、そしてプロダクトの大きな方向性を決める重要な意思決定になるため、やりがいはこの上なくあります。

自社や自らのプロダクトの強みや弱み、外部環境の変化、競合環境の分析などをベースにして、プロダクトビジョンの達成に向けて、どのような戦略を立てるべきかをトレードオフやインパクトなどを見てバランスを取りつつも、大きな成果を出すために意思決定もしっかりと行う必要があります。

経営や会社内の機能別組織、良い戦略立案のための思考法などが必要になり、深く会社経営について理解が進んでいくと思うので、エンジニアのキャリアパスとしてのCPOは学ぶべきことの宝庫であり、年々新たな学びがあるため、個人的には非常におすすめです。

簡単ですが、私がCPOになった経緯やCPOの業務について説明しました。エンジニアからのキャリアパスとしてはアドバンテージが大きく活かせる点と、新たに学ぶべきことが膨大にあるので、新しい学びを率先してやりたい人にはおすすめの職種だといえます。もちろん簡単にその役割を担える機会が転がり込んでくることは極めて稀だと思いますが、そのような機会が訪れたときに、この記事が参考になると幸いです。