Webサービスやアプリを開発するプロセス 〜企画編〜

この記事ではプロダクト=Webサービスやアプリをどう企画していくかについて述べます。プロダクトのつくりかたは千差万別で、このとおりにしたがえば必ず成功するというものではありません。ですが、失敗しない確率をできるだけ上げる方法は存在します。すなわち仮説を立ててユーザインタビューにより検証する開発プロセスです。

筆者は最近たくさんのエンジニアの方、とくにエンジニアになりたての方と話す機会があります。共通の課題として「プロダクトのつくりかた、とくに開発以外のことがわからない」というものが見えてきました。

筆者は過去10年間で20以上のプロダクトをつくってきました。ほとんどが失敗におわってしまいましたが、いくつか成果を残すことができたプロダクトがあります。失敗と成功をふまえ、さまざまな書籍を読み、できるだけ失敗しないプロダクトのつくりかたについてまとめました。すなわち次の章に示す5つのステップをとおしてプロダクトをつくっていきます。

この記事の著者は@zenizhです。Twitterでもプロダクトのつくりかたについて投稿しているので、よかったらフォローしてください。

5つのステップ

プロダクトの開発は、プロセスをステップごとに分けると次のような分類ができます。

1. Founder/Problem Fit: あなたが解決したい課題をみつける
2. Customer/Problem Fit: 解決したい課題を顧客が本当に抱えているかどうか確かめる
3. Problem/Solution Fit: 課題を解決する方法が本当に適切かどうか確かめる
4. Product/Customer Fit: 製品が顧客を満足させられるかどうか確かめる
5. Product/Market Fit: 製品が市場を満足させられるかどうか確かめる

この5つのステップについて、それぞれどのようなことをするのかを述べます。

それぞれについてはひとつひとつが大きなテーマとなるため、別途記事にしリンクを張る予定です。あるいはキーワードをGoogleなどで検索すると解説記事が見つかると思います

Founder/Problem Fit

このステップでは、プロダクトをとおしてあなたが解決したい課題を見つけます。また、その課題を解決する解決策や収益の流れなどを整理し、プロダクト開発を行うための準備を行います。

1. 解決したい課題をみつける: あなた自身やあなたの家族、親しい人などが体験した課題をもとに、解決したいと心の底から思う課題を見つけます
2. リーンキャンバスを書く: 解決したい課題をプロダクトとしてつくるために、ターゲットや解決策、収益の流れといったアイデアを1枚の紙に整理します
3. ミッションを決める: プロダクトをとおして実現したいこと、プロダクトが果たすべき使命を決めます

Customer/Problem Fit

このステップでは、作成したリーンキャンバスをもとに課題に関する仮説を整理します。またユーザインタビューをとおして課題仮説を検証します。「誰かの課題として明確に存在するプロダクト」を開発する、ということを確認することで、誰からも使われない可能性を下げることができます。

1. ペルソナを立てる: 課題を抱えている、心からその課題を解決したいと思う仮想のユーザをイメージし、属性を仮定します
2. 共感マップをつくる: ペルソナがふだん生活する中で、なにを見て聞いて感じるかを1枚の絵で仮定します
3. カスタマージャーニーマップをつくる: ペルソナが課題を解決するために、既存の解決策でどう解決しているか、そのときの感情はなにかを仮定します
4. 課題仮説を整理する: 1〜3でつくったペルソナに関する情報をもとに、仮説を『重要度』『不確実度』の2軸でマッピングします
5. プロブレムインタビューをする: 課題仮説を検証するために、ターゲットユーザに対してインタビューをします

Problem/Solution Fit

このステップでは、リーンキャンバスで仮定した解決策で本当に問題がないのか、いくつかの手法を用いて仮説を整理します。その後ユーザインタビューをとおして検証します。

1. PEST分析をする: 課題を解決する方法が、これを取り巻く環境においてどのような立ち位置にあるのか、あるいは実現可能性などについて分析します
2. ユーザストーリーマップをつくる: 課題をプロダクト上でどう解決するのか、ユーザストーリーをもとにマッピングします
3. プロトタイプをつくる: 解決策を検証できる最小限のコストでプロトタイプをつくります。ペーパープロトタイプやモックアップなどがあります
4. 解決策仮説を整理する: 1〜3でつくった解決策に関する情報をもとに、仮説を『重要度』『不確実度』の2軸でマッピングします
5. ソリューションインタビューをする: 解決策仮説を検証するために、ターゲットユーザに対してインタビューをします

Product/Customer Fit

このステップではMVP（Minimum Viable Product: 実用最小限の製品）をとおして製品がユーザの課題を解決できるかどうか、満足させられるかどうかを検証します。

1. プロダクト名を決める: 製品の名前を決めます。名前から解決策をイメージできること、ドメイン取得などの観点から候補を出します
2. フックモデルをつくる: ユーザが製品をどのような外的要因で起動するか、どのような行動や報酬を経て次の起動につなげるかを仮定します
3. グロースサイクルをつくる: ユーザの行動がプロダクトの成長にどうつながるか、循環する形でモデル化します
4. MVPを構築する: 課題を解決するために必要な最小限の製品をつくります。コードを書く必要は必ずしもなく、その場合はSaaSの組み合わせなどで実現します
5. 利用規約をつくる: 製品を利用するための利用規約やプライバシーポリシーをつくり、必要に応じて法務レビューを受けます
6. 製品仮説を整理する: 1〜3でつくった製品に関する情報をもとに、仮説を『重要度』『不確実度』の2軸でマッピングします
7. プロダクトインタビューをする: 製品仮説を検証するために、ターゲットユーザに対してインタビューをします

Product/Market Fit

このステップでは実際のプロダクトを開発しながら、市場が満足するプロダクトを目指します。このステップを完了すれば、あとはチームの拡大やマーケティングへの資金投入などでプロダクトをスケールさせることができます。

1. スクラム開発を導入する: 1〜2週間などの短い期間で機能を実装し仮説を検証するために、これに適した開発手法を導入します
2. バックログを更新する: ユーザストーリーマップをもとにバックログに追加していきます。入れる機能は熟考し、また積極的に機能を削除します
3. ロードマップをつくる: リリースまでの期間になにを実装するのか、誰に届けるのかを見える化します
4. プロダクトを構築する: バックログにしたがってプロダクトを開発します。PMF達成はスピードが重要なので、許される範囲で品質にこだわりすぎないようにします
5. プロダクトインタビューをする: いくつかの機能が実装されたタイミングで順次ユーザインタビューし、機能を検証します。必要に応じてバックログを更新します
6. カスタマーサポートをする: 初期のユーザはプロダクトを改善するためのたくさんのアイデアをもっています。適切にサポートし、そこから課題を抽出できる体制を構築します
7. ドッグフーディングをする: 自分自身もユーザとなりプロダクトを使い、改善のためのアイデアを出します
8. 顧客ライフサイクルを計測する: プロダクトを認知してから利用、定着し他者に紹介するまでの流れを数値化し観測します
9. ユニットエコノミクスを評価する: LTVとCACを計測し、資金投入によるスケールのタイミングを見定めます

おわりに

上記の開発プロセスはあくまで「失敗する可能性を減らすための方法のひとつ」です。すべてのプロダクト開発に適用できるものではありませんし、成功しているプロダクトもこのとおりに開発しているわけではありません。

もしあなたがプロダクト開発をはじめて行い、つくりかたがわからない場合は、この記事を参考にしつつ自分なりのつくりかたを構築できれば幸いです。

記事について不明な点や質問、改善点、ご指摘等ありましたら筆者のTwitterまでご連絡ください。フォローもお待ちしております。