PM×デザインの両視点から考える「いいプロダクト」の定義　事業フェーズで異なる“活きるスキルセット”

PM×デザインから見たリーンキャンバス最強説

南里勇気氏（以下、南里）：では次のトピックに入りたいと思います。2つ目のトピックですが、デザイン的観点から考える「いいプロダクト」です。前段では組織や事業に焦点を当てたので、もう少しプロダクトの部分をディスカッションできればと思っています。

そもそも「いいプロダクト」とは何ぞやというところは、かなり突っ込みがあるのではないかなと思います。「いいプロダクト」の定義は何かと、そのデザイン的な要素はなんだろうというところです。野田さん、どうですか。

野田克樹氏（以下、野田）：これはすごく抽象的で、メチャクチャ難しい問いです。僕が立場上クライアントワークを中心にやってきて、TBSも今後も新しいことを数多くやっていく系の会社で、立ち上げの仕事がけっこう多い（ので、その）文脈で話します。

PM×デザインの両方の知識が役立ったということに少し近いですが、なんだかんだ、1周、100周回ってリーンキャンバスというフレームワークはメチャクチャいいのではないかと思っています。すごく簡単にいうと、9マス、顧客課題、解決策や競合優位性を埋めていくものです。

「どの顧客をターゲットにするか」といったSTP（Segmentation、Targeting、Positioning）や、「その人たちの業務がどうなっているのか」いわゆる業務フローをきちんと洗い出したり、その会社のビジョンにきちんと沿った優位性やコンセプトになっているかとか、競合との差分がきちんとあるかみたいなところをしっかり理解しようと思うと、なんだかんだ結局リーンキャンバスのようなフレームワークに落ち着くなと思っています。

その抽象的なものとかけあわせて、いいプロダクトの定義としてはリーンキャンバス的な1本の筋が通っている、つまり一貫したコンセプトがきちんと立案できている状態とします。

「どのマーケットで何を作るか」というコンセプトが僕はすごく大事だと思っています。その後のところを作り続けて、経済性がきちんと担保されて、サステナブルな状態になるところまで担保できることもあります。全プロジェクトであらゆる線がきちんと通っているかは、僕の今の立場ではある程度最初にきちんと整理するところです。逆に1、10、100のあたりでどう定義を変えていくかは、お二人に聞きたいと思っています。

南里：なるほど。いやぁ、すごくおもしろいですね。ゼロイチでプロダクトを作る際は、まさにPM×デザイン的なところかなと思いました。そもそもステークホルダーが多い中で同じ絵を目指すために、どう表現してどう振り返っていくかというところで。野田さんの中では、やはりリーンキャンバスがすごく活用できていいのではないかという話ですよね。

野田：はい。なんだかんだ最強説を唱えています。お二人はどちらかというと、デジタルプロダクト専門でやってきた会社があると思います。僕は若干キャリアが違っていて、大企業と一緒に仕事をしてきたことも多かったし、（さらに）今は1周回って大企業に入っているみたいな感じだと、さすがにスケジュールを決めないのは許されません。

一同：（笑）。

野田：会議に十何人いるのが当たり前な世界なので、プロダクトマネジメントやデザインを進めていくうえで合意形成の効率化は逆にすごく大事です。投資家がすごく細かくたくさん入っているスタートアップや、経営陣・役員が8人ぐらいいる会社の新規事業になると、意外とそのスキルが活きてくるようなところがあります。そういった、ちょっとお二人とは違う話をしようかなと思って話していました。

デザインで未来を可視化し、現実との差を埋める

南里：すごくおもしろいです。この話を受けて、鈴木さんはどうですか。

鈴木伸緒氏（以下、鈴木）：野田さんが言ったように、大きめの組織だと、たとえインハウスだったとしても、活かせるスキルセットがわりとクライアントワークのほうに近いのかなと思っていたのですが、そんな感じですか。

野田：まさにおっしゃるとおりです。わかりやすくいうと、大きい会社は社内受託のようなデザイナーの人たちが多いですが、逆にいうとそれは課題かとも個人的には思っています。デザイン部署が、デザインではなくプロダクトマネジメントに染み出す仕事をするためにどう持っていくかを、僕は今はすごく考えて仕事をしています。

鈴木：なるほど、そうですね。僕がいる環境だと、まだ代表や役員陣と直接話せる機会が普通にある状態で、スタートアップだと合意形成よりは「持って行ったほうが早い」みたいなことが多いかなと思っています。

僕は今は投資家を見て仕事していたりするわけでは特段ないので、そのあたりはちょっと違います。インハウス、いわゆる事業会社だと、そこまでステップを踏まなければいけないものはないものの、逆にいろいろな絵をみんなが頭の中で描いているので。僕はデザイナーなのでそこは作っちゃったほうが早いとは毎回思っています。

一応、ソウゾウでは取り組みとして、半年先、1年先とか3年先ぐらいを常にビジュアルとして作りつつ、そこからブレイクダウンして作っていっているような進め方をしています。

南里：ロードマップ自体をデザインで可視化してわかりやすく伝えるみたいな？

鈴木：そうですね。会社の事業的なロードマップはありますが、どちらかというと僕らがサービスとして提供したい体験軸で、どういうことをマイルストーンというか、状態を目標としているのかというところから、現状との差分を細かく埋めていくかを、デザインを作って埋めていっている感じです。

南里：なるほど。僕はエンジニアなので、言葉でワーッと埋めたりわりとしやすいのですが、それよりはもうちょっとグラフィックスでみんなに理解してもらうほうが重要かなというイメージですかね。

鈴木：そうですね。僕らも当然言葉で会議など、お互いのディスカッションをやりますが、結局ゴール、見ている方向が違ったりすると、永久に噛み合わないんですよね。

特にリモートになってしまったので、お互いの温度感のようなものも、オンラインでは伝わりにくい部分が当然あります。まずは作って、同じものを「こうじゃない」「ああじゃない」と叩いてもらうようにしています。そうしないと、みんなが違う言語で話してしまうことがあります。

プロジェクトで意識する「確実性の高さ」

南里：なるほど。まさにPM×デザインの知識・経験が役に立った実例だなと感じました。このあたり坪田さんはどうですか。「いいプロダクト」の定義やPM×デザインの知識・経験みたいなところの軸でいうと。

坪田朋氏（以下、坪田）：そうですね。「いいプロダクト」の定義は、先ほども話に出ていたけど決めるのは難しいと思います。僕はプロマネ（プロジェクトマネージャー）上、デザイン上も含めて意識するのは、やはり確実性の高さです。「これを実現したい」という時に、その確実性が高いか低いか立ち振舞もマイルストン設計も柔軟に調整します。

明らかにゼロイチで作ればわかりやすい成果が出るプロジェクトで、例えば「クライアントが推しているものはこれです」わかりやすい価値がある時は、スケジュールを引いて早く作り切る方法をとります。

逆に、toCプロダクトやCGMプロジェクトで不確実性が高くソフトウェアだけで価値が作れないモノはスケジュールより価値を優先します。例えばコミュニティ作りが必要だったり、コンテンツを集めなければいけないモノは、デザインとコンテンツ両輪で育てる必要があるので価値を言語化して定義して推進します。

例えば今、TikTokとまったく同じUIや、Instagramとまったく同じUA（User Agent）を完璧に仕上げたソフトウェアでも、ユーザーの熱量とコンテンツが集まりません。不確実性が高いプロジェクトはそこの掛け合わせをしていかなければいけないので、そういう切り分けをします。

南里：なるほど。

坪田：僕個人的には不確実性が高いサービス作りが好きです。その時に僕はどちらかというとEarly Stageの立ち上げをやることが多いので、メチャクチャ早くユーザー価値の評価ができるプロトタイプやデザインを作れることを強みにしています。

極論、ノーコードで「とりあえずこれで検証できます」という提案とデザインが両方できるので、それを活かしています。

南里：なるほど。いや、すごくおもしろいですね。この後、「ものを作る時にエンジニアが必要かどうか」「技術を理解する必要があるかどうか」みたいな話に入ろうと思っていたのですが、坪田さんの今の意見でいうと、プロダクトの特性によってユーザー価値検証ができればいいという話ですよね。

坪田：そうですね。極論、別に「Repro」、「Firebace」とか、「KARTE」みたいなツール使って検証することもぜんぜんあります。

南里：（それで）判断できれば。

坪田：サーバーサイドのAPIを使わなくてもローカルで検証できることもあるし、その早く評価できる推進ハンドリング力がプロダクトマネジメントに活かしています。

南里：実際にクラシルのプロダクトだと、技術を理解する必要はどれぐらいあるんですか。

坪田：技術を理解する必要はそんなにないと思います。今みたいな話をエンジニアと話せる人間力というか、思考が大事な気がします。

南里：なるほど。

坪田：例えば、「検証する時にUIを作ってサーバーサイドの実装もし、クライアントのさわり心地もカッチリやりましょう」など全部完璧な状態じゃないと検証できない考えはMVP開発やアジャイル開発思考とズレていると思います。

「そのデザインがめっちゃいい」よりかは、可能な限りチケットサイズを小さくして早く検証しようとメンバーには伝えているので、その思考がある人の方がフィットするかなという感じです。

コメントしやすい土台を作ってディスカッションする

南里：なるほど、ありがとうございます。このあたりのエンジニアとの技術理解やコミュニケーションは、ソウゾウはどうですか、鈴木さん。

鈴木：そうですね。坪田さんはいわゆるPMやデザインを両方行ったり来たりしている人なので、僕からすると、PMとしての使える手段がメチャクチャ多いなという感じです。

僕は1年先をきちっと描けているかというと、描けているわけではありません。どう言えばいいのかわからないのですが、例えば、「とりあえずこういうものなんじゃない？」と言うと、「いや、そうじゃない」という意見がすごく出やすくなるんですね。なので、反対意見は反対意見とか、「なんかちょっと微妙に違うんだよな」みたいなことをすごく意思表明しやすくなるというのは感じています。

一般的に、エンジニアもビジュアルにはすごくコメントしやすいじゃないですか。

南里：まあ、たしかに。

鈴木：だから、真っ先にコメントしやすいものをただ作っているという感じです。例えば「ここが緑色だったら、ここは赤いほうがいいよね」と一般的には気軽に言うじゃないですか。それをプロダクトの作るプロセスとしても普通に言えるほうがいいかなというのがあります。それは、コロナの状況になってからすごく意識し始めたところです。

僕はもともとUSやUKのプロダクトチームとリモートでやっていたので、フィードバックをもらう手段は、この4年ぐらいずっとすごく模索していました。エンジニアも「結局どういうものを作るのか」がわかったほうが、彼らの中で取り得る最善の手段を明らかに選択しやすくなると思っています。

先ほど坪田さんが話していた、「いろいろな手段で『絶対にこの手段じゃなきゃだめ』というわけではない」みたいな話と近寄ってくるのですが、エンジニアに対して細切れに「こういうものを作りたい」というよりかは、イメージの共有をして、「僕らで勝手に選ばないほうがいいよね」というのは、すごく意識しているところです。

南里：ありがとうございます。「何を作るか」みたいなことは伝えるけれど、「どう作るか」みたいなことはあまり言わずに、その技術や方法の可能性はエンジニア側に任せるようなイメージですかね。

鈴木：任せるというか、トップダウンで決めるよりは一緒にディスカッションをしてPros、Consを挙げて決めていくほうが、確実に強いものにはなるのではないかと思っています。

南里：その方法を出すために、ディスカッションできる土台を渡すみたいなイメージですかね。

鈴木：そうですね。

デザインバックグラウンドを持たないPdMが押さえておくべきポイント

南里：なるほど。ありがとうございます。質問が増えているので、ピックしていきたいと思います。

（スライドを示して）「みなさんと対照的に、デザインバックグラウンドを持たないPdMがデザイナーと協働するうえで、押さえておくべきポイントはありますか」。これは野田さん、どうですか。

野田：サクサクッといきますね。僕はデザイナーのマネジメントをしていたことがあるのですが、元も子もないですが、デザイナーのタイプによるというところは前提となる答えとしてあります。

基本的に、「これ作ってね」「はい、作りました」という関係性だと、僕はデザイナーは絶対にパフォームしないと思っています。

すごくアホくさい答えかもしれないですが、ちょっとバカっぽく「ちょっとこれに悩んでいて、ここをこう解決したいんだけど、どうしたらいいかなぁ」みたいな感じで、余白を残すコミュニケーションを、僕は状況によっては取ります。カジュアルな答えですが。

南里：なるほど。ありがとうございます。いやあ、すごくおもしろいです。

野田：WHYは絶対に伝えるのと、変にワイヤーフレームを作り過ぎないとか。そのあたりの余白をひたすら残したうえで、デザイナーのクリエイティビティを最大限に引き出すように、情報をあえて制限することは気をつけるとは思います。優秀なデザイナーさんの時は、特にそんな関わり方が多いです。

南里：なるほどね。野田さんにばかり質問が来ているのでアレなんですけど、2個目も。先ほどの受託開発が多いみたいな話の中でのことだと思いますが、「ステークホルダーの多い合意形成において、いつも気をつけている点」についてはどうですか。

野田：これはクライアントワークあるあるの質問ですね。最近僕は立場が変わって、これまではお客さんという立場、今は事業オーナー側に回ってしまったので、その2点の違いがあります。

先ほどの坪田さんのスケジュールを決めない話と逆行する話で申し訳ないのですが、お客さんとしてのコミュニケーションを取りにいく時だと、お客さんが自分が持っていきたかった結論に持っていった感を出すことは、手口がバレるので次から使えなくなる話ですが（笑）。すごく気にしています。

自分が論点をきちんと整理して、正しい議論をしていくと、最初の数分でサッと考えた結論に近いところにいく可能性が高い。ただ、それを最初に「こうだよね」と言うよりは、きちんと順序立てて議論することで、最後の結論の納得度がぜんぜん違うことは往々にしてあると思っています。

南里：なるほど。

野田：だから僕はリーンキャンバスが好きなんです。あえて時間をかけて合意形成をすること、きちんと「前提はこうだよね」というところをすごく丁寧にやることは気をつけています。

南里：なるほど。前提となる条件であったりプロセスも含めてしっかり共有するところと、あとは感情に寄り添ってあげるみたいなところがけっこう重要ということですよね。

野田：そうですね。

機能の実装優先度を判断するうえでの判断基準と合意形成の進め方

南里：ありがとうございます。最後に1つ。4つ集まっている質問が、野田さん宛てとなっているのですが、内容的には他の方にも答えていただきたいなと思っています。

「クライアントワークにおいて、機能の実装優先度を判断するうえでの『判断基準』と『合意形成の進め方』について教えていただきたいです。無限に出てくる要望を受け入れ過ぎると、機能モリモリで『いいプロダクト』からかけ離れたものになりがちな一方で、優先度を判断できず、甘んじて受け入れてしまいがちです。」ということです。これはすごくおもしろいテーマだと思うのですが、坪田さんはどうですか。

坪田：そうですね。僕はもう3年ぐらいクライアントワークをやっていないので、クライアントワークという意味だと、やはり先ほど野田さんが言っていたように、いかにお客さんに理解してもらうかです。

あとは人間は突然モリモリな機能や提案を持って来られても、受け入れられない何かの感情があるんですよ。だから、何度か意思決定までのステップで巻き込んであげて、合意形成を丁寧にするのは重要だと思います。

そのうえで、先ほどのスケジュールの話や優先順位もそうですが、スケジュールは可能な限り早いほうがいいし、タスクは無限に湧いてきます。

これに優先順位をつけてコミットメントするのがPM能力の1つですが、優先度の高いタスク実現の意志をまず持って、その機能をまずweek1で作り、他の機能はweek1の結果が出てから作るステップを踏むのが、今の事業会社のやり方です。

ただ、クライアントワークだと小さいリリース単位で切れずにまとまった分量で開発するのでそういったことができない点は難しいですよね。クライアントワークは機能を絞ればスケジュールが短くなるから、人月単価が下がり売上も下がる謎の試練もあったりするじゃないですか。

南里：そうそう。受託開発会社からすると謎の。

坪田：そうなんですよ。予算目的でいうと、普通に1年モリモリで機能かけて作ったほうが売上は上がるんですよね。それと、アジャイル開発はやや相性がよくないので。であれば、作るべき機能を定めて期待品質までデザインを仕上げるスキルが必要だと思います。

ゼロイチのアイデア検証で必要なクオリティ

南里：なるほど、ありがとうございます。もう1つだけピックしましょう。これは鈴木さんにあたるかな。「ゼロイチでアイデア検証する時に、どの程度のクオリティのものを作りますか」と。鈴木さん、いかがでしょうか。たぶんこの質問の意図は、「伝わるのはどれぐらいのレベル感で、どう作ればいいのか」みたいなイメージだと思うんですけれど。

鈴木：そうですね。ゼロイチのアイデア検証は、紙でもいいと思います。どちらかというと、パッと作ってパッと検証できる早さはメチャクチャ大事だと思うので、紙に四角とかを描いてそれで検証できるのであれば、作り込む必要はぜんぜんないと思っています。

これは自分自身がユーザーなのかどうかにもよると思いますが、自分がそのツールやサービスを使う対象者ではないとしたら、できるだけ伝わるギリギリのローファイ、低いクオリティのもので試して、それで早くフィードバックをもらうほうが次に進めると思うので、作り込む必要はないと思います。

南里：デジタルツールを使わなくても、紙と手で描いていけるのならいけという話ですね。ありがとうございます。

（次回に続く）