組織・文化・技術の壁に挫折したEMが アーキテクトとして「構造化思考」を手に 再び保守開発組織の変革に取り組む

2026.3.4 EMConf

Transcript

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