Skip to content

DNET_ServiceEstimation

Jump to bottom
nishi_74322014 edited this page Aug 3, 2026 · 1 revision

見積

概要

見積とは...

  • 金額・量・期間・行動を前もって概算すること

    • 見積もること
    • あらましの計算をすること
    • また、その計算

  • エンタープライズの立上プロセスで重要になる

    • 工数 →（時間・原価）などを見積もる作業
    • SIerの事業では特に重要とされている

詳細

見積の分類

以下のような分類がある。

類推見積（トップダウン見積）

過去の類似プロジェクトの実績データを基に、規模や特性を考慮して見積もる手法。

パラメトリック見積

統計的な関係性やパラメータを用いて、数学的モデルで見積もる手法。

三点見積

楽観値、悲観値、最頻値の3つの値から見積もる手法。不確実性を考慮できる。

ボトムアップ見積

最下位レベルの作業を詳細に見積もり、それらを積み上げて全体を算出する手法。

ソフトウェア開発見積

基本的に、パラメトリック見積で行う。

FP法（ファンクションポイント法）

  • パラメトリック見積の一手法

  • ソフトウェアがもつ機能数を

    • 点数付け、
    • 複雑さによって重み付け、

    し、そのソフトウェアにおける合計点数（FP）から開発工数を見積もる

  • トレード・オフ

    • プログラミング言語の種類や書き方、機能の実装方法などに依存しない
    • 機能の複雑度の判定は主観が入り込みやすく、過去事例の無い場合の評価が難しい

オレオレ法

これも立派なパラメトリック見積（FP法と同じ）。

  • 「１画面、１K step、１人月」など
  • 上記はステップ規模を算出しているから、≒ステップ規模見積

ステップ規模見積

  • パラメトリック見積だが、企業 / 組織 / 個人の程度の差はあるもののオレオレ法ではある

  • 以下の事例情報が、企業 / 組織 / 個人に、多数、溜まっていることで見積もりが実現可能

    • 案件特徴
    • 工数 / 原価
    • ステップ規模
ステップ規模

  • ステップ・カウント・ツールなどを用いて算出する

  • 開発言語 / フレームワーク / ツールによって影響を受ける

    • ステップ規模が大きくなる

      • Webアプリケーション
      • 低水準言語
      • フレームワークの未活用
      • 自動生成の使用

    • ステップ規模が小さくなる

      • C/Sアプリケーション
      • 高水準言語
      • フレームワークの活用
      • EUCツールの使用
      • 自動生成の不使用
ローカル・ルール

ステップ規模の測定には、ローカル・ルールが多いが、事例内のルールが統一されていないとデータの利用が難しくなる。

  • SQL (DDL / DML)は測定しない
  • 画面定義、帳票定義は測定しない
  • （DHTML時代の...死語）JavaScriptは測定しない
新規開発規模以外のステップ規模算出式
  • 流用、改造等などを考慮する
  • ステップ・カウント・ツールに機能が組み込まれていることも

案件特徴

生産性変動要因

企業で分析されている≒リスクである。

生産性変動要因の例

  • 開発技術

    • 初めて使う開発技術
    • 生産性が 高い / 低い 開発技術

  • 顧客マター（上流）

    • 要件が固まらない（要件未確定）
    • 仕様が出てこない（仕様未確定）
    • 仕様膨張
      生産性ではなく規模の話のように聞こえるが、下流工程でも膨張を続けるようだと≒仕様未確定で生産性も低下する

  • 顧客マター（下流）

    • ユーザが「コレジャナイ。」と言う
    • オーナーが「こんなはずじゃなかった。」と言う

  • プロジェクト・マネジメント上の悪循環（負のスパイラル）

最近は単純な案件が減り、変動要因が重要になってきている。

再構築（現新一致）の見積もり

スクラッチ開発の見積もりと似ているが、以下の点が異なる。

  • 現行システムと仕様書の乖離が見積もりのポイントになる
  • 乖離が大きい場合、リエンジ後に見積もらないと危ない

パッケージ・カスタマイズの見積もり

スクラッチ開発の見積もりとは、大きく異る。

特徴
  • 要件 / 仕様が不明確なら段階的になるが、パッケージでは一括の慣例
  • 一括になると、業務に詳しくないとカスタマイズの見積が不可能
  • 結果、フィット＆ギャップが十分でない状態で契約してしまうケースが多い
ポイント
  • 一般的に、カスタマイズ規模が3割を超えると、≒新規開発と言われる
  • （参考資料参照）

移行・マイグレーションの見積もり

  • スクラッチ開発の見積もりとは、大きく異る
  • 例外的に、ボトムアップ見積的に行う

トピック

SE作業見積

ソフトウェア開発見積と異なり、ボトムアップ見積的に行う。

KKD（勘と経験と度胸）でエイヤの裏側

  • これは、「１画面、１K step、１人月」と言う感じの概算の見積もり方法
  • こう書くと、伝統的＆属人的な、陳腐な方法に見えるが、以下に該当と言われるとマトモな方法にも見えてくる不思議
    • データ分析の逆問題
    • PMBOKで
      • 専門家の判断
      • 類推見積（トップダウン見積）
概算可能な例
  • 金融 / 公共系：１画面、２K step、２人月
  • 産業系：１画面、２K step、１人月
これが成立してしまう理由

  • 「下限での見積」がSI事業の商習慣として慣例化しているため

  • また、発生したバッファ工数が「パーキンソンの法則」で消費されるため

  • 業種によって（、例えば以下のように）、WBSが異なり、形骸化など生産性が下がる事もある

  • コレが、ナカナカ是正されないは以下による

    • 「パーキンソンの法則」的、サプライ・サイドにメリットが無い
    • サプライ・サイドに無理をさせると品質に影響が出る
参考
  • WBSとパーキンソンの法則
  • その判断、単なる「エイヤ！」で決めていいんですか？ | ハフポスト記事

参考

Wikipedia

パッケージ・カスタマイズ

その他

  • DNET_ProductivityDataCollection.md（生産性事例収集項目例）
  • DNET_SIBusinessAndEstimation.md（SI事業と見積の関連）

Tags: 移行, 見積, プロジェクト管理, ソフトウェア工学

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally