なぜこんなことに

順調だったプロジェクトが迷走するとき

ソフトウェアプロジェクトでは、アプリケーションのリリース段階になって炎上し、火消しに追われるはめになることがある。どうしたらそんな事態を避けられるだろうか。

公開 2007年11月26日 04時00分

更新 2012年09月06日 13時23分

著者

Michelle Davidson

[TechTarget]

印刷する Googleで優先するソースとして追加

　スタートしたときは快調に見えたプロジェクトが、最終的に悪夢のような状況に陥った経験はないだろうか。こうした誤算は、人々が認めるよりも頻繁に発生しているはずだ。

　社内アプリケーションを例に取ってみよう。まず、社内の誰かが、売り上げの増加やワークフローの改善、あるいはシステムの操作性の改良などにつながるアイデアを思い付いたとしよう。収益向上に結び付くと判断されれば、そのアイデアのアプリケーションへの実装が強力に推進されることになる。だが、ことによると、開発スピードが優先されるあまり、そのアプリケーションにかかわるすべての部門がそれぞれの役割を果たさないうちにアプリケーションが完成したと見なされ、リリースされてしまうかもしれない。

　この場合、次のようなことが起こる。プロジェクトは「スケジュール通りに」完了した。だが、すべての利害関係者の声が吸い上げられてはいなかったことから、要件定義が不十分なものになっていた。このため、アプリケーションがリリースされても、ニーズを反映してもらえなかった部門は慌てて業務をアプリケーションに合わせたり、次善の運用方法を見付けなければならなくなった。こうした部門は、自分たちに必要な機能が次のバージョンに搭載されるのを期待するしかない。

　しかも、品質管理担当者とテスターは、自分たちの役割を果たす時間を十分に与えられなかった。このアプリケーションが想定通りの新機能を提供しているのは確かだ。しかし、そのアプリケーションとやりとりを行うシステムやアプリケーションにどんな影響があるかは、しっかりと検証されなかった。「新しいアプリケーションとこうしたシステムはうまく連携するのか」「こうしたシステムは新機能の負荷に対応できるのか」といった点が不安材料となっている。

　また、プロジェクトの進行を急ぐと、アプリケーションのユーザートレーニングの時間が足りなくなりがちだ。