COLUMNCTOがいない会社のシステム開発——発注する前に決めるべき6つのこと

社内にCTOやエンジニアがいないまま、システム開発を外部に発注する。新規事業ではよくある状況ですが、実はこの「発注の瞬間」までに、プロジェクトの成否はほぼ決まっています。

私は13年間、受託開発会社の代表として200件を超える開発相談を受けてきました。炎上するプロジェクトには共通点があります。開発が下手だったのではなく、発注の前に決めるべきことが決まっていなかったのです。この記事では、開発会社に声をかける前に社内で（あるいは信頼できる相談相手と）決めておくべき6つのことをまとめます。

1. 「何を作るか」ではなく「何が変わればよいか」を決める

発注前に機能一覧を作り込む必要はありません。むしろ危険です。決めるべきは「このシステムで、誰の、何が、どう変わればビジネスとして成功か」。機能はその手段にすぎず、開発の途中で必ず変わります。

悪い例：「予約機能とマイページと決済機能とお知らせ機能が欲しい」
良い例：「電話で受けている予約を自動化して、事務スタッフの時間を月40時間空けたい」

後者で相談すれば、まともな開発会社は「その目的なら最初は決済機能は不要では」といった提案を返してきます。その提案の質が、開発会社を見極める最初のリトマス紙になります。

2. 「作らない」選択肢を最後まで残す

相談の1〜2割は、実はスクラッチ開発が不要です。SaaSの組み合わせ、ノーコード、業務フローの変更で足りるケースは珍しくありません。開発会社に相談すると「作る前提」で話が進みがちです——彼らは作ることが商売だからです。

見極める質問はシンプルで、「これ、作らずに済む方法はありますか？」と最初に聞くこと。「作らないほうがいい」と言える会社は、あなたの事業の側に立っています。

3. 予算は「初期開発費」ではなく「3年の総額」で考える

システムの費用は、作って終わりではありません。サーバー費用、保守、機能追加、セキュリティ対応——一般に、初期開発費と同じかそれ以上の金額が、リリース後の3年間でかかります。

初期費用の安さだけで開発会社を選ぶと、「安く作って、保守で回収する」型の会社に当たることがあります。見積もりを取るときは必ず「リリース後の運用は月いくらか、何が含まれるか」までセットで聞いてください。

4. 契約形態の違いを知っておく（請負・準委任・定額）

• 請負：成果物を約束する契約。仕様が完全に固まっている場合は有効ですが、新規事業では仕様変更のたびに再見積もり・追加費用が発生しやすい
• 準委任：稼働時間に対して支払う契約。柔軟だが、進捗の管理責任は発注側に残る
• 月額定額：毎月一定額で開発チームが継続的に動く形。仕様変更を前提にでき、予算が読みやすい。新規事業に向くが、範囲の定義が曖昧な会社は避ける

どれが正解というより、事業のフェーズに合っているかが重要です。仕様が固まっていない新規事業で請負契約を結ぶのは、最も典型的な失敗パターンです。

5. 見積もりは金額ではなく「前提」を読む

見積書で見るべきは合計金額ではありません。どんな前提でその金額なのかです。

• 何が含まれ、何が含まれないか（デザインは？テストは？サーバー構築は？）
• 仕様変更が起きたらどうなるか
• 誰が作るのか（担当者のスキル。再委託の有無）
• 検収の条件と、修正は何回まで含むか

前提が書かれていない安い見積もりは、あとから「それは別料金です」が積み上がります。相見積もりで金額だけを比べるのは、前提が違うものを比べているので意味がありません。

6. 「技術の相談相手」を発注の前に持つ

ここまでの1〜5を、エンジニアがいない社内だけで判断するのは正直難しい。だからこそ、発注する前に、発注先ではない技術の相談相手を持つことをお勧めします。

外部CTOや技術顧問のサービスもありますし、スポットで相談できるプラットフォームもあります。重要なのは「その人が何かを売る立場でないこと」。開発会社の営業に相談するのは、不動産屋に「今買うべきですか」と聞くのと同じです。

まとめ

発注前に決めるべき6つ：①目的を「変化」で定義する ②作らない選択肢を残す ③予算は3年総額 ④契約形態をフェーズに合わせる ⑤見積もりは前提を読む ⑥売る立場でない相談相手を持つ。