本記事は、スマホアプリ開発の初心者が「どこから手をつければいいか分からない」という疑問点を明確にするために、7つの手順で細かく説明しています。また、手順と合わせて、スマホアプリ初心者が知っておきたい情報やよくある質問を解説しています。
本記事を読むことで、「スマホアプリ開発の初めの一歩を迷いなく踏み出すこと」ができます。
初心者でも迷わない7つの手順
アプリ開発は7つの工程があり、特に重要な工程は企画、開発会社選定、要件定義・設計です。
上流工程である、企画・要件定義はアプリ開発にとって大事な基礎となります。建築物同様に、基礎が固まっていない状態の制作物は、多くの欠陥を生じたり、想定とは異なるものなってしまいます。
■アプリ開発工程（内容要確認）
| 工程 | 作業者 | 内容 |
|---|---|---|
| 企画 | 発注者 | アプリの目的、ターゲット、解決したい課題を明確にする。 |
| 開発会社選定 | 発注者 | 実績や提案内容、予算などをもとに最適なパートナー企業を選ぶ。 |
| 要件定義・設計 | 発注者 & 開発者 | 必要な機能や画面構成を決め、システムの仕組みを設計する。 |
| 開発 | 開発者 | 設計書に基づき、プログラミングを行って機能を実装する。 |
| テスト | 発注者 & 開発者 | 動作の不具合がないか、仕様通りに動くかを厳しくチェックする。 |
| リリース（納品・検収） | 開発者 | アプリストア及び任意の環境にアプリを配信し、ユーザーが使える状態にする。 |
| 保守・運用 | 発注者 or 開発者 | バグの修正やOS更新への対応、サーバー管理を継続的に行う。 |
作業者欄を見て分かる通り、アプリ開発は開発者に丸投げして終わりではなく、開発者と共にアプリを作り上げ、運用していく必要があります。開発期間から保守運用期間を含めると数ヶ月〜数年間の関係となる為、開発会社選定も重要な工程になります。
①企画
作業者：発注者
アプリを制作する目的、ターゲットとなるユーザーの設定、アプリによる成功指標の設定など、アプリ開発の根本となる項目を明確化します。
企画書やRFP（提案依頼書）を作成することは最重要事項です。作成することで、社内や開発会社に正確に意図を伝えられます。
■企画書項目
| 項目 | 内容 |
|---|---|
| 背景・目的 | なぜそのアプリを作るのか、解決したい課題は何か |
| ターゲット設定 | 年齢、性別、利用シーンなど、誰に使ってもらいたいか |
| 競合調査 | 類似アプリを分析し、自社アプリならではの差別化ポイントはどこか |
| 対応OS | ネイティブ(Android,iOS)、Webなど |
| 主要機能の選定 | 必須必要とオプション機能のリスト化、及び機能優先順位決め |
| 予算 | 開発費用・ランニングコスト（サーバー費用など）・マーケティング費用の計画など |
| スケジュール | アプリ開発は3ヶ月〜数年単位かかるため、着手時期やリリース時期の計画 |
| 収益モデル | 無料提供、広告収入、月額課金、買い切り制などのマネタイズ手法 |
| プロモーション計画 | ユーザー獲得方法の検討（SNS、広告、既存顧客への告知など） |
| 成功指標の設定 | ダウンロード数、アクティブユーザー数、売上貢献上昇率など、成功と判断するための指標設定 |
②開発会社選定
作業者：発注者
アプリ開発を外注する場合は、開発会社の選定を行います。
企画書やRFP（提案依頼書）を元に、自社の要件に合う開発会社を探しましょう。
選定方法を5つの工程に分けて解説します。
開発会社の調査
開発会社の検索や調査方法は、主に3種類あります。
| 調査方法 | 内容 |
|---|---|
| インターネット検索 | 開発会社HPを確認する方法です。 メリット：自社のサービスや実績を詳しく調査することができる点 デメリット：数ある開発会社を個別に探すのは難しい 自社ブログを公開している場合のポイントとして、「現場で培った知見や解決策」などが具体的に公開されており、課題解決への向き合い方を知ることができる判断材料となります。 |
| ビジネスマッチングサービスの活用 | 発注を支援するビジネスマッチングサービスを活用する方法です。 メリット：複数の開発会社をまとめて紹介してくれる デメリット：サイト上の情報だけでは決断するに乏しい 紹介時に一斉に開発会社からメッセージや電話などの連絡がくるので、急いで開発会社を探している場合に有効です。 |
| 取引先・知人の紹介 | 取引先や知人から紹介を受ける方法です。 メリット：探す手間が省け、ある程度信頼がある会社を探せる デメリット：要件が合わない場合や、相場より高い可能性がある 実際に紹介した企業の実体験を聞けるのは貴重です。紹介された会社と合わせて、複数社を比較検討しましょう。 |
それぞれの状況に合わせて調査方法を選択し、最適なパートナーを探しましょう。
調査方法に関わらず重要な共通点は、企画書やRFP（提案依頼書）を作成することです。
企画書やRFPを作成することで、発注者は各社ごとに何度もヒアリングを受ける必要がなく、開発者は要件の背景や実現したいことを明確化することができ、双方スムーズに進めることができます。
お問合せ
お問い合わせは4つの工程に分けられます。
企画書・RFPを提出した場合、商談せずに見積もりを出してもらう場合もあります。
アプリ開発依頼が初めての場合は、商談の場を設け、疑問点や不満点など色々と相談してもらうと良いでしょう。
初回商談の時間は、一般的に30分〜1時間程度になります。
見積もり及び提案の比較検討
複数社から見積書及び提案書を提出してもらった後、比較検討のフェーズに入ります。
評価すべきポイント5つあります。
| 確認項目 | 内容 |
|---|---|
| 見積金額の妥当性 | 複数社の見積書と比較して金額に大きな差がないか、想定費用に収まっているか。ある程度細かい粒度で、見積もりが細かく表記されているかを確認します。想定費用と大きく差が出てしまうことを想定し、複数パターンの見積書を作成してもらいましょう。 また、企画書やFRPが具体的ではない場合、各社によって見積もりが大きくブレる可能性があります。 |
| 提案内容の具体性とその根拠 | 提示した課題に対する解決策が、具体的に示されているか。要望の実現が難しい場合、根拠となる理由と、別の提案内容が示されているかを評価します。 |
| 開発スケジュールと納期 | 各工程（要件定義・開発・テスト・リリース）で無理のない計画を立てられているか。納期に間に合いそうか。遅延リスクに対する備えが確保されているかを確認します。 特に、外的要因であるストア審査では、リジェクトと修正を往復することが想定されるので、十分に余裕を持った計画ができているかを確認します。 |
| 保守運用の体制と費用 | リリース後のバグ修正・OSアップデート対応・障害対応など、サポート範囲と体制の確認。保守運用時のランニングコストなどを確認します。 |
| 検収・納品物についての確認事項 | 開発完了となる条件が明確（検収内容）になっているか、納品物の一覧（設計書やソースコードなど）が定義されているかを評価します。 |
要望に対して、予算・納期・技術の方面で実現が難しい場合があります。そのような時に、はっきりと難しいと判断し、別の方法で再提案してくれる担当者（開発会社）を選んだ方が、後々のトラブルを回避できるでしょう。あいまいな提案のまま要件定義を終えてしまうと、開発フェーズで次々とトラブルが発生することが予想されるためです。
契約締結
契約時に確認しておくべきポイント4つを解説します。
| 項目 | 内容 |
|---|---|
| 業務内容・報酬 | 業務内容の範囲・開発報酬・支払いタイミングなどが記載されていることを確認します。機能追加による報酬変動も予想されるため、取引全体の基本ルールは「基本契約」として取り決め、報酬変動などがあった場合は「個別契約」として締結を行い、都度報酬と業務内容を決めるように規定することがあります。 |
| 検収方法 | 検収とは開発会社から納品された成果物を検査することをいいます。検収作業が完了することで、全ての開発完了がとなります。ここでは、成果物・検収実施期間・検収不合格となった際の取り決めなどを確認しておきましょう。 |
| 著作権の取り決め | プログラムは開発会社の著作権として保護されます。しかし、将来的に開発会社を変更したり、内製かすることを考えると、発注者に著作権を帰属したいと考えることもあります。著作権が誰に帰属するのかを明確にする必要があります。 |
| 契約不適合責任 | 検収後に不具合が見つかった場合、開発会社がいつまで補修を行うかを確認します。具体的に、「◯ヶ月まで契約不適合の責任を負う」といった記載が考えられます。 |
開発内容、開発費用、納品物、納期、検収条件など事前にすり合わせ、契約書を作成することでトラブルを未然に防ぐことができます。
初めてアプリ開発を行う場合は、法律事務所に契約書作成及び確認の依頼をすることを、検討するとよいでしょう。
キックオフ
契約締結を終えたら、キックオフミーティングを行います。
関係者顔合わせや、スケジュールの確認、連絡手段の確認、必要ツールの確認や手配などを行います。
以後は要件定義のフェーズに入り、コミュニケーションが増えるため、顔合わせをしておくことで、良好な関係を築けるようにしておきます。
③要件定義・設計
いよいよ、全工程で最も重要な要件定義に入ります。
この段階ですでに、企画書やRFP（提案依頼書）を元に提案を行っているので、おおまかな方針は決まっています。要件定義では、さらに細かな要件を分解・明確化し、要件定義書・設計書に落とし込む作業を行います。
■要件定義書・設計書項目
| 項目 | 内容 |
|---|---|
| 導入・概要 | ・背景と目的（なぜそのアプリを作るのか、現状の課題と解決したいゴールの設定） ・ターゲットユーザー（誰に使ってもらいたいか） ・アプリ全体の概要 |
| 業務要件 | ・業務フロー：システム導入前後の業務内容や業務の流れを必要に応じて図解 |
| 機能要件 | ・機能一覧：実装すべき全機能（ログイン、検索、データ登録、通知など）のリスト ・外部システム連携：他のツールや既存システムとのデータ連携方法 |
| 非機能要件 | ・性能・拡張性：同時接続数やレスポンス速度、将来のデータ増加への対応 ・セキュリティ：認証方式、アクセス権限管理、通信の暗号化 ・保守・運用：リリース後のバグ対応体制や、データのバックアップ頻度 |
| 開発スケジュール | 各工程（開発・テスト・リリース・保守運用）のスケジュール決定 |
| 設計書 | システム設計：要件定義でまとまった機能を具体化するための設計作業 データ設計：システムで扱う情報を整理し、データベースで効率よく管理するための構造を定義 テスト設計：開発したシステムが設計通りに正しく動くかを確認するための、検査項目や手順を計画する工程 |
| デザイン | ワイヤーフレーム：画面要素（テキスト、ボタンなど）の配置や画面構成を、線や枠を用いて描いた設計図 UIUXデザイン：ワイヤーフレームが設計に対して、UIUXデザインは意匠。色やアイコンなどユーザーが使いやすいようにデザインを作成 |
作業者：発注者 & 開発者
発注者の役割
発注者は、企画書及びRFPに記載されている要件の明確化、要件ヒアリング、開発者提出資料の確認を行います。
要件定義後は基本的に開発者の工程となる為、発注者にとってはここまでが最も時間のかかる工程になります。あと少し頑張りましょう。
開発モデル（詳しくは開発モデル（ウォーターフォール、アジャイル）を参照）にもよりますが、要件定義完了後では基本的に要件の変更はできません。要件の変更や追加がある場合、スケジュール遅延や開発費用変動の可能性がある為、事前に開発会社に確認しておきましょう。
開発者の役割
開発者は、要件ヒアリング、要件定義書作成、設計書作成、デザイン作成、発注者へ資料提出及び修正を行います。
要件定義完了の段階で、アプリを作る上で必要な資料が揃います。
④開発
作業者：開発者
開発工程では大きく3つシステムを構築します。
| 項目 | 内容 |
|---|---|
| アプリ開発（フロントエンド） | ユーザーが直接操作する画面のインターフェースを構築し、ボタン操作や画面遷移などの動きを実装します。iOS/AndroidそれぞれのOSで快適に動作するよう、デザインの再現や操作感の最適化を行います。 |
| バックエンド開発 | データの保存やユーザー認証、外部システムとの連携など、アプリの裏側で動くサーバー側の処理を構築します。データベースの設計やAPIの開発を行い、フロントエンドからの要求に対して正確な情報を安定して返せるようにします。 |
| ダッシュボード開発（Web管理画面） | 運営者がユーザー情報やコンテンツの更新、利用状況の分析などを行うためのWebベースの管理用画面を作成します。データの登録・編集機能やグラフによる可視化を実装し、日々の運用業務を効率化するためのツールを整えます。 |
開発者が各工程で気をつけているポイント
アプリ開発（フロントエンド）
ユーザーが直接触れるインターフェースのため、快適かつセキュアにアプリを使えるように考慮して開発します。具体的には、大量コンテンツを一覧表示する際に画面が重くならないようしたり、セキュアな情報を扱う場合はアプリ内にデータを保存しないなど、デザイン設計では表現できなような点も意識して実装します。
バックエンド開発
ユーザーが直接目にすることのない領域ですが、セキュリティと拡張性を最優先に実装します。通信経路の暗号化はもちろん、認証トークン等を用いた適切なアクセス制御を行い、悪意ある第三者による情報の抜き取りや不正操作を防止します。また、重要なロジックをサーバー側に集約することでデータの整合性と安全性を担保し、ユーザー急増時にもパフォーマンスを維持できるスケーラブルな構成を構築します。
ダッシュボード開発（Web管理画面）
運営者がミスなく操作できることはもちろんのこと、運営者権限の差異による操作制御や、不正利用対策などを考慮して開発を行います。
⑤テスト
作業者：発注者 & 開発者
テストには大きく分けて4つ種類があります。
| テスト項目 | 内容 |
|---|---|
| 単体テスト | プログラム（関数やクラスなど）の最小単位で動作を確認する初期工程です。この段階で細かなバグを確実に修正することで、プログラムの基礎部分の品質を担保します。 |
| 結合テスト | 単体テスト済みの各部品を組み合わせ、コンポーネント間のデータ連携やインターフェースを検証します。設計通りの操作が可能か、データの不整合がないかを確認します。 |
| 総合テスト | ソフトウェア全体の挙動や性能、負荷耐性、セキュリティなどを網羅的に評価します。システム全体が仕様通りに動作し、期待されるパフォーマンスを発揮するかを検証します。 |
| 受入れテスト | 開発の最終工程として、発注者がビジネス要求を満たしているか確認します。実際の運用を想定した使い勝手や品質をチェックし、納品前の最終判断を行います。 |
開発者の役割
単体テスト、結合テスト、総合テストを順次行います。
システムの観点からテストを行い、システム設計書や要件定義書に沿って作成したテスト設計書を元にテストを行います。
発注者の役割
受入テストの実施を行います。
受入テストは総合テストまでとは異なり、実際に発注者が求めている要件を満たしているか、快適に利用できるかなど、業務的な観点からテストを実施します。システム観点のテストは満たしていても、業務で使えなければ意味がありません。その為にも、受入テストによる業務的な観点からのテストは必要不可欠です。
⑥リリース（納品・検収）
作業者：開発者
一般的なアプリの場合、AppStore(Apple)やGooglePlay(Google)の各ストアにアプリをリリースします。また、社内アプリや特定範囲での使用を考えている場合は、一般公開せず一部範囲や非表示アプリとしてリリースすることが可能です。
公開範囲によっては要件の変更がありうるため、要件定義前からリリース範囲の検討をしておきましょう。
注意点としては、ストア審査は1週間以上を見込んだ方が良いでしょう。アプリ審査が厳格化していることや、リジェクト内容によっては修正に時間がかかること、米国の営業時間で審査を行っているためタイムラグが発生することが考えられる為です。
納品
納品物（ソースコードや資料など）を発注者指定先に納品します。
検収
契約提携時に取り決めていた通り、成果物・検収実施期間・検収不合格となった際の取り決めなどを元に、検収作業を行います。検収作業完了後、開発は完全に完了となり、開発会社に費用を支払います。
⑦保守・運用
作業者：発注者 or 開発者
以上でアプリの開発工程は完了しました、お疲れ様でした。しかし、アプリ開発は作って終わりではなく、むしろこれからアプリが稼働しユーザーがアプリを使い始めます。そこで、ユーザーがアプリを継続的に使ってもらう為にも、保守・運用が必要になります。
一般的には、依頼した開発会社に引き続き保守・運用を依頼します。しかし、開発だけ外注し、保守・運用は自社で対応する選択肢もあります。小規模なアプリや社内アプリなどの場合、開発会社に頼らず発注者自身で運用を行う場合もあります。
自社で保守・運用を行う場合の注意点として、ダッシュボードの使い方や各種サービスなど、運用に必要なサービスの取扱説明書を作成してもらいましょう。
その他発注者対応項目
AppStoreやGooglePlayの開発者アカウントは発注者がアカウントを作成し、開発者に共有してもらう必要があります。また、その他サービスを使う場合も同様のケースが多くあります。
■AppStore・GooglePlayのリリースに必要な対応
- DUNS番号発番
- AppleDeveloperProgramアカウント作成
- GooglePlayConsoleアカウント作成
- その他サービスの管理アカウント作成
- その他サービスの支払い設定
- など
アプリ初心者が知っておきたい情報3選
アプリの種類
アプリは大きく分けて2種類に分類されます。
スマホアプリの方が、動作が早く・拡張性に優れています。ブラウザアプリは、導入（インストール）ハードルが低く・開発費用を抑えられる特徴があります。
アプリは5つの種類があります。種類ごとにそれぞれ強みがあるので、自身に適切なアプリ種類を検討して下さい。本記事では、クロスプラットフォーム（特にFlutter）をおすすめしています。
| 動作環境 | 種類 | おすすめ度 | 内容 |
|---|---|---|---|
| スマホ | クロスプラットフォーム | ★★★★★ | Flutter等のフレームワークを用い、一つのコードでiOSとAndroid両方のアプリを開発します。品質の高さと開発効率の良さを両立でき、現代のアプリ開発において最もバランスの取れた手法です。 |
| スマホ | ネイティブ | ★★★★☆ | iOSはSwift、AndroidはKotlinなど各OSごとに開発を行います。端末の性能を最大限に引き出せますが、OSごとに別々の開発が必要なため、コストや期間が膨らみやすい傾向にあります。 |
| スマホ | ハイブリッド | ★★★☆☆ | WEB技術（HTML/CSS等）をベースに、アプリの枠組みを被せた手法です。開発コストは抑えられますが、ネイティブやクロスプラットフォームに比べると操作感や動作速度が劣ります。 |
| ブラウザ | WEBアプリ | ★★☆☆☆ | ブラウザ上で動作するシステムで、インストール不要で利用できるのが利点です。一方で、プッシュ通知やカメラ連携などのデバイス固有機能の活用には制限が多く、アプリとしての体験は限定的です。 |
| ブラウザ | PWA | ★★☆☆☆ | WEBサイトをアプリのようにインストール可能にした仕組みです。手軽に導入できキャッシュ機能も使えますが、ストア配信が基本できないため、アプリとしての認知度や信頼性を高めにくい側面があります。 |
開発モデル（ウォーターフォール、アジャイル）
開発モデルは、ウォーターフォールモデルとアジャイルモデルの2種類があります。
■ウォーターフォールモデル
ウォーターフォールモデルは、滝のように1方向に各工程が流れていく開発モデルです。
各工程を1つずつ確実に終わらせるため役割が明確であり、進捗状況が分かりやすい特徴があります。弱点として、各工程が完了するまで進めない、前工程に戻ることができない、後工程で変更があった際に計画が大きく崩れる場合があります。
■アジャイルモデル
アジャイルモデルは、各工程を小さく回し何度もリリースする開発モデルです。
ユーザーのフィードバックを得て改善を行い、素早くアプリをリリース行える特徴があります。
弱点として、要件の変更が少ないプロジェクトは効果が薄く、何度も仕様変更が行える環境であるがゆえに方向性がブレやすい場合があります。
ウォーターフォールモデルとアジャイルモデルの比較
| 項目 | ウォーターフォールモデル | アジャイルモデル |
|---|---|---|
| 計画の立てやすさ・管理のしやすさ | ⭕️ 各工程が1方向に流れているので分かりやすい | ❌ サイクル形式なのでウォーターフォールに比べて分かりにくい |
| スピードの速さ | ❌ 工程が大きいので終わるまで時間がかかる | ⭕️ 各工程が小さいのでスピードがある |
| 柔軟性 | ❌ 各工程が終わるまで次の工程に入れない | ⭕️ 各工程が小さいので前工程に戻りやすい |
| 顧客満足度 | ❌ フィードバックを得てからリリースするまで時間がかかる | ⭕️ 小さいリリースを素早く行える |
ウォーターフォールモデルは、初回リリース時や用件が明確なプロジェクトに向いています。
アジャイルモデルは、保守運用時や、ユーザーのフィードバックを素早く得たい場合に向いています。
ご自身のプロジェクトに合わせて開発モデルの検討を行いましょう。
開発手法（フルスクラッチ、ローコード、ノーコード）
開発手法は、フルスクラッチ、ノーコード、ローコードの3種類があります
- フルスクラッチ開発：アプリのオーダーメイド開発。0からプログラミングを行う為、デザイン性・拡張性・カスタマイズ性に強いです。
- ローコード開発：基盤となるパーツを利用しつつ、必要な箇所だけコードを書き加える手法です。フルスクラッチの柔軟性とノーコードの速さをバランス良く取り込めるため、ビジネスの成長に合わせた拡張にも対応しやすいのが特徴です。
- ノーコード開発：あらかじめ用意された機能を組み合わせるだけで構築します。プログラミングが不要なため圧倒的なスピードでリリースできますが、プラットフォームの制約を受けるため、独自のデザインや複雑なロジックの実装には限界があります。
■フルスクラッチ開発、ローコード開発、ノーコード開発比較表
| 評価項目 | フルスクラッチ開発 | ローコード開発 | ノーコード開発 |
|---|---|---|---|
| UI/UXデザイン性 | ◎ | ◯ | △ |
| 機能拡張性 | ◎ | ◯ | △ |
| カスタマイズ性 | ◎ | ◯ | △ |
| 外部連携 | ◎ | ◎ | ◯ |
| 開発速度 | △ | ◯ | ◎ |
| 開発コスト | △ | ◯ | ◎ |
| おすすめ度 | ◎ | ◯ | △ |
本記事では、フルスクラッチ開発をおすすめしています。ローコード開発やノーコード開発では、長期的に見た時にデザイン性、機能拡張性、カスタマイズ性においてフルスクラッチ開発に劣る為スケールするにも限界がありますです。また、ローコード開発やノーコード開発で成長してきたアプリから、フルスクラッチ開発に切り替えたいというお声をよく頂く為です。
しかし、小さいアプリを作りたい場合や、用途が限定的である場合は、開発速度や開発コストが抑えられるローコード開発・ノーコード開発が向いています。
よくある質問
アプリ開発費用相場について
アプリ開発費用相場は300万円です。
アプリの規模や、ジャンル、要望によって開発費用は大きく変動します。
企画検討段階であらかじめ調査しておきしょう。
アプリ開発の費用相場について、以下の記事に詳しく説明しています。
外注する際のポイントについて
外注する際に最も大切なことは、開発背景や目的・ゴールを明確にし、企画書に言語化することです。社内外でやりたいことが伝わるように、企画書及びRFP（提案依頼書）を作成しましょう。
他にもいくつかポイントがあります。以下の記事に詳しく説明しています、ご参考下さい。
おわりに
本記事では、アプリ開発のやり方として初心者向けに7つの手順を詳しく説明しました。また、初心者が知っておきたい情報や、よくある質問についても説明しました。はじめの一歩として、まずはやりたいことを明確化し、言語化することから始めましょう。
株式会社AppBellでは、アプリ開発初心者の方から多数のご相談を受け、ご支援させて頂きました。企画書の作成からご依頼頂けますので、まずはお問い合わせフォームからご連絡を頂けますと幸いです。
