開発パートナーの選定は、情報が少ないまま大きな判断を迫られる場面です。提案資料はどこも良く見え、見積もりは項目ごとの比較が難しく、本当の差はプロジェクトの中盤以降に表面化します。ここでは、結果を予測できる質問を整理します。
まず、何を買うのかを決める
「システムを作ってもらう」と一口に言っても、ニーズは3種類あります。混ぜて話すと見積もりが比較不能になります。
| 必要なこと | 適した相手 | 一般的な料金 |
|---|---|---|
| 作るべきか、どう作るかを見極める | 技術コンサルタント、フラクショナル CTO | プロジェクト費または月額 |
| 決まったものを作る | 開発チーム | 固定価格またはマイルストーン |
| 稼働中のシステムを維持する | 保守チーム | 月額、サービスレベル別 |
中央だけを買うのが最も危険です。要件が固まらないまま着工し、公開後は誰も責任を持たない状態になります。
結果を予測できる 5 つの質問
1. 反対してくれますか？
言われたとおりに作り、疑問を挟まないベンダーはリスクです。良いパートナーはコードを書く前に前提を問い直し、作らなくてよい機能を指摘します。初回の打ち合わせで誰も反論しないなら、それはサービスが良いのではなく、成果に責任を持つつもりがないということです。
2. コードとデータは誰のものですか？
ソースコード、データベース、クラウドアカウントはすべて自社が保有し、いつでも引き取れる状態であるべきです。契約終了日に何が手元に残るかを直接聞いてください。曖昧な回答や、コードが相手のリポジトリにしかない状態は要注意です。
3. 公開後は誰が責任を持ちますか？
保守の範囲、対応時間、費用を確認します。多くのベンダーの責任は納品日で終わりますが、本当のコストはそこから始まります。保守の選択肢がない見積もりは、完全な見積もりではありません。
4. 失敗したときにどう対応しますか？
どのプロジェクトにも失敗はあります。信頼できる相手は、何を壊し、どう直したかを話せます。「失敗したことはありません」は、経験不足か誠実さの不足のどちらかです。
5. 実際に作るのは誰ですか？
提案している人が書く人でしょうか。どれだけ外注されるでしょうか。この答えが、プロジェクト全体のコミュニケーションコストを決めます。
見積もりの読み方
代表的な 3 つの構造と適した場面です。
- 固定価格：範囲が明確なときに最も安全。変更は変更管理を経ます。仕様が固まった案件向け。
- 実費精算：探索フェーズや要件が変わる案件に向きます。工数明細と上限を必ず求めてください。
- 月額チーム：継続的に改修する product 向け。月額に含まれる人数と作業内容を確認します。
比較は同じ範囲で行います。テスト・ドキュメント・3 か月の保証を含む見積もりと、開発だけの見積もりは比較できません。「含まれないもの」を挙げてもらうほうが、総額よりも多くのことが分かります。
契約に明記すべき 5 項目
- 知的財産権の帰属：コード、デザインファイル、データ。相手の既存部品のライセンス条件も含めて。
- 検収基準：何をもって完了とし、誰が判断し、いつまでに回答するか。
- 支払い条件：マイルストーンに紐づけ、全額前払いにしない。
- 保守と保証：期間、対象範囲、その後の保守費用。
- 終了時の取り決め：ソース、ドキュメント、アカウント移管を含む引き継ぎ内容。
警告サイン
- 総額だけで内訳のない見積もり。
- 同種の案件より明らかに短い期間で、根拠を説明できない。
- 検証可能な実績がなく、照会先も出せない。
- ビジネスの質問に技術で答える。「何人分の工数が減るか」と聞いたのに、アーキテクチャの説明が返ってくる。
- 保守の話をしない、または「後で」と先送りする。
- 全額前払いを求める、または自社リポジトリへのコード配置を拒む。
そのまま使えるチェックリスト
各社と話した後で、当てはまる項目にチェックしてください。
- この案件の最大のリスクが何かを言える
- 「これは作らなくてよい」という提案が 1 つ以上あった
- コード、データ、アカウントが自社に帰属する
- 提案した人が開発に関わる
- 見積もりにテスト・ドキュメント・保証が含まれ、項目が明確
- 保守の提供があり、費用が事前に示されている
- 顧客名は伏せてでも、同種案件の進め方を説明できる
- 小さな有償試行から始めることに応じる
6 項目に満たない場合は、価格が安くても見送りを勧めます。途中でベンダーを入れ替えるコストは、通常は当初見積もりの 2〜3 倍になります。
すでに困っている場合
ベンダーと連絡がつかない、担当エンジニアが退職した、ドキュメントがない。いずれも致命的ではありません。まずシステム診断から始めます。コードを引き継げるか、アーキテクチャに致命的な問題はないか、データは揃っているか。そのうえで保守・改善・再構築を判断します。多くのシステムは作り直す必要はなく、責任を持って見る人が必要なだけです。