なぜモダンなプロダクトチームによるリーンなプロダクト開発が必要なのか
はじめに
メルカリUK版の立ち上げを終え2018年3月に帰国しました@tsumujikazeです。今は東京でメルペイのProduct Managerをしています。
イギリスではいわゆるモダンなプロダクトチームでのLeanなプロダクト開発を経験しました。得るものが多かったので、なるべく多くの人に知ってもらいたいと思いこのポストを書きました。
PMF →リーンプロダクトのプロセス →モダンなプロダクトチーム（組織論）という流れになっています。
はじめに
本編
・何のためにプロダクトを作るのか
・プロダクトマーケットフィット
・PMFピラミッド
・要件定義フェーズのリーン化
・モダンなプロダクトチームでのリーン開発とは
おまけ
・Problem Space vs. Solution Space
・Problem Solution Fitとは
・エンジニア組織とPM組織の特性について
・バリュープロポジションとは
はじめに
Leanと言われても正直ピンとこない人もいると思いますが、考え方はシンプルで間違いなく効果があります。イギリスでシニアなPMと話すともはや常識といった感じだったので、日本の現状とは結構差がありそうです。
プロダクト開発ではいかに無駄な作業を減らして最速で進めるかは死活問題です。そういえばイギリスでは無駄な業務に関してみんなものすごく敏感で、よく議論をしてました。その辺りに僕ら日本人の生産性を上げる鍵がある気もします。
誰かの参考になれば幸いです！
（２０１８年５月５日追記）TwitterのPopular ArticleとNoteトップページのおすすめにも入りましたので記念にスクショを貼っておきます。
この記事にかかれていることに興味ある人がいればぜひTwitter等で絡んできてください！
（2018年12月10日追記）メルカリのオウンドメディアに僕の記事が出たので貼っておきました。
それでは本編スタートです！
何のためにプロダクトを作るのか
超前段から入ります。
語呂が良いからなのか、英語のブログや記事でOutput vs. Outcomeというテーマをたまに見かけます。
もちろん両方重要なんですが、どちらかと言うとOutcomeになると思います。
プロダクトを世に出すだけではなく何かしらの成果を上げるために日々我々はプロダクトを作っているのです！
成果を出すためには、プロダクトが世に出ている必要があります。その意味を込めて上図でもOutputからOutcomeに向けて矢印が伸びています。
しかし、世に出されるサービスの殆どは長期的には生き残ることができません。公開した（Outputは出した）けれど、Outcomeに繋がらないからクローズするしかないのです。
そしてOutcomeを出すためにはプロダクトマーケットフィットが必要になります。
プロダクトマーケットフィット
みんな大好きPMF。
シンプルすぎる図でアレですが、マーケットが土台にあるのが肝です。そもそも正しい場所で戦うという例のやつです。
その上にプロダクトが乗ってきて、マーケットとプロダクトが合致するとPMF達成です。
PMFというのは時間とともに変化する概念なので、一度達成すれば全て良しということはありません。タイミングもめちゃくちゃ重要です。競合環境にも大きく左右されます。
当たり前ですね。
PMFピラミッド
もう少し分解してみます。『The Lean Product Playbook』という本の中でPMFピラミッドが紹介されていますので、簡単に説明します。
※著者のDan Olsen（@danolsen）さんが作ったThe Lean Productフレームワークの一部としてthe Product-Market Fit Pyramidが紹介されています。こちらのページ内に本家の画像があります。
ターゲットカスタマー：想定している顧客。target audienceと言われることも多い。
未解決ニーズ/ウォンツ/フィアー：想定顧客が持っているであろう「満たされていない」ニーズ。「I need to ○○」で表現できるのがニーズなので、文字通り非常に強い動機です。ニーズがあれば一番良いですが、現状でぽっかり開いている誰も満たしていないニーズというのはなかなかないと思います。なので個人的にはウォンツ（nice to have、必ずしも必須ではないがあると便利な機能）でも良いと思っています。特に痒い所に手が届く系のウォンツは有望。FOMO（Fear of Missing Out）に代表するような恐れの気持ちを理解することも重要です。
以上の2つのレイヤーが「マーケット」を構成しており、マーケットリサーチやユーザーインタビュー、ペルソナ、カスタマージャーニーマップ等といった手法があります。そこは割愛。
プロダクトには3つのレイヤーがあります。
バリュープロポジション：そのプロダクトが想定顧客に提供することを約束する価値。顧客が自社サービスを使った方がよい理由。Unique Value Proposition (UVP) と言われることも多い。
フィーチャーセット：バリュープロポジションを実現させるために必要となる、プロダクトが備えているべき機能一覧。「この機能遅らせよう」、「この機能は外せない」といった決断は、このレイヤーに影響します。また、フィーチャセットに関する判断をすると、ひとつ下のバリュープロポジションや一つ上のUXにも影響が出ることを意味します。必要最低限のフィーチャーセットを持つプロダクトをMVP（Minimal Viable Product）と呼びます。
UX：ユーザーエクスペリエンス。PMFピラミッドの最上位に位置していることを理解しておいてください。
要件定義フェーズのLean化
Outcomeを出すためにはPMFが必要で、PMFするためにはUVPを満たすフィーチャーセットを持つMVPを作る必要があるということがわかりました（横文字w
それを実際にどう作るのか。
その前に、ウォーターフォールモデルとアジャイル開発モデルのおさらいです。
言うまでもなくアジャイル開発では開発プロセスが「回されて」います。スクラムかカンバンかその手法にかかわらず、なるべく早く作って、リリースして、そこから学ぶフィードバックループを回していますが、それをiterative approachと言います。事前に全てをプランニングしたり、多くの機能を一度に出すことには大きなリスクがあるので、iterativeな開発で恩恵を受けることができます。
それでは以下の図を見てください。
左が普通のagile開発、右側がlean productなagile開発です。Leanなアジャイル開発では要件定義フェーズにおいてもイタレーションを回していることがわかります。
Phaseには「デザイン」（要件定義）と「実装」の２つがあります。多くの会社がアジャイル「開発」をしていると思いますが、おそらくその殆どは実装フェーズをアジャイル化しているだけで、要件定義フェーズはアジャイル化されていないのではないでしょうか。
注釈：「アジャイル化」というのはかなり漠然とした言葉ですが、わかりやすさを優先しました。
なぜ実装フェーズのアジャイル化はこんなに浸透したのに要件定義フェーズのアジャイル化が遅れているのかはわかりませんが、よくよく考えると不思議な現象です。
実装フェーズはアジャイル化されているけど、何を作るか決めるフェーズがアジャイル化されていない不完全な状態をWaterfall + Agileの造語でWagileと呼ぶことがあります。以下wikipediaからの引用。
Wagile software development is a group of software development methodologies that result from slipping from agile back into waterfall, doing a lot of short waterfalls and thinking it is agile, Waterfall model masquerading as Agile software development, etc.
上図の左にあるWagile開発では、アイデアを形にする際のリスクがどうしても残ってしまいます。一度で正解を出すことは至難の業です。
お客様が何を求めているかというよりは、事業サイドの都合で作るものが決まってしまうケースには高リスクです。
アイデアを形にする部分をイタレーション化して、なるべく早く回すことがLeanプロダクトの思想です。これはiterative approachをソフトウェア開発に持ち込んだアジャイル思想と同じです。
モダンなプロダクトチームでのリーン開発とは
先程の図の右側に合ったLean Product + Agileの部分を拡張しました。
Leanなプロダクト開発をするのに適したチーム構成があるのですが、そういったチームのことをここでは「モダンプロダクトチーム」と呼びます。プロダクトの名著『INSPIRED』で広がった表現です。
モダンなプロダクトチームの核になるのがProduct ManagerとProduct Designerです。
日本でPMと言うとProject Managerを指すことの方が多いですし、プロデューサーというタイトルも普及しています。PMが何をする人なのかいまいち理解されていなくて悲しいのですが、モダンなプロダクトチームにおけるPMとは「何を作るのか」に対して責任を持つ人です。
何を作るかを決めるためには顧客、マーケット/競合環境、ビジネス、ステークホルダー、データに関する深い洞察が必要になります。プロダクトの成功に対する重責を担うこともあり、よくCEO of Productとも言われます。
モダンなプロダクトチームにおけるもう１つの最重要ピースがデザイナーで、この文脈では通常Product Designerと呼ばれます。少し前によく言われたハッカー、ハスラー、ヒップスターの中ではヒップスターに該当します。
PMとプロダクトデザイナーはペアを組みプロトタイプを作ります。「何を作るのか」に対して責任を持つPMがこのプロセスをリードしますが、実際のプロトタイプはデザイナーが作ります。
お客様に見せる場合はInVision等のプロトタイピングツールを使うことが多いです。プロトタイプを「実装前に」想定顧客に見せることで、貴重なエンジニアの工数を割いて実装することなく確度の高いフィードバックを得ることができます。
リスクをなるべく早い段階で潰すことがモダンなプロダクトチームの大原則です。そもそもこのバリュープロポジションで良いのか、お客様は製品の使い方がわかるのか。様々なリスクを前工程で潰します。
この様にターゲットオーディエンスの立場に立ってプロジェクトを進めることを**HCD (Human Centered Design = 人間中心デザイン) **と言い換えて良いと思います。
プロトタイプを見せるのは本当に楽しいフェーズです。初回のイタレーションであれば、多くの仮説が間違っていて、勝手なassumption（こうなっているはずという仮定）を作ってしまっていたことに気づかされるはずです。
このフェーズで間違いに気づけるのは非常に良いことで、そこで得た検証済みの気づきを"validated learning"と言います。実装することもなくリスク検証できるのです！
ユーザーインタビューではwhyの深掘りも意識します。定量データからはwhyを理解することが難しいのですが、目の前にお客様がいれば実際に質問することができます。ここでインサイトを磨きます。なぜそうするのか（why）がクリアになると、何を作るのか（what）もソリッドなります。モダンなプロダクトチームでは機能の実装ではなく顧客の問題解決を重視するので、理由を理解することが重要です。
ユーザーインタビューはPMも自分でやるべきです。インタビュイーのリクルーティングやスケジュール調整、インタビュースクリプト作成等様々なタスクも出てくるので、可能な場合は専門家のUX Researcherを配置するべきです。外注でも構いませんが、なるべく同じオフィス内で同じチームとして働けるようにしてください。多くの組織では専属のUX Researcherはいないと思いますので、その場合はPMが兼務してください。
理想を言うとフロントエンドエンジニアも欲しいところですが普通はまず難しいと思います。実際に動く実物のアプリをお客様に触ってもらうことができるからです。こういった実物に近いプロトタイプのことをHigh Fidelity、ペーパープロトタイプやワイヤーフレームのような簡易版プロトタイプのことをLow Fidelityと言います。
UX Researcherやフロントエンドエンジニアは仕方ないとしても、プロダクトデザイナーは原則的には必要です。契約社員や外注でも良いです。社内のデザイナーの30%の時間をもらうといったやり方も初期は有効です。どうしてもデザイナーが確保できない場合はPMが頑張りましょう。Low Fidelityプロトタイプであっても、やらないよりは100倍有用です。
-----
以上脱線しながら、モダンなプロダクトチームによるLeanなプロダクト開発に関して重要な点を書いてみました。誤解しないでほしいのは、ウォーターフォールやWagileが悪いということではないということです。状況によって最適解は異なります。ただ不確実性の高い現代においてはLeanな開発手法の重要度が増していることは間違いありません。モダンなプロダクトチームがあるとUXのレベルも上がり、すなわちプロダクトが成功する確率も高くなるのです！
↓まだ続きがありますが、もっと知りたい人のためのセクションなので見たい人だけ見てください。
-----
Problem Space vs. Solution Space
『The Lean Product Playbook』の著者Dan OlsenはProblem SpaceとSolution Spaceを分けることも重要と言っています。
実際に開発されるプロダクトはSolutionスペースに、それ以外はProblemスペースにマッピングされます。
この2つのスペースは異なる2つの世界です。なるべく分けて考える必要があります。良いデザイナーやPMほど課題を理解しているとよく言います。プロダクトを作るのは楽しいので、アイデアが浮かぶとどうしてもソリューションスペースに飛び込みたくなります。が、解決する意味のある重要な課題を発見することは、意義のある解決策を出す上で超重要です。Steve Jobsのような天才であれば別ですが...
Problem Solution Fitとは
PMFは良い概念なんですが欠点もあります。
１）PMFが何なのかイマイチわかりにくい。なので測定しにくい
２）PMFはプロダクトをリリース後にしか達成できない
特に２は重要です。
その点Problem-Solution Fitであれば、リーンプロセスの中でプロダクトバリデーションを行うことで割りと簡単に検証ができます。実装やリリースを待つことなく、想定する課題（Problem）を持っている顧客を集めて、プロトタイプ（ソリューション）を見せることである程度の確証を持てるのです。
本来は、このProblem-Solution Fitの検証はProduct Discoveryと呼ばれるフェーズで行うべきものとされています。アイデアはあるけれど、刺さるかどうかよくわからない。なのでまだプロダクト化のGOは出していない。そういったふわっとした状況で、そもそもこのプロダクトを作るべきなのかを判断するためにあるのがProduct Discoveryフェーズで、ここで様々な仮説を検証するのがあるべき姿であるとされています。
社長さんや偉い人の一存でアイデアを検証することなくプロダクト化することが既に決まっているプロジェクトを経験をした人はすごく多いと思います。プロダクト化決定前にプロダクトディスカバリーフェーズというフェーズがあり、そこではアイデアを拡散したり、色々な角度からソリューションをエクスプローアしたりして、problem-solution fitを含む様々なアサンプションの検証を行うということを覚えておいてください。
エンジニア組織とPM組織の特性
PMとエンジニアと言う観点で、モダンプロダクトチームをみてみます。
PMの主戦場はデザインフェーズ、エンジニアの主戦場はインプリメンテーションフェーズです。リスクを早期に潰すためにもプロジェクトの理解向上のためにも、エンジニアにも積極的に要件定義フェーズに参加してもらいたいと思ってはいますが（特にクライアントエンジニア。結局その方がお互いハッピーになる）、エンジニアチームが一番力を発揮するのは実装フェーズです。PMが定義したプロダクトをいかに実現させるか、技術的な専門知識でプロダクトを世に出すこと = Howに責任を持つのがエンジニアです。
別の言い方をするとエンジニアはソリューションスペースのプロです。マーケットやお客様の行動への理解もあるに越したことはないのですが、そこはnice to haveです。一方でPMはプロブレムスペースとソリューションスペース両方の幅広い知識が不可欠です。その辺りを◯、△、◎で表現しました。
異なる守備範囲にいるので、通常はエンジニアはエンジニアリングマネージャーにレポートします。エンジニアがプロダクトマネージャーに報告する、もしくはその逆のケースはレアなケースなはずです（少なくとも海外では。人の少ないスタートアップは別かもしれません）。
ちなみに、自分が所属するメルカリでもエンジニアリングマネージャー制を採用しています。素晴らしい！
エンジニアリングマネジャーの役割は、「組織面」でエンジニアリングを支えること。開発では、「経営はこっちに進みたいけれど、技術的には今これをやるのが重要」という矛盾したシチュエーションがよく出てきます。こういった状況において、経営層やプロダクトマネージャーのカウンターパートとなってうまく開発を進めていくのがミッションです。
PMもエンジニアもどちらも広義のプロダクトチームの一員です。お互いがプロフェッショナルとして、対等な立場で、良いソリューションを提供するためにチームとして仕事をすることが重要です。
PMとエンジニアにおけるフェーズや役割の違いを理解することで見えることもあります。
例えば、厳しいデッドラインの中で日々実装をしているエンジニアに取ってはOutputを出すことが一番の目標になります。この場合エンジニアはOutput Spaceにいることになります。一方PMはもう少し複雑です。プロダクトをデリバーすること（Output）も責任範囲ですが、結局は成果（Outcome）でパフォーマンスを測られます。その点でPMはOutcome Spaceにいることになります。Outcomeを出したいPMからすると顧客の声を反映した変更を入れたいけれど、リリースを目的にしているエンジニアはなるべく変更を入れるリスクと取りたくないetc...
もう１つの概念として先ほど紹介したProblemスペースとSolutionスペースがあります。通常エンジニアはSolutionスペースにいますが、PMは両方に生息しています。
こういった立場の違いを理解して、それでもプロダクトの向かうべき方向をぶらさずにステークホルダーを納得させる能力がPMには必要になります。プロダクトを成功させるために必要なことはなんでもすることが求められるのです！
自分も一PMとして、プロダクトの定義をしっかりとして、「あとは作ってもらって、世に出してくれればオールOK」と言い張れる様に、日々奮闘しています！
バリュープロポジションとは
最後にバリュープロポジションについて。
Unique Value Proposition（UVP）という呼ぶことも多々あります。なぜお客様はこのプロダクトを使うのかを表す一言です。
お客様のニーズ/ウォンツに対して自社だからこそ提供できる価値なので、上図の赤い部分が一番重要になります。実は自分たちでも気づいていない自社の強みもあったりするので振り返ると良さそうです。
逆もあります。自社サービスを使ってくれているお客様はどういった不満を抱えているのか。ユーザーだからこそわかるインサイトが眠っています。「お客様から（実は）期待されていること」と「自社だからこそお客様に提供できること」の交わるエリアの面積が大きければ、お客様に提供できる価値も大きくなります。
バリュープロポジションはPMFピラミッドのプロダクト側の最下層にあり、マーケット側との接点となるので、重要なコンセプトです。とは言え実際はふんわりしていることが多いのが実情ではないかと思います。そもそもUVPを完全にスキップしてしまっていたり、定義しないといけないと思いつつ後回しにしてしまっていたり...
全部を完璧にはできないので、それはそれで良いと感じてます。本来であればマーケとプロダクトを中心にしっかりと議論すべきパートです。出来る限り時間を割くのは言うまでもないのですが、プロジェクトを進めながら修正をしていく形でも大丈夫です。結局、PMF前であれば全てがふんわりしている（変更可能）とも言えるので、仮説検証を繰り返して、やりながらUVPを絞っていき、必要があればPivotすればいいんじゃないでしょうか。やらないとわからないですしね。
-----
やっと終わりました（長かった）。すぐには全て消化できないと思いますので、スキやマガジン追加して読み直してみてください。徐々に理解が深まるかと思います！
伝統的なアジャイル開発に比べると、実装開始までに必要となる期間が長くなるといったデメリットもあります。ただし、思い出してください。すぐにソリューションスペースに飛び込みたくなるけれど、その前にプロブレムスペースを十分に理解すること = イシューから始めることが成功のために必要なのです！
頑張って書いたので、有益だと思ったらシェアしてもらえると喜びます。
#PM #ProductManagement #プロダクトマネジメント #リーン #アジャイル #agile #開発 #エンジニア #デザイン #デザイナー #PMF #プロダクト #アプリ #メルカリ #メルペイ #ビジネス #イノベーション #スタートアップ #ベンチャー #新規事業 #テクノロジー