会議で「根本的な課題は○○だ」と言い切られるのに、次のアクションが決まらないまま終わる。
企画書に立派な改善策が並ぶのに、半年後に「まだ検討中」になっている。
これはよくある組織の風景ですが、原因は人の問題ではなく構造的な問題です。
この「診断は大きく、処方は粗く、実装は見えない」という構造を解剖し、実務で即使えるように提示します。
なぜ「わかった気がするのに何も進まない」のか
問題解決には本来4つの段階があります。
- 問題の定義
- 原因の特定
- 解決策の設計
- 実装経路の提示
多くのプロジェクト会議では 1と3だけが行われます。
「レガシーシステムの技術的負債が問題だ（定義）→ だからフルリプレイスすべき（解決策）」
2（なぜ今その負債が生じているか・本当の原因）と4（誰がいつどの順で動かすか）が抜けているため、「重要性の確認だけが残って実行が始まらない」状態になります。
事例が統合されない理由
会議でよくあるパターンです。
- 「A社はマイクロサービス化で成功した → だからうちも移行すべき」
- 「B社は失敗した → でもうちは違うかも」
- 「海外事例がある → でも副作用もある」
事例が出るたびに「でもうちは違う」で流れ、結果として事例は反証にも根拠にもならず、その場の話題として消費されるだけになります。
これは事例の使い方が間違っています。事例を議論に統合するには 「この事例から何の条件を抽出するか」 が必要です。
問題を「小さくする」4条件
問題が大きいこと自体は悪くありません。処理単位が大きすぎることが悪いのです。
大きな問題をそのまま扱うと：
- 論点が増えすぎて本丸が見えなくなる
- 事例や意見が増えるほど決まらなくなる
- 最後に「重要性の確認」だけが残って実行が始まらない
問題を「小さくする」とは、以下の4条件を満たすことです。
| 条件 | 内容 |
|---|---|
| 分解できる | 単一の原因・単一のアクションに落とせる |
| 観測可能 | 変化したかどうか数字で確認できる |
| 担当可能 | 特定の誰かが責任を持って動ける |
| 期限を置ける | 2週間〜1ヶ月以内に検証できる |
実例
「組織連携が悪い」という大きな問題をこの4条件で落とすと
組織連携が悪い（大きすぎ）
↓
営業から開発への依頼仕様に抜け漏れが多い（分解）
↓
月に何件手戻りが発生しているか（観測可能）
↓
依頼テンプレートを統一する（担当可能）
↓
2週間後に再作業件数が減るか見る（期限つき）
ここまで落として初めて「仕事になる」のです。
ビジョン先行 vs 現実先行
プロジェクト提案には2つのパターンがあります。
失敗パターン：ビジョン先行
ビジョンを先に立てて事例を補強に使います。
「システムをモダン化すべき」（ビジョン）
→ 事例を探して補強
→「でもうちは違う」で崩される
→ 数字が出せないまま
→ 検討中のまま終了
成功パターン：現実先行
現実から始めて条件を絞っていきます。
事例を大量収集（20〜50件規模）
↓
企業規模・技術スタック・組織体制・対象領域・結果で分類
↓
自社に当てはまる条件の事例だけに絞る
↓
残った事例だけで自社向け設計を行う
↓
反論を「この条件がうちに当てはまらない理由を言え」に転換
出発点が「自分のビジョン」か「現実」かの違いで、議論の主導権が変わります。
進む人と進まない組織の違い
前に進む人は次の2つを両立しています。
- 大きな問いを持ちながら（Why・戦略的視点を失わない）
- 最初の一手は小さく切る（What・実装可能な単位に落とす）
実務で使う3つの確認
会議や企画のたびにこれだけ確認すれば変わります。
- この問題は今の単位だと大きすぎないか
- 誰が次に何をやるかまで落ちているか
- 2週間から1ヶ月で検証できる単位になっているか
まとめ
| よくある失敗 | 構造的原因 |
|---|---|
| 問題がわかるのに進まない | 原因特定と実装経路が抜けている |
| 事例を出しても決まらない | 条件抽出をせず雰囲気に使っている |
| 提案が「でもうちは違う」で崩される | ビジョン先行で事例を補強に使っている |
| 会議が終わっても誰も動かない | 担当・期限・観測可能な単位になっていない |
「診断は大きく、処方は粗く、実装は見えない」という構造は、プロジェクトマネジメントの問題ではなく思考の設計の問題です。
大きな問いを持ちながら、最初の一手を小さく切る。この2つを両立するだけで、組織の動き方は変わります。