プロジェクトを成功に導くためには？

プロジェクトを成功に導くためには？

ITベンチャーのプロジェクト・マネージャーは、「Webサイト構築」の「常識」に柔軟に対応することにしました。

発注側の担当者は、資料は読んでくれませんが、動いたシステムは見てくれます。そこで、設計を担当する日本側では、スーパー・プログラマと数人のプログラマを追加でアサインし、「品質」が低くてもいいからとりあえず動くものを作って欲しいという依頼をしました。

スーパー・プログラマは、一気にそれなりのものを作り、発注側に確認してもらいます。また、開発を担当する中国側では、日本人のエンジニアを中国に常駐させ、日本側と密にコミュニケーションをとって進めました。

ソフトウエアの開発以外にインフラ要員もアサインして、サーバー構成の見直しやステージング環境の作成などを行いました。その後も各種の問題が発生しましたが、プロジェクト・マネージャーを中心に「Webサイト構築」の「常識」に対応し、なんとか最低限必要な機能を満たしたものをリリースすることができました。

発注側は、初めてのリリースだったため感動し、ITベンチャーに対する評価も上がりました。そして、ITベンチャーの意見も聞いてくれるようになりました。その後、保守工程の中で、ドキュメントの整備、インフラの見直し、優先度の低い項目の追加リリースを行いました。

プロジェクト・マネージメント支援のほうは、商流の確認を行い、現在参画しているベンダーを明確にして、体制を見直し、コミュニケーション・フローの改善を行いました。そして、それまでは自社で作業していた窓口会社の作業場所を発注側のオフィスに変更し、ITベンチャーのプロジェクト・マネージャーの指示の下で働くようにしました。これによってコミュニケーションが大幅に改善され、「連絡が取れない、納期を守らない」という問題を解決できました。

発注側と開発側で「常識」を共有する

「それなり」のものを作ってリリースするというやり方は「業務システム」ではあり得ないことですが、「Webサイト構築」では、作っている間に流行が終わってしまうとサイトそのものが無駄になってしまいます。今回のリリースは「業務システム」の基準で考えると失敗かも知れませんが、「Webサイト構築」という点では商戦に間に合ったので成功と言えます。ITベンチャー側も、開発では赤字でしたが、保守と改修で最終的に黒字にすることができ、両者が満足する結果になりました。

今回は、「Webサイト構築」では「Webサイト構築」の「常識」に対応したことが、「プロジェクトマネージメント支援」では「Webサイト構築」の「常識」を破るという「柔軟」な対応ができたことが、それぞれ成功の要因だと思われます。

今回のやり方が最善だったとは言えません。大規模の「Webサイト構築」では、小規模の「Webサイト構築」のようにある程度要望を言うだけで完成するものではなく、最低限の資料や会議は「業務システム」と同様、当然必要になります。本来ならば、資料と会議の必要性を発注側に認識して作業をしてもらうべきでした。

また、今回はオフショア開発を行いましたが、コミュニケーションのコストがかかるオフショア開発は、「Webサイト構築」には不向きだったかも知れません。

これで、今回の事例の紹介は終わりです。重要なことは、発注側と開発ベンダーはプロジェクトにおける共同作成者であるということです。開発ベンダーは「発注側の担当者がやってくれないからできない」と言って投げだすのではなく、リリースに向けてお互いの「常識」の違いを確認しつつ、役割分担を明確にすることが必要なのではないでしょうか。

次回は、Webアプリケーション開発の手段として要素技術が複雑化している現状を報告するとともに、どの技術をどう適用するべきなのか、指針を示します。