あなたが小さなプロジェクトで苦労する理由

5/365 / anna gutermuth

あなたが、小さなプロジェクトや、すでにベース開発が終わったソフトの派生開発を任されたケースを思い出して下さい。ベースとなるソフトウェアの要求仕様書も、プログラムコードも、テスト結果も揃っているテーマはとても簡単なプロジェクトに見えます。さっさと片付けようといきなり開発に取りかかってつまづいた経験はありませんか。小さなプロジェクトとはいっても意外と難しい物なのです。

1. たいていの小さなプロジェクトのリスクは小さなものです。しかしリスクが全く「ゼロ」というわけではありません。小さなリスクでつまづかないように先に潜んでいるリスクを見通さなければなりません。リスク計画の作業はそんなに時間が必要ではありません。大きなプロジェクトに比べて遥かに少ない時間で終わるはずです。
2. プロジェクトの関係者（ステークホルダー）を確認して下さい。開発チームのフォーメーションと責任分担(RAM)は明確になっていますか。ベースとなったテーマに比べて、役割が変化してかも知れません、スキルレベルが不足しているかもしれません。チームのフォーメーションを描いてみましょう。大きなプロジェクトに比べ少人数ですのでこれも短い時間で終わるはずです。
3. 小さなテーマではプロジェクトスポンサーや製品要求を決めるプロダクトオーナーが割り当てられていないかもしれません。スポンサー、プロダクトオーナーが割り当てられていないなら、こちらからアサインして確保して下さい。
4. プロジェクトで要求されるQCD目標にあわせてマネジメントの詳細度をチューニングします。大規模プロジェクトで要求されるマネジメントプロセスをそのまま適用するとGO/STOPが多くなりすぎてチームのスピードが上がらないかもしれません。プロジェクトに関連するすべての部署から人を集めると人数が多くなりすぎることがあります。適正なメンバー数に絞って、シンプルなチームを編成して下さい。
5. まことに残念な話なのですが、小さなプロジェクトの事はだれも興味を持っていません。プロジェクトは誰かの思いつきで始まったのかも知れません。ビジネスゴールとプロジェクトゴールが合致していなくてギクシャクしていることもあります。もし不幸にもそのような状況のテーマであれば他の部署の協力を得ることは難しくなります。

小さなプロジェクトとはいえ、リスクは「ゼロ」ではありません。あなたがつまずく要因は実はたくさん隠れています。幸いなことに、それらの要因はたいていは解決しやすいものばかりです。プロジェクトスタートと同時にいきなり走りださないでください。ちょっとの時間を使ってリスクを見通して簡単なプロジェクト計画書を書くだけでほとんどは回避することができます。