システム思考

システム思考とは

解決したい課題を1つのシステム（系）として捉え、系の理解と課題の解決を目指す思考法
課題を1つのシステム（系）として捉えることで、課題の全体像を把握することを目指す
システム（系）を俯瞰的に捉えることで表象的な事象に留まらない、課題とそれをとりまくシステム（系）の背景や複雑な要因まで含めた理解が可能になる

分析プロセス

ステップ1: 問題の言語化

紙に書き出す:
- 今、何が問題か？（例: リリース遅延が常態化）
- 何が増えているか？（技術的負債、バグ、作業時間）
- 何が減っているか？（チームのモチベーション、品質）

ステップ2: 因果関係の連鎖を追う

「なぜそうなったか？」を3-5回繰り返す
循環（ループ）を探す
時間遅延を意識する（3ヶ月前の決定が今影響している）

ステップ3: データで検証（必要に応じて）

Gitメトリクス（コミット頻度、ファイル変更頻度）
Jiraのバグチケット推移
CI/CDのビルド時間
PRのレビュー時間
デプロイ頻度

ステップ4: 介入ポイントを見つける

悪循環を断ち切る場所を特定:
- レバレッジが高い場所（小さな変更で大きな効果）
- すぐに実行可能な場所

Appendix-1 ソフトウェア開発における具体的な適用例

パターン1: 技術的負債の雪だるま

技術的負債が多い
→ コード変更に時間がかかる
→ 納期に間に合わせるため、さらに手抜き実装
→ 技術的負債がさらに増加
→ （ループ）

パターン2: バグ修正の罠

バグが多い
→ バグ修正に追われる
→ テストコードを書く時間がない
→ 新しいバグが入りやすくなる
→ バグがさらに増える
→ （ループ）

パターン3: ブルックスの法則（人月の神話）

プロジェクトが遅れている
→ 人を追加する
→ 既存メンバーが新人教育に時間を取られる
→ 開発速度が一時的に落ちる
→ さらに遅れる
→ （ループ）

パターン4: 過度な最適化

パフォーマンス問題が発生
→ 複雑な最適化を実装
→ コードの可読性・保守性が低下
→ バグが増える、変更コストが上がる
→ 長期的には開発速度が低下
→ （悪循環）