新規事業のアプリ・Web開発｜最初の選び方の基準

新規事業で最初に作るシステムを、Webにするかスマホアプリにするかは、早い段階で話題になる論点です。この記事では、両者の違いを整理したうえで、選ぶときの6つの判断基準と、迷ったときの進め方を紹介します。

結論を先に書くと、形そのものに正解はありません。大切なのは「新規事業で最初に確かめたい仮説は何か」を決め、その仮説を最も早く、少ない作り込みで確かめられる形を選ぶことです。

最初に決めたいのは「形」より「確かめたいこと」

「アプリを作りたい」「Webサービスにしたい」という言葉は、企画の初期によく出てきます。ただ、形から入ると、後で判断がぶれやすくなります。アプリが良いという理由が「他社もアプリを出しているから」「スマホを使う人が多いから」だけだと、その形が事業の成否にどう関わるのかを説明しにくいためです。

新規事業の最初のシステムには、役割があります。事業のアイデアが本当に成り立つかを、実際の利用者の反応で確かめることです。つまり、最初のシステムは完成品ではなく、検証の道具です。この考え方は、新規事業の開発は小さく作って確かめる投資判断の進め方でも整理しています。

検証の道具として形を選ぶなら、次のように問いを立て直せます。

• 利用者は、このサービスの価値を感じるために何をする必要があるか
• その行動は、ブラウザで完結するか。端末の機能が要るか
• 最初の利用者に、どうやって届け、どうやって使い始めてもらうか
• 反応を見て直すとき、どれくらいの速さで更新したいか

この問いに答えていくと、Webとアプリのどちらが向くかが見えてきます。以降は、まず2つの形の特徴を押さえ、そのうえで判断基準を順に見ていきます。

Webとスマホアプリの違いを整理する

まず用語を整理します。ここでの「Web」は、ブラウザ（SafariやChromeなど）で開いて使うシステムを指します。URLを共有すればすぐ使い始められ、パソコンでもスマホでも同じ仕組みで動かせる点が特徴です。

「スマホアプリ」は、App StoreやGoogle Playからインストールして使うものを指します。端末に入るため、カメラ、位置情報、通知、Bluetoothなど、端末の機能を深く使えます。

間に位置する形もあります。

• レスポンシブWeb：画面の幅に合わせてレイアウトが変わるWeb。1つの開発でパソコンにもスマホにも対応できる
• PWA（Progressive Web App）：Webの仕組みで作りつつ、ホーム画面への追加や一部の通知など、アプリに近い使い方を可能にする技術。ただし、対応できる機能の範囲は端末やOSのバージョンによって異なるため、検討時にはAppleやGoogleの公式ドキュメントで最新の状況を確認する必要がある
• クロスプラットフォーム開発：FlutterやReact Nativeのように、1つのコードベースでiOSとAndroidの両方のアプリを作る方法。個別に作るより手間を抑えやすい一方、端末固有の機能を使う場面では個別対応が出ることがある

大まかな違いは次のとおりです。

観点	Web	スマホアプリ
使い始めるまで	URLを開くだけ	ストアで検索しインストールが必要
端末機能の利用	範囲に限りがある	幅広く利用できる
公開・更新	自社で更新を反映しやすい	ストアの審査を挟むことがある
対応する端末	ブラウザがあれば動く	iOS・Androidで対応が分かれる
検索からの流入	検索エンジン経由で見つけてもらえる	ストア内検索や広告が中心になりやすい

この表は一般的な傾向です。実際には、作るものの内容や使う技術で変わります。ここからは、この違いをどう判断に結びつけるかを見ていきます。

判断基準1：端末の機能が事業の核になっているか

最初に確認したいのは、端末の機能が価値の中心にあるかどうかです。

たとえば次のようなサービスは、アプリが向きやすい領域です。

• カメラで撮影した画像をその場で解析して使うサービス
• 位置情報を常時使って、近くにいることを検知するサービス
• 端末とBluetoothでつながる機器と連携するサービス
• 通知が利用の起点になり、通知がなければ使われないサービス

一方、次のようなサービスは、Webでも成立しやすい領域です。

• 情報を入力し、検索し、一覧で確認するサービス
• 予約、申し込み、見積もりなど、フォームと管理画面が中心のサービス
• 企業どうし、あるいは企業と個人をつなぐ、取引や手続きのサービス
• 会員向けのコンテンツや、ダッシュボード型のサービス

ここで見落としたくないのは、「端末の機能があると便利」と「端末の機能がないと事業が成り立たない」は別だという点です。便利さのために後から足せる機能なら、最初はWebで価値の検証を進め、必要になった段階でアプリ化を検討する順番も取れます。

判断基準2：利用の場面と頻度

次に、利用者がいつ、どこで、どれくらいの頻度で使うかを考えます。

毎日何度も開くサービスは、ホーム画面にアイコンがあり、通知で呼び戻せるアプリのほうが、習慣になりやすい面があります。反対に、月に数回しか使わない手続き型のサービスでは、わざわざインストールしてもらうこと自体が負担になり、使い始める前に離れてしまうこともあります。

利用の場面も整理したい点です。

• 外出先でスマホだけで使うのか
• 職場のパソコンで、画面を広く使って入力するのか
• 現場で手がふさがっている状態で使うのか
• 初回は営業担当と一緒に画面を見ながら使い始めるのか

法人向け（BtoB）のサービスでは、パソコンのブラウザで長い入力や一覧確認をする場面が多く、Webが基本形になることが少なくありません。個人向け（BtoC）でも、初回の登録はWebで行い、日常利用をアプリで行う、という分け方もあります。

「想像で決めない」ことも重要です。利用の場面は、想定している利用者に直接聞くか、近い行動を観察して確かめるほうが確実です。プロトタイプを見せながら聞く方法については、プロトタイプのユーザーテストで質問の作り方を紹介しています。

判断基準3：届け方と、使い始めてもらうまでの手間

新規事業では、システムを作るだけでなく、最初の利用者に届ける段階でつまずくことがあります。形によって、届け方の難しさが変わります。

Webの場合は、URLを送るだけで使い始めてもらえます。メール、チャット、営業の場での画面共有など、既存の接点をそのまま使えます。検索エンジン経由で見つけてもらう道もあります。

アプリの場合は、利用者がストアで探してインストールする手間が加わります。さらに、公開にはAppleやGoogleの審査があり、ガイドラインに沿っているかの確認が入ります。審査の内容や所要期間は時期や案件によって変わるため、公開日を逆算するときは、各社の最新のガイドラインを確認しておく必要があります。

小さな範囲で試したい場合の届け方も、形によって変わります。

• 特定の数社・数十人にだけ使ってもらう
• 招待した人だけが使える状態にする
• 反応を見ながら少しずつ範囲を広げる

こうした限定公開は、Webのほうが運用を組みやすい場面が多くあります。アプリでも、テスト配信の仕組みを使えば限定的に配れますが、利用者側の準備は増えます。公開範囲の決め方は、新規事業のクローズドβで詳しく取り上げています。

判断基準4：修正と更新の速さ

新規事業の最初のシステムは、公開してから直す回数が多くなります。利用者の反応を見て、画面の文言、入力項目、流れを何度も調整するためです。

Webは、自社で更新を反映しやすいのが強みです。修正が済めば、利用者は次にアクセスしたときに新しい状態を使えます。利用者側に操作を求める必要がありません。

アプリは、更新版をストアに提出し、審査を経て、利用者が更新するという段階を踏みます。利用者がすぐ更新するとは限らず、古いバージョンが残ったまま動く期間が出てきます。その間は、古いバージョンと新しいバージョンの両方に対応する前提で、システム側の設計も考えなければなりません。

もちろん、アプリでも更新の工夫はできます。ただ、「毎週のように画面を変えながら反応を見たい」という検証の初期には、Webのほうが身軽です。この点は、最初に作る範囲を決めるうえでも効いてきます。範囲の絞り方は、MVP開発の機能の絞り方も参考になります。

判断基準5：開発の範囲と、対応する端末の数

同じ機能でも、形によって作る範囲が変わります。

Webであれば、基本的には1つのシステムを作り、画面幅に合わせて表示を整えます。管理者が使う管理画面も同じ仕組みの中に作れます。

アプリでは、iOSとAndroidのどちらに対応するかを決める必要があります。両方に対応するなら、個別に作るか、クロスプラットフォーム技術を使うかを選びます。さらに、アプリを使う利用者向けの画面とは別に、運営側が使う管理画面は、結局Webで作ることが多くなります。つまり「アプリを作る」と決めても、裏側のWebは要る、という構造になりやすいのです。

最初の検証で、対応する端末の数や画面の数が多いほど、作り込みに時間がかかり、確かめるまでが遠くなります。新規事業の初期は、「最も重要な利用者の、最も重要な場面」に絞って形を決めるのが基本です。管理画面をどこまで最初に用意するかは、新規事業の管理画面開発で整理しています。

判断基準6：後から形を変えるときの引き継ぎやすさ

最初にWebを選んでも、アプリを選んでも、後で形を広げる可能性があります。そのとき困らないように、変えやすい部分と変えにくい部分を分けて考えておきます。

比較的引き継ぎやすいのは、次の部分です。

• 事業のルール（料金の計算、申し込みの条件、承認の流れなど）
• データの持ち方（利用者、取引、履歴などの構造）
• サーバー側の処理や、外部サービスとの連携

作り直しになりやすいのは、画面や操作性の部分です。Webの画面をそのままアプリに移すことは難しく、アプリとして使いやすい操作に設計し直すことが多くなります。

このため、最初の段階から、画面だけでなく、データと処理の部分を見通して設計しておくと、形を変えるときの負担を抑えられます。データの持ち方は、新規事業のデータ設計で最初に決めたい点を整理しました。また、検証用に作ったものを本開発にどう生かすかは、MVPから本開発は作り直し？で扱っています。

迷ったときの考え方：まず確かめたいことに近い形で動かす

6つの基準を見ても決めきれないときは、次の順で考えると整理しやすくなります。

端末機能が事業の核なら、アプリを前提にする

端末の機能がなければ価値が成り立たないサービスは、最初からアプリを前提にします。ただし、その場合でも、すべての機能を最初から作るのではなく、核になる機能だけに絞ります。

そうでなければ、Webから始めて反応を見る

端末機能が必須でない場合は、Webで最小限の形を作り、少数の利用者に使ってもらうのが、検証としては身軽です。使われ方を見て、「毎日開く習慣がある」「通知がほしいという声が多い」といった事実が出てきたら、アプリ化を検討します。

判断できないなら、動く実物で確かめる

意見が割れるのは、実物がなく、言葉と想像で議論しているときです。「アプリのほうが使いやすいはず」「Webで十分なはず」という見立ては、実際に触ってみるまで確かめられません。

動くプロトタイプを作り、想定する利用者の手元で使ってもらうと、次のようなことが具体的に見えてきます。

• ブラウザで開く手間は、利用者にとって負担になるか
• 通知がなくても、利用者は自分から戻ってくるか
• スマホとパソコンのどちらで主に操作しているか

プロトタイプ、MVP、モックの違いはプロトタイプとモックアップ・MVPの違いで整理しています。形を選ぶ段階では、完成度の高さより「確かめたいことが確かめられるか」で選ぶのが要点です。

事業の種類ごとに見る、形の選び方の例

一般的な傾向として、事業の種類ごとの考え方を整理します。個別のケースでは前提が変わるため、あくまで検討の出発点として読んでください。

取引や手続きをつなぐサービス

企業と企業、あるいは企業と個人の間で、申し込みや承認、請求などの手続きを扱うサービスは、入力や一覧の確認が中心になります。パソコンのブラウザで使われる場面が多く、まずWebで始めるのが自然です。マッチング型のサービスの進め方は、マッチングサービス開発の進め方で整理しています。

継続利用を前提にしたサービス

会員向けに継続して使ってもらうサービスでは、最初の登録や申し込みがスムーズであることが重要になります。Webで入り口を作り、利用が定着してきたらアプリで日常利用を支える、という段階的な進め方も考えられます。SaaS型の事業の範囲の決め方は、SaaS新規事業の開発にまとめています。

現場や外出先で使うサービス

現場作業中に撮影したり、位置を記録したり、通信が不安定な場所で使ったりするサービスは、端末の機能や使い勝手が価値に直結します。この場合はアプリを前提に考えつつ、最初に作る機能を絞ることが重要です。

社内発の新規事業

社内ベンチャーや新規事業のコンテストから生まれた構想は、社内の限られた関係者に見せて判断を仰ぐ場面が多くあります。URLを共有するだけで見てもらえるWebのほうが、稟議や承認の場で扱いやすいことがあります。決裁の場での使い方は、稟議を通すシステム開発で整理しています。

形を決めたあとに確認したいこと

形を決めたら、次の点を確認しておくと、後からのやり直しを減らせます。

• 最初の検証で確かめる指標は何か（登録数、継続率、成約など）。指標の決め方はMVP検証の指標を先に決める方法が参考になる
• やめる・続ける・形を変えるの判断基準を、事前に決めているか
• 最初の利用者を、誰にどう届けるか
• 個人情報や決済など、扱う情報の範囲と、守るべきルールは何か
• 公開後の修正や機能追加を、誰がどう進めるか

形を選ぶことは、事業の判断の一部です。技術の好みや流行で決めず、事業として何を確かめたいかを起点に、根拠を説明できる形にしておくことが、社内の合意にもつながります。

まとめ

新規事業の最初のシステムをWebにするかスマホアプリにするかは、形の優劣ではなく、「最初に何を確かめたいか」で決めるのが基本です。この記事で紹介した判断基準を、あらためて整理します。

1. 端末の機能が、事業の価値の核になっているか
2. 利用の場面と頻度は、どのようなものか
3. 最初の利用者に、どう届け、どう使い始めてもらうか
4. 反応を見ながら、どれだけ速く修正したいか
5. 作る範囲と、対応する端末の数をどこまで絞れるか
6. 後から形を広げるとき、引き継ぎやすい設計になっているか

端末機能が必須でなければ、Webで小さく始めて反応を見る。端末機能が核なら、アプリを前提に、核になる機能へ絞る。どちらか判断しきれないときは、言葉で議論を続けるより、動く実物で確かめるほうが、結論に近づきやすくなります。

JustFitは、株式会社LEGAREAが運営する完全オーダーメイドの受託開発サービスで、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断していただく進め方をとっています。WebかアプリかをはじめとするシステムをまだAdしていない段階でも、構想を動く形にして確かめたい場合は、JustFitのサービス紹介をご覧ください。