会議で「根本的な課題は○○だ」と言い切られるのに、次のアクションが決まらないまま終わる。

企画書に立派な改善策が並ぶのに、半年後に「まだ検討中」になっている。

これはよくある組織の風景ですが、原因は人の問題ではなく構造的な問題です。

この「診断は大きく、処方は粗く、実装は見えない」という構造を解剖し、実務で即使えるように提示します。

なぜ「わかった気がするのに何も進まない」のか

問題解決には本来4つの段階があります。

多くのプロジェクト会議では 1と3だけが行われます。

「レガシーシステムの技術的負債が問題だ（定義）→ だからフルリプレイスすべき（解決策）」

2（なぜ今その負債が生じているか・本当の原因）と4（誰がいつどの順で動かすか）が抜けているため、「重要性の確認だけが残って実行が始まらない」状態になります。

事例が統合されない理由

会議でよくあるパターンです。

事例が出るたびに「でもうちは違う」で流れ、結果として事例は反証にも根拠にもならず、その場の話題として消費されるだけになります。

これは事例の使い方が間違っています。事例を議論に統合するには 「この事例から何の条件を抽出するか」 が必要です。

問題が大きいこと自体は悪くありません。処理単位が大きすぎることが悪いのです。

大きな問題をそのまま扱うと：

問題を「小さくする」とは、以下の4条件を満たすことです。

「組織連携が悪い」という大きな問題をこの4条件で落とすと

組織連携が悪い（大きすぎ）
　↓
営業から開発への依頼仕様に抜け漏れが多い（分解）
　↓
月に何件手戻りが発生しているか（観測可能）
　↓
依頼テンプレートを統一する（担当可能）
　↓
2週間後に再作業件数が減るか見る（期限つき）

ここまで落として初めて「仕事になる」のです。

プロジェクト提案には2つのパターンがあります。

ビジョンを先に立てて事例を補強に使います。

「システムをモダン化すべき」（ビジョン）
　→ 事例を探して補強
　→「でもうちは違う」で崩される
　→ 数字が出せないまま
　→ 検討中のまま終了

現実から始めて条件を絞っていきます。

事例を大量収集（20〜50件規模）
　↓
企業規模・技術スタック・組織体制・対象領域・結果で分類
　↓
自社に当てはまる条件の事例だけに絞る
　↓
残った事例だけで自社向け設計を行う
　↓
反論を「この条件がうちに当てはまらない理由を言え」に転換

出発点が「自分のビジョン」か「現実」かの違いで、議論の主導権が変わります。

前に進む人は次の2つを両立しています。

会議や企画のたびにこれだけ確認すれば変わります。

「診断は大きく、処方は粗く、実装は見えない」という構造は、プロジェクトマネジメントの問題ではなく思考の設計の問題です。

大きな問いを持ちながら、最初の一手を小さく切る。この2つを両立するだけで、組織の動き方は変わります。