以前に書いたエントリーですが、もう3年も経っていました。それから状況が変わったかというと、システム業界の状況はあまり変わっていないように見えます。ただ、SIerは増々勢いを失い、自社製品の開発に携わるエンジニアの割合が増えたように思えます。
自身も、この記事を書いた頃は受託開発を行っていましたが、今では自社プロダクトの開発に携わるようになりました。
自社開発だからって、工数見積がなくなるわけではなく、今でも見積もりの問題は多くのエンジニアを悩ませています。
てなわけで、Qiitaでこんな記事を見かけたので、触発されて見積もりについて少し書きたいと思います。
この記事では、自社プロダクトをアジャイルで開発するというシチュエーションが前提として、様々な技法で「見積もりを正確に行うこと」を目指しています。また「状況に変化があったらアップデートすること」も大切だと言っているのだと思います。
確かに、正攻法だとこんな感じになると思いますが、自分は不真面目なので、搦め手から攻めたいと思ってしまいがちです。
冒頭の記事では、見積もりの内容よりも「覚悟」が大事だと語りましたが、自社プロダクトのようなケースだと、もう少し粒度を小さくできるので、覚悟を決めるよりも見積もり自体をなくしてしまって、「できた時が完成」方式にしてしまうのがたったひとつの冴えたやりかたって奴です。
「そんなの無理だ」と思った方も多いかとは思いますが、見積もり自体無理ゲーなので、見積もりを無くすのとどっちが無理ゲーか？という比較をする価値は十分にあると思っています。
そしてそのために、
- 作業単位をなるべく細かくする
- 管理者がある程度の作業量とリスクを判断できるようにする
- 結果で判断する
- チーム全体のスループットを定量的に測る
- できないものはできない(あきらめる)
などの方法を試してみるのはどうでしょうか？
見積もりを無くすことによるメリットはこんな感じです。
- 見積もりにかかる時間がなくなる
- 余計なバッファを積まなくて良くなる
- 積んだバッファを無駄に消費しなくて良くなる(小さな予算消化！)
- リスクの顕在化が早くなる
- 結果に注目し、正しい評価ができるようになる
全体的に、開発がスピードアップし、スループットが上がります。
管理者の仕事は、経営陣や上司が要求してくる「見積もりしろ！」という圧力をはねつけることです。
自身のチームのパフォーマンスを最大化するために必要な措置をとるのがマネージャーの仕事なので、安易にパフォーマンスを悪化させる不見識に屈してしまうことが無いように頑張って戦いましょう。
現代のビジネスでは、全てがダイナミックに変化し続けるので、ここのタスクの計画や締切よりも、スループットや柔軟性を以って組織の価値を判断するようにしていきたいものです。
もちろん、中には締切がマストなタスクもあるので、その場合は締切の設定とともに、そこに入る内容を取捨選択しましょう。予算・品質・納期は、全てをいっぺんに揃えることはできません。特に納期が絶対であるならば、予算と品質で調整するしか無いのです。
- 締切から逆算する
- リスク評価を最速で行う
- バックアッププランを可能な限り用意する
- 人員配置や補給など、最善を尽くす
などの手を尽くして戦うしかないです。
ご武運を！
