ストーリー
田
田中VPoE
組織横断改善の第一歩は「課題の可視化」だと話した。では具体的に、どうやって組織の課題を構造的に分析するのか。今日はそのフレームワークを学ぶ
あなた
課題は色々あると思うんですが、何から手をつければいいのか悩みます
あ
田
田中VPoE
それが問題なんだ。「デプロイが遅い」「障害が多い」「開発速度が落ちている」…症状はいくらでも出てくる。だが、症状を片っ端から潰しても根本解決にはならない。重要なのは、症状の裏にある構造を見抜くことだ
あなた
症状と原因を区別する、ということですね
あ
田
田中VPoE
その通りだ。そのために使うのが「問題構造分析」のフレームワークだ
問題の3層構造
組織の問題は、「現象」「原因」「構造」の3層で捉えることが重要です。
問題の3層構造:
Layer 1: 現象（Symptoms）
表面に見える問題。誰でも気づける。
例: 「リリースが遅い」「バグが多い」「チーム間の連携が悪い」
Layer 2: 原因（Causes）
現象を引き起こしている直接的な要因。
例: 「テスト不足」「レビュープロセスの非効率」「情報共有の不備」
Layer 3: 構造（Structures）
原因を生み出し続けている組織的・制度的な仕組み。
例: 「評価制度がチーム成果のみ重視」「技術負債を許容する文化」
「部門間のサイロ化を助長する組織構造」「Layer 1を潰しても新しい症状が出てくるだけだ。Layer 3を変えなければ、同じ問題が形を変えて繰り返される」 — 田中VPoE
フレームワーク1: なぜなぜ分析（5 Whys）
トヨタ生産方式で有名な「なぜなぜ分析」を、組織課題に応用します。
基本的な進め方
| ステップ | 内容 |
|---|---|
| 1 | 問題の現象を具体的に定義する |
| 2 | 「なぜそうなっているのか？」を問う |
| 3 | 出てきた答えに対してさらに「なぜ？」を繰り返す |
| 4 | 5回程度繰り返し、構造的な原因に到達する |
| 5 | 構造的原因に対する対策を検討する |
適用例: 「リリース頻度が低下している」
問題: リリース頻度が月4回→月1回に低下
Why 1: なぜリリース頻度が下がったのか？
→ 1回のリリースに含まれる変更が大きくなり、リリース準備に時間がかかるから
Why 2: なぜ1回の変更が大きくなったのか？
→ リリースに必要な承認プロセスが重く、まとめてリリースする方が効率的だから
Why 3: なぜ承認プロセスが重いのか？
→ 半年前の大規模障害後に、CTO承認を必須にするルールが追加されたから
Why 4: なぜCTO承認が必要なのか？
→ 障害の再発防止策として導入されたが、リスク評価基準がなく
すべてのリリースに同じ承認レベルを適用しているから
Why 5: なぜリスク評価基準がないのか？
→ 障害対策は「承認を追加する」という表面的な対策で完了とされ、
リスクベースの判断基準を設計する余裕も担当者もいなかったから
構造的原因:
「障害対策としてプロセスを追加する文化」+
「リスク評価の仕組みの不在」+
「対策の効果検証をしない風土」なぜなぜ分析の注意点
| 注意点 | 説明 |
|---|---|
| 人を責めない | 「○○さんが確認しなかったから」は原因ではない。仕組みの問題を探る |
| 事実ベースで進める | 推測ではなくデータや観察に基づいて分析する |
| 分岐を意識する | 1つの「なぜ」に対して複数の原因がある場合がある |
| 対策可能なレベルで止める | 「景気が悪いから」まで遡っても対策にならない |
フレームワーク2: 因果ループ図
複数の要因が相互に影響し合う複雑な問題を分析するのに有効なフレームワークです。
基本要素
| 要素 | 記号 | 意味 |
|---|---|---|
| 強化ループ | (R) | 変化が同じ方向に加速する（好循環/悪循環） |
| 均衡ループ | (B) | 変化を元に戻そうとする力が働く |
| 遅延 | // | 原因から結果が出るまでに時間差がある |
適用例: 技術負債の悪循環
技術負債の蓄積
↑ ↘
(R) 開発速度の低下
↑ ↓
短期的な 納期プレッシャーの増加
ワークアラウンド ↓
↑ 品質を犠牲にした開発
└──────────────┘
別の均衡ループ（うまく機能していない）:
技術負債の蓄積
↑ ↘
(B) 経営層の認識
↑ ↓ //（遅延）
改善活動の 改善のための
リソース不足 ←── 投資判断の遅れ因果ループ図の作成手順
| ステップ | 内容 |
|---|---|
| 1 | 中心となる問題を配置する |
| 2 | その問題に影響を与える要因を書き出す |
| 3 | 要因間の因果関係を矢印で結ぶ |
| 4 | 強化ループと均衡ループを特定する |
| 5 | 遅延が発生している箇所を特定する |
| 6 | 介入ポイント（レバレッジポイント）を見つける |
フレームワーク3: 制約理論（TOC）
エリヤフ・ゴールドラットが提唱した制約理論を、組織課題の分析に応用します。
基本原則
システム全体のスループットは、最も弱いリンク（制約条件）によって決まる。
ソフトウェア開発のバリューチェーン:
企画 → 設計 → 実装 → レビュー → テスト → デプロイ → 運用
↑
ここがボトルネック
（レビュー待ち平均3日）
ボトルネック以外を改善しても全体のスループットは変わらない:
✕ 実装速度を2倍にする → レビュー待ちが増えるだけ
✕ テスト自動化を進める → レビューを通過するコードが増えない
○ レビュープロセスを改善 → 全体のスループットが向上TOCの5つの集中ステップ
| ステップ | 内容 | 例 |
|---|---|---|
| 1. 制約を特定する | システム全体のボトルネックを見つける | レビュー待ちがボトルネック |
| 2. 制約を徹底活用する | ボトルネックの稼働率を最大化する | レビュアーの会議を減らし、レビュー時間を確保 |
| 3. 他をすべて制約に従属させる | ボトルネック以外はボトルネックのペースに合わせる | 実装チームはレビュー可能な単位で分割してPRを出す |
| 4. 制約を強化する | ボトルネックの能力を向上させる | レビュアーを増やす、AIレビューを導入する |
| 5. 新たな制約を見つける | ボトルネックが解消されたら次の制約を探す | テスト実行時間が新たなボトルネックに |
3つのフレームワークの使い分け
| フレームワーク | 適するケース | 成果物 |
|---|---|---|
| なぜなぜ分析 | 特定の問題の根本原因を深掘りしたい | 根本原因と構造的対策 |
| 因果ループ図 | 複数の問題が絡み合っている | 問題の全体構造と介入ポイント |
| 制約理論（TOC） | 全体のスループットを改善したい | ボトルネックと集中改善計画 |
「3つのフレームワークは排他的ではない。まずTOCでボトルネックを特定し、なぜなぜ分析で深掘りし、因果ループ図で全体像を描く。この組み合わせが強力だ」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|---|
| 3層構造 | 問題を現象・原因・構造の3層で捉え、構造レベルに介入する |
| なぜなぜ分析 | 「なぜ？」を5回繰り返し、根本原因に到達する |
| 因果ループ図 | 要因間の相互作用を可視化し、介入ポイントを見つける |
| 制約理論 | システム全体のボトルネックに集中して改善する |
チェックリスト
- 問題の3層構造（現象・原因・構造）を理解した
- なぜなぜ分析の進め方と注意点を把握した
- 因果ループ図の基本要素と作成手順を理解した
- 制約理論の5つの集中ステップを把握した
- 3つのフレームワークの使い分けを理解した
次のステップへ
次は「バリューストリームマッピング」を学びます。組織全体の価値の流れを可視化し、ムダとボトルネックを発見する手法を身につけましょう。
推定読了時間: 30分