その会議、ポインタしか動いていません。

問題は解決されず放置されることがある。
C言語風に書くとこうなる。問題ポインタだけが書き換えられる。
納期遅れが起きたとする。

C言語風に書けば、最初の参照先はこうである。
Problem *problem = &delivery_delay;

本来やるべきことは単純だ。
solve(problem);

納期遅れの原因を調べる。工程を確認する。誰がどこで詰まっているのかを見る。仕様変更があったのか、見積もりが甘かったのか、承認待ちが長かったのか、リソースが足りなかったのかを確認する。

ところが
problem = &communication;
本当の問題はコミュニケーション不足だ。」

次にこうなる。
problem=&ownership;「いや、当事者意識が足りない。」

さらにこうなる。
problem=&culture;
「結局、組織文化の問題だ。」

言っていることは、全部それらしく聞こえる。
しかし、最初の納期遅れは解決していない。
delivery_delay.fixed == false;

参照先だけが変わったのである。
遅刻でも同じことが起きる。

ある社員が毎週のように遅刻する。

本来は、まず事実を見る。
check(problem);
何曜日に多いのか。何分遅れるのか。通勤経路の問題か。夜勤明けか。家庭事情か。本人の時間管理か。勤務開始時刻の設計に無理があるのか。

ところが、ここでも参照先変更コマンドが走る。

problem = &motivation;「やる気の問題」
problem = &generation_gap;「Z世代は難しい」
problem = &discipline;「規律が大事だ」

しかし、遅刻の実態はまだ残っている。
late_arrival.fixed == false;

これは問題解決ではない。問題の参照先を変更しただけである。

もちろん、納期遅れの背景にコミュニケーション不足がある場合もある。
遅刻の背景に勤務設計の問題がある場合もある。
その場合は、原因探索として参照先をたどる意味がある。

しかし、根拠を確認せずに、
problem = &another_problem;

を連発すると、組織は問題を処理した気になる。
会議では話した。対策も出した。
もっともらしい言葉も並んだ。

だが、最初の問題オブジェクトは残っている。
問題は解決されずに先送りされることになる。
問題ポインタを書き換えただけだ。

部下も同じである
「納期が遅れたのは仕様が悪いからです。」
「遅刻したのは電車が悪いからです。」

もちろん本当にそういう場合もある。
しかし、確認なしに責任の参照先だけを外へ移すなら、
それも同じ処理である。

組織の中でこれが連発されると、問題は解決されない。

Problem *problem = &delivery_delay;
problem = &communication;
problem = &ownership;
problem = &culture;

/* delivery_delay は誰も処理していない
*/残るのは、未処理の問題オブジェクトと、
書き換えられたポインタだけである。

組織を壊すのは、バグではない。
problem = &another_problem;
を繰り返すことである。

以上