career
狼ユーザーを撃つ銀の見積もりはない
「納得できるITコスト」はいいけど、人月はそもそも原価じゃないし、ユーザは残業代を払いたくないとか以前に無駄な金を払いたくないだけだし。人月でもFPでもやってることが同じなら単位の違いだけだし。
「「人月からの脱却」の意味するところはベンダーが「ユーザーに“原価”を見せたくない」、ユーザーが「ベンダーの“残業代”を払いたくない」。話がかみ合うはずはない。「人月」に頼り切っているのが現状」
人月の機能を分析
「人月からの脱却」の意味するところは,ベンダーが「ユーザーに“原価”を見せたくない」,ユーザーが「ベンダーの“残業代”を払いたくない」ということ。話がかみ合うはずはない。
この話はよくわからないけど、ものごとの価値は原価で決まるわけではないですね。
てかSIもう辞めようよ。ほんとに自社に必要なシステムなら技術者を直接雇おうよ。それに受託開発ばっかりやってたら日本の技術者はいつまでたっても商品となるようなソフトウエア作らないでしょ。
ベンダーの目指すところは最終的にパッケージ売り切りと同じスタイルなのかなー。炊飯器ならとりあえず買って使いにくい!と思っても自己責任ぽいんだけどな。
この要望だとユーザが派遣契約で技術者を招き入れて納得いくまで開発すれば双方ハッピーだと思うよ!
ベンダー(PM)「仕事したくない」 vs ユーザー「勉強したくない」 まぁサラリーマンは永遠にサラリーマンやってりゃいいと思うよ。
//「人月からの脱却」の意味するところは,ベンダーが「ユーザーに“原価”を見せたくない」,ユーザーが「ベンダーの“残業代”を払いたくない」ということ。話がかみ合うはずはない。//
「人月からの脱却」の意味するところは,ベンダーが「ユーザーに“原価”を見せたくない」,ユーザーが「ベンダーの“残業代”を払いたくない」
ユーザー側が満足できて、ベンダー側がやる気を失わない指標ってなんなんだろう
つまり妥当かつ実用的で有用な値って事>人月
自分が欲しい物の要求仕様ぐらい自分で作ろうよ。あと、プログラム作れないSEはいらん
業界全体が本気で人月に代わる指標を作ろうとしないからじゃない?スタロジみたいにビシッと決めちゃわないといつまでも変わらないかと.
善し悪しは別にして何も考えず見た時のわかりやすさが最強>人月
じゃあもう見積もりは人月でオッケー!だからお互い変化を抱擁しようネ!
このやり取りは、請負なのか委託なのかがハッキリしていないのが問題。こうやって読むと、責任の所在が不明確なSIって歪んだモデルだと思えてきた。
「人月からの脱却」の意味するところは,ベンダーが「ユーザーに“原価”を見せたくない」,ユーザーが「ベンダーの“残業代”を払いたくない」ということ。
人月工数(笑)
そこまで精密な見積もりなんか出せやしないし(仕様があいまいなのにどうやって出すのさ)それを見ても正当かどうかなんて判断できないだろ
ベンダー「ユーザーに“原価”を見せたくない」、ユーザー「ベンダーの“残業代”を払いたくない」ので、不本意ながらも人月計算に落ち着く
仕様を変えさえしなけりゃ安くできるんですけどねぇ
長らく使われてきたこの人月単価や人月計算を,ユーザーとベンダーの両者が止めたいと思っている
人月内訳開示はベンダーにとって追加請求の言い訳に使われるから、人月脱却の方がユーザ側からしてもメリットあるように思うのだが。
「内訳の理由を見せたくない」の一種だけれど、どうしてもベンダーの要求はどうしても途中で変わるので、そのマージンを確保しなければいけないなどの流動部分があるからでは…
[PR]ブログのペットがお留守番
はてなブックマークの中から「これはひどい」エントリーを取り上げて、Digg風に表示したサイトです。より人の為になるこれはすごいバージョンもあります。
はてブで「これはひどい」タグを付けると投票としてカウントされ、コメントを書き込むとコメントとして反映されます。はてな認証APIによる投票にも対応しています。
コメント
career
狼ユーザーを撃つ銀の見積もりはない
「納得できるITコスト」はいいけど、人月はそもそも原価じゃないし、ユーザは残業代を払いたくないとか以前に無駄な金を払いたくないだけだし。人月でもFPでもやってることが同じなら単位の違いだけだし。
「「人月からの脱却」の意味するところはベンダーが「ユーザーに“原価”を見せたくない」、ユーザーが「ベンダーの“残業代”を払いたくない」。話がかみ合うはずはない。「人月」に頼り切っているのが現状」
人月の機能を分析
「人月からの脱却」の意味するところは,ベンダーが「ユーザーに“原価”を見せたくない」,ユーザーが「ベンダーの“残業代”を払いたくない」ということ。話がかみ合うはずはない。
この話はよくわからないけど、ものごとの価値は原価で決まるわけではないですね。
てかSIもう辞めようよ。ほんとに自社に必要なシステムなら技術者を直接雇おうよ。それに受託開発ばっかりやってたら日本の技術者はいつまでたっても商品となるようなソフトウエア作らないでしょ。
ベンダーの目指すところは最終的にパッケージ売り切りと同じスタイルなのかなー。炊飯器ならとりあえず買って使いにくい!と思っても自己責任ぽいんだけどな。
この要望だとユーザが派遣契約で技術者を招き入れて納得いくまで開発すれば双方ハッピーだと思うよ!
ベンダー(PM)「仕事したくない」 vs ユーザー「勉強したくない」 まぁサラリーマンは永遠にサラリーマンやってりゃいいと思うよ。
//「人月からの脱却」の意味するところは,ベンダーが「ユーザーに“原価”を見せたくない」,ユーザーが「ベンダーの“残業代”を払いたくない」ということ。話がかみ合うはずはない。//
「人月からの脱却」の意味するところは,ベンダーが「ユーザーに“原価”を見せたくない」,ユーザーが「ベンダーの“残業代”を払いたくない」
ユーザー側が満足できて、ベンダー側がやる気を失わない指標ってなんなんだろう
つまり妥当かつ実用的で有用な値って事>人月
自分が欲しい物の要求仕様ぐらい自分で作ろうよ。あと、プログラム作れないSEはいらん
業界全体が本気で人月に代わる指標を作ろうとしないからじゃない?スタロジみたいにビシッと決めちゃわないといつまでも変わらないかと.
善し悪しは別にして何も考えず見た時のわかりやすさが最強>人月
じゃあもう見積もりは人月でオッケー!だからお互い変化を抱擁しようネ!
このやり取りは、請負なのか委託なのかがハッキリしていないのが問題。こうやって読むと、責任の所在が不明確なSIって歪んだモデルだと思えてきた。
「人月からの脱却」の意味するところは,ベンダーが「ユーザーに“原価”を見せたくない」,ユーザーが「ベンダーの“残業代”を払いたくない」ということ。
人月工数(笑)
そこまで精密な見積もりなんか出せやしないし(仕様があいまいなのにどうやって出すのさ)それを見ても正当かどうかなんて判断できないだろ
ベンダー「ユーザーに“原価”を見せたくない」、ユーザー「ベンダーの“残業代”を払いたくない」ので、不本意ながらも人月計算に落ち着く
仕様を変えさえしなけりゃ安くできるんですけどねぇ
長らく使われてきたこの人月単価や人月計算を,ユーザーとベンダーの両者が止めたいと思っている
人月内訳開示はベンダーにとって追加請求の言い訳に使われるから、人月脱却の方がユーザ側からしてもメリットあるように思うのだが。
「内訳の理由を見せたくない」の一種だけれど、どうしてもベンダーの要求はどうしても途中で変わるので、そのマージンを確保しなければいけないなどの流動部分があるからでは…