失敗しない受託開発｜発注前に確認すべき10のチェックポイント

受託開発の失敗の多くは、開発が始まってから起きる。原因はほぼ発注前にある。

「3社見積もりを取った」「提案内容は悪くなかった」——それでも追加費用、納期遅延、品質問題が起きる。発注前に確認すべき論点は、意外と決まっている。

契約印を押す前に、次の10項目を「未回答のまま残していないか」を見る。金額より先に、空白を潰す。

発注前チェックリスト10項目

1. 何を「成功」と定義するか

「システムを作ること」は成功条件にならない。リリース後に何が変わるか——売上、工数削減、離脱率——まで書けているか。

2. スコープの境界線

「含む／含まない」が見積書に明記されているか。UIデザイン、インフラ構築、テスト、運用引き継ぎ——ここが曖昧だと追加費用の温床になる。

3. 見積もりの前提条件

工数見積もりは前提の上に成り立つ。要件の確定度、外部API連携の有無、既存システムとの接続——前提が書かれていなければ、安い見積もりは信用できない。

4. 体制の実名

営業担当だけでなく、PM・テックリード・主要エンジニアが誰か分かるか。名前が出てこない会社は、着手後に別メンバーが入るリスクが高い。

5. コミュニケーション設計

定例の頻度、報告フォーマット、意思決定者、エスカレーション経路——ここが決まっていないと、認識ズレがプロジェクトを止める。

6. 変更管理のルール

仕様変更が起きたとき、誰が判断し、どう見積もり・スケジュールに反映するか。口頭合意だけの変更管理は、必ずトラブルになる。

7. 品質基準

テスト方針、受入条件、性能要件——「動けばOK」で進めると、本番で初めて問題が表面化する。

8. 納品物の定義

ソースコード、設計書、インフラ構成、運用手順書——何が納品されるか。コードだけ渡されて運用できないケースは珍しくない。

9. 保守・引き継ぎの条件

納品後の障害対応、問い合わせ窓口、社内チームへの引き継ぎ期間——「納品したら終わり」の契約は避ける。

10. 出口戦略

万が一うまくいかなかった場合、どこまで進めて、どう切り離すか。途中解約条件や成果物の権利関係を確認しておく。

赤旗：この状態での契約は危ない

• 成功条件が「納品完了」だけ
• 含む／含まないが一覧になっていない
• 体制が「当社基準でアサイン」
• 変更は「都度相談」のみでフローがない
• 受入条件が「発注者確認後」だけで具体がない

赤旗が1つでも即中止ではないが、埋めずに押印すると、後から交渉材料を失う。

現場で効いた使い方

匿名化した一例だ。初回発注の事業会社が、10項目を表にし、未回答を赤にした。最初の候補ベンダーは10項目中4つが赤（体制・変更管理・品質・出口）のまま「早めに契約を」と急かしてきた。

発注側は契約を2週間延ばし、同じ表を別ベンダーにも送った。結果、赤が1つだけの提案と比較でき、前者は見送りになった。後から聞いた話では、見送った側は別案件でもキックオフ直後にメンバー入替が起きていた。

チェックリストは印象論を減らすための道具だ。完璧回答より、未回答の可視化が価値になる。

チェックリストの使い方

10項目すべてを満たす必要はない。ただし、3項目以上が「未回答」のまま契約するのは危険信号だ。

特に「体制の実名」「スコープの境界線」「変更管理のルール」の3つは、見積もり金額より先に確認すべき論点だ。

判断軸：今契約してよいか

状況	推奨
優先3項目（体制・スコープ・変更）が埋まっている	他項目の残を期限付きで埋めつつ契約検討可
未回答が3つ以上で、埋める意思が見えない	契約しない
金額は妥当そうだが成功条件が曖昧	成功条件を先に1段落書く
出口戦略だけ空欄	最低限の解約・成果物条項を入れてから

次に確認すること

1. 10項目の表を作り、未回答を色分けしたか
2. 優先3項目は文書で埋まったか
3. ベンダーに同じ表で回答を求めたか
4. 成功条件は事業指標まで落ちているか
5. 押印前に残課題の期限を切ったか
6. 社内の意思決定者は表を見たか

Beast Technologyの進め方

当社では、契約前に要件整理の段階から参画する。曖昧なまま見積もりを出すのではなく、事業目標と技術スコープを一緒に言語化してから提案する。

「まず何を作るべきか分からない」状態でも、そこから相談できる。

---

受託開発の要件整理・見積もり相談は、お問い合わせフォーム からどうぞ。