工数見積もりよりも大切なこと
ソフトウェアの見積もりをする上で最も大切なことはチーム全体でスケジュールすることだと思います。工数を正確に見積もることは難しいし、予測できない部分もある。それよりも開発をスムーズに行うためのチームの体制づくりこそが一番大切なことではないでしょうか。
これどのぐらいで出来る?
プログラマであれば誰しもソフトウェアの工数見積もりをしたことがあるでしょう。何人使ってどのくらいでプログラムが完成するか、というやつですね。
さて、この工数見積もり。あなたはどのようにして決定していますか?たいていは今までの経験とカンから「ざっとこんなもんかな」というぐあいにエイヤで決めているのではないでしょうか。
しかし現実には開発が予想通りに進むことは少ないようです。そこにはどのような問題があるのでしょうか。今回はこの工数見積もりについて自分なりに考えてみたいと思います。以前同じようなことを書いていますが、今回はもうちょっとBreak downしてみようかな。
工数の算出方法
見積もりの方法はいろいろあると思いますが、私が心掛けているのは以下のようなことです。
機能調査の時間
まずは調査にどれだけの時間が取られるかを考える。新しく使うAPIやシステム構成。今まで使ったことのない言語を使うのであれば、その習得にも時間がかかるだろう。
個々の実装にかかる時間
ソフトウェアの機能やモジュールなどの単位で実装にどれだけ時間がかかるか。個人差もあるので、このへんは経験から割り出すしかないか。言語により実装の難易度が変わることも考慮しよう。
依存関係の抽出
作成するソフトウェアが何かに依存していないか。同時並行して作られるモジュール、テストのためのデータ、等々。それらの準備にどれだけ時間がかかるか、どの程度依存しているか、影響度を見積もっておく。
なぜ予定通り進まないのか
多くのデータを元に時間を見積もっても、たいていは時間通りには進まないものです。主な原因はプログラミングが時間通りに作業できないことや、依存する他の作業や突発的な飛び込み作業なども影響するのですが、実はそれ以外に大きな要因があります。
例えば開発年数の長い人は、ソフトウェア開発に多くの外的要因が発生することを経験から知っています。このような人は実際の工数より多めにしておく傾向があります。
さらにプログラマが見積もることができない状況も多々あります。開発要因として投入された時はすでにスケジュールが決まっていて、とにかく頑張るしかないということも珍しいことではありません。このような場合、開発も修羅場となっていることがほとんどで、もはや予定云々というレベルではなくなっていたりします(汗)
本当の問題
ソフトウェアの見積もりをする上で最も大切なことはチーム全体でスケジュールすることだと思います。
ソフトウェア作成は手作業や不確定要素が多いため、工程算出はプログラマを中心として、わりとざっくり行われます。しかし本来開発はチーム全体で行うものです。スケジュールに無理はないか、見積もりは適切か。チームメンバー全員でチェックを行う必要があると私は考えます。
開発期間中もチームワークが大切です。作業が遅延したことをいち早くリカバリー。突発的な作業に対するフォローアップ。これらをチーム全体で見ることで素早い対応ができるはずです。プログラマも時間を上乗せしたりしなくなるかな!?:)
工数を正確に見積もることは難しいし、予測できない部分もある。それよりも開発をスムーズに行うためのチームの体制づくりこそが一番大切なことではないでしょうか。
過去の関連記事:
yasuhoの隠れ家 - 納期の遅れはプログラマだけの責任じゃない