納期優先のツケを後で払うことになる開発方法プロジェクトはなぜ失敗するのか(9)

皮肉なことに、プロジェクトと失敗とは相性がよい。納期どおりにできなかった、要求どおりにできないことが多い、機能を削減することが多いなど、もともとの目的、スコープから、後退したプロジェクトの経験を持つITエンジニアは多いに違いない。なぜ目的どおりにいかないのか。どこを改善したらいいかを本連載で明らかにし、処方せんを示していきたい。

» 2008年07月17日 00時00分 公開
[落合和雄@IT]

QCTのバランスの重要性

 顧客に製品やサービスを提供したときに顧客が満足するかどうかは、Q (Quality)、C(Cost)、T(Time)の3つの要素で決まる(図1)。品質(Q)が良く、コスト(C)が安く、納期(T)が早ければ顧客は満足してくれる。ここで難しいのは、この3つはトレードオフの関係になることが多いことである。多くの場合、T(納期)ばかりにこだわるとQ(品質)が落ちる、C(コスト)要求を厳しくすると、T(納期)が遅れたりする。

顧客の満足度を計る3要素 図1 顧客の満足度を計る3要素

納期を優先しがちなプロジェクトマネージャ

 ほとんどのプロジェクトマネージャは、この3つを対等に扱わずに、納期を優先して管理を行ってしまう。毎週の進ちょく会議で、とりあえずスケジュールが守られていると安心する。しかし、それで本当に問題はないのであろうか。

 一番多いのは、品質を犠牲にして納期を守っているケースである。人は納期が迫ってきていて、どうしても遅らせるわけにはいかない場合、手抜きをして納期を守ろうとする。手抜きの内容としては、以下のようなものがある。

  • テストをいい加減に済ましてしまう
  • 例外時の処理をあまり考慮せずに済ましてしまう
  • 安易にほかのプログラムから似たルーティンを持ってきて、あまりチェックをせずに手直ししてプログラミングに使用する

 上記のことが行われると、ソフトウェアの品質は非常に悪くなる。品質があまりにも悪いと、最悪、あとで全面的な手直しをするはめになってしまい、かえってコストが膨らむことになる。

 次に多いのが、コスト無視で納期を守っているケースである。予定より多い数の人員をつぎ込んでいたり、担当者に残業をさせている場合がこれに当たる。確かに納期を守れてはいるが、これでは実際のコストが予算よりも多くかかり、最終的にコストが予算を大幅に超過してしまう可能性が高い。

QCTを対等に扱うプロジェクト管理

 すでに述べたように、プロジェクトにおいては、QCTのどれか1つでも満足できない結果であれば、プロジェクトが成功したとはいえない。そうであれば、T(納期)を管理するだけでよいはずがない。プロジェクトは、QCT3つすべてを常に管理していなければならない。次にその方法を紹介する。

納期だけに翻弄されないための、TとQの同時チェック

 まず大事なことは、Q(品質)を定常的に管理することである。毎週の進ちょくミーティングで、スケジュール管理と同時に品質チェックも行うことである。これは、決して簡単なことではない。

 最も大事なことは、成果物の完成とそのテストやレビューをできる限り近付けることだ。例えば、プログラムが完成したら、すぐに単体テストを実施させ、その結果を報告させることである。このときに必ず、テスト結果をテスト記録などで確認し、品質をチェックする。これでTとQを同時にチェックできる。成果物の完成と品質のチェックが同時にできれば、たとえ品質に問題があったとしても、すぐリカバリーができ、大きな問題にはならずに済む。最初に品質をチェックせず、納品時に品質のチェックを行うと、品質上の問題が出たときにリカバリーができず、大きな問題に発展してしまう。

TとCも同時チェック

 コストの管理も本来は進ちょくミーティングのタイミングで同時に行うべきである。多くの会社は、コストの管理を進ちょくミーティングのタイミングとは別に、月次などのタイミングで行っている。これでは、コストオーバーに対して、タイムリーに対策が打てない。それだけでなく、進ちょく管理とコスト管理が結びついていないために、プロジェクトの途中では正確なコスト管理ができないことになる。

 これを解決するためには、進ちょくとコストを同時に管理する仕組みが必要である。この代表的な手法がアーンドバリュー法(参照:「結構ややこしいぞ! アーンド・バリュー計算と分析」)である。これは、プロジェクトの計画や成果物、労働力を同じ指標(出来高)に換算して管理する手法で、プロジェクトの遅延やコスト超過を早期に発見できる。この手法は、国際的には非常に広く使用されているが、日本ではまだあまり普及していない。しかし、ほかに進ちょくとコストを同時に管理できる手法がないことを考えると、もう少し積極的にこの手法の採用を考えるべきであろう。

著者プロフィール

落合和雄

1953年生まれ。1977年東京大学卒業後、新日鉄情報通信システム(現新日鉄ソリューションズ)などを経て、現在経営コンサルタント、システムコンサルタント、税理士として活動中。経営計画立案、企業再建などの経営指導、プロジェクトマネジメント、システム監査などのIT関係を中心に、コンサルティング・講演・執筆など、幅広い活動を展開している。主な著書に、『ITエンジニアのための【法律】がわかる本』(翔泳社)、『実践ナビゲーション経営』(同友館)、『情報処理教科書システム監査技術者』(翔泳社)などがある。そのほか、PMI公式認定のネットラーニングのeラーニング講座「ITプロジェクト・マネジメント」「PMBOK第3版要説」の執筆・監修も手掛けている。



Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。