経営者 × Forward Deployed Business Builder

答えは、市場の選択・営業の実行・業務の仕組みづくりを分けずに1人で持ち、経営者の判断に材料と結果を戻す役割である。

「Forward Deployed」は課題との距離を表す。御社の日々の業務に入り、制約を理解し、決めたことが現場でどう動くかまで関わる。「Business Builder」は担当範囲の広さを表す。何を、誰に、どの販路で売るかを考え、その選択を営業と運用に落とし、反応を判断へ戻す。

市場調査、営業、業務の仕組みが別々の担当に分かれると、顧客の反応が計画に戻らず、承認が経営者の手元で止まる。FDBBはこの間を1人で持つ。経営者が方向を決め、ビルダーが判断材料と実行をつなぐ。

答えは、任せる範囲から考えず、経営者にしか持てない仕事を先に固定し、残りを渡すことである。

外部の責任者に「何を任せるか」から考えると、範囲が決まらない。逆に「経営者にしかできない仕事」を先に定義する。決める（送信・公開・契約・価格の承認）、会う（商談・関係構築）、見極める（相手の質）、引っ張る（交渉）の4つである。当社も自社の運用で、人に残す仕事を先に決め、準備・調査・下書き・集計を渡す順番を取っている。

同じ線を、経営者とFDBBの間に引く。

左列が動くために、右列は「経営者が手を入れなくても使える状態」で納品されなければならない。右列を渡したのに経営者の確認時間が減らないなら、分担は名目だけで、判断材料が経営者の頭の中で作り直されている。分担が機能しているかは、任せた仕事の数ではなく、経営者の確認時間が減ったかで測る。

責任は、その人が実際に動かせる判断と結びついて初めて機能する。ビルダーには、右列に必要な情報へのアクセスと権限を最初に渡す。CRMの閲覧だけ渡して更新は経営者が行う、という形は、転記が経営者に戻るだけである。

答えは、結果を出すことより、次回も同じ品質で出せる手順を残すことである。

役割の説明より、1件の納品の方が伝わる。当社が支援したイベント運営会社（企業名非公開）のスタートアップ支援プログラムでは、応募フォーム3種・472行を突合し、有効応募211件を確定し、CRMを84件更新して、7軸×3フェーズの集計とチャート7点を納品した。工程を「突合」「品質フィルタ」「差分更新」に分けていたため、集計方法を誤ったときの作り直しは集計だけで済み、1〜1.5時間で戻せた。手作業で同じ成果物を作る場合の想定は17〜23時間、実所要は1〜2時間の概算で、削減率は約90%と推定している。この比較は推定で、対照実験ではなく、件数や難しさが違う仕事に同じ削減率を当てはめることはできない。

この事例でビルダー側が担った範囲は、突合ルールの決定、品質フィルタの設計、CRMへの差分反映、集計、そして次回も使える処理手順の整備である。経営者側に残ったのは、除外基準の承認と、集計結果をどう使うかの決定になる。

納品物の中で価値が残るのは、集計結果ではなく手順である。結果は次の応募期間には古くなるが、手順は次回も同じ品質で回る。ビルダーが抜けた後も回る手順が、経営者の手を借りない納品の条件になる。 手順が担当者の頭の中にだけあると、その人が休んだ日に止まり、経営者の確認に戻ってしまう。

答えは、渡す範囲、動かせる権限、完了の判定基準の3つを、着手前に文書で固定することである。

完了の判定は、報告ではなく実物で行う。処理が成功したという応答だけを信じず、保存先の件数と主要な項目を見て完了とする。存在しない選択肢を渡すとエラーにならず無視され、その列だけ空になる、という失敗は、成功応答だけを見ていると見つからない。

用語も最初に揃える。「アウトリーチ」が下書きまでなのか送信までなのか、「リード」が自社への問い合わせなのか顧客業務の候補なのかで、渡す範囲の解釈が変わる。無い用語は推測せず、経営者に確認する、と決めておくだけで、範囲の食い違いは減る。範囲・権限・判定基準の3つは、着手前に決めるほど安く、着手後に決めるほど高くつく。

明日からやることは3つで足りる。経営者に残す仕事を4つ書き出す。それ以外で、いま経営者が手を入れている仕事を一件たどる。その一件について、渡す範囲・権限・完了の判定基準を1枚に書く。営業の下書きと送信の分け方は営業AIの自社検証で、仕組みを業務に定着させる工程はAI導入を業務に定着させる方法で扱っている。