---
title: チームの開発スキルは現実の世界の変化に先行しなければばらない
tags: 
author: [miso_taku](https://convert.docswell.com/user/miso_taku)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/V7PPLXPX78.jpg?width=480
description: 俺の忘年会2025LT資料
published: December 18, 25
canonical: https://convert.docswell.com/s/miso_taku/59MX1P-2025-12-18-192445
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/V7PPLXPX78.jpg)

チームの技術スキルは現実の世界の変
化より先行しなければならない


# Page. 2

![Page Image](https://bcdn.docswell.com/page/2JV2QL23JQ.jpg)

お前、誰よ？


# Page. 3

![Page Image](https://bcdn.docswell.com/page/5EGRWXRYJL.jpg)



# Page. 4

![Page Image](https://bcdn.docswell.com/page/4JQV38V67P.jpg)

このLTに至った経緯
増田さん(ドメイン駆動設計、アーキテクチャの達人)と市谷さん
(仮説検証型アジャイルの達人)の対談の中での増田さんの言葉が
今日のLTのタイトルです。


# Page. 5

![Page Image](https://bcdn.docswell.com/page/K74M12MMJ1.jpg)

この言葉を聞いて、どうしてもこの言葉でLTしてみた
くなっちゃったんで話します。
本来、このタイトルで登壇が許されるのは、それこそ
増田さん、市谷さん、t_wadaさん、ミノ駆動さんのよ
うなソフトウェア開発の達人の方々がするべきだと思
いますが、私が話します。
そして、そんな私の無謀な発表を許してくれる、「俺
の勉強会」の懐の深さに感謝です。


# Page. 6

![Page Image](https://bcdn.docswell.com/page/LJ18GM8YEG.jpg)

というわけで、本編に入ります


# Page. 7

![Page Image](https://bcdn.docswell.com/page/GJWZK3Z1J2.jpg)

AIで“作れる”が増えた結果、運用と判断が
追いつかない。便利になったはずなのに、
なぜ現場は苦しいままなのか？


# Page. 8

![Page Image](https://bcdn.docswell.com/page/4EZ1ZV1X73.jpg)

よくあるパターン①
開発の速度が上がるほど、運用・レビュー・意
思決定がボトルネックになる


# Page. 9

![Page Image](https://bcdn.docswell.com/page/Y76LZ5LPJV.jpg)

よくあるパターン②
競合追従で変更が積み上がり、技術負債と
調整コストが増える


# Page. 10

![Page Image](https://bcdn.docswell.com/page/G751WY1PE4.jpg)

課題の本質
変化に対する追従では永遠に後手に回る


# Page. 11

![Page Image](https://bcdn.docswell.com/page/9J21QG1Z7R.jpg)

今日の提案
変化に先行できる「3層の技術スキル」を
チームで手に入れる


# Page. 12

![Page Image](https://bcdn.docswell.com/page/DEYZWVZN7M.jpg)

なぜ追従が辛くなるのか？原因は“同じプロダ
クトに複数の期待が同時に乗る”ことです


# Page. 13

![Page Image](https://bcdn.docswell.com/page/VJN39M3VJ8.jpg)

変化の根源はソフトウェアの「期待の多様さ」
ステークホルダー毎に期待することが異なる
経営者・・・事業成果、コスト削減、競合に対する優位性
利用者・・・便利な機能、使いやすさ、反応の早さ
開発者・・・保守性、拡張性、技術負債の返済
運用者・・・安定性、監視性、セキュリティ
それぞれが「正しい期待」を持っていて、互いに矛盾する
期待が増えるほど“正解”は一つではなくなり、トレードオフ判
断と調整が増える。結果、優先順位が揺れて“変更”が常態化す
る。


# Page. 14

![Page Image](https://bcdn.docswell.com/page/YE992N9VE3.jpg)

AIによって変化は加速する
AIで「学習ループが回りすぎる」ことで変化が加速
• AIで作る→試す が速くなる（試作が増える）
• 試せるから意見が増える（要望・改善点が増える）
• 意見が増えるから仕様が揺れる（優先順位が動く）
• 仕様が揺れるからまた試作（ループが加速）
変化が“イベント”じゃなく“平常運転”になる


# Page. 15

![Page Image](https://bcdn.docswell.com/page/GE895K947D.jpg)

変化とどう向き合うか？
「変化」を避けるものとして受動的に捉えるとリスク
になる。しかし「変化」を先に掴んで能動的に動けば、
チャンスに変えられる。


# Page. 16

![Page Image](https://bcdn.docswell.com/page/LELWYZWVJR.jpg)

変化を先に掴むには？
変化に先行できる技術スキルを身に着ける必要がある。


# Page. 17

![Page Image](https://bcdn.docswell.com/page/4JM9NV9NEW.jpg)

変化に先行するための３層の技術スキル
キー概念
目的
必要スキル
観察・理解 ドメインリテラ
シー
現実の変化を “技術以前” ドメイン分析力
の段階で正しく理解する システム思考
仮説検証力
観察・ヒアリング技術
設計・表現 モデリング能力
現実を抽象化し、変化を モデリングスキル(DDD)
吸収しやすい形に「モデ 抽象化・分割スキル
ル化」する
アーキテクチャ設計
パターン知識
実装・適応 適応能力
設計を現実に反映し、変 TDD
化を受け入れやすいコー CI/CD・自動テスト
ドを保つ
リファクタリング
DevOps・IaC


# Page. 18

![Page Image](https://bcdn.docswell.com/page/PJRGD2G4E9.jpg)

この3層の技術スキルで欠けているもの
があると現実の変化に対応できない


# Page. 19

![Page Image](https://bcdn.docswell.com/page/PEXX1DXZEX.jpg)

だから、個人ではなくチームで手に入れる


# Page. 20

![Page Image](https://bcdn.docswell.com/page/3EKW2XWVED.jpg)

3層の技術スキルをチームで担う
担当・中心人物
役割
観察・理解 プロダクトマネジャー 現実世界の変化（市場・業務・顧客行動）を
UXリサーチャー
いち早く察知し、「何が・なぜ変わったのか」
ドメインエキスパート という問いに変換する
設計・表現 テックリード
アーキテクト
シニアエンジニア
現実の変化を設計上のモデルや責務分離に落
とし込み、ドメインモデルやサービス設計を
通じて、変化を局所化できる構造をつくる
実装・適応 開発エンジニア
QAエンジニア
DevOpsエンジニア
設計されたモデルを安全・迅速に実装・デプ
ロイし、変更を安全に検証し、品質を担保す
る


# Page. 21

![Page Image](https://bcdn.docswell.com/page/L73145WQJ5.jpg)

まとめ
• 変化は期待の多様さから生まれ、AIで加速した
• その変化を能動的に動けばチャンスにできる
• そのためにチームで3層の技術スキルを身に着けよう


# Page. 22

![Page Image](https://bcdn.docswell.com/page/87DXQDKWEG.jpg)

受け身の変化はリスク。しかし、チームで
取りに行けばチャンスになる。


