途中変更による失敗

樹木構造（ツリー構造）組織では、役割分担を明確に行っているがゆえに生じる問題です。これは人的な組織だけでなく、成果物の構成などでも同じことが言えます。

社会に出てしまうと、外的条件の変化などによっていったん取り決めた企画や計画や設計を途中で変更せざるを得ない場合があります。

これは仕方のないことですし、そうなることが自然だと思ってまず間違いないでしょう。

　『昨日正しかったことが今日も正しいとは限らない』

のですから。

このとき気をつけなければいけないのは、

　「なにをどう変えたか」

という情報を組織全体で共有することなのですが、これはなかなか困難なのです。先に述べたように、組織上は別の系統でも、その部品と部品のあいだに密接なリンクがあることはよくあります。

ところが、樹木構造組織のなかでは部署間の情報伝達が不十分な場合が多く、圧倒的に「情報断絶」を起こしやすい側面を持っています。結果として、改良のための変更だったのに、失敗となって現れることになります。

この途中変更による問題は、生産現場の失敗はほとんどこれによって生じるといえます。これは『組織』と言う大枠だけでなく、プロジェクトの担当ごとにも言えることです。

たとえば、自分の担当箇所に発生した仕様変更。

ざっと見たところ、周囲に影響は無さそうと判断したため、あえて「情報展開」をしない、と判断することもあるでしょう。しかし、自身がプロジェクトの、あるいは成果物の全ての情報パスを熟知しているわけではありません。

結果的に、自身が知らない「見えないリンク」によって、他者に迷惑が掛かってしまうこともあるかも知れません。普通はそうあるのが当然ですし、そう考えます。

けれども、勝手に判断した結果、情報連携…すなわち『連絡』を怠るのです。失敗の多くの原因となりつつある「情報断絶」は、要するにただの報連相不備が原因と言うことなのです。

こういった問題は、若手はもちろん、中堅やベテランでもよく起こします。

むしろ色々なことを吸収しなければならないと言う状況に置かれている若手よりも、自分の考え方ややり方が固定化されてしまっている中堅やベテランの方がよっぽど悪質と言えるでしょう。

途中変更によって起きる失敗を防ぐためには、作業に取りかかる前に、

すべての情報を盛り込んだ「最終計画」を作り、
組織全体がそれを共有し、すべてそれに従って進める

というやり方が理想的なのです。これはPMBOKの根源的な思想でもあります。機械設計や建築設計では、あいまいな部分を残さず必ずそれを最終計画書として表現します。

そして途中変更をせざるを得ない場合は、「最終計画」を書き直します。つまり、

　「最終計画」を常に「最終」にしておくこと

が肝心なのです。
これは、情報断絶があいまいさのままにものごとが進んでいるときや、ものごとを見切り発車したときによく起きて、それが失敗につながることが多いためです。

しかし、ソフトウェア開発の世界では、なぜか逆のことを考える人がいます。

「仕様が決まっていないから、計画が立てられない。
　どうせ計画を立ててもすぐにコロコロ変わって意味がなくなる。
　だから計画を立てずに進めるしかない」

という考え方です。

「計画」が無い…すなわち、無計画で挑もうとするのです。建築であれば100%不良物件になるであろう想像がつきますが、ソフトウェアに限っては何故かそれでうまくいくと思っている風潮があります。

計画は、常に「最終」でなければなりません。

　「最終」＝「最新」

です。

現時点で揃っている最新の情報から、最善の計画を立てるのがマネージャーの仕事です。そのあとで情報が小出しに出てきたり、変更されたりしたら、その内容にあわせて常に最新の計画に改めなおすのが仕事です。

最新の情報を収集するには、プロジェクトの監視…すなわち定期的な『覗き込み（モニタリング）』を行えばいいのです。

仕様が決まっていないなら、決まっている部分だけでも。
仕様が決まっていないなら、いつまでに決めるべきかを。
仕様が決まったら、計画への影響を見直せばいいだけで、
見直した結果、新しい計画ができたら、それを「最終計画」にするだけの話です。

しかし、それをしません。

だから変更があった際に情報の断絶が発生し、失敗予測ができず最後になってから困ったことになるのです。