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