LASSIC Media らしくメディア
アプリ開発外注先の選定基準7項目｜発注失敗を防ぐ確認ポイント
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- IPA・経産省のガイドラインに基づき、アプリ開発外注先を評価する7つの基準を比較表で整理している
- 請負契約・準委任契約の違いや再委託構造の確認方法など、発注者が見落としがちな契約面のリスクを具体的に解説する
- RFP提示から試験的な小規模発注まで、外注先を段階的に評価する5ステップの手順を示す
目次
アプリ開発の外注先選定とは何か — 発注者が握るべき3つの事前整理
アプリ開発の外注先選定とは、自社が実現したいアプリケーション（スマートフォンアプリ・業務システム等）の開発を委託するベンダーを、技術力・契約形態・セキュリティ体制などの評価基準に基づいて決定するプロセスである。IPA（独立行政法人情報処理推進機構）が公表する「情報システム・モデル取引・契約書（第二版）」は、「発注者とベンダーが対話による共通理解のもとでITシステム開発を行うことが重要」と位置づけており、選定段階から発注者側が主体的に評価軸を設計することを求めている*1。
発注者が要件定義を先に固める理由
外注先選定を始める前に、発注者側が「何を作るか」の要件定義を一定程度固めておくことが前提となる。IPAの「情報システム・モデル取引・契約書」では、個別契約の締結前にRFP（提案依頼書）を発注者がベンダーに提示し、そのRFPと提案・見積もりを照合して契約条件を定めることを標準プロセスとして示している*1。要件が曖昧なまま外注先を決めると、追加費用や工期延長が発生しやすい。発注者が要件を整理することで、複数社の提案を同一条件で比較できるようになる。
外注形態の2種類 — 請負契約と準委任契約の違い
アプリ開発の外注には、大きく2種類の契約形態がある。
請負契約は、成果物（アプリの完成品）の引き渡しに対して報酬が発生する契約である。ベンダーが仕様通りの成果物を完成させる義務（契約不適合責任）を負う。
準委任契約は、ベンダーが専門家として業務を遂行すること自体に対して報酬が発生する形態である。IPAのアジャイル開発版モデル契約では、アジャイル開発において準委任契約が前提とされており、「ベンダーが善管注意義務に基づいてプロダクト価値向上に取り組む姿勢」が評価対象となる*2。
ウォーターフォール開発（仕様を先に固めて順番に工程を進める手法）では請負契約、アジャイル開発（短いサイクルで繰り返し開発する手法）では準委任契約がそれぞれ一般的である。どちらが自社の開発スタイルに合うかを、外注先選定の前に確認しておく必要がある。
選定フローの全体像（RFP提示→提案受領→評価→契約）
外注先選定の一般的なフローは、RFP提示・複数社からの提案受領・評価基準による比較・ヒアリング・契約締結の順で進む。経済産業省の「情報システム・モデル取引・契約書」では、複数のベンダーにRFPを提示して提案を受け取り、設定した評価基準で比較した上でベンダーを選定するプロセスを標準として示している*1。選定段階から評価基準を明文化することで、担当者の主観に依存しない客観的な選定が可能になる。
外注先を評価する7つの選定基準と比較表
外注先の評価は、技術力だけでなく契約・セキュリティ・コミュニケーション体制など複数の軸で行う必要がある。以下の7基準は、IPA「情報システム・モデル取引・契約書」および経済産業省「情報サービス・ソフトウェア産業における中小受託適正取引等の推進のためのガイドライン（令和7年12月改訂）」を参照しながら整理したものである*1*3。
基準①技術スタック・開発実績の適合性
自社が求める技術（iOS/Android/クロスプラットフォーム等）の開発実績があるかを確認する。ポートフォリオや類似案件の開発経験を提案書で求め、技術スタック（使用言語・フレームワーク・クラウド基盤）が自社要件と適合しているかを評価する。IPAのアジャイル開発版では、「開発チームが継続的に対応できる能力水準」を選定要件の一つとして挙げている*2。
基準②契約形態とプロジェクト管理体制
請負か準委任か、また工程ごとに契約形態が変わるかを事前に確認する。IPAのモデル契約では、「多段階契約時の紛争予防」が重要論点として示されており、工程ごとの役割分担と責任の所在を契約前に明文化することを求めている*1。プロジェクト管理者（PM）の配置体制や、進捗報告の頻度・手段も確認対象である。
基準③セキュリティ対策の確認方法
IPAが公表した「情報システム・モデル取引・契約書（第二版）」では、セキュリティ仕様の作成において「リスク評価に基づく共通理解プロセス」を確立することが重要論点として追加された*1。具体的には、個人情報の取り扱い方針、セキュリティ審査の受け入れ可否、ISO 27001やPマーク（個人情報保護に関する第三者認証制度）などの認証取得状況を確認する。
基準④コミュニケーション体制と要件定義支援力
外注先が発注者の業務理解を深めるヒアリング能力を持つかどうかが、要件定義の品質に直結する。窓口担当者の技術的知識レベル、要件整理のための提案資料の質、変更要求発生時の対応フローを確認する。IPA「重要情報を扱うシステムの要求策定ガイド」では、発注者とベンダーが共同で要件を整理するプロセスの重要性を示している*4。
基準⑤品質管理プロセスとテスト体制
テスト設計書・テスト実施結果の提出が契約に含まれるかを確認する。IPA「ソフトウェア開発分析データ集2022」では、直近6年間の1,479件のプロジェクト分析で信頼性と生産性の低下傾向が報告されており*5、品質管理プロセスの有無が納品物の信頼性に影響することが示唆されている。受入テスト（UAT：発注者が仕様通りであることを確認するテスト）の手順と責任分担も事前に合意しておく必要がある。
基準⑥再委託（多重下請け）構造の確認
外注先が実際の開発作業を別の下請け企業に再委託する場合、発注者が想定した技術力や品質管理が担保されないリスクがある。経済産業省のガイドラインでは、「受託企業が再委託を行う場合の条件や管理方法の明示」を発注時の確認事項として定めている*3。再委託先の企業名・技術力・所在地（オフショア開発かどうか）を契約前に確認し、再委託に関する書面での事前承認条項を設けることが望ましい。
基準⑦見積もり根拠と費用の透明性
見積もりが「人月単価×工数」の形で内訳を開示しているかを確認する。内訳が不透明な一式見積もりは、追加費用の根拠が曖昧になりやすい。工数見積もりの根拠となる機能一覧（WBS：Work Breakdown Structure、作業分解構造）の提出を求めることで、スコープの境界を明確にできる。
| 選定基準 | 確認すべき具体的ポイント | 根拠・参照先 |
|---|---|---|
| ①技術スタック・実績の適合性 | 類似案件の開発実績、使用言語・フレームワーク、チームの継続対応能力 | IPA アジャイル開発版モデル契約*2 |
| ②契約形態とPM体制 | 請負/準委任の区別、工程ごとの責任分担、進捗報告の頻度 | IPA モデル取引・契約書（第二版）*1 |
| ③セキュリティ対策 | 情報管理方針、ISO 27001・Pマークの取得状況、セキュリティ審査の可否 | IPA モデル取引・契約書（第二版）*1 |
| ④コミュニケーション体制 | 担当者の技術知識レベル、要件整理支援力、変更要求対応フロー | IPA 重要情報を扱うシステムの要求策定ガイド*4 |
| ⑤品質管理・テスト体制 | テスト設計書の提出義務、UAT手順・責任分担の合意 | IPA ソフトウェア開発分析データ集2022*5 |
| ⑥再委託（多重下請け）構造 | 再委託先の企業名・所在地、書面による事前承認条項の設定 | 経産省 情報サービス・ソフトウェア産業ガイドライン*3 |
| ⑦費用の透明性 | 人月単価×工数の内訳開示、WBSによるスコープ境界の明文化 | IPA モデル取引・契約書（第二版）*1 |
外注先選定で発生する3つの失敗パターンとコスト影響
本節では選定段階で見落とされやすい3つの失敗パターンを示す。次節では、これらの失敗を防ぐための評価ステップを具体的に説明する。
失敗1 — 要件定義を外注任せにして追加費用・工期延長が発生するケース
発注者が要件を十分整理しないまま外注先に依頼した場合、開発途中での仕様変更や機能追加が頻発し、追加費用や工期の延長が生じる。IPAは「システム開発において、発注者側が要件定義に主体的に関与することが、プロジェクト成功の前提条件」と位置づけている*1。外注先への要件定義支援を含める場合でも、発注者の承認プロセスを明確にすることがリスク低減につながる。
失敗2 — 再委託先の技術力が不明なまま本番稼働するケース
外注先が実際の開発を別会社に委託している場合、発注者が想定した技術品質が確保されていないことがある。経済産業省のガイドラインは、「受託企業が第三者に委託する場合、委託内容・管理方法を書面で明示する義務がある」と定めている*3。本番稼働後に不具合が多発した場合、責任の所在が曖昧になりやすく、修正コストを発注者が負担するリスクも生じる。
失敗3 — 契約形態の誤認でセキュリティ責任が曖昧になるケース
「システムができたら開発会社の責任は終わり」と理解していた発注者が、本番運用後のセキュリティインシデントで損害を被るケースがある。IPA「情報システム・モデル取引・契約書（第二版）」では、セキュリティ仕様は「発注者とベンダーが共同でリスク評価を行い、合意した仕様として契約書に明記する」ことが求められており*1、この合意が取れていない場合は責任の境界が不明確になる。契約締結前にセキュリティ要件を文書化しておくことがトラブル防止の基本となる。
RFP提示から契約締結までの5ステップ評価手順
外注先を段階的に絞り込む5ステップを以下に示す。IPAが標準プロセスとして示す流れを基本としながら、実務上の確認ポイントを加えている*1。
ステップ1 — 要件とRFPの作成
開発するアプリの機能一覧・性能要件・セキュリティ要件・予算感・スケジュールをRFP（Request for Proposal：提案依頼書）にまとめる。「何を作るか」「誰が使うか」「どのプラットフォームか」を明確にすることで、複数社から同一条件の提案を受け取れる。RFPに含める項目として、機能要件・非機能要件（性能・可用性・セキュリティ）・保守・運用の範囲・納品形式が挙げられる。
ステップ2 — 複数社提案の取得と評価シートの設計
3社以上の提案を取得し、前述の7基準を評価軸とした評価シートを事前に設計する。評価シートでは各基準に重み付け（例：技術適合性30点・費用透明性20点・セキュリティ20点）を設定することで、主観に依存しない比較が可能になる。IPA「情報システム・モデル取引・契約書」では「RFPと提案・見積もりに基づき個別契約条件を定める」ことを標準フローとして示している*1。
ステップ3 — 技術力・セキュリティ・実績の深掘りヒアリング
書類審査を通過した候補社に対し、技術担当者が同席するヒアリングを設定する。確認ポイントは、類似案件での技術判断事例・テスト設計の実例・セキュリティインシデント発生時の対応実績の3点である。「〇〇の技術課題をどう解決したか」という具体的な事例を求めることで、実力を評価しやすくなる。
ステップ4 — 契約形態・再委託条件の確認
ヒアリング後、最終候補社に契約条件の詳細確認を行う。経済産業省ガイドラインでは発注時に「委託内容・再委託の有無・支払い条件」を書面で明示する義務を定めており*3、これを発注者側からも事前に確認する形で進める。特に再委託先の所在地（国内か海外か）と情報管理体制の確認は、個人情報を扱うアプリ開発では欠かせない。
ステップ5 — 試験的な小規模発注でリスクを確認する
本開発の前に、設計書作成や画面プロトタイプなど小規模なフェーズを先行発注し、実際のアウトプットの品質・コミュニケーションの質・納期遵守の状況を確認する。この段階で問題が発覚した場合は、本開発前に外注先を変更できる。IPA「アジャイル開発版モデル契約」でも、「開発チームの能力と継続性」を実作業を通じて確認するアプローチが示されている*2。
内製か外注かを判断する3つの指標
アプリ開発を外注すべきかどうかを判断する際、以下の3つの指標から検討することが実務上の基準となる。
必要スキルセットと調達コストの比較
スマートフォンアプリをゼロから内製するには、iOS開発（Swift）・Android開発（Kotlin）またはクロスプラットフォーム開発（Flutter/React Native）の技術知識に加え、UI/UXデザイン・サーバーサイド開発・テスト設計・セキュリティ評価の各スキルが必要となる。これらを担える人材を複数名確保するためには、採用・研修の工数が発生する。スキルの網羅性と調達コストを、外注費用と比較した上で判断することが現実的だ。
内製リスク — 継続的な保守・セキュリティ対応の工数
アプリは開発完了後も、OS（iOSやAndroid）のバージョンアップ対応・セキュリティパッチの適用・障害対応などの継続的な保守が必要である。内製チームの場合、担当者の退職や異動で保守が停滞するリスクが生じる。経済産業省「システム管理基準（令和5年4月26日）」では、「ITシステムの継続的な維持・改善のための体制整備」が企業の管理責任として定められており*6、保守体制の確保も外注判断の重要な要素となる。
外注（元請・プライムベンダー）活用で下がるリスク
元請（プライムベンダー）として受託するベンダーに依頼することで、多重下請け構造のリスクを回避できる。元請は発注者との直接契約において責任を一手に引き受ける形であり、再委託先の管理・品質保証・セキュリティ対応も含めて一括で担う体制を持つ。IPA「情報システム・モデル取引・契約書（第二版）」では、「複数契約関係における発注者の管理コスト増大」が問題として挙げられており*1、元請機能を持つパートナーへの一元化がコスト削減と品質安定の両面で有効である。
内製でアプリ開発を進める場合、技術スタック×保守体制×セキュリティ対応の全領域を自社で賄う必要がある。外注では外注先の選定精度が品質を左右する。どちらにも固有のリスクがあるため、「選定基準を明文化した上で外注し、発注者側が要件定義と品質確認に主体的に関与する」形が、リスクを低減する現実的な方法となる。
まとめ — アプリ開発外注先選定の7基準と3つの判断軸
本稿では、アプリ開発の外注先選定において発注者が押さえるべき評価基準と手順を、IPA・経産省の公的ガイドラインをもとに整理した。要点を3つに集約すると次の通りである。第一に、外注先の評価は技術力・契約形態・セキュリティ・再委託構造・費用透明性を含む7つの基準で行い、評価シートによる客観的な比較を実施する必要がある。第二に、請負契約と準委任契約の違いを理解した上で、自社の開発スタイルに合った契約形態を選ぶことがトラブル防止の基本となる。第三に、本開発の前に試験的な小規模発注を行い、実際の納品物の品質とコミュニケーションの質を確認することで、選定リスクを段階的に低減できる。
よくある質問
アプリ開発の外注先選定にかかる期間はどれくらいか？
選定フロー全体（RFP作成→提案受領→ヒアリング→契約締結）にかかる期間は、案件の複雑さによって異なる。RFP作成を含めると数週間から数カ月程度のリードタイムが発生する。IPA「情報システム・モデル取引・契約書」では、発注者がRFPを用意してから個別契約を締結するまでの段階を標準プロセスとして示しており*1、複数社への提案依頼・ヒアリング・条件整理を丁寧に進めることが品質の高い選定につながる。選定を急ぐと要件定義が不十分になり、開発開始後の追加費用リスクが高まる。
請負契約と準委任契約はどちらが発注者に有利か？
どちらが有利かは開発の性質によって異なる。請負契約は成果物の完成義務をベンダーが負うため、仕様が明確で変更が少ない開発に向いている。準委任契約は成果物完成の保証よりも作業プロセスへの対価を払う形であり、仕様が流動的なアジャイル開発に適している。IPAのアジャイル開発版モデル契約では「アジャイル開発には準委任契約が前提」とされており*2、IPA「情報システム・モデル取引・契約書（第二版）」は両形態の特性を整理した上で、発注者が開発の性質に応じて選択することを推奨している*1。
再委託（多重下請け）が行われているかどうか、どう確認すればよいか？
提案書や契約書に「再委託に関する条項」が含まれているかを確認することが出発点となる。経済産業省の「情報サービス・ソフトウェア産業における中小受託適正取引等の推進のためのガイドライン（令和7年12月改訂）」では、受託企業が第三者に業務を委託する場合、委託内容・管理方法を書面で明示する義務が定められている*3。発注者側からは、「再委託を行う場合は事前に書面で承認を求める」旨を契約に盛り込むことで、再委託先の管理状況を把握できる。
小規模スタートアップへの外注リスクをどう評価するか？
小規模スタートアップへの外注では、技術力の高さと引き換えに、企業の継続性・保守体制・法令対応力のリスクが生じることがある。評価の際は、設立年数・有価証券報告書やIR情報の公開状況・ISO 27001等の認証取得状況・過去の類似案件の完遂実績を確認する。IPA「ソフトウェア開発分析データ集2022」では「信頼性も生産性も低下」という傾向が示されており*5、開発後の保守・運用フェーズを誰が担うかを契約前に合意しておくことがリスク管理の基本となる。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：IPA 独立行政法人情報処理推進機構「情報システム・モデル取引・契約書（第二版）」（2020年）
- *2 出典：IPA 独立行政法人情報処理推進機構「情報システム・モデル取引・契約書（アジャイル開発版）」（2020年、2025年4月更新）
- *3 出典：経済産業省「情報サービス・ソフトウェア産業における中小受託適正取引等の推進のためのガイドライン」（令和7年12月最終改訂）
- *4 出典：IPA 独立行政法人情報処理推進機構「重要情報を扱うシステムの要求策定ガイド」
- *5 出典：IPA 独立行政法人情報処理推進機構「ソフトウェア開発分析データ集2022」（2022年）
- *6 出典：経済産業省「システム管理基準」（令和5年4月26日）
