2020年1月5日日曜日

システムの費用対効果 〈 工数計算 〉

工数計算、見積を作る側のお話です。実はシステムエンジニアの実力が、数値としてはっきり表れるのが工数計算です。要は難しいということです。


難しさその1 実務経験が必要(設計開発、後工程の経験)
Windowsアプリでも、Webアプリ(フロントエンド)でも、サーバーサイド(データーベース、ビジネスロジック、フレームワーク、基盤構成・・・)でも、実務経験のないことは工数のイメージが湧きません。要素技術偏重の昨今だと全体を見通すことが難しいと思います。

難しさその2 仕様理解が必要(要件定義、前工程の経験)
何行程度なら何時間というものではないんですよね。あくまで業務要件とその実装というイメージで工数建てしていくので仕様理解が必要です。ファンクションポイント、積み上げ法も使いますが、細かく機能分解しても見積精度は上がりません。経験ベースで業務要件から工数建てしていく方が的確に出ることが多いです。なので積み上げ法の場合、過去事例、類似事例との比較で妥当性チェックもします。

特に重要なのは特殊性、例外要件の理解
時々あるのですが、要件定義と設計開発が別のチームリーダーの場合。うまくいかないですね。ひどいのになると、前工程と後工程が別の会社という場合があって、前後でお互いの責任はありませんから、損をするのはお客さんです。
要件定義と設計開発を同じ会社にやってもらうのが一番です。時間単価が高くなるかもしれませんがトータルで納期、金額とも少なく済みます。それができない場合はお客さん側でしっかり仕様把握、設計レビュー、工数管理をすることになります。

昔はみんなこれでやっていたのですが要素技術の広がりとともにベンダー任せになってしまいました。要素技術を絞るのはシステムの費用対効果を上げる近道です。クラウド&ウェッブサービスの組み合わせもいいのですが、費用対効果は発注者自身が見極めないといけません。悪気はないのですが、ベンダーは自分の得意なことは言っても、不得意なことは言いません(不得意なことの方が圧倒的に多い)

システムの費用対効果、一度見直してみませんか?
永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します