今回のテーマはプロジェクト推進計画である。システムの仕様が固まると、いよいよ開発プロジェクトが動き出す。プロジェクトを何とかスムーズに進行させるためには、まず推進計画とそのフォロー計画をしっかり立てなければならない。
 |
あいまいな要求仕様をベースに開始されたシステム開発プロジェクトの多くは、仕様が固まるのに時間がかかるだけでなく、一度決定した仕様にもしばしば変更要求が出て後戻りせざるを得なくなるなど、まさに闇夜の航海のような困難な状況に追い込まれる。
こういう闇夜の航海に必要なものこそ、行き先を照らす灯台明かりである。
困難なプロジェクトを引っ張ってくれる灯台明かりとは、プロジェクトが目指す明確な目的や方針だ。プロジェクト開始時点から、明確な目的や方針がしっかり明示されていれば、途中でいろいろ問題が発生してもチームの士気を高揚し、これを維持することにより、何とか無事乗り切れるであろう。
どんなシステムにも特徴があり、目的や目標があるはずだ。やりがいのある、分かりやすい目標を掲げたいものである。
 |
プロジェクトの開始に当たって、リーダーはチームのメンバーを集め、開発しようとしているシステムの目的や基本コンセプト、プロジェクト運営の基本的考え方、プロジェクトの共通基準、工程計画の土台となるリーダーの考え方などを説明し、全員に理解してもらう必要がある。プロジェクト・リーダーが推進方針・設計方針を明示してくれなければ、チーム・メンバーは具体的な作戦を決められないからだ。
こうした会合は通常、「キックオフ・ミーティング」とか「出陣式」と呼ばれることが多い。チーム全体のモラルを確立するためにも大事な会なので、ある種の演出も必要であろう。全員ミーティングは、キックオフ・ミーティングのほかに、主要メンバーがそろい定期的な進捗管理が始まった時、全メンバーがそろった時の少なくとも3回は実施したほうがよい。
 |
キックオフ・ミーティングには、顧客側のプロジェクト責任者にも来てもらい、闇夜の航海を先導する灯台に明かりをつけてもらおう。ベンダー側の担当者の前で、これから開発しようとしているシステムはどういうものなのか、どういう目的で開発するのか、どういう経営的効果が期待できるのか、などを直に話してもらえることは、とてもありがたいことであるし、担当者の大きなやりがいにつながるはずである。
ベンダー側の担当者が、顧客幹部の話を聞く機会はまずないだけに、直接話を聞ける効果は絶大であろう。何よりも、自分たちの仕事が単なる歯車役の仕事ではなく、顧客のために大いに貢献できることを実感できるからだ。そして運命共同体として顧客と一緒に同じ船に乗っているという感覚を味わうこともできるからである。
 |
多数のメンバーが参加する大規模プロジェクトでは、設計基準、進捗・変更管理、報告や各種会議の方法など、共通ルールを決めておく必要がある。しかし、これらのルールを、必要になるたびに行き当たりばったりに決められては、メンバーとしてはなかなか守れないし徹底できない。ルールを設定することは基本設計の重要な課題と考え、プロジェクト開始時にきちんと決めることが肝要である。
統一ルールがすでに定められている組織も多いだろうが、プロジェクトは、大きさ、難易度ともに千差万別であり、顧客によっても状況は異なるだけに、ルールの追加が必要になることもあれば、共通ルールは重すぎて効率が悪いという場合もある。プロジェクトに合わせた、ルールのカスタマイズを検討することも必要だ。
