LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

新しい事業のアイデアはあるのに、どこまで作れば試せるのかが決まらない。社内に経験者がいないのでフリーランスのエンジニアに頼みたいが、何をお願いすればよいのか言葉にできない——。新規事業を任された開発の現場では、こうした迷いが起こりがちです。MVP開発とは、利用者に価値を届けられる最小限の機能だけを持つ製品（MVP）を作り、実際に使ってもらって反応を確かめる進め方です。

社内にない技術を持つエンジニアに期間を区切って加わってもらうフリーランス活用は、短い期間で動くものを作るMVP開発と組み合わせやすい方法です。ただし万能ではなく、何を確かめるのか、どこまで作るのかが決まらないまま頼むと、作る範囲が広がり続けます。本記事では、新規事業を担当する開発マネージャーに向けて、確かめる仮説の決め方、作る範囲の絞り方、検証の節目、そして検証が終わったあとのコードと引き継ぎで確認したい点を整理します。

新規事業のMVP開発とは

IPA（情報処理推進機構）の「DX実践手引書 ITシステム構築編」は、MVPを「ユーザーへのサービス提供における、最小限の機能を備えたプロダクト」と説明しています。^*1 完成品を一度に出すのではなく、最小限の機能に少し足した程度のものを出し、利用者の反応を見ながら改善していく考え方です。デジタル庁の「アジャイル開発実践ガイドブック」も、MVPを「実用的で最小限の範囲で動くプロダクト」としています。^*2

画面の見た目や操作の流れを確かめる試作と違い、MVPは実際の利用者に使ってもらうことが前提です。機能は少なくても、申し込みから利用までの流れが本当に動く必要があります。画面の案や試作で要求を固める段階は「フリーランス活用で新規事業の要件定義を進める、試作から決める手順」で扱いました。本記事で扱うのはその先の、動くものを利用者に出して反応を確かめる段階です。

新規事業では、使う技術が社内の既存のシステムと違うことが少なくありません。その技術に詳しい人を、検証の期間だけ迎えたい場面が出てきます。一方で、何を確かめるのか、確かめた結果で事業をどうするのかは、事業を進める社内の人にしか決められません。MVP開発でのフリーランス活用は、作る作業を任せ、判断は社内に残す形で考えると整理しやすくなります。

何を検証するのか

DX実践手引書は、新しい製品を生み出す手法としてリーン・スタートアップを紹介しています。まず「価値仮説と成長仮説」を立て、構築、計測、学習の繰り返しで仮説を確かめる手法です。^*1 MVPを作るのは構築の段階です。計測の段階で利用者から実際のデータを集め、学習の段階で方向を変えるかどうかを判断します。

価値仮説は、利用者がそのサービスに価値を感じるかどうかについての見込みです。成長仮説は、利用者がどのように増えていくかについての見込みです。最初のMVPで両方を確かめようとすると作る範囲が広がるので、まずどちらを確かめるのかを決めます。

同じ手引書は、仮説と成功条件を明確にしたうえでまず挑戦することが重要だとしています。成功条件は、数字で書いておくと判断がぶれません。たとえば「予約を申し込んだ人のうち、1か月以内に2回目の予約をした人が3割を超えれば、価値仮説は当たったとみなす」という書き方です。3割という水準は書き方の例で、実際の数字は事業の計画から決めます。

仮説を立て、確かめ方と指標を設計し、結果を読み解いて次の判断につなげる力は、IPAの「デジタルスキル標準」でも「仮説検証・学習サイクル設計」というスキルとして定められています。^*3 仮説と成功条件は社内で書き、フリーランスのエンジニアに渡します。渡しておけば、エンジニアは申し込みの件数や2回目の利用といった数字を取れる仕組みを、最初から組み込めます。

作る範囲の絞り方

デジタル庁のガイドブックは、発注の段階で「その時点で必須もしくは解決すべき優先度の高い開発範囲」と「開発対象としたいが実現範囲と内容は調整可能」な範囲という、少なくとも2つの領域を設けて示すよう求めています。前者がMVPにあたります。^*2 政府の情報システムの調達に向けて書かれたものですが、フリーランスのエンジニアに頼む範囲を決めるときにも同じ分け方が使えます。

同じガイドブックは、今本当に必要なものだけを作るという「YAGNI」の考え方も紹介しています。使われない機能でも、作ればテストや保守、マニュアル作成などのコストがかかり、ソフトウェアも複雑になるためです。DX実践手引書も、ある調査の結果として、リリースされたシステムの機能のうち約3分の2はあまり使われていないと述べています。^*1

2つの領域に「今は作らない範囲」を加え、会員制の予約サービスを例に分けると次のようになります。

分けるときの問いは「この機能が無いと、決めた仮説を確かめられないか」の1つです。確かめられないなら外せない範囲に、確かめられるなら調整できる範囲か今は作らない範囲に入れます。範囲を決め、優先順位を付け、変えるときの影響を見て判断することは、デジタルスキル標準で「プロダクトスコープと優先順位のマネジメント」というスキルに整理されています。範囲を決めるのは社内の担当者で、エンジニアには機能ごとにどのくらい手間がかかるかを見積もってもらいます。

検証の節目の置き方

デジタル庁のガイドブックは、計画を立てるときに「早めに小さく失敗しておく」ことを意識するよう勧めています。MVPとして最初に作ったものが目的に合わないこともあるため、作り直しが起こる可能性を織り込んだマイルストーン（途中で状態を確かめる節目）を置くという考え方です。^*2

フリーランスのエンジニアと進めるときは、この節目を契約の前に決めておきます。たとえば「2週間ごとに動くものを見せてもらい、6週間目に利用者に出す。出してから4週間分の数字で判断する」のように、見せる時期、出す時期、判断する時期を並べておきます。

DX実践手引書は、各サイクルで何が実現でき、何が実現できなかったのかを明確にしておくことも有用だとしています。節目ごとに、確かめたかったこと、出た数字、次に変えることを1枚にまとめて残しておくと、エンジニアが交代したときにも経緯を引き継げます。判断する人は社内の担当者に決め、節目の打ち合わせには欠かさず出てもらいます。

検証が終わったあとのコード

検証が終わると、MVPのコードをそのまま育てるのか、作り直すのかを決めることになります。DX実践手引書は、次に生かすものは必ずしも作った成果物（システム）ではないとしています。そのうえで、ソフトウェアを技術的負債（後から直す手間が残る作り）にしないために、得られた知見だけを生かして「作ったものを捨てる覚悟も時には必要である」と述べています。^*1

デジタル庁のガイドブックも、MVPが目的に合っていても将来に向けて技術的な「負の遺産」になると見込まれる場合には、MVPそのものを一度破棄して作り直すことがあり得るとしています。^*2

そこで、MVP開発を始める前に、捨てる前提で作るのか、育てる前提で作るのかをエンジニアに伝えておきます。捨てる前提なら速さを優先し、自動テストや設計書は最小限にとどめます。育てる前提なら、自動テスト、コードの書き方の決まり、設計の判断の記録にも時間を取ります。決めきれないときは捨てる前提で作り、育てると決めた機能だけを作り直す方法もあります。

コードを捨てても、残すものはあります。利用者の反応を記録したデータ、節目ごとの判断の記録、作ってみて分かった技術上の難しさです。検証を終えて本番のシステムにするときの体制は「外部人材活用のPoC（概念検証）を本番化するときの課題と体制」で扱っています。

コードの権利と引き継ぎ

育てる前提でも捨てる前提でも、コードの著作権を誰が持つかは始める前に決めておきます。IPAの「アジャイル開発外部委託モデル契約」は企業どうしの取引を想定した契約の雛形ですが、決めておく項目を洗い出すのに役立ちます。第17条は、開発の対象を「その一部又は未完成のものを含む」としたうえで、受託した側が新たに作った著作物の著作権の帰属を定めています。^*4 MVPのような途中の段階のものも対象になるということです。

原則とされているのは、発注した側に著作権を移す案です。個々の要求の完了が確認され、その作業の委託料が支払われた時点で移り、移す権利には著作権法第27条と第28条の権利（元の著作物を直したり、直したものを使ったりする権利）も含めます。ただし、受託した側が作った汎用的に使えるプログラムは受託した側に残り、もともと持っていた著作物も移りません。受託した側に残す案と、共有にする案も別案として示されています。^*4

フリーランスのエンジニアとの契約では、少なくとも3つの点を書いておきます。MVPのコードの著作権をどちらが持つか、エンジニアが以前から持っていたコードを使う場合に自社がどこまで使えるか、検証のあとで自社や別のエンジニアがコードを直して使えるかです。条文の書き方は、契約書を作る段階で弁護士などの専門家に確かめてください。

引き継ぎの資料も、始める前に決めておきます。モデル契約の第9条は、設計書などの文書を求めるなら、要求事項の一つとしてプロダクトバックログ（作る機能や作業の一覧）に加えるとしています。^*4 最後にまとめて頼むのではなく、作業の一つとして一覧に入れ、作る時間を取っておきます。コードの置き場所は自社が管理するアカウントにし、エンジニアにはそこへの権限を渡しておけば、契約が終わったあともコードが自社の手元に残ります。

つまずきやすい点

一つ目は、検証の途中で機能を足し続けることです。デジタル庁のガイドブックは、従来の開発に慣れた人が「最初に決めたものをすべて作る」という姿勢を貫こうとしてしまうことがあると指摘しています。^*2 利用者から要望が出るたびに機能を足していると、決めた節目に数字がそろいません。足したい機能は、次の節目の判断のあとに回します。

二つ目は、数字が出ても判断する人が決まっていないことです。エンジニアは数字を集める仕組みまでは作れますが、事業を続けるか、方向を変えるかは決められません。判断する人と判断する日は、MVP開発を始める前に決めておきます。

三つ目は、捨てる前提で作ったコードを、そのまま本番のシステムにしてしまうことです。育てると決めた時点で、どこを作り直すかをエンジニアと洗い出しておきます。

まとめ：MVP開発で確かめておきたい3つの点

新規事業のMVP開発をフリーランス活用で進めるうえで、確かめておきたい点は3つに整理できます。第一に、確かめる仮説を価値仮説か成長仮説かに絞り、成功条件を数字で書いておくこと。第二に、機能を外せない範囲、調整できる範囲、今は作らない範囲に分け、範囲の判断は社内に残すこと。第三に、コードを捨てる前提か育てる前提かを始める前に伝え、著作権と引き継ぎの資料の扱いを契約に書いておくことです。この3点を踏まえておけば、「作り終わったのに、何が分かったのかを誰も説明できない」という事態を避けやすくなります。MVP開発に加わってもらうエンジニアの探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA「DX実践手引書 ITシステム構築編 完成第1.1版」（PDF）（https://www.ipa.go.jp/digital/dx/hjuojm000000gx4n-att/000094497.pdf）。出典：独立行政法人情報処理推進機構「DX実践手引書 ITシステム構築編 完成第1.1版」。p.14（仮説と成功条件、各サイクルで実現できたこととできなかったことの明確化、作ったものを捨てる覚悟）、p.32（事業への落とし込み）、p.71（MVPの説明）、p.90（リリースされた機能の利用状況。原典はIPA「IPA/SECにおけるアジャイル開発に関する4年間の取組みから分かったこと」p.18、2012年12月）、p.96（リーン・スタートアップ）、p.115（B社の予約システムの事例）を参照（2026年9月確認）
2. *2　参考：デジタル庁「アジャイル開発実践ガイドブック」（DS-121）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/150a60b4/20220422_resources_standard_guidelines_guidebook_01.pdf）。出典：2021年3月30日決定（内閣官房情報通信技術（IT）総合戦略室）。2.4 3)（開発範囲にMVPの範囲を用意する）、3.3 4)（全体計画についての認識を合わせる）を参照（2026年9月確認）
3. *3　参考：IPA「デジタルスキル標準 DSS-P 分冊版 ビジネスアーキテクト編 ver.2.0」（PDF）（https://www.ipa.go.jp/jinzai/skill-standard/dss/rcu1hd000000j76k-att/sep_dss-p_ba.pdf）。出典：独立行政法人情報処理推進機構（2026年4月）。第Ⅲ部第2章 ビジネス変革｜プロダクトのマネジメント（p.24）のスキル項目「プロダクトスコープと優先順位のマネジメント」「仮説検証・学習サイクル設計」を参照（2026年9月確認）
4. *4　参考：IPA「アジャイル開発外部委託モデル契約（解説付き）」（PDF）（https://www.ipa.go.jp/digital/model/ug65p90000001ldr-att/000081484.pdf）。出典：独立行政法人情報処理推進機構「情報システム・モデル取引・契約書（アジャイル開発版）」のうち、アジャイル開発外部委託モデル契約（2025年4月8日更新）。第9条（文書作成）、第17条（著作権の帰属）とその別案・解説、第19条（FOSSの利用）を参照（2026年9月確認）

Tweet