このブログを4000日以上続けてきて、一番見られているエントリが
１人月あたり、何ステップ？１画面あたり、何人日でできる？の考え方
http://blog.goo.ne.jp/xmldtp/e/513c525aa1b41929a7e8c49f66ba35b8
なんだけど、さすがにエントリが古くなってきたので、
書き直してみる。
■何日で出来る？の変化
昔と違って、何日で出来るというのは、自動生成技術やフレームワークの影響で
変わってきた。昔は、ソースコード量だったが、
・そもそも、ソースコードが自動生成部分を含むのかどうか分からない
・自動生成で全ていけるのかどうか、わからない
・ソースコード以外の要因が増えてきた
ということで、ソースコード量で、実際には決められなくなってきた。
■日数の決め方には、３種類（＋１種類）ある
そこで、開発にかかる日数を先に決めて、ステップ数をつじつま合うようにする
のが、早い道のりになってきた。
日数の決め方には３通りある
（１）類推事例法？っていったかな？
似たような事例をもってきて、その開発日数から割り出す（類推する）
→大手が良く使う方法
（２）特徴量によって
画面数、DBテーブル数などによってきめる。FP(ファンクションポイント）
がこれにあたる。COCOMOなどもこれ
（３）積み上げ法
システムを細かく分解していき、その分解したブロックにかかる時間を
つみあげていって、日数を決める方法。WBSが作成できないとできない。
→中小がよくつかう方法。実際には、これでやると、日数は大きくなり、
この日にちで見積もった分だけは、もらえない。
しかし、実際にはこの方法ではなく
（＋１）納期逆算法
納期が決まっている。ということは、開発日数は、何日で「行わなければならない」
と決まっている。この場合、スコープを変更したり、クオリティをコントロールしたり
する。アジャイル開発などは、この方法になってくる。
がよく使われる。
■MVCの場合の決め方
では、具体的に日数を決める方法について。
開発にかかる日数を出すには、積み上げ法以外では、決まっている。
（→この章をとばし、「日数が出たら全体ステップ数→１日あたりのステップ数」へ）
積み上げ法の場合、作業を全て出すことになる。
ここでは、MVCのような画面系の場合を例に考える。
すると、実装までに以下の作業がある
V：画面・帳票
画面共通部分のレイアウト、作成、確認
必要部品の開発、確認
画面割り
各画面の
項目・イベント動作決定、確認
レイアウト作成・確認
部品配置
エラーチェック（バリデーション）実装
各画面テスト
結合テスト
※画面数は、利用するシナリオを考え、データ入出力場面
を検討すれば、出てくる
M：モデル＝DB部分と業務ロジック
DB部分
全体の設計、確認
各DBの
作成
DBアクセス部分作成
業務ロジック
共通部分の設計、確認、実装
各業務ロジック（イベント数→画面から割り出せる）設計、確認、実装
業務ロジックテスト
結合テスト
データ設計、データ投入
※DBのテーブル数は、画面帳票の項目をどのテーブルに入れるかを考えると出てくる
これを正確に行うには、正規化する
※業務ロジックは、同期型の場合は、画面イベント数となり、具体的には、ボタンを
押したときなどに対応する。非同期の場合は、AJAX呼び出しになるので、この限りではない
が、推測は出来る
C：コントローラー
モデルをつなぐ（自動的に作れてしまうことも多い）
このうち、設計、確認、実装という言葉が何度か出てくるが、
このなかで、なにが、一番時間がかかるかを確定する。
それには、
１つの画面、１つのDB、１つの業務ロジック、１つのコントローラー
ができるまでのストーリー（シナリオ）を考える
そうすると、意外とクリティカルパスになるのは、確認になる。
以下、確認、実装、設計それぞれのクリティカルパスになる場合の
日数の求め方。
■確認が、業務の足を引っ張る場合の日数決定
お客様に確認を取らないと先にいけない場合、
１回のミーティングで何画面検討できるか、
ミーティングがどれくらいの頻度で開けるかを考え、
画面数を決定する
お客様でなく、レビューで時間がとられる場合も同じ。
実装にかかる時間＜会議時間の場合は結構ある
■実装が、一番かかりそうな場合
実装には２種類ある
新規の部分で確認を取らないといけないもの
→この部分が多いと、現実的には見積もれない
が見積もらないといけない場合、えいやで決める
（えいや加減でリスクが決まる）
既存の部分のコピペ、ライブラリ、部品を並べればよい
→画面、帳票、業務ロジックが使う平均部品数X画面、帳票、業務ロジックの数Xキケン率
お金が取れそうかどうかで危険率を決めていく
■設計が一番時間がかかると思われる
設計手順を確認し、不明なところを割り出す
実は、設計に時間がかかっていると思っているときは、
設計に不明なところがある場合が多い。
そうすると、たいてい、打ち合わせでOKがでない（確認会議回数X期間）か
ドキュメント化が大変で、これが不明か
本当は全く何もわかっていないになってくる。
ドキュメントのかかる時間は、ためしに１個作ってみればわかる。
打ち合わせでOKがでず、ちゃぶ台返しになるので、見積もれないというのは、
キケン率をかけて求めるしかない。
本当は何も分かっていない場合は見積もれないので、適当にごまかすか、
真面目に考える（答えになってないけど）。
■日数が出たら全体ステップ数→１日あたりのステップ数
日数が出るレベルなら、画面数、帳票、ロジック数は割り出せているはず。
（類推事例なら、その事例からわかる。FPなどでは、これが分かっているはず。
納期が決まっている場合で、これらの数が分からなかったら、上の章に戻り※のところ参照）
あとは、１つの画面、１つのロジックにかかるステップ数を割り出せば全体ステップ数は出る
（全体画面ステップ数＝画面数X１つの平均画面ステップ数）
１つの平均画面・帳票ステップ数は、自動生成する場合は、生成してみないと、どのくらいになるかわからない。
プログラムする場合は、１項目何ステップになるかX項目数
ロジックなどの場合も同様だけど、ロジックは、DB項目数というよりは、
ざっくりと１ロジックつくるのに、コレくらいとステップをアバウトにみつもってしまうか？
とにかくそんなこんなで、全体ステップ数が出たら、それを上記の日数で割ると、１日あたりのステップ数がでる。
それが、常識的に考えて、外れていれば（１日のコーディング量＞１日でできるタイピング量より大きいなど）
適当に日数をいじって、つじつまを合わせる。
１日がでたら、５倍すると、１週間、２０倍すると、１ヶ月がでる。
なお、ステップ数は、自動生成するところを入れるか入れないか、重要。
入れてしまった場合、そこもテスト項目を作るとなると、テスト項目を作るときに苦労するので注意。
・・・イマドキは、こんなかんじですかね。
１人月あたり、何ステップ？１画面あたり、何人日でできる？の考え方
http://blog.goo.ne.jp/xmldtp/e/513c525aa1b41929a7e8c49f66ba35b8
なんだけど、さすがにエントリが古くなってきたので、
書き直してみる。
■何日で出来る？の変化
昔と違って、何日で出来るというのは、自動生成技術やフレームワークの影響で
変わってきた。昔は、ソースコード量だったが、
・そもそも、ソースコードが自動生成部分を含むのかどうか分からない
・自動生成で全ていけるのかどうか、わからない
・ソースコード以外の要因が増えてきた
ということで、ソースコード量で、実際には決められなくなってきた。
■日数の決め方には、３種類（＋１種類）ある
そこで、開発にかかる日数を先に決めて、ステップ数をつじつま合うようにする
のが、早い道のりになってきた。
日数の決め方には３通りある
（１）類推事例法？っていったかな？
似たような事例をもってきて、その開発日数から割り出す（類推する）
→大手が良く使う方法
（２）特徴量によって
画面数、DBテーブル数などによってきめる。FP(ファンクションポイント）
がこれにあたる。COCOMOなどもこれ
（３）積み上げ法
システムを細かく分解していき、その分解したブロックにかかる時間を
つみあげていって、日数を決める方法。WBSが作成できないとできない。
→中小がよくつかう方法。実際には、これでやると、日数は大きくなり、
この日にちで見積もった分だけは、もらえない。
しかし、実際にはこの方法ではなく
（＋１）納期逆算法
納期が決まっている。ということは、開発日数は、何日で「行わなければならない」
と決まっている。この場合、スコープを変更したり、クオリティをコントロールしたり
する。アジャイル開発などは、この方法になってくる。
がよく使われる。
■MVCの場合の決め方
では、具体的に日数を決める方法について。
開発にかかる日数を出すには、積み上げ法以外では、決まっている。
（→この章をとばし、「日数が出たら全体ステップ数→１日あたりのステップ数」へ）
積み上げ法の場合、作業を全て出すことになる。
ここでは、MVCのような画面系の場合を例に考える。
すると、実装までに以下の作業がある
V：画面・帳票
画面共通部分のレイアウト、作成、確認
必要部品の開発、確認
画面割り
各画面の
項目・イベント動作決定、確認
レイアウト作成・確認
部品配置
エラーチェック（バリデーション）実装
各画面テスト
結合テスト
※画面数は、利用するシナリオを考え、データ入出力場面
を検討すれば、出てくる
M：モデル＝DB部分と業務ロジック
DB部分
全体の設計、確認
各DBの
作成
DBアクセス部分作成
業務ロジック
共通部分の設計、確認、実装
各業務ロジック（イベント数→画面から割り出せる）設計、確認、実装
業務ロジックテスト
結合テスト
データ設計、データ投入
※DBのテーブル数は、画面帳票の項目をどのテーブルに入れるかを考えると出てくる
これを正確に行うには、正規化する
※業務ロジックは、同期型の場合は、画面イベント数となり、具体的には、ボタンを
押したときなどに対応する。非同期の場合は、AJAX呼び出しになるので、この限りではない
が、推測は出来る
C：コントローラー
モデルをつなぐ（自動的に作れてしまうことも多い）
このうち、設計、確認、実装という言葉が何度か出てくるが、
このなかで、なにが、一番時間がかかるかを確定する。
それには、
１つの画面、１つのDB、１つの業務ロジック、１つのコントローラー
ができるまでのストーリー（シナリオ）を考える
そうすると、意外とクリティカルパスになるのは、確認になる。
以下、確認、実装、設計それぞれのクリティカルパスになる場合の
日数の求め方。
■確認が、業務の足を引っ張る場合の日数決定
お客様に確認を取らないと先にいけない場合、
１回のミーティングで何画面検討できるか、
ミーティングがどれくらいの頻度で開けるかを考え、
画面数を決定する
お客様でなく、レビューで時間がとられる場合も同じ。
実装にかかる時間＜会議時間の場合は結構ある
■実装が、一番かかりそうな場合
実装には２種類ある
新規の部分で確認を取らないといけないもの
→この部分が多いと、現実的には見積もれない
が見積もらないといけない場合、えいやで決める
（えいや加減でリスクが決まる）
既存の部分のコピペ、ライブラリ、部品を並べればよい
→画面、帳票、業務ロジックが使う平均部品数X画面、帳票、業務ロジックの数Xキケン率
お金が取れそうかどうかで危険率を決めていく
■設計が一番時間がかかると思われる
設計手順を確認し、不明なところを割り出す
実は、設計に時間がかかっていると思っているときは、
設計に不明なところがある場合が多い。
そうすると、たいてい、打ち合わせでOKがでない（確認会議回数X期間）か
ドキュメント化が大変で、これが不明か
本当は全く何もわかっていないになってくる。
ドキュメントのかかる時間は、ためしに１個作ってみればわかる。
打ち合わせでOKがでず、ちゃぶ台返しになるので、見積もれないというのは、
キケン率をかけて求めるしかない。
本当は何も分かっていない場合は見積もれないので、適当にごまかすか、
真面目に考える（答えになってないけど）。
■日数が出たら全体ステップ数→１日あたりのステップ数
日数が出るレベルなら、画面数、帳票、ロジック数は割り出せているはず。
（類推事例なら、その事例からわかる。FPなどでは、これが分かっているはず。
納期が決まっている場合で、これらの数が分からなかったら、上の章に戻り※のところ参照）
あとは、１つの画面、１つのロジックにかかるステップ数を割り出せば全体ステップ数は出る
（全体画面ステップ数＝画面数X１つの平均画面ステップ数）
１つの平均画面・帳票ステップ数は、自動生成する場合は、生成してみないと、どのくらいになるかわからない。
プログラムする場合は、１項目何ステップになるかX項目数
ロジックなどの場合も同様だけど、ロジックは、DB項目数というよりは、
ざっくりと１ロジックつくるのに、コレくらいとステップをアバウトにみつもってしまうか？
とにかくそんなこんなで、全体ステップ数が出たら、それを上記の日数で割ると、１日あたりのステップ数がでる。
それが、常識的に考えて、外れていれば（１日のコーディング量＞１日でできるタイピング量より大きいなど）
適当に日数をいじって、つじつまを合わせる。
１日がでたら、５倍すると、１週間、２０倍すると、１ヶ月がでる。
なお、ステップ数は、自動生成するところを入れるか入れないか、重要。
入れてしまった場合、そこもテスト項目を作るとなると、テスト項目を作るときに苦労するので注意。
・・・イマドキは、こんなかんじですかね。
アクセス
トータル
ランキング
