開発会社の選び方：契約前に確認すべき12の質問

アプリ開発を任せるベンダー選びは、家を建てる工務店選びに似ています。完成したものは何年も使い続けるのに、判断は1〜2回の打ち合わせと1枚の見積書だけで下されることが少なくありません。この記事は、私たちがまとめた開発会社（ソフトウェアハウス）選びのチェックリストです。どのベンダーでも公平に評価できるように作りました。もちろん、私たち自身を評価するときにも使っていただけます。

質問は12個あります。すべてに完璧な答えが返ってくる必要はありませんが、一つひとつの答えから、そのベンダーの仕事の進め方がよく見えてきます。

契約前に確認すべき12の質問

1. 実際にプロジェクトを担当するのは誰ですか？

営業担当者だけでなく、実際にコードを書き、デザインをする人の名前と役割を確認しましょう。また、社内チームで対応するのか、第三者に再委託するのかも聞いてください。再委託が必ずしも悪いわけではありませんが、コミュニケーションの質や責任の所在に関わるため、知っておく権利があります。

2. 自社で作ったプロダクトを見せてもらえますか？

取引先のロゴを並べた実績紹介は簡単に作れます。ごまかしにくいのは、自分で開いて試せるプロダクトです。受託案件だけでなく自社プロダクトを持つベンダーは、アプリを長期運用する現実をよく理解している傾向があります。自分たちの技術的な判断ミスの結果を、自分たちで背負うからです。

3. 開発プロセスは？ 進捗はどのくらいの頻度で確認できますか？

健全な回答は、明確な工程と、たとえば毎週のような定期的なデモのリズムを説明してくれるものです。「完成したらご連絡します」という答えなら大きなリスクです。問題に気づくのが3か月後になってしまいます。妥当な工程のイメージは経営者のためのSDLC解説をご覧ください。

4. ソースコード、リポジトリ、各種アカウントの所有者は誰ですか？

最も見落とされやすく、間違えると最も高くつく質問です。次の点を書面で確認してください。

• 支払い完了後、ソースコードとリポジトリが貴社に帰属すること。
• ドメイン、ホスティング、クラウドアカウント、アプリストアのアカウント、外部サービスが、ベンダー名義ではなく貴社名義で作成されること。
• ベンダーだけでなく、貴社もそのすべてに管理者権限を持つこと。

将来ベンダーを変更したくなったとき、移行が1週間で済むか大混乱になるかは、ここで決まります。

5. アプリ以外に何が納品されますか？

技術ドキュメント、デプロイ手順、データベース構造、アカウント一覧です。これらがないと、次のベンダー（あるいは将来の社内チーム）は推測で作業するしかありません。可能であれば、過去のプロジェクトのドキュメント例を見せてもらいましょう。

6. アプリのテストはどのように行いますか？

何年も使うアプリでは「納品前に手動でテストします」だけでは不十分です。自動テストの有無、メンバー間のコードレビュー、リリース後にバグが見つかったときの対応を確認してください。テストを追加オプションではなく標準作業として扱うベンダーほど、安定したアプリを納品する傾向があります。

7. 見積もりの算出方法と支払い方法は？

一般的なモデルは2つあります。

どちらも正当なモデルです。問題なのは、スコープが曖昧なまま固定価格にすることで、どちらかが必ず損をします。価格に何が含まれているか（デザイン、テスト、デプロイ、トレーニング、修正回数）の内訳を求めましょう。費用構造の詳細は2026年版 インドネシアのアプリ開発費用で解説しています。

8. リリース後はどうなりますか？

アプリはリリースで終わりではありません。OSはアップデートされ、外部サービスは仕様が変わり、新しいバグも見つかります。バグ修正の保証期間はあるか、その期間はどれくらいか、その後の保守体制と費用はどうなるかを確認してください。ここに答えられないベンダーは、必要なときにそばにいるつもりがないのかもしれません。

9. 顧客データはどのように保護されますか？

データの保存場所、アクセスできる人、パスワードや機密データの暗号化方法、定期バックアップの有無を確認しましょう。AIを使うプロジェクトなら、AIモデルの提供元にどのデータが送られるかも聞いてください。信頼できるベンダーは「安全なのでご安心ください」ではなく、具体的に答えてくれます。

10. 日々のコミュニケーションはどのように行いますか？

どのチャネル（WhatsApp、メール、プロジェクト管理ツール）を使うのか。返信はどのくらいの速さか。エンジニアと直接話せるのか、常に窓口を通すのか。遅い、あるいは何層にも挟まれたコミュニケーションは、プロジェクト遅延の最もよくある原因です。

11. 契約を終了する場合はどうなりますか？

聞きにくい質問ですが、重要です。引き継ぎのプロセスはあるか。コードとアカウントは、別のベンダーが引き継げる状態で渡されるか。いわば「身代金」のような費用を求められないか。自社の仕事の品質に自信があるベンダーなら、この質問を嫌がりません。

12. AIプロジェクトの場合：AIで何を作ってきましたか？ その限界は？

プロジェクトにAIが関わるなら、実際の経験を聞きましょう。LLMでどんなプロダクトを作ったか、誤った回答にどう対処しているか、精度をどう測っているか。「100%正確」「何でもできる」AIを約束するベンダーには注意が必要です。誠実なベンダーは限界も説明します。私たちもWhatsApp AIチャットボットや業務文書のためのRAGの記事でそうしています。

正直にお伝えすると： 私たちもここに挙げたすべての点で完璧なわけではありません。若い会社なので、受託実績の一覧はまだ長くありません。お見せできるのは、自社で開発したプロダクトであるCuplikinとKosPro、そしてオープンな仕事の進め方です。後から知られるより、最初にお伝えしておきたいと考えています。

注意すべき危険信号

私たちの考えでは、次のような兆候があれば慎重になるべきです。

• 詳細を聞かずに10分で金額を提示する。 良い見積もりにはスコープの理解が必要です。
• すべての機能に「できます」と答える。 何でもできるベンダーは存在しません。誠実なベンダーは、簡単なこと、難しいこと、やらないほうがよいことを伝えてくれます。
• リポジトリやアカウントへのアクセスを渡さない。 意図的な囲い込みです。
• 何週間もデモや目に見える進捗がない。
• 「本日限り」の値引きで即決を迫る。
• 技術的な判断を理解できる言葉で説明できない。 すべてを理解する必要はありませんが、良いベンダーは「なぜそうするのか」をわかりやすく説明できます。
• 「いいえ」と言わない。 途中で出た要望に、スケジュールや費用への影響を話し合わずにすべて応じるベンダーは、後々の問題をため込んでいます。

見積もりを公平に比較する方法

「同じアプリ」に対して4,000万ルピア、9,000万ルピア、2億ルピアという3つの見積もりが出たなら、それはほぼ確実に同じアプリではありません。公平に比較するには、次の手順を踏みます。

1. スコープをそろえる。 主要なユーザーフローと、Must／Should／Couldに分けた機能リストを書き、同じ資料をすべてのベンダーに送ります。まとめ方はMVPとフル機能プロダクトの違いで解説しています。
2. 含まれる作業を表にする。 デザイン、テスト、デプロイ、ドキュメント、トレーニング、保証、保守。合計金額1つより、○×の表のほうが正直です。
3. 金額だけでなく前提条件を比較する。 「決済サービス1社との連携」「デザイン修正は最大3回」のように前提を明記するベンダーは、数字を1つ書くだけのベンダーより責任の所在が明確です。
4. 開発費だけでなく2〜3年分の総費用を計算する。 保守、サーバー、外部サービスの利用料。見積もりが安くても保守が高ければ、総額は高くなることがあります。
5. 質問の質に注目する。 見積もり前に貴社のビジネスについて多く質問するベンダーは、これから作るものをよりよく理解している傾向があります。

フリーランス、開発会社、社内チーム、どれを選ぶ？

補足として、選択肢は開発会社だけではありません。

技術スタッフのいない中小企業であれば、開発会社か、明確なプロセスを持つ経験豊富なフリーランスが、多くの場合もっとも現実的な選択です。社内チームは、プロダクトの価値が実証され、継続的な開発が必要になった段階で検討するとよいでしょう。

次のステップ

この12の質問を手元に置いて、検討中のすべてのベンダーに聞いてみてください。もちろん私たちにも。試してみたい方は、無料の初回相談でアプリの構想をお聞かせいただき、このリストの質問を何でもぶつけてください。サービス内容をご覧のうえ、お問い合わせフォームからメッセージを送るか、WhatsAppでご連絡ください。メール（hello@rancanginaja.com）でのご相談も歓迎しています。