カテゴリ： 仕事

見積もりをする上での大原則があります。それは、 どんな方法を使っても完璧な見積もりは作ることは出来ない。 と言う事。 とはいえ、勘に頼って見積もりをするのは危険すぎます。 少しでも見積もりのブレをなくすためにも、見積もりの方法論を学ぼうと思い、整理してみました。

見積もりの流れ

見積もりは３つの段階があります。
  1. 規模の見積もり
  2. 工数の見積もり
  3. コストの見積もり
中でも特に難しいのは、規模の見積もりと、工数の見積もりです。 単純に作業量だけでなく、リスクや体制によるズレも考慮しなければなりません。 見積もり手法の中にはそういった、リスクや体制も考慮に入れた手法も存在します。 手法は数多くあるのですが、代表的な手法を幾つかピックアップして、特徴とメリット、デメリットを纏めてみます。

類推法

経験値による見積もりであり、過去の類似の開発事例から開発規模を類推する手法です。 主に規模の見積もりをする際に有効です。
  • メリット
    • 過去に同様のプロジェクトが有れば精度はそこそこ
    • 精密な資料が無くても見積もり出来る
    • 過去の経験からリスクを想定し易い
    デメリット
    • 過去の案件の精緻な情報が必要（大企業向け）
    • 見積もり担当者によりブレが生じる
    • 新規の案件には対応出来ない

プログラムステップ法、LOC法

プログラムステップ数(LOC:Lines Of Code)に生産性を掛け合わせておこなう見積もり。要求仕様から開発するプログラムのコード数を推定し、そのコード数と１コード当りの生産性から全体の工数を見積る。工数見積もりに向く。
  • メリット
    • 既存コードの改修の場合は精度が高い
    • コードが有れば見積もり出来る
    デメリット
    • 要求仕様からプログラムステップ数を推定する確実な方法は存在しない
    • 新規開発に使用することはあまりない
    • 類推法に頼る部分も出てくる

積算法、WBS法

WBS(Work Breakdown Structure)等によって 細分化されたタスク毎に工数(作業時間)を求めて、それらの推定した工数を積上げることにより 見積もりを行う手法。工数見積もり向け。
  • メリット
    • タスク自体の見積もり精度が高い
    • １つ１つの見積もり範囲細かいので見積もりやすい
    • スケジュール感が掴みやすい
    デメリット
    • 見積もりのベースになる資料自体に手間がかかる
    • 資料が大量に必要
    • 概算見積もりに使うのは現実的に無理
    • 意外と過小見積もりになりがち

FP法(Function Point）,標準値法

FPという共通の指標で開発規模を表す。入出力ファイルの数、画面や帳票、バッチなどの処理プロセスなどの機能面から工数を算出する。工数見積もり向け。
機能数　×　重み付け係数 = FP
　FP　÷　生産性基準(FP/人月) = 工数（人月）
  • メリット
    • 精度が高い
    • 組織も算出項目に入るので工数が出しやすい
    • 利用者の視点から見積もりできる
    デメリット
    • 要求仕様書が無いと使えない手法
    • 組み込み系の見積もりには合わない
    • 技術的な物を視野に入れられない

COCOMO /COCOMO ２

Constractive Cost Modelの略。開発するソフトウェアの行数を把握し、その行数に補正係数を掛け合わせて開発工数に換算する手法。 FP法の手法を入れるとCOCOMO IIになる。工数見積もり向け。最大の特徴は、スケール変動要因や、リスク項目が定義されていること。
  • メリット
    • 精度が非常に高い
    • 組織も算出項目に入る
    • リスクを想定しやすい
    デメリット
    • 係数の算定が難しい
    • 計算方法が煩雑

KKD法

じつは手法でもなんでもない。エンジニアの経験と間に頼った見積もりのこと。 K（勘）、K（経験）、D（度胸）の略。規模見積もり向けではあるが、単体で用いるのは危険。
  • メリット
    • 熟練した人であれば精度は高い・・かも？
    • 他の技法でカバーできないものはコレで見積もる
    • まったく根拠が無い場合はこれしかない
    デメリット
    • 算出根拠が薄弱
    • 勘が外れると氏ねる
    • 見積もる人によって見積もりが大きく変わる

精度を上げるために

どの技法も一長一短有りですが、あくまで一視点でしかない事に注意。 複数の手法を組み合わせて使ったり、複数手法で見積もりを出して検討するとより良いでしょう。 可能であれば、複数の人で見積もりを出して議論する方が誤りは少なくなります。 ユーザーの為にも、プロジェクトメンバーの為にも、そして何より自分の為に、皆様よいお見積もりを。 最後に、見積もりの参考になる本で、良く聞くのが此方。参考までに。
ソフトウェア見積り
タグ ：
Work
このエントリーをはてなブックマークに追加

　今日は自社で「見積もり手法勉強会」を行いました。 そもそもこの勉強会を企画した理由は、後輩が見積もりで失敗して苦労していたのがきっかけでした。

　見積もりって言うと、流石に誰でも興味を持つところでは無いので、実際に見積もりで苦労した人、かつ、平日の勉強会なので、時間的になかなか厳しいのもあり、参加者は多くて５人程度だろうと想定していました。が、今朝の時点で参加希望者を調べてみると、21人！？ これは想定外。
　参加者の幅も、見積もり未経験者から、そろそろ見積もりを任されても良いだろうと思う人、かなり見積もりをこなした強者まで、相当広かったです。意外とみんな見積もりに興味あるのですね・・・意外。

　見積もりを経験した事の無い人にとっても、自分自身の作業の見積もりは出さなきゃいけない事は多々あるので、それはそれで、良いこと。とはいえ、流石に５人の想定で考えたメニューでは予定の２時間では足りないので、急遽方針を変更することに。嬉しい悲鳴。

　本来は、見積もり手法について、簡単に概要を説明して、 「フリーディスカッション形式で、実際にその場で色々な手法を使って見積もりを出してみる」というメニューにしていたのですが、20人のフリーディスカッションでは纏まらないだろうと考え、 「一人一人、見積もりを出して貰い、選択した手法と着眼点、工数を比較してみる」 というメニューに変更しました。
　実はコレには一つ狙いがあって、「経験年数がランダムなメンバーで出した見積もりの平均値は意外と良いくんじゃないか？」って疑問の検証がしてみたかったのです。

　お題に使った案件の実際の工数は5．7人月。 既存のパッケージソフトのカスタマイズで、ＧＵＩが16画面新規追加、入力ファイル21、出力ファイル7画面。
　見積もり範囲は開発から、ＵＴまで。設計書の質は３段階のウチ最低品質。とても見直しなしには作成出来ないレベルです。（もっと細かい情報がありますが、過去にあった実際のプロジェクトなので、割愛） 各メンバーにだして貰った工数は、最小が1．5人月（！）、最大は15人月（！）でした。10倍の差が出ています。
　それにしても凄い。 私自身は、普段は画面ベースか、機能ベースで見積もりをだしているのですが、折角の機会なので、今まで「これはいけるんじゃないか？」という技法を採用して見積もってみました。 結局アプリケーションの本質は、入力されたデータを何か処理して、画面なり、ＤＢなり、ファイルなり、帳票なりに出力するのがメインな訳なので、入力ファイルと出力ファイルの数と項目数から、かなり精度の高い見積もりが出せるのでは無いか？と想定したのです。ＦＰ法のファイル特化バージョンです。 設計書の品質が低いので、1．5ポイント程度のウェイトを置いて算出。既存アプリ理解や環境設定のリードタイムを入れて、算出した工数が、5．75人月。 おおお！！なかなか行けるモノだ。
　現実に見積もり出すとすれば、６人月辺りで出すかな？って所です。 そして本題。 ばらつきがあった全員のサマリーを取ってみると、7．85人月程度。 ん・・・まぁまぁかなと思っていたら、参加していた部長から一声。 最大値と最小値を除いた見積もりの平均値を取ってみればどうか？と。標準偏差って奴でしたっけ？ 今度は、6．１人月。おおおおおおおお！！ これぐらいの誤差なら全然ＯＫなんのでは。

　結局、色々技法を凝らして考えても、ランダムに出した数値の平均もそれほどブレが無いような感じです。 これって、Wisdom Of Crowdsって言って良いのかな？ ・・・いやどちらかと言うと、株式相場におけるランダムウォーク理論の法が近い気がする。カオス理論とも思えるけど、実際に精密な計算して見積もり出すと、それなりの数値がでてくるので、カオスと言ってしまうと、少しズレがあるかもしれない。 今日の資料かまとめは、一部編集して近々あげる予定です。

↓元ネタ
「みんなの意見」は案外正しい
タグ ：
Work
このエントリーをはてなブックマークに追加

もともとはソフトウェア開発が本業なんですが、会社のサーバー管理していたり、趣味でLinux触っている関係で、インフラ構築案件に携わることになりました。 本業とはちょっと違うのですが、たまたま似たような作業、OpenPNEとか、Apacheとか、MySQLとかネットワーク構成とかやったことあったので、そこそこお役に立てているいるようです。 一つ前の案件でも、軽くインフラ周りを見ていたのですが、 最近の案件では、ネットワーク冗長化　＋　HA構成　＋　外部ストレージディスクがトレンドですね。 ちょうどついこの間まで、AIXの冗長構成を見ていたので、割とすんなり理解できました。 今回はLinux×６台で、Webサーバ、DBサーバ、ストリーミングサーバ、CMSなどなかなか面白い案件です。 ネットワークはfirewall、ロードバランサ、VPNなど一般的なライナップですが、なかなか興味深いです。 おかげでデータセンターに２日間ほど入り浸る事ができました。ん〜〜良い経験。 あと数回はデータセンターに行く予感がしています。 個人的にはデータセンターの近くにキルフェボンがあるのが○。 個人的にはMPP環境の構築をやってみたいんですけどね。 会社であいているThinkPadでThinkPadクラスタ組んでみようかなぁ。なんて企む毎日です。
タグ ：
Work
このエントリーをはてなブックマークに追加

最近仕事でAIXのパフォーマンス計測をしていました。 今まで"vmstat 2 100"とかやっていたのですが、 最近"topas"コマンドの存在を知りました。 コレがすっごく便利。そして非常に見やすい。 
    Topas Monitor for host:    niller               EVENTS/QUEUES    FILE/TTY
    Mon Mar  1 07:00:27 1999   Interval:  2         Cswitch     383  Readch   504233
                                                    Syscall    2421  Writech   86445
    Kernel   35.0   |##########                  |  Reads       254  Rawin         0
    User     39.5   |###########                 |  Writes       44  Ttyout      354
    Wait     22.5   |######                      |  Forks         7  Igets         8
    Idle      3.0   |#                           |  Execs         7  Namei       281
                                                    Runqueue    2.0  Dirblk       72
    Interf   KBPS   I-Pack  O-Pack   KB-In  KB-Out  Waitqueue   1.0
    tr0        0.0     0.5     0.5     0.0     0.0
    lo0        0.0     0.0     0.0     0.0     0.0  PAGING           MEMORY
                                                    Faults     1901  Real,MB     384 
    Disk    Busy%     KBPS     TPS KB-Read KB-Writ  Steals        0  % Comp     15.0
    hdisk0   27.5    110.0    25.5     0.0   110.0  PgspIn        0  % Noncomp  42.3
    hdisk1    0.0      0.0     0.0     0.0     0.0  PgspOut       0  % Client    0.0
    hdisk2    0.0      0.0     0.0     0.0     0.0  PageIn        0
                                                    PageOut      27  PAGING SPACE
    xlcentry (56328)  5.0% PgSp: 0.5mb nchris       Sios         25  Size,MB     512
    X        (2692)   4.0% PgSp:30.8mb root                          % Used     25.5
    cc       (56794)  2.0% PgSp: 0.1mb nchris                        % Free     74.5
    i4lmd    (21418)  1.5% PgSp: 0.5mb root  
    java     (31246)  1.5% PgSp: 5.4mb nchris
    topas    (50452)  1.5% PgSp: 0.5mb nchris          Press "h" for help screen.
    make     (53914)  1.0% PgSp: 0.2mb nchris          Press "q" to quit program.
    syncd    (4662)
CPU使用率、 I/O、 ネットワークポート毎の統計、　プロセス統計、カーネル統計、メモリ あらゆる項目が一画面に出てくれます。”P”を押すとvmstatライクな表示にもなったりする。すごッ！ ちなみに書く表示項目の意味はこちらのページに書いてあります。
タグ ：
Work
このエントリーをはてなブックマークに追加

といっても、「きゃんち萌え」ってこ事が書きたい訳ではないです。 Tech総研の”テックハニー“きゃんち”の突撃☆会社訪問”ってコーナーがおもしろ過ぎるのです。 このコーナー、メイドコスプレのテックハニーこと”きゃんち”が今をトキメク魅力的な会社へ突撃リポートを行うという企画なのです。個人的に興味を持っている会社も入っていて、なかなか面白いです。 職場もお仕事も社員もやっぱり、はてな？ 勿論これは”株式会社はてな”への突撃リポート。 自社開発ブログ「Vox」が生み出す仲良しな職場 これも見ればすぐわかる。"シックス・アパート株式会社"への突撃リポート。 個人的に面白い職場だなぁと思ったのは”株式会社ループス・コミュニケーションズ” 楽しい！ボードに書き込んで、即効仲良くできちゃう!! この会社面白いのは、ビルの一室を借りるのではなく、一軒家丸々会社なんですね。 当然和室もあれば庭もある。おまけにバスルームもある。面白いなぁ。 何かを自社内で作っている会社は何処でも、それなりにインスピレーションを刺激する職場づくりというか、能率を上げるために、色々な事を考えているんですねぇ。ベンチャーになればなるほどそうで、それが会社の魅力そのものになっているんですね。 IT系で大企業でありながら、ベンチャーレベルに創意工夫とスピリットを感じるられる会社もありますけどね。 今頭の中に２社ほど思い当たるトコロが有ります。 １社はApple。 もう１社は・・・言うまでもないね。
タグ ：
Work
このエントリーをはてなブックマークに追加

↑このページのトップヘ