AI駆動開発4年目の現在地（『あなたはFDEになるべきか？』イベント資料）

10/29 シンプレクス社主催『あなたはFDEになるべきか？～AI時代になにを身につけ、どんな仕事を選ぶか～』登壇資料

Transcript

1. あなたはFDEになるべきか？ 〜AI時代になにを⾝につけ、どんな仕事を選ぶか〜 AI駆動開発 4年⽬の現在地 エンジニアの役割の変化とは 2026.10.29（⽊）19:00〜 ランスティア株式会社/クマイ総研 熊井悠 kumai Yu
2. 本登壇で話したいこと その1 その2 その3 その4 シンプレクスで 約4年間の エンジニアの役割は あなたは 学んだこと AI駆動開発の歴史 どう変わったか？ FDEになるべきか？ コードの外にあった なぜコードを 「書く」から 役割の変化から エンジニアの価値とは？ 書かなくなったのか？ 「定義し、判定する」へ 答えを出す ⽬的 エンジニアの役割の変化から、「FDEになるべきか？」に答えます！ 2
3. ⾃⼰紹介 熊井 悠 ランスティア株式会社 CEO∕CTO エンジニア → PM → ITコンサル → 起業。シンプレクスでFXシステムの開発‧運⽤‧PMを経験 2023年夏からAI駆動開発に取り組み、「クマイ総研」というAI駆動開発コミュニティを運営 シンプレクス ベイカレント ランスティア 2015 2016 2017〜19 2019〜20 2020 2023.7 エンジニア 運⽤PL PM ITコンサル 創業 AI駆動開発 FXディーリング 24時間オンコール 年間400〜500⼈⽉ ITコンサルタント 受託開発‧ 検証開始→ システム開発 5〜6⼈のチーム 200⼈⽉の新規導⼊ AI/ブロックチェーン プロダクト開発 2024年にチーム展開 書籍 『AI×アーキテクト〜⽣成AI時代の開発が抱える「複雑性‧不確実性」を構造で受け⽌める〜』 元⽊‧熊井 共著 技術評論社 2026年10⽉27⽇発売 3
4. その1 シンプレクスで学んだこと 4
5. 1〜4年⽬：任された経験 技術も⾦融業務も分からないところから、 毎年、任される範囲が広がっていきました。 2014〜15 2016 2016年末 3年⽬ 4年⽬ 1 2 3 4 5 研修‧配属 10年超のFX案件 運⽤保守/開発PL 運⽤保守PM 新規導⼊PM Java‧⾦融⼯学 複雑なバッチ 社員‧業務委託 経緯を知るのが 200⼈⽉‧最⼤約50⼈ UCLAで講義も 24時間オンコール 5〜6⼈のチーム 実質⾃分だけなる。 毎⽇顧客拠点で FXディーリング 障害対応‧開発に集中 クラスタ‧サーバ 顧客折衝‧⾒積‧ 要件定義を⽴て直し インフラも全て対応 リリース管理 予実差異ゼロを実現 の開発へ ⽇常の開発‧運⽤はメンバーに任せ、難しいところは⾃分で深く⼊る。 若⼿のうちから、業務とシステム全体に責任を持つ経験を積んできた。 その1｜シンプレクスで学んだこと 5
6. 1〜4年⽬：開発の仕組みを変える 1年⽬の終わりに、⽣意気にもシステム開発の改善提案をしたら 「じゃあ、やりなよ」と⾔ってもらえました。 1年⽬ 1〜2年⽬ 2016年末 3〜4年⽬ 4年⽬ 1 2 3 4 5 SVN→GitHub CI/CD‧Slack 運⽤プロセス リリース⾃動化 余⼒を新規へ 改善提案から CircleCI等を⽐較 ITILを学び 年間約300⼈⽉の 粗利が改善 タスクフォースへ Jenkins 2‧Docker JIRAを4つの管理 既存PJで、リリースを 浮いた⼈員を 約10PJを移⾏ で基盤を刷新 プロセスに再設計 JP1でほぼ⾃動化 200⼈⽉の ⾃動テストも導⼊ 新規導⼊へ投⼊ Ant/Maven→Gradle 技術的な改善が、利益と⼈の余⼒を⽣み、次の案件を動かした。 いまAI駆動開発でやっていることも、この延⻑線上にあります。 その1｜シンプレクスで学んだこと 6
7. その2 約4年間のAI駆動開発の歴史 7
8. ⼤きな変遷の紹介 2023年夏の検証から始まり、 2026年はコードを1⾏も書いてません。 2023.7 2023.9 2024.4 2025 2026 1 2 3 4 5 要件定義で検証 コード⽣成 組織化 エージェント エージェント⾃⾛ OpenAI APIで Cursorで検証 UI⽣成の登場で AIが実装 設計レビューと フロー図作成を試す 既存コードの拡張や Biz‧開発‧QAに AI駆動開発チームが 品質管理チーム 当時の性能では 相談なら使える チームを分けて展開 ノウハウを提供 テストは半⾃動化 難しい AIの担当は「補完」から「⼯程全体」へ。⼈の担当は「書く」から「Issue定義とリリース判定」へ。 その2｜約4年間のAI駆動開発の歴史 8
9. 2026年の開発フロー 現在、僕がやっているのはIssue定義とリリース判定。 間の⼯程はAIエージェントが回しています。 サブエージェントが並列で実⾏（⼯程ごとの観点はSkillで渡す） 僕 親エージェント Issue定義 タスクを分解 調査 仕様‧設計 実装‧UT 調査 仕様‧設計 実装‧UT 調査 仕様‧設計 実装‧UT ミクロ レビュー ミクロ レビュー マクロ レビュー CI/CD 僕 リリース判定 ミクロ レビュー ↻ 各⼯程の成果に評点をつけ、基準に満たなければループ ▪⼈ □ AIエージェント‧⾃動化 ⾃社AIプロダクトは開発〜リリースまで5⽇間、約10⼈⽉の受託開発は2週間。 結果として、2026年はコードを1⾏も書いてません。 その2｜約4年間のAI駆動開発の歴史 9
10. 実際に⼀番詰まったのは？：レビュー負荷 作る速度は桁違いになった。 が、確かめる速度はむしろ遅くなっている。 起きたこと：逆ドーナツ ⼈ やったこと：ドーナツ型へ ‧コードはすぐ出てくるのに AI ‧レビュー観点‧ズレの レビュー待ちが減らない ⼈ チェックをSkill化 ‧並列の成果物は、1つずつは AI 正しく⾒えてもつなげると破綻する ‧各⼯程の成果に評点をつけ AI ‧今までエンジニアレベルで 数値で判定 ‧ミクロで個別に、 修正されていた課題が マクロで全体をレビュー 全てレビューに流れてくる ⼈は外側で後始末と承認係 ⼈は中間帯で検証‧例外判断 それでも最後に「正しいか」を判定するのは⼈。 その基準になるのが、ドメイン知識。 その2｜約4年間のAI駆動開発の歴史 10
11. その3 エンジニアの役割はどう変わったか？ 11
12. エンジニアの役割はどう変わったか？ エンジニアの役割は、 「書く」から「定義し、判定する」へ。 配置の原則：上流ほどゆらぎを許し、下流ほど固める（『AI×アーキテクト』より） 調べる‧⽐べる‧案を出す 設計‧実装‧検証 外部送信‧課⾦‧本番更新 AIが揺れても後で捕まえられる 検証できる形にしてAIに渡す AIを置かず、⼈が承認する 思考 何を作るか 何が正しいか 線を動かす条件 線をどこに引くか決める Issue定義で決める リリース判定で決める 「安定した」を何の数字で判定するか 仕組みづくり タスクの型 検証できるルール 評点とループ 引いた線を固める 依頼に必ず含める項⽬を固定する そのままレビューの判定基準になる Skill‧コードセットに落とし、AIが⾃⾛ 結論、⼈に残る仕事は「仕組みづくり」と「思考」。 何を作り、何が正しいかを決める。 その3｜エンジニアの役割はどう変わったか？ 12
13. その4 あなたはFDEになるべきか？ 13
14. そもそもFDEとは？ 最近のFDE論は「1⼈で要件定義〜実装する⼈」に寄りすぎ。 FDEは⼈ではなく、循環である。 探索：現場に出る 深化：本体を磨く Echo Delta（FDSE） Product / Core Deployment Strategist Forward Deployed SE プロダクト開発 顧客の業務と課題を理解し インサイトを掘り当てる ⾃社プロダクトを元に 現場で実装‧検証する 現場の知⾒を受けて プロダクトを改善‧拡張する 強くなったプロダクトを持って、また次の現場へ。次の開発がさらに速くなる 循環が⽣み出しているのは、顧客業界への深いインサイト。 だから「それは作りません」とNoと⾔える。 その4｜あなたはFDEになるべきか？ 14
15. 「ひとりFDE」の落とし⽳ 1⼈で何でも作れるFDEほど、 真っ先に代替される。 ひとりFDE 現場A 作る 終了 現場B 作る 本体へ還流 プロダクト 現場B 知⾒を磨き込む 強化 深いところから 知⾒は頭の中 終了 知⾒は頭の中 毎回ゼロから。要望に応える以外の選択肢がない＝⾼速な御⽤聞き 循環するFDE 現場A 作る Noと⾔える 経験が次に持ち越され、インサイトを再現性をもって出せる 約10⼈⽉を2週間で作れる時代。 速く作れること⾃体は、もう差別化にならない。 その4｜あなたはFDEになるべきか？ 15
16. あれ？よく⾔われる「ドメイン知識」は？ ドメイン知識が「頭の中に完全に揃っていること」は ほぼない。つまり⼀⼈では限界がある。 個⼈的に得意と思っていた「⾦融」領域も、クライアントの副社⻑と会話したら システム側の知識だけだったと思い知った。＝視座が低い イシュー定義 ① 集める 何を判断するか 最短で必要な情報を集める ② 整理する ③ 評価する 業務‧システム‧経営の 視座で並べ直す その情報で 判断してよいかを確かめる 判断 AIへの⼊⼒ Garbage In, Garbage Out：⼊⼒が悪ければ、AIを使っても正しい解には辿り着かない だからこそ、個⼈の経験を集合知に変える仕組みが要る。 これがFDEでいう「還流」の正体。 その4｜あなたはFDEになるべきか？ 16
17. エンジニアが持つべき3つの基盤 コンサルタントはインサイトを資料にする。 エンジニアは、インサイトをシステム‧プロダクトにできる。 1 2 3 思考フレームワーク 知の集合体（データ） プログラム基盤 イシュー定義‧情報源‧ 業界構造‧業務知識‧ コードセット‧Skill‧ フィードバック‧バイアス除去 過去の判断理由を 並列エージェント‧ を型として持つ AIが参照できる形で蓄積 機械判定できる完了条件 最初から揃っていなくていい。 知の集合体を持つ組織に所属して、組織の⼒で補うのも有効。 その4｜あなたはFDEになるべきか？ 17
18. あなたはFDEになるべきか？：僕の答え ⽬指すべきは、FDEという肩書きではない。 現場で得たものを次に持ち越し、循環させられるエンジニア。 1 2 3 現場に⼊る 次に持ち越す 仕組みで届ける 顧客の業務と業界の構造を 判断の理由と知⾒を インサイトを ときに顧客以上に理解する 知の集合体へ還流させる そのままプロダクトにする 役割が「定義し、判定する」へ移ったいま、 これはFDEに限らずすべてのエンジニアに求められる。 その4｜あなたはFDEになるべきか？ 18
19. シンプレクスを振り返って いま効いているのは、若いうちに ⾦融の現場で鍛えた、思考とドメイン知識でした。 シンプレクス時代 いま 思考 ひたすら要件定義や顧客折衝を繰り返した。 お客様先に毎⽇通って課題を分析した。 イシューを定義し、何を作るかを決める 知の集合体 ⾦融の知⾒‧有識者に聞ける環境 10年以上続くシステム 業務を掴み、AIに正しい⼊⼒を渡す プログラム基盤 ⾃社パッケージの上で開発し、⾃動化の基盤を作った コードセットとSkillでAIに任せる 厳しいドメインの現場で、若⼿のうちから考えて任される。 AI時代にいちばん効く経験になっています。 その4｜あなたはFDEになるべきか？ 19
20. まとめ 役割は「書く」から「定義し、判定する」へ。 FDEは肩書きではなく、循環させられるエンジニアを⽬指す。 ぜひ、思考とドメイン知識を鍛え、 知の集合体を持つ環境に⾝を置いてください！ 20
21. 以上となります！ ご清聴ありがとうございました kumai Yu