2007-08-11
■概算見積もりという罠をチャンスに変える方法
プロジェクト参画が決まると、プロジェクトリーダに課せられる最初の仕事として「概算見積もり」があります。
概算見積もりとは、顧客にある程度の規模感を伝えるものであり、確定した金額を確約するものではありませんが、ここで甘い見積もりを出すと、その後の正式見積もりに対する足かせになります。
かといって、膨らませすぎると営業やマネージャにたたかれ、挙句の果てには彼らの言い値になってしまいます。
では、どのような概算見積もりの出し方が納得されるのでしょうか？
僕の知る限り、概算見積もりの段階ではプロジェクトリーダの経験と勘を頼りに、規模を算出します。
その方法は「これくらいかな〜」というあいまいなものばかりでした。
これにちょっとだけ、客観性をプラスすることで、状況は劇的に変わります。
客観性をプラスする方法、それは、ステップ数による見積もりです。
ステップ数による見積もり
まず、職場でこれまでに行われたプロジェクトのソースと、スケジュールを入手します。次に、そのプロジェクトの要員投入実績を入手します。
これで、ステップ数とトータル工数がわかります。
たとえば、Javaでアプリケーションサーバを10人月10000ステップで作ったのであれば、その職場における生産性は、1000ステップ1人月です。
注意点としては、スケジュールから職場で担当した工程を把握することです。
企画は顧客がやっていた場合、仕様策定〜設計〜製造〜単体テスト〜結合テスト〜導入・現地テストを行う工数が、1000ステップでは1人月ということになります。
このデータがそろったら、参画するプロジェクトの総ステップ数が読めれば「ある程度客観性のある概算見積もり」の完成です。
では、概算見積もりの段階で総ステップ数をどのように見積もればいいでしょうか？
機能数からステップ数の見積もり
またも過去のプロジェクトからデータを抽出します。
1人月あたりのステップ数を導き出したプロジェクトにより作成されたシステムが、
- 何機能あるか？
- 何クラス（何モジュール）あるか？
を調べます。
機能数に関しては、詳細機能でも大機能でもいいです。
クラス数は、手を入れた形跡のあるものはすべて含みます。
これで、1機能が何クラスで生成されているか？を理解することができます。
あとは、そのプロジェクトで作成した総ステップ数をクラス数で割ります。
最終的には、
1機能がXクラスでできており、1クラスがYステップ数でできており、1人月でZステップ組める
という指標が出来上がります。
あとは、概算見積もり時点の要求で、機能を把握することに努めればよいわけです。
とはいうもののデータがないという状況の方は、
というところから進められたらいいと思います。
ここまで説明してきましたが、概算見積もりはどこまで行っても概算見積もりです。
「結局、機能数は勘でしょ！？」といわれる方もいらっしゃると思いますが、要件が変われば、規模は変わります。
よって、厳密に見積もる方法は無いと言っても過言ではありません。
ただ、これくらいかな〜と思いながら作った概算見積もりよりも、自分を含めたプロジェクト参画者の腑に落ちた概算見積もりを作ることが、半年後のあなたに吹く風を向かい風から追い風にしてくれるはずです。
Permalink | コメント(0) | トラックバック(0) | 23:33
2007-08-05
[ソフトウェア開発]
■プロジェクト開始直前における危険予知
リスクマネジメントとか、そういう話ではありません。
まず、プロジェクトに参加すると決定したときに、ある程度の心構えをしようというお話です。
- 納期が相談できるプロジェクトであるか？
たとえば組み込み系のプロジェクトの場合、製造ラインという後工程が控えていますので、なかなか納期の相談はしにくいです。
オープン系においても、カットオーバーを公言しており、納期調整は難しいという場合があります。
雰囲気だけでもいいので感じ取っておきたいところです。
- 追加要員を投入できる環境に（予算に余裕が）あるか？
さまざまなリスクに対し、時には遅れを追加要員で取り戻さねばなりません。
が、予算的に余裕がない場合は会社としても許可しにくいので、なかなか応じてくれないのが現状でしょう。
予算管理に口が出せる立場であれば、必ず確認し、そうでない場合も雰囲気は感じ取っておきましょう。
- 顧客に不安定なマイルストンがあるか
納期までの間に「この時期にデモやってほしいんだよね〜」とか、「β版を提供してもらうかもしれない」など。
この手の要求は一気にプライオリティが高くなる可能性を秘めています。
よって、何個くらいありそうか、どんなタイミングかは、線表に載せないまでも知っておいたほうがいいでしょう。
まぁ、大体こんなところでしょうか。
ここまで読んでどれかひとつでも自由にならない項目があれば、そのプロジェクトに関わる人は定時には帰れないでしょう。
納期の相談は、顧客責任の遅延要因があれば当然の権利ですし、追加要員の余裕を見ていない要員計画なんて規模が大きくなればなるほど絵に描いた餅になることでしょう。
そして、顧客都合のマイルストンは「言った言わない議論」に発展するの揉め事の原因No.1だと思います。
これらの要素があるプロジェクトを受注してしまうマネージャは、基本的に無能です。
まず、マネジメントの観点でこれらの不安材料を取り除くべきです。
でも、この手の不安材料は確実に現場にそのまま手渡されます。
なぜなら、マネージャは現場が「できない」と言いにくいことを知っているからです。
純粋にプロジェクト参画を打診された人にできることは、２つ。
- 断固拒否する
- 炎上覚悟で参画する
ただし、いろいろなことを省みずに1度はとっておきたい行動として、
- マネージャの無能さを、さらに上位の管理職にチクる
というのもあります。
プロジェクト参画の相談は、システムエンジニアにとってみればうれしいものです。
しかし、そのときに冷静になれるかどうかで、半年後の自分の状況は大きく変わるということを自覚しておいたほうがいいと思います。
Permalink | コメント(0) | トラックバック(0) | 22:11