エンジニアtypeは今年4月、1週間にわたってさまざまなテーマでエンジニアのキャリアを考えるオンラインイベント「ECDW」を開催。
中でもSansan、メルペイ、metrolyという注目企業の現役CPOが登壇し、「優れたソフトウェアプロダクトとは？」をテーマに鼎談したセッションは視聴者の関心度も高く、多くの質問が寄せられた。
プロダクト開発の現場で奮闘するエンジニアの悩みが投影された質問には、登壇した3人も興味津々だったが、当日は残念ながら時間切れで全ての質問に答えることができなかった。
そこで今回、3人にあらためてメールインタビューを行い、紹介し切れなかった質問に回答してもらった。ECDWのレポート本編とあわせて読むことで、CPOや理想的なプロダクト開発のあり方について考える材料にしてほしい。
※参加者からの質問コメントはすべて原文のまま掲載。
株式会社metroly CEO / CPO Ken Wakamatsuさん
カリフォルニア大学バークレー校卒業後、サンフランシスコでMacromedia社、Kodak社、Adobe社で開発に携わる。2007年にAdobe社でPdMに転職。Cisco社に転職後、11年にSalesforce社に入社。人工知能「Sales Cloud Einstein」を提供。16年にSalesforceの日本支社に出向。Salesforce Japan初のProduct Managementチームを立ち上げる。20年7月よりmetroly Inc.のCEO/CPOに就任
Sansan株式会社 執行役員 / CPO 大津 裕史さん
京都大学卒業後、株式会社ビービットに入社。デジタル領域を中心に100社以上のコンサルティングを手がける。2010年に株式会社WACULを設立し、代表取締役に就任。デジタル領域でのコンサルティング経験をもとに、人工知能の研究開発を推進し、2015年5月よりWebサイトの分析から改善提案まで行う人工知能「AIアナリスト」を提供。18年にSansan株式会社へ入社し、CPOとしてプロダクト戦略を指揮する
株式会社メルペイ 執行役員 / CPO 伊豫 健夫さん
大学卒業後、松下電器産業株式会社（現パナソニック株式会社）、株式会社野村総合研究所を経て、2006年に株式会社リクルート入社。中長期戦略策定および次世代メディア開発等、大小問わず多数のプロジェクトを牽引したのち、15年3月株式会社メルカリに参画。16年8月より執行役員。US版メルカリのプロダクトマネジメントを担当後、17年4月より国内版メルカリのプロダクト責任者を務める。2019年7月より現職
PMとCPOの役割って似てるような気がするんですけど、スキルにはどんな差があるんでしょうか
CPOとPdMは実質同じだと認識していますが、CPOだとプロダクト全体の統括になるんですかね
「Why」と「How」のどちらに責任を持つ組織なのか、が大きく違います。
プロダクトの「Why」、つまり「なぜ作るのか」に対する責任を持っているのがプロダクト組織。そして、プロダクトの「How」、つまり「どのように作っていくか」の責任を持っているのがエンジニア組織。
アメリカでは、プロダクトマネージャーは「PM」と省略することが多いのですが、多くの場合はPMは最初は一つの機能のWhyを考えて作ります。経験を積むにつれて一機能から、プロダクトの一つのエリア、そしてプロダクト全体まで考える対象が広がっていきます。複数のプロダクトを開発している場合はプロダクトがどのように連携していくかを考えます。
CPOは会社のプロダクトストラテジーの責任を持っています。経営者のビジョンを達成するためのプロダクトのストラテジーを作り、PMがそれを実現するようリードしていきます。
プロダクトの成長に合わせて役割を分担していくと考えるとイメージしやすいかも。
プロダクトが成長していくにつれて、方向性を意思決定したりプロダクトのあるべき姿を具体化したりする仕事を一人だけでこなすことは難しくなっていきます。
一人で行えるうちはCPO=PdMという認識で仕事がなされても違和感ないですが、複数人でプロダクトと向き合い始めると、一定の役割分担が必要です。
プロダクトの方向性を定めて、どんなプロダクトにするか最終的に意思決定する役割を担う人。その人が決めた方向性を受けて、具体的にプロダクトのあるべき姿を企画する人。この二つを同じ人がやり続けているとバランスが崩れやすい印象です。
そのため、複数人でプロダクトにあたれる場合は前者をCPO（CEOが兼ねるケースもある）、後者をPdMが担う形が望ましいと考えます。
会社の種類や規模によって異なるので定義にとらわれ過ぎないで。
まずは、一般論としての回答です。
【PdM】
個々の機能開発やプロダクト全体に対して責任を持つ人。ユーザーニーズを理解し、何を作るかを定め、その最終品質にまで責任を持つ。
【CPO】
経営に対してプロダクトの長として参画する人。短期・中長期の持続的な事業プランに呼応するプロダクト戦略やロードマップを描き、あらゆるプロダクト的側面からその実現にコミットする責任を持つ。
ただし、会社の種類や規模によって異なるはずなので、「一般的な定義」として覚えておきつつ、自社はどうなっているかなと考えてみるとよいでしょう。
日本にCPOが少ない理由や、これから増やしていくにあたって今足りないことはなんでしょうか
事業会社だと、CPOという役職は一般的なのでしょうか？
CPOってまだまだ珍しいと思うのですが、そもそも会社としてロールが無いことが多いと思うのですがどうやったらなれるんですか？
「プロダクトで価値提供しよう」という価値観への理解が乏しいのが原因だと考えています。
まだ規模が小さい会社の場合は、CEO=CPOとしての役割を担っていることが多いです。基本的にはプロダクトがどうあるべきかを本気で考え、方向性を決めていく役割だと思います。
日本ではそもそも手段としてプロダクトでビジネスをしよう、価値提供しよう、という価値観に対する理解が乏しいので、この重要性が軽んじられた結果、CPOなどのポジションが少ないのだと考えています。
経営陣や企業の意思決定者に対して、プロダクトの重要性を強く説いていくことが重要と考えていますし、それが私たちの仕事とも思っています。
実は呼び方が異なるだけで、CPO的なポジションが存在しているケースは多いのでは？
実は呼び方が異なるだけで、「製品担当役員」というポジションの人は、特に個人向け製品を作っている企業には少なからず存在しているケースは多いと想定しています（社長が兼務しているケースも含めて）。
中でもソフトウェア製品においては、開発サイクルが極端に短いことや、技術進化が早いことなどから専任の製品責任者がつくケースが多いと思われます。
一方で、製品戦略や製品ロードマップが経営の中核に置かれている日本企業は欧米と比べると相対的に少ない可能性はあるでしょう。特に対法人向け製品においては、日本の”御用聞き”文化が色濃く残っている企業などはその可能性も高いのでは？
最近のSaaSなどは、対法人であったとしても、UXやCSを顧客価値として掲げる方式が常識となってきているので、CPOの数は増えてきていると思われます。
企業が兼務の非効率性にぶつかったときに、そのポジションが生まれ、エンジニアリングの知見がある者が必要とされます。
ハードウェアを作っている事業会社が多い日本では、プロダクトマネージャーという役職が、ハードウェア、ソフトウェアのそれぞれにいます。TeslaやToyotaのような自動車、テレビのOS、『GoPro』のようなデバイスなど、さまざまな業界でプロダクトマネージャーは活躍していると思います。
現状、CPOがいない会社では、CEOやCTOがCPOのロールを兼務。プロダクトを作っている企業でプロダクトマネージャーがいない場合は、社長や役員、またはエンジニアかデザイナーが兼務していることが多いでしょう。
そして、兼務するよりも独立したポジションを持った方が生産性や効率、または売上が上がると感じた会社が、プロダクトの部署を立ち上げているのです。
プロダクトマネージャーは、エンジニアリングとデザインをビジネスの角度からリードしていく必要があります。それ故に、プロダクトマネージャーはエンジニアのキャリアを経験したことがある場合が多いのです。私たち三人も皆その経緯でプロダクトの責任者になっていますね。
製品開発はハード・ソフトがあり、プロダクトマネージャーは両方を統括する認識です。しかしながら、最近はソフトウェアファーストとしてソフトありきの開発が日本でも始まったと思います。この点について注意点を教えてほしいです。
コントロールできない部分は必ずあるが、そのリスクがあっても多くの企業がソフトウェアファーストで成功しています。
2006年にAWS、その翌年にはiPhoneがリリースされ、ソフトウェアファーストの可能性を大きく広げました。
AWSがリリースされる前は、サービスを立ち上げるための初期費用の中にサーバーのハードウェアが固定費がありました。プロダクトのアイデアがあっても資金がないと作れない「壁」をAWSが取り除いたことによってFacebook、Netflix、LinkedInのような会社が生まれました。
iPhoneもSDK（ソフトウェア開発キット）を提供することにより、大量の時間とお金が掛かるハードウェアの開発を考えなくても、アプリやゲームの開発を始められるようになりました。このようにしてTikTok、Instagram、Pokemon Goが生まれました。
資金と時間のリスク面が最小限で抑えられる「ソフトウェアファースト」の注意点は、ハードウェアを委託しているのでコントロールができないことです。「サイトにアクセスできません」とエラーを表示しているサイトをときどき見ますが、AWS自体に原因がある場合もあります。この場合はAWSが異常を直すまで待つことしかできません。
また、iPhoneは毎年ハードウェアとiOSをiOSを更新していますが、こうしたSDKの変更、新規ハードウェアの対応、そして古いハードウェアのサポート終了には対応し続ける必要があります。
注意点はいくつか挙げましたが、これらのリスクがあっても多くの会社はソフトウェアファーストで成功しているということをお伝えしたいですね。
本質は「プロダクトのコストをどれだけ下げていけるか」。ソフトかハードかはその手段の違いであることを忘れずに。
「ソフトかハードか」という考え方は手段の違いでしかなく、基本的にプロダクトというもののコストをどれだけ下げていけるか、というのがこれから求められる向き合い方だと思います。
多くの場合、ハードでの提供の方が総合的に見て顧客側のコストも提供側のコストも高くなる。だから、最近の流れがソフトウェアファーストなのだと理解しています。
一方で、状況によってはコストと向き合った結果、ハードウェアを選ぶケースもあると思います。本質はコストとの向き合いによる手段の検討だと思うので、そこがぶれていないことが大事なのかなと感じますね。
シンプルに両者の違いをきちんと理解することです。
ソフトウェア、ハードウェア双方の開発特性が大きく異なることを理解すること。
特に時間軸やリリース後の保守の可否など。ひいては顧客満足向上に対するアプローチが異なってくる点に注意が必要です。
日本における”優れたソフトウェアプロダクト”を作るにはQ・C・Dどれを磨けばよいと思われますか？
エンジニアに期待する要素という意味では、「Delivery」強めで。
ソフトウェアにおいてQCDと言われると、プロダクトの話というよりエンジニアリング側の話をしているように感じます。プロダクトについて「Why」に向き合うのがプロダクト側、「How」に向き合うのがエンジニア側なので、QCDがバランスとして議論されるのはHOWと向き合うエンジニアの議論ですかね。
その前提で言えば、エンジニアに期待する要素という意味ではやはりDeliveryが特別強めではあります。
一方で、エンジニアがQualityやCostを意識しやすく準備してあげることは、プロダクト側に期待したいことですかね。
最近は「Delivery＞Quality＞Cost」な印象です。
作るモノにもよりますが、最近は「Delivery＞Quality＞Cost」で考えるケースが多くなってきている印象です。
アジャイルに品質を高めていけるよう、優先度高くチーム設計することが大事かなと考えていますね。
同じ三角で例えると、ソフトウェアプロダクトマネージメントでは、「プロダクトトライアングル」があります。
QCD（Quality、Cost、Delivery）は製造業などで多く使われているプロセス改善法だと思います。生産するプロダクトの品質、費用、そして納期を改善することによって売上、利益、顧客の満足度を上げることができます。
同じ三角で例えるとソフトウェアプロダクトマネージメントでは、プロダクトトライアングルがあります。
テクノロジー（開発チーム）、ユーザー、そしてビジネス（自社）の三つを意識しています。「テクノロジー」は、コードを書くエンジニアの能力、キャパシティーだけではなくテクノロジーのトレンドも指します。「ユーザー」は、製品を利用または購入するお客さまのことを指します。そして「ビジネス」は、自社のストラテジーやビジョン、そして売上増を指します。この３つのバランスを意識しながらプロダクトを作っています。
日本CPO協会では7月9日（金）に初の主催イベント『PRODUCT LEADERS 2021』を開催する。本記事で触れたテーマを含め、あらゆる角度から日本のプロダクト開発にとっての学びを得られること間違いなし。『エンジニアtype』はメディアスポンサーとして後日レポートを公開予定だ。お楽しみに！
企画・編集／根本愛美（編集部）
NEW!
NEW!
タグ
