Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
システム思考で問題に対処する
Search
yussak
August 06, 2026
Technology
660
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
500
レガシーコード改善のために取り組んでいること
yussak
0
66
Other Decks in Technology
See All in Technology
SREでアラート疲れを 解決しよう!
kairim0
1
190
2026-10-01_MagicPod_QAハーネスエンジニアリングとQA組織の未来像
ynisqa1988
1
520
[2026 Oracle Technical Deep Dive] Apache Iceberg × Oracle AI Database -Oracle Autonomous AI Lakehouseが実現するAI時代のデータ基盤- (2026年9月17日開催)
oracle4engineer
PRO
0
110
【データ横丁主催】AI Agentがコンテキストを使って仕事をした後、何が残るのか― 組織の経験を次の判断に引き継ぐ「Agent Memory」
shisyu_gaku
2
330
形式手法を使って仕様をコーディングしよう
mikanichinose
0
180
予測不能な実行エージェントを安全にサクッと試せるサンドボックス環境の話
sansantech
PRO
0
120
AI時代に必要な脅威モデリング― 変化の速度に負けない理解とリスク判断
masakane55
4
910
ミイダス株式会社 テックチームのご紹介 / MIIDAS Tech Team
miidas
0
150
Snowflake Horizon Catalog と Apache Iceberg で作る オープンなデータ基盤
kitagawaz
0
440
カンファレンスに参加した後の浮遊感とセルフケア
pauli
0
310
営業オントロジーの作り方と、エージェントからの辿り方 ── ナレッジワークの現場から
kworkdev
PRO
1
260
1万名の社員が使う認証基盤で どう信頼性を担保するか?
kairim0
0
210
Featured
See All Featured
Designing Dashboards & Data Visualisations in Web Apps
destraynor
232
55k
Optimising Largest Contentful Paint
csswizardry
37
4k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
25
2.1k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.8k
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
610
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
1
620
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
450
The Curse of the Amulet
leimatthew05
3
15k
Git: the NoSQL Database
bkeepers
PRO
433
67k
SEO Brein meetup: CTRL+C is not how to scale international SEO
lindahogenes
2
2.9k
The Curious Case for Waylosing
cassininazir
1
550
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