MVP開発に必要な体制：PM・デザイナー・エンジニアの役割分担

MVP開発に必要な体制は、大人数のチームではなく、「何を作るかを決める人」「使われる形に設計する人」「動くものを作る人」の3つの役割がそろった少人数のチームです。結論から言えば、役割の数と人の数は一致しなくてよく、1人が複数の役割を兼ねることも珍しくありません。大切なのは、それぞれの役割に責任を持つ人が明確で、その人たちが短い間隔で顔を合わせ、その場で判断できることです。

そして、社内と外部の分担では、「何を作るかを決める役割」は必ず社内に置くのが原則です。設計や開発は外部の力を借りられますが、事業の判断まで外部に任せると、検証で得た学びが社内に残らず、次の判断ができなくなります。

この記事は、新規事業のMVPを作ろうとしている事業責任者・新規事業担当者に向けたものです。MVP開発に必要な役割、少人数での組み方の型、社内と外部の分担の考え方、体制づくりでよくある失敗とチェックリストを整理します。

MVP開発の体制が通常の開発と異なる点

一般的なシステム開発では、要件を固めたうえで、設計、開発、テストの担当者がそれぞれの工程を進め、プロジェクトの管理者が全体の進み具合を管理します。要件が決まっているため、関わる人数が多くても、役割に沿って分業すれば進められます。

MVP開発では事情が違います。作るものそのものが、検証の結果によって変わっていくからです。そのため、MVPの体制には次のような特徴が求められます。

• 判断を待たずに進められるよう、決める人がチームの中にいる
• 作る人と決める人の距離が近く、短い間隔で動くものを見ながら話せる
• 一人ひとりが自分の担当の範囲を超えて、全体の目的を理解している
• 人数が少なく、情報の伝達に時間がかからない

人数が増えるほど、情報の共有と合意に時間がかかります。MVPの段階では、人を増やすことが必ずしも速さにつながらない点に注意が必要です。短期間でMVPを作る進め方全般については短期間でMVPを作る進め方でも解説しています。

MVP開発に必要な役割

MVP開発に必要な役割を、役職名ではなく「何に責任を持つか」で整理します。

この5つの役割のうち、プロダクトの責任者とプロジェクトの進行役は、MVPの段階では同じ人が兼ねることが多くあります。いわゆるPM（プロジェクトマネージャー）という言葉は、組織によってこの2つのどちらか、あるいは両方を指して使われます。誰がどちらの責任を持つのかを、言葉の定義ではなく実際の仕事で確認しておくことが大切です。

プロダクトの責任者

MVP開発で最も重要な役割です。検証したい仮説を決め、どの機能を作り、どの機能を作らないかを決めます。顧客の声と、開発の手間と、事業の目的を天秤にかけて判断するのが仕事です。

この役割を担う人には、事業の目的を深く理解していること、判断する権限を持っていること、そしてMVPの開発に十分な時間を割けることが求められます。兼務が多く、週に一度の打ち合わせにも出られないような状態では、開発は判断待ちで止まってしまいます。

設計・デザインの担当

利用者が迷わずに使えるよう、画面の流れと画面そのものを設計します。MVPでは、すべての画面を細かく描く必要はなく、主要な操作の流れに集中します。既製の部品をそろえたUIキットを使えば、開発の担当がこの役割の一部を担うこともできます。

開発の担当

技術を選び、機能を作り、テストし、公開します。MVPでは、画面の側と、データを扱う側の両方を扱える人がいると、少人数でも進めやすくなります。最近はAIコーディングアシスタントなどの道具を活用することで、少人数でも開発を速く進められるようになっています。

顧客との接点の担当

MVPを使ってくれる利用者を集め、聞き取りをし、問い合わせに対応します。見落とされがちですが、この役割がないと、MVPを作っても検証の材料が集まりません。プロダクトの責任者が兼ねることもよくあります。

法人向けのサービスであれば、営業や既存顧客の担当者がこの役割を担うと、聞き取りの相手を見つけやすくなります。その場合も、聞き取りの内容がプロダクトの責任者に確実に届くよう、記録の形式と共有の場を決めておきます。顧客の声が担当者の頭の中だけに留まっていると、判断の材料として使えません。

少人数での体制の型

MVPの体制には、いくつかの典型的な型があります。事業の状況と社内の人材によって、どの型が合うかが変わります。

どの型でも共通して言えるのは、プロダクトの責任者が社内にいることです。開発の担当の人数は、機能の量と期間から決めますが、MVPの段階で人数を増やしすぎると、かえって調整の手間が増えます。

社内と外部の分担の考え方

MVP開発では、社内だけで必要な役割をすべてそろえるのは難しいことが多く、外部の力を借りることが一般的です。どの役割を社内に置き、どの役割を外部に頼むかは、次の考え方で整理します。

必ず社内に置くべき役割

プロダクトの責任者：何を作り、何を作らないかの判断は、事業の責任を持つ社内の人が行うべきです。外部に任せると、検証で得た学びが社内に残りません。また、外部の協力者は、契約の範囲を超えて事業の判断の責任を負うことはできません。

顧客との接点：顧客の声を直接聞くことは、事業の判断の土台です。聞き取りの一部を外部に手伝ってもらうことはできても、社内の責任者が自ら顧客と話す機会は必ず確保します。

外部に頼みやすい役割

開発：技術を選び、作り、公開する役割は、外部の開発会社やフリーランスに頼むことが多い部分です。MVPに慣れた外部の協力者であれば、少人数でも速く進められます。

設計・デザイン：画面の設計やデザインも、外部の協力者に頼みやすい役割です。開発と同じ協力者に頼むと、設計と開発の間の手戻りを減らせます。

プロジェクトの進行：社内に進行の経験者がいない場合、外部の協力者に進行を支援してもらうこともできます。ただし、判断そのものは社内の責任者が行う分担を明確にしておきます。外部からPMを迎える場合の考え方は新規事業のPMを外部から入れるときで詳しく扱っています。

分担を決める手順

1. 必要な役割を一覧にする：前述の5つの役割と、それぞれの具体的な仕事を書き出す
2. 社内の人材を当てはめる：各役割について、社内に担える人がいるか、その人がどのくらいの時間を割けるかを確認する
3. 社内に置くべき役割を確定する：プロダクトの責任者と顧客との接点を担う人を決め、必要な時間を確保する
4. 足りない役割を洗い出す：社内で担えない役割、時間が足りない役割を明らかにする
5. 外部に頼む範囲を決める：足りない役割を、どのような協力者に、どの範囲で頼むかを決める
6. 役割の境目を言葉にする：社内と外部の間で、誰が何を決め、誰が何を作るのかを文書にする
7. 連携の場を決める：週次の打ち合わせなど、社内と外部が一緒に判断する場の頻度と形を決める

外部の開発会社と組む場合の進め方は、MVP開発会社との進め方で、週次レビューと意思決定の回し方を詳しく解説しています。

役割ごとに必要な時間と、チームの動かし方

役割を決めても、担当者が実際にその仕事に時間を使えなければ体制は機能しません。特に社内の担当者は、既存の仕事との兼務になることが多いため、MVPの期間中にどのくらいの時間を割けるかを具体的に決めておきます。

社内の担当者の時間の確保

プロダクトの責任者は、週次の打ち合わせに加えて、開発からの質問への回答、顧客への聞き取り、検証結果の整理といった仕事があります。週のうち決まった曜日や時間帯をMVPの仕事に充てる、と上司や関係者と合意しておくと、急な既存業務に押し流されにくくなります。顧客との接点を担う人も同様に、聞き取りの予定を先に押さえておきます。

時間の確保が難しい場合は、その事実を隠さずに体制に反映させます。たとえば、責任者が週の一部しか関われないなら、日々の小さな判断は副担当に任せ、事業の方向に関わる判断だけを責任者が行う、といった権限の分け方を決めておきます。

チームの打ち合わせの組み立て

少人数のチームでも、打ち合わせの形を決めておくと、判断と情報共有の抜け漏れが減ります。よく使われるのは、次のような組み合わせです。

• 週次の打ち合わせ：動くものを見ながら、優先順位と次の1週間の作業を決める。責任者は必ず参加する
• 短い日次の共有：開発の担当同士で、進み具合と困っていることを共有する。社内の責任者は必要なときだけ参加する
• 区切りごとの振り返り：数週間ごとに、進め方そのものの良かった点と改善点を話し合う

打ち合わせを増やしすぎると、作る時間が減ってしまいます。判断が必要な事項はチャットなどで随時共有し、打ち合わせでは「決めること」に集中する運用が効果的です。

MVPの後を見据えた体制

MVPの体制は、検証が進むにつれて変えていく必要があります。MVPの段階では外部の協力者に開発を頼んでいても、事業が成長して開発を継続的に行うようになると、社内に開発者を置くことを検討する場面が出てきます。

この移行を見据えて、MVPの段階から次の点を意識しておくと、後の負担が小さくなります。

• ソースコードや設計の資料を、社内で管理できる場所に置いておく
• 設計の意図や、技術を選んだ理由を短く残しておく
• 社内の担当者が、開発の打ち合わせに参加し、全体の構成を理解しておく
• 外部の協力者との契約で、成果物の権利と引き渡しの条件を確認しておく

内製と外注をどの段階で切り替えるかについては、内製化か外注か：システム開発の体制を段階ごとに切り替える考え方で整理しています。

具体的な場面の例

架空の例で考えてみます。ある中堅の製造業の会社が、自社の設備保守のノウハウを活かし、同じ業界の中小企業向けに、設備の点検記録を管理するWebサービスを新規事業として始めることにしました。社内には業務システムを担当する情報システム部門の担当者はいますが、Webサービスを新しく作った経験のある人はいません。

最初は、新規事業の担当者を責任者に据え、開発はすべて外部の開発会社に任せる計画でした。しかし、責任者は既存の事業の仕事も兼務しており、週に一度の打ち合わせへの参加も難しい状況でした。このままでは、開発会社からの確認が溜まり、開発が止まることが予想されました。

そこで、体制を次のように見直しました。

• プロダクトの責任者：新規事業の担当者が担い、既存の業務の一部を他のメンバーに移して、MVPの期間中はこの仕事に多くの時間を充てる
• 顧客との接点：責任者と、保守の現場をよく知る社員の2名で担い、取引のある中小企業への聞き取りを行う
• 設計・デザインと開発：外部の開発会社に依頼する
• プロジェクトの進行：開発会社の担当者が進行を担い、判断が必要な事項は週次の打ち合わせで責任者が決める
• 社内の技術の窓口：情報システム部門の担当者が打ち合わせに参加し、社内のセキュリティの規則との調整と、将来の引き継ぎに備えた構成の理解を担う

この体制で進めたことで、判断待ちによる遅れが減り、現場をよく知る社員の意見が画面の設計にも反映されました。また、情報システム部門の担当者が早い段階から関わっていたため、社内の審査もスムーズに進みました。

よくある失敗と避け方

責任者が兼務で時間を割けない：最も多い失敗です。判断が遅れ、開発が止まります。責任者を決めるときは、MVPの期間中に割ける時間を具体的に確認し、他の仕事を調整します。

判断まで外部に任せる：何を作るかの判断を外部の協力者に任せると、検証の学びが社内に残りません。外部には選択肢と意見を出してもらい、判断は社内で行います。

最初から人を増やしすぎる：人数が多いと、情報の共有と合意に時間がかかります。MVPの段階では少人数で始め、必要に応じて増やします。

顧客との接点の役割を誰も持たない：作ることに集中するあまり、利用者を集め、話を聞く役割が抜け落ちることがあります。この役割の担当者を明確に決めます。

役割の境目があいまい：誰が何を決めるのかがはっきりしないと、同じことを二人が別々に進めたり、誰も手をつけなかったりします。役割の境目を文書にしておきます。

社内の関係部署を巻き込まない：法務、情報システム、経理など、後で確認が必要になる部署を巻き込まずに進めると、公開の直前に止まることがあります。早めに関わってもらう人を決めておきます。

体制を決めるときのチェックリスト

• プロダクトの責任者が社内にいて、判断する権限を持っている
• 責任者がMVPの期間中に割ける時間が、具体的に確保されている
• 顧客との接点を担う人が決まっている
• 設計・デザイン、開発、進行の各役割を誰が担うかが決まっている
• 社内で担えない役割について、外部に頼む範囲が明確になっている
• 誰が何を決め、誰が何を作るのかが文書になっている
• 社内と外部が一緒に判断する場の頻度と形が決まっている
• 法務、情報システムなど、関係部署の窓口が決まっている
• ソースコードや設計の資料を社内で管理できる状態になっている
• MVPの後の体制の移行について、方向性を話し合っている

よくある質問

Q. MVP開発は何人くらいの体制が適切ですか？

機能の量と期間によって変わりますが、多くのMVPでは、責任者を含めて数名の少人数で進めることが一般的です。人数を増やす前に、役割がそろっているか、判断がすぐにできる状態かを確認するほうが、速さにつながります。開発が遅れているときに人を追加しても、新しく入った人が全体を理解するまでの時間や、説明に既存のメンバーの時間が取られることで、短期的にはかえって遅くなることもあります。人を増やすのは、作業を分けやすい部分がはっきりしているときに限るのが安全です。

Q. 社内にエンジニアがいなくても、MVPは作れますか？

作れます。開発と設計は外部の協力者に頼み、社内では何を作るかの判断と、顧客との接点に集中する体制が現実的です。そのうえで、社内に技術の相談ができる窓口があると、外部とのやりとりがスムーズになります。

Q. デザイナーは必ず必要ですか？

必須ではありません。UIキットを使えば、開発者が画面を組み立てられます。ただし、利用者の使いやすさが検証の結果を大きく左右するサービスでは、主要な画面の流れだけでも設計の経験がある人に見てもらうことをおすすめします。

Q. 責任者に向いているのはどんな人ですか？

事業の目的を深く理解し、顧客の声を自分で聞きに行けて、不確実な状況でも判断を先送りしない人が向いています。技術の深い知識は必須ではありませんが、開発の手間やリスクについて説明を受けたときに、判断の材料として理解できることは必要です。

Otsumuに相談できること

社内に判断の権限と時間を持つ責任者がいて、開発者やデザイナーを社内外から確保できるなら、この記事の役割の整理とチェックリストに沿って、自社でMVPの体制を組めます。少人数でも、役割がそろい、判断がすぐにできる状態であれば、十分に速く進められます。

一方で、社内に開発や設計を担える人がいない、外部とどう分担すればよいか分からない、責任者が判断に必要な技術の見立てを得られない、といった場合は、事業の判断と開発の両方を理解した協力者と組むほうが、体制づくりに時間を取られずに済みます。

Otsumuは自らも事業を手がける立場から、目的から逆算して作る範囲を絞り、AIを活用した少人数・短期間の開発で、構想から検証、公開後の改善まで一気通貫で支援しています。新規事業の爆速MVPシステム開発では、社内の責任者の判断を支えながら、設計と開発、進行をまとめて担う体制を基本にしています。何を検証すべきかの整理から始めたい場合は新規事業開発コンサルティングもご覧ください。

体制をどう組むかを考え始めた段階からでもご相談いただけます。まずは30分の無料相談で、いまの状況をお聞かせください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01