Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
システム思考で問題に対処する
Search
yussak
August 06, 2026
Technology
420
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
システム思考で問題に対処する
2026/8/7 @ 多摩.dev #4 ~真夏のLT祭り~
yussak
August 06, 2026
More Decks by yussak
See All by yussak
Web エンジニアなのでブラウザを作ってみた!
yussak
0
450
レガシーコード改善のために取り組んでいること
yussak
0
64
Other Decks in Technology
See All in Technology
Master Dataグループ紹介資料
sansan33
PRO
1
4.8k
AI駆動開発はどこまで来たのか? ファインディの最新実態調査で読み解く現在地 Devin Con Tokyo
akiratom
1
910
Kiro WebとCloud Sessions
nagisa53
2
200
コミュニティから始まった農業IoTとの7年間 ——人との関わりが教えてくれたこと
peacemaker07
0
110
長期運営で肥大化したExcelマスターデータの解消に向けた移行事例
gree_tech
PRO
0
510
国家プロジェクトを支える「さくらONE」 大規模LLM開発におけるGPU障害を乗り越えるクラスター運用戦略
gpuunite_official
0
280
MCPを待つな、パスキーを拡げよう(OAuth/OIDC Numa (Immersion) Workshop 2026)
oidfj
PRO
0
260
:syncing_time:
sksat
2
750
Introduction to Bill One Development Engineer
sansan33
PRO
0
470
Oracle MCP Servers Explained
thatjeffsmith
1
500
型落ちシンクライアント端末のPoEモジュールを自作したかった話
logica0419
0
440
AI駆動開発を組織で促すために
lycorptech_jp
PRO
1
290
Featured
See All Featured
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
0
580
Test your architecture with Archunit
thirion
2
2.4k
Getting science done with accelerated Python computing platforms
jacobtomlinson
2
450
Side Projects
sachag
455
43k
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
68
57k
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
870
16th Malabo Montpellier Forum Presentation
akademiya2063
PRO
0
360
Tell your own story through comics
letsgokoyo
1
1k
Reality Check: Gamification 10 Years Later
codingconduct
0
2.3k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
28
3.6k
Effective software design: The role of men in debugging patriarchy in IT @ Voxxed Days AMS
baasie
0
480
Money Talks: Using Revenue to Get Sh*t Done
nikkihalliwell
0
470
Transcript
システム思考で問題に対処する yussak 2026/8/7 @ 多摩.dev #4 ~真夏のLT祭り~ 1
多摩.dev #4 開催おめでとうございます! 2
自己紹介 X: @yussak213 事業会社のWebエンジニア アジャイル、プロダクトマネジメントも興 味あり 趣味はボドゲ、相撲観戦 推しは藤ノ川関 最近アヴァロンが面白かった マイブームはed25519の自作
3
システム思考を学んでいる理由 問題にその場しのぎではなく根本対処をしたいと思ったから ※学んでいる最中のため、間違いなどありましたら指摘いただけますと幸いです 4
目次 1. システム思考とは何か 2. システム思考で得られること/得られないこと 3. システム思考で問題に対処するステップ 4. やってみる 5.
まとめ 5
システム思考とは何か 物事を単独でなく、要素同士の影響をシステムとして捉える考え方 構造、因果関係、時間的変化、フィードバックループ 生態系、太陽系のようなシステム 6
システム思考で得られること/得られないこと 7
得られること レバレッジポイントが見つかる 介入によって全体に大きな影響を与えられる箇所のこと 構造やループなどを理解することで「どこに介入すべきか」がわかるように なる 8
得られないこと 何をすべきか考えるには別のスキルが必要 早い馬ではなく車を作れるか 先にチームでTidy Firstの話をしておくか など 9
システム思考で問題に対処するステップ 1. 問題・対象・望む状態を定める 2. 振る舞いを観察する 3. 要素とつながりを書き出す 4. ループと時間的変化を見る 5.
レバレッジポイントを探す 6. 介入を試し、観察して見直す 10
やってみる テーマ:「プロダクトの既存機能仕様の属人化に対処する」 今回は個人でできる介入に絞る(チームの合意を待たず今日から始められるため) 今回見るシステム:プロダクトの開発・保守が回っている状況全体 仕様、テスト、コード、設計、使用技術、開発者、組織体制など 11
ステップ1 問題・対象・望む状態を定める なぜやるか 何がOKで何がNGかの判断基準がないと、構造を見ても介入先を決められない 例 問題: 既存機能では、仕様が特定の人に依存し、その人に確認しないと安全に変 更できない 対象範囲: プロダクト開発チームの開発プロセス
望む状態: 機能追加が続く中でも、詳しい人が不在で安全に変更できる 12
ステップ2 振る舞いを観察する なぜやるか 望む状態との違いを生む、繰り返される振る舞いと時間的な変化を捉える やること 日々どんな行動が優先され、どんな結果が繰り返されているか、それが時間とともに どう変化しているかを観察する 例 前ステップの「詳しい人に確認しないと安全に変更できない」に対して何が起き ているか
→ 変更のたびに詳しい人に確認し、確認で得た知識は記録せず当面のタスクを優 先する、が繰り返されている 13
ステップ3 要素とつながりを書き出す なぜやるか 「原因はこれだ」と一つに決めず、問題を生む関係を見えるようにする やること 前ステップの振る舞いを要素に分解し、因果関係でつなげる 例 要素:仕様を知る人の数 / 詳しい人への確認回数
/ 記録・共有の時間 つながり: 仕様を知る人の数が少ない → 詳しい人への確認回数が増える 詳しい人への確認回数が増える → 記録・共有の時間が減る 記録・共有の時間が減る → 仕様を知る人の数が増えない 14
ステップ4 ループと時間的変化を見る なぜやるか どんなループが働いていて、それが時間とともにどう効いてくるかを把握する やること つながりをたどり、結果が原因側に戻る箇所を探す 戻ったときに問題を強めるか、弱めるか、いつ影響が現れるかを見る 例:強化ループ ステップ3の要素をつなげると一周する 記録・共有の時間が取れない
→ 仕様を知る人が増えない → 確認が集中する → 余 裕が減る → 記録・共有の時間が取れない(最初に戻る) 「テストがない → 変更が怖い → 確認が増える」がこのループに合流して加速 15
ステップ5 レバレッジポイントを探す なぜやるか 症状への直接対処だけでなく、循環全体の振る舞いを変えられる場所を探す やること ループの各要素について、そこを変えたときに他の要素へどう波及するかを考える 例 ステップ4のループに合流して加速させている「テストがない → 変更が怖い
→ 確 認が増える」を狙う ここを崩せば確認の集中が減り、余裕が生まれ、記録・共有に時間を回せる 16
ステップ6 介入を試し、観察して見直す なぜやるか 介入仮説を実際の行動に変え、構造が変わるかを確かめる やること 小さく試す行動、観察する変化、見直すタイミングを決める 例 試す:触った周辺のコードを少しずつ改善(ボーイスカウトルール)。設計改善や テスト追加が積み上がり、ループが弱まっていく 観察:改善が習慣になっているか。テストが増えて、変更時の確認頼りが減って
きているかを見る 見直し:変化がなければ、改善の粒度や対象範囲を変える 17
まとめ 問題をシステムとして捉えることで、より効果的な介入先を見つけられる 小さな改善でも、レバレッジポイントへの介入なら好循環を生み、全体の振る舞 いを変えられる 自分のチームでも、コードレビューでRubocopの改善を一行依頼するところ から、テスト増えていったり設計の議論が増えたりといいループができてき ている 18
システム思考を持って物事に当たるエンジニア、システムエンジニ アを目指します 19
ご清聴ありがとうございました! 20