1 :
仕様書無しさん:
みなさん(みなさんの会社)はどのような手法で
ソフトウェアの見積もり(金額)を出してますか?
ステップ数、プログラムの行数による計算ですか?
ファンクションポイント法ですか?
人月計算ですか?
私の会社では、
基本仕様書から、各機能を洗い出し、
その機能の量や複雑さなどから、作成するのに何日(何ヶ月)かかるかを算出し
「X日か掛かりますから、見積もり金額はY万円になります」
という出し方をしています。
しかし実際のところ
一生懸命見積もりを計算して、客に提出しても
客の稟議が通らないことがほとんど。
客が言う「この金額までなら出せます」という金額が
システム全体の値段になってしまっています。
それが普通。
んで、客が出せる額と(これが増えることは普通無い。個人経営で無い限り)
客の要求とのせめぎあいになる。
相手も不具合修正と抱き合わせで追加仕様を要求したり。
4 :
仕様書無しさん:03/10/29 12:27
>3
わざわざ探してきたのかよw
6 :
仕様書無しさん:03/10/29 14:07
>1は逃げたな
丼
8 :
仕様書無しさん:03/10/29 14:14
そしてそろそろ>1擁護のジサクジエンレスが付くヨカーン
9 :
仕様書無しさん:03/10/29 14:18
>>3 このスレ立てたモノですが
そんなスレ立てた人物とは違います
スレを立てるのは初めてです。
>>3 わざわざごくろうさん
で、そんなことして何になるんの?
労多くして益なしとはこのことだな
仮に同じだとして、だから何だって感じだな
11 :
仕様書無しさん:03/10/29 14:26
>9=>10
だからさぁ、そうやって段落毎に意味無く改行するとこがそっくりだってのw
あと、句読点を忘れがちなとこもねw
もうちょっと文章をひねる癖を付けないとジサクジエンはできないぞ!!がんがれ!!!
>3です。
ごめんなさい、>1さんを叩くつもりとかそんなんじゃなくて、純粋に
同じ人かな?って思ったから聞いてみただけで。
もし同じ人だったら、ほんとに今の職場から逃げたくて一生懸命なんだなあ、
と思っただけです。ほんとにごめんなさい。
あと、信じてもらえないかもしれないけど、私も>3以降は書いてません。
13 :
仕様書無しさん:03/10/29 18:03
詳細設計くらいから行数をエイヤと見積もって割り出す。
その程度のことですらオレ以外はやってない…
地鎮祭も終わったようなので(w
本題に戻るとして、
見積もりねえ。うちの場合は、だいたい既存のパッケージをカスタマイズ
するのがほとんどだから、内容に応じて自ずと値段が決まっちゃってるんだよねえ。
それこそSUBWAYのサンドイッチみたいに。
少なくともプログラマが文句を言う余地はありません。
そのかわり>1のように値切られることもない。それだけ幸せなのかな?
16 :
仕様書無しさん:03/10/30 00:16
見積もりで腹が立つのが、
こっち「見積もり金額はこれくらいで」と言って、
それに、OKした後で、
こういう処理だの、この機能を追加しろだの、
見た目を綺麗にしろだの、言ってくること。
それで追加費用が、発生すると言うと、
「最初の見積もりに、その部分は入ってないの?」だの
「もう値段の話は、もうついたはずだ。」だの
「これくらいすぐ出来るでしょう、サービスで入れてくれないの?」だの
言ってくること。
17 :
仕様書無しさん:03/10/30 01:17
建築で例えると理解してもらえる。
逆にアホみたいな安い値段提示して仕事とっといて「機能はすべてオプションです」とか言われると腹立つ。
内容を確かめないお前が悪い。
20 :
仕様書無しさん:03/10/30 02:58
つーか自社の社長自体が半分の工数でやれって言うのまずいよね。
無理すると案の定確認漏れがあったり設計が練れてなくて無駄な苦労したり
納期遅れやバグが出て、落とし前の小出し変更が始まる。
結果、倍以上のコストがかかる。
最初にゆったりと詰めて、すぱっと納品すれば変更は全て追加料金取れるのに。
あとペナルティがあっても、現場の者ががんばって追加料金取れるよう交渉したのに、
社長がびびってサービスにしちゃったり。せっかく対等な立場に持ってったのに
一回サービスすると客は脅せばサービスが増えると思い始めるんだよね。まずいよね。
初期導入のクライアントの場合は
リクエストの内容から最低限度必要な内容だけを
初期バージョンにしてコストを低く抑えるようにする
もちろん、後の機能追加時の費用はきちっと説明する
内容にもよるけど納品後のデザインや操作性のリクエストに関しては
初期の仕様策定から大幅にずれていない限りはできる範囲で
無償でやってる
23 :
仕様書無しさん:03/10/31 04:11
>>21 >リクエストの内容から最低限度必要な内容だけを
高尚なお客さんしか相手にしてないようだね。うらやましい。w
「最低限度」とか「必要」とか分からない人に限って感情的でね。
それにその交渉術で世間を渡って来たんだろうし。
そして、気が強いということは実は金持ってるからで、金持ってる人が
家やフルオプションのセルシオを買おうとしてると思えば、
要望削るよりも料金上げる方が平和に済むケースもあろうかと思う。
逆に高尚なお客さんだけでなく、ほんとに金がない場合も”紳士的”で
「最低限度必要」という理性的提案に応じるようなイメージがある。
>>17 監理と積算はコンピュータシステムのどの工程に充てるの?
試験は建築のどの工程に?
25 :
仕様書無しさん:03/11/02 14:04
今、ファンクションポイントで
見積もりを出してくれって言われて
勉強しているんだけど、
いまいち、どうやって見積もればよいのか分からない
あまりファンクションポイントって聞かないけど
ファンクションポイントで見積もりをしてる会社ってあるのかな?
26 :
仕様書無しさん:03/11/04 00:56
>その機能の量や複雑さなどから、作成するのに何日(何ヶ月)かかるかを算出し
>「X日か掛かりますから、見積もり金額はY万円になります」
>という出し方をしています。
単純にこれだと、
個々の能力・実力の違いと言うのは考慮されない。
できる人間ほど損をし、できない奴ほど得をすると言うことになる。
そのあたり、どうやってますか?
27 :
仕様書無しさん:03/11/04 01:09
>>26 できない奴に合わせるんじゃないの、ふつう?
ウチは人月ベースで出してるけどいい加減疲れた。
・・・っていうかさ、ものすごく利益率がよくなるってわけでもなし、なんだかなぁ、って感じ。
28 :
仕様書無しさん:03/11/04 10:04
一番できない奴に合わせてたら、
客先に
「何を考えてこんな見積もり出しとんじゃ ゴルァ
顔を洗って出直してこい。」
と怒鳴られる
まぁ、実際怒鳴られるのは俺達PGじゃなく、営業なんだけど・・・
やっぱ、どの辺りに合わせるかが難しい。
そこで自分たちの腕に自信があれば、
---できない奴がどこの会社にもある程度いるってことも勘案して---
「じゃあ余所へ行ってください。この品質、この機能を満たすには
誰がやってもこれだけの期間と費用がかかります」
とか言えるんだが。
まあ普通のお客さんはそこで余所のもっと見積りの安いとこに
行って後で痛い目を見る、と。
30 :
仕様書無しさん:03/11/05 09:36
俺の部署は、基本はVBなんだけど
よその部署で、COBOLやRPG3を使っている所がある。
なんか、そこでは、ステップ数で
見積もりが決まるようで
この前も、機能追加で
「変更前がXXステップで、変更後がYYステップなので
いくらになります。」
なんて言っていた。
これは、COBOL独特の算出方法なんですか?
冗長したプログラム書くのが、得意中の得意の奴がいるんだけど、
そいつが、一番売り上げが多いってことになりそうな、気がするんだが・・・
>1=>30は、まず正しい日本語を覚えようなw
なんか、不自然な表現してますか?
35 :
仕様書無しさん:03/11/05 13:28
>31が親切に教えてくれたじゃんw
36 :
仕様書無しさん:03/11/05 13:36
冗長しているか?
Yahooの掲示板だと、何にも言われんぞ。
37 :
仕様書無しさん:03/11/05 13:37
>36
………わかりやすすぎ。
38 :
仕様書無しさん:03/11/05 13:42
本筋から離れたことで煽るなや、お前ら。
>36
なんでそこで屋風が出てくるのかが謎なんだが。
「冗長した」という日本語はない
と>31その他は言いたいんじゃないのか?
40 :
仕様書無しさん:03/11/05 13:52
『冗長なプログラム書くのが、得意中の得意の奴がいるんだけど』
って書けばいいの?
どっちでも、意味通じるだろ
>>40 意味が通じるとかいう問題ではない。
日本語においては『冗長した』という表現は誤り。
そういうわけで、40もアフォ確定。
『冗長な』って書くんですか。
いや、これは勉強になりました。
(恥ずかしいです。)
で、30の質問の方、よろしくお願いします。
43 :
仕様書無しさん:03/11/05 14:14
>>22 あと、仕事以外の分野で自分がゴネる側を試してみるのも良い勉強になる。
車を買う時とか家を建る時とかに、色々と難癖をつけて、他業種の人は
それをどうかわしていくのかは参考になるらしい。
「冗長なプログラムを書くのが得意」というのは、そのCOBOLerな
お友達のこと?
日本語がアレっていうか、なんか文章が解りづらいんですが。
俺、日本語教室の通信講座受けるわ。
>>44 そうです。
46 :
仕様書無しさん:03/11/05 15:00
画面数・機能数が大体決まった段階で、
画面、機能の難易度を3段とか5段に自分で評価して、それに対して時間を決めて、えい!って。
あとそれに前工程工数やら、結合以降のテスト工数やらを足す。
世の中にはとんだ暇人もいたものだ・・・
勘でしょ。勘
49 :
仕様書無しさん:03/11/05 16:54
>>48 KKDだよ。
KAN と
KEIKEN と
DOKYO
50 :
仕様書無しさん:03/11/06 03:59
>>46 あ、オレも似たような出し方している。
めんどくささ度とあぶなさ度で3段階つけてそっから工数弾き出す感じ。
KKDだけどね、かなり。
51 :
仕様書無しさん:03/11/06 10:58
>>46 イイね。
ファンクションポイント法を参考にするともっとイイぞ。
>>2-51 もうちょっと実のあるレスを期待した俺はアフォれすか?
>>51 FP法は知ってるけど、ポイントの設定基準って結構難しいよね。
大きい会社なら標準化の一環でやるだろうけど、あっしみないた小さいソフト屋には。
>>52 実際のところ、如何なる手法を用いても最終的にはKKDなんだよ。
完全に定量化できるなら誰も苦労はしてない。
KKDっつーか、KKKかな。
Kan と Keiken と Kakehiki だ。
最後のヤツが一番重要なのがなんとも。
>>53 だからこそメトリクス(測定)が重要になるんだ。
科学的に定量する方法が発見されていないんだから。
(人間の知的活動およびその成果を定量化する方法の発見なぞ望み薄)
測定しておけば、同様の開発の場合、修正係数を適用し精度を高めることが出来る。
開発の変化は加速しているが、その変化差分(&差分の差分)のを勘案することにより、
「見積もり精度を高めること」は可能だと思う。
勘は評価対象にならない。経験も変化には対応できない。
でもプロジェクト実施時のメトリクスデータを保存しているソフト屋っているのかなあ。
>>56 その辺は大手だとあるらしい(日経ITぷろとか今は無きNEXTエンジニア辺りにあったような)
でもさー小さいところだと、定量的に測定しても、その個人誤差が大きくて数値として使えないんだな。w
修正係数が出し切れないと。w
58 :
仕様書無しさん:03/11/07 02:51
>>56 測定つーかさ、過去の見積もりとか進捗は参考資料として残しておくってことじゃ
ダメなの?
「経験値」とか「さじ加減」とか、表現はいろいろだけど
結局は勘ってことだな。そしてデスマに突入すると。
>>58 その場合の問題点は、自社の技術レベルが客観的に平均に達しているかだな。
そうじゃないと、(同じ単価になった場合)他社より割高になってしまう。
まあ、それでしかできないという実績があるから、その見積は自社的には正しいけど・・・。
61 :
仕様書無しさん:03/12/13 01:28
再開してくれ
ああKKKね。
子役キッチリカッチリ打法ね、うん。
>>62 マガ派かよ。w
まあ、数値の蓄積に裏打ちされたKKDしかないんだよな。
完全定量化できるならば、見積ソフトに案件突っ込めば自動的に出てくるし。
64 :
仕様書無しさん:04/05/09 09:53
FP法は大規模な開発では、精度が保てないと思うんですが、
皆様どうお考えでしょうか。
あと、2次受けの際に、難易度について文句つけられて、
実コストよりもかなり安く叩かれた事がありましたね。
漏れが聞いたのは仕様作成からで一日50ステップだそうだよ・・・
本当は如何なのよ?おしえてみそ・・・
67 :
仕様書無しさん:04/08/08 00:28
冗長した、でも、冗長な、でもどっちでもええやろ。
そんなん得意げにつっこむなよ。さむい。
なんで、>30の日本語直してやらにゃならんの。
俺の客先は見積もりなどしない
必要な機能を設計と実装を反復してどんどん作っていって、
予算がなくなったら要員を減らす、それが逆効果で残業で工数かさんで赤字
その繰り返し
ちなみに社員1万人超の超大手メーカー
69 :
仕様書無しさん:
>担当人数:4名、必要人月:20人月、使用人月:16人月、開発コスト抑制率:40%
なんかおかしくね?