■
12/9のエントリの続き。
見積もりと実工数をあわせるためには見積もりの「人日」と
実作業者の遂行能力、ここでは「消化人日」という言葉を使うが、
「消化人日」のレートを合わせる必要がある。
でないと、
10人月の仕事に5人つっこんで2ヶ月で終わらないというような
世の中にあふれた結果が待ち受けることになる。
これはおいしくない。ﾔﾀﾞ。
回想
先日「オレ人日」で見積もりその通りに遂行した短期プロジェクトがあった。
いわゆる「平均的な技術者」でも遂行できるレートで「人日」を見積もったら
多すぎると言われたプロジェクトの話。11/21より
人日が大好きな模様な人たち向けに出したゆとりスケジュール。
プログラム製作は23.7人日。
なぜだか却下くらいました。
実質工数を出せといわれて。
「人日」は「人日」でも「オレ人日」ですよ。
10オレ人日。
基準「1人日」をさっきの「平均的な〜」のとすると、レートはこうです。
『オレ人日：基準人日＝1：2.37』
ちなみにその結果は（ →11/26）
その結果は次の通り〜となった。
「10オレ人日→約４営業日分＋残作業の１営業日」
5オレ人日でした。
『オレ人日：基準人日＝1：4.74』
っといいたいところだけれども、この後の改変要望、修正がちょこちょこときた結果、
全くスケジューリングしていないところの作業が増えたので
あまった5日分のゆとりはものの見事に消え去りましたよ。
「開発するためのｽｹｼﾞｭｰﾙ」で見積もれ言われたからその通りにやってみたのだが、
バグフィックス時にこっそりと入ってくる動作変更ってやっぱりあるねヽ(´ー`)ノ
今度は遠慮のｶｹﾗもなく改修時間もｽｹｼﾞｭｰﾙにいれといたる。
検証のための準備思考
その開発言語はASP2.0でした。
ってことは単純に考えればASP2.0でのレートは「2.37」
これがJSPでもPHPでも、C++でもC#.NETでもJavaでも、
はたまた画面デザインでもDB設計でもテスト仕様書作成でもそうかと言われたらそんなことはない。
人には向き不向きがあるのです。
経験したプロジェクト、経験した言語。これらのレートは高く見積もれる。
おいらの場合、Java＆JSPで「平均開発工数5人日」→「2人日」に減らしたことがある。
C#.NET＋ASP.NETで「平均開発工数2人日」→「2時間」に減らしたこともある。
特定の状況下においてだけれども、こうなる*1
Java＆JSPの場合は『オレ人日：基準人日＝1：2.5』
C#.NET＋ASP.NETの場合は『オレ人日：基準人日＝1：8』
プログラムを作ることにかけては高いレートを誇る傾向はあれども、
これがテスト仕様書作りになるとさっぱり。
『オレ人日：基準人日＝8：1』くらいになるんでﾈｰｶというくらいに働けない。
やれないのではなくサボり時間が多くなるので結果的にそうなるという計算。
だめじゃんオレ。
検証のための準備思考その２
先のASP2.0の事例だと、基準人日とオレ人日の違いは認識していた。
オレ見積もり、オレプログラミング、オレテストなんだから何とかできる。
しかして。
見積もり工数に「作業者の実工数」という要素を含むのはどうか？
レートの概念を持たずに「10人日」といわれたらだれでもこなせると思ってしまうのでは？
という懸念が消えない。
他のプロジェクトで見積もられた「人日」「人月」は何を基準にしているのだろう？
人は己の知りえる範囲で想像するものだ。
ゆえに見積もった人、その周辺、外的圧力、現在状況などによって
その時に選択する「基準」は違うのではないかとしみじみ思ってみる。
そう思って身の回りの事例にｸﾋﾞをつっこんでみたらﾁｮｺﾁｮｺあった。
焦げ臭いところに行っているから問題が表面化している様が見れたのだろうがヽ(´ー`)ノ
それを踏まえると。
事例検証でもしてみる
★「10人月を2ヶ月でやってください」
この事例にあたるとき。
まずやるべきは「見積もり時の基準は何か」を調査することが大事なような気がしてくる。
見積もりの基準レートが1なら10人月そのままだが、
基準レートが0.8であったりすると8人月になるのでゆとりがあることがわかる。
基準レートが1.5であったら実際の規模は15人月になるので気をつけないといけないし、
基準レートが2だったりした日には20人月になります。
こうなると人員を集める前に事例を持ってきたヤツを締め上げないといけない気になってきます。
(..´Д｀)＜要員をよこせ！ってかレートの高い人材をよこせ！！
と言いたい声にも気持ちがのりそうです。
★「10人月を2ヶ月でやってください。要員はあなたを含めて5人ですから大丈夫ですよね」
一見、まっとうにみえるこれも基準レート次第で事情がかわります。
見積もりの基準レートが1なら10人月そのままは変わらず。
しかして要員の消化人月レートが1を割っていたらどうなるでしょう。
消化能力が足りなくなります。
ついでに集団も4人を超えると管理コストを気にする必要も出てきます。
つまり要員5人が「消化人月レート：1」ではこのプロジェクトﾔｳﾞｧｲよ！ということになりそうなことを示すのです。
現実問題「平均的な技術者が5人」もきれいに集まるわけがありません。
だいたい「新人」とか「できのわるいの」とかくっつけられます。もしくは潜んでいます。
消化人月レートが「1.5、1、1、0.5、0」だとふつーに5人月に足りません。
( ﾟ∀ﾟ)＜優秀なあいつがいるやん。だからなんとかなるやろ
ってなことを言われてもわかりやすい数値をもって反論すれば一矢は報いれそうです。
今日のまとめ
レートを使用した場合なにが出来そうか？
→ 人月を用いての納期設定や要員配置について今より詳細な検証が行える。
検証が行えるとよいことがあるのか？
→ 不具合が出る個所、出ない個所が事前に判明する。
事前に判明する必要はあるのか？
→ 失敗してから、もっとはやく手をうつんだったと後悔しなくてすむ。
なぜその時後悔するのか？
→ 支払うコストが「失敗してから」＞「もっと早く手を」＞「今考える」の関係で多いから、今のほうが安くつく。
情報は事前に知っておくほうが得をするということになりました。
っということでトータルコストの削減が行えそうです。
リスク回避の意味合いが強そうです。
(,,ﾟДﾟ)＜それでレート設定はどうやるの？
過去の事例よりなんとなくレートは割り出せました。
が。
新規案件になった際、過去事例がない場合にはなかなか算出しにくいですな(;´Д｀)
また考えよう。
当面は開発経験がある＝１、ない＝0.1で仮決めしてあとは随時修正の方針でいくことにしよう。
何事も試してみないことには改修ﾎﾟｲﾝﾄが捕らえにくいものです。
*1:一応両方ともDBアクセス有りのプログラム
