そのプロジェクトでは何を犠牲にしていいのか

イー・キャッシュ株式会社
玉木 栄三郎
須永啓太

2006/12/27

■ プロジェクトの成否は発注前にほぼ決まっている

　 プロジェクトの成否はユーザー企業側のプロジェクトマネージャがRFPを書き出した時点でほぼ決まっているといっても過言ではない。ユーザー企業を行う前にリスクファクターを洗い出し、その内容をRFPに含めていく作業が必要なのである。「モノ」の連載でも書かせていただいたが、システムのアーキテクチャの選定は、そのシステムの将来的な方向性を見据える必要がある。そのシステムが3年間で使い捨てになるようなシステムなのか、それとも将来的に別のシステムとも連動して企業の基幹となるようなシステムになるのかを判断してRFPに推奨とされるアーキテクチャを記載していくべきである。「カネ」の回のような「度重なる仕様変更や機能追加」などはあらかじめ予見できないではないかといった声もあるかもしれない。

　しかしながら、そのシステムにかかわる人間つまりステークスホルダーの数からシステムの仕様の調整が難しいか優しいかは発注前に予見できることである。システムの仕様変更が多発すると判断されるのであれば、RFPにスパイラル型のプロジェクトマネジメント手法、もしくはアジャイル型などの仕様変更に強い開発手法を開発会社にリクエストすればいいのである。

■ プロジェクト運営中のリスクについて

　とはいえ完全に発注前つまりRFP作成時点では想像し得ないリスクなどもあるであろう。「開発会社のプロジェクトマネージャが退職してしまってプロジェクトが停滞した」「昨今の情報漏えい問題などで、開発中のシステムに対してすべてセキュリティに関する試験をサービスインまでの期間はそのままで全社的に行う業務命令が出た」、などここでは書き切れないくらいの大小かかわらずさまざまなリスクが発注側のプロジェクトマネージャを襲うであろう。

　発注側のプロジェクトマネージャが見失ってはならないのは、プロジェクトの最重要としているゴールは何で、そのために何を犠牲にしていいのかである。

　プロジェクトのゴール、「目的としていた機能をすべて実装したシステムを構築すること」「予算どおりにシステムが構築されること」「スケジュールどおりにシステムが構築されること」などが挙げられるのかもしれないが、どうかプロジェクトマネージャはすべてのプロジェクトの目的を満たそうとするのはやめて、会社に対してどれを優先すべきで、どれを犠牲にすべきかそのような交渉をしていただきたい。

　プロジェクトに発生した問題を先送りにするのではなく、問題を解決するためにどのような処理を行うかをプロジェクトが優先しているゴールを基に決定する必要があるのである。

◆

　プロジェクトマネージャは開発会社の最高責任者であり、出版されている書籍も彼らがより円滑にプロジェクトを運営するための優れたノウハウ本が非常に多く出版されている。このような風潮は、システム開発における技術は複雑化し、さらに求められる仕様の要件は環境の複雑さと相まってより高度化しつつある事情からである。

　このような状況の中でユーザー側のプロジェクトマネージャはプロジェクトの成功を会社側に求められているのである。開発会社プロジェクトマネージャにとってプロジェクトの失敗とは単に受託した開発案件の失敗であり、また別の開発案件のプロジェクトマネジメントへと移っていくだけであるが、ユーザー側のプロジェクトマネージャはそうはいかない。ユーザー側のプロジェクトマネージャは発注側の責任者として、永遠にそのシステムが稼働し続ける限り、マネジメントしていく必要があるのである。

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）