アイキャッチ

優れたソフトウェアプロダクトとは?欠かせないのは「シンプルさ」【CPO鼎談/ECDWレポート】

#働き方

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

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

日本CPO協会セッション登壇者写真

登壇者(詳しいプロフィールは記事下に)

(写真左)Sansan株式会社 執行役員 / CPO 大津 裕史さん
(写真中央)株式会社metroly CEO / CPO Ken Wakamatsuさん
(写真右)株式会社メルペイ 執行役員 / CPO 伊豫 健夫さん

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

日本CPO協会セッションスライド「どうやってCPOになったの?」
――日本ではまだCPOというポジションへの認知度や必要性への認識が低いように思います。皆さんは、どのようにしてCPOに就任されたのでしょうか?

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

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

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

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

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

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

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

――やりたいこと、どういう状態になりたいかを突き詰めていったら結果的に今の立場になった、というのは皆さんに共通する点のようですね。プロダクトマネジャーへの転向を意識し始めたのは、いつ頃でしたか?

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

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

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

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

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

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

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

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

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

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

日本CPO協会セッションスライド「エンジニアの役割は?」
――ソフトウェアプロダクト開発において、エンジニアの役割はどうあるべきだと思いますか?

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

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

――WHYとHOWの部分は、はっきりと分かれていた方がいいですか。

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

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

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

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

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

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

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

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

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

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

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

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

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

――エンジニアからプロダクトへの意見が出やすくしたり、関係性をよくしたりするためにCPOとして行っている工夫はありますか?

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

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

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

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

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

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

日本CPO協会セッションスライド「優れたソフトウェアプロダクトを作る人材とは?」」
――先ほど大津さんから「Sansanにはエンジニア出身のプロダクトマネジャーが多い」というお話もありました。エンジニアのバックグラウンドがプロダクトマネジメントと親和性が高いと思うのはどんなところでしょうか?

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

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

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

――ズバリ優れたソフトウェアプロダクトをつくるのは、どんな人材だと思いますか? エンジニア出身であることが生かせる部分は大きいというお話でしたが、将来的にプロダクトマネジャーになっていきたいと思っているエンジニアが今すべきことや、どういう素養があるといいかをお聞きしたいです。

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

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

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

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

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

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

――Kenさんに伺いたいのですが、日本の状況で求められる人材の条件と、海外とでは違いがありますか?

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

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

――改めてお聞きしますが、「良いプロダクト」とはなんでしょうか。先程は伊豫さんから「何をもって優れているとするかはプロダクトによって異なる」というお話がありましたが、逆に、すべての良いプロダクトに共通する要素を挙げるとすると?

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

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

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

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

――【質問1】プロダクトのKPI設定について、考え方や注意点などをお伺いしたいです。

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

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

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

――【質問2】「海外エンジニアは良い提案をしてくれる」というお話は、日本の課題の核心に近いように思いました。日本ではプロダクトとしての良し悪しを決めるのは要求を出す側が多く、開発からの提案が少ない気がします。

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

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

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

――【質問3】コロナやDXなど将来を見通しづらい環境下で、プロダクト計画をどう立てるべきでしょうか? 遠く先を考えすぎても絵に描いた餅ですし、近視眼的すぎても行き当りばったりになりかねないと思っています。

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

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

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

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

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

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

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

登壇者プロフィール(写真左から)

   

Sansan株式会社 執行役員 / CPO 大津 裕史さん

京都大学卒業後、株式会社ビービットに入社。デジタル領域を中心に100社以上のコンサルティングを手がける。2010年に株式会社WACULを設立し、代表取締役に就任。デジタル領域でのコンサルティング経験をもとに、人工知能の研究開発を推進し、2015年5月よりWebサイトの分析から改善提案まで行う人工知能「AIアナリスト」を提供。18年にSansan株式会社へ入社し、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に就任。

   

株式会社メルペイ 執行役員 / CPO 伊豫 健夫さん

大学卒業後、松下電器産業株式会社(現パナソニック株式会社)、株式会社野村総合研究所を経て、2006年に株式会社リクルート入社。中長期戦略策定および次世代メディア開発等、大小問わず多数のプロジェクトを牽引したのち、15年3月株式会社メルカリに参画。16年8月より執行役員。US版メルカリのプロダクトマネジメントを担当後、17年4月より国内版メルカリのプロダクト責任者を務める。2019年7月より現職

文/小林香織

Twitterをフォローしよう

この記事をシェア

RELATED関連記事

RECOMMENDEDあなたにオススメ

RANKING人気記事ランキング

JOB BOARD編集部オススメ求人特集

エンジニア転職フェア開催 IT&モノづくりエンジニアを求める優良企業が大集結!

「type転職エージェント」無料転職サポートのご案内


サイトマップ