- - PR -
システムの見積もりに関する会議室はどこが適切ですか？
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2005-10-19 22:51
フリーランスPGなので見積もりするようなことはほとんどないのですが、
悪態のプログラマ - やってみなきゃわからないという現実というのが現実ではないかと。 ポイントは技術ではなく相手が何をしたいのかをいかに見つけることで、その意味では小さくても動くシステムがあったほうが良いのではというのが自分の意見です。 なので、XPバンザイだったりするんですね。 _________________ http://www.furukawa-select.com/mt/ @BLOG(atsushifxの七転八倒) <font size=-1>[ URL部分を書き直し メッセージ編集済み 編集者: あつしfx 編集日時 2005-10-19 22:54 ]</font> [ メッセージ編集済み 編集者: あつしfx 編集日時 2005-10-19 23:02 ] | ||||
|
投稿日時: 2005-10-20 09:05
「やってみなけりゃわからない」というのは常々私も感じていますが、 それでも見積もらなきゃいけないのがＳＥなんですよね （いやＳＥだけではないと思うけど）、 「オレは超能力者か占い師か？、どうやって見積もるんだこんなもん」と 思うこともよくありますが、それでも何がしかの根拠を作って見積もりするんですよね。 「本見積もり」「仮見積り」はの話がありましたが、設計後再見積もりは確かに発想はその通りです。 でもだいたい「仮見積もり」の段階でも一度金額が出てしまうと、それが一人歩きして あとから値増しなんて出来るほうがまれで （いやぁ土下座同然で値増し要求やることもありますけどね） んで、それが怖いんで、倍とか３倍とかして見積もり作ったら、こんどは金額で失注するんで、次は前提条件てんこ盛り、そしたら客はそんなの読まないから、 今度は説明不十分でまた技術屋の敗北orz... 競合他社居た場合には、「これじゃ向こうのほうが安かったなぁ」とネチネチと言われ・・・ 辛い、、、ああぁまたグチってる。 でも、Cafeでこのまま続ける話じゃなさそうですが、あちらがあちらなのでちょいと様子見ます。 [ メッセージ編集済み 編集者: KENCH 編集日時 2005-10-20 09:11 ] | ||||
|
投稿日時: 2005-10-20 20:18
マイホームを設計させて、契約しなかった人です（笑）
たとえば、家の場合、費用のほとんどは水回りに集中します。台所、風呂、洗面所、トイレですね。このうち、割合が一番高いのは台所。ついで風呂です。これらの部屋の大きさ、位置さえ変わらなければ、場合によっては部屋の配置を全く変えても、ほとんど費用は変わりません（という説明を受けました）。 同じように、「ここを変えられると困るよなぁ」というところを見つけ、そこに前提条件を集中、つまりこの時点である程度設計して、「この前提条件から変更がある場合、再見積となります」の様な書き方をしてはどうでしょう？ 要は「設計後」とするから不安なので、「条件から外れる場合」であれば、どんな契約でもたいていそうですから、安心できるのではないでしょうか。 あ、土地を探しながら家の設計を依頼したので、
に符合すると思います。 ___________________________________________________________________ □ written by Jitta on 2005/10/20 □ Microsoft MVP :Visual Developer ASP/ASP.NET Oct.2004-Sept.2006 | ||||
|
投稿日時: 2005-10-21 09:24
前提条件の集中ですか。正直あまり意識してなかったかもしれません。 特にいまはどれだけ重箱の隅を突付けるかが肝になっておりまして自分の苦手な作業です。結構アバウティ〜な性格なので。 思わぬ枝葉の前提条件が書きもれていて、 「あいたたたた、そう来たかぁ」 なんてこともありました。 でも、振り返ると、無意識的にも、一番困るところは一番目立つところに書いていたかもしれません。 その中の一つに、ＯＳだったり言語だったりＤＢだったりする場合があって、それは逆に言うと、要件だけを言ってくる顧客にはなんの意味も無いものだったりしますので、ある意味こちらのいいように出来るのですが、あるときそのインフラではどうしても実装が難しい要件があって、 「前提条件がこのインフラなので、この要件をねじ込むのは難しいんですよ」と言ったら、 「そんなのそっちの勝手でしょ、私はこの要件を全て満たしてくれればそれでいいんですから、実装方法は問いません、要件は一つも変わってないんだから問題ないでしょ」 なんてやり取りをしたこともありましてね、迂回したところでそれはそれで工数かかるし、別な要件を満たすためにこのインフラなんだからぁみたいな感じで。 それからＯＳ，ハード、ＤＢなんでも全部要件を細かく調整してからでないと決定できなくなりました。それはそれでいい面もあるんですが、いかんせん時間がかかるしインフラ側がいつまでたっても発注できない・・・(;_;) 別なお客は、「とにかくこのＤＢが前提だから」ってお客もいて、それはそれで困る場合もあるんですけどね。 逆にアプリ側の業務要件的なところは、あとから何とか調整効くことが多いのでよほど設計の根幹に関わる事以外はそうそう前提に並べることも少なかったかなぁなんて思います。 アプリ側で特に注意することろは、目的とスコープ（適用範囲？、分析範囲？）でしょうかね。 範囲外が範囲内かは明確に切り分けられるようにしておかないと後からなんでもかんでも入れられちゃう。 なかなか、難しいです。日々酒豪^H^H修業です。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。