システム開発プロジェクトにおいて、ウォーターフォールモデルで進めていく限りは要件定義フェーズが存在し、業務やシステムへの要件をきっちりまとめていく必要がある。
ここ最近、私が携わっているプロジェクトでも要件定義フェーズの完了に向け、やらなければならないタスクに忙殺されてきたが、「なぜこうも忙しくなるのだろうか…」と誰もが、何度も悩むと思うので、自分が良く遭遇する問題点をピックアップしながら対策を考えてみたい。
- 成果物が明確に定義されておらず、当初よりやることが増えている
要件定義フェーズの開始にあたってどんな成果物を作るべきかきっちり決めておらず、いつの間にかやることが増えているパターン。まったく何も決めていないプロジェクトはそうそう無いと思うが、抜け漏れや誰がどういったフォーマットで作るかまで決めておらず、後で作業がどんどん増えていく…ということはありがち。成果物はどんな意思決定をし、どのような情報をまとめるのかを示す資料であり、後続フェーズの成果物に連綿と続くものでもある。要件定義フェーズだけ点で見るのではなく、後続フェーズ含め、面でとらえて必要な成果物定義をする必要があるのかと思う。
- レビュー工数が十分に確保されていない
レビューは通常、リードレベル等、品質を確保できるスキルを持ったメンバで行う必要があるが、たいていリードレベルのメンバは他の作業も重なっており工数が十分に確保できていないケースがある。また、お客さん側のレビュー工数を確保しておらず、結局レビューがどんどん後ろ倒しになってしまうこともある。
まず、レビュー工数はそんな片手間で出来るようなものではないためWBSに組み込みする必要がある。また、お客さん側のレビュー工数はフェーズ開始時にもらっておくよう、事前調整する必要がある
また、指摘件数が多ければ多いほどレビュー工数は増えるが、可能な限りAIに事前レビューさせることで、指摘件数を減少させることも可能になる。特に、誤字脱字や表現レベルの修正はAIで対応させることで品質・効率両面に効果的
- 課題対応が想定以上に発生し、成果物まとめやレビューに時間が取れない
本来的には、課題が想定以上に発生している時点でプロジェクトの前提や現状の品質に何らかの問題があるため、リプラン含めた検討が必要。また、その状況を把握できるようにするため、課題のチケット管理化と、進捗状況を可視化する必要がある。
具体的には残数管理、残数の消化予定の管理、消化ペースの管理（1週間に10件、等）、遅延の場合の理由、といったことが把握できるようにする必要がある。
上記のようなことはマネジメントのタスクとして、WBSにも組み込みながら工数確保して対応する必要がある。プロジェクトの作業は課題解決や分析といった華々しい作業だけでなく、こういった地味な作業も含めて地道に行うことが成功への鍵になるのかと改めて感じる。
The following two tabs change content below.
入会申込
ログイン
