■ムダをなくす ４ （No.281）
プロジェクトの中止の判断をする
一度始まったプロジェクトが止まらない
開発プロジェクトが一旦スタートすると，外部・内部などの環境変化に伴い，それ以上開発を続けてもムリ，或いはムダになってしまうことが起こることが時々ある。しかし，一度開発がスタートしてしまうと，途中で中止することはなかなか容易なことではない。
開発を進めていると，当初予定していたこと以外の変化が生じる。例えば，外部的なものでは，競合が製品を発表し，我々の開発製品以上の性能のものを出したとか，或いは，内部的な変化では，当初予定していた以上の問題が発生し，その壁を乗り越えることが困難となったなど，開発当初に予定した計画が大きくずれ込む，或いは見込み違い（想定外とかたづける人もいるが）の事態に陥ることがある。こうしたとき，素早くプロジェクトの中止の決断をすることは，なかなか難しい。
先ずは，中止してしまうと，開発スタートから進めてきたことがムダになることである。折角ここまで進めてきたのだから，何とか完成するまでやってしまいたい，と云うのは担当している誰しもの気持である。これ以上開発を続行するのはムダなことになると明らかなものは判断ができるが，通常はムダになりそうなことは判っていても，一縷の望みとも云うべき可能性を期待しながら，ズルズル進めて行くことがよくある。つまり，これまでの成果をムダにしたくないとの思いである。
また，プロジェクトの途中で中止すると云うことは，予定外のことで，次にやるべきプロジェクトが目白押しと云うことは少なく，次にやるプロジェクトが直ぐに見つからないことが多い。つまり，中断しても何をやるか決まらず，しばらくの間何もしない状態に陥る。そんなことならば，少しでも今のプロジェクトをやりながら，次のプロジェクトが見つかるまで進めると云うことさえ起こる。要は，動き出したプロジェクトを途中で止めることは大きなエネルギーを必要とし，そのエネルギーを使うなら，そのまま惰性で少しの間続けようとするのである。
途中の中断は，担当者のモチベーションが極端に低下する。つまり，与えられたプロジェクトであっても，一旦みんなでやろうとしたものは，完了させたい思いは誰しも同じである。いろいろな状況変化があっても，それを乗り越えようとするモチベーションがある。ところが，途中で中止などとなれば，折角の努力が水の泡となり，ともすれば自分の評価にも影響するとあれば，モチベーションをそのまま維持することは難しい。
プロジェクトの中止による影響は，以上のようなことだけでは終わらない。とにかく，ムダな時間を費やしてしまったとの後悔は大きい。
サンクコストが諦めきれない
以上のようなプロジェクトの中止に踏み切れない大きな要因にサンクコスト（埋没費用：事業に投下した資金のうち，事業の撤退・縮小を行ったとしても回収できない費用のこと）がある。要するに，これまで開発に掛かった費用が大きいからプロジェクトを中断できないとすることである。
確かにこれまで掛けた費用をムダにすることはできない。しかし，現時点でこれから掛かるであろう費用と，成果として得られるものを比較してどうかを判断することが大切で，前者が大きければ中止であり，後者が大きければ中断せず最後までやるべきである。ここでサンクコストの大きさを気にするようでは，更にムダを増やすことになる。言うのは簡単であるが，なかなか判断にサンクコストを無視してしまうことは難しいことなのである。
決断（判断）できる人がいない
もう一つ，プロジェクトを中止できない理由に，決断できる人がいない場合が多い。プロジェクトを中断することは，これまで掛かった費用をムダにすることを決めることになる。サラリーマンである以上，誰もミスを認めたくない。特に，腹の据わっていない上司の場合，責任をすべて部下に押しつけ，自分は責任を取りたくない態度を取る。即ち，上司としてプロジェクトを中断すべきとの判断を先送りし，結果大きなロスとなったとき，プロジェクトリーダの責任にしてしまうことがある。
確かに，プロジェクトリーダの責任は大きいが，外的要因，内的要因など含めて，プロジェクトをそのまま進めるべきか，中断すべきかを判断するのは，プロジェクトを任せた側の上司の責任も大きい。したがって，中断の判断するのは，プロジェクトリーダではなく，上司側にあることが殆どである。プロジェクトリーダの当事者よりも，上司の方が冷静な判断が下せるのである。
権限だけを持っているが責任を取らないタイプの上司は多い。そんな場合，プロジェクトリーダは冷静な目を持って，一段上の立場でプロジェクトのＧＯ，ＮＯ−ＧＯを判断すべきである。
デザインレビュー時に進捗の判断をする機能を持たせる
上述したように誰も責任を取らない組織は溢れている。しかし，プロジェクトが必ず成功するとは限らない。むしろ，プロジェクト半ばで止めた方がベターと感じている人が殆どでも，誰も言い出さず，判断もせず，先送りして，プロジェクトを最後まで進めてしまい，結論を上手くごまかして，その場を繕ってしまう。お互いにイヤな思いはしたくないと云う仲間意識で，結果的には会社に損失を与えている。
こうしたことが起こらないようにするには，プロジェクトのマイルストーンの節目に，プロジェクトの進捗のＧＯ，ＮＯ−ＧＯを判断する関門を置くべきである。普通一般にはデザインレビューと称して，設計のレビューをするタイミングが，何回か設けられている。もちろん，設計内容の吟味を衆知を集めてすることが一番の目的であるが，その会議の責任者にプロジェクトをそのまま進めるべきか，中断すべきかの判断をしてもらう仕組みを作っておくのが良い。
但し，この関門の縛りをきつくすると，本来のデザインレビューの主旨から外れ，この関門をパスすることが狙いになって，折角の衆知を集めて設計レビューする目的が失われてしまうことがあるので要注意ではあるが，仕組みにプロジェクトのＧＯ，ＮＯ−ＧＯを判断する機会を設けて置くと，意外と個人の責任にされることは少なくなり，正しい判断が組織としてできるようになる。ムダをなくす一つの手段で，効果的なものである。
（続く）
プロジェクトの中断は誰しも責任を取りたくない，それを仕組みでカバーしよう
[Reported by H.Nishimura 2012.07.30]
Copyright (C)2012 Hitoshi Nishimura
