アプリ開発会社は、有名さや見積総額だけで選ばず、自社の目的、必要工程、品質、安全、運用に合うかを同じ条件で比較します。実績数の独自ランキングは作りません。提案の根拠、担当者、成果物、契約、終了後の引き継ぎまで確認します。
1. 依頼目的を明確にする
新規事業、既存顧客支援、業務改善など、アプリで達成したい事業目的を定義します。開発会社へ機能一覧だけを渡さず、対象ユーザー、課題、成功指標、制約を共有します。
2. 内製と外注の範囲を分ける
企画、調査、要件、デザイン、実装、テスト、ストア、運用のうち、自社が判断する範囲と依頼範囲を決めます。事業判断や個人情報責任まで丸投げしません。
3. 共通の提案依頼書を作る
候補各社へ同じ目的、要件、対象OS、外部連携、品質、セキュリティ、成果物、希望時期を渡します。不明項目は明示し、仮定を分けて見積もるよう依頼します。
4. 候補の探し方
公式サイト、業界団体、既存取引先、専門家の紹介などから候補を集めます。広告掲載順を評価とみなしません。会社情報、連絡先、契約主体を公式情報で確認します。
5. 実績の確認
似た業界名だけでなく、担当した工程、機能、OS、公開後の運用、現在の担当者を確認します。守秘義務で名称非公開なら、開示可能な範囲と役割を聞きます。他社制作物を自社実績のように示していないか確認します。
6. 課題理解を見る
良い提案は、すぐに機能を増やすのではなく、対象者、業務、既存手段、制約を質問します。提案書に課題の理解、仮説、検証方法、対象外が書かれているかを見ます。
7. 技術提案を見る
ネイティブ、クロスプラットフォーム、Webなどの選択理由、制約、保守、チーム経験を確認します。流行語だけでなく、自社要件に対する利点と欠点が説明されているかを評価します。
8. 担当体制を確認する
営業だけでなく、責任者、プロジェクト管理、設計、デザイン、開発、テスト、保守の実担当を確認します。兼任、所在地、稼働、交代時の引き継ぎ、緊急連絡を聞きます。
9. 再委託を確認する
どの工程を誰へ再委託するか、事前承認、秘密保持、個人情報、品質責任を契約にします。再委託自体で判断せず、透明性と管理方法を確認します。
10. 開発プロセス
要件、プロトタイプ、反復、レビュー、テスト、リリースの進め方を確認します。定例会の頻度より、意思決定、課題、変更、承認が記録されるかを見ます。自社の参加工数も把握します。
11. 品質管理
対応端末、OS、テスト種類、不具合優先度、受け入れ条件、公開可否を確認します。テストを「一式」とだけ書かず、対象と成果物を明記してもらいます。アクセシビリティと性能も含めます。
12. セキュリティ
開発環境、ソース管理、認証、秘密情報、脆弱性、ログ、バックアップ、インシデント対応を確認します。認証資格や診断実績は有効範囲と担当者を確認し、ロゴだけで安全を断定しません。
13. プライバシー
取得データ、外部SDK、保管場所、アクセス、保持、削除を設計できるか確認します。AppleとGoogle Playへ申告する内容と実装を一致させる工程を含めます。テストデータに実顧客情報を安易に使いません。
14. ストア公開経験
署名、ビルド、掲載情報、プライバシー申告、審査対応の担当範囲を確認します。審査通過保証をうたう提案ではなく、公式要件の確認と差し戻し時の対応を見ます。ストアアカウントは自社所有にします。
15. 見積書を比較する
工程、成果物、単価、数量、前提、対象外、追加単価、保守を同じ行で比較します。総額だけで選びません。不明な費用は質問し、各社の前提をそろえて再見積もりします。
16. スケジュール
要件、確認、テスト、審査、移行、予備期間を含むか確認します。短納期を成果として評価せず、前提と削られる工程を聞きます。自社の承認遅延も計画に入れます。
17. 契約方式
請負、準委任など名称だけでなく、成果物、指揮、検収、変更、支払い、責任を契約文で確認します。要件が未確定なら調査・要件工程を分ける方法も検討します。
18. 知的財産と所有
ソースコード、デザイン、仕様、素材、データ、ドメイン、クラウド、ストア、外部ライセンスの帰属を確認します。既存部品と新規成果物を分け、利用・改変・移管できる範囲を合意します。
19. 保守と障害対応
対象作業、受付時間、一次応答、復旧、報告、月間上限、時間外、脆弱性、OS更新を確認します。開発契約終了後も運用できる体制と費用を見積もります。
20. 解約と移管
ソース、設計、アカウント、鍵、データ、手順、未解決課題をどの形式で返却するか決めます。移管支援の単価、期間、権限削除、データ削除を契約前に確認します。
小さく試す
大規模契約の前に、調査、プロトタイプ、技術検証など限定範囲を依頼します。成果物だけでなく、質問、記録、品質、連絡、問題対応を実際に確認します。試行条件は候補間で可能な限りそろえます。
比較表の作り方
行に候補、列に業務範囲、担当、技術理由、テスト、セキュリティ、総費用、所有、保守、移管を置きます。公式資料や提案書で確認できない項目は「-」にし、独自点数へ変換しません。
最終確認
契約書、提案、見積、議事録の矛盾を確認します。重要条件は口頭の約束だけにせず文書化します。価格交渉で品質工程が削られていないか再確認し、意思決定理由を残します。
提案面談で聞くこと
過去の成功談だけでなく、要件が曖昧だった案件でどう調査したか、重大不具合をどう防いだか、公開後の問題をどう報告したかを聞きます。回答を抽象的な「柔軟に対応」で終わらせず、工程、成果物、担当、判断基準の例を確認します。
自社要件に対して、作らない方がよい機能や段階的に検証すべき箇所も尋ねます。すべての要望を肯定する提案より、制約と代替案を根拠付きで説明できるかを見ます。ただし面談の印象だけで採点せず、提案書と契約へ反映された内容で比較します。
参照先への確認
紹介可能な取引先がある場合は、担当範囲、連絡、変更、品質、公開後支援について確認します。機密情報や成果数値の開示を求めず、紹介先の同意を得た範囲に限ります。一件の評価を全案件の品質へ一般化しません。
契約後の立ち上げ
開始時に、権限、連絡経路、会議、決定記録、課題管理、成果物保管、セキュリティ、請求を確認します。会社のストア・クラウド・リポジトリへ必要最小限の権限で招待し、個人アカウントや共有パスワードを使いません。
最初の節目で提案時の前提と現状を照合し、差があれば変更手続きへ進みます。問題を隠して終盤にまとめて報告しない体制を作ります。四半期ごとに担当、再委託、権限、契約、保守を点検し、変更がなくても確認日を更新します。
選定結果は、候補を選んだ理由だけでなく、他候補を見送った事実ベースの理由も記録します。価格、体制、対象範囲など提案書で確認できる内容に限定し、担当者への印象や根拠のない評判を書きません。次回調達時には同じ条件を再確認し、古い評価を現在も有効とみなしません。
公開後は、契約時の体制と実際の担当、保守応答、品質報告、権限管理を定期的に照合します。変更があれば影響と代替担当を確認し、重大な前提変更は書面へ反映します。良好な関係でも、アカウントとデータを自社で管理する原則は変えません。
まとめ
アプリ開発会社は、同じ依頼条件で提案、担当、品質、安全、費用、所有、保守、移管を比較します。順位や知名度ではなく、自社の必須条件と証拠で絞り、小さな工程で協働方法を確認してください。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。