納期優先の無理なプロジェクトが失敗を招く？：プロジェクトはなぜ失敗するのか（5）
皮肉なことに、プロジェクトと失敗とは相性がよい。納期どおりにできなかった、要求どおりにできないことが多い、機能を削減することが多いなど、もともとの目的、スコープから、後退したプロジェクトの経験を持つITエンジニアは多いに違いない。なぜ目的どおりにいかないのか。どこを改善したらいいかを本連載で明らかにし、処方せんを示していきたい。
甘い計画でプロジェクトをスタートすると
日本の社会は「委託者の地位が異常に高い」という特徴を持っている。委託者は納期はしっかり押し付けるにもかかわらず、要件定義ではなかなか結論を出さなかったりする（出したがらない）。このつけは、プロジェクトマネージャに回される。人のよいプロジェクトマネージャは、これを何とかしようとして、最初から無理な計画を立ててしまうことになる。これが失敗プロジェクトへの道の第一歩である。
プロジェクトはなぜ失敗するのか 各回のインデックス
第5回 納期優先の無理なプロジェクトが失敗を招く
プロジェクトにリスクは付きものである。従って、このリスクに対応するための予備を用意しておかなければならないのである。それにもかかわらず、予備を用意するどころか、最初から残業をするような前提で計画を立てたりする。残業すれば何とかなるという、甘い計画でプロジェクトがスタートすると、何らかのリスクが顕在化すると対処のしようがなくなる。そのうちに残業続きのメンバーの士気も落ちてきて、納期についてもあきらめ気分が生じてくると、もう失敗プロジェクトにまっしぐらという状態になってしまう。
スケジュールを立てる際に、納期から逆算して立てることがある。しかしこの方法はまったく適切ではない。プロジェクトで必要な作業を洗い出して、各作業の作業量から必要な期間を算出して、それを積み上げてスケジュールを作っていく。こうやって作成したスケジュールが納期に間に合わないのであれば、何らかの方策を取らなければならない。人員を増やすのか、納期を先に延ばすのか、どのような対策を取るのかを決めて、合理的にスケジュールを見直す必要がある。間違っても、精神論でこれを解決しようとしてはならない。無理なものは無理なのである。
合理的なスケジュール作成
スケジュールの作成は、納期ありきのトップダウンアプローチで行うべきではない。必要な作業をすべて洗い出して、それを積み上げてスケジュールを作成するボトムアップアプローチを採用すべきである。この手順を示すと以下のようになる。
（1）すべての作業の洗い出し
最初にプロジェクトに必要となるすべての作業を洗い出す。この作業のベースとなるのがWBS（Work Breakdown Structure）である。WBSとはプロジェクト全体を細かい作業に分割した構成図で、プロジェクトで作成しなければならない成果物を明確にして、それを作成するための作業を洗い出し、階層構造で表現したものである。
（2）各作業の順序を設定する
プロジェクトで行う作業は、行う順番が決まっている場合が多い。プログラム設計の前にプログラミングを行うことはできないのである。プロジェクトで行うべきすべての作業が洗い出せたら、各作業の順序関係を明確にする必要がある。この順序関係を示すために通常使われるのがネットワーク図である。
（3）各作業に割り当てる人員の決定
次に各作業にどのようなスキルの人間をどのくらい割り当てるかを決める。最近のシステム開発では、ネットワークやデータベースなど作業の内容に応じて、それぞれの分野の専門家を割り当てることも多い。このような人員のスキル、レベルも考慮したうえで、人員の割り当てを決めていく必要がある。
（4）各作業の所要期間の決定
各作業に割り当てた人員を考慮したうえで、各作業の所要期間を決めていく。このときに、生産性基準に従って、合理的な算定を行うことが重要である。設計作業の生産性が10ページ／人日だとする。もし、100ページの設計作業を1人で行うのであれば、10日かかることになるし、2人で行うのであれば5日で済むことになる。
（5）スケジュールの策定
（2）の作業の順序と、（4）の各作業の所要期間を使って、スケジュールを組んでいくことになる。このときに1つ考慮しなければならないのが、必要人員が最大値を超えていないかのチェックである。
単純に作業順序と所要期間だけを使ってスケジュールを組むと、ある時点での必要人員が最大値を超えてしまうことがある。システムエンジニアを5人しか用意していないのに、ある時点での必要人員を積み上げると7人になってしまうなどの場合である。この場合は、作業を少し後ろにずらすなどして、人員のピークを下げる必要がある。この作業のことを「資源の平準化」という。
納期短縮の方法として
このように作成した合理的なスケジュールが、もし納期に間に合わなかったとしたら、どうすればよいのであろうか。スケジュールを短縮する方法は、一般にクラッシングとファストトラッキングがあるといわれる。
クラッシングは、クリティカルパス上の作業に人員を追加投入して、全体のスケジュールを短縮する方法である。しかし、一般にこの方法はコスト増を招くことが多いため、予算とのバランスを考えながら、実施の可否を検討する必要がある。
ファストトラッキングは、本来は順番（シーケンシャル）に行う作業を並行（パラレル）して行うことにより、スケジュールを短縮する方法である。例えば、本来はプログラム設計が完了して、レビューによる承認を受けてからプログラミングを行うべきであるが、これを一部のプログラム設計ができたら、即座にプログラミングにかかり、この両方の作業を並行して行うことなどがある。この方法は、管理が難しくなるので、リスクが増大すると一般にいわれる。従って、この方法は計画段階では使うべきではないと、筆者は考える。
このように計画段階でのスケジュールの作成は、あくまでも合理的な計算の下に行うべきであり、そこに精神論をベースにした「頑張り」を持ち込んではいけない。納期をどうしても短縮する必要があるのであれば、人員の追加など、しっかりした根拠を持って短縮を行うべきである。
著者プロフィール
落合和雄
1953年生まれ。1977年東京大学卒業後、新日鉄情報通信システム（現新日鉄ソリューションズ）などを経て、現在経営コンサルタント、システムコンサルタント、税理士として活動中。経営計画立案、企業再建などの経営指導、プロジェクトマネジメント、システム監査などのIT関係を中心に、コンサルティング・講演・執筆など、幅広い活動を展開している。主な著書に、『ITエンジニアのための【法律】がわかる本』（翔泳社）、『実践ナビゲーション経営』（同友館）、『情報処理教科書システム監査技術者』（翔泳社）などがある。そのほか、PMI公式認定のネットラーニングのeラーニング講座「ITプロジェクト・マネジメント」「PMBOK第3版要説」の執筆・監修も手掛けている。
Copyright © ITmedia, Inc. All Rights Reserved.