Share
Embed
Slide 1
Slide 1 text
組織・文化・技術の壁に挫折したEMが
アーキテクトとして「構造化思考」を手に
再び保守開発組織の変革に取り組む
おだかとしゆき
as JGEEM（@EM4326168385309）
2026.3.4 Engineering Management Conference Japan 2026
Slide 2
Slide 2 text
自己紹介
おだかとしゆき
as JGEEM（@EM4326168385309）
事業(J)会社(G)の元(Ex)EM / 53才
現職はアーキテクチャと格闘 /
と思ったらまた部門長的なポジションに /
定年までできることしたいことを探る日々
定年後もキャリアは続く/ AIIT 科目等履修生 / 貢献てなんだろう
see also scrapbox，speakerdeck
2
Slide 3
Slide 3 text
おしながき
● 略歴
● 挫折
● 気づき
● AI時代の本質
● 新たな学びと外部環境からの示唆
● まとめ
3
Slide 4
Slide 4 text
略歴
Slide 5
Slide 5 text
略歴
● 前職ではEMとして挫折
● 現職でアーキテクトとして抽象化と構造に向き合う2年間
○ 大学院の 科目等履修生制度 を利用して
「管理会計」「情報社会学」などのインプットを得る
■ この辺りは 横浜北部ソフトウェアエンジニアの集い で
発表した 学校に行こう！ - Speaker Deck をご参考ください
● 昨年10月からグループ長として、
今年2月からは部門長としてマネジメントロールに復帰
5
Slide 6
Slide 6 text
挫折
Slide 7
Slide 7 text
挫折
EMとして “人” をマネジメントしていた。
だが “構造” を設計できていなかった。
当時のつらい日常:
● プロパー2：委託先8という人員構成
● 声の大きい業務部門の
要求をそのまま「要件」とし、
設計以降は委託先に丸投げが常態化
● 納期と要求変更への対応に終始し、
「内部品質」という言葉すら存在しない世界 7
Slide 8
Slide 8 text
挫折
撤退（挫折）を決断:
● 質の悪いソフトウェアに疲弊するチームをどうにかしたく、
自動テストや仕様の重要性を説いた
● 圧倒的なリソース不足から 場当たり的な対応 しかできない
● 最終的には「新卒を訓練し、彼らがマジョリティになるまで
待つしかない」という結論に至り、時間的な制約から撤退を選択
● ご参考）エンジニアニメ で発表した
わたしこそが、無知で、無邪気な、タコピーだった - Speaker Deck
（4/11に劇場版もあるよ！まどマギとEMネタで登壇するよ！）
8
Slide 9
Slide 9 text
気づき
Slide 10
Slide 10 text
レガシーの本質は「モデルのずれ」
現場再経験と越境学習による気づき: 学んだこと
● 構造とは 複数要素間の関係（グラフ構造）
● ビジネスにも 組織にも システムにも 構造を見出せる
● 世の中のすべては概念化され、構造化される
10
● 例外はない / すべては全体の一部
● こうした「構造化思考」によって複雑な事象を要素に分解・関係性を紐解くことで、
理解し得るサイズにまで噛み砕くことができる
Slide 11
Slide 11 text
レガシーの本質は「モデルのずれ」
現場再経験と越境学習による気づき: 学んだこと
● ヒトは自身の内部にある
メンタルモデル を通じて現実を見ている
● ソフトウェアの構造は現実そのものではない
ヒトの認知(メンタルモデル)がそのまま写像される
● 関係者のメンタルモデルを揃える価値は高い
11
● 同じ概念を持ち、その概念に基づいてソフトウェアを構成できれば誤解を最小化できる
● その点で、イベントストーミングやドメインモデリングは非常に強力な手法
Slide 12
Slide 12 text
レガシーの本質は「モデルのずれ」
現場再経験と越境学習による気づき: 気づいたこと
● アーキテクトに求められるのは
美しい図を描くモデリング能力だけではない
● 異なるメンタルモデルを持つ人々を対話のテーブルに
着かせ、認識を編み上げる ファシリテーション という
ソフトスキルもまた必要となる
12
Slide 13
Slide 13 text
レガシーの本質は「モデルのずれ」
現場再経験と越境学習による気づき: 気づいたこと
● なぜならソフトウェアエンジニアリングにおける
出発点は「相互理解と共有」にあるから
● 対話を通じた
意味づけ(センスメイキング) と 共創のプロセス こそが、
システムの価値（ビジネスインパクト）を最大化する
13
Slide 14
Slide 14 text
レガシーの本質は「モデルのずれ」
だとすると？
システムがレガシー化していくのは (メンテしにくくなるのは)、
ビジネス・システム・チーム・メンバ・技術 の関係 を
適切にデザインできていないから？
(あるいは時と共に適切さが失われていくから？)
14
Slide 15
Slide 15 text
レガシーの本質は「モデルのずれ」
モデルがずれていく瞬間:
● 設計初期はある目的のために用意されたクラス設計やデータ構造も、
度重なる変更の中で
「あのクラスに属性追加して条件で分岐したらいいんじゃない」
「とりあえずそれで」的な安易な判断から無関係な知識が混入していく
● メンバの異動で、複数のチームが1つのシステムの開発に携わり、
互いに調整が必要になる
● 組織変更により組織の責務が変わり、業務の所管が移っても、
ITチーム編成やデータモデルは変更されない
● 新しい事業が立ち上がるが、既存プロセスの派生として対応してしまう
15
Slide 16
Slide 16 text
レガシーの本質は「モデルのずれ」
つまり
問題領域と解決領域が乖離したことを正さず、
関係者の認知や調整でどうにかしようとすることで
モデルの適切さが失われていく
○ 関係者の認知や調整でどうにか:
これはああいう経緯なので、ここ と あそこ を
同時に確認しなければならない的な 本来不必要な認知 (cruft)
16
Slide 17
Slide 17 text
AI時代の
本質
Slide 18
Slide 18 text
AI時代の本質 (か？)
AIは増幅器。だから構造を設計できない組織は破綻する。
● AIはただの「増幅器（Amplifier）」である
○ DORA『State of AI-assisted Software Development 2025』
● 人間前提のプロセスは「破綻」する
○ Thoughtworks『The Future of Software Engineering Retreat』
(2026年2月)
18
Slide 19
Slide 19 text
AI時代の本質 (か？)
AIは増幅器。だから構造を設計できない組織は破綻する。
つまり、属人的なプロセスや、
整理されていないレガシー（負債≒ずれ）を放置したまま
AIを導入すれば、生産性向上どころではなく
「カオスと技術的負債」が暴力的スピードで増幅される
19
Slide 20
Slide 20 text
AI時代の本質 (か？)
AIは増幅器。だから構造を設計できない組織は破綻する。
● 私の観測範囲でもワークスロップをそのまま投げつけられる、
レビュー量が爆増するなどの状況が見られ、他人事とは思えない
● AIによる自律的な開発が本格的に始まる前に何とかしなければ
● AIの恩恵を引き出すためにも、
負債（モデルのずれ）を正さなければならない
● それを 率先してリードすべきはEM を置いて他にいないだろう
20
Slide 21
Slide 21 text
新たな学びと
外部環境からの
示唆
Slide 22
Slide 22 text
前職では
● メンバが仕事を進めやすい状況を整えることに集中
● 組織の力＝メンバの力の集合と考えていた
（だから メンバの仕事のやり方を変えれば何とかなる
と、安直なことしか考えられなかった？）
22
Slide 23
Slide 23 text
今は何を
つらみの源泉たる モデルのずれ にフォーカス
なぜ ずれ が生じるのか、
どうすれば正せるのか、
正すために必要なものは何か
という視点で
組織を考えるようになった
23
Slide 24
Slide 24 text
是正すべき3つの「モデルのずれ」
● 業務が属人的
○ how領域 のモデルのずれ
○ what/why領域 のモデルのずれ
● 業務とシステムの不整合
○ 組織境界とシステム間 の
モデルのずれ
24
Slide 25
Slide 25 text
25
Slide 26
Slide 26 text
how領域 のモデルのずれ
実装工程の実行主体を ヒト → AI へ (ループを閉じる)
● 「コンテキスト」はヒトに蓄積するだけではなく、
自律エージェントの知識としても蓄える
● 単に蓄えるだけでなく、自律して
評価をpassし、基準を満たす評価関数として実装する
○ 外部品質の基準(自動テスト) - validation
○ 内部品質の基準(レビュー) - verification
26
Slide 27
Slide 27 text
27
Slide 28
Slide 28 text
what/why領域 のモデルのずれ
要求を整合させる・価値あるものを創る
● 要求の3階層を意識する
○ ステークホルダ要求 / ビジネス要求 / ソリューション要求
● Easy vs Simple 問題
● AIの生成物の品質を測るにはヒトのスキルが必要
○ コード: エンジニア
○ 要求: ビジネスアナリスト（プロダクトマネージャ）
28
Slide 29
Slide 29 text
29
Slide 30
Slide 30 text
組織境界とシステム間 のモデルのずれ
メンタルモデルをすり合わせる・分割統治する
● 業務プロセスと構造 を把握する
システムプロセスと構造 を一致させる
● 境界を見極め、モジュールとして切り出す
● モジュール間のインタフェースを決め、
他の知識を隠ぺいする
● とにかく思いついたら図にして共有する
30
Slide 31
Slide 31 text
変化はEM次第？
アーキテクト時代から取り組んできた
○ 当時は「こうしたら良くない？」と
組織の外から提言するだけだった
○ 組織・チームの目標に据えられなければ
「余力(興味)で進める」な位置づけから逃れられない
EMが本気で取り組まなければ変革の速度は上がらない
技術も人も文化も。
31
Slide 32
Slide 32 text
EMは
ビジネス・システム・チーム・技術の関係(構造)をデザインせよ
● 属人的でその場しのぎの対応を止めさせよ
（モデルのずれを拡大させない）
● 負債を放置してAIで新しいシステムをつくるのを止めさせよ
（モデルのずれを放置しない）
● 組織が / チームが 優先して取り組むべき課題:
組織設計とプロセス設計を後回しにするのを止めよ
（EMがリードして真の課題と向き合う）
32
Slide 33
Slide 33 text
33
Slide 34
Slide 34 text
34
Slide 35
Slide 35 text
まとめ
Slide 36
Slide 36 text
36
Slide 37
Slide 37 text
EMよ、私は帰ってきた
挫折と越境を経て、私は 今このタイミング で
エンジニアリング組織をリードするロールに帰ってきた
まさに 変化のど真ん中 で、
こんなに大きなチャレンジができることに感謝している
37
Slide 38
Slide 38 text
かつて私は
受肉した技術的負債に圧倒されるチームを
どうすることもできなかった
再び同じ壁の前に立っている
当時とは景色が違って見える
それは、いくつかの 新しい視点や考え方 を得られたから
38
Slide 39
Slide 39 text
変化は速くて大きい
これまで何度も同じことがあった？
とか言いますけども
少なくとも、私史上最大の波なのは間違いない
この変化を楽しみましょう
こうして模索し続ける我々なら、きっと
新しい何か（チーム？自分？プロセス？）を掴めるはず
39
Slide 40
Slide 40 text
ありがとうございました