プロジェクトに配属されてから6ヶ月が経過しました。
その間、仕様変更の対応で詳細設計から製造、単体試験、結合試験、総合試験という一連の作業をいくつか担当してきました。
こうしてシステムのことも、開発のことも、少しずつわかってきたなぁというところで、新しい仕事がやってきました。
「見積もり」
5月上旬から6月下旬にかけて、合計7機能の仕様変更・故障改修見積もりを行ったのですが、システム改修の見積もりは初めてのことでした。
そこで今回は、初めての見積もりで私が何をしたか、そして今度見積もりをするときはどんなことをしたらいいのか、経験をベースにしてまとめたいと思います。
■初めての見積もりを振り返る
見積もり着手から最終レビューを通るまでの過程を案件ごとに振り返ってみました。工数出し直してースケジュール策定のための再見積もりー
改修にどれくらいかかる？ー故障改修見積もりー
これやったら工数いくつ？ー具体的な要求から見積もるー
最終的にこうしたいので宜しくー漠然とした要求から見積もるー
■見積もりのポイントって何？
いくつかの見積もりをしていく中で得た見積もりのポイントを整理したいと思います。あくまで今の私が思ったポイントですが、敢えてこれ以上のインプットをしないまま書きだしていきたいと思います。
①要件を明確にする
何をするにも目的は大事ですね。
見積もりの際の目的は今回のケースでいうと3つあると思います。
1.できるのか、できないのかを知るためのもの（工数とおおまかな実現方式）
2.内部資料（故障の改修など、要員確保や他チームとの調整を行うベースとなる）
3.スケジュールに落とし込むことができる精度の高いもの
目的別に、時間をかける場所がどこか、どの部分にどのくらいの根拠が必要かが変わってきます。
例えば、1のようにお客様もまだやるかやらないかわからないような状況で、おおまかに工数や改修内容を把握したい場合に細かな分析をする必要はありません。
逆に3のような細かな見積もりを行い、スケジュールに落としこむ場合には、見積もりの誤差によってはリスケが必要になってしまします。
見積もり時点で工数に影響すると思われる箇所があり、かつそれを数値化できないのであれば、懸案事項としてとりあげ、リスク管理をしておかなければあとで残業まみれの大変な状況になってしまうかもしれません。
②試験は観点を明確にする
どのような試験を行うかは直接試験工数に影響します。
試験観点が不明確な見積もりは、試験内容と工数とに乖離を招き、意味不明なものになってしまいます。
試験内容と工数の関係性が明確な記述をすべきです。
試験内容を記述する際に注意すべきは次のような内容です。
・結合試験、総合試験でどのような観点で試験を行うのかがわかる記述にする
・開発対象と試験のかかわりがわかるようになっていなければ、客観的に理解できる見積もりではない
（なんでそんなことするの？と思われないような内容になっているか）
・工数が妥当であると判断できるレベルで記載する（工数がかかるポイント、軽くできるポイント）
例えば、試験工数が大きくなる要素として「改修箇所以外の業務に使用する試験データも準備が必要である」というような記述をしておけば、工数の妥当性を訴えることができます。
他にも「定期的なイベントに合わせて試験を実施することで工数削減ができる」というような記載があれば、さらに検討の余地があることを提示できます。
また、試験観点、試験内容を明確にすることは、影響範囲を明確にすることにもなります。
③自分以外の人がその見積書を説明できるか、の観点で見直してみる
実際には営業担当者である場合がほとんどだと思われます(明確に役割を定めているようなプロジェクトであれば)。
つまり営業担当者が見てお客様に説明できる内容になっていなければ、お客様の同意を得るのは難しくなってしまいます。
そこで、「システムの中の人」から一歩離れて、お客様の立場になってもう一度見積書を見直すことが必要です。
客観的に評価することはなかなか難しくもありますが、チーム内外のレビューを通すなどして、より客観的な文書にしていくことで、わかりやすく明確な見積もりにすることが可能だと思います。
もちろん、どの程度文書として整理していくかの度合いも①で述べた目的によりけりかとは思いますが。
あとがき
こうして私の初めての見積もりは終わりました。ベースとなるような知識もないままにがむしゃらに取り組んだわけですが、まだここから、というところです。
今度はまとまった知識をインプットするなり、過去の事例を見るなしりて、次の見積もりでどう考えられるか、何をアウトプットできるかという段階に移って行きたいと思います。
Go to The Next Door.
