『エンジニアtype』では、４月13日～４月15日にかけて『ENGINEERキャリアデザインウイーク』（ECDW）と題した５日連続のイベントを実施。さまざまなテーマで全12のセッションを行った。

本記事では、2021年１月に設立された日本CPO協会から、エンジニアリングのバックグラウンドを持つ現役CPO（Chief Product Officer）３名が登壇した「日本CPO協会トークセッション　優れたソフトウェアプロダクトとは？」の内容を一部抜粋してお届けする。

CPOになった理由は？就任するまでの道のりは？

Ken：私はエンジニアからキャリアをスタートし、約７年間は開発チームに在籍していたのですが、日々マネジャーらと「なぜこのプロダクトを作るのか」「なぜこの機能が必要なのか」といった会話を重ねる中で、次第にプロダクトの方針やストラテジーを決める仕事に就きたいと思うようになり、プロダクトマネジャーに転向しました。

その後、しばらくはアメリカの大きな会社に勤めていましたが、最終的に自分が作りたいものを作れる環境を求めて、独立してmetrolyのCPOになる道を選びました。

大津：私はもともとデジタル領域のコンサルティング会社にいました。当時はどちらかというとディレクションが仕事でしたが、自分自身で作りたい気持ちが強くなったところから独立し、自分で受注して納品してということをやっていく中で、エンジニアリングやデザインを学びました。

自分のプロダクトとして『AIアナリスト』という製品を開発する一方で、他社のプロダクトのお手伝いもしていたのですが、その後、当時のクライアントの１社だったSansanに縁あって入社し、現在に至ります。

基本的には、ソフトウェアプロダクトと向き合い続ける中で、もっともっと自分の寛容度を高めたいという意識でやっていった結果、CPOのポジションに落ち着いたという感じです。

伊豫：私はSIer出身なのですが、しばらく続けていくうちにシステムの開発だけでなく、もっと根っこの企画のところからやりたい思いが強くなっていきました。であれば、事業会社で自社プロダクトをやっていくのがいいだろうということで転職し、そのタイミングでプロダクトマネジャーに転向しました。

そこからはプロダクトマネジャーひと筋で、メルカリに入った時もそう。当時はまだ全社でも社員80人ほどの規模で、エンジニアとデザイナーとQAからなる小さなチームを持っていました。その後もチームを率いてプロダクト開発にコミットすることを繰り返していくうちに、自然と全体を統括する立場になり、メルペイに移った今も、CPOを務めています。

伊豫：私はこれまで４社に勤めていて、転向したのは２社目の終わりなので、キャリアの前半ですね。

大津：Kenさんは最初から考えていた、という感じではないんですよね？

Ken：最初の５年はエンジニアで頑張っていこうと思っていたので。４年目くらいからキャリアチェンジしたいなと思い始め、転職をしたのですが、転職した先でも結局配属されたのは開発チーム。「やっぱり違う。自分がやりたいのはストラテジーを決めることだ」と思い、でも新しい会社でイチからネットワークづくりをするよりはということで、古巣に戻ることにしました。

プロダクトマネジメントをするにはチーム、特にエンジニアとのリレーションが大切なので、ネットワークづくりのしやすさは重要なポイントでした。当時のアメリカはまだ、今と比べてプロダクトマネジャーになる道がすごく少なかった時期でもありました。

大津：でも、今の日本がまさにその状態に近いですよね。「どういうきっかけがあればプロダクトマネジャーになれるんだろう？」とおっしゃっている人は多いです。私自身も正直、「プロダクトマネジャーやってます」みたいな時期があったわけではないので。経営者をやっていて、そこからプロダクト責任者に転向したというレアケース。海外だと、小さい会社をやっていて買収され、プロダクト責任者になるケースは結構多いですが。

Ken：そうですね。あとは、開発方法がウオーターフォールからアジャイルに移行していったことで、各アジャイルチームにはプロダクトマネジャーをつけることが多いから、アメリカではそうした流れで自然と増えていった気もします。

大津：ただ、日本においても、CPOというロールはなくても、「このプロダクト責任者って誰だっけ？」ということが言われやすくなってはいると思うんですよね。

伊豫：製品開発の責任者は多かれ少なかれ、どの企業にもいらっしゃると思うんですけど、要はそれのことですよね。

大津：そうそう。会社の規模が大きくなると、それを会社全体で統括することに意味が出てくる。そうした流れでCPOみたいな言い方をし始めるのであって、やっていることは大きく変わらない気がします。

ソフトウェアプロダクト開発でのエンジニアの役割

大津：これは私の感覚ですが、国内の企業だと「ソフトウェアプロダクトの開発」と言った時に、プロダクト側と開発側の境が曖昧で、開発側がなんとなくプロダクトも検討していますよというチームや組織が多い気がします。

プロダクト開発におけるエンジニアの役割は、プロダクトなり機能なりをどう作るかというHOWの部分。「なぜ作るのか」「どうあるべきか」というWHYの部分に向き合うのはプロダクト側であり、そこがしっかりと役割分担されていた方がいいと個人的には思うのです。

大津：「まったく口を出すな」というくらいに壁がある必要はないですが、ぼんやりとやっていると「ここはこういう仕様でやってくれ」とプロダクト側がエンジニア側に押し付けてしまったり、逆にエンジニア側が「これ、本当に作る意味あるの？」とプロダクト側を疑ってしまったりして、関係が崩れ始めてしまう。

意見を言い合う関係性ではあるけれども、役割をはっきりさせて、お互いにリスペクトがあると連携しやすいかと思うのですが、その辺り、Kenさんはどうですか？

Ken：私も役割がきれいに分かれていた方がスムーズにいくと思っています。９年勤めたセールスフォースでも、すごくはっきり分かれていました。

プロダクト側が設定したWHYをチームとして形にし、リリースするのが最終的なゴールだと思うのですが、そのWHYをHOWに落とし込む時のユーザーストーリーの設計、タスク割、コードを書いて改善する一連の作業こそがエンジニアの最も中心的な役割。そこは、プロダクト側としては完全にお任せしたいと考えています。

私自身は実際のコードから離れてもう長いですから、彼らが常に最新のテクノロジーに触れていて、最も生産性のいい方法を提案してくれることを信じて仕事をしています。

伊豫：私も同じ理解です。役割というか、突き詰めると関係性が大事だなと。お互いが補完関係になっているはずなのに、実際にはそうではない状態がよくありますよね。

海外のエンジニアと日本のエンジニアの考え方の違い

大津：メルカリさんにはグローバル人材が多いと思うのですが、国内と海外のエンジニアで、役割に対する考え方や身の振り方に違いはありますか？

伊豫：当然のことながら最終的には人によるのですが、海外の方の方がジョブディスクリプションへの意識が強いというか、日本人とは解釈が少し違う気がします。海外エンジニアの方がやや「広め」。KPIや企画、アウトカムとして何を得て、何を得なかったのかといったことに対する追求が強い印象があります。

Ken：確かに、難しい質問やいい質問、プロダクトへの提案をたくさんしてくれるのが、海外のエンジニアの特徴かなと思います。「こういう新しいテクノロジーがあるけど使ってみませんか？」とか、「こうしている理由はなぜですか？ もしこうであれば、別の解決策もあるのでは？」と提案してくれる場合もある。大きな方向性として「もっとプロダクトをこういう風にしたいんだ！」と強い気持ちを伝えてくれるエンジニアもたくさんいます。

伊豫：表現方法が違う印象ですよね。決して日本人開発メンバーがプロダクトに向き合っていないと言いたいわけではなくて。

大津：実際、エンジニアから「プロダクトのここはどうなんだ？」と聞いてもらうことで、目線がすり合って行けば行くほど、われわれとしてもやりやすいです。伝わった気になって任せているだけだと、蓋を開けたら全然ずれていたみたいなことも起きると思うので。

エンジニアとプロダクトの関係性をつくる

大津：Sansanでは、何を解決しようとしているのかというところの顧客の声やフロントメンバーからの声、あるいはプロダクトマネジャーが企画している内容がすべてオープンに見られる場所を設けています。もちろんプロジェクトにアサインされて初めてキャッチアップするという人も中にはいるとは思いますが、どんな課題があって開発が始まったかというストーリーがSlack上でのやりとりなどさまざまな方法で見えているため、エンジニアたちも自分ごとにしやすい環境にあります。

また、プロダクトマネジャーのほとんどがエンジニア出身なので、“見知った仲”のエンジニアとは、関係性が強い印象があります。

伊豫：メルペイではフラットに議論のテーブルを作ることを意識していますね。制約条件や目標などしがらみの強みプロダクトマネジャーは、ともすると事業目線が強くなりすぎてしまう。一方、エンジニアには職種特性としてそこにフラットに疑問を抱く人が多いので、彼らと議論を交わすことで、結局のところお客さんは何が欲しいのか？という原点に回帰できるところがあります。

Ken：コミュニケーションが重要ですよね。特にアメリカだと転職による出入りが多いし、いろんな国の人もいる。セールスフォース時代によくやっていたのは、月に１回、会社持ちでチームでランチに行くことです。そこでできるだけコミュニケーションをして、自分の意見を言いやすい関係づくりをしていました。

それ以外にも、リリースした後にスクラムチーム10～15人でセグウェイに乗りに行ったり、自転車でゴールデンゲートブリッジを渡ったり。そういうイベントを通じてより良い関係を作り、次のプロジェクトに挑むということをよくやっていました。

優れたソフトウェアプロダクトを作る人材とは？

Ken：スクラムとか、アジャイルとかで開発をする際に、何が可能なのか、何が難しいのか、何に時間がかかるのかといったことが分かるという意味では、エンジニアはプロダクトマネジャーに適していると思います。

でも、必ずしもエンジニア出身である必要はなく、プロダクトや会社にもよりますね。BtoBであればビジネス面が強くなり、顧客理解がより重要になってくる。その場合は元SE、元コンサル、元デザイナーの方が向いているケースも結構あります。

伊豫：当然プロダクトによるのですが、今はどんなプロダクトでも１回作って終わりではなく、まずスピーディに作り、お客さんの反応をみてどんどん良くしていくといったやり方がどんどん広がっている。そういった今の事業環境においては、エンジニアリングのバックグラウンドは有効に働きやすいかなと。必ずしもエンジニアを経験していないといけないわけではないですが、ものづくりに精通していることがいろんな意味で有効だとは思います。

大津：ソフトウェアプロダクトはほとんどの場合、何かしらの問題に対するソリューションとして存在しています。そう考えると、あれもこれもと無駄にたくさんの機能を作りたがる人は、あまり向いていないと思います。

エンジニア出身者をいいなと思うのは、「それ、本当に必要？」と立ち止まって、無駄に作ろうとしないところ。エンジニアは「それを解決するのであれば、これだけできればできちゃうじゃん」という、シンプルな解決策を見つけ出すところに美徳を感じる方が多いので、その点がすごく良いと思っています。

伊豫：何をもって優れているとするかはプロダクトによって異なるでしょうが、弊社（メルペイ）のようにBtoCだと、「多数派は何か」ということを感覚としてちゃんと捉えられるかどうか。それが重要だし、一番難しいところだと思います。その上で、それをシンプルな表現で実現できることももちろん大切です。

Ken：エンジニアの視点で難しいと思うのが、常に新しい解決策が求められるゆえ、過去に書いたコードを捨てなければいけない場面が頻繁に訪れること。特にSaaSの世界ではその傾向が強く、自分の作ったものが３カ月とか半年で使われなくなってしまうこともある。

それはプロダクト側の責任でもあるわけですが、市場は変わっていくものなので、そういったことを受け止めて、どんどん新しいものにチャレンジする姿勢が必要だと感じます。

大津：その通りですよね。そういう意味でも、スマートに作っていると、作る労力がかかっていないぶん、壊す時の抵抗感もない。大きな市場変化によってピボットが必要になっても、機転が利きやすく、スピードも出る。結局、「無駄に作りすぎない」のが大事なのかなと、Kenさんのお話を聞いて改めて思いました。

Ken：基本的には同じだと思います。共通して求められるのは、市場に対して、どのタイミングでどういうプロダクトを作ればいいのかを考えられること。違うところがあるとすれば、めんどくさいことや自動化できることをアプリケーションとしてどんどん開発する、その余地がどれくらい残されているかではないでしょうか。日本にはまだまだやれることがたくさんあります。すごくチャンスがあり、プロダクトづくりの国として面白いと思います。

結局、優れたソフトウェアプロダクトを作る人材とは、ひとことで言えば「Lazy」な人。めんどくさいと思ったら自分でプログラムを書いて自動化できてしまう人が、優れたプロダクトを作るのではないでしょうか。

大津：やはりシンプルでありながら、対応できる状況の面積が広いもの。限られた状況でのみ機能するのではなく、シンプルなんだけど一般的な状況に機能するのがいいプロダクトだと思いますね。

伊豫：僕もそうだな。シンプルで簡単で、一個のプロダクトで複数の問題を解決できるのが一番良いと思う。

Ken：ここは私も一緒です。ゴールに対して一番簡単に、なんの説明書も読まずに解決できるものが良い。ITが得意でない人でも使えるようなシンプルさがベストだと思います。

「プロダクトのKPI設定は？」「計画はどう立てるべき？」参加者からの質問への回答

大津：分散を防ぐ意味でも、もっとも重要な視点を一つに絞るといいと思いますね。プロダクト開発と同様にシンプルに設定して、その数字だけをパワフルに追い求めるのが大事な気がします。

伊豫：メルカリではOKR（Objectives and Key Results）という目標設定ツールがあって、一点突破というかシンプルにもっとも大事なことを指標にします。KPIツリーのような構造を理解したうえで、優先順位を決めるのがCPOの仕事だと思っています。

Ken：SalesforceではKPIが複数に分かれていました。企業側の視点ではプロダクトが売れているか、新しいマーケットに参入できているか、開発チームの視点では目標としていた機能をどれぐらい作れたか、開発チームメンバーが離脱していないか、加えて機能ごとの使用率や解約率、ユーザーからのフィードバック等も評価項目に含まれていました。

Ken：文化の違いもあると思いますが、日本人の方は訓練が必要かもしれないなと。私の場合はチームメンバーと一緒にランチしながら、ラフに質問をする機会をつくっていますね。

大津：開発に提供されている情報の範囲が狭いことが一番の課題のように思います。何を解決するプロダクトなのか、その情報を共有しないと提案のしようがないですし。

伊豫：特性として日本のエンジニアは職人気質というか、自分の役割へのコミットが強いですよね。そこに居心地のよさを感じる人が多いのかなと。弊社では組織の中に日本人と外国人の両方が在籍することにより、いいとこどりの状態になっているので、積極的にチームにダイバーシティを取り入れていくと良さそうですね。

伊豫：メルカリの場合はビジョンがすごく強いカルチャーで、ロードマップが整ってきたのは最近ですが、３〜５年の計画がありますね。今回のコロナ禍では何を変えるべきか活発に議論されていて、結論が出たら一気にスピードを持って動くような体制です。

大津：弊社はBtoBなので、プロダクト計画は四半期ごとに区切っていて、次かその次ぐらいの分まで決まっていますね。

Ken：『metroly』は交通費を自動化するプロダクトという特性上、仕様を大きく変えました。来月には新製品が出る予定です。Salesforceでは２期先ぐらいまで計画しつつ、全社的な方向性は変えずに各部署ごとにコロナ対応製品を作るなどしていました。

動画アーカイブ※近日公開予定

タイムオーバーで全ての質問に答えることはできなかったが、登壇者からは「すごくおもしろい質問ばかりなので、イベント等で見解を示せたらと思います」という感想も。

編集部でも引き続き、CPOのキャリアに迫る企画をお届けしたいと考えているので、ぜひ楽しみにしていてほしい。

動画でアーカイブを見ることができます。セッションの全貌はぜひ動画をご覧ください。※近日公開予定

登壇者プロフィール（写真左から）

文／小林香織