業務アプリやスマホアプリを外に頼むとき、開発の流れは、発注する側から見て5つの工程に分けられます。工程ごとに、発注する側が決めること、確かめること、受け取ることがあります。
工程ごとの役割分担の例は、情報処理推進機構（IPA）が公開している「情報システム・モデル取引・契約書」（以下、モデル契約）の資料に示されています。受け取ったあとに不具合が見つかったときの扱いは、民法と契約書の定めで決まります。
アプリ開発はどんな順番で進むか
発注する側から見ると、企画と要件定義、設計、開発とテスト、受け入れと運用テスト、運用と保守の5つの順に進みます。モデル契約の工程をもとに、Nue が発注する側から見て5つにまとめました。
- 企画・要件定義何を作るかを決め、要件定義書にまとめる
- 設計画面などの外部設計を確かめて承認する
- 開発・テストテストに使う情報を出し、進み具合を確かめる
- 受け入れ・運用テスト決めた基準で確かめて検収し、自分たちの業務で動かして確かめる
- 運用・保守不具合に気づいたら開発会社に知らせる
図の設計には、IPA の資料でいうシステム外部設計とシステム内部設計を入れています。講演資料の役割分担の例では、外部設計の成果物に画面処理仕様書が入っています。外部設計は、画面など発注する側が見て確かめられるものを含む工程です。
企画と要件定義は、発注する側が決める工程
業務の要件とシステムの要件は、発注する側が企画の段階で、必要ならコンサルタントの支援を受けながら主体的に決め、要件定義書にまとめます。それを受けて、開発の段階で開発会社が主体となって仕様にします（IPA の講演資料「システム開発の健全化に向けて」、2025年4月）。
モデル契約では、要件定義の作業も、発注する側が行い、開発会社が支えます。モデル契約は、この工程の契約を、完成ではなく作業そのものを頼む準委任契約として想定しています。支える側の開発会社も、受けた仕事を注意深く行う義務（善管注意義務）を負います。
開発会社には、提案の段階でも、その時点で予測できるリスクを発注する側に説明する義務がある、という解説も講演資料に載っています。
社内では、業務部門が業務の要件を出し、情報システム部門が、アプリに持たせる機能（機能要件）と、速さや安全さのように機能以外に求めること（非機能要件）を定めて、経営層の承認を受けます。非機能要件の検討には経営層も加わります（講演資料が示す分担）。情報システム部門が無い会社では、この役割を社内の誰が持つかを先に決めておきます。
要件がまとまったら、それをもとに開発会社から見積もりをもらいます。見積もりを工程ごとに出し直してもらう考え方と費用の決まり方はアプリ開発の費用はどう決まるかにまとめています。
設計からテストまでに、発注する側がすること
外部設計を確かめて承認する
外部設計は、発注する側が中身を確かめて承認します。講演資料の役割分担の例では、外部設計を準委任で頼む場合はここを発注する側が主に受け持ち、内部設計は確認に回ります。モデル契約にも「中間資料のユーザによる承認」という条があります。
承認したあとに要件を足したり仕様を変えたりするなら、変更の手続きに沿って委託料や納期を協議するのが望ましい、と講演資料は書いています。委託料や納期が変わるなど契約の内容を変えるときは、書面で変更契約を結びます（モデル契約の第33条）。
テストに使う情報を出す
開発の段階では、テストで確かめる項目（テストケース）を適切に作るための情報を、発注する側が出します。講演資料は、特に外部設計と、検収やテストに関わる部分での情報の提供などを、発注する側の協力として挙げています。
進み具合を確かめ、作業を妨げない
モデル契約では、進み具合や問題点を話し合う連絡協議会を開きます。議事録が届いたら、決めた日数のうちに点検します。議事録は開発会社が作るもので、期間内に書面で理由を示して異議を出さなければ、承認したものとみなされます。
反対に、避けることもあります。協力には、開発会社の作業を妨げないことも含まれます。仕様を固めたあとに大量の追加の要望を強いることや、契約に無い要求を繰り返すことがその例です。開発が契約の目的を果たせなくなったとき、こうしたことが原因の1つとして、発注する側の過失と認められうるとされています（講演資料）。
受け入れでは何を確かめるのか
出来上がったものを受け取るときは、事前に決めておいた検査の基準で確かめ、合格として受け取ります。これを検収と呼びます。モデル契約では、開発の契約の中に、検査仕様書の作成と承認、ソフトウェアの検収の条があり、講演資料はモデル契約の要点に検収基準の明確化を挙げています。何をもって合格とするかは、受け取る前に開発会社と決めておきます。合否を判定できる条件の書き方はAI駆動開発の要件定義の記事に書いています。
検収のあとには、自分たちの業務で動かして確かめる運用テストがあります。講演資料の役割分担の例では、導入・受け入れと運用テストは発注する側が主担当で、開発会社は契約に基づいて支援します。講演資料が引く判決の要旨も、オーダーメイドの開発では、発注する側が社内の意見をまとめ、成果物を検収するなどの役割を分担する必要があるとしています。
完成を約束する請負契約では、民法上、報酬は出来上がったものの引渡しと同時に払うのが基本です（633条）。実際の支払いの時期は契約で決めます。
受け取ったあとに不具合が見つかったら
請負契約で受け取ったものが契約の内容に合っていなければ、発注する側は直すよう求めることができます（民法562条。請負にも559条で当てはまります）。開発会社が負うこの責任を、契約不適合責任と呼びます。
民法の定めでは、不具合を知った時から（受け取った日からではありません）1年以内に開発会社に知らせないと、直すこと、報酬を減らすこと、損害の賠償、契約の解除のいずれも原則として求められなくなります（637条）。開発会社が引き渡しの時に不具合を知っていた場合などは別です。発注する側が出した指示が原因で生じた不具合も、これらを求める理由になりません（636条）。開発会社がその指示が不適当だと知りながら伝えなかった場合は別です。
期間や数え始めの日は、契約書で決めていることがあります。モデル契約にも契約不適合責任の条があります。契約書のその条を確かめ、不具合に気づいたら、その時点で開発会社に伝えておきます。
ストアに出すなら、発注する側が先に用意するもの
iPhone や Android のアプリをストアに出すなら、開発者のアカウントを誰の名義で作るかを、開発の早い段階で決めておきます。以下は、いずれも2026年11月時点の Apple と Google の公式ページの記述です。
Apple に組織として登録するには D-U-N-S 番号が必要です。Dun & Bradstreet が割り当てる9桁の番号で、企業を見分ける情報として広く使われています。App Store では、組織名が販売元として表示されます。Google Play でも組織のアカウントを作るには D-U-N-S 番号が要ります。Google は、番号を持っていなければ、その申請に最長で30日ほどかかることがあるとしています。
出すときには、それぞれのストアの審査があります。Apple は、提出されたアプリやアップデートの50%以上を24時間以内に、90%を48時間以内に審査していると書いています。Google は、送信から公開まで1週間以上かかることを見込んで計画を立てるよう勧めています。公開日が決まっているなら、審査の時間を含めて逆算します。
少しずつ作る進め方を選ぶとき
動くものを見ながら少しずつ決めていくアジャイル開発でも、発注する側の役割は減りません。IPA の「アジャイル開発外部委託モデル契約」では、何を作るかに責任を持つプロダクトオーナーを発注する側の会社が選びます。プロダクトオーナーは、作るものの一覧（プロダクトバックログ）を作って優先順位を変え、出来上がったものの完成と、要求1つずつの完了を確かめます。
社内に適任者がいなければ、開発会社に補佐を頼むことは考えられます。それでも、プロダクトオーナーの職務そのものは開発会社に任せるべきではない、とモデル契約の解説は書いています。IPA の掲載ページは、プロダクトの方向と中身を決めるための主体的で積極的な関与が要り、相応の負担を伴うと書いています。
このモデル契約は準委任契約なので、開発会社は完成の義務を負いません。発注する側は、成果物について請負のような契約不適合責任を問えず、開発会社が注意義務に反した場合に損害の賠償を求める形になります。
よくある質問
要件がまとまっていなくても、開発を頼めますか
頼めます。何を作るかを決めるのは発注する側の仕事ですが、決め方は文書だけとは限りません。Nue のAI受託開発では、解決したいことが1つ決まっていれば始め、最初の2週間で動くものを作って、それを見ながら決めていきます。どこまで作って何を確かめるかはプロトタイプとMVPは何が違うのかとPoCとは？に書いています。
試作の一部を社内で AI を使って作ってみるなら、AI にコードを書かせる道具の1つ、Claude Code の始め方と、使う前に決めることをClaude Codeの使い方にまとめています。