プロジェクト内容
|
Ｘ社は中堅のＳＩベンダであるが、センサーメーカＹ社より、情報化の相談を受ける
登場人物 Ｌさん Ｙ社の営業マネージャー
Ａさん Ｘ社のプロジェクトマネージャー
Ｄさん Ｘ社の営業
＜仕様打ち合わせの場面＞
Ｌさん「最近、ライバルのＮ社とコンペで負けることが多くてね。今年度の重点目標で顧客を取り返すっていうテーマが決まったんだ。それで調べてみたところ、Ｎ社に顧客を取られだしたのが、彼らが営業マネジメントシステムを入れてからだというのが分かってきた。Ｚ社さんの仕事らしい。これに負けないシステムを作りたいんだ。予算は５０００万円確保してある」
Ｄさん「分かりました。具体的に、今の営業の仕方の問題だとか、あるいは理想像だとかありますか」
Ｌさん「それがあれば、お宅に声をかけない。お宅もＺ社とはライバルなんだろう」
Ｄさん「わかりました、力を併せて、ぜひ、よいシステムを作りましょう。電話で大体のお話は伺っていたので、今日はこのプロジェクトを担当するＡをつれてきました」
Ａさん「Ａです。よろしくお願いします。システムに疎くて、紙に書いただけでは分かりにくいということをＤの方から伺っていますので、とりあえず、イメージできるようなプロトタイプのシステムを作って、そこから話を始めたいと思うんですが、よろしいでしょうか？」
Ｌさん「よろしくお願いします」
＜プロトタイプ完成後の打ち合わせ＞
Ａさんがプレゼンをした後で
Ａさん「われわれはこんなイメージなのですが、如何でしょうか？」
Ｌさん「悪くないけど、何か、違うような気がするね」
Ａさん「どのあたりでしょうか」
Ｌさん「たとえば、このシステムだと営業マンがだいぶ時間をかけて日々の活動をコンピュータに入力していかないといけないね。こんなことが本当にできるんだろうか？うちの営業マンの中には、いまだにパソコンに触るのを嫌がっているのがいるよ」
Ａさん「難しいですか？もし、だめならここでもっと営業マンの負担を減らす方法を考えないといけないですね。次はそこを検討して、また、案をお持ちしたいと思います」
Ｄさん「この辺で、そろそろ、契約をしてからということにしてもらえないでしょうかね？」
Ｌさん「ああ、いいよ。実は、おたくを指名したのはうちのＰ社長で、おたくのＱ社長とはゴルフ仲間らしい。もう、社長の承認も取れているんだ」 |
| このプロジェクトの結末 |
この調子で、ああでもない、こうでもないということで進んでいき、工数だけを食っていった。結局、当初の予算だった５０００万円を原価ベースで使いきったところで、Ｘ社はさじを投げ、適当にシステムの形を整えて終わろうとしたが、そこでＰ社長からＱ社長へ泣きが入り、結局、営業事務作業の支援に使えそうな部分だけを切り出して、２５００万円のシステムとして引渡し。Ｙ社は営業事務の省力化により営業マンの時間を浮かし、人海戦術という営業スタイルへ。Ｘ社は２５００万円の損失。 |
| 問題点 |
・プロジェクトの目的があいまいなまま、プロジェクトを発進させている
・プロジェクトマネジメントフェーズで考えると、企画プロセスの完了の前に、計画プロセスに入り、さらには実施プロセスに入っている |
| 処方箋 |
・プロジェクトマネジメントプロセスのマネジメントをきちんと行い、企画プロセスが完了するまで、計画プロセスに進まない
・諸般の事情でそれが難しい場合には、フェーズ分割を行い、まず、目的を明確にするフェーズ（要件分析）と、そのためのシステムの開発のフェーズを分けて進める |
| 解説 |
ソフトウエアプロジェクトの難しい点は、成果物に対するイメージが難しいことである。これはプロジェクトにさまざまな影響を与える。そのひとつが、どういうソフトウエアを作れば、問題が解決するのかが明確にしにくく、プロジェクトに関与する人全体が共有できるイメージを持つことが難しいことである。つまり、目的は明確だけど、手段が決まらないというプロジェクトがソフトウエアプロジェクトである。
そのために、このケースのように、何をやるのかを明確にできないまま、プロジェクトが走り出し、場合によっては最後まで決まらないというケースもまれにあるし、また、ビジネスとして考えた場合、契約時点では決まっていないといったケースは結構多い。
このような状況を避けようとすると、フェーズマネジメントをきちんとするのがよい。そして、それぞれのフェーズでの成果物を明確に定義し、その成果物が得られるまでは次のフェーズに移行しない。
ソフトウエアプロジェクトのフェーズは、開発方法論に依存することが多い。たとえば、ウォーターフォールモデルだと、要件定義で１フェーズ、設計〜開発で１フェーズ、テスト〜運用で１フェーズというフェーズの取り方をすることが多い。また、最近、流行の兆しがあるＸＰに代表されるイタラティブな開発では、イタラティブをひとつのフェーズとして考える。システムの機能に注目してフェーズを定義していくため、プロジェクトにとっても顧客にとっても分かりやすいのが特長である。
ここで、プロジェクトマネジメントとして考えなくてはならないことは、契約をどのタイミングで行うかである。ウォーターフォールの場合、望ましいのはフェーズごとに契約を行うことである。これは最近では一般的になりつつある。イタレーションを行う場合には、イタレーションの回数をベースにして契約をすることが多い。 |
| ワンポイント |
目的なくして、プロジェクトなし |
| 参考文献： |
