Togetter/min.tを安心してお使い頂くためのガイドラインを公開しました。
編集可能
2010年9月14日

見積もりと発注企業と受注企業の関係

今度は見積もり回り。なぜ見積もりは失敗するのか。 あるべき姿としては発注側のビジネスモデルやバックオフィス系における経費削減度合いによって予算を決め、そこからシステム構築費用を算段すべき。そして受注企業はITの専門家としてどう組むべきかを提案する。
31
MOONGIFT @moongift

次は見積もりの話かなー。見積もりが正確だったことがほぼ皆無なんだけど、他の会社(or 人)はどうなんだろう。見積もりは大抵甘めになりがちだし、昨今はアイミツになって価格低下しがちだと思うんだけど。

2010-09-14 19:50:14
kaz. Suenaga / 末永 和史 @kazSuenaga

@moongift 値付けの妥当性のためには要件確定が必要ですよね、ということでいつものループに陥る予感。。

2010-09-14 19:54:10
たけだっちぃ(ちっちぃ) @yasutkd

@moongift 見積は大体自分のイメージの1.5~1.7倍するとちょうど良くなったりしますねー。それにちょこっと乗っけるとお客様からディスカウント要求されてもなんとか範囲内になること多し、だったり。

2010-09-14 19:56:45
たけだっちぃ(ちっちぃ) @yasutkd

@moongift あとは最初に相手の予算感を聞いてしまうのもアリ、というかよくやる手だったりしますね。そうするとその予算内で最大限の効果となる解法が導き出せるし、その選択肢の中で「クライアントに」取捨選択させられる、と。まークライアントに責任をおっ被せる方法ですねーw

2010-09-14 20:00:21
MOONGIFT @moongift

@yasutkd 私の経験上では初期で見積もりの0.4倍くらいのパフォーマンス。それ以降でも0.8位ですね。なので見積もり予算の1.5~2倍を概算としています。

2010-09-14 20:01:34
MOONGIFT @moongift

発注企業の問題として、開発会社からあがってきた見積もりを予算のベースにすること。開発中に工数が増えても稟議が通らなかったりする。

2010-09-14 20:03:04
MOONGIFT @moongift

@kazSuenaga そもそも見積もりは楽観的観測が入っているので見積もりを元に何かを決めてしまう方がよろしくないですね。

2010-09-14 20:04:49
MOONGIFT @moongift

システムは戦略的なものなので、予算があってしかるべき。なぜか安ければ安いほど良いという風潮がある。発注側はもちろん受託側にも。

2010-09-14 20:06:25
MOONGIFT @moongift

だからオープンソースを使うので安くできますなんてトンデモな意見が出してしまう。

2010-09-14 20:07:16
MOONGIFT @moongift

@yasutkd 責任というかはあれですが、クライアントの予算はないと話にならないですね。

2010-09-14 20:08:07
kaz. Suenaga / 末永 和史 @kazSuenaga

@moongift 見積もりといいつつ請求金額の確定になるのが良くないんですよね。工数が増した責任がどこにあるかがわかりにくいのも一因でしょうが。 見積もりは見積もりであって確定ではない、というのが通らないことが多いです。

2010-09-14 20:08:08
@naoyajoker

機能に根付けがされず、結局人工いくら。しか見られないですからねぇ。。。 RT @moongift: システムは戦略的なものなので、予算があってしかるべき。なぜか安ければ安いほど良いという風潮がある。発注側はもちろん受託側にも。

2010-09-14 20:09:08
kaz. Suenaga / 末永 和史 @kazSuenaga

@moongift 発注企業の問題はもっと深刻で、自分たちがオーダーしているものの完成像がわからない、だから言われた通りの金額を信じる、なんですよね。

2010-09-14 20:09:14
MOONGIFT @moongift

開発会社は大目に見積もって、スムーズにいったら儲けたと思っている。これも実に誠実ではない。工数がかかるならその旨きちんと伝えるべきだし、逆に工数が減ったなら減額するべき。

2010-09-14 20:10:09
MOONGIFT @moongift

企業になると致し方ないこともあるんだけど、契約書とかドキュメントで過剰にヘッジを立てすぎていると思う。その時点で互いの信頼性が損なわれていく。

2010-09-14 20:14:36
kaz. Suenaga / 末永 和史 @kazSuenaga

@moongift そのシステムがなければ何人雇う必要があるのか、からその人件費分をメドにどの程度削減するかで予算建てする習慣がつけばいいのに。

2010-09-14 20:14:47
MOONGIFT @moongift

信頼性がないと工数がかかった時の追加見積もりにも応じてくれなくなったりする。

2010-09-14 20:15:20
たけだっちぃ(ちっちぃ) @yasutkd

@moongift 過去に海外(カナダ)に発注した時(オフショアというより普通の開発発注)には「通常価格」とそれより早く出来た場合の「インセンティブ」、ディレイした時の「ディスカウント」が契約書に明記されてたのが印象的でした。

2010-09-14 20:15:33
kaz. Suenaga / 末永 和史 @kazSuenaga

@moongift 信頼性、というより、線引きが明確になりすぎてその間のあいまいさを埋めることができなくなるんですよね。

2010-09-14 20:15:54
MOONGIFT @moongift

@naoyajoker 個人的には最終的には人が関わっている以上、人月にならざるを得ないのかと思っています。ファンクションが幾つだから~とか言っても、最終的に動くのは人間なので

2010-09-14 20:16:58
てんじゃ @tenja

@moongift 「工数が減ったら減額すべき」は反対意見ですな。機能が見積り時から変わらないのに、工数が減ったなら、設計と開発の優秀さで捻出したのだから、開発会社の利益ですよ。

2010-09-14 20:17:47
MOONGIFT @moongift

@kazSuenaga 価格の妥当性および完成イメージが示せないのは受託側の問題ですね。

2010-09-14 20:17:51
kaz. Suenaga / 末永 和史 @kazSuenaga

@moongift 見積もり通りにしか請求できないから、スムーズに行ったときはその6割程度、問題があっても9割程度のコスト予測で収まるように見積もりを立てるようになるんだと思うんです。

2010-09-14 20:17:54
MOONGIFT @moongift

@kazSuenaga バックオフィス系の場合はそうですね。作業の数値化をしなければ適切なシステム化は難しいと思います。

2010-09-14 20:19:03
MOONGIFT @moongift

@yasutkd 人月とは逆の考えですね、素晴らしい。その商習慣は見習いたい。

2010-09-14 20:20:02
残りを読む(76)

コメント

MOONGIFT @moongift 2010年9月14日
さらにツイート追加。
0
42 @deepsort42 2010年9月14日
@moongift これ言い出したの誰なんだろう...困るよね。 >> だからオープンソースを使うので安くできますなんてトンデモな意見が出してしまう。
0
MOONGIFT @moongift 2010年9月15日
関連性のないツイートが追加されたので削除。
0
phasetransition @cotton_swab 2010年9月15日
これは興味深い議論。というか、IT業界のあるある話かなw。
0