スケジュールについてPMが知っていなければならない、絶対原則

スケジュールについてPMが知っていなければならない、絶対原則。

• 完了日を1点で見積もるのは絶対にムリだ、ということ

このことはエンジニアがタイトル買い、著者買いすべき本 - Fight the Future じゅくのblogでも紹介した本から学んだ。

ソフトウェア見積り―人月の暗黙知を解き明かす

もしあなたがマネージャなら、最低でもマコネルの「ソフトウェア見積り」は読んでおいてほしい。

本に書いてあることをそのまま実践してほしいわけじゃない。

こうした英知をベースに見積もりやスケジュールを考えてみてほしいだけだ。

自分のプロジェクトに合わせてアレンジとフィードバックを繰り返してほしいだけだ。

そうでなければシステム開発が成功しないからだ。

スケジュールや見積もりを計画することが仕事なら、以前からそれを仕事にしていた人から学ぶ。それは責務なのだから。

PMがプログラミングを学んでいないプログラマなどチームに入れたくないのと同義で、スケジュールや見積もりを学んでいないPMの元でなどプログラマが働きたくないのは理解してもらえると思う。

「Manage It!」にはこうある。

Manage It! 現場開発者のための達人式プロジェクトマネジメント

見積もりに必要なのは正確さであり精度ではない

プロジェクトの早期にプロジェクトのリリース日が何月何日になるかを特定するのは不可能だ。
それが可能なのはリリースするものや品質をプロジェクトチームが決定できる場合だけである。

精度というのは測定値の精密さの尺度であり、有効数字の桁数のことだ。

正確さとは、自分がどれだけ見積もりに近いかを意味している。

スケジューリングで気にするのは正確さだ。

つまり、タスクの期間やスケジュールの予測がどれくらい現状に近いかであり、タスクの完了やプロジェクトの終了の日時ではない。

見積もりの精度を心配しないこと。むしろ、どれくらい正確かを心配しよう。

「ソフトウェア見積り―人月の暗黙知を解き明かす」にもその説明がある。

正確性は、ある数字が実際の値にどれだけ近いかを表すが、精度は、単にある数字がどれだけ精密かを表している。

あるタスクの見積もりで「35日」と「早くて1ヶ月、遅くて2ヶ月」という見積もりがあったとする。

「35日」の方が精度が高いが、実際の作業が50日かかったとすれば「35日」は正確ではなく、「早くて1ヶ月、遅くて2ヶ月」の方が正確性が高かったことになる。

もちろん、ただ範囲を大きく広げれば正確性は高まる(遅くても10年後にはできます、など)、それでは見積もりにならないのであり、バランスは必要だ。

1点の見積もりというのは、見積もる人によってバラツキがある。

慎重な人はバッファを多く入れ、楽観的な人は到底完了しない日を完了日にする。

見積もる際に1点で完了日を考えるのではなく、幅を持たせるという意識をするだけで見積もりの正確性は多いに変わってくるはずだ。

「More Joel on Software」にもスケジュールの話題があり、それは「第20章 エビデンスベーススケジューリング」にある。

More Joel on Software

過去の作業時間記録から集めたエビデンスを、スケジュールのフィードバックとして使う。

結果として得られるのは1点の完了日ではなく、見込みの分布関数で、任意の時点に対し、それまでに完了できる確率を示す。

やはり1点ではなく確率であると書かれている。

この章は非常に興味深いので読んでおくべきだと思う。

僕は、何月何日にできるかわからないからカットオーバーの日を決めるなとか、スケジュールは不要だというつもりは一切ない。

もちろん、納期を決めなければ契約ができないといった制約があることも十分承知している。

だが、ソフトウェアの完了期日を予測できないという前提の上で、契約した納期にどのように対応していくのか、そこがマネジメントでもあるはず。

納期が近くなって、必要な機能がすべて実装できない場合はどうするのか。

提供する機能を減らすのか？

バグが多くてもすべての機能をひとまず提供するのか？

スパートすればすべて実装できるのか？

すべて実装できそうもないが、メンバーを限界まで酷使するのか？

とれる戦術は数多くある。

この前提を知らないPMのもとでは、悲しみが繰り返されるだけだ。