デスマの傾向と対策


日常風景のデスマ
デスマって、ITプロジェクトで品質、コスト、納期、スコープが当初計画から逸脱し、開発チームの労働環境が著しく悪化している状態ですね。学習能力がないのか、のど元過ぎれば何とやら、なのか、いつどこでも見かける、もうそれはプロジェクトがいくつかあれば必ず一つはそれのような日常風景のようなものです。


本当の?デスマはそれほど多くないでしょうけれど、−仮にほとんどのプロジェクトがデスマならこの業界に人は集まらないですわな−、品質、コスト、納期、スコープのどこかでも当初計画より面倒になっているプロジェクトを閾値にするなら、ほとんどのプロジェクトは問題を抱えたプロジェクトでしょう。


そのデスマが日常的に存在するのはどこでも同じだと思うんですが、どうもそこにデスマがある状態をそこにいる人たちが許容しているのではないかと疑いたくなるものです。なぜなら、相変わらずデスマが存在し続けているし、その症状もいつものデスマと変わらないからです。


人は本当に嫌なこと、生命の危険を感じることを経験すれば、次は回避運動をするものだと思っています。実際、ワタシがデスマに遭遇したときだってそのときに学んだことを肝に銘じて、次からデスマにならないような予防的な行動を必要コストとしてやろうと決めたし、実際、その経験からまなびを得て、思考がリスクベースになったからです。


それ故、ワタシはその状態を恰も許容している風が理解できないんですけど、みなさんはデスマをどう見て感じているのでしょう。「あぁ、またやってるよ。」なのか「(自分のプロジェクトじゃなくてよかった...)」なのか。良心の呵責云々ではなくて、デスマがある状態を面前にして、そのデスマを受け止めているかってことです。


確かにワタシも「あぁ、(今度は)あそこなんだ。」とか思ったりするけれど、これだけ日常的にデスマが...、いや、ちょっと待て、ワタシの周りだけなのではないか...、そんなことはないだろう...、良くTLとかで見るじゃないか。


デスマの症状
デスマになっているプロジェクトを第三者の客観的な目で見ると、症状として見聞きするのはこんなことの具体的なことが耳に入っているんですね。

  1. プロジェクト計画が作られていない
  2. 週次レポートが報告されない
  3. 週次レポートがあっても内容が毎週同じ
  4. 課題管理が作られていない
  5. WBSが作られていない
  6. WBSがあっても更新されない
  7. 誰が何をやるか知らされない
  8. 自分のWBSの前工程は何であと工程がどうなるのか直前まで知らない
  9. 自分のWBSのアウトプットが誰のインプットになるか知らない
  10. 後先がわからないから目の前に来た作業を消化する単機能工になってしまっている


この症状がプロジェクト開始からすぐに耳に入るならまだ手の打ちようがあるんですが、デスマって工程終了の納期に差し迫ってから何とかしてほしいって訴えてくることが多い。ほんと、多い。


デスマを見分けるポイント
デスマなんて、誰も幸せになれないんだから、その兆候を知ることが出来ればそれこそ早期発見に繋がるわけです。それができればスバラです。じゃあ、何を見るかってことです。

  1. プロジェクト計画をそのプロジェクトで必要な項目だけテラーリングして作ってあるか。
  2. スケジュールは、工程の枠、他へ依存関係を持つマイルストーンを作ってあるか。
  3. WBSは今の工程が展開されていて、次工程はざっくりできているか。
  4. WBSの一つひとつのアウトプットの仕様(形、分量、状態)が定義されているか。
  5. 課題管理が作られ、課題が工程に相応しい分量がリストされているか。
  6. 課題管理で目標解決日を超過しているものがないか。


プロジェクト計画は、その中でプロジェクトメンバがプロジェクト期間中の行動様式を決めるのです。そこにはプロジェクトメンバが守らなければならない規律が書かれているのです。だからこれがないとプロジェクトメンバは、必要都度、一人ひとりが考え、行動することになるのです。それでは、規律に則った行動がとれやしない。


その規律にのっとった行動をとるときの時間的な制約の一つがマイルストーンです。プロジェクトとして、自分のチームとして、自分の作業として約束の時間がそこにあるのです。


今いる工程のWBSがなければ、いったいどうやってメンバは歩めばいいのか。箸の上げ下げは裁量として渡すとしても、自分の作業が誰に繋がるのか、それがわかっていなければ後工程を気遣てやりはしないでしょう。いつまでに仕事を仕上げる。それは後ろが決まっているから意識するのです。


WBSのアウトプットの仕様が決まっていなかったら、いくら期日に間に合わせてもWBSを作った人の思いは伝わらずに実行されるものだから、マイルストーンでそれぞれ完了したと言っているアウトプットを合わせてみてもパズルとしてハマるわけがない。かみ合わない。そんなことは当たり前です。だから、形、分量、状態を決めて、理解してから作るんです。


課題管理がないことがどれだけ拙いかわからなければ、それは非常に危ない状況です。プロジェクトの作業を言われたとおりにやっている“作業”でしかないのではありませんか。知らぬ人どおしが完成したものを観たこともないのに作業しているわけですから、そうしたら、なんでそう言った要求があるのか、なぜ、そう言った仕様が必要なのか、その仕様を実現するための壁があることを、その壁は越える必要があるのかないのか、そういったことを共有するツールとして必要なわけで、それがないとしたら顧客との“プロジェクと共通の悩み”をどうやって共有するのか、ということです。工程ごとに何十もでてもおかしくないのです。


そしてその課題が解決したい期日を越えていて、放置されている状態も危ないです。課題はリスクにすぐに昇格するものです。簡単にランクアップしてプロジェクトを揺るがすんです。


インターバルは短くから長くへ
こういった症状を見つけるのは最初は日々、そして徐々に安定していると確信が持てるまで短いインターバルで。確認が持てたら徐々に長くして、でも継続してウォッチすることがデスマか識別する唯一の方法だと思っています。