計画は実行されてこそ意味がある。でも、計画がそもそも誤っていたら？そう。計画とは常に不完全なものだ。不完全な中スタートを切らなければならないのだ。だから、「いかに実行していくのか」が結局のところは鍵を握ることになる。
実行が上手くいかない理由は二つ。①想定外の課題が発生する②想定していた時間で対処できない、だ。これらを計画の問題と考えることももちろんできるが、事前に検討できる範囲には限界がある前提で考えると、実行の問題であるとも言える。
どこからが計画の問題でどこからが実行の問題なのか、という切り分けは非常に難しいポイントであり、このあたりは管理する立場と現場の人たちでしばしば意見は対立するはずだ。計画を立てる側からすればそのぐらいは柔軟に対応してくれ、と思うし、実行する側からすれば、計画時に取り込んでくれよ、と思う。最適解は見つからない。
だからこそ、定期的に再計画をするプロセスが重要である。結局、計画通りに終わらないことをいつまでも実行する側のせいにしてはいけない。スケジュールを伸ばすなり、要員を追加するなどの対策をする必要がある。こういった対策を取らずに、つまり実行する側に対してやれるはずだ、という勝手な理想を押し付けて盲信しているとその時点でデスマーチは始まることになる。
ただし、一般的なプロジェクトではおそらく、再計画するというのは当たり前に行われているはず。しかし、これでも問題が収束しない場合は何が原因か。ここで第三の要因が登場する。
それが、
③品質
である。
全ての仕事には品質がある。例えば、「設計書を作成する」という仕事。設計書に求められる品質とは、仕様が正しく反映されていること、設計書を読むプログラマーが実装できること、などの基準がある。
たとえ、計画通りに設計書が完成したとしても、その設計書をもとにプログラムの作成が進められないのであれば、それは品質を満たせていないため、設計書の書き直しという手戻りが発生する。
つまり、品質が悪いというのは、実は仕事が終わっていない、ということと同義なのだ。
本来であれば、作業計画を立てる時に必要な時間だけではなく、求められる品質水準というものを全て立てておくべきなのだが、そこまで計画策定を綿密に行う猶予は与えられないし、この辺りを厳密に定義するのは現実的ではないため、ある程度のその仕事をした人たちの感覚に依存するケースが多い。
結果的に、品質計画に対する乖離は可視化されづらく、実際に品質が悪いことが露見するまでは”オンスケ状態”に見えてしまうのだ。
大幅な要因追加やリスケが頻繁に発生するプロジェクトはだいたいの場合、品質管理が甘く、仕事を進めるとすぐに品質不良による問題が発生する。試験後半に差し迫って、「そこは設計できていません」とか、「そこはまだ方針が固まっていません」とか、そんなリスクが常につきまとうからいつまでたっても計画通りに進まない。
現場は遅れが発生していないように報告したい手前上、品質を落とすことで進捗をでっち上げるという手法に走りがちである。ただし、繰り返しになるが、「品質を落とす」、ということは「進捗が遅れている」のと同じである。
管理する立場にある人はこのあたりをちゃんと考慮しなければならないが、管理する人も忙しいと、「オンスケです」という報告を楽観的に信じてしまう傾向にある。あるいは進捗の遅れが見えている場合は、直接見えている進捗の遅れにのみ対応できる要因調達を考えるのだ。
デスマーチプロジェクトの場合、忙しいので、品質管理が必ず雑になる。大きめのプロジェクトの場合、品質管理部門を専属に立てて、品質強化施策を実施することも多いが、これも私は懐疑的だ。
管理部門は原因分析や対策方針を立てるまではできるが、結局のところはスキル的に現場の人間にしか品質強化のための作業は実施できない。現場が忙しい状態のままこんなことをしても、品質管理施策自体の品質が悪く、大した品質向上効果が得られなかったり、品質管理自体は正しく行われていたとしても、並行して実施している作業の品質が悪くなるなど、モグラ叩き状態で根本的解決に至らないことも多い。
だが、顧客や上層部向けに受けがいいのだろう。品質が悪いことを受けて、こんな品質強化施策を打ちました、その結果これだけのバグが見つかりました、という報告を聞けば安心するからだろうか、こういった茶番は通例となっている。
さて、様々な角度からデスマーチが起こる原因を考えてきたけれど、ポイントとなるのはやはり「品質」で「上位の人たちに現状を正直に言えないこと」もしくは「現場の作業品質レベルを見抜けない管理職」が原因となっているというが私の結論だ。
今のプロジェクト、品質が悪いな、と思っている人はデスマーチがこれから始まる覚悟をした方がいいかもしれない。
