FDEを組織で構造化する際の境界 — それを埋める社内FDEと当事者のマインド

2026/09/28、ROSCA株式会社主催「FDEは、コンサルなのかエンジニアなのか？ー顧客課題とプロダクト開発の境界線」（Algoage × YOUTRUST）での登壇資料です。
https://rosca.connpass.com/event/404984/

FDEを1人で担える人は採れなかったので、BizPM / プロダクトPjM / プロダクトエンジニア＋PdM / ARE の4つに役割を分けました。分けた結果どこに境界ができて、それを誰が埋めるのかを整理しています。

・一人では無理 → 構造化の模索
・分けた先にできた境界
・境界を埋める社内のFDE
・外から持ってきた型は定着しない
・個人の気合には乗せ続けられない
・で、コンサルなのかエンジニアなのか

等、組織で構造的に解こうとした先で当たった壁とそこで要るマインドの話を詰め込みました。

役割を4つに分けるまでの経緯は4月のFindy登壇で話しています。
https://speakerdeck.com/miyatakoji/findy-fdedeng-tan-2026-04-14-xian-chang-ke-ti-woben-qi-dejie-itetara-fdeninatutetahua

Transcript

1. Algoage FDEを組織で構造化する際の境界 — それを埋める社内FDEと当事者のマインド 宮田航志 株式会社Algoage 執行役員 / CTO FDEは、コンサルなのかエンジニアなのか？ Algoage × YOUTRUST / ROSCA Dev's Garden 2026.09.28 ©2026 Algoage, Inc. All Rights Reserved. 1
2. 自己紹介 執行役員 / CTO — Algoage Inc.（DMM Group） 宮田航志（Miyata Koji） 2015年 コロプラ入社 — VR・位置情報ゲームの新規開発 2020年 DMM.com入社 — マーケティング技術部門のTL・PM 2023年 DMMCrypto 子会社化、Web3特化事業のCTO・PdM 2025年 Algoageに転籍、CTOとして色々 趣味 ・2才の息子と戯れる ・K-1アマチュア(AI時代に物理的な痛みで生を感じる） ©2026 Algoage, Inc. All Rights Reserved. 2
3. 会社紹介 会社名 株式会社Algoage（アルゴエイジ） 設立 2018年02月01日 代表 代表取締役 横山 勇輝 東京大学AI研究室発のスタートアップ 従業員数 150名（パート/業務委託含む） 事業内容 Cコマース事業、生成AI研修事業、 カスタマーサポートAI事業 出資企業 合同会社DMM.com DMMグループ傘下 （生成AI前の）DeepLearning時代から 一貫して最新技術のビジネス応用に強み ©2026 Algoage, Inc. All Rights Reserved. 3
4. AlgoageはAIに強みを持った事業創造会社（2018創業） CV最大化する チャットマーケティングSaaS事業 企業のAI活用を加速 コンサルティング・研修事業 ©2026 Algoage, Inc. All Rights Reserved. 4
5. 事業の現在地（フェーズ） ©2026 Algoage, Inc. All Rights Reserved. 5
6. 事業紹介 ©2026 Algoage, Inc. All Rights Reserved. 6
7. 01 01 一人では無理→構造化の模索 02 分けた先にできた境界 FDEを組織で構造化するための 試行錯誤 03 境界を埋める社内のFDE 04 外から持ってきた型は定着しない 05 個人の気合には乗せ続けられない 以前の登壇の振り返り ©2026 Algoage, Inc. All Rights Reserved. 06 コンサル？エンジニア？ 7
8. 01 一人では無理→構造化の模索 FDEの定義の再確認（以前登壇の再掲） ベースは事業の成長をKGIとして最適化する 事業モデル作成・改善のループを行う １ ２ ３ ４ ５ 現場に入る 課題特定 ソリューション 提案 作って届ける 事業に還元 見学/ロープレ 課題特定 決裁者とKPIを語る 期待値整理 仲間として一緒に 個社拡張を実装 汎用機能として昇華 現場への敬意を忘れない。「AIの人たちが来た」と思われたら本質的価値は提供できていない。 「置き換えに来ました」じゃなくて「痛みを取り除きに来ました」。 ©2026 Algoage, Inc. All Rights Reserved. 8
9. 01 一人では無理→構造化の模索 これを全部1人でできる人＝FDE？ でも採れない（以前登壇の再掲） これを全部１人でできる人がFDE？ でも採用は難航 • 実際、書類選考の通過率は2.3%（他は約20%） • スーパーマンは少ない。そういう人はこの時代会社を立てて１人でやってる • 文化マッチ・スキルマッチ完璧を求めるとさらに希少性が高い • あまりにもキーマンリスクが高すぎる ©2026 Algoage, Inc. All Rights Reserved. 9
10. 01 一人では無理→構造化の模索 分業（以前登壇の再掲） データ・ソフトウェア・AIの知見を分けて考え 適切な役割分担をする • ARE：Applied Research Engineer（応用研究エンジニア） ◦ データエンジニアリングとAIに関する深い知見 • FDE：Forward Deployed Engineer ◦ ソフトウェア開発とプロダクト化への深い知見 ©2026 Algoage, Inc. All Rights Reserved. 10
11. 01 一人では無理→構造化の模索 分業（以前登壇の再掲） AIプロダクト 顧客の 業務環境 → エージェント層 各社のSaaS・業務の癖に アンビエントに浸透する ワークフロー層 業務をどう定型化し どこまでAIで解くか コンテキスト層 顧客のナレッジデータを 構造化する 個社知見を 汎用に還元 役割・意思決定の主権を分け合う。 ©2026 Algoage, Inc. All Rights Reserved. 11
12. 01 一人では無理→構造化の模索 分業（以前登壇の再掲） AIプロダクト 顧客の 業務環境 → エージェント層 各社のSaaS・業務の癖に アンビエントに浸透する ワークフロー層 業務をどう定型化し どこまでAIで解くか コンテキスト層 顧客のナレッジデータを 構造化する FDE FDE x ARE 個社知見を 汎用に還元 ARE 役割・意思決定の主権を分け合う。 ©2026 Algoage, Inc. All Rights Reserved. 12
13. 今日の発表で話すこと 分けた先の課題・組織論とマインドについて
14. 02 01 一人では無理→構造化の模索 02 分けた先にできた境界 03 境界を埋める社内のFDE 分けた先にできた境界 04 外から持ってきた型は定着しない 05 個人の気合には乗せ続けられない 06 コンサル？エンジニア？ ©2026 Algoage, Inc. All Rights Reserved. 14
15. 02 分けた先にできた境界 いまの役割分担概要 いま動いている4つの役割 BizPM：顧客の窓口に立つ、事業側のPM プロダクトPjM：案件を跨ぎ優先順位を決める プロダクトエンジニア＋PdM：要件を決めて作る ARE：成果を測ったりデータを構造化する → 分業が進み、最近は社内でFDEというワードはあまり使わなくなっている。 ©2026 Algoage, Inc. All Rights Reserved. 15
16. 02 分けた先にできた境界 高速で変わる状況での複雑なプロジェクト管理 1つ目 — 事業側と開発側の境界 ・リリース日程の調整が曖昧に ・顧客との定例で出た日付が、開発には前日まで 届いていない ・間に合わないと判断する人が決まっていない → 顧客環境に依存した追加開発は見積もりが読めない。仮の日付がそのまま顧客に ©2026 Algoage, Inc. All Rights Reserved. 16
17. 02 分けた先にできた境界 顧客業務の解像度 vs プロダクト要件/システムの解像度 2つ目 — 顧客の業務と実装の境界 ・要件の意思決定を誰が持つか曖昧に ・顧客の業務を理解しているBizPMも、開発へ の細かい要件定義までは踏み込めていない。 ・プロダクトエンジニアは顧客業務の解像度が 上がりきらない → エージェント層とワークフロー層の判断が業務を知らない側に落ちる ©2026 Algoage, Inc. All Rights Reserved. 17
18. 02 分けた先にできた境界 プロダクトのメトリクス計測の難しさ 3つ目 — プロダクトとデータの境界 ・メトリクスを取る担当が曖昧化 ・高速なプロダクト開発・機能刷新にデータ分 析エンジニア（ARE）が追従できない ・プロダクト側のエンジニアもログに細かく気 を配らずに機能をリリース → コンテキスト層の作り替えは、汎用化を急ぐたびに走る ©2026 Algoage, Inc. All Rights Reserved. 18
19. そもそもなぜ このような初歩的なミスが起こるか
20. 02 分けた先にできた境界 FDEの難易度を上げる前提 → 役割を分けると境界が生じてコミュニケーションコストが増えるのは、昔から一緒 ©2026 Algoage, Inc. All Rights Reserved. 20
21. 02 分けた先にできた境界 組織論としての選択肢の例 例１ プラットフォームを薄くして、 ストリームアラインドを招集 例２ プラットフォームを厚くして、 Biz＋少数のFDEで回す 案件ごとにチームを組み顧客に張る 共通基盤に投資しまくり横展開を効かせる。 立ち上がりは速いが、横展開が効かない。 ただし、何が汎用かが分からない段階では AI開発時代には、組織を立ち上げられるのであれば良しとされている印象 基盤そのものを引き直し続けることになる。 がある → どちらも中途半端だと境界は残り続ける ©2026 Algoage, Inc. All Rights Reserved. 21
22. 03 01 一人では無理→構造化の模索 02 分けた先にできた境界 03 境界を埋める社内のFDE 境界を埋める社内のFDE 04 外から持ってきた型は定着しない 05 個人の気合には乗せ続けられない 06 コンサル？エンジニア？ ©2026 Algoage, Inc. All Rights Reserved. 22
23. 03 境界を埋める社内のFDE 社内にFDEが必要じゃないか 社内FDE=事業を止めず後から 共通基盤を作る人 基盤は最初から設計できない前提で、0→1が複数走る。 その状態で境界を埋めるには、後付けで作るしかない。 ©2026 Algoage, Inc. All Rights Reserved. 23
24. 03 境界を埋める社内のFDE 社内FDE（仮）は何をするか 3つの境界を埋めて自動化する ・顧客課題の伝達 ・業務の前提とかけていいコストの基準 ・品質管理 ・リリース判定 ・メトリクス計測 ・障害対応フロー 等全部にガバナンスを利かせて自動化し ていく人 → 決めたことを、人の記憶ではなく仕組み側に置く。この役割を、社内FDEと呼んでみる？ ©2026 Algoage, Inc. All Rights Reserved. 24
25. 03 境界を埋める社内のFDE プラットフォームエンジニアリングとの差 プラットフォームエンジニアリング 社内FDE 開発側のDevOpsの インターフェースの実装 営業の最初から運用まで、 一気通貫で型化する 開発者が自分で前に出られる基盤を作る。 営業の最初の接点から、顧客デリバリー、 CI/CD、環境、権限、可観測性。 その後の運用まで。 対象は開発組織の中に閉じている。 Bizサイドも含む組織全体のプラットフォーム そこを再発明したいわけではない。 かどうかが、分かれ目。 ©2026 Algoage, Inc. All Rights Reserved. 25
26. 04 01 一人では無理→構造化の模索 02 分けた先にできた境界 03 境界を埋める社内のFDE 外から持ってきた型は定着しない 04 外から持ってきた型は定着しない 05 個人の気合には乗せ続けられない ここからはマインドの話。 仕組みを作れるのは、誰か ©2026 Algoage, Inc. All Rights Reserved. 06 コンサル？エンジニア？ 26
27. 04 外から持ってきた型は定着しない 型は課題を知る当事者しか作れない 型は一度全部やった人にしか作れない 型を外から持ってきても境界を繋ぐ仕組 みは定着しない。 3つの境界を全部踏んだ人が、どこで落ち るかを知っている。知っている人だけ が、落ちない置き方を決められる。 なので、当事者として全てに潜り込める ような人がペルソナです。 ©2026 Algoage, Inc. All Rights Reserved. 27
28. 04 外から持ってきた型は定着しない 入らないと境界は見えない 仕組み化が先ではない。 当事者になるのが先 顧客の課題に向き合う。約束した日付を守る。 やるのは当たり前のことだけ。 全部やって当事者になってからじゃないと生きた仕組みは作れない ©2026 Algoage, Inc. All Rights Reserved. 28
29. 05 01 一人では無理→構造化の模索 02 分けた先にできた境界 FDEも社内FDEも 個人の気合では続かない 組織・CTOとして何をすべきか 03 境界を埋める社内のFDE 04 外から持ってきた型は定着しない 05 個人の気合には乗せ続けられない 06 コンサル？エンジニア？ ©2026 Algoage, Inc. All Rights Reserved. 29
30. FDEに必要なのは、当事者意識と コミットメントと、気合！ ただし、、、
31. 05 個人の気合には乗せ続けられない 人生の中で本当にFDEをやりたいのか（パイオニアになりたいか） 本気でやると相当辛いが見合うか？ その辛さを、全員の前提にはできない。 家庭や大事なものを犠牲にする働き方になることもある。 ただ、 FDE的な仕事も、いずれ落ち着くはず。 基盤が整えば、いまの辛さは仕組みの側に移る。 そのとき捨てたものがその人の人生にプラスなのか。 人生の中で一度、ちゃんと見極めたほうがいい。 ©2026 Algoage, Inc. All Rights Reserved. 31
32. 05 個人の気合には乗せ続けられない 組織・CTOとしての役割 FDEを体現できるアーキと組織を作り続ける 事業フェーズを捉え組織論に昇華させる 事業と技術を正しいアーキテクチャに落す そして正しい方向に引っ張る これもFDEが提案してくれてもいい ここまで来ると経営レベル。FDEに求めすぎかもしれない だから役割が分かれてきているのかもしれない ©2026 Algoage, Inc. All Rights Reserved. 32
33. 06 01 一人では無理→構造化の模索 02 分けた先にできた境界 03 境界を埋める社内のFDE コンサルかエンジニアか？ 04 外から持ってきた型は定着しない 05 個人の気合には乗せ続けられない 組織が整えるとして、 人の側には何が要るか ©2026 Algoage, Inc. All Rights Reserved. 06 コンサル？エンジニア？ 33
34. 06 コンサル？エンジニア？ イベントのタイトルに戻る FDEは、コンサルなのかエンジニアなのか？ 事業を成功に全部持っていく人の象徴。そのペルソナをFDEと呼んでいる。 ここまでの話を踏まえて、この問いに答えてみる。 ©2026 Algoage, Inc. All Rights Reserved. 34
35. 06 コンサル？エンジニア？ 答えは条件で変わるかも（今回のイベントタイトルの問いに添えて） 基盤がある場合 基盤がない場合 コンサル寄り エンジニアより 共通基盤が実装されていて、 基盤が無い段階で境界を埋めて、 プラットフォームが重厚なら。 一度当事者になって全部実装するなら。 顧客の業務を掴んで、要件に落として、 エンジニアとして全部巻き取る人が要る。 基盤の上で組み立てれば価値が出る。 後付けで共通基盤を作るのは、 また、事業戦略自体のアップデートの話もできるなら尚良 実装できる人にしかできない。 Palantirが一人で動けるのは、この側。 → 弊社は後者だから社内FDEが要るし、その型を作るのは当事者になった人 ©2026 Algoage, Inc. All Rights Reserved. 35
36. 以上です！ 採用ページ @miyata_17_ AI事業を作る上での組織・アーキテクチャ論 その中で幸せに生きるためにはどうすればいいか というお話でした！ 懇親会で一緒に楽しく飲みましょう！ ©2026 Algoage, Inc. All Rights Reserved. 36