システム思考で問題に対処する 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