■開発現場の悩み・問題点を解く ２ ～プロジェクトが遅れる ② ～ （No.307）
前回，計画性の大切さを述べたが，その続きでどのようにすれば，計画性あるプロジェクトにできるかを考えてみよう。
マイルストーンの有効性
マイルストーンはプロジェクト計画の中間目標として設定されるもので，通常一般には，デザイン・レビューなどの関門を設けている場合が多い。つまり，この時点で，開発・設計としてこれだけのことをしておかなければならないと云ったルール・決め事である。企業によって各々のやり方は様々であるが，これまでのプロジェクトから学んだエキスが凝縮されたチェックポイントで，チェックシートがあったり，開発経験者が持っているノウハウから質問をしたりなど，同じ失敗を繰り返さないことをチェックされる仕組みである。
開発計画当初にマイルストーンの日程を決めておくと，プロジェクトの進捗状況が具に判る。つまり，予定の日程が来ても会議ができない状況では遅れが明白になり，その遅れの度合いを知ることで，挽回策を練ることができ，プロジェクトの日程の軌道修正が図れることになる。このマイルストーンがあるのと無いのでは，日程遵守に大きな差が生じるのは明らかである。
通常一般には，このように計画当初にマイルストーンを設定する。マイルストーンと云う呼び名はともかく，最後までチェックをしないと云うのではなく，中間点など区切りをつけてチェックを入れることはプロジェクトを進める上での必須要件である。デザインレビューと云って，企画，開発，設計，量産設計など一定の検討が終わった時点で，会議が開催されるなどが一般的に行われている。或いは，企業で新製品開発規定があって，その中でルールが決められていることも多い。
プロジェクトに入ったメンバー全員が，こうしたマイルストーンを意識しながら進めることが，身近な目標に向かって取り組みが行われることとなり，プロジェクト遅延に対しては非常に有効な方法である。
クリティカル・パスの把握と管理
プロジェクトには，幾つかのタスクが並行して進むのが通常で，すべてをきっちり管理できればそれに越したことはないが，複雑さやタスクの多さによって困難な場合がある。しかし，進捗管理の原則があって，クリティカル・パスを把握し，それを中心に進捗を管理できれば，大きな遅れが発生することは少ない。つまり，進捗管理をやっているつもりでもプロジェクトに遅れが生じるのは，このクリティカル・パスが十分把握できていなく，ただ漫然とすべてのタスクを追っかけている場合が多い。これでは，本当の管理とは云えない。
自分が担当しているタスクがクリティカル・パスになっていることは担当者としては十分認識をしていなければいけない。プロジェクトリーダーが明確にしておくべきである。リーダーと当該の担当者が知っているだけでなく，他のタスクを抱えているサブリーダー又は担当者にも周知徹底して，互いに協力し合うことが大切である。プロジェクトとはチーム一丸で進めるものである。
クリティカル・パスは最初の計画で決まってしまうものではなく，その進捗状況でクリティカル・パスは移動する。即ち，クリティカル・パスは全体の進捗を把握していないと正しく認識できないものである。そういった点では，プロジェクト全体の進捗が把握できるWBSまたは，PERT図などはプロジェクトには欠かせないものである。
挽回計画の大切さ
遅れ始めたプロジェクトを元に戻すには，きっちりとした挽回計画が必要である。これは当たり前で，誰もが考え，挽回計画を立てようとする。ところが，この挽回計画が不十分・杜撰なケースが多いのである。
一度遅れだしたプロジェクトを元に戻すことは，再計画すれば良いと云うような単純なものではない。遅れ出した原因があるはずである。この原因究明，及び対応策検討なしに，再計画しても，遅れがさらに延びるばかりで，挽回にはならないケースが多い。まして，精神論での挽回など無意味と云っても過言ではない。
先ず，遅れの要因が，技術的な壁なのか，人的なパワーの要因なのか，課題がクリアできず行き詰まっているのか，何が原因で遅れているのかを明確にしなければならない。要因は必ず一つとは限らず，複数の要因が絡み合っていることもよくあることである。それら各々の要因に対する挽回策が的確に打てるのか見極めることが大事である。
一番多い過ちは，詳細な検討をせずに，終了時点が合うように日程計画だけを修正するものである。そんなバカなことはしないと云われるかも知れないが，挽回計画は一般的に上司への報告のための辻褄合わせであることが多い。つまり，上司のチェックをかいくぐるための挽回計画であることが往々にして起こるのである。もちろん，酷いものは上司のチェックで引っ掛かるが，なかなか上司も詳細な部分は見破ることが難しい。ついつい，プロジェクトリーダーの言を信じて，その挽回計画で頑張ってくれと檄を飛ばす程度が多い。これでは問題の先送りで，プロジェクトの遅延は解消できていない。
挽回計画とは，遅れた原因を明らかにし，それに対して，今までとどんな違いで対策しようとするのか，それのスキル・パワー・期間などが適切かどうかを見極めなければならない。遅れが生じているので，ついついその見極めが甘くなる。つまり，希望的観測を含んだものである場合が殆どと云ってもよい。十分過ぎる挽回策を立てられていた経験は殆どない。何とか取り戻したい一心はリーダーからよく伝わってくるが，その一心とは裏腹に，挽回計画はそれほど熱心に綿密に詰められていないことが多い。
これは遅れと云う負担を負わされた者の心理でもあり，殆どのリーダーが同じ轍を踏んでいる。リーダーに責任を負わせるのではなく，この場合，その上の上司が，挽回計画の詰めの甘さを指摘するべきである。また，必要なリソースを充てるなどができるのも上司で，遅れを背負ったリーダーは何とか与えられたリソースでムリをして挽回しようとするものなのである。それを見抜かなければ，遅延はますます酷くなる例を多く見てきた。そして，上司は責任を感じることもなく，リーダーに責任を押しつけていることが殆どである。もちろん，リーダーの責任は大きいのは当たり前だが，挽回計画を承認する上司にも責任はある。
挽回計画は当初の計画よりも実現が難しいことを知って，その内容をよく吟味しよう。
遅れによる機会損失を考えたか？
プロジェクトの遅れを少し違った角度から見てみよう。
プロジェクトが遅れると予定していた日程で終わらないため，開発費用が嵩むことは誰の目にも明らかで，余分なコストが掛かっているとの認識はできる。ロスコストとしていくらと云う算出である。ここまでは殆どの企業で検討されている。しかし，実際にはそれ以外にも大きな損失があるのだ。先ずは予定通りプロジェクトが終わったときと遅れたときとの差の期間による販売の機会損失である。本来ならば販売に貢献したはずが，貢献できなかったと云う損失である。これは検討すれば，大凡の損失は計算できる。
それ以外にはブランドの失墜，企業取引の信用失墜などがある。これは場合によってダメージが大きいこともあれば，そうでない場合もあり，損失の計算は容易ではない。普通こうした信用を落とすことは，なかなか取り返すことが難しい。信用は一度起これば直ぐに失うが，信用を得るには一度や二度で済むことではない。また，損失計算をするしないの問題ではなく，プロジェクトの遅れが，単に開発費用のロスだけに止まらない大きな損失であることは肝に銘じておくべきものである。
このように機会損失まで意識してプロジェクトを進めていると，プロジェクト遅延の影響がどれほど大きいかがよく理解でき，進捗管理に万全を期さないといけないことを身に沁みて判るのである。
再発防止策は
プロジェクト計画の不備・杜撰だったことは，プロジェクトが終了した時点で明らかになる。ここでプロジェクトが終わったとホッとするのではなく，次のプロジェクトに向けた反省が重要である。これは，リーダー自身がじっくり振り返り，計画のどの点が拙かったのか素直に反省することが大切である。特に，企業そのものに与えた損失はすぐ思いつき，素直に認めるが，ともすると顧客に与えた損失は見過ごされることが多い。再発防止とは，顧客も含んで検討されるべきものである。
再発防止策と云うと，メンバー全員に反省をアンケートなどで収集することもよく行われるが，決して悪いことではないが，リーダー自身の真摯な反省無くして，アンケートなどで済ませてしまうのは論外である。特に，メンバーではなかなか顧客のことまで気が付かないことが多い。プロジェクト遅延の大きな原因である計画性の問題は，リーダー自身の問題として真摯な反省を望みたい。
プロジェクトの遅れは防げる
プロジェクトの遅れは単に開発コストのロスだけではない
[Reported by H.Nishimura 2013.02.04]
Copyright (C)2013 Hitoshi Nishimura
