プロジェクト内容
|
・観葉植物のインターネット販売を行うＷｅｂサイト開発のプロジェクト
・顧客は中堅の花屋さんで、商品紹介などを行うサイトは持っているものの、あまり、更新をしていない。
・開発費用：４００万円
・見積もり工数：設計１５０時間、インプリメント５００時間
・技術的フィージビリティは問題なし |
| 体制 |
プロジェクトメンバーは３名。
Ｓさん：プロジェクトマネージャー兼システム設計担当
Ｋさん：１人はＷｅｂプログラマー
Ｎさん：データベースのプログラマー
Ｓさんは、受注企業の社員、Ｋさん、Ｎさんはフリーランス |
| 開発期間 |
開発期間は６０日間
１〜２０日：要件分析、基本設計
２１〜６０日：システム化、テスト、導入
週１回、進捗報告会議 |
| トラブル |
Ｓさんが中心に要件分析と基本設計を行い、その後を受ける形でＫさんとＮさんが中心になりシステム化作業。ＳさんはＫさん、Ｎさんと一緒に仕事をした経験があるが、ＫさんとＮさんは初めて。スケジュールでは、最初の２５日間で、在宅でコード化をし、１５日間で統合する予定で開始。統合してみると、あちこちに矛盾があり、動かない。開発ドキュメントも簡単なものだけでコードを見なくては内容がわからない有様。結局、５日間の納期遅れ。工数的には、インプリメントが１５０時間オーバー。 |
| 問題点 |
・チームとして機能していない
・作るべきシステムの仕様が明確になっていない |
| 処方箋 |
・ＫさんとＮさんのプロジェクト計画へのコミット
・ＫさんとＮさんの設計作業へのコミット |
| 解説 |
どこにでもあるような状況である。疑義はいくらで思い当たる。Ｓさんの設計ドキュメントの書き方はよかったのか、それがきちんとＫさんとＮさんに伝わっていたのか、メンバーの在宅勤務は適切な方法だったのか、Ｋさん、Ｎさんのプログラミング能力は十分だったのか、そもそも、５００時間という工数見積もりに妥当性があったのか？ など。
おそらく、これらの原因というのは多かれ少なかれ該当している。
この種のトラブルをなくすことは意外なくらい難しいものである。このプロジェクトの難しさは、２ヶ月という納期にある。短納期のプロジェクトの難しい最大の原因はチームビルティングである。車に例えれば、徐々に加速していたのでは、あっという間に納期が終わる。いきなり、トップギヤーに入れなくては、うまくいかない。誤解を恐れずにいえば、そのままトップギヤーで駆け抜けてしまわなくては、プロジェクトは成功しない。まあ、もともと、プロジェクトとはそういうものかもしれない。
このようなプロジェクトにどのようなマネジメント戦略で対処していくか。はやり、コミュニケーションをできるだけ、早期に確立し、多々ある難しさをコミュニケーションでカバーしていくしかないと思う。
そのためには、この規模のプロジェクトであれば、計画にコミットさせることをおすすめする。また、上流工程へのコミットすることをおすすめする。コミュニケーションをうまく進めることは難しいが、その理由の最たるものは、プロジェクトの所有意識である。もし、そのプロジェクトに「参加させられて」いるのであれば、コミュニケーションほど「うっとうしい」ものはないだろう。しかし、「自分のプロジェクト」だと思っていれば、コミュニケーションほど頼りになるものはないとすぐに気がつくだろうし、気づかせなくてはならない。
「自分のプロジェクト」だと思わせるには、やはり、プロジェクトの基本となる部分に対して、自分の意見が反映されていることにまさるものはない。
上に書いてある内容だけも、コミュニケーションの問題を引き起こしているものは、いくつもあるし、経験をつんだ人であれば、行間に見えるものもあるだろう。しかし、進捗会議の回数を増やしても、作業場所をまとめても、コミュニケーションルールを決めてもそれでコミュニケーションがうまく行くものではない。コミュニケーションというのは自発的な環境で、こういうハード的な動機付けよりは、上に述べたようなソフト的な動機付けを考えるべきだろう。
さらに、ドキュメントの質を上げるという対処も当然、ありうる。しかし、ドキュメントの質というのはコミュニケーションの質そのものであるということも考えておかなくてはならない点である。 |
| ワンポイント |
コミュニケーションは百薬の長 |
| 参考文献： |
