アプリ開発の流れを発注担当者向けに解説｜準備・工程・手法別の進め方

自社アプリの新規開発やリニューアルを検討する企業担当者にとって、発注前に何を整理し、各工程で何を確認・判断するかを把握しておくことは重要です。

開発会社へ依頼する場合も、目的や要件、社内で確認すべき事項を整理しておくことで、認識のずれや手戻りを防ぎやすくなります。

アプリ開発の工程は、開発方法やプロジェクトによって異なります。

 

本記事では、「企画・目的整理」「要件定義」「設計」「開発・実装」「テスト」「ストア申請・リリース」「運用・改善」の7段階に整理して解説します。

あわせて、ウォーターフォールとアジャイルの違い、各工程で発注側が確認・判断するポイント、プラットフォーム活用型の開発方法についても紹介します。

 

アプリ開発を始める前に整理しておくこと

開発会社へ相談する前に、自社内でアプリ開発の目的や必要な機能、予算、希望時期、意思決定の体制などを整理しておくと、初回相談や見積もりの前提を共有しやすくなります。

発注前には、少なくとも以下の項目を確認しておきましょう。

 

• 目的とターゲットユーザー
• 解決したい課題
• 必要な機能の優先順位
• 予算の範囲
• 希望するリリース時期
• 社内の承認・稟議プロセス
• 関係部署と担当者

 

アプリを開発する目的とターゲットユーザーを明確にする

アプリ開発では、アプリを作ること自体を目的にするのではなく、解決したい事業課題やユーザー課題を明確にすることが重要です。

例えば、顧客との継続的な接点を作る、再来店・再購入を促すといった目的が考えられます。

目的が曖昧なままでは、必要な機能や開発の方向性を判断しにくくなります。

 

ターゲットユーザーについても、年齢や性別などの属性だけでなく、どのような場面でアプリを利用するのか、どのような行動を取るのか、何に困っているのかまで整理しておきましょう。

利用場面や課題を具体化することで、アプリで提供すべき機能や体験を検討しやすくなります。

また、目的やターゲットユーザーを担当者だけで決めるのではなく、関係部署と認識を合わせておくことも大切です。

 

あわせて、最終的な方針をどの部署・役職が判断するのかを決めておくと、開発会社との協議や社内承認を進めやすくなります。

解決したい課題と必要な機能の優先順位を整理する

開発会社へ相談する前に、解決したい課題を起点として、アプリに必要と考えられる機能を社内で洗い出しておきましょう。

例えば、「店舗での会員証提示を簡単にしたい」「購入後も顧客との接点を維持したい」など、課題と機能を結び付けて整理すると、必要性を判断しやすくなります。

洗い出した機能は、すべてを最初から実装する前提にせず、初回リリースに必要な機能と、将来的に追加を検討する機能に分けて優先順位を付けます。

 

既存の会員基盤や基幹システムなどと連携する可能性がある場合は、対象となるシステムも確認しておくことが重要です。

この段階で行うのは、あくまで開発会社へ相談するための社内要求の整理です。

詳細な機能要件や性能・セキュリティなどの非機能要件は、後の要件定義工程で開発会社と検討し、合意していきます。

予算・希望時期・社内体制を確認する

発注前には、予算の上限だけでなく、どの程度の範囲まで検討できるのかを社内で確認しておきましょう。

アプリ開発の費用は、搭載する機能や開発方法、開発期間、体制などによって変わるため、一定の幅を持たせて整理しておくと開発会社とも相談しやすくなります。

希望するリリース時期がある場合は、その時期だけでなく、その理由も共有できるようにします。

 

キャンペーンの開始や既存アプリ・サービスの契約満了など、動かしにくい期限がある場合は、特に早い段階で明確にしておくことが重要です。

また、開発期間だけでなく、社内の稟議や法務、情報システム、セキュリティなどの確認に必要な期間も考慮し、現実的なスケジュールを検討します。

 

あわせて、プロジェクト責任者と実務担当者、関係部署、最終的な意思決定者を明確にしましょう。

開発中には画面や仕様のレビュー、社内承認なども発生するため、必要なタイミングで確認・判断できる社内体制を整えておくことが大切です。

アプリ開発費用の相場や内訳については、以下の記事で詳しく解説しています。

アプリ開発の流れを7つの工程で解説

アプリ開発の工程は、開発方法やプロジェクトの内容によって分け方が異なります。

ここでは、アプリ開発の流れを「企画・目的整理」「要件定義」「設計」「開発・実装」「テスト」「ストア申請・リリース」「運用・改善」の7つの工程に整理して解説します。

工程	主な実施内容	主な成果物	発注側が確認・判断すること
1｜企画・目的整理	目的・対象ユーザー・課題・提供価値を整理する	企画書、プロジェクト概要、要求一覧など	目的・対象ユーザーの認識、企画を具体化する範囲、次工程へ進む判断者
2｜要件定義	必要な機能・性能・外部連携・セキュリティなどを具体化する	要件定義書、要件一覧など	機能の優先順位、今回の対応範囲、変更時の扱い、承認者
3｜設計	画面・操作フローやシステム構造、データフローなどを設計する	画面設計書、システム設計書など	画面・操作性、ブランド要件、関係部署の確認、画面確定の期限
4｜開発・実装	設計に基づいてアプリやサーバー側の機能を実装する	アプリのビルド、プログラムなど	進捗、課題・遅延、仕様確認事項、追加要望・仕様変更への対応
5｜テスト	要件どおりに動作するか、品質や安全性に問題がないかを検証する	テスト仕様書、テスト結果、不具合一覧など	受け入れテストの範囲、不具合の優先順位、リリース基準
6｜ストア申請・リリース	ストア申請・審査への対応を行い、公開する	ストア掲載情報、申請データ、リリース版など	納品条件、公開時期、管理権限、審査で修正が必要になった場合の対応
7｜運用・改善	利用状況を確認し、不具合対応や機能改善を継続する	運用レポート、改修計画など	保守運用の範囲、改修予算、運用担当者、改善の優先順位

成果物はプロジェクトや開発会社、契約内容などによって異なるため、上表は代表例としてご覧ください。

1｜企画・目的整理

企画・目的整理は、アプリで解決したい事業上の課題やユーザーの課題、対象ユーザー、提供する価値を整理し、プロジェクトの方向性を具体化する工程です。

発注前に社内で整理した内容を開発会社と共有し、実現可能性や想定する開発規模などを確認しながら企画を具体化していきます。

開発会社とは、アプリを開発する目的や対象ユーザー、解決したい課題、必要と考えている機能などを共有します。

 

企画書やプロジェクト概要、要求一覧などに整理する場合もありますが、成果物の名称や範囲はプロジェクトによって異なります。

発注側は、社内で合意した目的や対象ユーザーが開発会社にも正しく共有されているかを確認しましょう。

また、企画内容を誰が承認し、どの段階で次の要件定義へ進むのか、意思決定のルールを決めておくことも重要です。

 

なお、ネイティブアプリやWebアプリなど、採用するアプリの種類によって開発方法や必要な工程・工数は異なります。

種類ごとの特徴については、以下の記事をご覧ください。

2｜要件定義

要件定義とは、アプリで実現することと必要な機能・性能を、発注側と開発側で合意する工程です。

企画段階で整理した要求をもとに、実際の開発範囲を具体化していきます。

開発会社と機能要件や非機能要件、対象OS・端末、外部システムとの連携、セキュリティ、運用体制などを整理します。

 

あわせて、機能の優先順位や予算・スケジュールの範囲、成果物、双方がどのような方法で内容を確認・合意するかも決めておくことが重要です。

合意した内容は、要件定義書などの文書として残し、後工程でも確認できる状態にします。

 

発注側は特に、どの機能を優先するのか、どこまでを今回の開発範囲に含めるのかを明確にしましょう。

また、開発途中で変更が発生した場合の手続きや影響の確認方法、要件を最終承認する担当者も決めておく必要があります。

要件整理やRFP作成を含む企画段階から支援が必要な場合は、アイリッジのアプリ企画／RFP作成支援もご確認ください。

3｜設計

設計は、要件定義で合意した内容をもとに、アプリの画面や操作フロー、UI・UX、システム構造、データフローなどを具体化する工程です。

開発会社では、ユーザーから見える部分を整理する外部設計と、システム内部の処理などを整理する内部設計を進めます。

発注側は、画面や操作フローが想定するユーザーの利用場面に合っているかに加え、自社のブランドやデザイン上の要件が反映されているかを確認します。

 

情報システム部門や事業部門など、確認が必要な関係部署もあらかじめ決めておきましょう。

設計段階で確認や意思決定が遅れると、開発・実装など後工程のスケジュールにも影響する可能性があります。

そのため、画面を確定する期限を設定するとともに、機能要件の確認とデザインの確認を分けるなど、論点を整理しながら承認を進めることが大切です。

4｜開発・実装

開発・実装は、要件定義や設計で決めた内容に基づき、アプリやサーバー側に必要な機能を実装する工程です。

開発会社が設計書などに沿って実装を進め、アプリとして動作する状態へ仕上げていきます。

発注側が実装作業そのものを担当しない場合でも、開発会社に任せきりにするのではなく、進捗や課題を継続的に確認することが重要です。

 

定例会などで何を確認するかを決め、「進捗率50％」などの数値についても、何をもってその進捗率とするのか、認識を合わせておきましょう。

また、課題や遅延、発注側の判断が必要な仕様確認事項を把握します。

追加要望が生じた場合は、そのまま実装を依頼するのではなく、スケジュールや費用、既存機能への影響範囲を確認し、あらかじめ決めた方法で仕様変更を承認することが大切です。

5｜テスト

テストは、実装したアプリが要件どおりに動作するか、品質や安全性に問題がないかを確認する工程です。

開発会社では、個々の機能を確認する単体テスト、機能同士の連携を確認する結合テスト、システム全体を確認するシステムテストなどを実施します。

発注側も、実際の業務やユーザーの利用場面を想定した受け入れテストについて、どこまで自社で確認するのかを決めておく必要があります。

 

必要に応じて検証端末やテストデータを準備し、自社が確認すべき操作シナリオを整理しておきましょう。

不具合が見つかった場合は重大度や影響範囲に応じて優先順位を付け、修正後に再確認します。

すべての不具合を一律に扱うのではなく、事前に定めた品質基準やリリース基準を踏まえて対応を判断することが重要です。

 

テスト不足は動作不良やセキュリティ上の問題につながる可能性もあるため、必要なテスト期間と予算を計画に含めておきます。

6｜ストア申請・リリース

ストア申請・リリースは、完成したアプリについて必要な納品物を確認するとともに、App StoreやGoogle Playなどへの申請・審査を経てユーザーへ公開する工程です。

納品、ストアへの申請、審査、公開はそれぞれ異なる手続きであり、「納品された時点で公開が完了する」とは限りません。

ストア申請では、アプリ本体に加えて、説明文やスクリーンショットなどの掲載情報を準備します。

 

審査の結果によっては問題への対応や修正が必要になる場合があるため、公開希望日には余裕を持たせることが大切です。

Appleでは審査提出前に必要なメタデータを入力し、手動・自動などのリリース方法を選択できます。

また、アップデートについてはApple、Google Playとも段階的な公開に対応しています。

 

発注側は、アプリ本体だけでなく報告書など契約上の納品物がそろっているかを確認します。

さらに、開発者アカウントやストア掲載情報を誰が管理・編集できるのか、公開後の権限も確認しておきましょう。

ストア審査の通過や実際の公開までを納品条件に含めるかについても、契約前に開発会社と取り決めておくことが重要です。

7｜運用・改善

運用・改善は、アプリのリリース後に利用状況を確認し、不具合への対応や機能改善などを継続して行う工程です。

公開後もOSや端末、ストア側の仕様変更などに対応しながら、安定して利用できる状態を維持していきます。

運用では、利用状況や設定したKPIを確認するとともに、不具合への対応やユーザーの声を踏まえた機能改善を行います。

 

改善を継続するには、誰が状況を確認し、どのような手順で改修を判断するのか、運用・改善の体制を決めておくことも重要です。

発注側は、開発会社との保守運用契約に何が含まれているのかを確認し、必要な改修予算や社内の運用担当者を確保しておきましょう。

 

アプリ開発の主な手法

アプリ開発の進め方として代表的なウォーターフォール開発とアジャイル開発は、工程の進め方や仕様変更への対応方法、発注側の関わり方などが異なります。

どちらか一方が優れているわけではなく、要件の確定度や変更の可能性、社内体制など、プロジェクトの条件に応じて選ぶことが重要です。

比較項目	ウォーターフォール開発	アジャイル開発
進め方	要件定義、設計、開発、テストなどの工程を順番に進める	短い単位で設計・開発・テスト・レビューなどを繰り返す
向いているプロジェクト	要件や仕様を事前に具体化しやすく、計画に沿って進めたい場合	ユーザーの反応などを確認しながら、機能や優先順位を調整したい場合
仕様変更への対応	後工程で変更すると、完了済みの設計や実装などへの影響が広がる場合がある	開発対象の優先順位を見直し、以降の反復へ変更を組み込みやすい
期間・予算の考え方	開発範囲を事前に具体化し、全体計画を立てて管理する	期間・体制・開発範囲などの管理方法をあらかじめ決め、優先順位を調整しながら進める
発注側の関与度	各工程の成果物を確認し、次工程へ進む判断・承認を行う	定期的なレビューに参加し、優先順位や仕様について継続的に判断する
成果物・ドキュメント	工程ごとに設計書やテスト関連資料などを整理しやすい	動作するソフトウェアを重視しつつ、重要な仕様や判断内容など必要な情報を記録する

なお、実際の進め方や契約形態、成果物の範囲はプロジェクトによって異なります。

比較表は両手法の典型的な違いを整理したものであり、プロジェクトの条件を踏まえて開発会社と具体的な進め方を確認することが大切です。

ウォーターフォール開発

ウォーターフォール開発は、要件定義、設計、開発・実装、テストなどの工程を順番に完了させながら進める開発手法です。

初期段階で可能な範囲まで要件や開発範囲を具体化し、合意した計画に沿って開発を進めます。

工程と成果物を段階ごとに整理するため、全体計画や進捗状況を確認しやすい点が特徴です。

 

一方、後工程に進んでから仕様変更が発生すると、すでに完了した設計や実装などにも修正が必要となり、手戻りの範囲が大きくなる可能性があります。

そのため、開発開始前に要件を可能な範囲で具体化し、発注側と開発側で認識を合わせておくことが重要です。

 

発注側は、開発会社へ要望を伝えて終わりではなく、各工程で成果物や要件との整合性を確認します。

どの状態になればその工程を完了とするのかをあらかじめ共有し、次の工程へ進む際に必要な確認・承認を行う体制を整えておきましょう。

アジャイル開発

アジャイル開発は、短い単位で設計・開発・テスト・レビューなどを繰り返し、優先順位に応じて機能や仕様を改善していく開発手法です。

開発を始める前にすべての詳細を固定するのではなく、まずプロジェクトの目的や要求、優先順位を整理し、バックログなどをもとに各サイクルで取り組む開発対象を決めます。

開発中に得られたフィードバックを踏まえて優先順位や詳細を見直せるため、仕様変更へ対応しやすい一方、全体の開発範囲や期間、予算をどのように管理するかを事前に決めておくことが重要です。

 

発注側も定期的なレビューやフィードバックに参加し、機能の優先順位や次に開発する内容について継続的に判断します。

また、アジャイル開発でもドキュメントが不要になるわけではありません。

重要な仕様や合意事項、意思決定の内容など、プロジェクトを進めるうえで必要な情報は記録・共有できる状態にしておきましょう。

 

ウォーターフォール開発の流れ

ウォーターフォール開発は、要件定義、設計、開発・実装、テスト、納品・リリースと、工程を順番に完了させながら進める手法です。

前工程で合意した内容を次工程の前提として開発を進めるため、各段階で内容を確認・承認することが重要です。

アプリ開発全体の7工程のうち、本セクションではウォーターフォール開発における「要件定義」から「納品・リリース」までの5工程を詳しく解説します。

 

「企画・目的整理」と公開後の「運用・改善」は、本記事の7工程の説明で扱います。

ウォーターフォール開発でも、開発途中に変更や手戻りが発生する場合があります。

後工程で変更すると、すでに完了した設計や実装などにも修正が及ぶ可能性があるため、各工程で内容を確認しながら計画的に進めることが大切です。

 

工程管理にはガントチャートなどを活用する方法もありますが、具体的な管理方法はプロジェクトによって異なります。

1｜要件定義

要件定義とは、アプリで実現することと必要な機能・性能を、発注側と開発側で合意する工程です。

企画・目的整理で決めた方向性をもとに、実際にどこまで開発するのかを具体化します。

開発会社は、必要な機能を整理する機能要件に加え、性能や可用性などの非機能要件、対象OS・端末、外部システムとの連携、セキュリティ、運用体制などを発注側と確認します。

 

さらに、機能の優先順位、予算・スケジュールの範囲、成果物と合意方法、仕様変更が発生した場合の扱いなども整理します。

合意した内容は、要件定義書やプロジェクト計画書など、後から確認できる文書として残しておくことが重要です。

 

発注側は、初回リリースに必要な必須機能と将来的に追加する機能を区分し、非機能要件をどこまで確認するのか、今回の開発で対応しない範囲はどこかを明確にします。

また、仕様変更によって費用や期間に影響が生じる場合の確認方法と、要件を最終承認する担当者も決めておきましょう。

2｜設計

設計は、要件定義で合意した内容を、実際に開発できる形へ具体化する工程です。

ユーザーが目にする画面や操作方法などを定める外部設計と、システム内部の処理などを定める内部設計を進めます。

開発会社は、UIをはじめ、画面一覧、画面遷移、操作フロー、システム構造、データフローなどを具体化し、設計書へ落とし込みます。

 

必要に応じてデザインルールやブランド要件、ユーザー・管理者などの権限、データの扱いについても整理します。

発注側は、画面や操作フローが要件と合っているか、自社のブランドやデザイン上の要件が反映されているかを確認します。

事業部門や情報システム部門など複数部署の確認が必要な場合は、各部署の確認期限と画面を確定する期限をあらかじめ決めておくことが重要です。

 

機能要件の確認とデザインの確認を分けるなど論点を整理し、合意した判断基準と期限に沿って設計を確定しましょう。

確認や意思決定が遅れると、開発・実装など後工程のスケジュールにも影響する可能性があります。

3｜開発・実装

開発・実装は、要件定義と設計で合意した内容に基づいて、アプリ側やサーバー側の機能、必要な外部システムとの連携などを実装する工程です。

開発会社は設計書に沿って実装を進めます。

発注側がプログラミングなどの実装作業そのものを行わない場合でも、定例会などを通じて進捗や未決事項、課題、遅延、仕様に関する確認事項を共有しながら進めます。

 

発注側は、単に「何％進んだか」だけを見るのではなく、何をもって完了とするのか、どの単位で進捗を確認するのかを開発会社とあらかじめ認識を合わせておくことが重要です。

例えば、定例会で確認する項目や進捗率の定義、課題・遅延の有無、発注側の回答待ち事項などを決めておくと、双方の認識を合わせやすくなります。

追加要望や仕様変更が発生した場合は、既存の設計やスケジュール、費用などへの影響範囲を確認したうえで、決められた承認方法に沿って対応を判断します。

 

契約上の対応範囲に含まれない要望をどのように扱うかについても、事前にルールを決めておきましょう。

4｜テスト

テストは、実装したアプリが要件どおりに動作するか、品質や安全性に問題がないかを確認する工程です。

開発会社では、個々の機能を確認する単体テスト、機能間の連携を確認する結合テスト、システム全体を確認するシステムテストなどを行い、不具合が見つかった場合は修正します。

発注側も、実際の業務やユーザーの利用場面を想定した受け入れテストについて、どの範囲を自社で確認するのかを決めておく必要があります。

 

検証端末やテストデータを準備し、会員登録や購入など自社で確認するシナリオ、確認担当者を整理しておきましょう。

不具合が見つかった場合は、重大度や影響範囲に応じて優先順位を決め、修正後に再確認します。

すべての不具合を一律に扱うのではなく、事前に定めた品質基準やリリース可否の基準に沿って対応を判断することが重要です。

 

特にセキュリティ上重大な不具合が確認された場合は、影響を確認したうえでリリース可否を慎重に判断する必要があります。

発注側が受け入れテストへ参加する時間も含め、必要なテスト期間と予算をあらかじめ計画に組み込んでおきましょう。

5｜納品・リリース

納品・リリースでは、完成したアプリや関連成果物を受け取るだけでなく、必要に応じてApp StoreやGoogle Playへの申請・審査を経て公開まで進めます。

納品、ストア申請、ストア審査、公開はそれぞれ異なるため、どこまでを開発会社の対応範囲とするかを契約前に明確にしておくことが重要です。

開発会社からの納品時には、契約内容に応じてソースコードや設計書、テスト結果、各工程の報告書などの成果物を確認します。

 

また、開発者アカウントなどのアカウント情報や管理権限についても、公開後に誰が管理するのかを確認します。

ストアで公開する場合は、アプリ本体だけでなく、ストア掲載情報や画像、説明文など必要な情報を準備して申請します。

Appleでは、必要なメタデータとビルドを用意してApp Reviewへ提出し、問題が確認された場合は対応したうえで公開へ進む仕組みです。

 

リリース方法も、承認後の手動リリースや自動リリースなどから選択できます。

Google Playでも、リリースを準備して審査・公開へ進めます。

エラーなどが確認された場合は、解消してから公開する必要があります。

 

発注側は契約前に、ストア審査の通過を納品条件に含めるのか、公開作業や審査で修正を求められた場合の対応を誰が担うのかを確認しておきましょう。

あわせて、公開後のアカウント・管理権限を誰が保有するのか、保守運用をいつから開始するのかも明確にしておくことが大切です。

 

アジャイル開発の流れ

アジャイル開発は、短いサイクルで設計・開発・テスト・レビューを繰り返し、優先順位やフィードバックに応じて改善していく開発手法です。

開発開始前の計画や要求整理が不要になるわけではなく、目的や優先順位を明確にしたうえで、詳細を段階的に具体化していきます。

ここでは、アジャイル開発の流れを次の5工程に整理します。

 

1. 目的と仮説を整理する
2. 優先順位を決めてバックログを作成する
3. 短いサイクルで設計・開発・テストを行う
4. レビューとフィードバックを行う
5. リリースと改善を繰り返す

 

アジャイル開発では、この流れを一度だけ進めて終了するのではなく、開発した内容を確認しながらバックログや優先順位を見直し、反復して開発を進めます。

発注側にも継続的な確認と意思決定が求められるため、開発会社へ任せきりにせず、判断できる担当者や体制を整えておくことが重要です。

1｜目的と仮説を整理する

目的と仮説の整理は、アジャイル開発で何を実現し、何を検証するのかを開発チームと共有する工程です。

発注前に社内で整理した内容をもとに、解決したい課題や対象ユーザー、提供価値、成功指標、検証したい仮説などを具体化します。

開発会社とは、どのようなユーザー課題を解決するのか、アプリによってどのような価値を提供するのかを確認し、初期リリースで検証する範囲を整理します。

 

アジャイル開発でも、開発開始前にプロジェクトの目的やプロダクトの方向性を共有することが重要です。

発注側は、「何を検証するのか」「どの状態を成功とみなすのか」を確認し、機能の優先順位を誰が決めるのかを明確にします。

また、最初のリリースに含める範囲と含めない範囲を分け、開発チームと認識を合わせておきましょう。

2｜優先順位を決めてバックログを作成する

バックログとは、実装候補となる機能や改善事項、解決すべき課題などを、優先順位とともに管理する一覧です。

目的や仮説をもとに開発対象を整理し、どの項目から取り組むのかを決めます。

開発チームは、ユーザーにとっての価値や事業上の重要度、技術的な依存関係などを踏まえて開発対象を整理します。

 

必要性が十分に確認できていない機能まで初期段階ですべて実装するのではなく、優先順位に基づいて初期リリースの範囲を決め、必要に応じて後のサイクルで機能を追加していきます。

MVPとして必要な範囲から検証を始める方法もありますが、適切な範囲はプロジェクトによって異なります。

発注側は、優先順位を決める基準や初期リリースに含める機能、後回しにする機能を確認します。

 

また、レビュー結果などを受けてバックログを変更するときの承認方法を決め、予算や期限との整合性を確認しながら優先順位を見直すことが重要です。

3｜短いサイクルで設計・開発・テストを行う

この工程では、バックログから各サイクルで取り組む対象を選び、設計・開発・テストを短い単位で繰り返します。

サイクルの具体的な期間は、採用する開発手法やプロジェクトの内容、チームの体制などによって異なるため、一律ではありません。

開発チームは、サイクルごとに実装する範囲を決め、設計・開発・テストを進めます。

 

その際、何をもって完了とするのかをあらかじめ定め、技術的な課題や他機能との依存関係も確認します。

予定していた項目が完了しなかった場合は、次のサイクルへ持ち越すのか、優先順位を変更するのかを整理します。

発注側は、各サイクルの開発対象と完了条件を確認し、仕様について判断を求められた場合に回答できる期限や担当者を決めておきましょう。

 

追加要望が生じた場合も、その場で無条件に追加するのではなく、既存の優先順位や予算、期限への影響を確認したうえで判断します。

また、サイクルごとの成果をレビューできる社内担当者を確保しておくことも必要です。

4｜レビューとフィードバックを行う

レビューとフィードバックは、実際に動くアプリや機能を発注側と開発側で確認し、期待していた状態との差分や次に対応すべき内容を整理する工程です。

アジャイル開発では、発注側も継続的に開発へ関与し、必要な判断を行うことが求められます。

開発チームと発注側は、完成した機能を確認し、進捗状況や課題、期待との差分、追加・変更したい内容などを共有します。

 

その結果を踏まえて、次のサイクルで対応する項目やバックログの優先順位を検討します。

発注側はレビューへ参加するだけでなく、フィードバックを返す期限や、意見が分かれた場合の最終決定者を明確にしておきましょう。

判断が遅れると次のサイクルで取り組む内容を確定できない可能性があるためです。

 

レビューの頻度や参加者については一律に決めるのではなく、プロジェクトの進め方や体制に合わせて設定します。

5｜リリースと改善を繰り返す

リリースと改善では、検証可能な単位で機能を提供し、利用状況やフィードバックを確認しながら、次に改善する内容を決めます。

アジャイル開発では、初回リリース後も開発を継続し、必要に応じて機能追加や改善を繰り返す進め方があります。

開発チームは、リリース後の結果やフィードバックを確認してバックログを見直し、次に対応する機能追加や修正を検討します。

 

進捗や成果物、重要な仕様や意思決定についても必要な情報を文書として残し、チーム内で共有できる状態にします。

アジャイル開発では動くソフトウェアを重視しますが、ドキュメント自体を不要とする考え方ではありません。

発注側は、リリース可否や検証するKPI、改善対象、次回の優先順位を確認し、結果に応じて開発を継続するのか、方向性を見直すのか、終了するのかを判断します。

 

また、合意した内容や判断の経緯、対応範囲を後から確認できるよう、成果物や意思決定記録の保管方法も決めておきましょう。

 

プラットフォーム活用型のアプリ開発フロー

プラットフォーム活用型は、あらかじめ用意された標準機能や共通基盤を活用しながら、要件に応じて設定・外部システム連携・追加開発などを行う進め方です。

スクラッチ開発とすべての工程が同じではありませんが、企画・要件整理、デザイン、テスト、ストア申請・リリース、運用・改善などは必要です。

開発時は、まず標準機能で対応できる範囲を確認し、自社固有の要件について追加開発や外部連携が必要かを整理します。

 

プラットフォームを利用すれば常に低コスト・短期間になるとは限らず、必要な機能や連携内容、カスタマイズの範囲によって工程や工数は変わります。

プラットフォーム活用型の一例として、アイリッジではアプリビジネスプラットフォーム「APPBOX」を提供しています。

APPBOXでは標準機能に加え、モジュールの組み合わせや外部システムとの連携、追加開発などに対応しています。

プラットフォーム活用型とは

プラットフォーム活用型とは、アプリ開発に必要な標準機能や共通基盤を利用し、自社の要件に合わせて設定やデザイン調整、外部システムとの連携、必要に応じた追加開発などを組み合わせる開発方法です。

すべてを個別に設計・実装するスクラッチ開発とは異なり、利用できる標準機能がある部分では、それを前提に要件や設計を検討できます。

一方、自社独自の機能や既存システムとの連携が必要な場合は、追加の設計・開発が必要になることがあります。

 

そのため、「プラットフォームを使えば開発作業がなくなる」という意味ではありません。

また、プラットフォーム活用型とノーコード・ローコードは必ずしも同義ではありません。

どこまで設定のみで対応できるか、どこから開発が必要になるかは、利用するプラットフォームや要件によって異なります。

 

例えば、APPBOXは必要なモジュール（SDK）を組み合わせて利用できるアプリビジネスプラットフォームです。

フリーレイアウト、プッシュ通知、アプリ内メッセージ、クーポンなどの標準機能に加え、外部システム・他社サービスとの連携や追加開発にも対応しています。

プラットフォーム活用型でアプリを開発する流れ

プラットフォーム活用型でも、企画からリリース、運用・改善までの基本的な検討は必要です。

ただし、標準機能や共通基盤を利用できる部分では、スクラッチ開発とは設計・実装の作業内容や工数が変わります。

 

目的・課題・対象ユーザーを整理する

 

発注側がアプリの目的や解決したい課題、対象ユーザーを整理し、提供会社と共有します。

提供会社は要望を確認し、プラットフォームを利用した実現方法を検討します。

 

必要な機能と優先順位を整理する

 

発注側と提供会社で必要な機能を洗い出し、初回リリースに含める機能などの優先順位を整理します。

 

標準機能で対応できる範囲を確認する

 

提供会社は必要な機能とプラットフォームの標準機能を照合します。

発注側は、標準機能の仕様が自社の要件を満たしているかを確認します。

 

追加開発・外部連携が必要な範囲を整理する

 

標準機能だけでは対応できない要件について、追加開発や既存の会員システムなどとの外部連携が必要かを確認します。

発注側は、必要性や優先順位、開発範囲を判断します。

 

デザインや画面を調整する

 

ブランド要件や利用者の操作性などを踏まえて画面・デザインを調整します。

発注側は、自社のブランドルールや必要な画面・導線が反映されているかを確認します。

 

テストする

 

設定した標準機能や追加開発した機能、外部システムとの連携などを検証します。

発注側も必要な受け入れテストを行い、要件どおり利用できるかを確認します。

 

ストア申請・リリースする

 

必要なストア掲載情報などを準備し、申請・審査を経て公開します。

発注側は公開時期や管理権限、リリース可否などを確認します。

 

運用・改善する

 

公開後は利用状況を確認し、必要に応じて設定変更や機能改善、追加開発などを検討します。

発注側は運用体制や改善の優先順位を判断します。

スクラッチ開発とプラットフォーム活用型の工程の違い

スクラッチ開発とプラットフォーム活用型では、企画や要件定義、テスト、リリースなど共通して必要となる工程がある一方、設計・実装などの進め方や作業量が異なります。

特にプラットフォーム活用型では、標準機能で対応できる部分と、追加開発・外部連携が必要な部分を切り分けることが重要です。

比較項目	スクラッチ開発	プラットフォーム活用型
企画・目的整理	目的・課題・対象ユーザーなどを整理する	同様に目的・課題・対象ユーザーなどを整理する
要件定義	必要な機能・性能などを個別に具体化する	要件を整理したうえで、標準機能で対応できる範囲と追加対応が必要な範囲を切り分ける
設計	要件に応じて画面やシステム構造などを設計する	標準仕様を活用できる部分では、それを前提に画面や設定を調整する。独自要件がある場合は追加設計が必要になる
開発・実装	設計に基づいて必要な機能を個別に実装する	標準機能を利用し、対応できない要件について必要に応じて追加開発を行う
外部システム連携	連携先の仕様に合わせて設計・実装する	プラットフォームが備える連携機能を利用できる場合がある。対応していない連携では追加開発が必要になる場合がある
テスト	実装した機能やシステム全体を検証する	標準機能の設定内容、追加開発部分、外部連携などを含めて検証する
ストア申請・リリース	必要な申請・審査対応を行って公開する	同様に必要な申請・審査対応を行って公開する
運用・改善	保守や機能改修などを継続する	管理機能などを利用しながら運用し、必要に応じて設定変更・機能追加・追加開発などを行う
自社の確認・判断	要件、設計、仕様変更、テスト、リリースなど各工程で判断する	各工程での判断に加え、標準機能を採用する範囲と追加開発する範囲を判断する
カスタマイズ範囲	技術的・予算的な条件などの範囲内で個別設計・開発を検討できる	プラットフォームの仕様・拡張方法によって対応範囲が異なり、追加開発できる内容もサービスごとに異なる

プラットフォーム活用型は、標準機能で自社要件をどこまで満たせるかによって作業内容が大きく変わります。

そのため、スクラッチ開発より「工程が少ない」「短期間になる」「費用を抑えられる」と一律に判断せず、必要な機能や外部連携、カスタマイズの範囲を確認したうえで比較することが大切です。

具体的な選択肢を検討する場合は、APPBOXのサービス内容もご確認ください。

 

アプリ開発にかかる期間の考え方

アプリ開発にかかる期間は、機能数や外部システムとの連携、開発方法、ストア審査、発注側の確認・承認などによって変わるため、一律には決められません。

自社のプロジェクトに必要な工程と作業内容を整理したうえで、開発会社とスケジュールを確認することが重要です。

期間に影響する主な要因は、以下のとおりです。

 

• 機能数や機能の複雑さ
• 外部システムとの連携の有無や内容
• スクラッチ開発、プラットフォーム活用型などの開発方法
• 対象とするOSや端末
• 画面やデザインの確認・承認にかかる時間
• 必要なテストの範囲
• App StoreやGoogle Playなどのストア審査
• 発注側の確認・承認にかかる時間
• 開発チームの体制
• 開発途中に発生する仕様変更

 

例えば、必要な機能や外部連携が増えれば、要件定義・設計・実装・テストなどで確認・作業する範囲も広がります。

また、開発作業だけでなく、デザインの社内確認や仕様の承認、ストア審査などもリリースまでのスケジュールに影響します。

そのため、「アプリ開発には○カ月かかる」と一律の期間を前提にするのではなく、自社の要件や確認・承認プロセスを踏まえてスケジュールを検討しましょう。

 

アプリ開発の工程別の期間や、スケジュールを立てる際の考え方については、以下の記事で詳しく解説しています。

アプリ開発をスムーズに進めるポイント

アプリ開発をスムーズに進めるには、開発会社側の作業だけでなく、発注側が社内承認や意思決定、見積もり・契約条件の確認を滞りなく進めることが重要です。

発注後の手戻りや認識のずれを防ぐためにも、発注・進行時に必要な確認事項を整理しておきましょう。

特に、社内ルールや承認プロセスを確認したうえで、それらを開発会社へ共有し、プロジェクトの進行計画に反映する必要があります。

 

また、複数社へ見積もりを依頼する場合は同じ要件・条件を提示し、価格だけでなく、対応範囲などの条件もそろえて比較することが大切です。

要件や前提条件を整理したRFPなどを準備しておくと、各社へ同じ条件を提示しやすくなり、見積もりの比較も進めやすくなります。

社内ルールと承認プロセスを確認する

アプリ開発を発注する前には、自社の社内ルールやコンプライアンスに沿って、必要な確認・承認手続きを整理しておくことが重要です。

確認漏れがあると、開発途中で仕様変更や再確認が必要になり、手戻りが発生する場合があります。

具体的には、稟議・決裁権限や発注・契約手続きに加え、法務、情報セキュリティ、個人情報・データの取り扱い、ブランド・デザインなどについて、どの部署の確認が必要かを洗い出します。

 

あわせて、関係部署と最終承認者を明確にし、それぞれの確認に必要な期間も把握しておきましょう。

発注側では「確認項目／担当部署・担当者／承認者／確認期限」などを一覧化しておくと、いつ誰に確認を依頼すべきかを把握しやすくなります。

開発スケジュールを検討する際も、開発会社の作業期間だけでなく、自社内の確認・承認に必要な期間を考慮することが大切です。

開発会社に社内の稟議・確認フローを共有する

社内の確認・承認プロセスを整理したら、プロジェクトの進行に影響する内容を開発会社へ共有します。

契約や仕様の確定、デザイン承認、リリースなど、どの工程で誰の承認が必要になるのかを伝え、進行計画へ反映してもらいましょう。

例えば、各レビューに必要な日数、定例会に参加する部署・担当者、法務・セキュリティ・ブランド確認を行うタイミングなどを共有します。

 

社内承認に一定の時間が必要な場合、それを開発会社が把握していなければ、確認待ちによって後続工程の開始時期に影響する可能性があります。

また、承認が予定より遅れる場合の連絡方法や、意思決定者が不在の場合に誰が代わって判断するのかも決めておくと安心です。

発注側は社内フローを把握するだけでなく、開発会社がスケジュールへ組み込める粒度で共有することがポイントです。

複数社の見積もりを条件まで含めて比較する

複数の開発会社から見積もりを取得する場合は、金額だけでなく、各社がどこまでの作業を見積もりに含めているのかを確認し、条件をそろえて比較することが重要です。

比較条件が異なるままでは、単純な金額差だけで適切に判断できません。

まず、各社に同じ目的・ターゲットユーザー・要件・前提条件を提示し、見積もり対象となる範囲を確認します。

 

初期開発と保守運用、外部システム連携や追加開発、デザイン、テスト、データ移行、マニュアル・研修、ストア申請・審査対応など、どこまで含まれているかを比較しましょう。

例えば、以下のような比較表を用意すると条件を整理しやすくなります。

比較項目	A社	B社	C社
対応範囲
初期費用
保守運用費
開発期間
外部システム連携
デザイン対応
テスト範囲
ストア申請・審査対応
納品物
サポート体制
追加費用が発生する条件

納品物やソースコード・権利、管理アカウントの扱いについても確認しておくと、条件の違いを把握しやすくなります。

見積金額の安さだけで良否を判断せず、自社が求める要件と各社の見積もり条件が一致しているかを確認しましょう。

開発会社そのものの実績や得意分野、支援範囲などを比較したい場合は、以下の記事も参考にしてください。

見積書・契約書・納品条件を確認する

開発会社を決める際は、見積書で「何にいくらかかるのか」を確認するとともに、契約書で双方の責任範囲や権利、検収・納品などの条件を確認することが重要です。

見積書と契約書では役割が異なるため、分けて確認しましょう。

見積書では、開発範囲や対象機能、作業期間、人員配置、費用などを確認します。

 

さらに、要件変更や追加開発が発生した場合に、どのような条件で追加費用や期間変更が生じるのかも確認しておくことが大切です。

契約書では、納品物、検収条件、品質基準、不具合対応の範囲、保証期間、支払い条件、契約解除条件などを確認します。

加えて、著作権・知的財産権やソースコードの納品有無、アプリストアの管理アカウント、外部サービスの契約名義など、開発後の管理に関わる事項も確認しておきましょう。

 

ストア公開を伴う場合は、ストア申請や審査で修正を求められた際の対応範囲、審査通過を納品条件に含めるか、公開後の保守運用をいつから開始するかについても取り決めておく必要があります。

また、将来、契約を終了した場合に、データや必要な成果物をどのような形で返却・引き継ぐのかも確認しておくと安心です。

契約条件や権利の扱いは契約内容によって異なるため、判断に迷う事項は自社の法務・契約担当者へ確認してください。

 

費用相場や見積もりの内訳について詳しく知りたい場合は、以下の記事も参考にしてください。

アプリ開発でよくある質問

アプリ開発を検討する際は、相談前の準備や開発期間、開発手法の選び方などで迷うことがあります。

ここでは、企業のアプリ開発・発注担当者が抱きやすい疑問に回答します。

 

開発会社に相談する前に何を決めておくべきですか？

開発目的、ターゲットユーザー、解決したい課題、必要な機能の優先順位、予算の範囲、希望時期、関係部署、意思決定者を整理しておくと、相談を進めやすくなります。すべてを確定する必要はなく、決まっていることと未確定のことを分けて共有し、開発会社と相談しながら具体化することも可能です。

 

アプリ開発にはどのくらいの期間がかかりますか？

アプリ開発にかかる期間は、機能数や外部システムとの連携、開発方法、対象OS・端末、発注側の確認体制などによって異なります。要件定義や設計、テストの範囲、ストア審査、開発途中の仕様変更などもスケジュールに影響するため、自社の要件に合わせて確認することが重要です。

アプリ開発の期間や、公開日から逆算したスケジュールの立て方については、以下の記事も参考にしてください。

ウォーターフォールとアジャイルはどちらを選ぶべきですか？

要件の確定度や仕様変更の可能性、予算・期間の管理方法、発注側が継続的に開発へ関与できるかなどを踏まえて選びます。要件を事前に具体化し、計画に沿って進めたい場合はウォーターフォール、利用者の反応などを踏まえて優先順位を見直しながら進めたい場合はアジャイルが選択肢になります。

 

発注後、発注側はどの工程に関わりますか？

発注側は、要件定義だけでなく、設計確認、開発中の進捗確認、受け入れテスト、リリース判断、公開後の運用・改善まで、アプリ開発全体を通して確認・判断に関わります。各工程で必要な判断を行えるよう、意思決定者と実務担当者をあらかじめ明確にしておくことが大切です。

 

プラットフォーム活用型が向いているのはどのような場合ですか？

必要な機能の多くを標準機能で満たせる場合や、すべての機能をスクラッチで一から構築する必要性が低い場合は、プラットフォーム活用型が選択肢になります。標準機能の範囲に加え、外部システムとの連携、カスタマイズの自由度、追加開発の範囲などが自社の要件に合うかを確認しましょう。

 

まとめ

本記事では、アプリ開発の流れを「企画・目的整理」「要件定義」「設計」「開発・実装」「テスト」「ストア申請・リリース」「運用・改善」の7段階に整理して解説しました。

開発会社へ相談する前には、開発目的や対象ユーザー、必要な機能、予算の範囲、社内の承認・意思決定体制などを整理しておくことが大切です。

また、発注後も開発会社へ任せきりにするのではなく、要件や設計の確認、仕様変更、テスト、リリースなど、各工程で発注側による確認・判断が必要になります。

 

ウォーターフォール、アジャイル、プラットフォーム活用型は、それぞれ進め方や発注側の関わり方が異なります。

仕様変更の可能性や必要な機能、社内の意思決定体制など、自社の要件に合わせて開発方法を検討しましょう。

自社に適した開発方法や、どの工程から相談すればよいかわからない場合は、要件がすべて固まるのを待たず、早めに開発会社へ相談することも選択肢です。

 

アイリッジではアプリ開発に関する相談を受け付けています。

ぜひご相談ください。