営業が約束した機能を誰が承認するか。受注前の技術確認を作る

営業が開発前の機能を約束してよいのは、顧客の要望を聞いた時点ではありません。製品責任者が優先順位と製品方針を、技術責任者が依存関係や運用可能性を確認し、経営者が事業上の条件を受け入れた範囲だけです。営業には商談を前へ進める責任がありますが、未提供機能の作り方と提供時期を一人で決める責任までは持たせません。

受注前の技術確認は、営業を止める関所でも、詳細な要件定義でもありません。「いま言えること」「条件が満たされれば言えること」「まだ言えないこと」を分け、顧客への回答者を決める仕組みです。この仕組みなら、営業は曖昧に逃げず、開発も商談のたびに即答を迫られません。

難しいのは、確認をいつ、どの情報で始めるかです。すべての質問を技術責任者へ送れば商談は滞り、契約直前まで送らなければ約束が先に固まります。僕なら商談を三段階に分け、確約の強さに応じて承認者と台帳の記載を増やします。

営業が開発機能を約束できる範囲を商談三段階で分ける

次の表は、出典の一般原則を基に僕が提案する実務上の方法であり、原典所定の分類や義務ではありません。初回ヒアリングでは事実の収集、提案段階では前提付きの実現可能性、契約直前では承認済みの提供内容だけを扱います。

判断の起点は、顧客の要望の強さと開発の優先順位を切り分けることです。GitLabのCustomer Issues Prioritization Frameworkは、顧客影響を、その機能なしでは販売できないもの、既存顧客の維持に関わるもの、販売や維持は可能でも将来提供を確約済みのものなどに分けています。そのうえで、各区分を計画への入力と位置づけ、技術的依存関係、戦略上の優先順位、製品全体の方向性と比較し、製品チームが最終的な優先順位を決めるとしています。2026年9月21日時点の公開ハンドブックで確認でき、ページの更新日は2026年4月9日です。

つまり「この機能がないと受注できない」は、重要な商談情報ですが、そのまま開発命令にはなりません。営業は重要度を記録し、製品責任者は他の要求と製品方針を比べ、技術責任者は実現条件を調べます。その結果を受けて、経営者が受注条件として引き受けるかを決めます。この承認境界は、GitLabの一般原則を基に僕が提案する方法であり、同社所定の役割分担ではありません。

「技術的には作れる見込みです」は、契約上の確約と同じではありません。情報が足りないまま固定した約束を作る危うさは、英国政府のContracting For Agile Guidance Noteにも通じます。同ガイダンスは、情報が限られて不確実性が大きい案件ほど硬直的な一括固定価格では意図した成果を得にくいとし、フェーズ単位の契約や、理解を深めてから構造化する方法を示しています。2026年9月21日時点で確認し、ページの更新日は2023年6月20日です。受注前にも、分からないことを消したふりで固定せず、確認後に確定する条件として表へ出すべきです。

技術確認へ渡す条件付き見積もりを一つの台帳にする

技術確認の依頼をチャットの「実現できる見込みですか」だけで済ませると、技術側は顧客が何を必須とするのか分かりません。返答が「たぶん可能です」だけなら、営業側はどこまで提案書に書けるのか分かりません。往復を減らすには、詳細仕様に入る前に判断条件を台帳へそろえます。

台帳には、次の項目だけを同じ場所へ置きます。台帳は出典の一般原則を基に僕が提案する実務上の方法であり、原典所定の様式や義務ではありません。

• 顧客の必須条件、対象範囲と範囲外、既知の回避策、未確認の技術前提、外部依存、運用・セキュリティ上の確認点、希望時期、製品・技術・経営の承認者、条件が崩れたときの再確認先

空欄は無理に埋めず、「未確認」と表示します。そのうえで、空欄が残っていても出せる回答なのか、埋まるまで確約できないのかを決めます。

GitLabの同フレームワークでは、顧客課題の内部コメントに顧客レコードへのリンク、事業上の影響、必要に応じた顧客区分を記録し、回避策や商談状況が変われば文脈を更新します。顧客名や契約額などの機密情報はコメントへ直接書かず、リンク先の外部システムに置く方針です。2026年9月21日時点の確認です。受注前の台帳には、アクセス権を制限した顧客レコードへのリンクと要望名を残し、広く共有する課題やコメントには顧客名や契約額を直接書きません。そのうえで「なぜ必要か」と「何が変わったか」を残します。

技術側は、実装方法に加えて運用まで確認します。GoogleのLaunch Coordination Checklistは、リリース前の確認対象として、アーキテクチャ、容量・性能、信頼性とフェイルオーバー、監視、セキュリティ、変更・リリース手順、成長余地、外部依存、日程とロールアウト計画を挙げています。2026年9月21日時点で確認し、本文上の公開日・更新日は確認できませんでした。受注前には、提案の成立を左右する項目をこの一覧から選び、未確認事項の見落としを防ぎます。全項目の完了はリリース前に改めて確認します。

外部データ連携の条件付き見積もり例

たとえば、顧客が「自社で使う外部サービスのデータを取り込みたい」と求め、外部データの取り込みが受注の必須条件になったとします。初回ヒアリングで営業が確約できるのは、現行製品にその連携があるか、既知の代替手段があるかまでです。新規開発が必要なら、提案段階の台帳へ移します。

台帳の顧客必須条件には「外部サービスのデータを製品で扱えること」と書きます。ただし、必須条件の記載だけでは見積もれません。対象範囲には取り込むデータと処理を、範囲外には顧客側のデータ整備など今回引き受けない作業を記します。未確認の技術前提には、接続方法、利用できるデータ、認証、利用上の制約を置きます。外部依存には、相手側の仕様や利用許可が変わった場合の影響を置きます。運用・セキュリティ欄では、失敗の検知、再実行、アクセス制御など、提案成立前に確認すべき論点を示します。

この時点の回答例は、次のようになります。

外部データ連携は、記載した対象範囲を前提に技術確認へ進めます。接続方法、利用できるデータ、認証、利用上の制約、運用・セキュリティ条件は未確認です。各条件を確認し、製品責任者が優先順位と製品方針を、技術責任者が依存関係と運用可能性を承認した後に、提供内容と時期を確定します。前提が変わった場合は、対象範囲と回答を再確認します。

この回答例では見積額を確定せず、見積もりの確定に必要な確認事項を示しています。営業は可否を先走って答えず、顧客へ次の判断点を伝えられます。技術側も、商談の背景が分からないまま全設計を始める必要がありません。

確認後に実現可能と分かっても、すぐ確約にはしません。製品責任者は、個別商談への対応が製品全体の方向性と両立するかを判断します。技術責任者は、外部依存、非機能要件、運用可能性を含め、どの前提なら回答できるかを示します。経営者は、その条件を顧客との約束として引き受けるかを決めます。営業は承認済みの文章を提案書へ反映し、前提の変更を見つけたら台帳を再び開きます。

営業から開発への受け渡しでは、顧客課題を最もよく知る営業、製品全体を扱う製品責任者、実現と運用を扱う技術責任者、事業上の約束を引き受ける経営者が、各担当者の判断を一つの記録へ重ねます。部門間の言葉を決裁可能な形へ直す役割については、経営と技術をつなぐ人がいないと、会議は決まらないでも整理しています。

契約直前は承認済みの条件を読む

契約直前の確認会議では、機能一覧の丸印から一段深く読みます。確認対象は、顧客の必須条件、承認された対象範囲、残っている未確認事項、外部依存、運用条件、希望時期と回答可能な時期、前提が崩れた場合の再確認先です。営業の説明、技術側の認識、提案書の記載が同じ台帳を参照しているかを確かめます。

経営者は技術の細部を再審査せず、残る条件を理解したうえで約束するのか、条件を明記して契約するのか、確定まで提案から外すのかを決めます。技術責任者は、分かったこと、未確認のこと、再判断が必要になる変化を示します。リスクをゼロと言い切る役割ではありません。経営と技術の決裁をどう分けるかは、CTO代行を入れると、組織の意思決定はどう変わるのかも参考になります。

営業が開発機能を約束して混乱する会社では、営業個人の慎重さを求めるだけでは足りません。初回ヒアリングは課題と現行仕様まで、提案段階は前提付きの実現可能性まで、契約直前は製品責任者と技術責任者が確認し、経営者が引き受けた範囲だけとします。この境界を営業資料に組み込みます。

まず、進行中の商談から未提供機能を一つ選び、条件付き見積もりの台帳へ移してください。必須条件、範囲外、未確認の技術前提、外部依存、運用・セキュリティ、承認者、再確認条件が読めれば、技術確認を始められます。読めない欄が、受注前に営業と開発が埋めるべき次の問いです。