プロダクト開発における「Core/Why/What/How」に沿って考え、振り返って得た学び

現在、PLAN-Bでは新しいプロダクト開発を進めています。SEARCH WRITEやCast Me!ら既存プロダクトも成長過程ですが、「プロダクト」を中心とした事業をさらに進めるため昨年より次のプロダクトの準備を進めてきました。
サービス開始の予定がある程度見えてきたという段階ですので、この機会に新しいプロダクト開発にて体験したこと・学んだことをPM(プロダクトマネージャー)目線で振り返っていきたいと思います。
その中で、実際に用いたフレームワークや考え方の手法を整理しながら、得た学び・失敗などを新規プロダクトの企画・開発のフローに沿ってご紹介していきます。

Core/Why/What/How を可視化するためにリーンキャンバスで整理

私たちが次のプロダクトとして検討したのは、デジタルマーケティングにおける「集客」→「接客」→「追客」というフェーズの「接客」におけるプロダクト展開でした。 背景はいろいろありますが、自社が抱える顧客層（特にSEARCH WRITE）が次に抱える課題を解決できるプロダクト展開がよいのではないか、「接客」領域におけるマーケティング施策の実施にて自社メディアである「PINTO！」において成果が出てきており「接客」領域の中でのノウハウを自社内にて構築できていたため、この領域を次のプロダクトとして企画していきました。

新プロダクトの企画に関しては、社内では経営層はもちろん、事業側（マーケ・セールス・サクセス）といった開発チーム以外のメンバーや実際の開発チームメンバーと長期的に議論を重ねることになります。
関係者も多いため、議論が発散して終わらないように、社内では何個かのフレームワークを用いて、市場課題の定義と顧客となるユーザー・プロダクト像を整理していくことでおおよその草案をまとめていきました。

まず初めにですが、プロダクト作りの前提としてプロダクトを市場に提供するまでに、４つの階層で全体を俯瞰的に捉えるところから整理をすすめます。
プロダクトを「Core→Why→What→How」という4つの階層でとらえ、各階層間での仮説検証において「学び」を行なっていくことで、失敗のリスクを少しでも減らしていく必要があります。

振り返ってみて思うことは、この「Core/Why/What/How 」の４つの階層で全体像を俯瞰しながら進めると良いのですが、もう少し視野を広げるために、別の視点で「リーンキャンバス」を用いて整理する方法がよいというところが、すごく腑に落ちました。

このリーンキャンバスが良いなと思う点としては、中心に「Core＝独自の提供価値」を置きながら、プロダクト⇄マーケットの対比を用いながら整理できるところにあると思います。

ここが整理できていない状態で開発をスタートしてしまうと、市場やユーザーに受け入れられない、無駄な開発をおこなってしまう可能性が高く、プロダクトアウトでのギャンブルを迫られることになります。
結果、開発投資が無駄となってしまう場合もありますし、失敗での学びはあるかもしれないですが、ただでさえ成立させることが難しい新規ビジネスの失敗リスクを自分たちであげてしまっていることに繋がりかねないのです。

では、最終的にここに落とし込むことを念頭におきながら、個別の部分をどう埋めていくかが「プロダクトを企画する」ことになりますので、「Core→Why→What」もフレームワークで整理していきます。

「Why」の整理に役立つバリュープロポジションキャンバス

では、「リーンキャンバス」の中身の１つ1つを様々なフレームワークを用いながら整理を進めます。
今回の企画では「バリュープロポジションキャンバス」というフレームワークを用いて整理を進めました。

この他にも「なぜ自社がおこなうべきか」を検討する必要もあります。
外部環境分析（PEST・ファイブフォース）や強み・弱み（SWOT→クロスSWOT）といったフレームワークも抑えておくと市場・競合という外部環境と自社環境を分析するとより解像度は上がってくるはずです。

 プロダクトを企画する際や他の企業や上司からプロダクト開発を指示された場合などでも、こうやって書き出して整理することで、多くの関係者と認識の齟齬なく進めることにつながってきます。

今回の新しいプロダクト開発では、この部分までの整理を進めた結果、すでに世の中に浸透しているサービスの価値を再認識できたというところでした。
展開するサービス領域（今回でいうと「ウェブ接客領域」）が後発のサービスの場合は、すでに世の中に価値として提供されている「機能」としては再開発・再検証する必要はなく、同じ機能を模倣して作ることは最低の条件になってきます。ですので、自社がプロダクトを作る際の機能価値を全て仮説検証する必要性は低い場合が多くなるはずです。
必要なのは「自社がやる理由＝プロダクトの提供価値がある」の部分が最も重要です。
（※後発で革新的なイノベーションを生み出したい場合は全く別だと思います）

ですので、まずはある程度同等の「機能」を開発し、競合優位性やPLAN-Bとしての提供価値の意味は開発をしながら考え・検証することでまずは動き出そうと踏み切りました。
開発着手に踏み込んだ経緯はそれ以外にもさまざまな背景がありますが、 リーンキャンバスにおける「独自の価値提供」の部分は、しっかりと関係者でも認識を合わせておく必要を感じました。

プロダクトの基礎となる考え方は、「誰のどのような課題を解決するためのプロダクトなのか？」です。

Founder/Customer Fit
プロダクトの「Core」
▼
Customer/Problem Fit
プロダクトの「Why」
▼
Problem/Solution Fit
プロダクトの「What」
▼
Solution/Product Fit
プロダクトの「How」

この一連の流れをつなげること。そして「なぜ自社が解消でき、ビジネスとして成立できるのか」をリーンキャンバスに整理できるところまで議論できているか、振り返り・疑うことができているかが、とても大事であると学びました。

まったく新しいイノベーション的なサービスを展開するときはもちろんですが、多くのサービスはすでに世の中に星の数ほど存在します。新しいプロダクトでのサービス提供を進めるためには、様々なサービスを利用した結果に生まれるさらなる「課題」を見つけ出していくことが「独自の価値提供」につながるはずです。
この半年間での開発を振り返って感じることは、4つの階層において整理ができていない・検討しきれていないと、どこかふわふわした内容で走ってしまい、途中から芯がブレた目先の開発になりがちということです。

では、次にその経験も振り返りながら、どのように「WhatとHow」つまり企画から開発に落とし込んでいったのかも、少しご紹介していきます。

「What」で行うユーザー体験設計と「How」までの重要さ

新しいプロダクト開発も「What」のフェーズに入ってくると、ユーザー体験の設計やビジネス設計に取り掛かりました。
実際のプロダクト開発の現場では、この「What」から場合によっては着手し始める人も多いかもしれません。ですが、この「What」を考え出すと結局はこの前の工程となる「Why」は必要になってきますので、実際は「Why⇄What」を何度も繰り返しているはずです。
実際にPLAN-Bでの工程においても、

• カスタマージャーニー / 認知から利用・目的達成までのユーザー体験し各シーンにおける感情を整理する
• ビジネスモデルキャンバス / どれぐらいのコストでどんな価値が創出され収益をあげるのかを整理する
• ロードマップ / プロダクト開発に関わる全ての人に現在からの短期・長期の見通しを示す

を順番に設計していきながら、「Why⇄What」を繰り返し、徐々にプロダクトが形づくられていきました。

特にユーザー体験の設計がなければ、「Why」で定義したユーザー課題に対して、どのような解決策があるかをユーザーに提供・提案ができないため、しっかりと設計できていることが望ましいと思います。
またユーザー体験を設計することで、次の工程である「How」をより早く設計できることにもなります。 この設計を行うことで、ユーザーの理解が深まることもプロダクト開発では重要ですよね。

この辺りのお話は、PLAN-Bでは、優秀なUXデザイナーがおりますので、また別の機会に記事にて紹介してまいります。

では、いよいよ「How」の部分ですね。
この部分からいよいよ「UIデザインを作る」「開発する」ところが具体的になってきます。 つまり「どのように実現するのか」という話です。しかし、ここまでの工程が長い、、本当に長いですね。。

いきなり「どのように実現するのか」を考え出すことは結構やりがちですし、特にエンジニアやデザイナーといった「モノ」を作れる人がいる会社なら、まずここが行われていなければ「進捗が出てない」と感じられることが多いのではないでしょうか。
開発を行う工程がもっとも長くなる場合が多いため、早くに着手しなければいけないという焦りや不安からそうなりますよね。

実際にPLAN-Bでも、今回の新しいプロダクト開発において、必要だと思う部分・これは必ずいるであろう機能という「How」からスタートした部分はあります。

そして、いざこのフェーズが始まると、そちらにばかりに目が向いてしまうため、プロダクトマネージャーとしては、常に全体俯瞰をしながらの視野の広さをもちながら「How」の部分に重きを置かない・実際に手を動かす部分は最小限にとどめていくなど、「Why/What」に集中できる体制を目指す方が結果的には望ましいと思いました。
プロダクトマネージャーが「How」を開発チームと共に行なっていると、作ることに集中してしまって、やはり目が曇ってくるのです。

「Core→Why→What」と流れてはいきますが、実際にはこの間を何度も思考をめぐらせる感覚が必要になり、行ったり来たりを繰り返し、より自分の中での解像度をあげて、迷いをなくしていく。
常に疑うことをどれだけ行なっても足りないぐらいにプロダクトマネージャーは「Core→Why→What」に重心をおいて、自分が担保すべき責任と思いながらプロダクトを企画していくのが理想ですね。

PLAN-Bでも「Core→Why→What」の考え方が定着するまでには3年〜4年はかかっていると思います。
そして、まだまだ「経験」が足りない部分が多いため、もちろんできていないことも多いです。
頭ではわかっていたりするが「経験」が圧倒的に足りないため、再現性が低いのです。

さらに「How」の部分においても「MVP」で開発するということを、PLAN-Bの開発体制においては定着しだしているのですが、このMVP開発が共通認識でインストールできているかというところでは、まだまだ個々の解釈が微妙に生まれていたりします。

例えば、、MVP開発に関する解釈のずれとして、
１：「小さく作ることでレビューを繰り返し確認しつつ、実際に動くものを見て確認することで、そうじゃなかったんだけどを少なくすることだ！」

２：「要件・要求がふわっとした新規ビジネスを開発するさいに作り込みを行いすぎず、小さく作り込み仕様変更・不具合修正などの手戻りを起こさないようにしよう！」

３：「開発にかける費用・工数を最小限に抑えながら一気にサービスを作り込まずに小さく市場での検証をすすめる開発しようぜ！」

と、大きくは外れないのですが、各自の関わり方の立場や目線・役割が違うため、解釈はまちまちになります。このMVPの考え方を合わせることがプロダクト開発では本当に大事だと感じました。

では、次からは、もう少し深く「How」をどのように新規プロダクトにおいて進めていったのかをご紹介していきます。

「How」ではリーンスタートアップをベースとしたMVP開発がPLAN-Bでは定着

PLAN-Bでは、いきなり全てを作り切るわけではなくMVP開発の考え方を取り入れて開発を進めています。 アジャイル開発ですね。 MVPを決める方法として「ユーザーストリーマッピング」を用いることが主流です。

ユーザーのメインアクション（横軸）があり、その一つのメインアクションを、ユーザーの細かいアクションとして細分化していき（縦軸）＝開発の単位ぐらいに積み上げていき、優先度をつけて開発していくことで、作りすぎないということを行う形です。PLAN-Bでは要求を「エピック」という単位に区切っていき徐々に「プロダクトバックログ」に落とし込んでいきます。

実際にビジネスシーンにおいてのプロダクト機能への要求の大枠が出来上がった段階で、更なる機能設計がどんどん進んでいきます。プロダクトマネージャーとして企画していく作業の中でも想像力が膨らみ面白い瞬間でもあるため、ユーザーのためにより多くの機能を提供したいと考えてしまいがちです。
ですが、本当にユーザーが価値として感じるかもわからないので、小さく作ることがMVP開発です。積み上がった開発要求であるエピックを見て、MVPのラインを決定していきます。このMVPのラインを整えずに、作ることに集中しだすといつの間にか作り込みをかけすぎていたなんてことも場合によっては出てくるかと思います。

ユーザーストーリーマッピングにおいて、どこまでの開発が作りすぎで、どこまでの開発を行うことをMVP開発と定義するところを可視化することで開発チームとの意識をすり合わせを行い、ようやく開発体制の準備がととのってきます。

余談ですが、 カスタマージャーニーマップとユーザーストーリマッピングはよく混同されがちですが、全く目的が違うため混在しないように注意しましょう。

今回の新規プロダクト開発において「顧客価値の提供」を意識せずに「機能要求」が優先的に進んだことにより開発を動かすことに集中していったことで、MVPとしての作り込みすぎの基準がないままスタートしてしまいました。
その結果としては、なんとなくこれは作りすぎ、これは必要ということを開発仕様として振り分けていくことになっていたところも大きな反省点です。
合わせて、プロダクト開発におけるコアメンバーだけでもこの「MVP」の考え方のインストールと認識あわせは最低限ですべきだったというところもあります。

では、そのMVP開発における手法をご紹介すると、BMLループ（Build→Measure→Learn）の考えに基づき、以下のサイクルで検討します。

1. 「仮説」/ アイディアに対するニーズの仮説を立てる
2. 「プロダクトMVP構築」/ ニーズを満たすアイディアの実用最小限機能(MVP)を、コストや時間を極力かけずに開発する
3. 「計測」/ ユーザーに当てて反応をみる「計測」を行う
4. 「LEARN」/ 反応の結果から、製品や次の仮説に反映させる「学習」

世の中にまったく新しい価値を提供するという場合は、「仮説→MVP構築→計測→学習」を進めるのがお作法です。 丁寧に何を学習するかを定義しながらMVPという手法で小さく作っていくことが、MVP開発の本質です。

今回の新規プロダクト開発では、何度もお伝えしていますが、まさにこの「学習」の定義が曖昧なまま、世の中にある既存サービスでの機能提供の最低水準に追いつくところを開発優先としながら、３ヶ月ほどは開発を進めていました。

並行した開発を進める中で見出した「価値ある差別化」の部分

開発が３ヶ月ほど進んだ段階で、徐々に機能要求がまとまり、より具体的に何を作るかが見えてきました。
そのタイミングでアイディアを一度、すべて洗い出しながら、顧客・売り方・今後の方向性などを話し合い、「価値ある差別化」の部分を洗い出しました。

これまでに紹介したフレームワークを用いながら、ユーザーが抱える課題・価格・機能などを想定し、全員が納得できるような「価値提供」の企画を行うことができました。

このPLAN-Bの新しいサービスはもうすぐお披露目となりますが「ウェブ接客領域における施策を実行ができ結果を分析しさらに実行するというPDCAサイクルを回せること」を目指したサービスです。
デジタルマーケティング領域におけるウェブ接客の施策にて差別化していくための具体的なアイディアなども話し合いました。

では、この生まれたアイディアをどのように検証をすすめるのか。
PLAN-Bでは、一つのコンセプトシートにまとめユーザー検証を進めることを行なっています。

話が前後してしまいますが、ここで「Why」の検証を行なっています。

具体的には、コンセプト検証のための簡単なサービス概要を表したチラシを作成し、ターゲットとなる顧客へのヒヤリングを行います。
ヒヤリングする内容も調査したい論点をまとめ何を得たいのかを明確にしながら行いました。

このユーザー調査でわかったことは、 「SEARCH WRITEと同じお客様に対して同様のセールス戦略では顧客のニーズは顕在化されない」ということでした。
また、既存の企業の中でも一部の企業様にヒヤリングをおこなったため調査できる企業数も少なく、新規プロダクトに対するユーザーニーズを持つ企業をヒヤリングの中では見つけることができませんでした。

新しいプロダクトにおける価値検証をする前の段階で、ウェブ接客領域における施策を実行したいという課題が顕在化しているお客様が少なくそれ以前の問題だったのです。

つまり、十分な検証は行うことができずに、MVPでの価値提供となりうるところがまだ明確にできないまま、継続的な議論としながら、プロダクトを企画・開発を並行して進めることを決断していました。
開発から４ヶ月ほどが経過していたのですが、まだまだ機能開発のプロダクトバックログが大量にあり、引き続き、開発を進めることがあったため、立ちどまって考えることをしませんでした。

リーンとなっていなかったプロダクト開発に気づき始める

SEARCH WRITEを利用いただいているユーザーは、流入数が向上をめざしてさまざまな集客施策（SEOやコンテンツマーケティング・広告など）を行い、一定の集客が見込める形になれば次のフェーズ「接客」が課題となってきます。

ユーザーインタビューを実施したお客様の多くでは、ウェブ接客領域のニーズをまだ顕在化できておらず、とにかく利用のメリットを理解してもらう必要があると考えていました。
またその中で、わかりやすく施策が実行できて、施策を分析し、PDCAを回すことで効果的なウェブ接客を行う必要がある。

コンセプト検証にてわかったことを頭の片隅におきながら新規プロダクト開発はどんどん進んでいきます。

これまでの開発の流れを振り返ると、、

1. デジタルマーケティング市場において有効な施策実行とされるウェブ接客領域にて実績があった
2. 社内におけるオウンドメディアにおける施策実行のノウハウをまとめ価値提供と考えた
3. プロダクトにおける機能はすでに世の中で定義されていたので開発をスタートした
4. 自社内での顧客層ではまだ潜在的なニーズとなるフェーズであり、課題は顕在化していない状態だった

確実な事実や経験をもとにしながらもユーザーニーズではドンピシャな課題として捉えられているところでのユーザー像に深いヒヤリングは行えなかったという不安定さがありながらも、自社の経験を元にした開発を進めていました。
冒頭でお話した、どこかしら何かを大事なところが抜けていながら開発を進めているような感覚がありました。何かしらの違和感はこれのことです。

そんな中で、ウェブ接客というフェーズにおいて自社が大事な価値と考えている「分析のPDCA」を回すところのUX設計を進めていく中で、MVP開発の中での「検証したい価値となる箇所」を見つけ設計していくフェーズを迎えます。

PLAN-Bが提供するプロダクトの重要価値となる仮説は「ウェブサイトに訪れたユーザーとのコミュニケーション設計を行う必要がある」という点でした。そしてこの「コミュニケーション設計を行なった施策をどのように検証しプロダクトとして可視化するべきか」という点です。
私がプロダクトマネージャーとして判断していた検討していたところは、分析となる部分は判断できる施策の数値を可視化するだけにとどめ、実行した接客施策のPDCA部分はサクセスチームによるサービスとしてのフォローアップにより実行していこうというところをぼんやりと考えていました。

しかし、「コンセプト検証」やUX設計が進み、分析画面のUIが立ち上がってきた段階でいよいよその違和感が目に見える形でよくわかってきました。

プロダクトマネージャーが計画を立てる上で、３ヶ月先・半年先といったプロダクトロードマップを引くことを常に検討していると思うのですが、UX設計からUIデザインの領域は実際の開発の３ヶ月先ぐらいの感覚で進めていることが多いと思います。
新しいプロダクト開発においてもサービスローンチを目標としていたところよりからさらに３ヶ月ほど後に開発されると計画している部分にて、UX・UIは動かしていたところで「ウェブ接客におけるコミュニケーションを設計する」というUIが完成したことにより、これまで感じていた違和感に気づくことができました。

この結果から、徐々に自分の頭の中が、先にウェブ接客における有効性を顧客に理解してもらう必要があるのではないかというところの視点ばかりを重視してしまっており、ウェブ接客の施策を実行する機能開発を優先的にバックログとして開発をすすめるところを行なっていたのです。
本来行うべきMVP開発における顧客に感じて欲しい価値の仮説検証ができないような状態でプロダクトを市場に提供してしまうことにつながっていると気づけたのです。

「Why」におけるユーザーのペイン・ゲインからくる課題定義や「What」におけるユーザー体験が綺麗に設計できなかったことが大きな原因です。

結果として、その気づきを開発の途中という段階で得ることができたため、バックログの優先度やロードマップ上のスケジュールを入れ替えつつも、すでに一部作ってしまった開発の部分は作り替えるなどを行い、サービスローンチの時期を少しだけ後ろ倒しにすることで、解消できる体制は作れました。
ですが、分析用のタグなどの仕様変更・作り込んでしまったUIや導線の変更、マイクロサービス化されている各種のAPI 仕様を変更するなど開発チームには、１ヶ月半ほど修正に費やすほどの工数が余計にかかってしまい大きな迷惑をかけてしまいました。

そんな中でも開発チーム側でも、MVP開発やアジャイルでの開発の考え方が浸透していたために、柔軟な切り替えに対応してくれたことは、大きく変更に舵を切る際には心強かったです。
開発チームとはスクラムで、コミュニケーション多く開発をすすめていることもあり、チーム全員でロードマップの変更に合意しながら進められたところは、PLAN-Bでの開発の特徴が出たような気がします。
私たちPLAN-Bでの開発チーム全員の特徴は全員が「顧客思考」をもった開発を進めるという点です。
たとえすでに開発が完了したところであっても、チーム全員が良いと思えるものが後発であがってくれば、良いと思えるところに舵をきり、全員で開発に取り組む姿勢は、より良いと思えるものをお客様に提供したいという一人一人の「顧客思考」とプロフェッショナルがあるからではないかと思います。

まとめ：「学び」の定義の重要性について

ここまで、PLAN-Bにおける新規におけるプロダクト開発の流れを、具体的な方法などでご説明しながら振り返ってみました。
今回、新しく開発を進める中でもっとも大きな学びとしては、「Core→Why→What→How」」のフェーズにおいては少なからずとも小さい仮説検証をまわし、リーンでのMVP開発では「学びの定義」をしっかりプロダクトマネージャーは常に意識をすることが重要だと感じました。

プロダクトの開発フェーズが進むとどうしても多くの関係者との調整や複雑となってくるバックログの整理、要件定義やUX設計、開発の進行などなど、日々の業務で盲目的になりがちです。
大枠の流れは今回ご紹介したようなところにはなりますが、リソース状況や組織による背景が違うこともあり、全てを手順通りに行うことも難しいのは、プロダクト開発の現場ではよくある話でもあると思います。

ですが、様々なフレームワークによってまずは問題を整理し、何が考えきれていないのかを開発を進めながら考えることを忘れては、いつのまにかMVP開発がうまくいかなくなることもあります。
この記事を読んでいただいている方の中には、新しいプロダクトや機能を企画していたり、MVP開発を現在進めていたりする開発チームもあるかもしれません。
その際に、企画中の各フェーズにおいて、今のMVP開発において「何を学ぶことができるのか」を再度、チーム全員で話し合ってみてもよいかもしれないですね。