プラットフォーム開発とは？失敗しない進め方と費用、開発会社の選び方

本業の知見を生かしてマッチングや受発注のようなプラットフォーム型のサービスを立ち上げたいものの、何から始め、いくらかかり、どこに頼めばよいのか分からない。
「プラットフォーム 開発」で調べても技術用語の解説が多く、事業として作る人向けの情報は見つけにくいものです。

この記事では、事業としてのプラットフォーム開発の意味と普通のアプリ開発との違い、参加者が集まらない失敗を防ぐ「確かめてから作る」進め方を解説します。
作る・使うの判断、機能と開発手法、費用と期間、開発会社の選び方まで、社内説明に使える形で整理しました。

運営するEPICsは、「欲しい人がいるか」の検証から、MVP（必要最小限の機能で作る最初の製品）の開発、本格開発・拡大までを1社で担う受託開発会社です。
250件以上の開発実績があります（出典：EPICs「新規事業のためのアプリ・システム受託開発サービス」／EPICs「アプリ・システム受託開発」）。

プラットフォーム開発とは？普通のアプリ開発と何が違う？

プラットフォーム開発（プラットフォーム構築）とは、商品やサービスを提供する側と利用する側をつなぐ「場」を、Webサービスやアプリとして作ることです。
法律でも、デジタルプラットフォームは、商品やサービスを提供しようとする者の情報を表示する「場」を、インターネットを通じて多数の者に提供するものと定義されています（出典：特定デジタルプラットフォームの透明性及び公正性の向上に関する法律 第2条）。

なお、IT分野では、アプリが動く土台となるOSや開発ツールを「開発プラットフォーム」と呼ぶことがあり、複数のOSで動くアプリを作る「クロスプラットフォーム開発」も、技術の分野の言葉です。
この記事では、こうした技術の話ではなく、事業としてのプラットフォームを作る話に絞って解説します。

ここからは、プラットフォームの仕組みと普通のアプリとの違いを、次の3点で説明します。

• 運営者・提供する側・利用する側の三者で成り立つ
• 参加者が増えるほど価値が上がる仕組みを持つ
• 普通のアプリとの違いは、両方の参加者を集める必要があること

運営者・提供する側・利用する側の三者で成り立つ

プラットフォームは、場を用意してルールを決める運営者と、商品やサービスを提供する側、それを利用する側の三者で成り立ちます。
運営者は、自社で商品を売るわけではありません。
両者が出会い、やり取りし、取引できる仕組みを用意したうえで、誰がどんな条件で参加できるかというルールを決める役割を担います。
運営者が用意する仕組みは、提供する側の情報の掲載、利用する側の検索、両者の連絡、代金の決済、取引後の評価などです。

運営者の収益は、場を提供する対価として、成約したときの手数料、掲載料、月額の利用料などで得る形が一般的とされています。

本業を持つ企業の場合、取引先や顧客として、提供する側か利用する側のどちらかをすでに抱えていることが多くあります。
自社がどちらの側をすでに持っているかを意識しておくと、後の章で解説する「作り込む前に確かめること」の進め方を、自社に当てはめて考えやすくなるはずです。

参加者が増えるほど価値が上がる仕組みを持つ

プラットフォームには、参加者が増えるほど価値が上がる仕組みがあります。
提供する側が増えるほど利用する側にとって選択肢が広がって便利になり、利用する側が増えるほど提供する側にとっても魅力が増す、という循環で価値が大きくなるためです。
総務省の『令和7年版 情報通信白書』は、ユーザーが増えるほどサービスの価値が高まるこの性質を「ネットワーク効果」と説明しています（出典：総務省『令和7年版 情報通信白書』「プラットフォーム事業者の成長とその背景」）。

特定デジタルプラットフォームの透明性及び公正性の向上に関する法律も、提供する側が増えると利用する側の便益が増し、それによって提供する側がさらに増えるという関係を、デジタルプラットフォームの条件の1つにしています（出典：同法 第2条）。
たとえば求人サービスなら、掲載する企業が多いほど仕事を探す人が集まり、仕事を探す人が多いほど企業も掲載したくなる、という関係です。

普通のアプリとの違いは、両方の参加者を集める必要があること

普通のアプリとの最大の違いは、提供する側と利用する側の両方を集めなければ、サービスとして成り立たない点です。
自社の商品やサービスを顧客に届ける普通のアプリは、自社が中身を用意すれば、集める相手は顧客の1種類で済みます。
一方でプラットフォームは、中身を用意するのが提供する側です。
提供する側と利用する側がそろわない限り、利用する価値が生まれません。

予約の仕組みを例に、普通のアプリとプラットフォームを比べると次のとおりです。

比べる点	普通のアプリ（例：自社の予約アプリ）	プラットフォーム（例：店舗と利用者をつなぐ予約サービス）
集める相手	顧客のみ	提供する側と利用する側の両方
中身を用意するのは誰か	自社	提供する側（店舗）
運営に必要なこと	自社サービスの更新	場のルールづくり（参加の審査、トラブル対応、評価の管理）
収益の取り方	商品やサービスの販売 利用料	成約の手数料 掲載料 月額の利用料

プラットフォームは、作っただけでは提供する側も利用する側もそろわないため、「作っても人が集まらない」という特有の失敗が起きやすくなります。
その理由は、後の章「なぜプラットフォーム開発は失敗しやすいのか？」で詳しく見ていきましょう。

事業として作れるプラットフォームの種類と例

事業として作るプラットフォーム（プラットフォームビジネス）は、「何と何をつなぐか」で4つの型に分けると、自社の構想を当てはめやすくなります。
4つの型と、つなぐ相手・身近な例・主な収益の取り方を一覧にすると次のとおりです。

型	つなぐ相手	身近な例	主な収益の取り方
マッチング型	人と人 人と仕事	業務委託 スキルシェア 家事代行 求人	成約手数料 掲載料
マーケットプレイス型	売り手と買い手	フリマ ECモール	販売手数料 出店料
受発注型	発注企業と受注企業	業界内の調達や手配	手数料 月額利用料
コミュニティ・配信型	参加者同士 作り手と視聴者	会員コミュニティ オンライン講座 動画配信	月額会費 都度課金 広告

ただし、型はいつもきれいに分かれるとは限りません。
実際には、1つのサービスに複数の型が混ざっていることも多いものです。

人と人、人と仕事をつなぐ「マッチング型」

マッチング型は、仕事やスキル、場所などを提供したい人と、それを求める人を条件で引き合わせるプラットフォームです。
業務委託や求人、講師と生徒などが代表的で、地域・スキル・日時といった条件で相手を探し、連絡を取り合って成約する流れが中心になります。

売り手と買い手が取引する「マーケットプレイス型」

マーケットプレイス型は、多くの売り手が商品を出品し、買い手が選んで購入する「売買の場」を運営するプラットフォームです。
フリマやECモール（多くの店が出店するネット上の商店街）が代表的で、出品の審査や決済、評価など、取引を安心して成立させる機能が中心になります。
なお、自社の商品だけを売る通販サイトは、売り手が自社1社のため、プラットフォームには当たりません。

企業同士の発注と受注をつなぐ「受発注型」

受発注型は、仕事や部材を頼みたい企業と、それを請け負う企業をつなぐ、企業同士（BtoB）のプラットフォームです。
見積もりや発注、納期の管理、請求といった取引の手続きを、場の中で進められる機能が中心。
業界ごとの取引の慣習に合わせる必要があり、業界の事情を知る企業が作ると強みが出やすくなります。

交流や発信の場をつくる「コミュニティ・配信型」

コミュニティ・配信型は、共通の関心を持つ人同士の交流や、作り手が届けるコンテンツを楽しむ場を運営するプラットフォームです。
会員コミュニティやSNS、オンライン講座、動画配信などが代表的な例。
売買や成約ではなく、参加を続けてもらうこと自体が月額会費などの収益につながる点が、ほかの型との違いです。

本業の取引先や顧客がいる型から考える

本業を持つ企業がプラットフォームを考えるなら、取引先や顧客をすでに持っている側がある型から選ぶと、最初の参加者を集めやすくなります。
プラットフォームは、提供する側と利用する側の両方がそろって初めて価値が出る仕組みです。
そのため、どちらか一方を本業ですでに抱えていることが、立ち上げの足がかりになります。

当社が開発した例に、医療機器の販売や、フリーランスの看護師とクリニックのマッチングなどを手がける株式会社ライズ様からご依頼いただいた、クリニックと看護師のマッチングアプリ『JNAC』があります。
エリアやスキルなどで検索でき、仕事の依頼をチャットですり合わせてから、契約書の送付、業務の終了報告までをアプリの中で進められる仕組みです（出典：クリニックと看護師のマッチングアプリ『JNAC』）。
本業で手がけてきた看護師とクリニックのマッチングを、アプリの形にした例といえます。

なぜプラットフォーム開発は失敗しやすいのか？

プラットフォーム開発が失敗しやすいのは、システムを作り終えても、両方の参加者が集まって取引が続く状態にならなければ、事業として成り立たないからです。
参加者が増えるほど価値が上がる「ネットワーク効果」は、裏を返せば、参加者が少ないうちは価値が出にくいということでもあります（出典：総務省『令和7年版 情報通信白書』「プラットフォーム事業者の成長とその背景」）。

失敗の主な原因は、次の3つです。

• 提供する側と利用する側が、互いを待って集まらない
• 需要を確かめる前に作り込み、予算を使い切ってしまう
• 審査やトラブル対応など、運営の負担を後から知る

提供する側と利用する側が、互いを待って集まらない

最初にぶつかりやすい壁は、提供する側と利用する側が互いの参加を待ち、どちらも集まらないことです。
提供する側は「利用する人が多いなら参加する」、利用する側は「選択肢が多いなら使う」と考えます。
参加者が多いほど価値が上がる仕組みのため、公開直後で参加者がいない状態では、どちらの側にとっても参加する理由が弱いのです。

総務省の『令和7年版 情報通信白書』も、ネットワーク効果などの特性を生かして先に市場を得た事業者が、競争で優位に立ちやすいと説明しています（出典：総務省『令和7年版 情報通信白書』「プラットフォーム事業者の成長とその背景」）。
そのため、後から始める事業者ほど、最初の参加者をどう集めるかが大きな課題です。

たとえば求人サービスでは、求人が少ないと仕事を探す人が来ず、仕事を探す人がいないと企業も求人を載せません。
この壁は、システムの出来が良いだけでは解消できない点に注意が必要です。

需要を確かめる前に作り込み、予算を使い切ってしまう

2つ目の失敗は、本当に使いたい人がいるかを確かめる前に機能をそろえて作り込み、公開後に方向を変える予算が残っていないことです。
プラットフォームは、運営者・提供する側・利用する側の三者分の画面に加えて、検索・連絡・決済・評価など、必要な機能が多くなりがち。
すべてをそろえてから公開しようとすれば、そのぶん費用も期間もふくらみます。

新規事業の開発では、時間と費用をかけて機能の整ったサービスを完成させたものの、公開してみると欲しい人がほとんどいなかった、というのがよくある失敗の1つです。
最初から作り込んだ結果、顧客のニーズとずれていると分かっても、軌道修正のための追加開発に回す予算が残っていなかった、という例もあります（出典：EPICs「新規事業のためのアプリ・システム受託開発サービス」）。

プラットフォームを立ち上げるときは、最初に開発費を使い切らず、検証と改善に回す予算を残しておく考え方が欠かせません。
具体的な進め方は、次の章で解説します。

審査やトラブル対応など、運営の負担を後から知る

3つ目の失敗は、参加者の審査やトラブル対応、利用規約の整備といった運営の負担を、作った後に初めて知ることです。
総務省が紹介しているアンケートでは、シェアリングサービスを使う際に確保されているべきものとして、事業者による保証や介入の仕組みを挙げた回答が最も多くなっています（出典：総務省「シェアリングエコノミーの進展ともたらされる変化」）。
知らない人同士が取引する場だからこそ、利用する側は、運営する事業者がどこまで関わってくれるかを重視するということです。

運営の仕組みとして必要になるのは、たとえば次のようなものです。

• 本人確認や、出品・登録の審査
• 利用者同士のトラブルの仲裁
• 不正な利用への対応
• 問い合わせの窓口

審査や仲裁などの運営の仕組みを開発の範囲に含めていないと、公開後にすべてを人手で回すことになり、運営を続けられなくなるおそれがあります。

なお、サービスによっては、届出などの法令の確認も必要です。
こちらは次の章で取り上げます。

作り込む前に確かめること：小さく検証してから広げる進め方

プラットフォーム開発は一度に作り切らず、段階ごとに確かめる問いと作るものを決め、両方の参加者の反応を見ながら少しずつ広げると失敗を避けやすくなります。
新規事業の進め方を5つの段階に分けた例を、プラットフォームに当てはめると次のとおりです（出典：EPICs「新規事業のためのアプリ・システム受託開発サービス」）。

段階	確かめる問い	作るもの（例）
1. 課題と市場の検証	提供する側と利用する側の両方に困りごとがあり、お金を払う側がいるか	サービスの説明ページ 事前登録 聞き取り
2. 解決策の検証	場をつくれば、その困りごとが解決しそうか	画面のたたき台 手作業を組み合わせた試行
3. プロダクトの検証	最小限の機能で、実際に取引や成約が起きるか	反応の計測を組み込んだMVP
4. 市場適合の検証	繰り返し使われ、参加者が増え続けるか	改善したサービス 利用データの分析
5. 拡大の検証	収益化と拡大ができるか	機能の拡張と作り込み

この進め方で、特に押さえておきたい点は次の5つです。

• 提供する側と利用する側、両方の困りごとを確かめる
• どちらの側から先に集めるかを決めておく
• 範囲と機能を絞ったMVPで、取引が起きるかを試す
• 段階ごとに「進む・変える・止める」を判断する
• 届出が必要なサービスか、着手前に確かめる

提供する側と利用する側、両方の困りごとを確かめる

最初に確かめるべきなのは機能ではなく、提供する側と利用する側の両方に、場を使ってでも解決したい困りごとがあるかです。
あわせて、どちらの側がお金を払うのかも確かめておきます。
片方の困りごとだけを確かめて作ると、もう片方には参加する理由がなく、互いを待ったまま、どちらも集まらない状態になりかねません。

確かめ方には、たとえば次のような方法があります。

• 両側それぞれ数人ずつに、今のやり方と不満を聞く
• サービスの説明ページを作って事前登録を募り、両側の登録の集まり方を比べる

課題と市場の検証の段階は、システムを作らなくても確かめられることが多いのが特徴です。

どちらの側から先に集めるかを決めておく

公開する前に、どちらの側を先に集め、最初の参加者をどうそろえるかを決めておきます。
両側を同時に集めようとすると、どちらにも参加する理由が弱いまま公開することになるためです。
新規事業の進め方でも、最初の課題と市場の検証の段階から、テストユーザーの集め方を考えておくことが勧められています（出典：EPICs「新規事業のためのアプリ・システム受託開発サービス」）。

最初の参加者のそろえ方には、たとえば次のような方法があります。

• 本業の取引先や顧客など、すでにつながりのある側から先に参加してもらう
• 地域や業種を絞り、狭い範囲で両側をそろえる
• 最初は運営者が手作業で仲介し、取引が成立する手応えを先に得る

最初の参加者のそろえ方は、どの方法が合うかが事業によって異なるため、自社の状況に合わせた選択が必要です。

範囲と機能を絞ったMVPで、取引が起きるかを試す

困りごとと集め方が見えたら、取引が実際に起きるかを確かめるため、MVP（必要最小限の機能で作る最初の製品）を作ります。
最初は、「登録する・探す・連絡する・成約する」という取引の流れが一通り動けば十分です。
評価や高度な検索などの機能は、参加者の反応を見てから足していきます。

決済や審査の一部は、最初は運営者の手作業や外部のサービスで補う方法もあります。
作り込みを後に回すことで、反応を見て方向を変えるための予算を残しておける点が利点です。
どこまでを最初に作るかの考え方は、後の章「最初に作る機能と、開発手法の選び方」で詳しく解説します。

段階ごとに「進む・変える・止める」を判断する

各段階の終わりには、事前に決めた基準で「進む・変える・止める」を判断します。
段階ごとに判断することで、開発費の総額を一度に投じずに済み、うまくいかなかったときの損失も小さく抑えられるからです（出典：EPICs「新規事業のためのアプリ・システム受託開発サービス」）。

判断の基準には、事前登録の集まり方、成約の件数、繰り返し使われているかなどがあり、段階の目的に合わせて決めておきます。
止めるという判断も失敗ではなく、損失を抑えるための選択肢の1つです。
この判断の仕方は、社長や役員会に進め方を説明するときの材料にもなります。

届出が必要なサービスか、着手前に確かめる

サービスの内容によっては事業の開始前に届出や登録が必要になるため、作り始める前に確かめておきます。
必要な場合は、その手続きを開発の範囲や公開の時期に組み込んでおくと安心です。

届出や登録が関わる例には、次のようなものがあります。

• 異性との出会いを目的とする紹介サービス：インターネット異性紹介事業を利用して児童を誘引する行為の規制等に関する法律により、事務所の所在地を管轄する警察署長を経由して、公安委員会への届出が必要です（出典：島根県警察「インターネット異性紹介事業」）
• 求人情報を提供し、会員登録などで仕事を探す人の情報を集めるサービス：令和4年10月1日施行の改正職業安定法により、厚生労働大臣への届出が必要になる場合があります（出典：東京労働局「募集情報等提供事業の運営ルールが変わりました!!」）
• 利用者同士の代金を運営者がいったん預かって受け渡す仕組み：内容によっては為替取引（離れた相手にお金を移すこと）にあたり、資金移動業（銀行以外の事業者が送金を扱う業務）の登録が必要になる場合があります。
  金融庁の審議会の資料では、2020年の資金決済法の改正で、受け取る側が個人である一部の収納代行（代金の受け取りを代わりに行うこと）が為替取引にあたると明示されたことが紹介されています（出典：金融庁 金融審議会「資金決済制度等に関するワーキング・グループ」第4回 事務局説明資料）

ここに挙げた届出や登録は一例です。
該当するかどうかは事業の内容によって変わるため、所管の官庁や専門家に事前に確認してください。

自社でプラットフォームを作るべきか？既存サービスとの比べ方

プラットフォーム型の事業の始め方は、自社で開発する、既存のプラットフォームを使う、既製のパッケージを使うの3つです。
どれが合うかは、何を自社の強みにしたいかで決まります。
3つの始め方の性質を比べると、次のとおりです。

選択肢	始めやすさ	ルールや機能の自由度	顧客データの扱い	向いているケース
既存のプラットフォームに出店・掲載する	すぐ始められる	運営者のルールに従う	運営者側に集まる	まず販路や反応を試したい
既製のパッケージを使う	比較的早く始められる	パッケージの範囲内	自社で持てる	一般的な仕組みで足りる
自社で開発する	検証から段階を踏む必要がある	自社で決められる	自社で持てる	独自の取引の仕組みや本業との連携が強みになる

3つの始め方は、どれが優れているかではなく、事業の段階や目的に合うかどうかで選ぶのが基本です。
検証の段階では既存の場や手作業で試し、手応えを得てから自社で開発する、という組み合わせ方もあります。

既存のプラットフォームは早いが、ルールは相手が決める

すでに利用者が集まっているプラットフォームに出店・掲載すれば早く始められますが、手数料や規約などのルールは運営者が決めます。
自社で開発する費用を抑えられ、最初の集客もしやすい点は利点です。
一方で、機能やデザインを変えられる範囲は限られ、運営者が仕様や規約を変えれば、それに合わせる必要があります（出典：KDDI「プラットフォームとは？ IT用語としての意味と活用するメリット」）。

国も、デジタルプラットフォームと、それを使う事業者との取引条件の透明性と公正性を高めるため、特定デジタルプラットフォームの透明性及び公正性の向上に関する法律を定めました（出典：経済産業省「デジタルプラットフォーム取引透明化法」）。

既存のプラットフォームに出店・掲載する方法は、自社の商品やサービスの販路をまず広げたい場合や、需要があるかを手早く試したい場合に向いています。
ただし、自社が「場」を持つことにはならない点に注意が必要です。

既製のパッケージは手早いが、独自の仕組みは作りにくい

既製のパッケージを使えば自社の場を比較的早く持てますが、独自の取引の流れや本業のシステムとの連携は作りにくいことがあります。
マッチングサイトやECモールなどを作るためのパッケージは、用意されたひな型や設定の範囲内で運営する仕組みです。
そのため、範囲を超える独自のデザインや機能には、制約が出やすくなります。

既製のパッケージは、一般的な「登録・掲載・問い合わせ」で足りる事業なら、有力な選択肢です。
反対に、業界特有の見積もりや契約の流れ、独自の審査が必要な事業では、カスタマイズの費用がかさんだり、実現できなかったりすることがあります。

自社で開発すると、顧客データと独自のルールを持てる

自社で開発する最大のメリットは、参加者や取引のデータを自社で持ち、手数料や参加の条件などのルールを自社で決められることです。
取引の流れを自社に合わせて作れるうえ、本業の業務やシステムとつなげられる点も強み。
総務省の『令和7年版 情報通信白書』も、海外の大手プラットフォーム事業者が、収集したデータなどを活用して急速に成長したと説明しています（出典：総務省『令和7年版 情報通信白書』「プラットフォーム事業者の成長とその背景」）。

一方で、最初の参加者を集めることや、審査やトラブル対応などの運営、公開後の改善や保守は、自社で担う必要があります。
そのため、前の章「作り込む前に確かめること」で解説したように、段階を踏んで確かめながら進めることが前提です。
費用の考え方は、後の章「プラットフォーム開発の費用と期間の目安は？」で解説します。

強みにしたい部分があるなら作り、なければ使う

競合と差を付けたい独自の部分があるなら自社で開発し、一般的な仕組みで足りるなら既存のサービスを使う方が合理的です。
判断の目安として、次の点に当てはまるかを確かめます。

• 取引の流れが、業界独自のものか
• 参加の審査や契約に、独自のルールが必要か
• 本業のシステムや顧客情報とつなぎたいか
• 集まるデータを、自社の事業に生かしたいか

判断の目安のどれにも当てはまらないなら、自社で作らない選択も十分にありえる判断です。
自社で作ると決めた場合に、何をどの手法で作るかは次の章で解説します。

最初に作る機能と、開発手法の選び方

自社で開発すると決めたら、必要な機能の全体像をつかんだうえで、最初に作る範囲を絞り、段階に合った開発手法を選びます。
ここで説明するのは、次の4つです。

• 機能の全体像
• 最初に作る範囲
• 3つの開発手法
• 段階に合わせた手法の選び方

機能は参加者の画面と運営者の管理画面に分かれる

プラットフォームの機能は、提供する側の画面、利用する側の画面、運営者が使う管理画面の3つに分かれます。
参加者が1種類の普通のアプリに比べて、作るものが多くなる点が特徴です。
画面ごとの主な機能の例を、次の表にまとめました。

画面	主な機能の例
提供する側の画面	登録 プロフィールや商品の掲載 問い合わせへの返信 受注や予定の管理 売上の確認
利用する側の画面	登録 検索 詳細の閲覧 問い合わせやチャット 申し込みや購入 評価
運営者の管理画面	会員の管理 登録や掲載の審査 通報やトラブルへの対応 お知らせの配信 取引と手数料の管理
共通	決済 通知 本人確認

運営者の管理画面は見落とされやすいものの、作る範囲に最初から含めて考えておく必要があります。
総務省が紹介しているとおり、利用者はサービス事業者による保証や介入の仕組みを重視しているためです（出典：総務省「シェアリングエコノミーの進展ともたらされる変化」）。

最初は取引の流れに必要な機能だけに絞る

最初のMVPは、登録から成約までの取引の流れが一通り動く機能と、最低限の会員管理・審査に絞ります。
最初の段階で確かめたいのは、取引が起きるかどうかです。
機能を増やすほど費用と期間がかかり、反応を見て方向を変えにくくなります（出典：EPICs「新規事業のためのアプリ・システム受託開発サービス」）。

区分	機能の例
最初から作る機能	登録 掲載 探す 連絡する 成約する 最低限の会員管理と審査
反応を見てから足す機能	評価 高度な検索やおすすめ表示 スマートフォンアプリ化

決済は、最初は外部の決済サービスを組み込む、手作業で補うといった方法もあります。
対応する端末も、まずWebで始め、iOS・Androidのアプリにするかは利用の状況を見てから判断する、という進め方も1つの選択肢です。

開発手法はノーコード・AI駆動開発・スクラッチの3つ

プラットフォームを作る手法には、大きくノーコード、AI駆動開発、スクラッチの3つがあります。
ノーコードはプログラムを書かずに専用のツールで作る方法、AI駆動開発はAIにプログラムの作成を支援させながら作る方法、スクラッチはプログラムを一から書いて作る方法です。
速さ・作り直しやすさ・自由度・拡張性のどれを重視するかで、向き不向きが分かれます。

手法	向いていること	注意点
ノーコード	画面や機能を早く作り、作り直しやすい	ツールの機能や料金体系の範囲に左右される 独自の複雑な処理や大規模な利用では、限界が出ることがある
AI駆動開発	プログラムを書く作業を速められる 文書の処理や要約など、AIを組み込む機能とも相性がよい	品質は、開発チームの確認と設計に左右される
スクラッチ	自由度と拡張性が高く、長く使う基盤に向く	期間と費用がかかりやすい

検証は作り直しやすい手法、本格化は作り込める手法で

開発手法は1つに決め打ちせず、検証の段階は作り直しやすい手法、本格化の段階は作り込める手法を選ぶと、無駄な作り込みを避けられます。
検証の段階は方向を変える可能性が高く、作り直しやすさが重要です。
一方、参加者が増えて事業として続ける段階では、拡張に耐え、資産として作り込めることが重みを増します（出典：EPICs「新規事業のためのアプリ・システム受託開発サービス」）。

1つのサービスの中でも、機能ごとに手法を使い分けられます。
たとえば、検証の段階で作った機能のうち、よく使われたものを本格化の段階でスクラッチに移す、といった形です。

注意したいのは、段階が変わるたびに開発会社を乗り換えると、仕様の引き継ぎに手間がかかる点です。
複数の手法に対応できるか、途中で手法を移せるかは、依頼する前に確認しておきましょう。

プラットフォーム開発の費用と期間の目安は？

プラットフォーム開発の費用と開発期間は、作る機能の量と段階で大きく変わるため、何で決まるかを押さえて段階ごとに区切って見積もると判断しやすくなります。
ここで説明するのは、次の3点です。

• 費用と期間が変わる要因
• 段階ごとの区切り方
• 公開後にかかる費用

費用と期間は、参加者の種類・決済・端末・運営機能で変わる

費用と期間を大きく左右するのは、参加者の種類の数、決済の有無、対応する端末、運営者の機能の量の4つです。
それぞれ、次のような場合に費用と期間が増えやすくなります。

要因	費用と期間が増えやすい場合
参加者の種類	提供する側・利用する側に加え、法人と個人など複数の立場があり、画面と権限が増える
決済	利用者同士の代金の受け渡しを行う 手数料を自動で計算する 届出や登録の確認も関わる
対応する端末	Webに加えて、iOS・Androidのアプリも作る アプリの公開には、各ストアの審査がある
運営者の機能	審査・通報対応・売上や手数料の管理などを、手作業ではなくシステムで行う

前の章「最初に作る機能と、開発手法の選び方」で解説したように、最初は取引の流れに必要な機能だけに絞れば、最初にかかる費用と期間を抑えられます。

段階ごとに区切って見積もると、総額を一度に負担せずに済む

「作り込む前に確かめること」の章で紹介した段階ごとに見積もりと判断を区切れば、総額を最初に負担せずに済み、手応えがなければ途中で止められます。
段階ごとの費用の一例として、本記事を運営するEPICsが公開している目安は次のとおりです。

段階	費用の目安
現在地の判定・ロードマップの提案	無料
課題と市場の検証	50万円〜
解決策の検証	50万円〜
MVP開発	150万円〜
市場適合・拡大	規模に応じて個別に見積もり

表の金額はいずれも「〜」の付いた下限の目安で、実際の金額は機能や規模によって変わります。
大切なのは金額そのものより、段階ごとに区切ることで、次へ進むかをその都度判断できる点です。

出典：EPICs「新規事業のためのアプリ・システム受託開発サービス」

公開後の運営と改善の費用も、最初から見込んでおく

プラットフォームは公開してからが事業の本番のため、公開後の運営と改善の費用も最初から予算に入れておきます。
開発費とは別にかかる主な費用は、次のとおりです。

• サーバーや外部サービスの利用料
• 決済サービスの手数料
• 保守やセキュリティ対応などの運用
• 参加者の反応を見た改善と追加開発
• 審査や問い合わせ対応など、運営にかかる人件費
• 両側の参加者を集めるための集客

開発費で予算を使い切ると、公開後に反応を見て直すことができません。
検証と改善に回す予算を残しておくことが、作っても続かないという失敗を防ぐ備えになります。

プラットフォーム開発を任せる開発会社の選び方

プラットフォーム開発の依頼先は、見積もりの金額だけでなく、作る前の検証から公開後の改善まで一緒に考えられるかで選びます。
プラットフォームの失敗の多くは、システムの出来ではなく、参加者が集まらない、作り込みすぎる、運営が回らないことから起きるためです。
開発だけでなく、事業の立ち上げに関わる部分まで相談できるかが、結果を左右します。

まずは、公開されている開発事例で、マッチングや売買などプラットフォーム型の開発経験があるかを確かめておきましょう。
マッチングアプリの開発を手がける会社を比べたい場合は、マッチングアプリに強い開発会社を紹介した記事も参考になります。

そのうえで確かめたい観点は、次の4つです。

• 作る前の検証から一緒に考えてくれるか
• 参加者の集め方と運営の仕組みまで相談できるか
• 段階に合わせて開発手法を変えられるか
• 公開後の改善と、コード・データの引き渡しまで任せられるか

作る前の検証から一緒に考えてくれるか

構想をそのまま見積もるだけでなく、最初に何を確かめるべきかから提案してくれる会社かを確かめます。
最初の課題と市場の検証は、システムを作らずに進められることも多い段階です。
ここを飛ばして作り始めると、作り込みすぎの失敗につながりかねません。

相談の場では、たとえば次のように聞いてみてください。

• 「この構想で、最初に確かめるべきことは何ですか」
• 「最初の段階では、どこまでを作り、どこを作らずに確かめますか」

質問への開発会社の答えが機能の一覧と金額だけか、確かめる順番まで示されるかで、会社ごとの違いが分かります。

参加者の集め方と運営の仕組みまで相談できるか

システムの機能だけでなく、参加者の集め方や運営の回し方まで相談できる会社かを確かめます。
両側の参加者をどう集めるか、審査やトラブル対応をどう回すか、届出が必要かといった論点は、プラットフォームならではのものです。
利用者は事業者による保証や介入を重視するとされ、運営者の機能は見落とされやすい部分でもあります（出典：総務省「シェアリングエコノミーの進展ともたらされる変化」）。

確かめるための質問の例は、次のとおりです。

• 「最初の参加者をどう集めるか、過去の進め方を教えてください」
• 「運営者の管理画面では、どこまでをシステムにし、どこを手作業にしますか」

なお、届出が必要かどうかの最終的な判断は、開発会社ではなく、所管の官庁や専門家に確認するものです。

段階に合わせて開発手法を変えられるか

検証から本格化へ進むときに作り直しや会社の乗り換えが起きないよう、段階に合わせて開発手法を切り替えられる会社かを確かめます。
検証の段階は作り直しやすい手法、本格化の段階は作り込める手法が向いており、途中で手法を移すこともあるためです。
1つの手法しか扱わない会社では、手法を移す段階で別の会社に頼み直すことになり、仕様や経緯の引き継ぎに手間がかかります。

次のように聞くと、手法の切り替えへの対応が分かります。

• 「検証で作ったものを、本格化の段階ではどう扱いますか」
• 「途中で開発手法を変える場合、どこまで引き継げますか」

公開後の改善と、コード・データの引き渡しまで確かめる

公開後の改善を続けて担ってくれるかと、コードやデータを引き渡してもらえるかを、契約の前に確かめます。
プラットフォームは公開後も参加者の反応を見て改善を続ける事業のため、開発会社との関係が長くなりがち。
将来ほかの会社に移すことになった場合に備えて、プログラムのコードやデータ、設計の資料を引き渡してもらえるかも確かめておく必要があります。

コードやデータの所有権の扱いと、資料が整っているかどうかは、別の会社へ移すときの移しやすさを左右する要素です（出典：EPICs「業務改善のためのアプリ・システム受託開発サービス」）。

契約の内容を考えるときは、IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」も参考になります。
発注する側と開発会社のどちらかに有利に偏らないことを目指して作られた、契約書のひな型です（出典：IPA「情報システム・モデル取引・契約書（第二版）」）。

契約の前には、次の2点を聞いておきましょう。

• 「公開後の改善や追加開発は、どのような体制と契約で続けられますか」
• 「コード・データ・設計資料は、こちらに引き渡してもらえますか」

新規事業のプラットフォーム開発ならEPICs

EPICsは、プラットフォームのような新規事業を、需要の検証から本格開発・拡大まで1社で支える受託開発会社です。
これまでの開発実績は250件以上。
作ったのに参加者が集まらない事態を防ぐため、この記事で解説した「確かめてから作る」進め方で伴走しています。

着手前に現在地とこの先のロードマップを共有し、段階ごとに確かめる問いと作るものを決めます。
各段階の終わりに「進む・変える・止める」を判断でき、一発勝負を避けられる進め方です。
現在地の判定とロードマップの提案は、無料で行っています。

開発手法は、ノーコード・AI駆動開発・スクラッチを、段階や機能ごとに使い分けます。
1つの手法に縛られないため、検証から本格化へ進んでも、開発会社を乗り換えずに手法を切り替えられるのが特長です。

作った後も、定期的な振り返りで、利用データをもとに「続ける・変える・止める」の選択肢を示し、改善や追加開発まで伴走します。

社内にマーケターがいるため、開発に閉じず事業の視点で提案できる点も強み。
オプションでテストユーザーの集客支援と顧客インタビュー支援も行っており、開発だけのご依頼も受けています。

まずは作りたいサービスの構想と今の状況を整理し、どこから確かめるかを決めることから始めてみてください。

出典：EPICs「新規事業のためのアプリ・システム受託開発サービス」／EPICs「アプリ・システム受託開発」

プラットフォーム開発の費用はどのくらいかかりますか？

プラットフォーム開発の費用は、作る機能の量と段階で大きく変わります。一例として、本記事を運営するEPICsが公開している目安では、課題と市場の検証と解決策の検証が各50万円〜、MVP（必要最小限の機能で作る最初の製品）の開発が150万円〜です。いずれも下限の目安で、実際の金額は参加者の種類の数、決済の有無、対応する端末、運営者の機能の量しだい。一律の相場で判断するより、段階ごとに区切って見積もる方が、総額を最初に負担せずに済み、手応えがなければ途中で止められるため判断しやすくなります。開発費とは別に、外部サービスの利用料や保守、改善、運営の人件費、集客といった公開後の費用も、最初から見込んでおくことが大切です。

なぜプラットフォームは、作っても参加者が集まらないことがあるのですか？

提供する側と利用する側が、互いの参加を待ってしまうからです。プラットフォームは参加者が増えるほど価値が上がる一方、公開直後は参加者が少ないため、提供する側は「利用する人が多いなら参加する」、利用する側は「選択肢が多いなら使う」と考えてしまい、どちらも集まらない状態になりやすくなります。この状態は、システムの出来が良いだけでは解消できません。そのため、公開前に両方の困りごとを確かめたうえで、本業の取引先など一方の側から先に集める、地域や業種を絞って両側をそろえるといった、最初の参加者の集め方を決めておくことが大切です。

マッチングサービスや求人サイトを作るとき、届出は必要ですか？

サービスの内容によっては必要になります。異性との出会いを目的とする紹介サービスは、事務所の所在地を管轄する警察署長を経由して、公安委員会への届出が必要です。求人情報を提供し、会員登録などで仕事を探す人の情報を集めるサービスは、改正職業安定法により、厚生労働大臣への届出が必要になる場合があります。利用者同士の代金を運営者がいったん預かって受け渡す仕組みも、内容によっては資金移動業の登録が必要になる場合があり、注意が必要です。該当するかどうかは事業の内容によって変わるため、作り始める前に、所管の官庁や専門家に確認してください。

本業がある会社は、どんな型のプラットフォームから始めるとよいですか？

提供する側か利用する側のどちらかを、本業の取引先や顧客としてすでに持っている型から選ぶと、最初の参加者を集めやすくなります。プラットフォームは、提供する側と利用する側の両方がそろって初めて価値が出る仕組みです。そのため、どちらか一方を本業ですでに抱えていることが、立ち上げの足がかりになります。たとえば、医療機器の販売やフリーランスの看護師とクリニックのマッチングを手がける企業が作った、クリニックと看護師をつなぐマッチングアプリがその例です。本業で手がけてきたマッチングを、アプリの形にしたものといえます。

プラットフォーム開発を依頼する会社は、何を基準に選べばよいですか？

見積もりの金額や速さだけでなく、作る前の検証から公開後の改善まで、一緒に考えられるかで選びます。プラットフォームの失敗の多くは、システムの出来ではなく、参加者が集まらない、作り込みすぎる、運営が回らないことから起きるためです。具体的には、最初に何を確かめるべきかから提案してくれるか、参加者の集め方や運営の仕組みまで相談できるか、段階に合わせて開発手法を切り替えられるか、公開後の改善とコード・データの引き渡しまで対応するかを確かめます。公開されている開発事例で、マッチングや売買などプラットフォーム型の開発経験があるかも、最初に見ておくとよいでしょう。