AI-Agent時代のエンジニアの役割と野性

2025.3.9 きのこカンファレンス2025

1. AIが台頭する時代の エンジニア進化論 価値探索とAI-Human Interfaceの スペシャリストへ おだかとしゆき as JGEEM（@EM4326168385309） 2025.3.9 きのこカンファレンス2025
2. 自己紹介 おだかとしゆき as JGEEM（@EM4326168385309） 事業(J)会社(G)の元(Ex)EM / 52才 現職はアーキテクチャと格闘 定年までできることしたいことを探る日々 / 定年後もキャリアは続く AIIT 科目等履修生 貢献てなんだろう see also scrapbox，speakerdeck 2
3. おしながき • AIの波とわたしの動揺 • AIの波とエンジニアの動揺 • エンジニアリングの本質とは • 価値提供へのフォーカス • 今、すぐにでも始めるべきこと 3
4. AIの波と わたしの動揺
5. 最近AI方面の動きが早すぎ!? プロポーザルしたのは2024年9月ごろ 5
6. プロポーザル当時は • CursorはGA済み, Devinはアーリーアクセスだった ◦ CursorはVSCode+Copilotの競合？ ◦ Devinはまともに動いたらすごそうだがよく分からん • コーディングエージェントというより、 チャットが主だったように思う（要コピペ） • ゆえに基盤モデルの性能に注目が集まっていたか 6
7. 空気、変わったよね？ はっきりと空気が変わったと感じたのは年末あたりから • 「Devin観察日記」を読んだ ◦ 月給8万円で雇えるAIプログラマーDevin、雇いますか？ - Devin観察日記｜Daiki Teramoto ◦ ここまでのDevin観察日記のまとめ。なぜDevinは「破壊的」なのか？｜Daiki Teramoto • 自分でも正月休みにClineに触ってみた 7
8. 著名な方々による 現状認識と展望がつぎつぎと 2/4 The End of Programming as We Know It – O’Reilly 2/5 DeNA南場智子が語る「AI時代の会社経営と成長戦略」全文書き起こし 2/14 Building Products in the LLM Era - Speaker Deck 2/26 CLINEに全部賭けろ 8
9. 4記事のエグゼクティブサマリ AI技術の進化は、プログラミングのあり方、企業の経営戦 略、個人の働き方に大きな変革をもたらしている。 AIは、業務効率化、新たなビジネス機会の創出、創造性の 向上に貢献する一方で、人材のスキルシフトや組織の再編を 必要とする。 AI時代を生き抜くためには、AIを積極的に活用し、変化に対 応できる柔軟性と人間ならではの能力を磨くことが重要。 9
10. （うわっ...私の年収、じゃなくて） これもう俺が 話す余地なくね？ 10
11. とは言えせっかくの機会ですし • 先人を真似て、 私の視点・文脈から見える景色についてお話しします • さらに、具体的に、明日から、何を目指して、 どんなアクションを起こすべきかも提言してみます （うまくいかなかったらゴメンなさい） 11
12. というわけで 改めて 12
13. AI-Agent時代の エンジニアの役割と野性 おだかとしゆき as JGEEM（@EM4326168385309） 2025.3.9 きのこカンファレンス2025
14. AIの波と エンジニアの動揺
15. AIはエンジニアの仕事を奪う？ コーディングエージェントの進化 • 入力支援（IntelliSenseとか） • コード補完（初期のCopilotとか） • コード提案（各種基盤モデルのチャットとか） • 実装計画・環境構築・実装・テスト（Clineとか） • Backlogからチケット対応（Devinとか） 15
16. すごい マジですごい（すごい） • 語彙力 • 今はまだ簡単なタスクしか任せられないけれど、 いずれエンタープライズなプロジェクトでも 人によるコーディング・デバッグ（≒介在）が 不要となる日も遠くないのでは？？ 16
17. 奪われちゃう？本当?? 現状を第一次産業革命に例えることがあるが • 手工業→機械工業で熟練工の仕事が機械に代替された • 一方で機械の製造/操作/保守など新たな職種が生まれた • 製造業における生産性が飛躍的に向上 • 都市への人口集中、労働者階級の形成、貧富の格差拡大な ど、様々な社会問題 • 人々の生活を豊かにする技術革新への期待とともに、 機械による職の喪失や社会変革への不安が広がる 17
18. 確かに似てるかも。でもそれって • 既存のスキルセットに固執すれば脅威となる 一方で、新しいスキルを習得すれば大きな機会になる • ソフトウェア開発の 生産性、品質、スピードを大幅に向上させる可能性 • 雇用の二極化、AI倫理、プライバシー侵害、AIによる格差拡 大など、新たな社会問題 • AIによる生活の質の向上や新たな価値創造への期待がある一 方で、AIに仕事を奪われるのではないかという不安や、AIの 暴走、倫理的な問題への懸念 18
19. そもそも「ソフトウェア」はこれまでも 多くの業界・業務を変革してきた 19 今度はわれわれの番、、ということなのか？ • そうは思わない • これまでもソフトウェア開発業務には さまざまな変革があった ◦ 機械語→アセンブラ→構造化言語→オブジェクト指向... ◦ オンプレ→VM→クラウド... • それは「偶有的な複雑性」を抽象化する変革だった ※ 偶有的：偶然に備わっているとみられる性質
20. つまり、 まだ慌てるような時間じゃないってこと？ いや、それもちがう • 今起きていることは、第一次産業革命に比べて 圧倒的な速度でソフトウェア開発業務を変革している • しかも繰り返される変化は「振り子」ではなく「らせん」 であり、同じ軌跡は取らない • これまでの変化とは 比べ物にならないインパクトがあるかもしれない 20
21. エンジニアリングの 本質とは
22. エンジニアリングの本質 「偶有的な複雑性」という語を出しましたが、 ソフトウェア開発における「本質的な複雑性」とは 22
23. エンジニアリングの本質 「偶有的な複雑性」という語を出しましたが、 ソフトウェア開発における「本質的な複雑性」とは 誰に・どんな価値を届けるか では。 23
24. エンジニアリングの本質 「偶有的な複雑性」という語を出しましたが、 ソフトウェア開発における「本質的な複雑性」とは 誰に・どんな価値を届けるか では。 つまり、エンジニアリングの本質は技術ではない。 24
25. エンジニアリングの本質 「偶有的な複雑性」という語を出しましたが、 ソフトウェア開発における「本質的な複雑性」とは 誰に・どんな価値を届けるか では。 つまり、エンジニアリングの本質は技術ではない。 技術を、価値提供に応用する こと。 25
26. 変わらぬ本質・変わる技術 26 ご参考：Building Products in the LLM Era - LayerX 松本勇気氏 これまで：人が、プログラミングで、コンピュータの 動作を規定 これから：人の要望で、エージェントが、コンピュータを動作させる 価値 本質 技術 より良い手段に パラダイムシフト
27. How は劇的に変わる、だが Why / What つまり 問題領域を分析し、最適な解を提供するという エンジニアリングの本質は何ら変わらない • 我々エンジニアの役割は、 価値提供に伴う偶発的な複雑性を隠ぺいすること • その手段（自動処理実装／AI適用）はさまざまであり、 時流に沿った効率のよい手段を継続して学ぶ必要がある 27
28. 課題設定と価値探索 それってプロダクトマネージャ(PdM)の仕事では？ 見方によってはそうなのかも。 28
29. 課題設定と価値探索 それってプロダクトマネージャ(PdM)の仕事では？ 見方によってはそうなのかも。 • でも、PdMもエンジニアも プロダクトを開発/提供するチームの一員ですよね？ ◦ 「あなた考える人・わたし作る人」ですか？ ◦ 言われたことをやってたらそれでいいですか？ 29
30. 言われたことをやってたら、それでいいですか？ • 文句も言わず24時間働いて、 指示されたことをその能力(資金)の限り遂行してくれる リソース(AI)と競合しちゃいそうですね ◦ 勝てそうですか？ 課題設定と価値探索 30
31. 課題設定と価値探索 勝てそうにないですよね、、 AI-Agentに最適化した開発プロセスも広まりつつありますし • アンラーニングは難しいですよね • 第一次産業革命との対比で話した 既存のスキルセットに固執して、新たな機会を得られない って、そういうことかもしれませんね 31
32. ところで 今週のレトロスペクティブでこんな会話がありました • AI-Agentが生成するコードは動けばよい ◦ 手続き的でも読みにくくても構わない ◦ ただしテストで守り動作は保証する • いや、品質を担保する責任は人にあり、内部品質も同様 ◦ 人が書いたコードと同様にレビューもする ◦ 必要に応じてコメントも書く 32
33. ところで 今週のレトロスペクティブでこんな会話がありました • AI-Agentが生成するコードは動けばよい ◦ 手続き的でも読みにくくても構わない ◦ ただしテストで守り動作は保証する • いや、品質を担保する責任は人にあり、内部品質も同様 ◦ 人が書いたコードと同様にレビューもする ◦ 必要に応じてコメントも書く 33 わたしは ↑ 前者派 ただし、関心の分離とモジュール化が 十分に考慮された小さな部品の単位で AI-Agentに任されており、生成結果の インタフェースが仕様を踏襲しているなら。
34. 再掲）How は劇的に変わる、だが Why / What つまり 問題領域を分析し、最適な解を提供するという エンジニアリングの本質は何ら変わらない • 我々エンジニアの役割は、 価値提供に伴う偶発的な複雑性を隠ぺいすること • その手段（自動処理実装／AI適用）はさまざまであり、 時流に沿った効率のよい手段を継続して学ぶ必要がある 34
35. 人と技術をつなぐインタフェース それはつまり 問題領域と解決領域の インタフェース • これまでもスクラムやDDDなどの文脈においては特に、 ドメインエキスパートとの共創が重視されてきた • 今後はさらに重要度が増し、社内外の多様な方々と ゆるいつながりを多く持つことで共創を促し、より大きな インパクトを生む抽象度の高い問題に取り組む必要がある でしょう 35 自らが持つに技術を用いて価値を提供するだけでなく、 他者が持つ技術によって自らの技術が革新されることも
36. 価値提供への フォーカス
37. AIは道具・活かすのは人 • これまでお話してきた通り、 エンジニアリングの本質は「価値提供」です • その本質的な複雑性に向き合うために、これまでは様々な 偶有的な複雑性に向き合う必要がありました • これからは偶有的な複雑性はAIが抽象化してくれる ◦ CI/CD環境、自動テスト、部品の実装あたりはそろそろ現実的？ ◦ 要望→要求→仕様化→機能／非機能要件化→アーキテクチャ設計→モ ジュール設計→コンポーネント設計→クラス設計...どこまで行ける？ 37
38. あれ？やることなくね？ 要望→要求までAIがやってくれるなら人（エンジニア）は何を？ • 複雑な／混沌とした状況下で 決断・意思決定する こと • OODAループ的にはこの部分 観察する→状況判断する→意思決定する→実行する ◦ 意思決定 とは 仮説を立案するということ ▪ 観察により得られた事実を、文脈知識に照らして洞察を得る → 現状を認識し、適応する仮説を立てる ◦ 実行=仮説を検証する ←AI支援で爆速に（そして新しい仮説へ） 38 エンジニア の役割
39. 仮説検証なら AI にもできそうだけど 例えばAかBかといった対立項があったとして、 弁証法で より高次の命題を導出できそう • 突然ですが、野中郁次郎氏は 野性 の重要性を説いた ◦ 人間が本来持っている 困難な状況にも対応し、生き抜くための力 ◦ 知性＝形式知 と 野蛮＝身体知という 相反する概念を選ぶでも統合するでもなく、 うまくグラデーションして使いこなす概念と解釈（ちがうかも異論大歓迎） 39 野中郁次郎氏の「野性の経営」における"野生"：その定義、効果、そして必要性
40. ありのままに現実の只中で、 先入観なく「感じる」ことだ。(中略） そこで生まれる共感を媒介に、忖度なしに 徹底的に対話する。 野性 as 知的バーバリアン • つまりは経験主義 • これをリーンに繰り返すことはスクラム理論にも通じる 40 https://president.jp/articles/-/60930?page=4 より抜粋
41. 考えるな、感じろ 人は絶対に形式知でAIに敵わない • だからこそ手を動かし、 共同作業を通じて得られた共感をもとに 対話を重ね、意思決定することこそが人の本分であり、 この営みを指して 共創 と呼ぶのだろう （こちらも異論大歓迎） 41 また共創は、探索／センスメイキング／オープンイノベーション／紐帯／創発 にも通じる さいきょうのアーキテクチャを生み出すセンスメイキング
42. 今、すぐにでも 始めるべきこと
43. 事業・プロダクトに興味を持つ • 事業・プロダクトがお客さまに どんな価値を提供しているか 調べる • その価値が 競合他社よりも魅力的か 比べる • その魅力的な価値が、どんな業務プロセス を経て 創出・提供されているか確認する • 魅力的な価値を創出・提供する業務プロセスに 事業リソースが使われているか 点検する 43
44. どうやるの • プロダクトを自分で使ってみる • SNSでエゴサしてみる • 使ったことのある人にインタビューしてみる （5人で80%？） • 公開資料を 分析してみる ◦ 統合報告書、決算短信、決算説明会資料、プレスリ リース、採用情報、などなど 44 開発チームリーダー・ビジネスアナリストが独力でできるコア業務分析
45. • ただし「分析して」だけだとイマイチです • どういう目的で、何を知りたいから、 どういった資料を参照して、どういう観点で分析して。 ぐらいまで言わないと「へぇ」で終わっちゃいます ◦ ちなみに「分析」とは、 全体を 目的に沿って 分けて 観察し、事実を列挙し、 文脈知識に照らして洞察を得るってことだと思ってます • 結果について壁打ちし（あれこれ聞き）まくりましょう 分析？AI　　の出番ですね DeepResearch めちゃ便利・notebookLMおすすめ 45
46. • たとえば ◦ プロダクトの競争力はどのような業務プロセスで 創出されているだろうか？ ▪ これは公開情報だけだときついかも （業務プロセス一覧があればワークしそう） ◦ 各業務プロセスにおいて 最も競争力に貢献しているものはどれだろう？ 分析？AI　　の出番ですね 目的 / 知りたいこと / 観点 / ソース を示す 46
47. • たとえば ◦ 競合比較して自社の強みをより伸ばすために、 注力してエンジニアリングすべき 業務領域はどこだろうか？ ◦ 今開発・改修しているプロセスは、 競合優位性の観点においてどのようなインパクトが あるだろうか？ 分析？AI　　の出番ですね 目的 / 知りたいこと / 観点 / ソース を示す 47
48. ここまではひとり。でも ここからは 共創したいのでチームに持ち掛けましょう • 開発チーム内に、業務に詳しい人いますよね？ または無難にチームリーダーに見てもらいましょう • 興味を持ってくれるように 「今の開発案件の目的・目標をより理解したら、 　もっとシャープな開発ができると思うんですよね、、」 などと言って、今を良くしたい と訴求してみましょう 48
49. 開発チームだけでは限界が さらに共創の輪を広げましょう→次はチームの外にも • プロダクトマネージャやドメインエキスパート あるいは、よく改善要望を出してくれる人など 業務側・ビジネス側の人たちと、共創の場を持ちましょう • 出来物の資料を見せるよりも、 目の前でLLMにゼロから生成してもらったほうが 共創・共感がマシマシになるかもですね、野性ですね 49
50. 対話しまくりましょう どうしたら より魅力的な価値を届けられるだろう • How よりも What を What よりも Why を問い続けましょう • そして Why に見合った What / How を熟考しましょう ◦ それは 抽象と具体を行き来する ということでもあるし インパクト、アウトカム、アウトプットを考える こと にも似ています 50 対話のツールとして イベントストーミング とか おすすめです
51. いきのこるための まとめ
52. 野性を手段につなぐインタフェース エンジニアリングの本質は野性 • 事業・プロダクトを知り、共創し、共感を育て、 対話を通じて意思決定し、磨き続けること • AIはエンジニアリングの手段に過ぎないが、 時代が求める早さに追随するためには不可欠 ◦ 開発環境を使うように、開発言語を使うように、 適切に使いこなして 本質に集中しよう 52
53. いきのこるぞ！ 53