アプリ開発を発注する前に、社内で用意しておくべきものリスト【準備物×担当×なくても始められるか】
公開日:2026年11月4日 最終更新日:2026年11月4日
「まだ何も決まっていないのですが、だいたいいくらくらいになりますか」。
初回のご相談で、いちばん多くいただく質問です。
予算の目安がないと社内で話を進められない、というご事情はよく分かります。
ですので、まずは率直にお伝えします。
この段階でお出しできる数字は「100万円から2,000万円の間のどこか」になってしまいます。
アプリの費用は、何を作るか・誰が使うか・最初に何を外すか、でほぼ決まるからです。
ここが固まる前にいただいた見積り依頼には、私たちもお役に立てる数字を返せません。
幅の広い概算になるか、こちらで勝手に前提を置いた数字になるかのどちらかで、後者は後々「思っていたのと違う」という行き違いの元になります。
ただ、安心していただきたいのは、揃えるべきものはそれほど多くない、ということです。
社内で用意しておくべきものを13項目に整理しましたが、全部を揃えてからご相談いただく必要はありません。
「目的」「使う人」「最初のリリースに入れる機能と入れない機能」の3つさえ言葉になっていれば、残りは開発会社と一緒に決めていけます。
むしろ、画面設計やデザインまで作り込んでから持ち込まれると、かえって手戻りが増えることもあるので、そこは肩の力を抜いていただいて大丈夫です。
この記事では、発注前に用意しておくものを「誰が用意するか」「なくても始められるか」つきで一覧にし、どこまで自社で準備すれば十分かの線引きをお伝えします。
費用の相場は「アプリ開発の費用相場と見積書の読み方」、契約の形は「アプリ開発の契約形態の選び方」にまとめていますので、あわせてご覧いただければと思います。
発注前に用意しておくものの一覧
「なくても始められるか」は、それが決まっていなくても開発会社との初回相談に進めるかどうか、という基準で付けました。
「必須」は、これがないと見積りの精度が出ないもの。
「あると良い」は、あれば相談が速く進むもの。
「開発会社と決める」は、自社で無理に作らなくてよいものです。
| 準備物 | 内容 | 誰が用意するか | なくても始められるか |
|---|---|---|---|
| ① アプリの目的 | 何のために作るのか。売上を増やしたいのか、業務を減らしたいのか、既存顧客の離脱を防ぎたいのか | 発注者(経営・事業責任者) | 必須。ここが曖昧だと、機能の優先順位が決められない |
| ② 使う人 | 誰が、どんな場面で使うのか。社内の人なのか、顧客なのか。年齢層やITリテラシーはどうか | 発注者 | 必須。使う人でUIも機能も変わる |
| ③ 最初のリリースに入れる機能・入れない機能 | 「これがないと成り立たない」機能と、「あとでいい」機能の仕分け | 発注者(開発会社と調整可) | 必須。ここが見積りの幅を決める |
| ④ 既存システムとの関係 | 連携する基幹システム・会員DB・ECサイト・決済などがあるか。あるならAPIの有無 | 発注者(情シス) | あると良い。連携先の有無で費用が数十〜数百万円動く |
| ⑤ 予算の上限と幅 | 出せる上限と、できれば収めたい額 | 発注者(経営) | あると良い。伝えていただいたほうが現実的な提案を返せる |
| ⑥ 希望する時期 | いつまでに公開したいか。その理由(展示会、キャンペーン、年度など) | 発注者 | あると良い。期限から逆算して方式を選べる |
| ⑦ 競合・参考アプリ | 「こういう感じにしたい」と思えるアプリの名前。逆に「こうはしたくない」も | 発注者 | あると良い。言葉より早く伝わる |
| ⑧ 社内の意思決定者と窓口 | 最終判断をする人と、日々のやり取りをする人。できれば1人ずつ | 発注者 | 必須に近い。ここが曖昧だと途中で仕様が揺れる |
| ⑨ ストアアカウント・開発者登録 | Apple Developer Program、Google Play Consoleの登録。自社名義にするかどうか | 発注者(開発会社が代行可) | なくても始められる。ただし自社名義をお勧めします |
| ⑩ 画面一覧・画面遷移 | どんな画面があり、どうつながるか | 開発会社と決める | なくて良い。要件定義で一緒に作る |
| ⑪ デザイン・ブランドガイド | ロゴ、ブランドカラー、フォントなどの既存ルール | 発注者(あれば) | あれば提供。なければ開発会社が提案 |
| ⑫ 開発方式・技術の希望 | ネイティブかクロスプラットフォームか、など | 開発会社と決める | なくて良い。要件から開発会社が提案 |
| ⑬ 保守・運用の体制 | リリース後、誰が問い合わせを受け、誰が改修を判断するか | 発注者 | なくても始められるが、契約前には決めておきたい |
①〜③が「必須」です。
ここだけは、開発会社に相談する前に社内で言葉にしておいていただけると、初回の打ち合わせから具体的な話ができます。
それ以外は、ご相談いただきながら一緒に埋めていけるものがほとんどです。
①〜③が決まっていないと、見積りの数字は出ません
ここは、発注されるお客様が損をされないように、あえてはっきりとお伝えしておきます。
目的・使う人・最初に入れる機能。
この3つが決まっていない段階で見積りをご依頼いただいても、どの開発会社からも正確な数字は出てきません。
出てくるとすれば、幅の広い概算か、開発会社側が勝手に前提を置いて作った数字のどちらかです。
後者は見た目には具体的なのですが、その前提が貴社の意図とずれていれば、契約後に「それは含まれていません」が続くことになります。
これは発注されるお客様にとっても、開発会社にとっても不幸な展開です。
逆に言えば、この3つさえあれば、見積りの精度は一気に上がります。
「会員向けの予約アプリで、使うのは30〜50代の既存会員。最初は予約と履歴確認だけで、ポイントや通知はあとから」。
これだけ言語化されていれば、方式も規模も絞れるので、見積りの幅は数倍から1.5倍程度まで縮まります。
難しく考える必要はなく、社内で話し合った内容をそのまま書き出していただければ十分です。
① 目的は「何が増えれば成功か」まで
「アプリを作りたい」は目的ではなく手段です。
その先にある「予約の電話対応を半分にしたい」「既存会員の来店頻度を上げたい」まで言葉にしていただけると、機能の優先順位が自然に決まります。
予約の電話を減らしたいなら予約機能が最優先で、ポイント機能は後回し、という具合です。
私が要件定義でまずお聞きするのもここで、目的が一文で言えるお客様ほど、その後の進行がスムーズです。
もし一文にまとまらなければ、それも含めてご相談いただければ、一緒に整理します。
② 使う人は「具体的な1人」を思い浮かべる
「一般ユーザー」ではなく、「週に1回来店する40代の常連客」のように具体的に。
使う人のITリテラシーと利用場面で、画面の作りも文字の大きさも、ログインの方式まで変わってきます。
社内の業務アプリであれば、使う部署と人数、スマホの支給状況まで分かると、より正確なご提案ができます。
③ 「最初に入れない機能」を決めるのが、いちばん難しい
入れたい機能を挙げるのは簡単で、削るほうが難しい。
これはどのお客様も同じで、悩まれて当然のところです。
ただ、最初のリリースに全部入れようとすると費用が膨らみ、公開も遅れてしまいます。
「これがないと使えない」機能だけを最初のリリースに入れ、残りは公開後の反応を見てから足す。
この仕分けができているお客様の案件は、総額も期間もきれいに収まります。
社内での仕分けが難しければ、「全部入れた場合」と「最小構成」の両方で見積りを出してもらう手もありますし、仕分けそのものをご相談いただいても構いません。
自社で作り込まなくてよいもの
一方で、頑張って用意しすぎないほうがいいものもあります。
ここは意外に思われるかもしれません。
画面一覧や画面遷移図、デザインカンプを社内で作り込んでから持ち込んでくださるケースがあります。
そのご準備には本当に頭が下がるのですが、実はおすすめしていません。
作り込んだものがあると、開発会社側はそれを前提に見積もらざるを得ず、「この画面は不要では」「この遷移は迷いやすい」といった提案がしにくくなります。
要件定義の段階で、目的と使う人から逆算して一緒に設計したほうが、結果的に良いものになります。
もちろん、「こんなイメージ」という手描きのスケッチや参考アプリは大歓迎です。
開発方式(ネイティブかクロスプラットフォームか)も同様で、要件が固まってから開発会社が提案すべきものです。
先に方式を決めてしまうと、選択肢が狭まってしまいます。
選び方の考え方は「[ネイティブ vs Flutter vs React Native の判断基準]」に書いていますので、判断材料として読んでいただく分には役立つと思います。
相談前に社内で確認しておくと助かること
一覧には入れませんでしたが、初回相談でよくお聞きする項目です。
決まっていなくても問題ありません。
ただ、確認してきていただけると、話が一段速く進みます。
| 確認しておくこと | なぜお聞きするのか |
|---|---|
| iOSとAndroid、両方必要か | 片方だけなら費用が大きく変わる。使う人のスマホ比率で決める |
| 既存のWebサイトやシステムのソースコードは自社にあるか | 連携や流用の可否が決まる。ないなら「[引き継ぎ前のチェックリスト](https://www.init-inc.com/column/250)」の話になる |
| 社内にエンジニアはいるか | いるなら契約形態の選択肢が増える(SESや内製との組み合わせ) |
| 個人情報や決済を扱うか | 扱うなら、プライバシーポリシーや審査対応の工数が乗る |
| 多言語対応は必要か | 後から足すと手戻りが大きいので、最初に決めておきたい |
| 公開後の改修は誰が判断するか | 保守契約の形(月額か都度か)に関わる。「[保守・運用費用](https://www.init-inc.com/column/251)」も参考に |
よくある質問
アプリ開発の準備は何から始めればいいですか?
目的・使う人・最初に入れる機能の3つを、社内で言葉にすることからです。
A4一枚に収まる程度で構いません。
それがあれば、開発会社との初回相談で具体的な話ができます。
まとまらない部分があれば、そのままお持ちいただいて大丈夫です。
要件定義は自社でやるべきですか、開発会社に任せるべきですか?
目的と使う人、機能の優先順位は自社で決め、それを画面や仕様に落とす作業は開発会社と一緒にやるのが現実的です。
全部を自社でやろうとすると時間がかかりますし、全部を任せると意図とずれたものができてしまいます。
役割を分けるイメージで考えていただくと、無理がありません。
予算を先に伝えると、その金額いっぱいの見積りが来ませんか?
そのご懸念はもっともだと思います。
ただ、予算を伏せたまま相談されると、開発会社側は規模を測れず、結局は幅の広い概算になります。
「上限はこのくらい、できればこのくらいに収めたい」と幅で伝えていただくと、その範囲で何ができるかのご提案が返ってきます。
信頼できる会社かどうかは、その提案の中身で判断していただければと思います。
画面のイメージ図は作っていったほうがいいですか?
手描きのスケッチや参考アプリのスクリーンショット程度で十分です。
作り込んだデザインカンプは、かえって提案の幅を狭めることがあります。
何社に相談すればいいですか?
2〜3社が目安です。
同じ①〜③を渡して見積りを取ると、各社の前提の置き方や提案の違いが見えてきます。
1社だけだと比較ができず、5社以上になると対応に時間を取られてしまいます。
相談したら、その場で契約を迫られませんか?
まともな開発会社であれば、初回相談で契約を迫ることはありません。
要件が固まっていない段階で契約を急ぐ会社は、むしろ注意が必要です。
「一度持ち帰って検討します」と言える関係が普通ですので、安心してご相談ください。
弊社に頼む必要があるケース、ないケース
最後に、弊社のことを少しだけ。
①〜③が社内で固まっていて、すでに信頼できる開発会社があるのであれば、そのままその会社にご相談いただくのがいちばん早いです。
弊社にご相談いただく必要はありません。
弊社がお役に立てるのは、①〜③をどう言葉にすればいいか、整理の段階から一緒に考えてほしいとき。
社内で作った資料が見積りに足りているか、第三者の目で確認したいとき。
そして、複数社から取った見積りの前提がばらばらで、どれが妥当か判断がつかないときです。
手元にある資料を、まとまっていない状態のままお見せいただいて構いません。
何が足りていて、何が足りないかをお伝えします。
アプリ開発の発注準備について、30分で診断しています。
ご相談だけで終わっても構いません。
