アプリ開発とは？発注前に知っておく流れ・費用・依頼先の全体像

アプリ開発を外部へ依頼するときは、「何を作るか」だけでなく、新規開発が必要か、どの形態が課題に合うか、初回公開で何を検証するかを先に整理することが重要です。公開後の保守や改善まで視野に入れなければ、見積金額や公開日だけでは投資判断を進めにくくなります。

この記事では、スマホアプリ・Webサービス・既存活用の選び方から、工程、初回公開範囲、費用・日程の比較、依頼先選定、相談準備までを解説します。自社に合う形態と比較条件を定め、発注準備へ進むための判断軸を持てるようになります。

アプリ開発の発注は、形態・初回公開範囲・比較条件を順に整理すると進めやすくなります。

01Sectionアプリ開発とは：まず課題と形態を選ぶ

企業におけるアプリ開発は、画面を作る作業だけを指すものではありません。利用者や業務の課題を整理し、必要な機能・データ・運用方法を決め、設計、開発、テスト、公開、改善へつなげる取り組みです。発注前には、目的、業務フロー、外部システムとの接続、性能などを整理しておくと、依頼範囲を比較しやすくなります。項目の整理には、IPAの調達管理ガイド（共通フレーム2013に基づく試作版、2013年）も参考になります。

アプリ開発で整理する範囲

最初に決めるべきなのは、作りたい機能ではなく「誰の、どの行動を、どう変えたいか」です。たとえば、顧客への情報提供が目的なのか、従業員の入力・承認業務を減らしたいのか、取引先との受発注を一元化したいのかで、必要な仕組みは変わります。

そのうえで、利用者、利用場面、必要なデータ、公開後の問い合わせ・更新・改善の担当者を確認します。新規開発だけでなく、既存システムの改修や既存サービスの活用で初回の目的を満たせないかも、同じ条件で比べることが大切です。

形態と既存活用を比べる

形態ごとの特徴を踏まえ、利用者の行動、必要なデータ処理、端末機能、運用体制に合う候補を残します。

初期候補を絞る4つの問い

候補を絞る際は、次の順番で考えると判断しやすくなります。

1. 1情報提供や問い合わせ誘導が中心なら、まずモバイル対応Webサイトを比較対象にします。
2. 2ログイン、権限、継続的なデータ処理、管理機能が必要なら、Webサービスまたはスマホアプリを候補に残します。
3. 3通知、カメラ、位置情報、オフライン利用などが提供価値に直結するなら、スマホアプリを優先して検討します。
4. 4既存サービスの設定変更や既存システムの改修で初回必須要件を満たせるなら、新規開発と初年度の総負担・運用負荷を比べます。

形態の優劣を先に決めず、利用者の行動、必要なデータ処理、既存環境、公開後の運用体制から候補を残すことが重要です。

02Section発注から公開後までの工程

委託後も、目的・優先順位・受入基準・公開判断・改善方針は発注者側で確認する必要があります。

外部へ委託しても、目的、優先順位、受入基準、公開可否、公開後の改善判断は発注者側の仕事として残ります。工程名や契約上の分担は案件ごとに異なりますが、全体は次の5つの工程で整理できます。

工程ごとの目的と発注者の関与

受入テストと変更管理

開発中の追加要望は、口頭で実装を始めると、費用・期間・品質への影響を追いにくくなります。変更内容、理由、初回公開に反映するか後続公開へ回すか、影響を承認する担当者を記録しましょう。

また、テストでは画面単位ではなく、「ログインして対象を検索し、登録を完了し、担当者が確認する」といった業務・利用シナリオで確認します。外部連携がある場合は、接続先、データ項目、認証方法、連携障害時の扱いも受入条件に含めます。

公開後を見据えた責任分界

責任分界とは、自社・委託先・利用する基盤などの担当範囲の境界です。公開前に少なくとも、障害の一次窓口、問い合わせの担当、アカウント・ソースコード・データの管理者、更新や改善の決定者を決めておきます。

可用性、つまり必要なときに安定して使える状態をどこまで求めるかも、利用時間や業務影響に応じて決める必要があります。公開は完了ではなく、保守と改善を開始する地点として計画に組み込みましょう。

03Section初回公開の範囲をKPIから絞る

初回公開の範囲を機能数で決めると、要望の多さに引っ張られがちです。先に「初回公開後に何を確認できれば、次の投資判断ができるか」をKPIとして置き、利用者がその確認に必要な行動を完了できる最小利用フローを定めます。

目的別にKPI候補を置く

KPIは固定の目標値から始める必要はありません。まず現状値を取れるか、初回公開後に何を比較するか、誰がどの頻度で見るかを決めます。たとえば、業務効率化なら処理時間・差戻し率・利用率、顧客向け利用なら会員登録完了率・予約完了率・継続利用率、取引先向け業務なら処理時間・誤入力件数・利用企業率が候補になります。

重要なのは、KPIの数を増やすことではなく、初回公開の利用フローと測定方法を対応させることです。KPI確認の責任者も、企画段階で置いておきます。

必須・代替手段あり・後続公開に分ける

初回公開の候補機能は、次の3区分で扱います。

• 必須：対象利用者が目的の行動を完了するために欠かせないもの、または契約・安全上必要なものです。
• 代替手段あり：既存ツール、手作業、運用ルールで当面補えるものです。初回は簡易対応または対象外として比較します。
• 後続公開：初回のKPIを確認してから優先順位を決められるものです。改善候補として別に見積もります。

たとえば予約運用なら、初回に必要なのは「対象者が条件を確認し、予約を確定し、管理者が確認できる」流れかもしれません。高度な分析、追加の権限区分、複雑な通知設計は、初回のKPI検証後に判断できる場合があります。予算が限られるほど、必須の利用フローを守り、周辺機能を後続に移す判断が重要です。

04Section費用は初年度比較総額と見積条件で比べる

アプリ開発の費用は、画面数だけでは比較できません。対象プラットフォーム、ログイン・権限、外部連携、データ移行、テスト、公開支援、品質条件、保守範囲によって変わります。開発データには対象工程が限定されるものもあり、要件定義前や総合テスト後の作業を含まないケースがあります。したがって、発注準備から公開後の運用までを含む総額へ単純に当てはめるのは適切ではありません。IPAの開発データに関するFAQを確認したうえで、同一条件の個別見積もりを比較しましょう。

初年度比較総額の考え方

初期費用だけでなく、公開後の利用・保守・改善に関わる費用を含め、前提をそろえて比較します。

初期費用だけを比べるのではなく、初年度に発生する費用を同じ枠で集計します。

初年度比較総額
= 初期費用
+ 月額固定費 × 初年度の利用月数
+ 利用量連動費の想定額
+ 初年度に予定する保守・改善費
+ データ移行・外部審査・端末調達などの個別費用

見積依頼では、どこまでを初年度総額に含めるかを明記します。特に、監視、バックアップ、障害対応、更新、改善の扱いを除くと、初期費用が低く見えても運用開始後の比較が難しくなります。

見積比較で固定する条件

品質条件も金額差の要因です。可用性、性能、運用・保守性、セキュリティなどは、IPAの非機能要求グレードの考え方を参考に、案件に必要な水準を整理します。

費用構造や比較シートをさらに確認したい場合は、費用の詳細も参照してください。

05Section公開希望日から逆算して計画する

公開希望日だけを決めても、候補選定、社内承認、契約、要件整理、受入、公開準備に必要な時間は確保されません。期間は、発注準備、開発・公開、公開後安定化に分けて計画します。案件条件をそろえない一般的な期間相場は、自社の計画にそのまま使いにくいため、終了条件から逆算する方法が有効です。

発注準備と開発・公開を別計画にする

発注準備は、構想開始から候補比較、稟議、法務・購買・セキュリティ確認、契約締結までです。開発・公開は、企画・要件整理を始めてから、設計、開発、テスト、受入、公開を完了するまでを指します。初回公開後は、問い合わせ・障害対応・KPI確認の定例を始められるまでを安定化期間として別に置きます。

この3区分を混ぜると、開発側の作業予定だけでは公開可能か判断できません。社内レビューや連携先の準備も、同じ計画上で管理します。

公開希望日から先に決める期限

公開希望日から逆算して、少なくとも次の期限を置きます。

1. 1受入テスト完了日：必須シナリオの合格と公開承認を終える日です。
2. 2公開準備完了日：公開責任者、アカウント、公開手順、連絡体制を確認する日です。
3. 3連携・移行準備完了日：認証、接続先、データ移行、必要素材を用意する日です。
4. 4変更判断の締切：初回公開に反映する変更と後続公開に移す変更を分ける日です。
5. 5契約・社内承認の期限：候補選定、稟議、法務・購買・セキュリティ確認を完了する日です。

iOSアプリの公開では、ビルド、必要情報、審査申請、公開方法などを確認します。公開準備時にはAppleの公開フローを参照してください。Androidアプリも、Android Developersの公開ガイドで公開準備・公開手順を確認します。ストアの手順や要件は変わり得るため、申請・公開準備の直前に公式情報を確認することが必要です。

変更と予備期間を管理する

変更要望は、追加の価値だけでなく、テスト範囲、公開日、運用への影響を確認して判断します。公開希望日が固定されている場合は、変更を無制限に受け入れるのではなく、初回必須利用フローを守れるかで採否を決めます。

逆算計画の作り方は、期間計画の詳細でも確認できます。

06Section依頼先を必須条件と加点評価で選ぶ

依頼先は、企画から支援する開発会社、デザイン・制作寄りの事業者、特定技術に強い受託チーム、個人の専門家などに分かれます。ただし、類型だけで優劣は決まりません。自社がどこまで企画・進行管理・受入・運用を担えるかに応じて、必要な支援範囲を先に定義します。

依頼先類型より先に決めること

個人の専門家へ依頼する場合は、担当者が不在になったときの代替、成果物の共同保管、引継ぎ資料、アカウント管理を自社側でも確保できるか確認します。どの依頼先でも、目的と優先順位の決定者、利用部門のレビュー担当、公開後の責任者は自社に必要です。

一次選定と最終比較

候補は、まず満たさなければならない条件で一次選定し、その後に提案内容を評価します。個人データを委託先が扱う場合は、委託先の安全管理措置、再委託、契約上の取り決め、取扱状況の確認方法を、自社の法務・セキュリティ方針と照合してください。検討の基礎資料として、個人情報保護委員会のガイドラインを参照できます。

必須条件を満たさない候補は、価格や提案の評価前に対象外とします。

業界や企業によって必須となるセキュリティ審査、購買手続き、契約条件は異なるため、自社固有の条件を表へ追加してください。

自社側に必要な体制

依頼先の比較では、委託先の体制だけでなく、自社の確認体制も評価対象です。少なくとも、事業上の優先順位を決める人、利用部門のレビュー担当、連携・セキュリティを確認する担当、受入テスト担当、公開後の一次窓口を明確にします。

依頼先の比較から契約・進行管理までの論点は、外部委託の進め方で詳しく確認できます。

07Section相談前にそろえる情報

初回相談の時点で、専門的な仕様書を完成させる必要はありません。一方で、目的や利用者、初回公開で検証したいことが曖昧なままでは、提案と見積もりの条件をそろえにくくなります。次の項目を1〜2枚程度に整理して共有すると、会話を始めやすくなります。

1〜2枚の相談シートにまとめる項目

個人情報・資産・運用の確認

個人情報や機密情報を扱う場合は、アクセス権限、再委託、データの保管・返却、監督方法、契約条件を確認します。決済、位置情報、医療・金融、国外移転を伴うデータなどを扱う案件では、追加の法務・セキュリティ確認が必要になる場合があります。

また、公開用アカウント、ソースコード、設計書、データ、証明書、ドメインなどは、誰が最終管理者かを明確にします。委託先に運用を任せる場合でも、自社がアクセスや引継ぎを行える条件を契約・運用ルールに含めることが重要です。

アクセシビリティについても、対象利用者や利用環境に応じて、対応範囲と検証方法を決めます。デジタル庁のウェブアクセシビリティ導入ガイドブックを参考に、利用しにくさが業務や顧客体験に与える影響を確認しましょう。

未確定事項を提案依頼へ変える

未確定の項目を無理に決め切る必要はありません。たとえば「スマホアプリとWebサービスのどちらが適切か」「初回に必要な管理機能はどこまでか」「既存システムとの連携方法をどうするか」は、提案を受けたい論点として明記できます。

ただし、未確定事項ごとに、判断したい理由、選択肢、決定者、公開日・予算への影響を記載します。これにより、依頼先から単なる機能追加ではなく、代替案や段階公開を含む提案を受けやすくなります。

Webアプリ・SaaS開発の依頼先を比較する

整理した目的、初回公開範囲、連携要件、公開後の運用条件をもとに、対応可能な開発パートナーを比較できます。

Webアプリ・SaaS開発4593社掲載

開発パートナーを探す