なぜモダンなプロダクトチームによるリーンなプロダクト開発が必要なのか

はじめに

2016年からロンドンで行ってきたメルカリUK版の立ち上げを終え、今年3月に帰国しました@tsumujikazeです。今は東京でメルペイの立ち上げプロジェクトでProduct Managerをしています。

イギリスではいわゆるモダンなプロダクトチームでのLeanなプロダクト開発を経験しました。得るものが多かったので、なるべく多くの人に知ってもらいたいと思いこのポストを書きました。

PMF →リーンプロダクトのプロセス →モダンなプロダクトチーム(組織論)という流れになっています。

はじめに
本編
・何のためにプロダクトを作るのか
・プロダクトマーケットフィット
・PMFピラミッド
・要件定義フェーズのリーン化
・モダンなプロダクトチームでのリーン開発とは
おまけ
・Problem Space vs. Solution Space
・Problem Solution Fitとは
・エンジニア組織とPM組織の特性について
・バリュープロポジションとは


はじめに

Leanと言われても正直ピンとこない人もいると思いますが、考え方はシンプルです。すぐにこのやり方に完全移行することはできないかもしれませんがリーンなプロダクト開発には間違いなく効果があります。イギリスでシニアなPMと話すと、「まだそんなやり方してるんだね..」という反応で、もはや常識といった感じでした。

多くのメンバーが力を合わせて開発するプロダクト。いかに無駄な作業を減らして最速で進むのかは死活問題です。そういえばイギリスでは無駄な業務に関してみんなものすごく敏感でした。その辺りに僕ら日本人の生産性を上げる鍵がある気もします。

スタートアップ界隈でよく出てくる重要なコンセプトの復習にもなると思います。知っている人からすると当たり前のことばかりですが、ご容赦ください。誰かの参考になれば幸いです!

(2018年5月5日追記)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)に代表するような恐れの気持ちを理解することも重要です。※本家のthe Product-Market Fit Pyramidでは"Underserved Needs"とあります。Wantsやfearの部分は筆者の意見として追加したもので本家の内容とは異なります。

以上の2つのレイヤーが「マーケット」を構成しており、マーケットリサーチやユーザーインタビュー、ペルソナ、カスタマージャーニーマップ等といった手法があります。そこは割愛。

プロダクトには3つのレイヤーがあります。

バリュープロポジション:そのプロダクトが想定顧客に提供することを約束する価値。顧客が自社サービスを使った方がよい理由。Unique Value Proposition (UVP) と言われることも多い。

フィーチャーセット:バリュープロポジションを実現させるために必要となる、プロダクトが備えているべき機能一覧。「この機能遅らせよう」、「この機能は外せない」といった決断は、このレイヤーに影響します。また、フィーチャセットに関する判断をすると、ひとつ下のバリュープロポジションや一つ上のUXにも影響が出ることを意味します。MVP(Minimal Viable Product)の考え方に従って、UVPを満たす必要最低限のフィーチャーセットを作るのが教科書的な流れ。

UX:ユーザーエクスペリエンス。一種のバズワードと化しているUXですが、PMFピラミッドの最上位に位置していることを理解しておくと良い気がします。UXの中にも幾つものレイヤーがあるのですがそれはまた別途...


要件定義フェーズのLean化

Outcomeを出すためにはPMFが必要で、PMFするためにはUVPを満たすフィーチャーセットを持つMVPを作る必要があるということがわかりました笑

それを実際にどう作るのか。

その前に、ウォーターフォールモデルとアジャイル開発モデルのおさらいです。

言うまでもなくアジャイル開発では開発プロセスが「回されて」います。スクラムかカンバンかその手法にかかわらず、なるべく早く作って、リリースして、そこから学ぶフィードバックループを回していますが、それをiterative approachと言います。事前に全てをプランニングしたり、多くの機能を一度に出すことには大きなリスクがあるので、iterativeな開発で恩恵を受けることができます。

それでは以下の図を見てください。

左がいわゆる普通のagile開発、右側がlean productなagile開発です。Leanなアジャイル開発では要件定義フェーズにおいてもイタレーションを回していることがわかります。

Phaseには「デザイン」(要件定義)と「実装」の2つがあります。多くの会社がアジャイル「開発」をしていると思いますが、おそらくその殆どは実装フェーズをアジャイル化しているだけで、要件定義フェーズはアジャイル化されていないのではないでしょうか。

注釈:自分で使っておきながら何ですが、「アジャイル化」というのはかなり漠然とした言葉ですが、ここではわかりやすさを優先しました。そもそもアジャイル開発とはAgileソフトウェア開発宣言に書かれている価値観に則った開発スタイルのことで、ある特定の開発手法を指す訳ではありません。そのため色んな人が違う意味でアジャイルと言っていて混乱するわけですが...

なぜ実装フェーズのアジャイル化はこんなに浸透したのに、要件定義フェーズのアジャイル化が遅れているのかはわかりませんが、よくよく考えると不思議な現象です。

実装フェーズだけ見ればアジャイル化されていますが、プロダクト開発全体を見ると前半はそうではない。そういった不完全なagileのことを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開発では、アイデアを形にする際のリスクがどうしても残ってしまいます。一度で正解を出すことは至難の業です。

「事業責任者に画面見せてok貰った」(多くの場合この判断軸は個人の経験から来る勘。それもいいのですが!)とか「他社がこういったUIになっているからこの遷移にしよう」とか「開発工数の関係でこうするしかないよね」などなど。科学的な手法というよりは職人的な勘、お客様が何を求めているかというよりは事業サイドの都合で作るものが決まってしまうことが多いのです。

アイデアを形にする部分をイタレーション化して、なるべく早く回すことがLeanプロダクトの思想です。これはiterative approachをソフトウェア開発に持ち込んだアジャイル思想と同じです。


モダンなプロダクトチームでのリーン開発とは

やっと本題です。先程の図の右側に合ったLean Product + Agileの部分を拡張しました。

Leanなプロダクト開発をするのに適したチーム構成があるのですが、そういったチームのことをここでは「モダンプロダクトチーム」と呼びます。プロダクトの名著『INSPIRED』にて広がった表現だと認識しています。

モダンなプロダクトチームの核になるのがProduct ManagerとProduct Designerです。

日本でPMと言うとProject Managerを指すことの方が多いですし、プロデューサーというタイトルも普及しています。PMが何をする人なのかいまいち理解されていなくて悲しいのですが、モダンなプロダクトチームにおけるPMとは「何を作るのか」に対して責任を持つ人です。日々の開発を回す役目(Scrumで言うところのProduct Ownerロール)も兼務することが多いので混乱しやすいのですが、PMの責任範囲は要件定義フェーズにあります。何を作るかを決めるためには顧客、マーケット/競合環境、ビジネス、ステークホルダー、データに関する深い洞察が必要になります。プロダクトの成功に対する重責を担うこともあり、よくCEO of Productとも言われます。

モダンなプロダクトチームにおけるもう1つの最重要ピースがデザイナーで、この文脈では通常Product Designerと呼ばれます。少し前によく言われたハッカー、ハスラー、ヒップスターの中ではヒップスターに該当します。

PMとプロダクトデザイナーはペアを組みプロトタイプを作ります。「何を作るのか」に対して責任を持つPMがこのプロセスをリードしますが、実際のプロトタイプはデザイナーが作ります。

お客様に見せる場合はInVision等のプロトタイピングツールを使うことが多いです。プロトタイプを「実装前に」想定顧客に見せることで、貴重なエンジニアの工数を割いて実装することなく確度の高いフィードバックを得ることができます

リスクをなるべく早い段階で潰すことがモダンなプロダクトチームの大原則です。そもそもこのバリュープロポジションで良いのか、お客様は製品の使い方がわかるか、エンジニアはこのプロダクトを作れるのか。様々なリスクを前工程で潰す

この様にターゲットオーディエンスの立場に立ってプロジェクトを進めることをHCD (Human Centered Design = 人間中心デザイン) とかDesign Thinkingとも言います

プロトタイプを見せるのは本当に楽しいフェーズです。初回のイタレーションであれば、多くの仮説が間違っていて、勝手なassumption(こうなっているはずという仮定)を作ってしまっていたことに数多く気づかされるはずです。

このフェーズで間違いに気づけるのは非常に良いことで、そこで得た検証済みの気づきを"validated learning"と言います。「こういうタイプのお客様はプロダクトをこう使うはず」といった作る側の思いには、実は多くのassumptionが含まれています。そういったリスクを実装もリリースもすることもなく検証できるのです!

ユーザーインタビューではwhyの深掘りも意識します。定量データからはwhyを理解することが難しいのですが、目の前にお客様がいれば実際に質問することができます。ここでインサイトを磨きます。なぜそうするのか(why)がクリアになると、何を作るのか(what)もソリッドなります。モダンなプロダクトチームでは機能の実装ではなく顧客の問題解決を重視するので、理由を理解することが重要です。

ユーザーインタビューはPMも自分でやるべきですが、多くのテクニックが必要となります。またインタビュイーのリクルーティングやスケジュール調整、インタビュースクリプト作成等様々なタスクも出てくるので、可能な場合は専門家のUX Researcherを配置するべきです。外注でも構いませんが、なるべく同じオフィス内で同じチームとして働けるようにしてください。多くの組織では専属のUX Researcherはいないと思いますので、その場合はPMが兼務してください。

更に理想を言うと、UX Researcherに加えてフロントエンドエンジニアも欲しいです。実際に動く実物のアプリをお客様に触ってもらうことができるからです。こういった実物に近いプロトタイプのことをHigh Fidelity、ペーパープロトタイプやワイヤーフレームのような簡易版プロトタイプのことをLow Fidelityと言いますが、やはりHigh Fidelityな方がリアリティのある結果を得ることができます。

UX Researcherやフロントエンドエンジニアは仕方ないとしても、プロダクトデザイナーは原則的にはメンバーに加えてください。社内で人が足りなければ、契約社員や外注でも良いです。社内のデザイナーの30%の時間をもらうといったやり方も初期は有効です。プロトタイプを作りユーザーインタビューを行い、課題を抽出/整理して、最適なソリューションを考えようとすると、これはフルタイムジョブになります。どうしてもデザイナーが確保できない場合はPMが頑張るしかありませんが、さすがにtoo muchかもしれません。Low Fidelityプロトタイプであっても、やらないよりは100倍有用です。

-----

以上脱線しながら、モダンなプロダクトチームによるLeanなプロダクト開発に関して重要な点を書いてみました。誤解しないでほしいのは、ウォーターフォールやWagileが悪いということではないということです。マーケットやプロダクト、抱えるチームメンバーのスキル等によって最適解は異なります。ただし、ものすごくスピードが早い = 不確実性の高い現代にはLeanな開発手法の重要度が増していることは間違いありません。モダンなプロダクトチームがあるとUXのレベルも自然と上がり、すなわちプロダクトが成功する確率も高くなるのです!

GW休みの勢い(&初Notesということで)張り切ってまだ続きがあります。↓もっと知りたい人のためのセクションなので、見たい人だけ見てください。

-----


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は良い概念なんですが欠点もあります。

1)PMFが何なのかイマイチわかりにくい。なので測定しにくい

2)PMFはプロダクトをリリース後にしか達成できない

特に2は重要です。

その点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... 

もう1つの概念として先ほど紹介したProblemスペースとSolutionスペースがあります。通常エンジニアはSolutionスペースにいますが、PMは両方に生息しています。

こういった立場の違いを理解して、それでもプロダクトの向かうべき方向をぶらさずにステークホルダーを納得させる能力がPMには必要になります。プロダクトを成功させるために必要なことはなんでもすることが求められるのです!

自分も一PMとして、プロダクトの定義をしっかりとして、「あとは作ってもらって、世に出してくれればオールOK」と言い張れる様に、日々奮闘しています!


バリュープロポジションとは

最後にバリュープロポジションについて。

僕もイギリスに行く前は知らなかったのですが、この言葉には割りと頻繁に出くわしました。Unique Value Proposition(UVP)という呼ぶことも多々あります。なぜお客様はこのプロダクトを使うのかを表す一言です。

お客様のニーズ/ウォンツに対して自社だからこそ提供できる価値なので、上図の赤い部分が一番重要になります。実は自分たちでも気づいていない自社の強みもあったりするので振り返ると良さそうです。

逆もあります。自社サービスを使ってくれているお客様はどういった不満を抱えているのか。ユーザーだからこそわかるインサイトが眠っています。「お客様から(実は)期待されていること」と「自社だからこそお客様に提供できること」の交わるエリアの面積が大きければ、お客様に提供できる価値も大きくなります。

バリュープロポジションはPMFピラミッドのプロダクト側の最下層にあり、マーケット側との接点となるので、重要なコンセプトです。とは言え実際はふんわりしていることが多いのが実情ではないかと思います。そもそもUVPを完全にスキップしてしまっていたり、定義しないといけないと思いつつ後回しにしてしまっていたり...

全部を完璧にはできないので、それはそれで良いと感じてます。本来であればマーケとプロダクトを中心にしっかりと議論すべきパートです。出来る限り時間を割くのは言うまでもないのですが、プロジェクトを進めながら修正をしていく形でも大丈夫です。結局、PMF前であれば全てがふんわりしている(変更可能)とも言えるので、仮説検証を繰り返して、やりながらUVPを絞っていき、必要があればPivotすればいいんじゃないでしょうか。やらないとわからないですしね。


-----

やっと終わりました(長かった)。いかがでしたでしょうか?すぐには全て消化できないと思いますので、スキやマガジン追加して読み直してみてください。徐々に理解が深まるかと思います!

伝統的なアジャイル開発に比べると、実装開始までに必要となる期間が長くなるといったデメリットもあります。ただし、思い出してください。すぐにソリューションスペースに飛び込みたくなるけれど、その前にプロブレムスペースを十分に理解すること = イシューから始めることが成功のために必要ですよ!

頑張って書いたので、有益だと思ったらシェアしてもらえると喜びます。

それではみなさんhave a great GW!

#PM #ProductManagement #プロダクトマネジメント #リーン #アジャイル #agile #開発 #エンジニア #デザイン #デザイナー #PMF #プロダクト #アプリ #メルカリ #メルペイ #ビジネス #イノベーション #スタートアップ #ベンチャー #新規事業 #テクノロジー

この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

スキ、ありがとうございます!
552

#マーケティング 記事まとめ

#マーケティングのタグがついた記事を中心に、マーケティングに関する理論や実践についての記事をまとめていきます。
41つのマガジンに含まれています

コメント2件

むっちゃわかりやすかったです!あざっす!
日本メーカーが世界市場に拡大していた頃に似ていると感じました。
社会状況や社内状況が変わっても続ける/革新していくためには?という問いが頭をよぎりました。
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。