なぜコードではなく「思考プロセス」を残すのか？ Salesforce FDEが実践するSlack活用術

ニューヨークを拠点に Forward Deployed Engineer（FDE）として活躍する深田紘平氏。卓越した開発スピードとチーム連携を支えるのは、独自の Slack 活用法にありました。本記事では、AI エージェント開発の裏側と、思考プロセスを資産化する Slack の実践術に迫ります。

コーディングエージェントでバグの原因がわかっても、そのバグが起こる設計上の理由や他のケース・対応策はSlackにある。Slackを作業ログにしています
SalesforceForward Deployed Engineer深田紘平氏

Forward Deployed Engineer(FDE)という仕事とSlack

FDEとは、顧客の現場に深く入り込み、課題のヒアリングから AI エージェントの構築までを完結させる顧客起点のエンジニアリングです。

特にコンサプションモデル（従量課金）においては、最初のユースケースを成功させることが極めて重要です。この成功体験が次のユースケースを生むエンジンとなり、Salesforce が顧客企業のビジネス基盤として深く根を下ろすきっかけとなります。

汎用機能を開発する一般的なソフトウェアエンジニアとは異なり、現場ごとの個別の業務フローに寄り添い、「理想」と「現実」のギャップを埋める核心的な役割を担います。

実際の具体的な業務内容は、別途公開予定のSaleforce ブログで詳しく紹介しています。本記事では、FDE の実践的な働き方を支える「Slack 活用」に焦点を当てます。

AI開発の猛烈なスピードの中で、消えていく「思考プロセス」を守る

グローバルチームが 24 時間体制で開発とテストを回す大型 AI エージェントプロジェクトでは、成果物であるコードそのもの以上に「なぜそのアプローチを選んだのか」という思考の文脈（コンテキスト）が重要になります。バグの原因追究、ナレッジの継承、顧客との密な議論。これらすべての文脈を一元化し、チーム開発を駆動する基盤として Slack が機能しています。

Slackという業務プラットフォームとFDEの仕事の相性の良さ

FDE の真価は、エージェントの業務フローにおいて「問題をどう定義し、AI の出力をどこまで信頼し、いかにチューニングするか」という意思決定の積み重ねにあります。

プロジェクトの開発作業の8割を占めるのは、順調なシナリオ（Happy Path）に加え、無数の例外処理やエッジケースなどエージェントの振る舞いのテストと評価です。

毎回推論プロセスが変わるエージェントの挙動に対して、それぞれのFDEが開発やテスト過程でそれをどう評価するか、そのビジネスインパクトは何かを見極めながら下すこれらの判断ログを、オープンチャンネルへリアルタイムに残せることこそが Slack の強みであり、FDE の働き方と抜群の親和性を誇ります。

鍵となるのは、評価条件をあらかじめ定義して進める「評価駆動型開発（Eval-Driven Development）」や「テスト駆動型開発（Test-Driven Development）」の視点です。

FDE がエージェントの挙動を評価するのに必要な項目を事前に定義し、それをクリアするまでエージェントを調整していきます。その試行錯誤のプロセスが Slack に刻まれることで、後から参画したメンバーも即座にエージェントのロジックやコードの文脈を把握できます。蓄積された知見は、別のバグ解析や新たなアウトプット創出の確固たるベースとなります。

また、開発やバグ修正の局面では Slack ハドルが威力を発揮します。日常的に5分程度の短時間ハドルを開いてスピーディーに議論を交わし、そこで話された内容や決定背景を文字起こしして AI に読み込ませます。AI が生成した解決策を即座にプロジェクトへ反映させることで、ハドルでの会話そのものを開発の直接的な「素材」として組み込んでいるのです。

「手動では100%成功するのに、100件まとめて自動実行すると成功率が約37%に落ち、半数以上は担当者への引き継ぎが発生してしまう」という不可解な挙動を、チームがスレッドで追っている場面。原因を推測し合い、セッションIDをたどって傾向を検証。添付画像には、エージェントが誤って「技術的な問題が発生しました。担当者におつなぎします」と応答したやり取りが残っています（コードだけでは分からない「なぜその挙動になったのか」の文脈が蓄積されている様子）。

「できたコード(アウトプット)だけを見てもわからない。同じコンテキストを使って、違うバグにアプローチしたり、違うアウトプットを作ったりできる」

— Kohei Fukada

バグ解析の「知見バンク」としてのSlackbot活用

FDE チームの日常には、洗練された作業フローが根付いています。QA エンジニアから届くテストレポートとセッションのログをコーディングエージェント（Codex/Claude Code）で分析して問題を把握した上で、他のチャンネルで議論されている他の FDE の回避策やベストプラクティス、プロダクトの制約といったリアルな知見を Slackbot 経由で検索して問いかけます。

「エージェントの回答に出典が表示されない」という不具合について、「他プロジェクトで同様の事例に当たった人はいないか」とチームに問いかけ、Slackbotがワークスペースを横断検索。過去に別チームで起きた類似事例を、根本原因・回避策・関連スレッドつきで複数返答しています（＝Slackを“知見バンク”として検索・再利用している様子）。

「コーディングエージェントでバグの原因がわかっても、そのバグが起こる設計上の理由や他のケース・対応策はSlackにある。Slackを作業ログにしています」

— Kohei Fukada

顧客との密なコミュニケーションの場としてのSlack Connect

顧客の基幹システムに深く切り込む FDE にとって、密な関係構築とアジャイルな連携は欠かせません。チームは Slack Connect を通じて顧客から直接要件や生の声を吸い上げ、コーディングエージェントなどの AI ツールへ投入して迅速にコードへ反映します。

検証作業は自社の Salesforce 環境ですぐに実行され、顧客と Salesforce 双方のワークスペースを往来しながら Slack Connect 上で対話を重ねます。このシームレスなやり取りが、巨大プロジェクトを爆速で推進するエンジンとなっています。

お客様と直接つながった共有チャネルでの会話。画面下部には「社外メンバーが参加していることを表すバナーが表示され、お客様と同じ場でやり取りしていることが分かる。「4スプリントで全47要件を達成し、バージョン1.0に到達した」とデモ動画つきで報告している（＝顧客と同じ場で進捗や成果物をリアルタイム共有している様子）。

開発の「フルコンテキスト」をチームに橋渡しするSlackと3rd Appの連携

サンフランシスコ、ニューヨーク、インド——時差を活用して 24 時間体制で開発を進めるグローバルチームにおいて、引き継ぎの精度はプロジェクトの命運を分けます。FDE チームでは、コーディングエージェントなどの AI ツールで進めた作業のアップデートを、MCPなどを介して直接 Slack へ送信し、自身の活動ログとして即座に同期させています。

各メッセージ末尾に「MCP連携で送信」と表示され、コーディングエージェントで進めた検討内容が自動で記録されている。単なる完了報告ではなく、判定フラグの設計意図や検証シナリオ、見つかった不具合の発生メカニズムまで、判断の根拠を含めて残されている（＝思考プロセスごと次のチームへ引き継げる活動ログの様子）。

単なる作業完了の報告にとどまらず、思考の過程や判断根拠を含めた「フルコンテキスト」を次のタイムゾーンのチームへ完璧に手渡すことができます。国境や時差を越えても、エンジニアリングの思考プロセスそのものがチーム共通の資産として蓄積され続けています。

さらに、1つの AI エージェントに対して複数のユースケースを並行開発する環境では、ファイルのバッティングや上書きを防ぐための緻密なチーム連携が不可欠です。あるチームが作業を終えると、更新内容やステータスを次のチームへ確実に引き継ぎます。重要なタイミングで即座に対応できるよう、メンバーは Slack を常時オンにしてスタンバイし、必要に応じて迅速に割り込む「クイックイン・クイックアウト」の敏捷性を保っています。