「波乱」のスタート

「波乱」のスタート

プロジェクトが始まりました。ITベンチャーのプロジェクト・マネージャーは早速、要件定義を始めようとして、発注側の担当者と会議を開きました。ところが、会議が始まっても担当者が来ません。数十分後に来たと思ったら、ひっきりなしに電話が鳴って中座してしまいます。事前にお願いしていた資料などは、作成してくれていませんでした。

結局、ホワイト・ボードにメモを書いて終了です。このメモをデジカメで写真に撮った画像が、要件定義書となりました。基本設計書も同様に、画像のみです。基本設計書というフォルダには、写真の画像ファイルだけが並ぶことになりました。オフショア開発では、日本と海外では「常識」の違いがあるので設計書を丁寧に作成するのが「常識」なのですが、画像ファイルだけではオフショア開発で開発に着手することができませんでした。

とりあえず日本側で画面のプロトタイプを作成して担当者に見せたところ、そのたびに新たな要望が大量に発生し、そのたびにスケジュールの調整を行いました。作るたびに新たに要望が発生するが、事前に聞いても何もでてこない、という状況に、プロジェクト・メンバーのモチベーションも下がってしまいました。

また、発注側の情報システム部門もほぼ機能していませんでした。サーバーの手配も依頼したけれど、できていませんでした。テスト環境などもなく、本番環境のみというような状況でした。また、プロジェクト・マネージメントの支援に関しても、サイトを作成しているベンダーが納期を守らない、連絡も時折とれなくなる、品質も低い、という状態で、どうしようもありませんでした。

このプロジェクトをどうリリースすればいいのか、ITベンチャーのプロジェクト・マネージャーは途方に暮れてしまいました。

「常識」に困惑

後から分かったことですが、この案件は過去に数社が開発に携わって、全部失敗していました。「Webサイト構築」にしては規模が大きいため「Webサイト構築」専業の会社では作成できず、一方で「業務システム開発」の会社では要件がまとまらないので途中で撤退していたようです。それで、このITベンチャーのところに話が来たというわけです。

このITベンチャーは、通常の「業務システム」であれば、「今回の開発を行うにはこのような成果物が必要なので作成してください、また、こういう体制を作ってください」というような依頼を発注側にします。しかし、発注側には現実的に資料を作る時間もないし、体制も作れません。そして、一番重要な納期は迫っています。「Webサイト構築」においては「スピード」が命ですから、納期を遅らせるわけにはいきません。

ところが、発注側は、小規模の「Webサイト構築」を作成するのと同じ感覚でした。「ある程度要望を言っておいて、できあがったものを見る」、というスタンスです。そのような感覚なので、ITベンチャーからの「資料を作って欲しい」という依頼や、「会議が多い」ということに不満があった模様です。発注側は、とにかく動くものが見たかったのです。

プロジェクト・マネージメント支援のほうは、窓口となっている会社の下に複数の開発ベンダーがいて、さらにその下に、というように商流が大きくなっており、実際に作成している会社がどこなのか発注側には分からない、という状況でした。通常の「業務システム」の開発では商流をはっきりさせるのが「常識」ですが、「Webサイト構築」では、そうではなかったのです。

次ページでは、課題を抱えた同プロジェクトをどう成功に導いたのかを解説しつつ、プロジェクト・マネージメントの心構えについてまとめます。