ソリューション・受託開発

仕組み

ソリューション・受託開発（SI、システムインテグレーション）は、顧客ごとの要件に合わせてシステムを作り、動かし続けることを請け負うモデルです。仕事の流れは、おおむね次の段階に分かれます。

• 企画・コンサルティング: 業務課題の整理、IT戦略、要件の検討
• 開発・構築: 設計、プログラミング、テスト、パッケージ製品の導入
• 運用・保守: 稼働後の監視、障害対応、改修、データセンターやクラウドの運用
• 物品販売: ハードウェアやライセンスの仕入販売

同じ業界の複数の顧客が共通で使うシステムを提供者側が用意し、利用料を受け取る「共同利用型」の提供形態もあります。

収益の上がり方

開発は案件ごとの売上で、人員（エンジニア）の稼働量にほぼ比例します。契約形態は、成果物の完成に責任を負う請負と、作業の遂行に対して対価を払う準委任に大きく分かれ、どちらかによって赤字リスクの所在が変わります（開発会社との契約の注意点（請負と準委任））。

一方、運用・保守や共同利用型サービスは、システムが動いている間続く継続収入です。開発で顧客と関係を作り、運用で長く収益を得る組み合わせが、この型の基本的な稼ぎ方です。

利益を左右するのは次の点です。

• 見積もりの精度（想定外の工数増加＝不採算案件を出さないこと）
• 稼働率（手の空いた技術者を減らすこと）
• 単価（業務知識や上流工程の比率が高いほど上がりやすい）

見るべき指標

• 受注高・受注残高（先の売上の見通し）
• 売上に占める運用・保守など継続収入の比率
• 売上総利益率と不採算案件の発生状況
• 技術者1人あたり売上・利益、稼働率
• 主要顧客への依存度

向いている事業・注意点

業務が複雑で、既製のソフトウェアでは合わない領域（金融、公共、大企業の基幹業務など）に向いています。業界知識が深いほど、同じ業界の次の顧客に展開しやすくなります。

注意点は、売上が人数に比例しやすく急な拡大が難しいこと、見積もりの誤りが直接赤字につながることです。要件が固まらないまま開発を始めると追加工数が膨らみやすいため、MVPの要件定義の進め方で扱うような要件の詰め方が重要です。

新規事業で使うとき

新規事業では、受託開発を「最初の収益源」と「顧客理解の手段」として使う例がよくあります。特定業界の案件を重ねると、各社に共通する機能が見えてきます。それを自社製品やクラウドサービスに切り出せば、人数に比例しない収益源に移ることができます。

ただし、受託の売上が安定すると製品化への投資が後回しになりやすい点には注意が必要です。どの時点で何割の人員を製品開発に回すかを、あらかじめ決めておくと判断がぶれにくくなります。大企業向けの提案・受注の進め方はBtoB新規事業の営業プロセスも参照してください。