＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
見積もりパターン・アンチパターン
| 投票結果総投票数：43 | |||
|---|---|---|---|
| 1.言語等アーキテクチャ |  |
3票 | 6.98% |
| 2.ミッションクリティカル性 | |
3票 | 6.98% |
| 3.チームの質 | |
12票 | 27.91% |
| 4.開発環境 | |
1票 | 2.33% |
| 5.営業的事情 | |
21票 | 48.84% |
| 6.見積手法 | |
3票 | 6.98% |
| |||
| 投稿者 | 投稿内容 |
|---|---|
|
投稿日時: 2007-04-04 16:00
記事をご一読なさった方にお願いです。
記事を読んで以下の投票にご協力ください。 http://www.atmarkit.co.jp/im/cpm/serial/team04/team04a.html 尚、前回は御指摘ならびに貴重な御意見もたくさん頂きました。有難うございました。 どこかで（最終回？）で頂いた意見も取りまとめさせていただく予定です。 是非、様々な御意見を賜れるとあ有り難い次第です。 第一回で「メンバのスキルとチーム構築プロセス」について 第二回で「モチベーションについて」について 第三回で「そもそも、一番大事なのはなんだっけ？」と取り上げてきました。 今回は「スキルもモチベーションも高いチームが何故生き残れなかったか？」を通して「ステークホルダーの満足」について検討させてもらいました。 其の中で、特に「見積もりアンチパターン」に触れさせていただきました。 是非、同じような「見積もりパターン」に御意見を頂き対と思います。 現在マネージャーの方は自身の経験をご教示いただく形で。 現在見積もりを行う立場にない方は逆に自分のプロジェクトの見積もりを行った人に対して思うことに投票あるいは御意見をください。 見積もりの土台が「機能の数」だとして次に「工数」に影響するもっとも大きい要素はなんですか？ １．言語等アーキテクチャ（フレームワーク、デザインパターンやAPPサーバーやDBプロダクトなどを含む） ２．ミッションクリティカル性 ３．チームの質 ４．開発環境（IDE、ツールなどから、オフショアや全体の規模まで） ５．営業的事情（企業間力関係など） ６．見積手法（FP法、ユースケース法など） 「その他」の方は返答の形でお願いいたします。 追伸： 前回はＡｈｆ様、ラフィン様、加納正和様、よねＫＥＮ様、むさいくろう様、T.O様御意見有難うございました。 取りまとめ記事の際に参考にさせていただきます。 今までのアンケートならびに御意見を元に取り纏めという形で書かせて頂きますので是非今後も御意見のほどを宜しくお願いいたします。 |
|
投稿日時: 2007-04-04 16:21
「その他」に一票。
理由は、「すべて」が重要要素と考えるからです。 私は、規模をFP(ファンクション・ポイント)法にて見積り、 工数、期間はCOCOMOⅡを使用して見積もっています。 特に2～5は、COCOMOⅡでの規模要因、コスト要因に該当しま すので、すべての要素を取り入れています。 |
|
投稿日時: 2007-04-04 16:25
工数 = のべ作業時間 という前提で話をしますが
作れる人がいなければどれだけの金と期間を投じてもモノが完成しませんので 「３．チームの質」としました。 チームの質がどんなに最悪であろうと完成にこぎつける手法があるのであれば 我々技術者は不要ということになりますね。 素人をそのへんで安い時給で雇えばよい。 これではあまりに面白みに欠けますのでさらに次点を考える場合の 指針を考えてみました。 工数 = 作業量 / 作業効率 として考えると 作業効率に影響するのが １．言語等アーキテクチャ ４．開発環境 ５．営業的事情 作業量に影響するのが ２．ミッションクリティカル性 ５．営業的事情 ６．見積手法 かなと思います。 作業効率に影響する部分の方が工数圧縮には効くのですが、 技術的難易度が高い場合、結局チームの質が悪ければ決して完成しないので 場合によっては非常に大きな影響となると思います。 また、営業的事情により作業効率を著しく悪化するケースもありますので 影響度は大きいと言えると思います。 このあたりはケースバイケースなので一概には言えないのでしょうが、 工数への影響を「最悪の場合」と「最良の場合」の落差の激しさで捕らえるか、 それとも経験則的な分布での「悪い場合」と「よい場合」の落差で捕らえるか、 そういったところの前提次第で答えの変わる投票になるのではないでしょうか。 [編集]typo修正[/編集] [ メッセージ編集済み 編集者: nagise 編集日時 2007-04-04 16:26 ] |
|
投稿日時: 2007-04-04 16:40
佐藤@OTさん、いつも拝読させていただいております。
YASUYOKAさんのおっしゃるとおり、すべて大事だと思いますが、 佐藤@OTさんの記事の趣旨・内容をかんがみて、あえて、 「１．言語等アーキテクチャ」 に一票入れさせて頂きます。 僕が技術者としていつも思うのは、 適材適所であるべきだ ということです。 それは全てにおいてですが、記事内容から、特に、 言語などアーキテクチャを無理やり使うべきでないと思っています。 Windows ServerでPerlを使ったり、 J2EEアーキテクチャなのにバッチ処理がやたら多かったり、 映像配信サーバに予算の都合でFreeBSDを立てたり。。。 （上記、間違っているというわけではありません。技術者のスキルを越えているということです） そういうことをされると、 かなりへこみますし、実際に手間もかかるかと思います。 そういう意味では、「チームの質」を選ばれてしまってもしかたないか。。。 |
|
投稿日時: 2007-04-04 17:58
見積上の工数、となると微妙な感じもありますが、
「３．チームの質」に投票しました。 #見積もりを算出する段階で、チームメンバが有る程度確定できるケースは #結構多いのでしょうか？自分の環境限定かもしれませんが、 #メンバが確定した状態で見積を出す機会がなかったりします。 私は「想定する標準的スキルレベル」を基にして工数算定を行っていますので、 「チームの質が異なる ＝ 見積の工数根拠が崩れる」 というところです。 |
|
投稿日時: 2007-04-04 18:17
「チームの質」って、良い／悪いという意味なら、
それって、お客さんに認めてもらえるんだろうか？ （工数＝見積もり＝おカネですよね？） チームの質の一端を担っているプログラマより。。。 |
|
投稿日時: 2007-04-04 18:44
３．チームの質
見積時には実際に開発を行うメンバーを意識しないのでカット。 ５．営業的事情（企業間力関係など） 工数を触ると嘘になるので、見積では値引き等の金額で反映させます。よってカット。 ６．見積手法（FP法、ユースケース法など） 工数というより誤差の問題かと思いますのでカット。 １．言語等アーキテクチャ（フレームワーク、デザインパターンやAPPサーバーやDBプロダクトなどを含む） ２．ミッションクリティカル性 ４．開発環境（IDE、ツールなどから、オフショアや全体の規模まで） この３つの内、１と３は工数に影響しますが開発事情。納品物そのものを決める要素を優先させる意味合いで、「機能の数」と肩を並べるものとして「機能の質」。 よって、「２．ミッションクリティカル性」に投票してみました。 |
|
投稿日時: 2007-04-04 22:52
>５．営業的事情（企業間力関係など）
に入れてみました。 「見積もり」はお客に言う金額を示すと思ってました。 金を得るのに使うものだと思っていますので、金額に影響するのが 一番工数に影響するものだと瞬間的に考えました。 ただ、1分ぐらい考えると、単に自分の立場を表しているに過ぎないような 気もします。 根拠は?と言われたら今の環境でちょっとばかし影響が大きいだけのような。 せいぜいの根拠は。 ・親会社に近いほうが当然工数が上。 ・「技術的見積もり」は外に出さない。 ぐらいですか。私は「技術的見積もり」、純然たる意味で技術的な内容を追求した工数、 は内部でしか使ったことがありません。外部に「真の(?)」見積もりを出したり はしません。 なので、「見積もり」の意味内容が普通と食い違ってるかもしれません。 |
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.