前回の記事では『MVP開発』がどのようなものか、という点を取り上げましたが、今回はもう1歩踏み込んで、『MVP開発の進め方』『MVP開発の際、気をつけるポイント』等について、まとめてみたいと思います。
本記事の目的と対象読者
- MVP開発を取り入れたいエンジニア
- 既にMVP開発をおこなっているが上手く進んでいない方
- 新規事業を考えている事業主様
爆速でMVP開発を進めるステップ
『爆速で』と書きましたが、闇雲に作り初めてはいけません。
むしろ、限られたリソースを最大限活用するためにも、しっかりと計画を建てた上で望むのが最善です。
１.業務・処理フローの整理
以下の点に気をつけて整理を行ってみてください。
- MVP開発で検証したい仮説
- 仮説の検証に当たり必要な機能
- 運用体制
- 必要なコスト
『MVP開発で検証したい仮説』はMVP開発の根幹となる箇所です。
目的・ゴールを具体的に設定してください。
『仮説の検証に当たり必要な機能』はしっかり考える必要があります。
本当にその機能は必要でしょうか。
例えば”ウェブサービス”をMVP開発で作る場合に、”会員登録機能”は必ずしも必要ではないかもしれません。とにかく利用してもらったり、SNSログイン認証を使ったほうが早いケースもあります。
そういった機能の取捨選択を綿密に行いましょう。
もし迷うようでしたら、以下の図を参考にしてください。
『インパクトが強く』、『必要性が高い』機能はMVP開発に最初から含めていいでしょう。
一方で『インパクトが弱く』、『必要性も小さい』機能はMVP開発には要りません。
『運用体制』もこの段階で考えておきましょう。
運用によっては、機能のいくつかを削減できるかもしれません。
最後に『必要なコスト』を算出しましょう。
”コスト”はお金だけでなく、時間や人員も含まれます。
いきなり走り出すのではなく、支払うコストが最低限のものになっているか、しっかり確認してください。
２.最初に”見た目”から開発を行う。インフラ開発は最低限。
いよいよMVP開発に入ります！
インフラを作り込んで……システムを作って……と行きたいところですが、まずは”見た目”部分から開発を行います。
『Minimum Viable Product開発なら、”見た目”は一番力を入れなくて良いのでは…？』と思われたかもしれませんが、それは誤りです。
逆に『見た目さえしっかりしていれば、あとはハリボテで構わない』というのがMVP開発です。
とにかく使いやすく、”何を提供したいのか”がひと目で分かるようにしてください。
ものすごくニーズのあるサービスでも、使い勝手が悪ければ誰も使わないでしょう。
シンプルで明快なデザインを心がけてください。
なお、インフラ部分については最低限で構いません。
最終的には数万人に使ってほしいサービスだとしても、それは必要になってから用意すればいいのです。
3.一週間単位で改善を繰り返す
MVPが形になったらすぐに公開しましょう。
完璧にこだわってはいけません。「もっと良くできるかも……」と公開せずに改善を図ってしまっては、MVP開発の意味がありません。
改善は反応を見ながら行えば良いのです。
リアルなユーザーの動向を見ながら改善を重ねていく、それがMVP開発のメリットです。
常にデータを確認し、ユーザーはどの機能に注目しているか、どの機能を多く使っているか見てみましょう。
なお、ここも時間を掛けてはいけません。
１週間単位で改善を繰り返すことで、素早く需要にフィットさせましょう。
オススメの環境や言語
ここでMVP開発におすすめの環境や言語をご紹介します。
主にエンジニアの方向けの内容ですが、非エンジニアの方であっても、どういった手法であるのか知っておくならば、システム会社と組む際等にコストの削減が図れるかもしれません。
MVP開発に適した言語
- JavaScript（TypeScript）
- Ruby(Ruby on Rails)
- Python
まずは「JavaScript」です。何故これがMVP開発向けかと言えば、フロントエンド・バックエンド両方をこれ一つで描くことができるからです。
特に、”React”や”Vue.js”といったフレームワークを用いることで、工数を圧倒的に削減することができます。
またWEBだけでなく、スマホアプリ・ネイティブアプリも一つの言語で対応可能なので、汎用性の高さも非常にMVP開発向きだと言えます。
「Ruby」はWebアプリ、Webサービスを作る際、最も簡単に作成が可能な言語です。
特に”Ruby on Rails”はWebアプリケーション開発用のフレームワークなので、開発工程を短縮するためのモジュールやツールが多分に含まれています。
その点「Python」も有用です。PythonもWebアプリやWebサービスを作るのが簡単な上、Ruby以上にライブラリが充実しています。
特に目下注目されている”機械学習”や”AI開発”との相性が非常に優れている言語です。
MVP開発におすすめの環境
- AWS(Amazon Web Services)
- GCP(Google Cloud Platform)
- Firebase
- Vercel
「AWS」と聞くと『難しそうだからMVP開発には向かないのでは…』と思うかもしれませんが、むしろ逆です。
多くの導入事例がネット上に掲載されており、ドキュメントも豊富に用意されています。「何かをやりたい」と思った際、おおよそのことは調べればできてしまうでしょう。
後述のGCPと比較して、日本語のサポートが手厚いのも利点といえます。
更に、うまく軌道に乗って、将来的にプロジェクトが大きくなったとしても、AWSならそのまま対応が可能です。
「GCP」も多くのMVP開発で使われています。
サービス自体はAWSと似ていますが、Googleが用意しただけあって、ビッグデータ解析やAI分野のサービスに秀でています。
また無料枠が豊富に用意されているところも、MVP開発向きと言えるかもしれません。
「Firebase」はGCPと同じくGoogleが用意した、モバイル・Webアプリ製作に特化したプラットフォームです。
柔軟性の面ではAWSやGCPに劣りますが、できることが限られているため初期の構築コストを抑えることができます。
更に手軽なサービスとして「Vercel」があります。
Githubなどのリポジトリと連携することで、すぐにWEBサービスやWEBアプリを制作することが可能です。Firebaseと比較しても格段に簡単です。
ただし、日本語のドキュメントはまだ少ないので、調べ物は英語で行なうことをオススメします。
開発時の気をつけるポイント
MVP開発では、特に以下の点を意識して行ってください。
機能からではなく、ニーズから開発する。
前回の記事でも書きましたが、MVP開発の目標は『ニーズの検証』です。
「こういうものを作りたい！」という発想は大事ですが、それを目的にしてしまっては意味がありません。
「このプロダクトにはニーズがあるはずだ」という仮説を検証するためにMVP開発を行いましょう。
プロダクトオーナーと開発者の２つのロールを設ける
チームで取り組む際、必ず「プロダクトオーナー」と「開発者」の役割を作りましょう。
先程MVP開発では「機能の取捨選択が大事」と言いましたが、細かい箇所でもその取捨選択が必要になります。
そのすべてをチームで議論したり、メンバーそれぞれで意見が分かれている状態ならどうでしょうか。スピードは上がらず、開発メンバーに負荷も掛かります。
なので「プロダクトオーナー」のロールを設けて、その一人がすべての判断を行なうことで、迅速に開発を行なうことが重要なのです。
シンプルな業務・処理フローにする
ここまでMVP開発について読んでいただいた方にはわかるかと思いますが、”複雑な業務フロー”や”複雑な処理フロー”は、MVP開発の大敵です。
『開発速度』『柔軟性』『コストの削減』『問題の特定』等、MVP開発の重要な部分が、全て台無しになってしまいます。
MVP開発を取り入れる以上、業務フロー、処理フローはなるだけシンプルなものになるよう意識しましょう。
より早く開発できるプログラミング言語・環境で行う
MVP開発を行なう際、多少不慣れであっても、先程挙げた「MVP開発に適した言語・環境」を使うようオススメします。
これは単純に「開発期間を短縮できる」というだけではありません。
「今まで多くのMVP開発で使われてきた」ということは、MVP開発向けのライブラリやプラグイン、ドキュメントが多数用意されているということです。
”リスクの低減”や”改良”のためにも、MVP開発に適した言語・環境を使いましょう。
失敗する前提で最低でも半年は試行を繰り返す
そして重要な点として、例え優れたアイデアであったとしても、すぐに評価される製品は多くありません。
１ヶ月経っても良い反応が得られなかったからといって、諦めてしまわないようにしましょう。
むしろそこからが「MVP開発」のスタートです。
毎週毎週、得られた情報から改善点を洗い出し、試行を繰り返してください。
最初に開発したものとはだいぶ変わってくるかもしれませんが、それでもきちんと顧客のニーズに応えられる製品が作れたのなら、MVP開発は大成功と言えます。
MVP開発のよくある失敗
気をつけるべき点の次は、よくある失敗についてご紹介します。
最初から機能を多くする
MVP開発において「機能を多くする」ことは悪いことです。
作る時間が無駄というのももちろんですが、「ニーズがあるかどうか検証する」上では、無駄な機能が入っているとかえって邪魔なのです。
しかしながら、うっかり会議等で「こういう機能を追加したらどうだろうか……」という意見が、まるで素晴らしいものかのように出てくるかもしれません。
それで検証に失敗したら本末転倒です。「意識的に」機能を少なくしてください。
プロダクトオーナー任せ、開発者任せになる
先程「プロダクトオーナー」「開発者」の役割を作る重要性についてはお話しましたが、
役割を作ったからといって、完全に孤立してはいけません。
最終的にはプロダクトオーナーが決定を行いますが、仕様の意図や、実装時に気になった点等は積極的に意見を交換しましょう。
また、プロダクトオーナーがコードを書くのに忙しかったり、
開発者に全て自分で考えるよう任せたり、といったこともないようにしましょう。
サービスの提供先がない。またはこれから開拓する
MVP開発の目標は『需要の検証』という点はお話しましたが、
「まったく需要が存在するのわからない」プロダクトや、
「まったく接点がないところから、需要を作り出そうとする」試みは、いささか無謀かもしれません。
需要を確認する手段は、MVP開発以外にもたくさんあるはずです。
しっかりと市場を調査し、情報を収集し、綿密な仮説を立て、最後その仮説の検証を行なう手段としてMVP開発を行いましょう。
予算を確保していない
MVP開発は「低コストに始められる手段」ではありますが、その後改善を繰り返していくことが前提の開発手法なので、
総額でみれば、通常の開発手段とそこまで大きな差が付くわけではありません。
「初月からマネタイズできる」といった無謀な計画を建てるのではなく、しっかりと改善期間・改善コストも視野に入れた上でMVP開発に望みましょう。
（なお、MVP開発を行った上で融資を依頼するという手もあります。その場合、リアルな製品・数字を武器にできるため、非常に強力です）
MVP開発に精通したシステム会社と組みましょう
もしあなたがMVP開発を依頼する側の方なら、ぜひMVP開発に慣れたシステム会社を選ぶようお勧めします。
MVP開発に慣れたシステム会社ならば、既存のCMSを利用したり、工数の削減案等を出したり等、圧倒的に作業量を下げられるかもしれません。
利用状況の読み方や、改善案の出し方もスムーズでしょう。
そのためにも慎重な会社選びをおすすめします。
なお弊社もMVP開発経験のあるシステム会社です。
MVP開発に関する相談等ございましたら、ぜひお問い合わせください。
弊社のMVP開発事例
- toB向け教育SaaS
- リース業様顧客管理システム
- 公共事業者様向け決済サービス基盤
