Webサービス・スマホアプリ開発の支援会社に相談すべきケース・自社で進められるケース

Webサービスやスマホアプリの開発を検討し始めると、「自社で進めるべきか、支援会社に相談すべきか」で迷いやすくなります。ですが実務では、この判断は単純な二択ではありません。社内にエンジニアがいるかどうかだけでなく、要件の固まり具合、公開希望時期、連携の多さ、セキュリティや運用の重さまで見ないと、途中で手戻りが起きやすくなります。

この記事では、判断の軸を「全部自社」か「全部依頼」かではなく、工程ごとの役割分担として整理します。簡易診断で自社の現在地を確認し、Webサービスとスマホアプリの実務差分、内製しやすい範囲、早めに相談したほうがよい条件、依頼範囲の4パターン、3案比較の6軸、相談前の準備までを順に見ていきます。

開発方針は『全部自社』か『全部依頼』の二択ではなく、工程ごとの役割分担で考えると整理しやすくなります。

01Section結論から押さえる：判断は「全部自社」か「全部依頼」かではなく工程分担で考える

最初に固定しておきたいのは、開発の進め方は二択ではなく3択だということです。実務では、次の3つのどれに近いかで考えると整理しやすくなります。

この記事で決めること

この記事で決めたいのは、次の3点です。

• どの工程までを自社で持つか
• どの工程だけ支援会社に相談するか
• 外部活用しても自社に残す責任は何か

選択肢は「自社主導」「支援会社活用」「併用」の3つ

自社主導は、課題設定から要件整理、設計・実装・運用までを社内中心で回す進め方です。支援会社活用は、上流から開発・運用まで外部の比重を高める進め方。併用は、その中間で、目的設定や優先順位は社内で持ちながら、要件整理、設計、QA、運用の一部など不足工程だけを外部で補う進め方です。

特にBtoBの開発では、併用が現実的な落としどころになりやすい傾向があります。事業や業務の理解は社内にあり、開発や品質保証、公開準備の専門性だけを外から補うほうが、過剰な丸投げにも無理な内製にもなりにくいためです。

判断を誤りやすいポイント

判断を誤りやすいのは、「エンジニアが1人いるから内製できる」「要件が完全に固まるまで相談できない」「外部に出せば社内負荷が消える」と捉えてしまうケースです。実際には、受入判断、公開判断、公開後の改善優先順位づけも必要です。外部を使っても、判断と受入の責任まではなくなりません。

02Sectionまず自社の状況を診断する

簡易診断は合否ではなく、どの論点を深く確認すべきかを見極めるための目安です。

ここでは、案件を内製寄り・併用寄り・早期相談寄りのどこに置くかをざっくり見ます。点数はあくまで実務上の目安ですが、最初の方向づけには有効です。

簡易診断のチェック項目

判定の目安は、0〜2点で内製寄り、3〜5点で併用寄り、6点以上で早期相談寄りです。ストア公開がある案件や、社内基準としてセキュリティ要件が重い案件は、点数にかかわらず一段階厳しめに見たほうが安全です。

判定結果の読み方

内製寄りなら、自社主導で小さく始める余地があります。ただし、設計レビューやQAレビューのように、弱い工程だけ外部の目を入れる選択肢は残しておくと安全です。

併用寄りなら、目的や業務理解は社内で持ちつつ、要件整理、設計、テスト、運用設計のどこを外部に出すかを先に決めるのが現実的です。最初から全工程を外に出す必要はありません。

早期相談寄りなら、社内だけで前提を詰め切ろうとせず、構想段階から相談テーマを切って動くほうが手戻りを減らしやすくなります。特にストア公開、機微データ、複数連携、固定公開日は、後半で修正しにくい論点です。

中間状態ならどう進めるか

3〜5点前後の案件は、「どちらつかず」で止まりやすい層です。この場合は、全部を決めようとせず、次のように分けると進めやすくなります。

• Webで足りるか、アプリ前提かだけ先に相談する
• 要件定義だけ外部に支援を入れる
• 設計レビューとテスト設計だけ外部に依頼する

03SectionWebサービスとスマホアプリで、何が追加論点になるのか

Webサービスとスマホアプリは、実装だけでなく公開前後の運用条件まで含めて比較することが重要です。

Webサービスとスマホアプリは、同じ「画面を作る開発」に見えても、実務では追加論点が異なります。特にアプリは、公開前後の運用条件まで含めて見ないと判断を誤りやすくなります。

配布・審査・テストの違い

iOSアプリでは、App Review Guidelines を前提に提出準備を考える必要があります。完成度、必要メタデータ、ログイン必須機能がある場合のデモアカウントやデモモードの準備など、実装以外の準備も発生しやすい点がWebとの大きな違いです。

Androidアプリでも、Google Play のテストトラック案内 が示すように、internal / closed / open testing を踏まえた段階的な検証を置いたほうが進めやすくなります。

OS/端末差分と通知の違い

Webでもブラウザ差分や画面サイズ差分はありますが、アプリではさらにOSバージョンや端末性能の違いが効きます。Android Developers の画面互換性ガイド でも、画面サイズや密度差分を前提にした設計が案内されています。

通知も実装だけの話ではありません。iOSでは 通知許諾の設計、Androidでは 通知の表示や挙動 を踏まえる必要があり、運用設計まで含めて考える必要があります。

公開後更新と運用負荷の違い

Webサービスはサーバー側更新で反映しやすい一方、アプリは審査待ちや利用者側の更新タイミングの影響を受けます。公開後の改善スピードや緊急修正の進めやすさは、Webとアプリで大きく異なります。

なお、認証、個人情報、複数連携、高可用性、アクセシビリティが重い案件では、Webでも相談優先度は上がります。アクセシビリティの確認観点は W3C WCAG が基本的な確認先です。

04Sectionどこまでなら自社で進めやすいか

ここでは「内製できるか」ではなく、どの工程なら自社で持ちやすいかを見ます。全部を抱える発想より、持ちやすい工程から定義するほうが現実的です。

自社主導で持ちやすい工程

自社で持ちやすいのは、主に次の領域です。

• 誰の何の課題を解くかという課題設定
• 対象ユーザーや業務フローの理解
• 何を優先し、何を初期リリースから外すかの判断
• 受入判断と公開後の改善優先順位づけ

これは外部が代行しにくい領域でもあります。CIO TechFAR Handbook でも、外部支援が入る場合でも発注側がプロダクトの目的や優先順位を持つ考え方が示されています。

内製しやすい条件の目安

内製しやすい案件に共通するのは、役割が置けることです。最低でも、事業またはプロダクト責任者、業務判断者、受入テスト担当、公開後運用窓口の4役割は意識しておきたいところです。開発担当だけでなく、受入と運用の責任者まで置けるかが分かれ目です。

加えて、初期スコープが絞れていることも重要です。MVPまでに入れる機能を限定できる案件は、自社主導で進めやすくなります。作るところだけでなく、公開後の問い合わせや障害初動の窓口まで決めておくと、内製の難易度を上げにくくなります。

PoC・MVP・本開発の使い分け

PoCは「成立するかを確かめる小さな検証」、MVPは「最小限の価値提供ができる最初の版」、本開発は「継続運用を前提にした本番水準の開発」と捉えると整理しやすくなります。

05Sectionどんな条件なら支援会社に早めに相談すべきか

要件が完全に固まっていなくても、早く相談したほうがよい案件はあります。共通するのは、後からの修正コストが高い条件を含んでいることです。

早期相談が有効な典型条件

次の条件があるなら、早めに相談優先度が上がります。

• スマホアプリのストア公開が前提
• 個人情報、決済、権限管理、監査ログなどの扱いが重い
• 外部連携が複数あり、前提条件のすり合わせが多い
• 公開日が事業上固定されている
• 社内にQAや運用設計の経験者がいない

後から直しにくい条件がある案件ほど、要件が粗い段階でも相談価値があります。

特にセキュリティは、後から付け足す前提で進めると整理しにくくなります。NIST の SSDF が示すように、セキュリティはライフサイクル全体で考える前提にしたほうが、要件定義や設計の時点で抜け漏れを防ぎやすくなります。

相談が遅れると起きやすい手戻り

相談が遅れると起きやすいのは、設計や画面の作り直しだけではありません。たとえば、連携方式の前提が合わない、通知設計が運用に乗らない、ストア公開準備が足りない、受入条件が決まっていない、といった問題は後半で発覚しやすく、修正コストも大きくなります。

まず1枚整理してから相談するケース

一方で、次の状態なら、先に社内で1枚整理したほうが相談が進みやすくなります。

• 誰のどの課題を解くのかが曖昧
• 対象ユーザーが未定
• Webかアプリかの仮説もまだない
• 希望時期や決裁経路がまったく見えていない

この段階で必要なのは、詳細仕様ではなく「何の必要性があるのか」を整理することです。要件整理の出発点として何を明確にするかは、GSA の Requirements Definition の考え方も参考になります。

06Section支援会社に依頼するなら、どこまで任せるか

依頼範囲は『何を全部任せるか』ではなく、『社内のどこが不足しているか』から決めると整理しやすくなります。

支援会社への依頼範囲は、「何を全部任せたいか」ではなく「社内のどこが不足しているか」から決めると過不足が出にくくなります。

依頼範囲の4パターン

代表的な依頼範囲は、次の4パターンです。

1. 1相談のみ：Webかアプリか、初期スコープ、進め方を整理したい
2. 2要件定義・設計まで：方向性はあるが、要件整理や設計方針を固めたい
3. 3開発・テストまで：方針は決まっており、実装とQAを任せたい
4. 4保守運用まで：公開後の監視、障害一次対応、改善定例まで含めたい

工程別の役割分担

見方は単純です。社内担当を置けない工程は外部活用候補です。ただし、外部に任せやすい範囲と、自社が判断を持つべき範囲は分けて考えます。目的・優先順位・受入判断は切り分けて自社に残します。この考え方は CIO TechFAR Handbook とも整合します。

外部に任せても自社が手放さない責任

07Section自社開発・支援会社活用・併用を何で比較するか

3案比較で失敗しやすいのは、見積総額だけで決めてしまうことです。初期費用が低く見えても、社内工数や運用負荷、変更時の追加対応で逆転するケースは珍しくありません。

比較すべき6軸

比較は、少なくとも次の6軸でそろえると判断しやすくなります。

費用は「金額」より「費目構造」で見る

費用比較で見るべきなのは、単純な外部支払いの多寡ではありません。GSA の Acquisition Overview や Acquisition Pricing が示すように、見える費用と見えにくい負荷を分けて考えると判断しやすくなります。比較の軸は「いくら払うか」だけでなく、「どの負荷が誰に残るか」です。

同じ枠で見たい費目は、次の5つです。

• 外部への初期支払い
• 社内の要件整理、進行管理、受入にかかる工数
• 内製要員の採用・育成・立ち上がり負荷
• 仕様変更時の再設計・再テスト負荷
• 公開後の監視、障害対応、軽微改修の負荷

アプリ案件では、審査対応、端末差分確認、通知運用、OS更新追随が追加されやすくなります。金額を一律に比べにくいのは、契約条件、支援範囲、利用規模、連携要件で前提が変わるためです。

決裁者説明で押さえる論点

社内説明では、総費用から話し始めるより、必要な速度、その速度を支える体制、事故時の影響、最後に総費用の順で整理したほうが通しやすくなります。比較表に空欄が多い案は、金額が魅力的でも判断材料として未成熟です。

08Section相談前に何を整理し、次の一手を決めるか

相談前に完全な要件定義書は必要ありません。ただし、何も決まっていない状態と、最低限の前提がある状態では、提案や見積もりの精度が大きく変わります。

初回相談に必要な最低限

初回相談で必要なのは、完成した要件定義書ではなく、目的と前提のたたき台です。未確定事項があっても問題ありません。重要なのは、未確定であること自体を共有することです。考え方は GSA の Requirements Definition とも近い整理です。

見積もり精度を上げる追加情報

複数社を比較する場合は、全社に同じ前提資料を渡すことが重要です。前提条件、除外事項、成果物、変更対応、保守範囲を同じ観点で並べると、見積もり比較の精度が上がります。

よくある迷いへのFAQ

最後に、次の一手は大きく3つです。診断が内製寄りなら、自社主導でPoCやMVPの範囲を絞る。併用寄りなら、弱い工程だけを切り出して相談する。早期相談寄りなら、目的・対象ユーザー・希望時期を1枚にまとめ、上流整理から相談する。この順で進めると、無理な内製や過剰な外部依頼を避けやすくなります。

プロダクト企画・要件定義支援の支援会社を見つける

条件に合う支援会社をスグに検索・比較できます

プロダクト企画・要件定義支援0社掲載

会社一覧を見る