ゆとりがひとりで企業内スタートアップ。

ゆとりがひとりで企業内スタートアップ。

20歳の頃から「とりあえず3年」といって働き始め、早6年。新人や若手リーダーへ向けたライフハック、働き方(心の持ち方)、を簡単にまとめたいなと思います。

要件定義の妥当な工数っていくらなんだ、積み上げで考えてみた

follow us in feedly

スポンサードリンク

お疲れ様です。しどまです。

 

前回、チーム内で作業割り振りしてたら揉めたっていう記事を書きました。(僕のチームはシステム化要件定義が仕事。)

 

shidoma.hateblo.jp

 

 

で、要件定義って後続の設計とか、プログラミングとか、テストとかの工程に比べると工数の妥当性がわかりづらいな、って話になったわけです。

 

f:id:shidoma:20160511002714j:plain

あらゆる書籍をみてみると開発工数の割合8%~15%くらいが妥当なんじゃないか、ということでしたがやっぱ一定の割合じゃ全然妥当な気がしない。

 

ということで、積み上げ式でやってみる

僕のところの要件定義の作業はざっくり言うと、こんな感じです。カッコ内の数字は、要件定義の中での工数比率です。体感ですけど。

 

1.ユーザーが業務要件出してくる(5%)

2.ダメだしする(25%)

3.直った業務要件出してくる(5%)

4.実装案を考える(20%)

5.社内の稟議を通す(25%)

6.ベンダに渡す(5%)

7.ダメだしされる(10%)

8.直ったシステム化要件出す(5%)

 

2番、5番がなかなか進みません。

で、工数に跳ねそうなパラメータは以下の通り。

 

<担当者/ユーザの要素>

・担当者の知識量

・作業スピード/コミュニケーション力

・上司が頑固かどうか

・他の案件との輻輳があるか

 

<要件による要素>

・機能数(開発規模)

 →画面数、イベント数、帳票数、IF数、・・・等々

・関連する周辺システムの数

・既存機能の保守性・可視性(ドキュメントの有無)

・エンドユーザへの影響度

・定例か、非定例か

 

・・・ただブレストで書き出しているので全く体系的ではありませんが、もうあきらめたくなるほど要素はたくさんあります。だから、みんなカンと経験でやってるんでしょうけど。

 

想像で1件やってみます

ユーザからの要件が、

20歳以下で年収1000万以上の会員を日次の夜間バッチで抽出して、周辺システムへ送ってくれ。だとする。担当者/ユーザはベテランで要件書のやり取りは1発で終わる。とする。

 

日次の夜間バッチで会員DBのアンロード、

新規COBOL PGM 1本(コンバート)で、

新規IF 1本で、既存処理への影響はなし、

エンドユーザへの影響はなし。

 

ん~、開発1人月かな。要件定義は半日!手続き入れて、2日!

(あ、開発規模の10%になってる・・・。)

 

 

・・・結局、カンと経験になるのでしょうか。。。要素の書き出しは時間をかければ出来そうです。基本モデルを作って、プロジェクト毎に書き換えて流用できるか、全く流用できないのかは悩みどころですが。

 

あとはパラメータの重み付け、これが各プロジェクトの実績から持ってくるしかないのでしょうね。しかし、実績といってもあてになるデータなんてみつからないでしょうから、やっぱり経験次第。

 

ぬがぁぁぁー!!

 

 

結論:要素の書き出しは出来るので、ある程度は基準化出来るが、重み付けはあなた次第。あと、リーダーが端から見て、パラメータをそんなに察知出来るかは、疑問。

ばっちり可視化できる方法があれば教えて頂きたいです。

 

 

以上!

広告を非表示にする

スポンサードリンク