受託開発会社で営業の兼務に限界を感じるのは、受注すると納品へ集中し、案件が終わってから次の営業を始める状態が続くときです。営業を止めなければ割り込みが増え、止めれば次案件がなくなるため、努力量ではなく役割と時間の境界が必要です。
この記事の結論
受託開発会社が営業と納品を両立するには、代表が案件の選別と受注判断、PMが見積もり前の要件・工数・変更管理、エンジニアが技術判断と実装に集中する境界を決めます。さらに受注可能枠を先に算出し、営業枠・納品枠・緊急枠をカレンダーで確保し、繁忙時も見込み案件の記録と次回連絡だけは止めません。
この記事は、どの顧客をどう開拓するかではなく、営業と納品を同じ人員で両立する運用を扱います。対象顧客、紹介・協業候補、案件獲得ルートは、最後に紹介する別記事へ明確に分けます。
代表・PM・エンジニアの役割を三つに分ける
役割を分ける目的は、部署を増やすことではありません。一人が兼任する場合でも、どの立場で何を判断しているかを分け、開発中の割り込みを減らします。
役割 | 主な責任 | 営業で担うこと | 納品で担うこと |
|---|---|---|---|
代表 | 受注の優先順位と経営判断 | 対象外案件の見送り、重要商談、価格・リスクの最終判断 | 重大な例外と顧客関係の判断 |
PM | 要件・工数・スコープの境界 | 見積もり前の確認、体制・期限・変更条件の整理 | 進行、変更管理、顧客との調整 |
エンジニア | 技術的な実現性と品質 | 必要な技術判断、調査範囲の回答 | 設計、実装、検証、技術課題の共有 |
代表は案件の選別と受注判断を担う
代表がすべての初回連絡、ヒアリング、見積もり、進捗確認を抱えると、営業と納品の両方が代表の空き時間待ちになります。代表は、受ける案件の条件と例外を決めます。
- 自社が強い案件か
- 受注可能枠に入るか
- 顧客側の責任者と判断時期が分かるか
- 価格、期限、技術、契約上のリスクを受けられるか
- 将来の保守や追加開発を含め、会社の方針に合うか
条件に合わない案件を早く見送ることも、納品を守る営業判断です。
PMは要件・工数・変更の境界を担う
PMは、営業が持ち帰った期待を開発可能な条件へ変えます。すべての初回商談へ参加する必要はありません。概算工数、期限、体制、外部連携、未確定要件が受注判断へ影響する段階で参加します。
PMが確認するのは、要件を完全に決めることではなく、「何が分かれば見積もれるか」「未確定部分をどう扱うか」「変更時に誰が何を判断するか」です。
エンジニアは技術判断と実装へ集中する
エンジニアを営業へ参加させるのは、技術的な不確実性を減らす必要があるときに限ります。顧客との日程調整や一般的な会社説明まで任せると、集中時間が細切れになります。
技術確認を依頼するときは、質問、前提、回答期限、必要な精度をPMがまとめます。「少し相談したい」という割り込みを減らし、調査が必要なら営業工数として記録します。
受注可能枠から営業活動の上限と時間を決める
営業目標から受注件数を決めるだけでは、納品能力を超える可能性があります。先に受注可能枠を計算します。
受注可能枠は、次の考え方で出します。
受注可能枠 ＝ 提供可能時間 − 受注済み案件の見込工数 − 変更対応の余白 − 社内業務
提供可能時間には、実装だけでなくPM、レビュー、顧客会議、テスト、リリース、保守を含めます。人員の総勤務時間をそのまま販売可能時間にしないでください。
納品枠と変更対応の余白を先に引く
受注済み案件は、残工数だけでなく、不確実性を確認します。
- 要件が確定しているか
- 顧客確認の待ちがあるか
- 外部サービスや他社へ依存しているか
- 変更要求が起きやすい工程か
- リリース後の対応が見込まれるか
変更対応の余白は、すべての会社へ同じ率を当てるのではなく、過去案件の差分から更新します。余白を使い切ったら、追加受注より先に既存案件の範囲と期限を見直します。
営業枠を週の予定へ固定する
「空いた時間に営業する」では、納品がある限り空きません。代表、PM、エンジニアそれぞれに、営業へ使える時間を固定します。
- 代表：案件選別、重要商談、受注判断の時間
- PM：見積もり前の確認と引き継ぎ準備の時間
- エンジニア：まとめて技術質問へ回答する時間
営業枠は毎日細切れにせず、役割ごとにまとめます。緊急枠は営業と納品のどちらにも使い切らず、障害や重大変更に備えます。使わなかった緊急枠を自動的に新規受注へ回すのではなく、次週の計画時に判断します。
商談から納品への引き継ぎゲートを置く
受注後に初めて開発側が条件を知ると、見積もりと納品の前提がずれます。見積もり前と受注前に、次工程へ進める条件を置きます。
見積もり前に五つの条件を確認する
最低限、次の五つを確認します。
- 目的：顧客が何を変えたいか
- 対象範囲：今回含める業務・機能と対象外
- 判断者：要件、費用、期限、受入を誰が決めるか
- 前提：既存システム、データ、外部連携、顧客側作業
- 未確定事項：調査が必要な点と、確定する時期
この条件が不足する場合は、確定見積もりを急がず、調査工程、概算範囲、追加確認のどれで進めるかを決めます。PMやエンジニアが無償で無制限に調査する状態を避けます。
受注後の変更窓口を一本にする
受注後は、顧客からエンジニアへ直接届く変更依頼をPMへ集めます。小さな変更でも、工数、期限、他機能、品質へ影響することがあります。
PMは、変更内容、理由、影響、追加判断が必要な人を整理し、代表が判断すべき価格・期限・リスクだけを上げます。営業担当が顧客へ約束し、開発側が後から知る状態をなくします。
繁忙時にも止めない営業作業を一つに絞る
納品が繁忙な時期に、平常時と同じ営業量を維持する必要はありません。ただし、すべてを止めると、再開時に見込み案件の状況確認から始まります。
新規提案を減らしても見込み案件の記録は残す
繁忙時に残す最低限の作業は、見込み案件の記録と次回連絡日です。
- 相手が解決したい課題
- 現在の検討段階
- 次に相手が行うこと
- 自社が次に行うこと
- 連絡する日
- 受注可能になる時期
新しい提案作成や広い候補探索を一時的に減らしても、既に会話している相手へ返信し、いつ回答できるかを伝えます。無理な納期を約束するより、受注可能時期を正直に示します。
次の開始日を決めて一時停止する
営業施策を止める場合は、「納品が落ち着いたら再開」ではなく、再開日と条件を決めます。たとえば、特定工程の完了、顧客受入の終了、受注可能枠の回復などです。
週次では、納品の残工数、変更対応の余白、見込み案件の次回行動を同じ表で確認します。納品が予定より増えたら、営業枠を無言で削るのではなく、どの作業を止め、いつ再開するかを決めます。
役割と時間を整えた後で、次案件の入口自体が不足しているなら、受託開発の新規開拓でDX・BPO・士業との案件ルートを作る方法へ進んでください。公開済み記事は対象顧客と協業先の選び方、本記事は営業と納品を両立する運用を扱っており、目的が異なります。
最初に行うのは増員の判断ではなく、三役の境界、受注可能枠、固定する営業時間、引き継ぎゲート、繁忙時に残す一作業を一枚にすることです。誰かの空き時間に依存しない状態が、納品を守りながら次案件を準備する土台になります。