アプリ開発仕様書の作り方｜発注前の必須項目

スマホアプリ開発の発注仕様書は、目的・利用者・対象OS・画面・機能・運用・受入条件を、各社が同じ前提で見積もれる粒度にまとめるのが結論です。技術的な詳細まで自社で決める必要はありませんが、優先順位と対象外を明記すると、見積もり差や追加費用を抑えやすくなります。

• アプリ開発仕様書はどこまで作ればよいか
• 発注仕様書に入れる必須項目
  • 1. 開発目的と判断指標
  • 2. 想定利用者と利用場面
  • 3. 対応する端末とOS
  • 4. 画面一覧と画面遷移
  • 5. 機能一覧と優先順位
  • 6. アプリ特有の動作条件
  • 7. サーバー、管理画面、外部連携
  • 8. 品質・セキュリティ・運用条件
  • 9. ストア公開と受入条件
• アプリ仕様書を作成する5ステップ
  • ステップ1：目的と初回公開の範囲を決める
  • ステップ2：利用者ごとの操作の流れを書く
  • ステップ3：画面一覧と機能一覧を対応させる
  • ステップ4：例外、運用、対象外を追加する
  • ステップ5：開発会社との打ち合わせで確定する
• 仕様書作成の外注費用と見積もりの見方
  • 見積書で確認する項目
  • 仕様書作成から依頼できる会社の選び方
• まとめ
• よくある質問
  • 仕様書がなくてもアプリ開発の見積もりを依頼できますか？
  • アプリ開発の仕様書はExcelやPowerPointでも問題ありませんか？
  • 発注後は誰が仕様書を更新するべきですか？
  • アプリ仕様書の作成を外注すると費用はいくらかかりますか？

アプリ開発仕様書はどこまで作ればよいか

アプリ開発を相談する時点では、開発者向けの詳細な技術仕様まで用意する必要はありません。発注者が最初に作るべきなのは、複数の開発会社が同じ条件で提案・見積もりできる「発注仕様書」です。

仕様書という言葉は、企画段階のメモから開発者向けの詳細設計まで幅広く使われます。まずは次の3段階を区別してください。

発注者から「仕様書を完成させてからでないと相談できませんか」と聞かれることがありますが、完成させる必要はありません。技術構成や実現方法は、開発会社から提案を受けたほうが適切な場合も多いためです。

一方、目的や主要機能まで開発会社に丸投げすると、各社が異なるアプリを想定して見積もることになります。たとえば、一方は会員登録や管理画面を含み、もう一方はアプリ画面だけを見積もっている可能性があります。合計金額だけを比較しても、妥当な判断はできません。

発注時点では、次の状態を目標にしてください。

• 誰が、どのような場面で使うアプリか説明できる
• 必要な画面と主要機能が一覧になっている
• iOS、Android、タブレット対応の範囲が決まっている
• 初回公開に必要な機能と、将来追加する機能を分けている
• アプリ以外に必要なサーバーや管理画面を記載している
• 発注範囲と対象外を説明できる
• 何を満たせば納品と判断するか、受入条件の骨子がある

要件定義（＝作るものと実現条件を具体的に決める工程）との関係や外注範囲は、要件定義の費用相場｜外注範囲と依頼方法でも詳しく解説しています。

発注仕様書に入れる必須項目

発注仕様書では、画面や機能だけでなく、利用環境、例外時の動作、公開後の運用まで記載することが重要です。スマホアプリは端末機能やストア審査とも関係するため、Webサイトの仕様書をそのまま流用するだけでは不十分です。

1. 開発目的と判断指標

最初に「なぜアプリを作るのか」を明記します。目的が曖昧だと、開発会社は機能の要否や代替案を判断できません。

記載例は次のとおりです。

• 店舗会員の再来店を増やしたい
• 営業担当者の外出先での報告時間を短縮したい
• 既存Webサービスの継続利用率を高めたい
• 電話で受けている予約をアプリへ移行したい

可能であれば、KPI（＝成果を確認するための数値指標）も置きます。ダウンロード数だけでなく、会員登録完了率、予約完了率、継続利用率、業務時間の削減量など、目的に近い指標を選びます。

2. 想定利用者と利用場面

利用者の年齢や職業だけでなく、どこで、どの端末を使い、何を完了したいのかを記載します。

たとえば、現場作業員が屋外で利用するなら、通信が不安定な場合の動作や、手袋を着けた状態でも押しやすい画面が必要になる可能性があります。一般消費者向けなら、会員登録の手間やログイン方法が利用率に影響します。

利用者が複数いる場合は、一般会員、有料会員、店舗スタッフ、管理者など、権限ごとに分けてください。

3. 対応する端末とOS

OS（＝iOSやAndroidなど、端末を動かす基本ソフト）の対応範囲を決めます。

• iPhoneのみか、Androidも対象か
• スマートフォンだけか、タブレットにも対応するか
• 縦画面のみか、横画面にも対応するか
• 対応するOSバージョンをどこまで遡るか
• スマートウォッチなどとの連携が必要か
• 社内配布か、一般向けのストア公開か

古いOSを広くサポートすると、開発やテストの負担が増える場合があります。発注者側でバージョンを断定できなければ、想定利用者や既存顧客の端末状況を伝え、開発会社に推奨範囲を提案してもらいます。

4. 画面一覧と画面遷移

画面一覧には、ログイン、ホーム、検索、詳細、入力、確認、完了、設定など、利用者が触れる画面を並べます。画面遷移図（＝どの画面からどの画面へ移動するかを示した図）を添えると、見積もりの前提が伝わりやすくなります。

この段階では、完成デザインは不要です。手書きや簡単な図でもよいので、ワイヤーフレーム（＝情報やボタンの配置を示す画面の設計図）を作ります。

各画面には次の情報を対応づけます。

• 画面名と画面番号
• 表示する情報
• 利用者が行える操作
• 入力必須項目と任意項目
• エラー時の表示
• 権限による表示の違い
• データが0件の場合の表示
• 読み込み中や通信失敗時の動作

正常に完了する流れだけでなく、入力誤り、通信切断、ログイン期限切れ、権限拒否なども記載することが重要です。

5. 機能一覧と優先順位

機能一覧には、利用者向け機能だけでなく、管理者向け機能や外部サービスとの連携も含めます。

すべてを「必須」にせず、優先度を付けます。たとえば「初回公開に必須」「予算に余裕があれば実装」「公開後に追加」の3段階にすると、予算超過時にも事業目的を保ったまま調整できます。

6. アプリ特有の動作条件

スマホアプリでは、次の項目を早い段階で確認します。

• プッシュ通知を誰が、いつ、どの条件で配信するか
• カメラ、写真、マイク、位置情報を何のために使うか
• 権限を許可しなかった場合にも利用できるか
• 圏外や通信不安定時にどこまで操作できるか
• バックグラウンド中に処理する必要があるか
• 生体認証を利用するか、代替ログイン手段を用意するか
• URLからアプリ内の特定画面を開く導線が必要か
• 個人情報や端末内データをどこまで保存するか
• 退会時にどのデータを削除するか

デジタルコンテンツや有料機能を販売する場合は、アプリ内課金に関するストアのルールが関係することがあります。対象商品や提供方法によって扱いが異なり、ルールも更新されるため、発注時点の最新条件を開発会社と確認してください。

7. サーバー、管理画面、外部連携

アプリ画面だけではサービスが成立しないケースが大半です。会員情報や投稿、予約、購入履歴を保存するバックエンド（＝アプリの裏側でデータ保存や処理を担う仕組み）や、運営担当者が使う管理画面の要否も記載します。

特に漏れやすいのは次の項目です。

• 運営担当者による会員検索と利用停止
• コンテンツやお知らせの登録・公開予約
• 問い合わせ対応に必要な履歴確認
• CSVなどによるデータ出力
• 売上や利用状況の集計
• 不適切な投稿の通報・非公開化
• 既存システムとの会員情報同期
• メール、SMS、地図、決済などの外部サービス利用料

API（＝システム同士がデータをやり取りする接続口）で既存システムと連携する場合は、接続仕様書の有無、利用申請、テスト環境、利用上限、接続先の担当窓口も確認します。

8. 品質・セキュリティ・運用条件

非機能要件（＝画面や機能以外の品質条件）も、事業上重要なものから記載します。

• 想定利用者数とアクセスが集中する時間帯
• 画面表示速度の目標
• 個人情報や決済情報の取り扱い
• ログの保存期間と確認方法
• 障害発生時の連絡先と対応時間
• データのバックアップと復旧方針
• 不正ログインや大量アクセスへの対策
• アクセシビリティ（＝年齢や障害にかかわらず利用しやすくする考え方）への配慮
• 公開後の問い合わせ受付と不具合対応

「高セキュリティ」「高速に表示」といった抽象的な表現では、見積もり条件になりません。扱う情報、事業への影響、許容できない状態を伝え、具体的な基準は開発会社と決めます。

9. ストア公開と受入条件

App StoreやGoogle Playへの公開作業を、どちらが担当するか明記します。ストア掲載文、画像、プライバシーポリシー、問い合わせ先、年齢区分などの準備担当も決めてください。

開発者アカウントは、原則として発注企業名義で取得します。ソースコード、デザインデータ、サーバー、外部サービスの契約名義も含めた管理方法は、アプリ開発契約の注意点｜権利・アカウント管理も参考にしてください。

受入条件（＝納品物を問題なしと判断する基準）には、少なくとも次を記載します。

• 検査対象となるOSと端末
• 確認する機能と操作手順
• 修正対象となる不具合の基準
• 検査期間と再確認の方法
• ストア審査通過を納品条件に含めるか
• 納品される文書、データ、アカウント

ストア審査はプラットフォーム側の判断も伴います。そのため、「申請作業の完了」と「審査通過」のどちらを契約上の完了条件にするかは、事前に合意しておく必要があります。

アプリ仕様書を作成する5ステップ

仕様書は、最初から文章を細かく書くより、利用者の行動、画面、機能、例外条件の順に具体化すると作りやすくなります。

ステップ1：目的と初回公開の範囲を決める

まず、アプリで解決したい課題を一つの文章にします。そのうえで、初回公開時に検証したいことを決めます。

発注のご相談を受ける開発会社の立場では、「競合アプリと同じ機能をすべて入れたい」という依頼より、「既存顧客が1分以内に再予約できるようにしたい」といった目的のほうが、適切な機能や代替案を提案しやすくなります。

既存Webサイトで実現できることや、手作業で代替できる管理機能は、初回範囲から外せる場合があります。

ステップ2：利用者ごとの操作の流れを書く

ユーザーストーリー（＝利用者が何のために何をしたいかを表す短い文章）を作ります。

例として、予約アプリなら次の流れです。

1. 利用者がメールアドレスで会員登録する
2. 地域と日時から空き枠を検索する
3. メニューと担当者を選ぶ
4. 内容を確認して予約を確定する
5. 予約完了通知を受け取る
6. マイページから変更またはキャンセルする

この流れから必要画面を洗い出し、各画面に必要な機能を対応づけます。管理者側の操作も同じように整理してください。

ステップ3：画面一覧と機能一覧を対応させる

画面ごとに「表示」「入力」「操作」「条件」を記載します。機能一覧には画面番号を付け、どこで使う機能か追跡できるようにします。

このとき、同じ「検索機能」でも条件によって開発量が変わる点に注意してください。キーワード検索だけなのか、位置情報、絞り込み、並べ替え、検索履歴、候補表示まで必要なのかを分けます。

ステップ4：例外、運用、対象外を追加する

正常な操作だけでなく、次のような状況を確認します。

• パスワードを忘れた
• 認証メールが届かない
• 入力途中で通信が切れた
• 同じ予約枠を複数人が同時に選んだ
• 決済だけ成功し、予約登録に失敗した
• 利用者が通知や位置情報を拒否した
• 運営担当者が誤ってデータを削除した

また、初回発注に含めない機能も明記します。「多言語対応は対象外」「タブレット最適化は対象外」「データ移行は別途」と書くことで、双方の思い込みを減らせます。

ステップ5：開発会社との打ち合わせで確定する

発注仕様書をもとに、開発会社へ不明点、リスク、代替案を出してもらいます。技術方式を発注者が先に固定するのではなく、目的、予算、公開時期に合う方法を提案してもらうことが重要です。

仕様を確定したら、版番号、更新日、更新者、変更内容を残します。契約後に変更する場合は、費用、納期、ほかの機能への影響を確認してから承認します。チャット上の会話だけで仕様を変更せず、必ず仕様書や変更管理表へ反映してください。

発注前の最終チェックリストは次のとおりです。

• アプリを作る目的を一文で説明できる
• 想定利用者と利用場面を記載した
• iOS・Android・タブレットの対応範囲を決めた
• 画面一覧と画面遷移を作成した
• 機能に優先順位を付けた
• エラーや通信失敗時の動作を確認した
• 管理画面と運用担当者の業務を整理した
• 外部サービスと既存システム連携を記載した
• ストア公開の担当範囲を決めた
• 受入条件と納品物を記載した
• 初回発注の対象外を明記した
• 仕様変更の承認方法を決めた

仕様書作成の外注費用と見積もりの見方

仕様書作成の費用は、単なる資料化なのか、事業要件の整理、画面試作、技術調査まで依頼するのかで変わります。以下は一般的な目安です。

費用は、画面数、利用者の種類、外部連携、決済、位置情報、オフライン対応、セキュリティ要件などによって変動します。要件定義費用が開発費に含まれる会社もあれば、別契約にする会社もあります。

見積書で確認する項目

アプリ本体の金額だけで判断せず、次の項目が含まれているか確認してください。

特に確認したいのは、「別途見積もり」「一式」と書かれた項目です。一式表記が直ちに問題というわけではありませんが、含まれる作業と前提条件を質問してください。

初期仕様書の情報が少ない場合、開発会社は不確実性を上乗せして見積もるか、最低限の範囲だけを見積もることがあります。極端に安い見積もりは、管理画面、テスト、ストア申請、プロジェクト管理などが含まれていない可能性もあるため、金額ではなく範囲をそろえて比較します。

仕様書作成から依頼できる会社の選び方

仕様が固まっていない案件では、要望をそのまま機能へ置き換える会社より、目的から必要性を確認し、選択肢を示す会社が適しています。

選定時は次を確認してください。

• アプリだけでなく、サーバーや管理画面も含めて提案できる
• 不明点や未決定事項を一覧化してくれる
• 必須機能と将来機能を分けて提案する
• 技術用語を発注者に説明できる
• ストア審査や端末権限を考慮している
• 見積もりの前提と対象外が明確である
• 仕様変更時の費用と手順を説明できる
• 作成した仕様書や設計資料を納品できる
• 公開後の保守や追加開発まで相談できる

相談時には、仕様を確定させるために誰が参加するのかも確認します。営業担当者だけで見積もりを作るのではなく、設計や開発を理解する担当者が早い段階で確認する体制が望ましいです。

自社だけで仕様を整理することが難しい場合は、企画や要望が断片的な段階でもご相談いただけます。開発のご相談はこちらから、現状と実現したいことをお知らせください。

よくある失敗と回避策も整理しておきます。

まとめ

• アプリ開発の発注仕様書は、複数社が同じ条件で提案・見積もりできる粒度を目指します
• 発注前に技術の詳細まで決める必要はありませんが、目的、利用者、対象OS、画面、主要機能は整理します
• 画面一覧だけでなく、管理画面、サーバー、外部連携、ストア公開、運用も発注範囲に含めて検討します
• 機能は初回必須、任意、将来対応に分け、対象外も明記します
• 通信失敗、権限拒否、入力誤りなどの例外条件を記載すると追加費用を抑えやすくなります
• 仕様書作成支援は一般に20万〜80万円程度、詳細な要件定義は80万〜300万円以上が一つの目安です
• 見積もりは合計額だけでなく、含まれる作業、前提条件、対象外、月額費用まで比較します
• 契約後は仕様書を更新し、変更による費用と納期への影響を文書で承認します

よくある質問

仕様書がなくてもアプリ開発の見積もりを依頼できますか？

はい、概算相談はできます。ただし、情報が少ない段階の金額は幅が大きく、正式な発注金額にはなりません。最低限、目的、利用者、主要機能、対象OS、希望時期、予算感を整理して相談することをおすすめします。

アプリ開発の仕様書はExcelやPowerPointでも問題ありませんか？

Excelやスプレッドシート、PowerPointでも問題ありません。重要なのはファイル形式ではなく、画面、機能、条件、優先順位、対象外が対応づけられ、関係者が同じ内容を参照できることです。

発注後は誰が仕様書を更新するべきですか？

原則として、発注者側の責任者と開発会社の担当者を決め、合意した変更を開発会社が反映し、発注者が承認する流れにします。更新権限、承認方法、変更履歴の残し方は契約前に決めてください。

アプリ仕様書の作成を外注すると費用はいくらかかりますか？

一般的な目安では、要望整理や簡易仕様書の作成支援は20万〜80万円程度、試作画面や非機能要件まで含む要件定義は80万〜300万円以上です。機能数、外部連携、検討の深さによって大きく変わります。