 |
|
| ビジネスとITのギャップを埋める〜システム開発の失敗を招く4種類のギャップ〜 |
第５回：プロセスのギャップは取り返しの付かないタイミングで起こる
著者：ウルシステムズ 平光 利浩 2007/6/20
|
|
|
| 前のページ 1 2 3 次のページ
|
|
| プロセスのギャップがユーザ企業に与える被害
|
プロセスのギャップが顕著化してしまうと、システム開発プロジェクトが破綻してしまう。このため通常は、対応するために技術者の増員を行う必要が生じたり、スケジュールの大幅な遅延が起こる。
これによって当然受注側の開発ベンダーも損失を受けるのだが、それ以上に発注側であるユーザ企業の被害は甚大となる。今回のケースのように全社システムともなれば、数千万円から数億円のコストがあっという間に超過してしまうので、経営上の重大な問題となる。またサービスインが遅れるためにビジネスチャンスを逃すことにもつながってしまう。
|
| プロセスのギャップを生じる根本原因
|
発注側と受注側の双方に甚大な被害を与えるプロセスのギャップが生じる原因は、どこにあるのだろうか。B部長は、今回のプロジェクト遅延は一方的に開発ベンダーに責任があると考えているようだ。
しかし、本当にそうなのだろうか。
|
| スケジュール遅延の兆しはなかったのか
|
B部長は開発ベンダーから遅延について、突然報告があったといっているが、何の予兆もなかったのだろうか。
それを知るために少し詳しく質問していくと、次のような事実が明らかになった。
「順調とはいっていましたが、開発ベンダーのメンバーが睡眠時間を削って作業をしていたのは知っています。それに、1ヶ月くらい前に開発ベンダーのプロジェクトマネージャ（以下、PM）が増強されましたが、そろそろ終盤だから佳境に入ってきたなと思いました。そんなことはシステム開発ではよくあることだし、不思議にも思いませんでしたが、まさかこんなことになるなんて・・・」
開発終盤で新たな開発ベンダーのPMが投入されたこと、そしてメンバーが睡眠時間を削って作業を続けていたこと、これらの2つはすでににプロジェクトの遅延リスクが顕著化してきてしまっているアラートだったようだ。
1ヶ月前の時点でアラートだと認識できていれば、その時点で何らかの手を打つことが可能だったはずだ。予兆を正しく捉えることができていれば早期に対処することができ、大きな問題に至ることはなかったかもしれない。
|
| 状況を正しく把握できていたか
|
では、なぜ予兆を正しくとらえることができなったのだろうか。この理由もB部長の話の中で明らかになった。
「開発ベンダーからは、毎週の進捗会議で報告を受けていました。かなり厳しい状況だが頑張ってリカバリできる範囲だという話でした。私は設計書の内容や現場とのやり取りまでは見ていませんから、どこまで進捗しているかは信じるしかありません。私も今時の開発については素人同然なので、直接見たところでわかるわけないですし。そうでしょう？」
結局、遅延の予兆を捉えられなかったのは、根拠のない報告を鵜呑みにして、正しい状況を把握できていなかったためである。
適切な報告を行なっておらず、プロジェクト自体の管理・コントロールも行えていなかったという開発ベンダー側の問題は確かにある。しかし、発注側から報告の根拠を求めるという姿勢をとり続けない限り、報告自体が形骸化していくことになるというのは自然な成り行きである。
技術的な詳細を知らないことをいい訳にして、緻密な管理を怠っていたB部長にも問題があったといえるだろう。
|
前のページ 1 2 3 次のページ
|
|
|
|
|
著者プロフィール
ウルシステムズ株式会社 平光 利浩
ITコンサルタントとして、数多くの大規模システム開発のプロジェクトマネジメントに関わる。近年では、プロジェクト活動における様々なギャップを埋めるべく、発注サイドに立ったプロジェクトマネジメント支援に従事している。
|
|
|
|
|
|
