マイルストーンの要件定義をプロジェクトメンバーに共有する必要性
ゲームに限らず、システム開発には、大概、マイルストーンが設定されている。
例えば、α版であるとか、β版であるとか。
時折、マイルストーンの要件がプロジェクトメンバーに伝わっていない現場に遭遇する。
そこで、マイルストーンでなぜ要件を詳細に伝える必要があるのかについて書きたい。
問題の背景
そもそも、マイルストーンは、その性質上、マスターアップの様に、クオリティーや必要な要件は明示的ではない。
マスターは、製品版に対する締めであるため、当然ながらクオリティーも実装する必要も仕様も全て、製品レベルである。
一方、マイルストーンはマスターアップに至るまでの途中で設ける節目にすぎない。
どういった仕様を実装し、どれだけのクオリティーにするのかは、プロジェクト責任者が任意に設定する必要がある。
必要性1:どの仕様を実装すべきがあるかがわかる
プロジェクトの要件定義を知ることで、プロジェクトメンバーは、どういった作業をいつ終わらせればいいか考えられるようになり、細かく作業のスケジュールをたてられるようになる。
スケジュールを管理するのは、プロジェクトマネージャー(PM)やディレクターの仕事ではあるが、メンバーの全ての作業に対して、期限を切ることは現実的ではない。
どこかで、メンバー個々人によって決めてもらう必要がある。
マイルストーンの要件定義を伝えることによって、個々人が、マイルストーンに向けた作業の計画を建てられるようになる。
ひいては、PMやディレクターのスケジュール管理に対するコストは幾分か減る。
必要性2:どの要件を落とせるのかがわかる
マイルストーンは、スケジュール管理を効率よく行うためにおかれるものである。
よって、必ずどの仕様をいれなければならないといこと本来はない。
仕様A、仕様B……仕様Dまで必要と決まっていても、Dを入れるために、徹夜で残業する必要はないのである。
マイルストーンが、どういう意味を持っているのかの意図や意味を伝えることで、プロジェクトメンバー各々が要件に対して優先順位をつけることができる。
仕様Dを入れるために、仕様Bを落とすといったトレードオフをプロジェクトメンバーの個々人が判断できるようになる。
もちろん、勝手に判断し、それを実行されると困るが、作業者自身が考え、どの仕様を落としてどの仕様を絶対に入れるかを、PMやディレクターに提案できるようになれば、PMやディレクターが判断を下すまでのコストが下がる。
また、要件定義の詳細や意図を伝えずにいれば、どの仕様もいれなければならないとプロジェクトメンバーが思い込んでしまい、無理に残業しかねない。
このご時世、それはまずいだろう。
まとめ
マイルストーンの要件を明確に示さなければならない理由は、それがマイルストーンだからである。
マイルストーンは、プロジェクトの進捗を図るために設けられるものであるはずなのに、それに向けて作業者が無理やり作業をつめこんだり、逆に、そのマイルストーンまでに必要な作業がなされていなければ、マイルストーンの本来の目的が損なわれる。
〈スポンサードリンク〉