自社開発×アジャイルだからこそ、「スケジュールを決めない」　“組織全体で分担する”プロジェクトマネジメントの考え方

登壇者の自己紹介

南里勇気氏（以下、南里）：登壇者の自己紹介を進めたいので、登壇者の方々に上がってもらいます。本日はよろしくお願いします。

野田克樹氏（以下、野田）：お願いします。

鈴木伸緒氏（以下、鈴木）：お願いします。

坪田朋氏（以下、坪田）：お願いします。

南里：司会のフードテックキャピタルCTOの南里勇気と申します。よろしくお願いします。ふだんはエンジニア・経営者としていろいろやっていますが、今回のテーマはPM×デザインで、もの作りの観点から登壇者の方々にいろいろ聞きたいと思うので、よろしくお願いします。それではdely株式会社の坪田さん、紹介をお願いします。

坪田：今回はCXOというタイトルで「クラシル」を運営するdely株式会社でクラシルの開発責任者としてサービスの方針を決めたり、意思決定しています。

僕自身はデザインを軸としていろいろな事業を作ったり、会社を作ってそれが丸ごとdelyに入ったりしているので、プロダクトマネジメント経験もありつつのデザイナーみたいな感じです。今日はそんな話をできればと思っているので、よろしくお願いします。

南里：ありがとうございます。それでは株式会社ソウゾウの鈴木さん、よろしくお願いします。

鈴木：株式会社ソウゾウで、プロダクトデザイナーをしている鈴木伸緒と申します。サービスは2021年10月にリリースしたメルカリShopsを主にやっています。どこでも誰でも簡単にネットショップを開けるサービスを、メルカリグループとして展開し始めたところです。僕自身はプロダクトももちろんやってはいますが、まだまだ立ち上げて2年目の会社なので、そのPRやBizDev、マーケなど、わりと横断的に動いている感じです。

自分自身がプロダクトマネジメントに思い切り当てはまるかどうかはちょっと怪しさもありますが、ソウゾウではいろいろな職種にそれぞれが滲んで仕事をしていたりするので、今日はデザイナーを軸にして、プロダクトマネジメントにちょっと滲み出ている話ができればいいかなと思っています。よろしくお願いします。

南里：よろしくお願いします。最後に株式会社TBSテレビの野田さん、よろしくお願いします。

野田：よろしくお願いします。野田と申します。前職はGoodpatchでUXデザイナーとPjM（Project Manager）として仕事をしていました。今はTBSテレビに入りもう少し職域が広がって、よりプロダクトマネジメント寄りの仕事を担当したり、逆にUIデザインの仕事も自分で行うなどして、インハウスのデザイナー兼PdMのように、いろいろなプロジェクトを回しています。今はまだあまり見せられる実績がないので、具体的なプロダクト名は出せない前提にはなります。

副業やUXデザイナーから徐々にPdMに染み出す部分も挑戦しているので、UXデザイナーおよびPjMキャリアからプロダクトマネジメントに徐々に染み出しているの文脈で話せればと思っています。よろしくお願いします。

セッションの3つのトピック

南里：では、さっそくメインセッションに入っていければと思います。今日は大きく3つのトピックを話したいと思っています。

（スライドを示して）トピック1ですが、みなさんの会社がどういう会社か、（どういう）事業をやっているのかというところから、その会社事業におけるPMとデザイナーの役割の違いに言及できるといいと思います。

2つ目は、デザイン的な観点で見た「いいプロダクト」とはなんだろうというのを、ディスカッションできればと思っています。

最後に、そういう人材になるために、個人としてどうアプローチしていけばいいのかに関して話していければと思っています。

各トピックでQAセッションも設けているので、（気になることは）そこで拾えればと思っています。では、さっそくセッションに入っていきたいと思います。

MIDAS TECH STUDYの背景ですが、今まではエンジニア系の勉強会をメインにやってきました。どう作るかもすごく大事ですが、今は何を作るかの重要性も以前よりも増してきています。かつ、今日登壇する方々もそうですが、デザイナー出身でPM（product management）をされる方が増えてきています。

その中で、プロダクトマネジメントとデザイナーの役割が曖昧になるというか、境界が少しわかりにくくなったりすることある状況において、デザイナーとPMというスキルセットをどう切り分けて考えるのか。もしくは、どう融合してプロダクト作りに活かしていくのかみたいなところが、この会の発端です。

PMとデザイナーの役割の違い

さっそく1つ目のテーマですが、PMとデザイナーの役割の違いです。まず今回の登壇者がどのようなことをしているかの概要を知ってもらえればと思うので、自身の会社の概要と、どういった事業をしているのかの具体的な内容。また、どういうフェーズにいるのかを説明してもらえればと思います。

その中で、どういったチームの体制・思想を持ってその体制になっているのかと、PMとデザイナーの役割をどう分担しているかみたいな話をできればと思っています。まず坪田さんから説明してもらってもいいでしょうか。

坪田：はい。デザイナーとPdMの役割みたいな感じですよね。

南里：そうですね。

坪田：最近はクラシルの開発は、Squad制を採用しています。「ここのSquadはこのKPIを追いましょう」「このSquadはこの新機能の実現を達成しましょう」となっています。特殊かもしれないですが、ソフトウェア開発チームにBizDevや企画の人は不在で、プロダクト開発に関わっている人は、エンジニア、デザイナーオンリーで課題解決から実行を回しています。

なので、Squadが達成するミッションに適した人がPdMの役割を担うので、適材適所でデザイナーがやるケースもあれば、エンジニアがやるケースもあります。

南里：なるほど。Squadの達成するべきミッションが変われば、その役割も微妙に変わるようなイメージですか。

坪田：そうですね。そのミッションを達成するのに一番適した人がPdMをやったほうがいいと思っています。たぶん、1機能に1人プロダクトマネージャーが必要だと思います。

組織をスケールさせる時はSquadのミッションを決めていくんですが、そのミッションに応じて一番適した人がやったほうがいいとなると、例えばユーザー体験の可視化とスクラップビルドが重要な場合は、デザイナーがゼロイチでプロトタイプしながらサービスを作るケースもあるかもしれません。

グロースフェーズに入って、特定のKPIを上げるためにレコメンドのシステムカイゼンが必要なら、滞在時間を増やせるアルゴリズムが作れるエンジニアがマネージしたほうがいいかもしれないし。クオーターごとにSquadの編成を組み替えている感じです。プロダクトマネージャーを役職にはあまりしていなくて、役割にしています。

南里：なるほど。みなさん質問があればどうぞ。僕がいっぱい質問してしまいそうなので。

坪田：ははは（笑）。

delyがSquadを始めた時期

南里：すみません、僕が質問していいですか。Squadは一定の大きなフェーズというか、メンバーや事業規模にならないと始めない印象があります。Squadはいつぐらいから、どれぐらいの人数体制のタイミングで始められたのですか。

坪田：2年前くらいです。チームの人数が増えてきて、エンジニアが10人超えたあたりから目的毎のチーム細分化組織が必要になってきたかなぁという感じです。事業会社は上流下流で分かれるとエンジニアやデザイナーが社内受託のようになっていると、イマイチワークしないです。

チームで話してタスクを分解し小さく開発し、分析して次のアクションを決めるサイクルを早く回していきたいので、朝会の人数には僕はけっこうこだわっています。「朝会が6人以上になったら、そのチームは分解する」という自分ルールがあります。6人以上いると、シェアだけで議論できなくなってしまうんですよ。特に今リモートで、みんなミュートを解除するのがめんどくさいから、あまりしゃべらないじゃないですか。

南里：たしかに。スタンダップなので朝かはわからないですが、朝は顔を出さない人もいますね。

坪田：そうそう。プロダクト開発も、特にアジャイル開発するなら、対話量を重要視してます。Squadの目的を決め、毎日議論して、昨日の数字を見て改善するサイクルが回りやすい体制を取っています。

南里：なるほど。

抽象的なロードマップなどはPdMなしで成し遂げられるのか？

野田：質問兼コメントしてもいいですか。

南里：はい。

坪田：はい。

野田：僕はこの質問に対して、ザックリ言うと、意思決定する役割のPdMと、実際的な具体的なものを進めていくデザイナーという分け方ができると答えようかなと思っていました。坪田さんの先ほどのご回答だと、例えば抽象的なロードマップや、いつ・何を・どのようにのようなコミットメントは、PdMなしでどのように成し遂げられているのですか。

坪田：受託開発とちょっと違うのが、厳密なスケジュールは引かないことです。怒られそうだからあまり言えませんが、細かいスケジュールやロードマップは切っていないです。

野田：なるほど。

坪田：スケジュールを守るのが目的になると、ユーザー価値創出が実現できなくなってしまう可能性がある。例えば、何かのユーザー体験を作るとして、「この機能をいつまでに作りましょう」とスケジュールを引くと、もうその時点でアジャイル開発ではなくなってしまうので。

南里：そうですよね。

坪田：そもそもスケジュールという概念はやめたほうがいいですよ。KPIに向かっていればなんでもいいんです。スケジュールを作ることに決めてしまうと、機能のリリースが目的になってしまいます。なので、その代わりにルールがあります。可能な限り小さくチケットを切って早く改善できる、リリースを心掛けています。

今どれだけ徹底されているかわかりませんが、基本的には2週間以上の開発をしてリリースするものは議論します。1週間以内に見積りが出て作ってリリースするものは、すぐに分析するというか可視化されます。その場合は機能のズレが起きないので、そういったものはチームでよしなにやって、大きめのものはみんなで議論や意思決定が必要という感じにしています。

野田：なるほど。自律性がメチャクチャ高いですね。

坪田：そもそもスケジュールを細かく引いている暇があったら、早く開発してくれって感じですね。

野田：あはははは（笑）。

坪田：だって、アジャイル開発していたら、スケジュールを引いても2週間後にたぶんズレてますよ。それよりは、要求定義をキチッと決めて、その達成目標と向き合ったほうがいいかなという考えではいます。受託開発でこんな会話をしたら理解が得られなくて怒られる可能性が高いので、事業会社だからできることだと思います。そういう感じだと思います。

期日を設けない代わりに、仮説検証をしっかり当てに行く

南里：ありがとうございます。鈴木さん、どうですか。

鈴木伸緒氏（以下、鈴木）：話を聞いていて、本当に自律性が高いというか。プロジェクトマネジメント自体は組織全体ですごく分担しているのかなと感じました。そこは、ある意味弊社と近いと思ったところはありますが、坪田さんはさすがだなと思いました。それを実際にやろうと思ってもなかなかできないというのが、率直な感想です。

坪田：俺の話をしても仕方がないけれど、今日や明日達成するチケットに対してのスケジュールは、きちんとコミットしたほうがいいですよ。でも、2ヶ月で開発する見積りのスケジュールをカチッと決めると、正確な見積りは不可能ではないですか。

南里：そうですね。要件が変わったり、要求から変わるようなことが多かったりします。今聞いていてけっこう難しいなと感じています。鈴木さんも坪田さんもそうだとは思うのですが、PMでもデザインでも、何を作るかやその仮説をどう検証するかというデータのようなものは、逆にすごくしっかり作られているのではないかという印象を受けました。

要するに、期日を設けない代わりに、仮説検証をしっかり当てにいきましょうとなるのが特徴としてあるかなと思いました。結局、スケジュールを決めないのは、作るものがわりとクリアであったり、ユーザーの課題に対しての仮説検証の軸が明確で、そこを満たせればOKという考え方（の時）だと思っています。鈴木さんのソウゾウではどのようにやっていますか。

鈴木：そうですね。ぜんぜん違うというか、ベースはたぶんすごくオーソドックスなやり方です。この1年ぐらいはPMとエンジニアとデザイナーと、基本的にはきちんと分けてやってきました。

ただ僕自身、デザイナーは初期に1人しかいませんでした。プロダクトをメインでするのは私1人だったので、どちらかというとPMをデザイナー化するというか、PMに直接UIやデザインを作ってもらうみたいなことをしないと回らないところがありました。

それこそ、坪田さんのスケジュールを決めないということでいうと、スケジュールを最初にバチッと決めて、思いっきりそれに合わせて作っていこうと思うと、自分が1人でデザイン（を担当）しているとやることが多過ぎたので、とても間に合わない感じでした。

PMができるだけ自走して、デザインからスペッキングまで全部できるようにデザイナー化するほうが最適だなと思ったので。彼らがデザインを扱いやすい状態を2021年の1年間、ずっと作っていた気がします。

なので、delyさんほど体系化されておらず、完全に進められているわけではありませんが、一応PMはみんなFigmaを使って勝手にUIを作って、ある程度要件を定義してどういうものをやりたいかというところはやれています。

スケジュールを決めない代わりに何を目標として定めるのか？

南里：わかりました。ありがとうございます。Figmaを使っているくだりも後ですごく突っ込みたいところではありますが、コメントも来ているみたいなので、QAに回りたいかなと思います。

（スライドを示して）「『スケジュールを決めない』は目から鱗でした。逆にどのようにプロダクトやチームの目標を決めているのか、具体的に知りたいです。」とありますが、これは坪田さんですかね。

坪田：フェーズによって違います。ゼロイチで機能開発する時は、「何を達成したらゴールか」を言語化することが多いかもしれないです。例えば、Aの機能を作って完結することが目的というか、手段が目標になると、「リリースしたら俺らの目標は達成したよね」と（なって）少し曖昧になってしまうので、「ユーザー価値を実現すること」を目的にした時は、機能がきちんと実現できたらそれを目標にしていて。今はクラシルを大胆に変えているので、そういう案件のほうが逆に多いです。

1から10にしていくグロースフェーズだったら、月数回訪問しているライトユーザーを3ヶ月で15パーセント上げることを目指すことを目標としていたりします。

サービス全体のKPIがあるとしたら、そのKPIを「各Squadが達成したらきっとこっちが達成する」みたいに、結合するのがたぶん僕の役割の1つです。その時に、連続的で成長的な機能を開発できるのか、非連続的成長的な機能ぶっ込むのかは、わりと経営方針も含めて判断することが多いかなと思います。

事前にスケジュールを決めないという話も、誤解を生みそうですが、細かいガントチャートは作らないけれど「10月1日にこの機能をリリースする」と外部的にアナウンスしたものは、さすがに達成します。

南里：スクラム開発においては、価値を最大化するためにスケジュールは決めない感じですよね。

坪田：そうですね。

南里：ありがとうございます。たしかに「スケジュールを決めない」が1人歩きしてしまうと変な感じになってしまうので、スクラム開発とセットというところですね。

坪田：そうですね。

（次回に続く）