┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.74 2004/12/15
■ I N D E X
┃
┣【Topics】オブジェクト倶楽部クリスマスイベント」開催！
┣【新発想】オブジェクト指向の再定義[6] - ソフトウェアのプル生産
┣【見積もり手法】実践！ソフトウェアの見積もり手法［6］
┗【アンケート】気になるシステム業界 ホントのところ
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 オブジェクト倶楽部クリスマスイベント」開催！
〇 〇━━━━━━━━━━━━━ ━━・
9日(木)、国立オリンピック記念青少年総合センターにて、オブジェクト倶楽部
クリスマスイベント「オブジェクト指向実践者の集い(第3弾)」を大盛況のうち
に終了しました。快くご協力くださった講演者の皆さん、ライトニングトークス
トーカーの皆さん、お忙しいところをご参加くださった皆さん、電車事故の中お
越しいただいて、本当にありがとうございました。主催側としても嬉しい限りで
す。講演資料等は順次公開中です。
http://www.objectclub.jp/event/2004christmas/#lecture
なお、参加レポートを随時受付中です！！！！
レポートを書かれた方は、event-staff@ObjectClub.jp に送って頂ければ、オ
ブジェクト倶楽部ページへの掲載を検討します。すでにblog等で公開されてい
る方は、URLをぜひ教えてください。オブジェクト倶楽部ページからリンクを張
らせて頂きます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【新発想】オブジェクト指向の再定義[6] - ソフトウェアのプル生産
今回は、トヨタ生産方式とアジャイル開発の共通点である、「プル生産」につ
いて書いてみたい。前回から継続している「テスト」の話に関連している。前
回は、上流から下流へ向かって１個ずつ要求を流す、という話をしたが、今回
は、生産指示（いつどれだけ作って後工程に流すか）について。
トヨタ生産方式では、工程間に溜まった仕掛を在庫（＝ムダ）と捕らえている。
この在庫を「かんばん」で管理し、前工程への生産指示を出す。後工程が必要
になって初めて、前工程が作る。前工程は、生産指示がない限り作らない。生
産物は必要な分だけ前工程から後工程へと流れ、生産指示は逆に後工程から前
工程へと流れるのだ（後工程引取り）。
たくさん作ることは良いことだという開発側の論理で生産を続けると、前工程
から後工程へと生産物がプッシュされることになる。後工程で必要とする以上
の生産物は、ムダとなり工程間に在庫として貯まる。これが、在庫のムダだ。
かんばんを使った後工程引き取りは、顧客要求が生産を「プル」することに対
応する。
ソフトウェアでは、読まれない仕様書、テストされていないソースコードなど
の中間生産物が、この「在庫のムダ」に相当する。アジャイル開発では、顧客
が書くストーリーカードと受け入れテストが、要求を定義する。一度にたくさ
んの要求を分析・設計するのでなく、１つ１つの要求をテスト駆動で進める。
後から来るであろう要求を予測した、大きな設計などはしない。要求されてい
るものだけを、シンプルに作る。これによって中間生産物を避けたプル生産が
可能になる。
トヨタ生産方式では、自分の工程を基準にして後工程を「お客様」、前工程を
「神様」(*1)、と呼ぶ。お客様が必要としているものを必要としているタイミ
ングで提供することがジャストインタイム生産の鍵となる。お客様が必要とし
ないものは作らない。現実に、ラインでは後工程からのカンバンがなければ、
掃除をしたり、後工程への応援(*2)に出向いたりする。そこまでして、在庫の
ムダを嫌うのだ。（平鍋）
(*1): 自分ができない領域、という意味で尊重する。
(*2): 応援すること、応援を受け入れることを、「応受援」とよぶ。
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/cgi-bin/question.cgi?K001+5+0
普通：
http://www.ObjectClub.jp/cgi-bin/question.cgi?K001+5+1
イマイチ：
http://www.ObjectClub.jp/cgi-bin/question.cgi?K001+5+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【見積もり手法】実践！ソフトウェアの見積もり手法［6］
みなさんは、どんな見積もり手法使っていますか。
□ おさらい
これまで、プロジェクト計画・運用における見積もりの必要性や、デルファイ
法、ファンクションポイント法(FP法)、ユースケースポイント法(UCP法)の見積
もり手法のご紹介をしてきました。今後も、COCOMO法などの見積もり手法のご
紹介や、見積もりをするにあたって直面する問題や、考慮すべきポイントなど
の情報についてお伝えできたらと思っています。
□ 今回のテーマ
みなさんは、何かしらの見積もり手法を実際の業務で使っていますか？または、
みなさんが所属する部門や会社で決められた見積もり手法があり、それを使っ
ていますか？FP法などの見積もり手法を、全社的に積極的に取り入れている企
業のお話を、筆者は耳にしたりします。だた、大部分の方々、特にソフトウェ
アハウスに所属の方々は、これと決めた見積もり手法を持ってないのではない
でしょうか。もしかしたら、いまだに経験・度胸・勘で見積もりを実践してい
たりしませんか。今回は、筆者が実際に行っている見積もり手法をご紹介しよ
うと思います。
□ WBS法＋UCP法
筆者がいままで所属していたところでは、部門や会社で決められた見積もり手
法を持っている環境に遭遇したことがありませんでした。いつも感じていたこ
とは、「なぜ会社としての見積もり手法を持っていないのだろう？」「これで
はアプリケーション、技術などの違いなどによって、見積もりをするための経
験がまったく蓄積されないじゃないか」などと思っていました。また、毎回案
件の見積もりをするたびに、今回の見積もりのポイントやリスクはどこにある
のかと、悩まされていました。
筆者は、WBS法[*1]をベースに見積もりをしています。ただ、これまでの経験か
らWBS法の単独の利用では、予算内におさまるような十分な見積もり結果は得ら
れないと感じています。以前はWBS法のみで見積もりをしていましたが、結果と
して過少見積もりのケースが多々ありました。現在では、より見積もりの妥当
性を高めるために、WBS法での見積もり結果の検証を目的に、UCP法[*2]を併用
するようにしています。UCP法は、ユースケースをベースにしているため、顧客
要求の洗い出しを行っている段階に適用することが可能であり、初期の概算見
積もりを出すときにも有用です。ユースケースさえ抽出できていれば、30分も
あれば算出できるため、便利です。
WBS法では、とくに以下のことに気をつけています。
(1)できる限りタスクを細分化する。目安は、1人日単位で見積もり可能なタス
クまで細分化することです。1タスク当たり5人日以内のレベルになるくらい
まで細分化すると良いと思います。
(2)細分化されたタスクにシステム(アプリケーション)やプロジェクトの特徴を
工数として反映する。
(3)過去のプロジェクトの見積もり事例などから抜け落ちているタスクを発見し
反映する。
細分化することには、大きなメリットがあります。まずは、新しいと思えるタ
スクでも、実は過去に経験したことのあるタスクが一部あったりすることがあ
るので、過去の経験を参照することが可能になり、より工数推定の精度が高ま
ります。また、作業の類型がしやすくなり経験が蓄積しやすくなります。さら
に、成果物を作るための必要な作業を洗い出しているため、顧客にも分かりや
すく説明ができ、合意が得やすくなります。WBSを作成することで、工数の見積
もりだけでなく、工程や要員の計画にそのまま直結するので、初期の計画作成
と並行して見積もりが行えるというメリットもあります。
それでも、WBS法には問題点があります。WBS法は、積上げによる見積もりであ
るため、結果的に現実離れした見積もり結果になるという可能性があるという
ことです。しかも、筆者の過去の経験では、多くの場合過少見積もりとして、
その結果に現れます。
そこで筆者は、より見積もりの妥当性を高めるために、WBS法での見積もり結果
の検証を目的として、UCP法を併用して見積もり実施しています。具体的には、
WBS法とUCP法のそれぞれで見積もりを出して、両者の見積もり結果がほぼ似通っ
た値になるまで見直しを繰り返します。それぞれの結果が大きく違っている場
合、WBS法の場合だと、細分化が不十分でないか、必要なタスクが抽出できてな
いか、必要以上にリスクを乗せていないか、あるいはリスクを見込めてないか
などの点について再度見直しをします。UCP法の場合だと、ユースケースやアク
ターを漏れなく抽出できているか、ユースケースの重み付けは正しいかなどの
点について再度見直しをします。両者の見積もり結果がほぼ似通った値になっ
たら、WBS法の結果を見積もり値を正式な見積もり値として採用します。これは、
UCP法はあくまでもWBS法の見積もり結果の検証を目的としているためです。UCP
法で気をつけなければいけないのは、ユースケースの大きさ(ユースケース当た
りの作業時間)です。事例毎に異なったユースケースが抽出されることがあり、
ユースケースの大きさを均一化するには、ユースケースのとらえ方や、大きさ
をなるべく均一にする工夫が必要だと感じています。
さらに筆者が現在所属している会社では、PMO(プロジェクト・マネジメント・
オフィス)[*3]があり、PMOでレビューを行い、そこで承認を得られたものが最
終的な見積もり結果となるようにしています。
□ まとめ
今回は、筆者が実際に行っている見積もり手法を簡単にご紹介しました。みな
さんは、どんな見積もり手法を使っていますか。非常に興味深いので、一度ア
ンケートしてみたいところです。
FP法、UCP法、WBS法など、それぞれの見積もり手法を学ぶことの意義は大きい
と感じています。これらの見積もり手法は、見積もりの考え方だけでなく、経
験の蓄積ができ、技術面やプロジェクト管理面など、見積もりをする上での考
慮のポイントなどを気づかせてくれる良いお手本にもなります。（中村）
[*1]WBS(Work Breakdown Structure)法
プロジェクトが生み出す成果物を中心として、その成果物を作るために必要な
作業をブレークダウン（分解）し、階層的に業務内容（通常タスクと呼ばれる）
を明確化したものをいいます。スケジュール作成、要員計画、工数見積もりな
ど、プロジェクトマネジメントで計画を立てる際に用いる手法の一つです。WBS
法とは、そのWBSによって細分化されたタスク毎に工数(作業時間)を求めて、そ
れらの推定した工数を積上げることにより、見積もりを行う手法です。
[*2] UCP(Use Case Point)法
メルマガ2004/10/27号参照。http://www.objectclub.jp/ml-arch/magazine/72.html
[*3] PMO(Project Management Office)
プロジェクトで必要なマネジメント作業や、プロジェクト業務の品質向上に寄
与する組織を指します。 PMOには主に以下のミッションがあります。
(1)実施プロジェクトの最適な選別
(2)プロジェクトへのリソースの配分と調整
(3)プロジェクトマネジメント手法の標準化と普及
(4)プロジェクトマネージャの派遣
(5)プロジェクト遂行の最適化
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/cgi-bin/question.cgi?J001+5+0
普通：
http://www.ObjectClub.jp/cgi-bin/question.cgi?J001+5+1
イマイチ：
http://www.ObjectClub.jp/cgi-bin/question.cgi?J001+5+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【アンケート】気になるシステム業界 ホントのところ
今週は「どんなソフトウェアの見積もり手法を使っていますか？」のホントの
ところ。上記記事【見積もり手法】実践！ソフトウェアの見積もり手法[6]に合
わせての質問です。さてみなさん、どの手法をお使いですか？
デルファイ法を使っています。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+38+0
ファンクション・ポイント法を使っています。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+38+1
ユースケース・ポイント法を使っています。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+38+2
COCOMO法を使っています。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+38+3
WBS法を使っています。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+38+4
独自の手法を使っています。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+38+5
勘、経験、度胸（Ｋ・Ｋ・Ｄ）でエイヤー！
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+38+6
それは秘密です。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+38+7
ちょっと語らせて！
editors@ObjectClub.jp まで詳細を！！
アンケート結果はオブジェクト倶楽部サイト上にて公開します。お楽しみに。
なお、前々号「状態遷移図が好き」の結果は公開中。是非ご覧下さい。
⇒http://www.ObjectClub.jp/special/kininaru
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。年末ジャンボ宝くじ、みなさん買ってらっしゃいま
すか？売り場は常に人だかりが出来てますね。夢を買う宝くじ、夢の国ディズ
ニーランド。大人になっても、夢見る子供の気分を忘れることはできないもの
です。さぁ、もうすぐクリスマス。あなたは誰に夢をプレゼントするのですか？
今週の強引な一言
*** 亀の甲より年の劫（ことわざ） ***
今や部長となったあの人も、昔はバリバリの開発者だったかもしれません。た
まには、開発の知恵を何か盗めないかという気持ちで、開発の相談事をしてみ
るのはいかがでしょうか。思わぬ収穫があるかもしれませんよ。
（さとみ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/community/object_ml/help/
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003-2004 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.