必ず行ってください、間違ったら取り返しがつきません。自分で何度も見直すことも重要ですが、ほかの人と比べる、ほかの手法と比べることをしてください。
見積もりが違ったら、その原因を探る、難しさの見積もり誤りがあったり、見積もり漏れがあるかも知れません。
できれば、主観的見積もりと客観的見積もりをくらべ食い違いがあった場合に規模、生産性、見比べて差の原因を探ってください。何等か見落としや前提条件の思い込みなどがあるかもしれません。
不安がある場合は、その分をリスク費として原価に追加しておくことも必要です。
ただし、不安だからと言って見積もりを膨らませるとそもそも受注できなくなります。
連休なのでこの辺で・・・
見積もりにはすべて前提条件があります。それらが崩れるとき見積もりはずれます。お客様が予想に反してわがままだったり、行間にものすごい仕様が隠れていたり。この不測の事態に対しても見積もりは必要です。リスク管理です。
チームリーダレベルでは権限範囲の①想定リスクをあげて②何等か対応をしておき③リザーブを確保しておくことが必要です。
リスクを上げると、それを回避するために何をするのか決めなければならない風潮があったりしますが、リスク対策は「リスクファイナンス(お金を確保する)」と「リスク予防対応(起きないように何かする)」「許容(リスクが発生してもあきらめる)」などがあり、明らかにしたうえで分析をし、リスクを許容することも対応の一つです。
スケジュールは見積もりを左右する重要な要素です。実際にはやることがスケジュールに反映されますから、それらを行う工数が見積もりから漏れていないか、それらのスケジュールの前提となる条件整備の工数が見積もられているか。
無理のない長さのスケジュールになっているか。最適な生産性を生む期間から短くする場合はその分のオーバーヘッドを考慮した見積もりになっているか。期間に人を割り当て、その人をその期間に確保できるのか。などを考慮します。
そのためのいろいろなツールもあります。WBSや人積表などがそれに当たります。
結果的には妥当性のある見積もりには妥当性のあるスケジュールも一緒についていないと意味をなさないのが一般的です。計算で出す工数は限定的な作業しか入っていないうえに最適な生産性を出す期間がいただけることが前提になっているからです。
最適な生産性が出せる期間(この期間は開発内容チームの実力によって変わります)より短く期間が設定される場合目に見える形で工数を増やす必要があります。
以上の見積もり手法を駆使して見積もりをするわけですが、同じような見積もりでも業界やお客様によって見積もりの結果が変わります。
たとえば官庁系見積もりなどではサーバを一台構築して立てる場合(開発なしで構築のみ)でも結構かかります。納品物、試験等がたくさんあるためです。
一方、研究所などのスーパーコンピュータの構築、たとえばLinuxサーバを１０００台単位で入れるわけ(１０００ノード)ですが、１台当たりの構築はその1/100程度の工数で行います。構築手法が違うからなのですが、それでも納品物、要件的義とかの客先対応などの文化(前提条件)の違いからくるものが多分にあります。それぞれ人を入れ替えて見積もりさせるととんでもないことになります。莫大な工数になり受注できなかったり、過少見積もりになり、客先要件を満たさず納品が完了しないなどがおきます。
また、開発方法の工夫や、ミドルウエアの利用で生産性を上げることができます。共通チームのようなものを作り、いろんなところで使われるモジュールはライブラリ化してそれぞれで開発しなくていいようにしたり、仕様を単純化して難しくない実現方法に誘導したり、フレームワークやミドルウエアの利用は普段から行っていると思います。皆さんもこの点はいろいろな工夫を持っていると思います。それらを駆使して工数を減らします。
その他、考慮すべきこととして
スキルレベルの考慮
スケジュール
リスク
見積もり検証
があります。リンクを参照ください。
作業を細かく分解してそれぞれ単純に何をするかイメージがわくレベルにして、そのするのに必要な工数を積算していきます。
ここで重要なのは「実際に何をするかイメージできるレベルまで作業を分解する」ということです。
この方法は開発外作業(研修教育など)・構築作業などの見積もりで使います。根気のいる作業ですが地道に行っていきます。
ＷＢＳを作るという作業は例の変な表を作ることではないことを知っておいてください。「作業を分割してイメージがわくレベルにすること」です。
細かく分解すればするほど工数が大きくなる場合があります。これは作業の分割単位と見積もり単位があっていない場合におきます。
単位が「月」であった場合最少は1M(月)になってしまいます。1W(週間)でできるタスクに分解した場合に最少の１を入れてしまうと３W(週間)分１２０H(時間)のずれが生じることになります。
作業単位が「D(日)」単位で終わるようなものであればH(時間)にすべきです。一つ下の単位を設定して見積もってもらいます。
単位をM(月)のままで０．１とかやめてください。０．１M(月)は２D(日)です(１６０時間前提)当該作業が２日間＝１６時間かかるのかの考慮をするのが嫌になり、妥協することがあるからです。
見積もり精度、分解粒度に合わせて単位を適切に設定してください。
見積もり妥当性を見る場合は、単位に応じた見積もり精度を前提にレビューすることになります。(つまり細かくすればよいものではないということ、余計な突っ込みを受けます。)
部分見積もりの妥当性が無ければそれ以降も見積もり検証をする意味がないと判断され、再見積もりになりますから注意が必要です。
自分が見積もったものと、自分以外のチームメンバの見積もり、あるいは別手法で見積もった内容を比べます。
できれば、主観的な見積もり(勘など)と客観的見積もり(FP法など)を出すのがいいかもしれません。同僚とか、社内のほかのチームとかに頼む手があります。協力会社の方(下請けさん)に開発をお願いする場合は自分の見積もりと協力会社の方の見積もりを使うのがよいでしょう。
協力会社の方にお願いするとき、注意すべきなのが発注する気がない場合、相見積であることを協力会社の方に伝えてください。彼らは見積もりをお願いすると場合によっては受注できるものと思い込んで人を増やしたり準備を始める場合があります。そもそも発注する気がないのに見積もりをお願いすることはナンセンスなのですが・・・
コンペの形式をとってもよいと思います。もし、他社より条件が合えばお願いすることを前提にお願いするべきです。
協力会社の方に損をさせたり損害を与えたり、信頼関係を壊すようなことが無いように慎重に行動してください。
ファンクションポイント法といわれる手法です。おもに、WEB画面系のDBを使った単純な業務画面の作成を見積もるのに適しています。
係数が多く、ご自身の組織で使われており、ツールがあり、統計情報が集まっていないのであればちょっとハードルが高いかもしれません。
使う場合はご自身の組織のマニュアルを参照されることをお勧めしますのでここではあまり説明しません。
いろいろＷＥＢ等から探すと概略がわかるのですが、ちょっと使えないと思います。なぜか。
FP法はたくさんの係数を持っています。これらの係数は各PJに応じていじられるものです、わからないからとデフォルトで使うのはやめてください。つかいかたがわからないのであれば、必要な精度で見積もりを成功させている経験者の指導を仰ぎながらやってください。安全方向に倒しながら見積もりをすると、このFP法は最終的な工数が莫大なものになります。小さな係数の影響が最終的に大きなものになる可能性があります。(イ)機能見積もりと比較して莫大な工数になることもしばしばです。ご注意を。
前に似たようなものを作ったことがあって要求内容やレベルが同じであるならば、おなじ規模や工数でできるはずです。
これに違う部分を考慮して増減させたり、別手法で計算した規模を足すことで見積もることができます。
過去に同じような開発をやったことがあることが前提ですが、これは自分でなくてもよく、ほかのよく知っている人や組織で行った頃があるのでも良いです。
ただし、この参考にする元見積もりは、よく理解することが必要です。ヒアリングをして、実態はどうであったのか、今回の例と違うところはあるのかないのか、お客様の性質はどうか？全体が使えなかった場合部分で参考にできるところはあるかなど冷静によく考えます。
この例で失敗するのは前提条件やお客様の性質が違い、本来参考にならないのに参考にした場合や、実態が報告と違い、うらで相当苦労をしていたり、裏ワザを使っていた場合などがあります。
自分の経験でない場合は詳細なヒアリングを実施して参考にするようにしてください。
不確定要素は必ずリスクへ・・・
この機能だったらこのくらいという勘です。経験がものをいう見積もり方法ですから、このお客様でこのような開発をしたことがあって十分な経験があり、信用できる人がすべきです。お客様を経験したことが無かったりこのようなシステムを開発したことがなければ、求められる内容が違ったり、余計なことをさせられたり、いつもはこれでよかったはずだったり、うまく実現できなかったり、必要な機能が基盤になかったりして、見積もりが大きくぶれることになります。
正直言うと、個人的には、何を作るか正確にわかっており、このお客様でこのような開発をしたことがある信用できる人がいるならばもっとも正確な見積もりであろうと思っています。
実態はベテランによる勘です
これはチームリーダのときに絶対にできるようになってください。将来、PMになった時に見積もり妥当性を見極めるスキルにつながります。
この勘を経験により養うことは非常に重要です。偉くなればなるほど、大きな、あるいはたくさんの広い範囲を見る必要が出てきますので細かく見る時間はなくなります。
この時重要なのが勘です。勘は ヤマ勘ではなく、経験(統計)に基づくレベル意識です。「このような案件のこのような要件であればこのくらいだろう。」という感覚です。何度も書きますが、この段階でこれを養うべく、経験を積んで絶対に何となくわかるようになっておいてください。
ステップ数、ライン数、機能数から工数を割り出す手法です。これらの方法をとるためには、統計的にたとえば１０００ステップ(1KStep)や１０００ライン(1KL)作成するのに大体何時間の工数がかかるかを知っている必要があります。この1KStepあたりの時間が生産性などと呼ぶ組織もあります。単位時間当たりの標準生産量からの比率を生産性という場合もあります。ここでは文字数が少ないので1KLを例に話します。キロライン当たりの時間を基準にする場合「H/KL」という単位で記載します。規模のKLが計算できればこの「＊＊H/KL」を掛ければ何時間の工数が必要か計算できるわけです。求められる工数の単位が「人月」(一人が一月間必要)であるならば一月の時間数(一月は４週間、一週間は５日間、一日は８時間とすると１６０時間)で割れば計算できます。
ここで気を付けなければならないのは、「生産性は案件によって変わる」ということです。難しければ生産性が落ちますし、開発言語によっても、もとめられる品質などによっても変わりますので、適切に生産性を過去の事例や自分の経験からいじる必要があります。
ここまで規模がわかっている前提で話しましたが、規模の妥当性に関しても精度を上げていく必要があります。これらは（ロ）～（ニ）の見積もりを用いて求めていくことになります。
