やることだけを見える化しているとトラブルの原因を可視化し忘れる

プロジェクトを回していて、思うように進捗できていないと相談を受けて話をよくよく聞くと、一方向でしか作業を見ていないということに気づかされることが多いいのです。

まあ、第三者の視点で見られるので、この点はどうなのとかそっちから見たらどうなのというように他人事で巻き込まれていないからこそ、頭の中にある経験知を引っ張り出す余裕が持っているから、なのですけれど。

何事も余裕がないと打つ手にはろくなことがなくなってしまうのは世の常、なのですが。

例えばどのようなことが起きるか。

作業をする前には、次のような工程があります。

普通ですよね。標準的というか。ここまでガイドされたらうまくいかない理由がわかりません。

でも、現実には上記のように作業項目を列挙して、その通りにやったとしてもうまくいかない方が多いのです。

それぞれの作業項目ごとに幾らでも上手くいかない原因は潜在しています。更に言えば、これらの潜在している上手くいかない原因の他にも、これだけ上手くいかない原因を可視化したはずなのに、まだ見えていないことがあるのです。

さて、何が見えていないか挙げられますか。

仮に、上記で列挙した作業項目とそれが上手くいかなくなる原因まで対処できたとしても、思うように終わらせることができない原因がまだあります。

逆の見方をしてみましょう。仕様は揃った。作業も具体化できた。必要なリソースも確保できた。とすると、あとは進捗をモニタリングしていれば、問題なさそうです。

でも、それでも上手くいかなくなるかもしれない。

どうしてそのようなことが起きるのか。

それは、前述した作業の列挙では可視化されていない別の指標があるからです。それは、負荷です。

ええっと思ったかもしれないですが、これって無意識に頑張るとかやり切るとか言ってしまう、精神論的な行動を取りやすい指標なのです。この負荷も何が原因で負荷がある状態になるかは想像がつくと思います。

原因は、見積もりとリソースでの較差と必要とするスキルと充足されたスキルのギャップなど、上述した作業項目が絡み合って一旦、負荷という状態に変遷し、更に進捗が遅れる、などの事象に変化するのです。

こうした事象の変遷を解きほぐしもせずに見えている事象だけを短絡的に解決しようとすると、実は一つも二つも先に本当の原因があった、ということに気づくことができないのです。

これを不十分な可視化、見える化と呼ぶのです。