■ 1. FDEに必要なスキル
- 主要な結論:
- クライアントのビジネスを理解すると技術の導入が容易になる
- 有能なFDEは自分の専門外の問題を誰に聞くべきか知っている
- FDEの役割はAIデモから信頼性の高い本番システムへ移行しつつある
- 技術面のスキル:
- Python、SQL、REST API、Docker、LangGraphやn8nなどのエージェントフレームワークが必要
- 一見すると幅広い技術力で顧客の求めるものを何でも作る役割に見える
- 技術と同等に重要な要素:
- ビジネスコミュニケーションと関係構築
- 要件定義と担当業界の理解
- 根拠となる経験:
- 自分自身、今年の初めまではFDEではなかった
■ 2. 既存スキルの意外な有用性
- FDE以前の経歴:
- データ品質エンジニアリングを担当するSDET（テスト担当ソフトウェア開発エンジニア）だった
- 肩書きは変わったがコアスキルは変わらず、変わったのはスキルを適用する文脈
- 既に持っていたスキル:
- 自動化によるプロセスのスケール
- ETL（抽出・変換・ロード）ライフサイクルの理解
- 複雑な事柄を非エンジニアにかみ砕いて説明する力
- 初めての顧客対応:
- 自作の自動化プロセスの顧客オンボーディングで、同僚が変更管理の摩擦に直面していた
- プロジェクトの期限が迫る中、技術面だけで解決しようとはしなかった
- シニアリーダーに顧客ミーティングへの同席を依頼し、顧客に求める作業を自分で説明した
- 当時は、この経験が後のFDEの仕事とこれほど似ているとは気づかなかった
- FDEチームの結成:
- AIデモへの顧客需要の高まりを受け、会社が顧客要件を理解しソリューションを作るFDEチームを結成
- 技術面の学習:
- 音声エージェントやLangGraph、n8n、CrewAIを学び始めた
- Pittsburgh Tech Councilのハッカソンで、Google Mapsの有料掲載なしにフードトラックの認知を高める仕組みを試作
- Steel City AIのワークショップで約30人に旅行日程作成ツールの作り方を教えた
- 技術以外の学び:
- FDEになるとは、不確実性への対処、顧客とのコミュニケーション、技術の背後にあるビジネス課題の理解を学ぶこと
■ 3. すべてを知る必要はない
- インポスター症候群:
- 役割に就いた当初は、役に立つにはもっと知識が必要だと考えていた
- 知らないことに罪悪感を持つという考えを捨てる必要があった
- 全部知っているふりをやめ、助けを求めることに慣れる必要があった
- 移行案件での試練:
- プラットフォームで最も複雑な部分をマッピングしていた
- クライアントが仕組みの理解を望み、プロダクトスペシャリストとの共同デモを依頼した
- 特定機能がクライアントのユースケースでどう動くか質問され、答えられなかった
- 正直な対応:
- まだ分からないこと、自分が新任であることを伝えた
- 調べて具体的な動作を示すと約束し、クライアントはそれを受け入れた
- その後の準備と成果:
- 週末にプロダクト動画を見て、技術チームから文脈を得た
- ビジネス文脈を理解することで技術と結びつけられた
- デモではすべてを簡潔に説明し、追加質問に答え、摩擦なくクライアントのビジネスをより深く知った
■ 4. 技術よりビジネス理解
- ビジネス理解の重要性:
- 技術も重要だが、ビジネスの理解は当初の予想以上に重要
- ビジネスを理解すると「どう動くか」だけでなく「なぜ重要か」が分かり、技術導入とクライアント支援が容易になる
- 捨てた思い込み:
- 速く進むことだけが正解だという思い込み
- ミスをしてはならず、弱さを見せるのは悪いことだという思い込み
- 以前はミスで評価されることを恐れていたが、周囲は協力的だった
- 最も困難だった局面:
- 大量データをクライアントのステージング環境にロードする際、リソース上限に繰り返し達した
- 原因を理解するためにログやキューを徹底的に調べた
- テスト環境でのミス:
- 別チームの助けが必要な復旧を要するミスをした
- どちらのケースも責任を認め、協力して修正した
- FDEとミスの関係:
- FDEになってもミスはなくならない
- ミスを発見し、伝え、適切な人と協力して直す責任を負うことがFDEの役割
■ 5. 言われた物を作るだけではない
- 以前の働き方:
- 他者がクライアントから解釈した要件に基づいて自動化していた
- 要件が正しければ問題ないが、誤っていても自分には知る術がなかった
- 現在の業務範囲:
- データ取り込み、データ検証、レポーティングにわたって担当
- データ辞書なしのデータ移行:
- レガシーシステムから自社プラットフォームへの移行で、移行元にデータ辞書が存在しなかった
- レガシーシステムと自社システムを対応づける部分的なデータ辞書の作成を主導した
- レガシーデータをプロファイリングし、テーブル間のつながりを解明した
- 実際には多くのテーブルがつながっていない
- 仕事の本質:
- 要件をコードに変換するだけではない
- クライアントが期待するデータの表示と、クライアント自身のデータの実態を比較・理解することが大きな比重を占める
■ 6. 顧客ニーズとシステムの翻訳
- 要件定義の比重:
- 要件定義が業務の大きな部分を占めるようになった
- クライアントの要望を翻訳し、本人と検証し、フィードバックを集める
- 要望が現時点で実現可能か、別のアプローチが必要かを判断する
- 役割の大枠:
- 信頼を築き、大きな労力を要する場合でもユースケースを解決する方法を見つけること
- 標準外の要望への対応例:
- クライアントが標準提供範囲外の領域の可視化を求めた
- 不可能と答えるのではなく、必要なものを提供する方法を見つけた
- 当初考えていたエンジニアリングの仕事とは異なる
- 仕事の目的:
- 依頼されたものをそのまま作ることが常に目的ではない
- 本当に必要なものを見極め、既存システムで最善の到達方法を見つけることが仕事
■ 7. エンジニア以外との協働
- 関与範囲の拡大:
- 以前は主にデータエンジニアリングとカスタマーサクセスと働き、顧客との接点はほぼなかった
- 現在は範囲が非常に広い
- 全製品群への知識要求:
- 各製品群にオーナーと専門家がおり、そのすべてにまたがる知識が求められる
- 有能であるとはすべてを知ることではなく、誰に聞くべきかを知ること
- 状況別の協働相手:
- 複雑なデモにはプロダクトスペシャリスト
- データ辞書なしのテーブルマッピングにはプロダクトの専門家
- テスト環境の障害にはインフラとデータベース信頼性のチーム
- 調整の負担:
- 専門家の一部は別のタイムゾーンにおり、適切な人を集めるには手間がかかる
- 関係者全員が夜遅くまで対応することもある
- 社内外の関係者:
- クライアント側はステークホルダー、データオーナー、ビジネスリーダー
- 社内はエンジニア、アカウントチーム、プロジェクトマネージャー
■ 8. 組織をつなぐ結合組織
- 必要な3つの能力:
- システムを理解できるだけの技術知識
- 顧客を理解できるだけのビジネス知識
- 専門外の問題で適切な人を巻き込める関係構築力
- 誰に聞くべきか知る価値:
- 誰に聞けばよいかを正確に知る人は、答えを知る人と同じくらい価値がある
■ 9. 役割の未来は本番システム
- AIエージェントとの誤った結びつけ:
- FDEの役割はAIエージェント、デモ、AIワークフローの構築と結びつけられやすい
- しかし現在の移行案件ではエージェントを一切作っていない
- 本番システムへの移行:
- 基盤となるデータ層が固まって初めて、AIエージェントが運用負荷を下げられる
- そのため役割はデモから、決定的な結果を出し曖昧さの少ない本番システムへ移行している
- システム間の相互作用やエッジケースの深い理解と、障害時に素早く動く力が必要
- PoCの限界:
- PoCでは小さなサンプルでプラットフォーム上のデータ表示を示した
- 要件の確定には役立つが、スクリプトはサンプルを基に作られている
- サンプルでは全レコードで動作するかは分からない
- 実データの検証:
- 顧客は承認済みサンプルと照らして全データセットを検証する
- データは乱雑で、多くの自由記述欄が長年その場しのぎの方法で入力されている
- できる限り多くのケースに対応するが、新しいデータが来たら再取り込みしてプラットフォームに反映し、意図通り表示されるか確認する
- その後、再度検証する
■ 10. 鍵はコンテキスト
- AIによるコンテキスト支援:
- AIツールがコンテキスト面で大いに役立つ
- 数十時間の会議の内容をすべて追跡するのは難しい
- 数週間前に議論したフィールドのソースを手書きメモから探すこともあった
- AIアシスタントの活用:
- 会社承認のAIアシスタントで、既に議論済みかを会議メモから確認し始めた
- 実際に議論済みだった
- 社内ナレッジベースの活用:
- 同僚に聞く前に既に解決済みの問題かを確認でき、質問の質が上がる
- AIの誤り:
- データ辞書なしのテーブルマッピングで、AIが存在しない列名を捏造した
- プロダクトの専門家がマッピングを検証し、自分がデータから推測できる情報を補った
- 別の機会には、テーブルに必要な列とその理由をAIが見落とした
- レビューしていなければ下流で障害を起こしていた
- AIとの付き合い方:
- AIが書いたものはすべてレビューする
- 自分が何をなぜしているかのコンテキストをAIに与え続ける
■ 11. FDEが本当にすべきこと
- 最大の教訓:
- FDEになることは、より優れたエンジニアになることだけではない
- 技術、人、ビジネス文脈、曖昧さを横断して働く力を高めること
- FDEを目指す人への助言:
- 1つの問題を選ぶ
- その問題に直面している人と話し、日々のワークフローを理解する
- ワークフローに新たな作業を追加しない解決策を作る
- 要件をシンプルなステップに分解する
- 顧客が気づかないギャップやエッジケースを見つけ、早期に提示する
- 最も重要な原則:
- 技術に問題を合わせるのではなく、問題に技術を合わせる