タグ:Work

10月1日から新らしい職場に来ています。
今までやって来た事とはちょっと違うので、結構戸惑う事も多いです。

でも、ありがたい事に、「全然知らない!」って事はあまり無く、
「知っているケド、あんまり本格的に使った事ないなぁ・・」って所がほとんどです。

初めは研修課題を実装していたのですが、この会社は基本的に放置の文化らしく、勝手に作業しています。
ずっとやりたいなぁ・・と思っていた事、ツールなどが自由に使えるので、楽しくて仕方ありません。

今までは、「あれもやらなきゃ、これもやらなきゃ!」って感じだったのが、
「アレもやりたい!コレもやりたい!!」に変わりました。
もうすぐ研修課題が終わりそうなので、漸く業務に入れそうです。やった!!

そんななか、同期の仲間に聞いた話によると、もうすぐ社内コンペがあるそうです。
新アプリケーションの案をプレゼンして、勝ち残ると、実際のプロジェクトになるかも・・って奴です。

・・・

なにぃ!!

それはエントリするしかないでしょ!!
プランは沢山あるけど、とても全部は出せないし、自社のサービスを考えると、コレはちょっとなぁ・・ってのもあります。う〜〜ん、悩ましい。

一応今のところ、一つ思いついた奴を資料化してプレゼンに備えようかと思います。
イメージを付けたいけど、そんなスキルないしなぁ・・どうしよう。

このエントリーをはてなブックマークに追加

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

見積もりの流れ

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

類推法

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

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

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

積算法、WBS法

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

FP法(Function Point),標準値法

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

COCOMO /COCOMO 2

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

KKD法

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

精度を上げるために

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

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

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

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

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

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

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

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

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

最近仕事で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ライクな表示にもなったりする。すごッ! ちなみに書く表示項目の意味はこちらのページに書いてあります。
このエントリーをはてなブックマークに追加

↑このページのトップヘ