はじめに
こんにちは。エムスリーキャリアで健康経営事業開発を担当しているエンジニアの金子です。
限られたリソースの中で、いかにして事業課題の解決に繋がるプロダクトを迅速に市場投入するかは多くのエンジニアの悩みの種です。MVP（Minimum Viable Product）はその有効なアプローチの一つですが、実務では「あれもこれも必須だ」と要望が増え、いつの間にか最小からは程遠いものになってしまうことが少なくありません。
このギャップを技術的な視点から埋め、プロダクトを「検証可能な最小限の形」に導くこと。それが、MVP開発におけるエンジニアの重要な役割だと考えています。
この記事では、私たちがMVP開発を進める上で心掛けていること、特に「やらないこと」を明確にし、ビジネスサイドとどう円滑に調整するか、実際に実践している以下の3つの方法をご紹介します。
- 議論の軸を作るためのドキュメント
- 「やらない」判断を円滑に進めるコミュニケーション
- 開発時に注意したいこと（落とし穴）
日々のスコープ決めに悩むエンジニアやプロダクトマネージャーの方にとって、少しでもヒントになれば幸いです。
実践１：議論の軸を作るためのドキュメント
職種や立場が違うと、同じゴールを見ていてもそこに至るイメージは少しずつ異なります。特にシステム開発においては当然ながらエンジニアとビジネスサイドとの間には大きな認識のギャップがあります。そのため、まずチーム全員の目線を合わせ、議論が迷走しないための共通の土台を作ることが効果的です。
私たちは、ヒアリングやブレストを一通り終えたあと、詳細を詰めていく起点として、A4一枚程度のシンプルなドキュメントに以下のような基本的な方針をまとめるようにしています。
- 目的
このプロジェクトで何を達成したいのか？ - 検証したい仮説
このMVPで何を明らかにしたいのか？ - リリーススケジュール
いつまでに市場に投入する必要があるか？ - やること
価値を提供でき、かつ仮説検証に必要な最小限の機能の一覧。 - やらないこと
スコープ外とする機能の一覧と、その理由。代替案や、想定されるリスクと、その回避・軽減策も併記する。
議論が複雑になったり、話が逸れたりしたときに「この機能は、ドキュメントの目的に立ち返ると本当に今やるべきだっけ？」と確認することで、本来の目的に立ち返りやすくなります。
特に「やらないこと」は曖昧にしておくと、開発が進むにつれ「これは必要なのでは？」と突然復活することがよくあります。そんなときにこのドキュメントを元に認識をすり合わせ、開発を本筋に戻すことができます。
実践２：「やらない」判断を円滑に進めるコミュニケーション
MVP開発で特に丁寧さが求められるのが、ビジネスサイドの要望に対して「やらない」と判断し、納得してもらうプロセスです。ここではロジックだけでなく伝え方の工夫も重要になります。
CSや営業から挙がる要望は、貴重な顧客の声です。まずはその背景にある課題をしっかりヒアリングし、理解することから始めます。その上で要望を以下の3つに整理します。
- 必須の機能
これがないと顧客が価値を感じられず、仮説検証もできない機能 - あると良い機能
価値を高めるが、代替手段があったり、次の開発フェーズでも良い機能 - スコープ外の機能
MVPの目的から外れてしまう要望や機能
そして「やらない」と判断したものについては、その理由を技術的な観点や開発スケジュールなどを踏まえて説明します。「やらない」と伝える際は、代替案または想定されるリスクの軽減・回避策と今後の見通しをセットで提示することを心掛けています。
例えば「XXができる運用管理機能が欲しい」という要望があった場合、
やらない理由
MVPの段階では、利用するユーザーが限定的で、運用コスト削減に対して開発コストが見合わない可能性があります。
代替案と今後の見通し
既存の機能の組み合わせで運用コストが削減できるので、まずはこの手順で試してみてはいかがでしょうか。フルスクラッチ開発時には容易に実現できるので優先的に開発を検討しましょう。
と、このように伝えることで、ビジネスサイドにも判断の背景が伝わり、納得感を得やすくなります。
MVP開発で注意したいこと
MVP開発は強力なアプローチですが、その過程にはいくつかの落とし穴も存在します。最後に、私たちが注意している点をいくつか紹介します。
MVPの「次」を見据えた設計
MVPはあくまで始まりです。特にkintoneやBubbleなどのノーコードツールを使って素早く開発する場合、将来の本格開発への移行が困難にならないよう、データ移行のしやすさといった技術的な「次のステップ」を初期段階で少しでも検討しておくと、将来の修正コストが高くなるリスクを減らせます。
スコープ削減の落とし穴①：「作らなさすぎ」の罠
スコープを厳しく絞ることはMVPの基本ですが、それが行き過ぎると、見落としがちな罠に陥ることがあります。それは「作るべき価値ある機能を作らないまま進んでしまう」リスクです。
例えば、ビジネスサイドが「これは実現が難しいだろう」「時間がかかりすぎるだろう」と遠慮してしまうことで起こります。結果として、本当は価値が高く、工夫次第で実現可能な提案を拾えなくなってしまいます。
この罠を避けるには、エンジニアが単にスコープを守るだけでなく「こういう方法なら低コストで実現できますよ」と積極的に技術的な選択肢を示すことが重要です。そして、その土台となるのが、どんなアイデアでも気兼ねなく言える「心理的安全性」の高い環境です。
例えば、エンジニアが専門用語を避け、対等な立場でどんな質問も歓迎する姿勢を示すことで「こんなことを聞いてもいいのだろうか」という無用な遠慮がなくなり、活発な意見交換が生まれます。
スコープ削減の落とし穴②：「安心感」という価値の見落とし
もう一つのスコープ削減の落とし穴が「安心感」という価値を見落としてしまうことです。MVPでは、実際に頻繁に使われるコア機能に目が行きがちです。しかし、顧客が導入を決定する際には「これならちゃんと運用できそうだ」という安心感も重要な判断材料になります。
例えば、レアケースでしか利用しない設定項目なのでその項目をスコープ外とした結果、そのレアケースが心配で導入を見送るという事例が実際にありました。今思えば、導入前のイメージの湧かない段階で顧客が不安に思うことは当然ですが、スコープを削る議論の中でも「この機能がないと、顧客が導入に不安を感じないか？」という視点を忘れないようにしたいものです。
おわりに
MVP開発を成功に導くには、エンジニアがコードを書くだけでなく、ビジネスサイドと連携し、一緒になって事業目的の達成を目指す視点が重要です。そのためには、ビジネスサイドと信頼関係を築き、顧客の課題への深い理解が不可欠となります。
技術的な視点から「何が顧客への価値となり、何を検証すべきか」を考え「やること」と「やらないこと」の判断をサポートし、チームの合意形成を後押しすること。こうした主体的な動きこそが、MVP開発を成功に導く鍵となります。
この記事が、皆さんの日々の開発の参考になれば幸いです。
このように、技術的な挑戦だけでなくビジネスサイドと深く連携し、事業課題の解決に主体的に関わっていくスタイルが、私たちエムスリーキャリアのエンジニアの特色です。
もし、私たちの働き方に少しでも興味を持っていただけましたら、ぜひ下記の採用ページをご覧ください。
