1 年ほど前、私は、この用語を生み出した会社で 10 年にわたってフォワードデプロイメントに携わってきた人と、1 時間ほど電話で話しました。この 1 年間、私はさまざまな形で、フォワードデプロイメントエンジンを構築している人々と協力してきました。今でも、フォワードデプロイメントに含まれるすべての要素を適切に説明できるコンテンツはないと感じています。
友人と話したとき、私は、あの有名なディスカバリープロセスが実際にどのように機能するのかを尋ねました。その答えは、少なくとも表面的に見ただけでは、ほとんど恥ずかしいほど物理的なものでした。飛行機で現地に飛び、問題に関わる全員と会うのに 2 日間を費やします。ERP マネージャーからは発注書に関する理論の講義を受けます。その後、工場の現場に連れて行かれ、理論だけでは見落とされている部分を実際に自分の目で確認します。そして、データを結線しながら、3 週間にわたって毎日 1 つの質問を彼らに投げかけます。私は「公式のようなものはあるのか」と尋ねました。彼は「公式は、知っている人々とできるだけ多くの時間を過ごすことだ」と言いました。10 年経っても、その部分は決して変わっていません。
しかし、より深く掘り下げなければ、これは誤解を招く可能性があります。確かに、彼らは顧客と多くの時間を過ごします。しかし、優れたフォワードデプロイメントエンジンは、事前にモデルを構築します。優秀なデプロイメントエンジニアやデプロイメントストラテジストは、自分たちがすべてを理解できるわけではないことを認識していますが、物事を構築し、顧客とともに反復していくことが非常に早いです。最初のワークフローが当面の目標です。オントロジーは、そのツールを徐々にオペレーティングシステムに拡張する方法として使用されます。優れたフォワードデプロイメントエンジンが輝くのは、コンテキストの多くがチーム、つまり Subject Matter Experts（SME）からもたらされ、彼らがそれらを、顧客と初めて会う前の段階で、ある程度までつなぎ合わせるという事実にあります。この部分は時間の経過とともに改善されており、一部のエンジンが複合的に成長し、他のエンジンがそうでない理由の真の理由です。
私はすぐに 2 つの考えを抱きました。優れたフォワードデプロイメントが何であるかに注意を払っていないのであれば、あなたもおそらく同じ考えを持つでしょう。ぜひ読み進めてください。
最初の考えは、顧客のワークフローについてまったく知識がない場合はどうなるのか、ということでした。多くのインタビューから始めることになるのでしょうか？ 友人は「ノー」と言いました。なぜなら、誰もインタビューされるのを好まないからです。しかし、彼はある話をしてくれました。彼のチームはかつて、ある物流会社向けにルーティングエンジンを構築しました。そこでは、ディスパッチャーが手作業による判断と、地図、距離、埋立地の場所、その他の運用上の制約に基づいて、ドライバーやルートに毎日のチケットを割り当てていました。友人はディスパッチャーに推奨事項を提供するツールを構築しましたが、最初の問題は、ディスパッチャーが直感に基づいて推奨を拒否することが多く、その理由を明確に説明できなかったことです。これに対処するために、彼のチームは考えられるすべての割り当ての組み合わせを表面化し、その可視性を利用して、人間の意思決定をシミュレーション結果と比較しました。誰かがすべての組み合わせを画面上にマッピングしたのはこれが初めてであり、したがって、人々が直感に基づいて行っている意思決定が、大規模なデータによって裏付けられているかどうかを振り返る機会を得たのもこれが初めてでした。これにより、物流会社のチームはワークフロー自体を監査し、プロセスロジックが実際に正しいかどうかを理解し、ビジネスが実際にどのように運営されているかをより適切に反映するようにデジタルツインを改良することができました。彼らはまた、このプロセスを楽しみました。なぜなら、それは決してインタビューのように感じられることはなく、代わりに、初めてパズルのすべてのピースを 1 つのボード上で見ることができるようになったからです。
次の考えは、エージェントの追加によって、数年前と比較して、今日のプロセス全体がどのように変化するのか、ということでした。 友人がくれた答えは、それは単に、エージェントを使用することで、より速く開発でき、暗黙知のレイヤーでより多くのコンテキストを得られることを意味するが、それはパズルの一部にすぎないというものでした。彼は、これらのパイロットに関して、彼らの FDE モデルにおける魔法のソースは、アインシュタイン級のものではないと言いました。場合によっては、今でもパイロットを行っている間、彼らは単にステップと結果を聞き、動詞をマッピングし、顧客に専任のエンジニアとして 5 人のチームを提供しているだけです。これらのエンジニアはすべてをコード化し、その後、彼らは姿を消し、顧客はソリューションを使い続けることができます。エージェントは、顧客のシステム全体からより多くのコンテキストや暗黙知を取り込むことを容易にすることで、コード化プロセスを加速および深化させるという点で確かに役立ちます。エージェントは、直接的なユーザーフィードバックを超えて、履歴や運用上のコンテキスト、つまり、メール、営業プロセスの変更、Salesforce などのシステムでのステータス変更、そして組織が時間の経過とともにどのように機能してきたかのその他の痕跡を取り込む方法になりつつあります。これにより、顧客のワークフローをより豊かにモデル化し、断片化された知識ソースを接続し、ビジネスをデジタルツインで表現するだけでなく、現在人間が手動で行っている意思決定の自動化や支援を支援するシステムを構築することが容易になります。
彼との通話の文字起こしから、いくつかの段落を紹介します。
*それで、私たちの始め方は、常に「価値へのスピード」に焦点を当てることです。常に手順的なアプローチ、つまり「よし、オントロジーを作ろう。次に、その上にアプリケーションを作ろう。それからユーザーに届けよう」というわけではありません。いいえ。ある側面ではそれに従いますが、他の側面では、単に顧客に「私たちがあなたのために構築できる最大の付加価値は何ですか？あるいは、今すぐあなたに提供できる最大のインパクトは何ですか？」と尋ねます。「あなたのビジネスにおける問題と、あなたが私たちが解決できると思う問題を説明してください。」
*顧客が共有したら、私たちは設計図に戻り、「よし、オントロジーのバージョン 1 を切り出して、アプリケーションのバージョン 1 も 1 週間以内に構築して、テストしてみよう」と言います。これは、まるでスタートアップを立ち上げるようなものです。多くの場合、顧客がユースケースのアイデアを思いつくかもしれませんが、話しているうちに、私たちはまったく別の潜在的なユースケースを発見し、それを解決できることに気づきます。そして、たとえ顧客が別の何かを必要としていると思っていても、私たちはそれを構築します。結局のところ、私たちは彼らが解決を必要としている最大の問題に合わせようとします。
*私たちはそのために何かを迅速に構築し、オントロジーに関しては 5 つのオブジェクトを構築します。たとえば、ERP システムに関連することを行っている場合、それは非常に複雑になる可能性があり、統合を完了した後でも、その ERP の専門家に、週に数回、1 時間のジャムセッション形式のものや、30 分のアドホックミーティングを依頼します。そして、そこで私たちの価値を証明したら、2 番目、3 番目、4 番目のユースケースを探し、最終的には彼らの会社全体のエンタープライズ OS のようなものを構築できるようにします。
*私たちは通常、これをオンサイトの形で行います。飛んで行き、「2 日間ください」と言います。関係者全員と、一緒に会えるか、1 対 1 で会います。多くの場合、人々が忙しいときは、彼らの隣に座って、彼らの営業プロセスやクライアントとのやり取りを理解しようとします。彼らの視点から何が起こっているのかを理解しようとし、顧客と過ごす時間を短縮しようとはしません。実際、私たちはそれにさらに傾倒し続けており、それは 10 年間変わっていないことです。時には、クライアントと丸々 1 週間を過ごすことさえあります。ディスカバリーに関して、私たちは決してそこから逃れようとしたり、プラットフォームを完全に自動化しようとしたりしたことはありません。
議論の中心的なアイデアは、コード化は重厚なドキュメントではなく、反復を通じて行われるということでした。チームは、データ統合、運用コンテキスト、Subject Matter Expert のインプットを使用して、組織が実際にどのように機能しているかを表す、会社の「デジタルツイン」をコードで直接構築します。しかし、そのデータモデルだけでは十分ではありません。より困難で価値のあるレイヤーは、ビジネスロジック、つまり、介入が重要となる場所、どのようなアクションを推奨すべきか、経験豊富なオペレーターが実際にどのように意思決定を行うかについての理解です。これらすべては、単に情報を表面化するだけでなく、ユーザーがトレードオフを評価し、ワークフローを検証し、最終的には意思決定支援を製品自体に組み込むことを支援します。
会話の残りの部分では、この作業が、最初から深いドメインの専門家が組み込まれていることに依存しない方法について、さらに深く掘り下げました。期待されるのは、フォワードデプロイされたエンジニアが、不慣れな環境に入り、素早く学習し、有用なシステムを迅速に構築することで信頼性を築くことができることです。初期のエンゲージメントは、多くの場合、事前に構築されたプロトタイプとサンプルデータによってサポートされた短いブートキャンプから始まり、迅速に価値を実証し、より深いデプロイメントの権利を獲得するように設計されています。そこから、関係は単一のユースケースから顧客のためのより広範なオペレーティングシステムへと拡大し、長期的な目標は、チームが最終的に後退してもクライアントがソリューションを使い続けられるように、ワークフローを効果的にコード化することです。
これは、現在構築中の新しいベンチャーにとって非常に重要なプレイブックです。これがフォワードデプロイメントです。それ以外はすべて、おそらく飾りに過ぎません。
複利の法則
フォワードデプロイメントは、コストがかかり、粗利益に現れるのが遅く、きれいな計画を立てるのが難しいものです。創業者はこれを感じ、「努力に見合う成果が出ているのか」と問い始めます。やがて、あるリーダーが「私たちは 2 倍の努力をして 2 倍の結果を得ている」と声に出して言います。
この文は、特定の業界にとって、フォワードデプロイメントが正しいモデルではないことを示唆している場合、危険信号です。私自身もかつて創業者だったので、創業者の焦りは理解できますが、素朴さと焦りは紙一重です。フォワードデプロイメントエンジンとうまく機能するビジネスにとって、この計算を掛け算で行う人は、仕事を理解していません。もし 2 倍の努力が 2 倍の結果を買うのであれば、あなたはコンサルタントを雇って、彼らをエンジニアと偽っているだけです。あなたは収益と完全に連動して人員を増やし続け、マージンは決して改善せず、あなたが構築したものの正直な名前は、コードを出荷するかサポートを提供する人材派遣会社です。自分が何を構築しているのかを明確にしていない人は、ほとんどの場合、平凡な結果に終わり、この特定の混乱はあなたに不利に働きます。
フォワードデプロイメントは、計算が曲がった場合にのみ意味を成します。最初のデプロイメントは、見苦しく、手作りで、経済的に非合理であることが許されます。その仕事は教えることです。2 番目のデプロイメントは、最初のデプロイメントがテンプレート、統合、文書化されたパターン、プラットフォームの一部を残すため、より安価でなければなりません。10 番目のデプロイメントまでには、最初のチームが手作業で行ったことのほとんどは設定を通じて行われるべきであり、人間は 1 レベル上の、1 年前には顧客の目から見ても存在しなかった問題を解決しているべきです。1 ヶ月目と n ヶ月目のこれら 2 つの数値の間の距離は複利であり、その曲線が、フォワードデプロイされたチームに資金を提供するときに実際に購入しているものです。複利がすべてのポイントです。複利にならないエンジンなしで、自分自身をフォワードデプロイと呼ぶことは、単に愚かなことです。
ソフトウェアエンジニアとフォワードデプロイエンジニアの主な違いは、SWE がコードを書くことに費やす時間の量です。つまり、メンテナンス、サポート、またはロードマップに沿った機能の構築に費やす時間と、FDE がロードマップにないことが多いが顧客価値を引き出し、それをデプロイし、パターンが顧客全体で繰り返され始めたら製品に引き継ぐ、発見作業に費やす時間の違いです。
誰もが使うが、ほとんど誰も意味していない言葉
このアイデアには特定の起源があります。20 年前、ある創業者が「なぜ素晴らしいフランス料理のレストランは素晴らしいのか」と尋ね、ウェイターに行き着きました。素晴らしいレストランでは、ウェイターはキッチンの一部であるため、何かを推薦するとき、それはキッチンが話していることになります。Palantir はそのエンジニアリング版を構築し、その役割に軍事的な名前を付けました。なぜなら、その顧客は軍隊だったからです。その名前は、フィールドワークに当然の地位を与え、それは正しかったのです。その報酬は非常に高かったため、20 年後には誰もがその名前を欲しがりますが、どれだけの人がその仕事を理解しているかはわかりません。
ある意味で、フォワードデプロイされたチームは、創業者が 0 から 1 のフェーズで行わなければならないことを行わなければなりません。あなたは、出荷できるもの、つまり、虚栄の指標を持ち上げるだけでなく、顧客が本当にビジネスを成長させるのに役立つものを、しばしば発見しています。これは、友人の会話からのもう 1 つの実際の例です。彼のチームは、生産量を約 10 倍に増やしたいと考えていた EV 充電器メーカーに雇われました。それがブリーフでした。結果が戦略デッキではなかったことは確かですが、推測できますか？会社の目標は表面上は単純でした。EV 充電器の出力を 10 倍に増やすこと。フォワードデプロイされたチームが実際に行ったことは、現場に赴き、ビジネスの複数のレイヤーから業務を学ぶことでした。彼らは ERP の責任者と時間を過ごし、記録システム、発注書、作業指示書、供給、需要を理解しました。その後、工場の現場に行き、実際に生産がどのように行われているかを確認しました。同時に、経営陣と話し、問題の戦略的バージョンを理解しました。なぜなら、現場のオペレーターが間違っている、または緊急であると言うことが、リーダーシップが最も重要な制約と見なしているものと常に完全に一致するとは限らないからです。その後、作業は、少なくとも会議で言われたことからすると、新しい生産ラインを直接構築することではありませんでした。それは、業務のデジタルツインを構築し、ソフトウェアがワークフローに介入できる場所を特定することでした。例えば、重要な部品の不足、発注書のタイミング、安全在庫、その他の運用上の決定などの問題です。説明された結果は、製造自体への物理的な変更ではなく、リスクを早期に表面化し、アクションを推奨できるシステムでした。これで、私が「元創業者は卓越したフォワードデプロイメント担当者になり得る」と言うときの意味が理解していただけたと思います。
今日の職務経験（説明ではなく）を調べてみると、顧客のシステム内で本番コードを書き、稼働後のサポートを含む責任を負うエンジニアが見つかります。残りは、より良い名刺を持ち、デモで評価されるセールスエンジニアと、その言葉が流行っているため借りてきた内部自動化の役割です。フォワードデプロイメントが何であるかについての隣接する混乱はさらに悪化しています。100 のドメインインタビューを通じてエキスパートネットワークを運用することは研究ですが、それはフォワードデプロイメントではありません。プライベートエクイティが企業を買収し、変革チームを送り込む場合、それは有用で、時には素晴らしいですが、必ずしもフォワードデプロイメントではありません。なぜなら、これらの 2 つの動きのどちらにも、私が「ワーククロージャー」と呼ぶものを所有している人はいないからです。
ワーククロージャーは、この分野全体が評価される単位です。出荷された機能や、解決されたチケットではありません。顧客の仕事の一部であり、懸念事項から、誰ももう考えなくなるものまで、ずっと運ばれます。契約書への署名は、ここで混同される職業の境界線です。セールスエンジニアは、その境界線まで働きます。フォワードデプロイされたチームは、その境界線から始まります。なぜなら、何かが機能するべきであると同意することは、それが機能することと同じではないからです。その人がノルマを負っているなら、あなたは営業を見ています。その人がローンチの 3 ヶ月後もまだ顧客のログに残っているなら、あなたはフォワードデプロイメントを見ています。マーケティング製品を販売する会社は、契約を成立させ、デプロイして設定するためにセールスエンジニアを派遣します。真の FDE は、製品がサポートするワークフローのどれも問題の顧客に役立たず、まったく新しいものがトップラインまたはボトムラインに直接影響を与えるという結論に達し、その後、そのワークフローを構築するかもしれません。これには、Mom's Test（本を読んでください）の専門家であること、顧客はあなたの機能ではなく、どのようにビジネスを改善するかに関心があることを理解していること、あなたの製品が何ができるかを理解し、高速で出荷して、顧客と実際のワークフローで反復できることが必要です。
そこで、私が壁に掲げたい定義を以下に示します。フォワードデプロイメントとは、あなたが出荷したものと顧客が必要としたものとの間の距離に立ち、あなた自身の手で、彼らの世界の中で、その距離を縮め、次回はあなたの製品が単独でそれを縮めることを教える方法で行うことです。
その文の後半で、ほとんどすべての人が失敗します。
なぜこれが突然どこにでもあるのか
70 年間、ソフトウェアは人々が仕事をするのを助けてきました。今、ソフトウェアは仕事をし始めています。それは、隠れた前提を覆します。ツールはゆっくりと採用される余裕があります。労働者はそうはいきません。成果を売る瞬間、誰かが、あなたのデモ環境とはまったく異なる動作をする会社の中で、その成果を実現させなければなりません。
モデルは、ここ 2 年のどこかで制約ではなくなりました。デプロイメントが制約になりました。エンタープライズ AI パイロットに関する最も引用される研究では、約 20 件中 19 件が測定可能な P&L インパクトを生み出さず、その死因分析はほとんどがモデルの品質ではありません。それは、ワークフローを決して学習しなかったソフトウェアです。文書化されたプロセスには 4 つのステップがあります。実際のものには 9 つあり、欠けている 5 つは、ある女性の記憶、彼女が何年も前に構築した個人用トラッカー、そして彼女が別の建物にいる別の女性と取引している好意の中にあります。古い業界では、仕事はあなたのエンジニアが生まれる前にインストールされたシステムを通じて実行され、その端はファックスや電話でつなぎ合わされています。そのどれにも API はありません。油田では、誰かが耳をリグに当てて、その音が心配すべきことを示しているかどうかを評価します。インドから米国にイカを輸送する船では、ロンドンに停泊し、運賃と価格は、勘、限られた気象データ、そして視覚的に見える在庫の品質に基づいて決定されます。暗黙知はすべての企業の荷重支持層であり、誰もそれ用の SDK を出荷したことはありません。過去 10 年間の産業用プラットフォームの墓場は、この教訓を数十億ドルかけて教えました。変革はアーキテクチャで死ぬのではありません。採用で死ぬのです。
資金はそれに気づきました。Microsoft は、25 億ドルと 6000 人を投入して、専門家を顧客に埋め込むことを約束しました。AWS は、その数週間前に同じアイデアに 10 億ドルを投入しました。OpenAI と Anthropic はそれぞれ、世界最大の投資家の一部を擁する専用のデプロイメント会社を立ち上げました。これを流行と呼ぶこともできます。この規模の資本が衣装であることはめったにありません。研究所は自社のパイプラインを価格設定し、買い手が知能に不足していることは決してないことを発見しました。買い手が不足していたのは「人手」でした。失敗はラストマイルにあり、ラストマイルこそが堀が掘られる場所です。LLM に関する積極的な研究に 10 年かかって、現在の状態に至りました。これらのモデルにワークフローと人間の意思決定フレームワークの理解を持たせるためには、さらに多くの時間がかかるかもしれません。
なぜそのチームにビジネスパーソンが必要なのか
エンジニアが存在するのは、ギャップがコードで埋められるからです。顧客のインフラ上で、顧客のエッジケースに対して、通常は数日以内に。ユーザーが朝に説明したことが、数日以内に、四半期ではなく、彼らの前で実行されているべきです。そのスピードが、3 年計画の変革プログラムがスライドライブラリを生み出すのを見てきた人々との信頼構築の方法です。
ビジネスパーソンが存在するのは、デプロイメントにおける最も困難な問題は技術的なものではなく、そうでないふりをすることが技術チームの失敗の方法だからです。誰かが、誰も自動化する前に、実際の仕事が何であるかを突き止めなければなりません。誰かが、20 のエスカレーションのうちどれが重要か、誰のワークフローが本当のボトルネックか、どの役員の沈黙が採用を殺すか、そしてどの成果がエンゲージメント全体を正当化するかを決定しなければなりません。誰かが、顧客がいつひるんでいるのか、いつ礼儀として何かを言っているのかを読むのが得意でなければなりません。誰かが、エンタープライズ AI における最もデリケートなインターフェース、つまり、今日の製品ができることと、6 ヶ月後には避けられないとあなたが売り込んだこととの間のインターフェースを実行しなければなりません。私は、デプロイメントストラテジストを会社のフューチャーズデスクと考えています。彼らは、製品が何になるかを、関係が耐えられる価格で販売し、そのポジションが決してデフォルトしないようにします。高額な取引はそのデスクで勝ち取られ、それなしでは吹き飛ばされます。
障害モードは、どの役割が欠けているかを教えてくれます。製品が顧客の世界で動作しないために取引が停滞する、または製品が製品内部にのみ存在するワークフローしかサポートしないシナリオは、エンジニアが不足していることを意味します。エンジニアが要求された機能を出荷して忙しくしているが、収益がそれほど伸びていない、または FDE が 100 回以上の電話をかけたが、契約収益が実現収益よりもまだ一桁大きい、またはシステムを改善しないカスタムワークフローのサイロが存在するシナリオは、ストラテジストが不足していることを意味します。
最高のチームでは、2 つの役割は曖昧になり、その曖昧さこそがポイントです。エンジニアはビジネス本能を身につけ、ストラテジストはスキーマを読むことを学び、あなたが得るものは、会社が雇える創業者に最も近いものです。フォワードデプロイメントは、すべての創業者が組織図がそれを隠すまで何年も行うことです。顧客の混乱の中に座り、手元にあるもので仕事を閉じ、学んだことを製品に反映させることです。この役割は、他人のキャップテーブルでの創業者の 1 週間のようなものです。また、これらのチームがビッグテックを恥じ入らせる割合で創業者を生み出す理由でもあります。もしあなたが FDE ポッドを運営しているなら、初日から後継者計画を立てて備えるべきです。なぜなら、10 年後に構築する創業者は、おそらく全員が過去生で FDE だった可能性が高いからです。それは今日展開されています。
実際に持っているかどうかを知る方法
フォワードデプロイされたチームをスナップショットで判断することはできません。なぜなら、どんな日でも、優れたチームと偽物のチームは同じように見えるからです。賢い人々が顧客に飛び、英雄的な働きをします。5 つのチェックでそれを明らかにできます。
#1 顧客あたりの労力。 昨年 5 社の顧客にサービスを提供し、今年も 5 社にサービスを提供しているチームは、何も複利にしていません。現在 15 社にサービスを提供しているチームは、現場で学んだことを吸収する製品を育てています。顧客が増えるごとに、社内では Subject Matter Expert を育成する必要があります。
#2 仕事の新規性。 4 番目のデプロイメントが 3 番目を繰り返している場合、誰も現場からプラットフォームへのパイプを所有していません。誰かがアカウント間での繰り返しを探すために給料を支払われなければなりません。なぜなら、繰り返しは、ロードマップが自らを書き換えているからです。
#3 セグメント内での 2 番目のデプロイメントの形状。 10 番目の顧客にかかるコストが 1 番目の顧客と同じである場合、あなたは製品をスケーリングしているのではなく、プロジェクトをフランチャイズ化しています。
#4 報告ライン。 製品またはエンジニアリング内では、ループを閉じることができます。営業やサービスのサイロ内では、学習は誰も読まない出張報告書に残され、チームは静かにマージンになります。
#5 顧客自身のスコアボード。 活動は見せかけです。使用状況の数値は、下流で何も改善されていないにもかかわらず、見事に見えることがあります。CFO との接触に耐える唯一の測定基準は、顧客が作成を支援した評価であり、その評価は、顧客のデータに関する顧客の成果に対して作業を採点し、第 1 週に構築され、公開で追跡されます。その横に 1 つの人間的なテストを置いてください。あなたの製品とはまったく関係のない、彼らのビジネスで何かが壊れたとき、あなたが最初の電話先ですか？ これまでに構築されたすべてのダッシュボードは、その電話を近似する試みです。
そして、ダークパターンに注意してください。それは今、どこにでもあります。一部の企業では、フォワードデプロイされたチームは学習エンジンではなく、隠蔽者です。製品がうまく機能しないため、すべてのギャップに人間が配置されます。人間が英雄的であるため、ギャップは決してロードマップに到達しません。ギャップが決してロードマップに到達しないため、製品は決して改善されず、人間は決して離れることができません。現場が製品を吸収し続けるため、製品はプレッシャーを感じません。現場は、アカウントを救うのに忙しすぎて、何も書き留めません。顧客が実際にサービスを受けているため、請求書は届き続けます。機械はバランスが取れており、そのバランスこそが問題です。企業は何年もその中に住み、顧客とまったく同じ速さでフィールドの人員を増やし、それをフォワードデプロイメントと呼びます。それは違います。それは、毎月請求される、製品の不在です。また、これらの地位にある多くの才能ある人々が、自分は失敗していると感じる理由でもあります。彼らは複利にするために雇われたが、隠蔽するために配置されました。
各段階での様子
Translated text (Japanese (日本語) only, no explanations):
初期段階では、まだ人を雇ってはいけません。自らがその役割を担いましょう。創業者自身が前線に立つチームです。乏しい理解を他人に委ねるのは、最も避けるべきことです。2日間の出張は自分で行き、ディスパッチャーの隣に座ってください。そして、ようやく人を雇う時が来たら、仕事を完了させるスピードを上げてくれる人を選びましょう。決して、あなたと顧客の間に立つ人を雇ってはいけません。
成長段階では、前線展開は誤解されがちです。外から見ると、スピードが落ちているように映るからです。ボードメンバーは、エンジニアが数週間も特定の顧客先に張り付き、その間にも競合他社が毎週のように新機能を発表するのを見ています。会計処理も事態を悪化させます。前線展開は、その活動がR&Dのように振る舞うにもかかわらず、売上原価として計上されます。つまり、学べば学ぶほど、財務状況は悪化して見えるのです。しかし、どちらの立場も真実として受け止め、どちらかに嘘をついてはいけません。会計帳簿上はコストですが、戦略上は研究です。この矛盾を解決するのは、物語ではなく、研究に確実に成果を生み出させるためのガードレールです。すべての案件に時間制限を設け、それぞれを単一の明確なビジネス成果に結び付けます。四半期ごとに収穫を行います。つまり、現場で手作業で構築したものを、四半期ごとにプラットフォームが自動で処理できるようにするのです。「後でプロダクト化しよう」という言葉は、この段階で会社を潰す原因になります。なぜなら、「後で」には責任の主体がないからです。
規模が拡大すると、問題は様変わりします。数百もの顧客から数百万ドルの収益を得るようになり、ソリューションコンサルタント、導入チーム、マネージドサービス、アカウントエグゼクティブ、カスタマーサクセスといった組織も既に存在します。この段階のリーダーは、前線展開チームをどこに配置すべきか本当に分からなくなり、結局は第4のサポート窓口的な位置づけとして付け加えられ、チケットの山に埋もれて消えていきます。答えはこうです。既存のすべての機能にはプレイブック（行動規範）があり、前線展開チームはプレイブックが存在しない領域にのみ存在します。最も野心的な10のアカウント、新しい垂直市場、業界全体が「自動化は不可能だ」と言いながらも、自社だけは独自に自動化できると確信しているワークフロー。これらが対象です。前線展開チームはプロダクト部門に所属し、自らの仕事を不要にすることを使命とし、解決したパターンをすべてプレイブックを運用するチームに引き継ぎます。これこそが、プレイブックを生きた状態に保つ方法です。Uber の事例は参考になります。Uber は、AI に精通したエンジニアと、財務、法務、サポートの各部門のドメインエキスパートをペアにし、各ペアに2週間の猶予を与え、プレゼンテーションではなく、ワークフローの所有者の隣で実際に構築することを求めました。2日間のシャドウイング、1日間の目標選定、10日目には実際に動く状態に。16のチームが2ヶ月で16の機能を再構築し、2日かかっていたレポートが10分で完了するようになりました。自動化の単位は、決してタスクではありません。ワークフローこそがその単位であり、ワークフローは、その中に身を置く者にのみ姿を現します。
同じ仕事でも、業界によって装いが異なる
防衛・政府系では、その存在自体がプロダクトです。セキュリティクリアランス、ネットワーク非接続環境、ラップトップを持ち出せない部屋などが求められます。医療業界では、仕事はワークフローの発掘です。実際のプロセスは、20年前のシステム上で動いており、FAXや電話連絡網が今なお例外処理を担い、施設ごとに異なる不文律のバリエーションが存在します。標準的なものが存在すると想定したチームは、1年を無駄にします。金融サービス業界では、顧客はコンプライアンスに準拠した判断力を購入しており、成果物は規制当局が読める評価書であることが多く、最大の懸念はデータ漏洩ではなく、判断力の漏洩、つまり、自社の優秀な人材の意思決定パターンが他社のモデルに取り込まれることです。製造・物流業界では、真実は現場にあり、制約は物理的なものです。そのため、発見はビデオ会議では不可能であり、システムは古く、視覚的に複雑で、クラウドから切り離されていることがよくあります。消費者向けビジネスでは、フィードバックループは四半期ではなく日単位で回り、不足しているスキルは「センス」、つまりブランドのトーンを理解し、機械がいつ話すのを止めるべきかを知ることです。そして、最新の領域は自社です。同じチームを、自社の財務、法務、サポート部門に投入します。AI ができることと、組織が実際に行っていることのギャップは、同じであり、ただ建物が違うだけだからです。
地形が戦術を決めます。戦術は交渉の余地がありますが、順序は譲れません。仕事に寄り添い、仕事を完了させ、プロダクトにフィードバックする。これです。
誰が本当にこれに長けているのか
発明者である Palantir は、今でも最も深いバージョンを実行しており、誰もが忘れがちな詳細は、そのモデルがプロダクトよりも前に生まれたということです。最初は設定すべきものなど何もなく、壊れた組織の中に十分長くいれば、プロダクトは自然と姿を現すという確信だけがあったのです。そして、それは現実のものとなりました。現在、同じ会社はより短く、より定型化された案件を実行しています。なぜなら、プロダクトが存在するようになった今、複利の効果を追求することが信条だからです。
新しい世代は、カスタマーサービスエージェント企業に見るのが最も簡単です。Sierra は、現場機能をエージェントエンジニアとして運営しており、そのループは意図的に設計されています。一人の顧客のために問題を解決し、その解決策を社内で広め、成功したものをプラットフォームに格上げして、すべての顧客が継承できるようにする。何十もの導入を通じて、エンジニアが「エージェントがいつ再試行をやめて人間に引き継ぐべきか」を正確に学んだとき、その判断は再利用可能なコンポーネントになりました。そして彼らは、構築自体を行うエージェント Ghostwriter を開発しました。これは、通話記録、SOP、ホワイトボードの写真などを学習し、エージェントが直接操作できるように再設計されたプラットフォーム上で動作します。Sierra への投資は、大部分が、その展開チームが他の誰も見つけられないワークフローを発見し続けるだろうという賭けです。Decagon はシステム面でのアプローチを取り、自社の導入案件を監査して、個別対応する必要のない作業を特定し、各エージェントの背後にあるカスタムエンジニアリングを80%削減しました。そして、公然と核心を語りました。「差別化要因はプロダクトではなく、デリバリーである」と。Ramp は、現場チームに元創業者を多く配置し、最初の問い合わせから長期サポートに至るまで、顧客ライフサイクル全体を担当させます。そして何よりも、構築する前に要件を疑問視する習慣を徹底させます。なぜなら、提示された要求は通常、問題の原因ではなく症状だからです。
一度その形が分かれば、あらゆる本格的な垂直市場でそれを見ることができます。Harvey は、元弁護士を法律事務所に派遣しています。これは、展開される人物が必ずしもエンジニアである必要はなく、責任を負える人物であればよいという証拠です。金融分野では、Rogo は社員の半数近くを元銀行家で構成し、彼らが出身の金融機関に派遣されています。一方、Hebbia はエンジニアを送り込み、世界最大級の資産運用会社内でラストワンマイルを構築しています。Abridge は、病院システムと連携して展開チームを立ち上げています。AI による医療記録作成を12,000人の臨床医に導入するのは、単なるインストール作業ではなく、キャンペーンです。HappyRobot は貨物ブローカーに、Gecko Robotics は Navy の艦船に、Applied Intuition は世界のほとんどの大手自動車メーカーに人材を送り込み、Cursor (SpaceX) は、エンジニアが既に愛用しているツールを銀行や通信会社に導入する前線展開チームを運営しています。
形は異なっても、物理法則は同じです。現場が工場を養うのでなければ、それは前線展開ではありません。
最も強力な反対論、それに耳を傾ける価値があるから
この職業全体が、ある種の言い訳に過ぎないという主張があります。あなたは「自動で料理ができるキッチン」を売り込まれたのに、実際に届いたのは、あなたの家に住み込み、あなたの給料で、ベンダーのマークアップが上乗せされ、しかも退去予定のないシェフだった、という話です。このセールストークを信じるには、二つのことを同時に信じる必要があります。つまり、機械は料理を代替できるほど優秀でありながら、住み込みの監視員を必要とするほど無力でもある、と。プロダクトに人間の常駐が必要なら、そのプロダクトは未完成です。
この批判を真摯に受け止めてください。多くのベンダーにとって、それは単なる事実だからです。種を区別するテストは、この記事が繰り返し述べてきたものと同じです。ギャップにいる人間が恒久的なものなら、批判は正しく、あなたはパッチをレンタルしているに過ぎません。ギャップにいる人間が複利的に機能し、自らの必要性をなくすように仕事を完了させているなら、その批判は2回目の展開で死に絶えます。この批判が見落としているのは、仕事の大部分はプロダクトの仕上げではなかったということです。それは、コンテキスト（状況・文脈）の獲得です。文書化されていない5つのステップ、ディスパッチャーの言葉にできない直感、建物を越えて交換される頼み事。完成したプロダクトがそれらを内包することは決してありません。なぜなら、それらは会社ごとに異なるからです。誰かがそれらを取りに行かなければなりません。重要なのは、彼らが持ち帰るものが、資産として複利で成長するのか、それとも請求書として消え去るのか、ただそれだけです。
この先の行方
すでに4つの変化が起こりつつあります。
コンテキストが資産になる。 展開チームが各顧客先で実際に構築しているのは、その会社がどのように動いているかという実用的なモデルです。オントロジー、デジタルツイン、誰が何をなぜ決定するかの地図。投資家はこれを「カンパニーブレイン」と呼び始めており、その名称は定着しつつあります。なぜなら、すべての会社にいずれ必要になるからです。誰かが飛行機に乗る前に、かなりの部分をブートストラップ（自己充足的）に構築できます。顧客は、サポートチケット、通話記録、メール、エスカレーションスレッドなどで、常に自社の真実を漏らしているからです。そこから始めましょう。しかし、最も深い層、つまり人々が言葉にできない知識には、依然として現場での存在と、内部関係者が自らの直感を論理に変換できるまで監査するためのツール（鏡）が必要です。その地図を保持する者がアカウントを保持します。これは、すべてのCEOがまもなくすべてのAIベンダーに問いかけるであろう疑問を提起します。「私は知能をレンタルしているが、学習したことは誰のものになるのか？」もし共有モデルが市場のすべての融資者の信用判断を吸収した場合、その市場で最も鋭い引受担当者は、自分自身の競合他社を訓練し、その特権に対して対価を支払っていることになります。どのCFOでも実行できるテストがあります。明日、紙の上でモデルベンダーを切り替えてみて、システムに教えたすべてのことがベンダーと共に去っていくかどうかを確認するのです。契約、チーム、そして最終的には企業自体が、一つのラインを中心に再編成されるでしょう。「知能はレンタルするが、学習したことは自社のものにする」と。
エージェントがチームに加わる。 前線展開エージェントは、すでに初期の形で存在しています。統合作業の午後を数分に圧縮するオンボーディングエージェント。自身のトランスクリプトを一晩で読み込み、自身のスキルへの改善案を提案する展開エージェント。これが人間の役割に何をもたらすかを見てください。手動介入はすべて、仕事ではなくなり、訓練シグナルになります。そしてチームの仕事は逆転します。展開を実行することから、展開を実行する工場を運営することへ。スタッフモデルは、マネージャーが人材を配置するように。評価を書くことは、マネージャーがレビューを書くように。より深い逆転は、ユーザーが誰かということです。プロダクトはエージェントが直接操作できるように再構築されており、顧客先での最初の発見質問は、静かに「あなたのチームは何を必要としていますか？」から「あなたのエージェントは何を必要としていますか？」へと変わりつつあります。同じ逆転は収益面でも起こっており、エージェント群を擁する一人の人間が、かつてフロア全体で担当していたパイプラインを運用し、ポストセールスソフトウェアは自らを「ツール」から「成果を所有するサービス」へとブランド変更しています。今日は「リテンション・アズ・ア・サービス」、明日は「エクスパンション・アズ・ア・サービス」です。そして、顧客のエージェントがあなたのエージェントと交渉し始めると、テーブルの両側に残された人間は、ループだけでは完結できない二つのこと、つまり「何を望む価値があるかを決定すること」と「それが実際に起こったことを証明すること」を行うようになります。
コストの下限が下がる。 数年前には500万ドルのエリートエンジニアリングを要した展開が、今では数十万ドルと、優れたエージェントを持つ優秀なジェネラリスト一人で可能になり、その価格はまだ下がり続けています。前線展開は、Fortune 500企業の贅沢品ではなくなり、ミッドマーケット向けソフトウェアの販売方法そのものになります。制約はエンジニアリングの供給から、判断力の供給へと変わります。
役職名が溶けていく。 真面目な企業のエンジニアは皆、部分的に前線展開型になりつつあります。バックエンドエンジニアが顧客電話に同席し、プロダクトエンジニアが通話記録を基に機能をリリースする。まもなく、顧客と向き合う時間の割合が、FDE（前線展開エンジニア）とソフトウェアエンジニアの唯一の違いとなり、役職名はその区別をやめるでしょう。これには、求人情報に決して書かれていない警告が含まれています。この仕事は、ビルダーを外交官に変えます。多くの優秀なエンジニアが、まさに見知らぬ人々で溢れる会議室にエネルギーを消耗されるからこそ、構築することを選んだのです。内向的な人を無理に展開してはいけません。そして、この役割を、エンジニアリングの腕が平凡だったエンジニアを追いやる場所として決して使ってはいけません。全く逆です。何かを創業させてもいいと信頼できる人材を送り込む場所なのです。
会社で最も古い仕事
専門用語を取り除けば、前線展開とは創業者の本来の姿勢であり、成長してそれを忘れてしまった会社の中で生き続けているものです。仕事のある場所に身を置き、仕事を完了させ、学んだことを基に構築するものを変えていく。永続する企業は皆、それに名前がつく前からこれを行っていました。ほとんどの企業は、それを「する余裕」ができた日に、これをやめます。
だから、本当の問題は、前線展開エンジニアを雇うべきかどうかでは決してありません。それは、現実に最も近い人々に真の権力があり、努力がその傾き（成果の伸び率）で評価され、現場で学んだことが決してそこで死なないような会社を、あなたが運営する覚悟があるかどうかです。それを築き上げれば、役職名は後からついてきます。
あなたのチームが最後に、顧客がそのことを考えなくなるほど完全にやり遂げた仕事は何ですか？ 顧客が、あなたのプロダクトスイートから価値を得たからではなく、あなたが彼らのビジネスを成長させるために、彼ら自身も気づかなかったものまで構築してくれると知っているから、更新を決めたのはいつですか？ そこから数え始めてください。
