AI時代のエンジニア育成課題を『モデリング』と『生成AI』でなんとかする

Developers Summit 2025 Summer

1. AI時代のエンジニア育成課題を 『モデリング』と『生成AI』で なんとかする ～ 文脈知識の壁を乗り越えるには ～ 株式会社MonotaRO おだかとしゆき 2025.7.18 Developers Summit 2025 Summer
2. 自己紹介 おだかとしゆき 株式会社MonotaRO シニアアーキテクト as JGEEM（@EM4326168385309） 事業(J)会社(G)の元(Ex)EM / 53才 現職はアーキテクチャと格闘 定年までできることしたいことを探る日々 定年後もキャリアは続く/ AIIT 科目等履修生 / 貢献てなんだろう 技術書を書いてみたい ← 「技術書同人」というジャンルを知った see also scrapbox，speakerdeck 2
3. おしながき • 文脈知識、どうやって獲得してますか？ • 意味の構造とモデリング • 「ビジネスベース」に昇華する • やってみる • まとめ と 展望 3
4. 文脈知識 どうやって 獲得してます？
5. エンジニアの役割は変化しつつある • エンジニアが 本質的な複雑性 に向き合うべき理由 ◦ “DevelopersSummit2025” でモノタロウの状況をご紹介 ◦ 生成AIの進化で、その傾向はより顕著に • 本質的な複雑性に向き合うには 文脈知識 が不可欠 ◦ 文脈＝コンテキスト ◦ その事業、業務が行われる背景も含む知識 ◦ 事業要求だけでなく、その要求の背景まで理解する ことで、より価値ある選択・判断を行えるようになる 5
6. 文脈知識、どうやって獲得してます？ • シニアなみなさんはすでに、業務エキスパートとの 対話が進んで、暗黙知や身体知として身に付いてるかも？ ▪ 事業なんも分からん → とりあえずOJTで ▪ 分からないまま開発業務に従事 ▪ 疑問を持つ→聞く→部分的な答えを得る ▪ 部分的な情報が脳内で結晶化される ▪ 業務エキスパートの対話が答え合わせとなり、 「ギョウム、チョットワカル」状態に至る 6
7. 文脈知識、どうやって獲得してます？ • ジュニアなみなさんを初めとした これから参画するメンバも同様にいけそう？ ◦ コードを書く機会、減りましたよね ◦ ドキュメントも文字起こしから自動生成しますよね （しかも冗長なんで目が滑りませんか） ◦ 生成AIのPR、しっかりレビューできてますか ◦ 生成AI前提時代のオンボーディングとは？ 7
8. めっっっちゃ心配 • どうなっちゃうんでしょうね ◦ 「新人のみなさんは claude.md 読んどいて～」 みたいな感じ？ • でもそれって、 コード生成に必要な情報が書かれたモノであって、 何でそうなってんの？っていう 背景情報(＝コンテキスト)も書かれてます？ 8
9. AI-Agent開発の現場では • 唐突ですが最近は、AI-Agentの開発案件が多いそうで ◦ ここでいう「AI-Agent」は、 (ルールベースでは解きにくい)定型業務を 生成AIに対応させることを意図したシステムとします • 当然ならがら、生成AIに業務を把握してほしいので、 業務マニュアルを再整備したり、生成AIが読みやすいよう 整形したりと、形式知化が進んでいることでしょう 9
10. 「形式知化が進む」その流れは歓迎 • 全人類はAI-Agentによる業務の代替を促進するためにも、 業務マニュアル等の整備をどんどん進めるべき （一子相伝的な口伝えの現場も多いでしょうし） • でも、、やっぱりそこに 文脈知識(＝コンテキスト)は含まれていないのでは？ ◦ だって、普通に業務を実施するだけなら、 ビジネスルールが「そのように決められた背景」まで 知る必要ないですよね 10
11. なにが起きるか • 当初はAI-Agentの判断を人が確認するとして 自動化が進めば、人の目に触れず業務が片付いていく ◦ つまり知識がAI-Agentにカプセル化されていく • AI-Agentが想定しないユースケースには人が対応 ◦ 今はまだ百戦錬磨の業務エキスパートがいる ◦ AI-Agentが対応できるユースケースが拡大し、 業務エキスパートの代替わりが進むと、、？ 11
12. つまり • 業務知識はAI-Agentにカプセル化 • 「業務エキスパート」は絶滅危惧種となり、 最終的には「責任を取る人」だけに • ビジネスルールが決められた背景といった 文脈知識（コンテキスト）は現場から失われ • 開発チームが文脈知識に触れる機会は望めなくなり • 「このルール正しいの？」「古からのしきたりじゃ」 12
13. 意味の構造と モデリング
14. 文脈知識も形式知化しなければ • 【再掲】文脈知識とは 14
15. 文脈知識の壁を乗り越えるには • 知識が継承されているなら残せばいいが、、 • すでに失われた知識、不合理な知識は？ ◦ 要求の背景を探求する ▪ その要求のビジネス的な意義は何か ▪ 一見矛盾するルールが併存するのはなぜか • 複数の要求や、制約や前提などとの関係を推論して、 その意図 ≒ 意味の構造を探求する 15
16. 意味の構造？ • 「意味の構造」という言葉、聞いたことあります？ ◦ わたしは、とある ウェビナー で初めて聞きました （出典：イベント | 株式会社レヴィ） ◦ 今も大いに参考にさせていただいてます。ありがとうございます • 言葉は知らずとも ◦ 判断に迷ったら上位概念に照らして考える ◦ 上位目標を詳細化して、自らの目標設定する のように使われている方は多いのでは 16
17. MVV とか Purpose とか • あるじゃないですか ◦ 意味の構造における上位概念 ◦ 社是とかも（朝礼で唱和しがち？） 普段の業務で役に立ってます？ 17
18. あ、答えなくて大丈夫です • 大丈夫です。それはきっと、 意味の構造において ギャップが大きいから？ （つながっていないから？） 18
19. 知ってはいるが、使うに至らない • あるいは、使ってはいるが表出には至らない • ギャップを埋め、あるいは表出させるのに役立つのが 「モデリング」・「生成AI」 • 使わない手はないですよね いい時代ですね 19
20. ビジネスベースに 昇華する
21. モデリング？ 21 • モデリングワークショップにより、 事業、業務の意味を発見する、あるいは共創する ◦ 業務フローやルールの「なぜ？」を可視化する つまり意味の構造を表出させ、つながりを見出す ◦ どうやって？ ← モデリング思考で モデル(図)で表現された 概念と概念の関係性を 考察(分析・総合)する。洞察を得る。推論する。 推論: 既知の事実から新たなルールを発見したり、 新たなケースを既知のルールに照らして結果を導出したり
22. 生成AI？ 22 • ワークショップは文脈知識を獲得する機会 ◦ 業務エキスパートやジュニアなエンジニアはもちろん ◦ 生成AIも「参加」させる ▪ 資料、動画、音声、文字起こし、ホワイトボード の画像など、可能な限りデータを採取して NotebookLMのソースにしたり、 GeminiでGemを作ったり
23. 生成AIが知識の継承を担う • 人が入れ替わっても生成AIは残る • 業務エキスパートも、ジュニアエンジニアも、 「あれ、なんでだっけ？」と思ったら何万回でも聞ける • ビジネスルール間の整合に疑問を持ったら、 納得できるまで議論に付き合ってくれる ◦ 生成AIは推論も得意 → 新たな概念を発見する（深い洞察に至る）かも!? 23
24. 単なる便利AIではなく • こうして作られた環境は、 文脈知識＝ビジネス知識を蓄え、管理する ビジネス知識マネジメントであり、形式知化された ビジネス知識ベースとして Single Source of Truth となり ビジネスの整合を保つ可能性を持っている ◦ ビジネスアジリティ・マニフェスト変革の実現のために (ロジャー・バールトン，ロナルド・ロス，ジョン・ザックマン著（訳）植松隆，塩田宏治，清水千博，庄司敏浩1) 24
25. もちろんAI-Agentの拡張にも • 文脈知識が形式知化されれば、 AI-Agentが対応できるユースケースの拡大も期待できる ◦ 業務マニュアル（業務仕様）にないユースケースにも より上位の概念に照らして是非を判断できるかも 自ら知識を蓄えて自働化を始めたら怖いかも？ いや、複数Agentによる合議制ならあるいは、、 25
26. やってみる
27. 改めて「目的」を確認する • 目的＝文脈知識を表出させる ◦ ビジネスとして ▪ なぜその要望が出たのか ▪ どのような状況を達成できればよいのか ◦ システムとして ▪ 何を、どのように実現すべきか ▪ なぜその判断に至ったのか 27
28. これまで 私がお勧めしてきた手法との違い • これまで: DDDにおける戦略的分析・設計プロセス ◦ ビジネスプロセスから集中すべきプロセスを特定し、 詳細化→分析→構造化 • 今回: より現場に即した分析・設計プロセス ◦ bizから要望を聞く→要求・背景を引き出す (意味の構造を表出させ、つながり可視化する) ◦ 現状分析→ToBe検討→落としどころ判断→移行計画 28
29. 戦略的設計はやらんでいいのか？ • 戦略的な分析・設計は大事 ◦ 会社に儲けさせ、事業を存続させるために不可欠 • でも誰もがその場に居合わせるわけではない • SAチームは、Biz要望の実現が最優先 ◦ 要望と戦略、要望と他施策との関係？今やる意義？？ ◦ ではソフトウェア設計はどこまで求める？ ◦ 獲得した知見をどう遺す？ 29
30. 「やってみた」の前に • BPMの定義でモデリングの粒度を揃える ◦ ビジネスプロセス・モデルの 階層（レイヤー）とステップ ( 出典: 公益団法人企業情 報化協会 ＢＰＭ推進プロジェクト ) • 戦略マップ ◦ 戦略マップとは？令和時代における戦略マップの活用方法 - Miro (出典: Miro | イノベーション ワークスペース ) • イベントストーミング ◦ イベントストーミングから始めるドメイン駆動設計 (JJUG CCC 2025 Spring の登壇資料で触れてます。ご参考ください🙇) 30
31. やってみた（全体の流れ） • まずは 戦略マップ で意味の構造を表現 • からの ◦ asis分析として ビッグピクチャ → コンテキストマップ が鉄板 ◦ ToBe検討では、 プロセスモデル と 概念構成図 も書きます 31
32. やってみた（意味の構造） • 意味の構造を表出させる （BPMでいうところのFL2:詳細事業機能ぐらい） ◦ 要望と戦略、要望と他施策との関連も考える • 描くモデル ◦ 戦略マップ 32
33. やってみた（AsIs分析） • 事業を構成する機能、および機能間の関係を分析する （BPMでいうところのFL3~4:業務機能ぐらい） • 描くモデル ◦ ビッグピクチャー ◦ コンテキストマップ 33
34. やってみた（ToBe検討） • 業務としてどう変えたいか(変えるべきか)を検討する ◦ AsIs分析したモデルをもとに ◦ 現行とのギャップが大きすぎる場合は いきなりToBe検討してもいいかもしれない • 描くモデル ◦ ビッグピクチャー ◦ コンテキストマップ 34
35. やってみた（ToBeを詳細化） • 設計・実装方針を検討する ◦ まずは「とにかく全部盛り込んでみた」を ▪ 方針を検討できるレベルで、ざっくりと ▪ 時間をかけ過ぎず（数時間レベルで）ざっくりと ▪ 意思疎通できる最低限で ざっくりと • 描くモデル ◦ プロセスモデル（BPM(ry)のFL5~6:作業ぐらい） 35
36. やってみた（落としどころ） • 設計・実装方針を検討する ◦ ビジネスインパクトをどう想定するか ◦ 素早く価値を実現するために必要なことは何か ◦ ToBe検討とのギャップこそ「負債」 ▪ 負債を負う意味はあるか、レバレッジできているか ◦ 何に・いつ対応するか ▪ 何が負債で、利子はいくらで、どう返すか ▪ オーバーエンジニアリングは(楽しいが)避ける • この記録こそADR（Architecture Decision 36
37. やってみた • 「ざっくり」ってどんな粒度？の サンプルとして温かい目で見守ってやってください https://miro.com/app/board/uXjVIhYyi6w=/?share_link_id=883122885223 37
38. では細かく見ていきましょう と言いたいところですが 今日の主題はモデリング実践の紹介ではない!?ので、 さらっと参ります🙏 個別に説明してくれ、一緒に検討してやる、 わからんけどとりま話そう、などなど 多様なお声がけをお待ちしております🙇 38
39. 39 進め方: とあるアパレルチェーンで
40. 40 要求を 引き出す
41. 41 戦略マップ
42. 42 ビッグピクチャ
43. 43 コンテキストマップ
44. 44 ToBeビッグピクチャ
45. 45 ToBeコンテキストマップ
46. 46 ぜんぶもりもり設計
47. 47 落としどころ１
48. 48 落としどころ２
49. 49 落としどころ３
50. ギャップが埋まり・表出される • 意味の構造により、戦略と設計が接続される ◦ 「要望と事業戦略」「要望と他施策」の関係が分かる ◦ それをどうやって実現すべきかが分かる • つまり、事業戦略により決まる 「ビジネスルール」や「ビジネスプロセス」が、 実現手段である「現場の設計」として表出される 50
51. そして、生成AIと共創する • ワークショップの記録を生成AIに共有する ※人の記憶はね、、 ◦ 動画、音声、文字起こし、個人のメモなど ◦ 各種モデル ◦ ADRなど各種文書 ※生成AIにまとめてもらってもいいかも ◦ （あれば 統合報告書 や プレスリリース なども） • 生成AIに十分な文脈知識を与えると、 びっくりするような精度でまとめてくれる ◦ 十分な知識が蓄積されれば、 新たな洞察すら得られるかもしれない 51
52. まとめ と 展望
53. 生成AI活用はどんどん進む • コーディングにおけるスニペット提案 • チャットによる相談 • CodingAgentによる自動化・自律化 • 開発環境から独立→並列実行可能に • VibeCodingによる高速なアウトプット （まだまだありそうですけど） 53
54. 人類は ますます「記述」しなくなる • ドキュメントを書くのはもともと疎か • コードも書かなくなってきた • 記述しないどころか、 AIに作ってもらったPRsをレビューするのもしんどい 54
55. システムはさらに自動化 • 事業における業務プロセスが 情報システムに置き換えられている • AgenticCodingによるアウトプット爆増で流れが加速 • ビジネスルールも、ビジネスプロセスも、 すべてのビジネスに関する 知識・構造が 情報システムにカプセル化 されていく 「このルール正しいの？」「古からのしきたりじゃ」 55
56. 人類は「ボタン押し係」 • 人類の役割は ◦ 承認ボタンを押して責任を引き受けること ◦ 自動化しきれない面倒ごとを引き受けること • ビジネスルールやビジネスプロセスの 目的を理解できない人類は、 ビジネスのコントローラビリティを失う？？ 56
57. 伝えるべきは モデル と ナラティブ • 要望が持つ目的とその背景（コンテキスト）を 意味の構造としてモデルに表出させる • 戦略(why)の表出である モデル(what)を忠実に 実装する ◦ 目的に対して忠実に ◦ 手段(how)はクリエイティブに 操作を自動化しただけのスクリプトや、言われるがまま追加した区分は創造的？ エンジニアは best of the best(理想) と 現実の差(負債) を捉え、戦おう。 そのために、良い構造・良い抽象を探求しよう。価値提供に沿った判断をしよう。 開発チームの コンテキスト ナラティブ を伝えよう 57
58. ありがとうございました 58
59. いや待てくれ まだ語り切ってない 時間もちゃんと?余らせた 59
60. エンジニアの PURPOSE とは • アイディアを持った人が、 自ら生成AIを駆使してモノを生み出せるようになった時代 ◦ エンジニア(が | の | に） ▪ 付加できる価値 って何ですか？ ▪ クリエイティビティ って何ですか？ ▪ 仕事を任せたくなる理由 って何ですか？ ▪ 後進に伝えるべきは何ですか？ 60
61. フィーチャーファクトリは不要 • 言われたまま機能を作る フィーチャーファクトリでいいならエンジニアはいらない • AI-Agent時代のエンジニアの役割と野性 では 「エンジニアリングの本質は技術ではない。 　技術を、価値提供に応用すること」だとお話した • 「価値」とは？エンジニアが付加できる価値とは？ ◦ ビジネスの価値なら、ビジネスにより高い解像度を持つ 業務エキスパートが Vibe Coding できたらいいのでは？ 61
62. すべてはトレードオフ • 業務エキスパートが Vibe Coding で開発を始めたら どんなトレードオフスライダーになるだろう MAX ＜〇－－－－＞ MIN：スコープ やりたいことは全部盛る MAX ＜〇－－－－＞ MIN：納期 VibeCodingならあっという間！ MAX ＜〇－－－－＞ MIN：コスト 開発環境は定額制だし、実質無料!? MAX ＜－－－－〇＞ MIN：品質 動いてるんだからいいじゃない 62 荒ぶる四天王案件もここに極まれり？
63. シニアなみなさんは見たことあるはず • 事業の価値の源泉である超重要業務が、 誰が作ったのかも分からんExcelマクロで行われる • 変更要求があるが、どう修正したらいいか分からない • 業務担当者 > じゃあ、あのマクロの出力を入力にして、 ちょっと修正するマクロを作ればよくない?!?!?! • 謎マクロが増殖していく、、みたいな状況を 63
64. 今に始まった議論ではない • End User Computing と Software Engineering の違い という文脈で昔からあった ◦ 拙速につくるか、巧遅につくるか ◦ 色々な事情により事業会社から software engineering的 クリエイティビティが失われた結果、 偶有的複雑性にまみれ、遅くて拙いアプローチしかできない事情も • Agentic Coding の 暴力的な物量により加速され、 急速にスコープを広げ・深刻化するんだと思ってます • ほんの数年で、より大規模に、より深刻に 64
65. AIの進化が解決してくれそう？ • そうかもしれない ◦ コンテキストエンジニアリング的なアプローチで、 マイクロサービス単位で毎回新規作成が現実的になる日が来るかも (出典: Philipp Schmid氏ブログ ) ◦ 今日の話も「意味の構造を生成AIに記憶してもらおう」も同じ文脈 • わからない （いや、わかりたくない のかも） 65
66. エンジニアのクリエイティビティとは • ログラスCEOの布川氏は、そのブログで エンジニアのクリエイティビティに触れていました ◦ 与えられたお題や皆さんが提供した解像度の高い お客様の情報をもとに、創造的に解決 を行うことが、 クリエイティブな職種たる開発の人の仕事 (出典: AIとセクショナリズム｜布川友也 | ログラスCEO ) 66
67. エンジニアのクリエイティビティとは • Rolling the ladder up behind us では エンジニアのクリエイティビティを 「Finesse（技巧）」と表現し、またそれが 容易に失われうることを事例と共に紹介しました (出典: Xe Iaso氏ブログ) ※この文章はその他の文脈も含むが、ここでは触れない ◦ Rolling the ladder up behind us は 「後ろの梯子を巻き上げる」つまり我々は、後進が登るべき 巨人の肩への梯子を巻き上げようとしているのではないか？と 67
68. クリエイティビティがもたらす 品質に価値はあるだろうか？ • エンジニアのクリエイティビティは保守性に宿る ◦ 熟考された構造(設計)は適時性の高い変更を可能とし、 事業の整合性と、システムの安定稼働の礎になる ◦ 拙速に作られたシステムがどうなっているかは、 保守性に苦しむ事業者が多い昨今の状況を見れば自明だろう ◦ AgenticCodingがこの問題を解決してくれるかもしれない そうじゃないかもしれない ◦ 少なくとも わたしは このように考える。だから、 同じ梯子を登れるように、モデルとナラティブを伝えたい 68
69. 無邪気なのかもしれない 69 出典: Wikipedia（ナレッジマネジメント - Wikipedia） • チームが創出する価値はそれぞれと思います。でも、 やるべきことは、そう変わらないんじゃ？ ◦ エンジニアが あなたが（に） ▪ 付加できる価値って何ですか？ ▪ クリエイティビティって何ですか？ ▪ 仕事を任せたくなる理由 って何ですか？ ▪ 後進に伝えるべきは何ですか？
70. つまり 70 いま、エンジニアに必要なのは、 開発チームの、開発チームによる、 開発チームのための、戦略的設計 開発チームの「価値」と「その源泉」を探り、 後進に伝えていこう
71. 本当に ありがとうございました 71