アプリ開発の要件定義は、開発会社が書く書類ではありません。発注する側が「何を作らないか」を決める作業です。 ここを取り違えて「要件定義もお願いします」と発注すると、開発会社は自分たちが作りやすい形に要件を寄せます。それが悪意によるものであることは稀で、単に「決める人がいないから決められる人が決めた」だけです。しかし結果として、自社の業務に合わないアプリが、自社の予算で出来上がります。
本記事は、スマホアプリの開発を検討している経営者・事業責任者・新規事業担当の方に向けて、企画書 → 要件定義 → 見積もり依頼という順序で、発注側が自力で埋められる項目を整理します。開発全体の費用感はスマホアプリ開発費用の完全ガイド、そもそも小さく検証してから作るべきかはMVP開発とは何かで扱っています。
目次
- 結論：要件定義は「作らないもの」を決める作業
- 企画書と要件定義は別物
- ステップ1：企画書に書く6項目
- ステップ2：要件定義で決める18項目
- アプリ特有の決め事（Webにはない論点）
- スケジュールの立て方
- 見積もり依頼の出し方
- 要件が固まらないまま発注するとどうなるか
- 自社で書けないときの選択肢
- 発注前チェックリスト
- よくある質問（FAQ）
- 要件定義でつまずいたら
<a id="conclusion"></a>
結論：要件定義は「作らないもの」を決める作業
要件定義を「欲しい機能を並べる作業」だと考えていると、必ず膨らみます。会議で機能を出し合えば、誰も反対しないので全部が採用されます。そして見積もりが予算の2倍で返ってきて、削る作業が始まる——この順序が最も時間と信頼を消費します。
正しい順序は逆です。先に「これがなければ意味がない」という中核を1つ決め、それ以外を後回しに落とす。 落としたものは消えたのではなく、次のリリースの候補として記録されるだけです。この決め方ができていれば、見積もりは最初から予算の範囲に収まりやすくなり、開発中の「あれも欲しい」に対しても「それは第2弾です」と答えられます。
発注者が要件定義で答えるべき問いは、突き詰めると次の3つです。
- 誰が、いつ、どこで使うのか（通勤電車か、店頭か、工場か。片手か両手か）
- その人が、これで何を早く終わらせられるのか（既存の手段と比べて何分短くなるのか）
- 今回は何を作らないのか（見送るものを名指しできるか）
3番目に答えられないうちは、要件定義は終わっていません。
<a id="difference"></a>
RESTAURANT DX
店長の経験と勘を、仕組みで再現できる店舗にしませんか？
発注／シフト／予約／FLコストを標準化する多店舗飲食特化のDX。食材ロス削減・インバウンド対応まで概算費用をその場で示します。
企画書と要件定義は別物
この2つは混同されがちですが、目的も読者も違います。
横にスクロールして確認できます
| 企画書 | 要件定義書 | |
|---|---|---|
| 目的 | やるかどうかを決める | 何を作るかを確定する |
| 主な読者 | 経営層・決裁者 | 開発会社・社内の関係部署 |
| 中心にあるもの | 課題と投資対効果 | 機能・非機能・制約 |
| 書く時期 | 予算を取る前 | 見積もりを依頼する前 |
| 精度 | 粗くてよい | 曖昧さが費用になる |
順序としては、企画書で「やる」と決めてから、要件定義で「何を作るか」を詰めます。企画書がないまま要件定義に入ると、途中で「そもそもこれ必要だっけ」に戻って停滞します。 逆に、企画書だけで見積もりを依頼すると、開発会社は前提を推測で埋めるため、各社の見積もりがまったく比較できない金額で返ってきます。
<a id="kikaku"></a>
ステップ1：企画書に書く6項目
企画書は分厚くする必要はありません。次の6項目が埋まれば、決裁の議論はできます。
- 解決したい課題：今、誰が何に困っているか。時間・コスト・機会損失のどれで表現できるか
- アプリでなければならない理由：Webサイトや既存ツールで足りない理由は何か
- 利用者と利用場面：社内の誰か、顧客か。使う場所と頻度
- 成功の判定基準：何がどうなったら成功と言えるか（利用率、処理時間、問い合わせ件数など）
- 概算予算と時期：いくらまで、いつまでに
- やらないこと：今回のスコープ外を明記する
2番目は特に重要です。「アプリを作りたい」という要望の相当数は、実はWebサイトのスマホ対応や既存SaaSの設定で足りることがあります。アプリにする合理性は、プッシュ通知、カメラやGPSなどの端末機能、オフライン利用、ホーム画面からの起動といった「アプリでないとできないこと」に紐づいているはずです。ここが説明できないなら、アプリ化そのものを再検討したほうが、費用も運用負荷も下がります。作り方の選択肢はシステム開発の種類と選び方にも整理しています。
<a id="youken"></a>
ステップ2：要件定義で決める18項目
企画が通ったら、次は要件定義です。以下は発注側が決めるべき項目で、技術的な知識がなくても事業側で判断できるものを中心に並べています。
利用者と業務
横にスクロールして確認できます
| # | 決めること |
|---|---|
| 1 | 利用者の種類（一般顧客／会員／社員／管理者）と、それぞれができること |
| 2 | 利用開始の方法（誰がアカウントを作るのか、招待制か、自由登録か） |
| 3 | 想定利用者数と、ピーク時の同時利用の規模感 |
| 4 | 既存業務のどの工程を置き換えるのか（並行運用の期間はあるか） |
機能の範囲
横にスクロールして確認できます
| # | 決めること |
|---|---|
| 5 | 第1弾で必ず入れる機能（3つ以内で言えるか） |
| 6 | 第2弾以降に回す機能（名指しできるか） |
| 7 | 管理側の機能（利用者データの確認・修正を誰がどこで行うか） |
| 8 | 既存システムとの連携の有無（何と、どの方向に、どの頻度で） |
データ
横にスクロールして確認できます
| # | 決めること |
|---|---|
| 9 | 扱うデータの種類（個人情報・決済情報・業務データの有無） |
| 10 | データの保管場所（自社サーバー・クラウド・端末内） |
| 11 | 保存期間と削除のルール |
| 12 | 移行するデータの有無（既存の顧客名簿や履歴を持ち込むか） |
非機能（後から効いてくる項目）
横にスクロールして確認できます
| # | 決めること |
|---|---|
| 13 | 対応OSとバージョンの下限（古い端末をどこまで切るか） |
| 14 | 応答速度の期待値（何秒までなら許容できるか） |
| 15 | 障害時の許容停止時間と連絡経路 |
| 16 | セキュリティ要件（詳細は別記事） |
| 17 | ログと記録（誰が何をしたかを追えるようにするか） |
| 18 | 運用体制（問い合わせ対応・アプリ更新・OS追随を誰が担うか） |
13番は、発注者が決めなければならない典型です。古いOSまで対応するほど、費用と検証工数は増えます。 「全部対応してください」は最も高い選択で、しかも自社の利用者に本当に必要かどうかは、事業側でないと判断できません。社内アプリなら支給端末の一覧を見れば決まりますし、一般顧客向けなら既存サイトのアクセス解析からOS別の比率が分かります。
16番のセキュリティ要件は範囲が広いため、スマホアプリのセキュリティ要件12項目で別立てにしています。要件定義の段階で並行して詰めてください。
<a id="app-specific"></a>
アプリ特有の決め事（Webにはない論点）
Webシステムの発注経験がある方でも、アプリで初めて出会う論点があります。
プッシュ通知。 何を、誰に、どのタイミングで送るのか。通知は強力な反面、多すぎると通知そのものをオフにされ、二度と届かなくなります。「送る条件」を要件として書いてください。
オフライン利用。 電波の届かない場所で使うのか。使うなら、どこまでの操作を許し、通信が復帰したときにどう同期するのか。オフライン対応は費用が跳ね上がる代表的な要件なので、本当に必要かを業務側で精査する価値があります。
ストアへの公開と更新。 iOS・Android両方を出すのか、片方から始めるのか。アカウントは自社名義で用意します。そして重要なのは、アプリの更新には毎回審査があり、即日反映ではないという点です。Webのように「今すぐ直して公開」ができないため、緊急時の手当て（重要な情報はサーバー側から出す設計にするなど）を要件に織り込んでおきます。
OSのバージョンアップ。 iOSもAndroidも年単位で更新され、仕様変更でアプリが動かなくなることがあります。誰がいつ確認し、誰が費用を持つかを、要件定義の段階で運用側の項目として決めてください。
端末の紛失。 業務アプリの場合、端末を落としたときにデータをどうするか。遠隔で消せるようにするのか、そもそも端末に置かないのか。これは技術要件である前に、社内規程の問題です。
<a id="schedule"></a>
スケジュールの立て方
アプリ開発のスケジュールで最も見落とされるのは、開発以外の時間です。逆算するときは次の要素を積んでください。
横にスクロールして確認できます
| 工程 | 発注側の作業 |
|---|---|
| 要件定義 | 社内ヒアリング、決裁、既存業務の棚卸し |
| デザイン確認 | 画面の確認と修正指示（関係部署の合意形成が必要） |
| 開発 | 中間確認への参加、仕様の質問への回答 |
| 受入テスト | 実際の業務で使ってみる。発注側が主役の工程 |
| ストア申請 | プライバシー申告の内容決定、審査の待ち時間 |
| 社内展開 | 端末への配布、利用者への説明、問い合わせ対応 |
このうち、受入テストとストア申請は発注側の作業量が多く、かつ短縮しにくい工程です。開発会社の見積もりに書かれた「開発期間」だけを見て社内に日程を約束すると、後半で必ず苦しくなります。
もう一つの注意点として、審査は落ちることがあります。プライバシー関連の申告不備や、機能の説明不足でリジェクトされ、修正して再申請するとさらに日数がかかります。公開日を対外的に告知するなら、審査通過後にしてください。工程全体の読み方はソフトウェア開発の流れと工程表の読み方も参考になります。
<a id="estimate"></a>
見積もり依頼の出し方
要件が整理できたら、複数社に見積もりを依頼します。このとき、各社に同じ前提を渡すことが最も重要です。前提が違えば金額は比較できません。
依頼時に必ず添える情報は次の通りです。
- 企画書（課題・利用者・成功基準）
- 要件の一覧（上記18項目のうち決まっているもの）
- 決まっていない項目のリスト（正直に開示する）
- 予算の目安と希望時期
- 対応OSとバージョンの下限
- 既存システムとの連携の有無
3番目を隠さないことがコツです。「決まっていない」を伏せると、各社が違う推測で埋めるため、見積もりの差が要件差なのか単価差なのか分からなくなります。開示すれば、その項目をどう扱うかという提案の質で各社を比べられます。
見積もりを受け取ったら、金額の前に前提の一致を確認してください。同じ機能名でも、想定している範囲が違えば金額は倍半分になります。比較の観点はシステム開発の費用・見積もりガイド、発注先そのものの見極めはITベンダーとは（種類・選び方）で整理しています。
なお、契約と工程の考え方については、IPAが公開している情報システム・モデル取引・契約書が参考になります。請負と準委任のどちらで進めるか、要件定義工程を分離して契約するかどうかは、要件の固まり具合で決まります。
<a id="risk"></a>
要件が固まらないまま発注するとどうなるか
「詳細は走りながら決めましょう」で始まったプロジェクトで、実際に起きることを順に挙げます。
- 開発会社が自社の標準的な作りで実装を進める。 悪意ではなく、決まっていないので進めるしかない
- 中間確認で「思っていたものと違う」が発覚する。 ここまでの工数は消費済み
- 仕様変更として追加見積もりが出る。 契約が請負なら、変更は原則として追加費用
- 予算が足りず、機能を削る判断を迫られる。 削るのは、たいてい後工程のテストと運用設計
- リリースはしたが業務に乗らない。 現場が使わず、投資が回収できない
この連鎖の起点は、技術ではなく決める人の不在です。だからこそ、要件定義は開発会社に外注しきれない領域が残ります。社内の誰が決裁するのか、現場の意見を誰が集約するのかを、発注前に決めておいてください。
<a id="outsource"></a>
自社で書けないときの選択肢
「18項目を自社で埋めるのは無理」という場合もあります。その場合の選択肢は3つです。
選択肢1：要件定義だけを分けて発注する。 開発を頼む会社と同じところに要件定義から任せると、その会社が作りやすい要件になりがちです。要件定義を別契約にして、成果物（要件定義書）を持って複数社に見積もりを依頼すると、比較可能性が保てます。
選択肢2：小さく作って確かめる。 要件が固まらない理由が「使ってみないと分からない」であれば、それは要件定義の失敗ではなく、検証すべき仮説がある状態です。この場合は最小限で作って反応を見る進め方が合理的で、MVP開発の考え方が使えます。
選択肢3：第三者に整理を手伝ってもらう。 開発を受注しない立場の相手に、要件の抜けと優先順位の整理だけを依頼する方法です。利害が開発受注と結びついていないため、「これは作らなくてよい」という助言が出てきます。
どの選択肢でも共通するのは、決めるのは自社ということです。手伝ってもらえるのは整理の仕方であって、事業判断そのものではありません。
<a id="checklist"></a>
発注前チェックリスト
- 企画書で解決したい課題を時間・コスト・機会損失のいずれかで表現した
- アプリでなければならない理由を説明できる（Web・既存SaaSで足りないことを確認した）
- 第1弾に入れる機能を3つ以内で言える
- 今回作らないものを名指しできる
- 利用者の種類と、それぞれの権限を決めた
- 扱うデータの種類（個人情報・決済情報の有無）を確認した
- 対応OSの下限を自社データに基づいて決めた
- オフライン利用の要否を業務側で精査した
- プッシュ通知を送る条件を決めた
- ストアアカウントを自社名義で用意することを確認した
- 受入テストとストア審査の期間をスケジュールに積んだ
- リリース後の運用担当（問い合わせ・更新・OS追随）を決めた
- 見積もり依頼時に未決定項目も開示する方針を決めた
- 社内の決裁者と現場の意見の集約役を決めた
<a id="faq"></a>
よくある質問（FAQ）
Q. 要件定義は開発会社にお願いできませんか。 A. 作業として依頼することはできますが、決めること自体は委任できません。開発会社が書けるのは「決まったことを文書化する」部分と「選択肢を提示する」部分までで、どの選択肢を選ぶかは事業判断です。ここを渡してしまうと、判断の責任だけが自社に残ります。
Q. 要件定義にどれくらい時間をかけるべきですか。 A. 期間の目安を一律に示すことはできませんが、判断の基準はあります。「作らないもの」を名指しできるようになったら次に進んでよい、という基準です。逆に、機能一覧が増え続けている間は、まだ議論が発散しています。
Q. 企画書と要件定義書は、どちらも自社で書くのですか。 A. 企画書は自社で書くべきです（決裁を通す文書のため）。要件定義書は、自社で骨子を作り、開発会社または第三者に整形してもらう形が現実的です。骨子すら外部に任せると、自社の業務が反映されません。
Q. iOSとAndroid、両方作るべきですか。 A. 利用者の端末構成次第です。社内アプリなら支給端末で決まります。一般顧客向けなら、既存サイトのアクセス解析でOS別比率を見てください。両方作れば費用は上がるので、片方から始めて反応を見る選択肢も検討する価値があります。
Q. 「アプリ開発 企画書 テンプレート」を探しています。使ってよいですか。 A. 構成の参考にはなりますが、テンプレートの空欄を埋めるだけでは決裁は通りません。埋まらない欄があるとき、それは書式の問題ではなくまだ決まっていない事業判断です。空欄そのものが、次に議論すべき論点を示していると考えてください。
Q. 見積もりが各社でまったく違います。何が起きていますか。 A. たいていは前提の違いです。対応OSの範囲、オフライン対応の有無、管理画面の作り込み、テストの範囲、リリース後の保守の含み方——このどれかが揃っていません。前提を揃えて再依頼すれば、差は縮みます。
Q. 途中で要件を変えたくなったらどうなりますか。 A. 契約形態によります。請負契約なら原則として変更は追加費用の対象、準委任なら工数の中で調整できる余地があります。契約の違いは受託開発とは何かで整理しています。変更が起きる前提なら、契約形態の選択から見直したほうが早い場合もあります。
<a id="cta"></a>
要件定義でつまずいたら
アプリ開発の要件定義は、機能を並べる作業ではなく、何を作らないかを決めて、決めた理由を残す作業です。この作業をやり切った案件は、見積もりが比較でき、開発中の会話が短くなり、リリース後に「思っていたのと違う」が起きません。逆にここを飛ばすと、削減したはずの時間は、開発の後半に利息を付けて返ってきます。
とはいえ、社内に前例がなければ、最初の1枚を書き始めるのが最も難しいのも事実です。埋まらない項目があること自体は問題ではありません。問題は、埋まっていないことに気づかないまま見積もりを依頼してしまうことです。
GXOは開発会社ですが、要件整理の段階では「作らない」という結論も含めて発注側の立場で並走します。売りたい構成に寄せる必要がないためです。
- 要件の抜けと優先順位を整理したい → 要件定義・業務フロー整理の相談
- 受け取った見積もりの前提が妥当か見てほしい → 見積もりセカンドオピニオン
- どの会社に頼むかの判断軸から相談したい → システム開発会社の比較・選定
- まず小さく検証してから決めたい → MVP開発とは何か
- 自社のIT・DXの現在地を診断したい → DX成熟度診断
「決めてから頼む」順序にするだけで、同じ予算で作れるものは変わります。その順序の整理から、ご一緒します。
参考（一次ソース）
- IPA「情報システム・モデル取引・契約書」（一次・公的機関。契約形態と工程の考え方）
- Apple「App Review Guidelines」（一次・プラットフォーム公式。審査要件）
- Google Play「Developer Policy Center」（一次・プラットフォーム公式。審査要件）
- 個人情報保護委員会「法令・ガイドライン等」（一次・公的機関。個人データを扱う場合）
※本記事は要件定義の進め方を発注者向けに整理したもので、特定の契約形態や成果物の適法性を保証するものではありません。ストア審査の要件は改定されるため、申請の直前に公式ページで現行版をご確認ください。契約条項の妥当性については、必要に応じて法務の確認を経てください。
