アカウント名:
パスワード:
金を湯水のごとくつぎ込んで、複数の調査会社入れてコードやシステムをレビューしたり、別の担当者による複数のアルゴリズムで多数決したり、複数のデータセンターに冗長化された構成にしたり、することはできると思うけど、それにかかるコストと、まぁそこそこ動く安いヤツでの費用対効果でしょう。
それでも心配というなら、保険でも作ればいいと思う。保険会社がコードやシステム、体制の調査して金額弾きだすんだろうけど。その保険に入るかどうかも、費用対効果だろうけどね。
クソなものと良い物のどっちがいい?っていけば誰だって良い物が欲しいはずで、あとはコスト比較だと思うしね。あとはそのクソがどこまで容認できるかってのを決めるだけだろう。
んで、そのどこに落とし所を持っていくのかをずばって決めるのが経営の仕事だと思うわー
リンクされてるThe Atlanticの記事ではアルゴリズム取引なんかを例に出してプログラムエラーが途方も無い損失を引き起こしうるが、決定権を握っている人たち(男性ホルモンで行動してるトレーダーとか)はコストを重視しがちでリスクを過小評価しているというようなことを書いてるみたいです。つまり、
>そのどこに落とし所を持っていくのか
が上手くいかない構造がヤバいよね、みたいな話ですな。リスクを過小評価するってのは人間の性みたいなものじゃないかとも思いますけど。
仮にエラーが起きる確率が10年に1度程度で、いくらかの損失が出るくらいなら、品質が悪くてもほうっておけみたいな判断になるでしょうけど、10年に1度の確率で数億ドル、取引が複雑になるにしがって損失が増えるとすると数百億ドル数千億ドルとふくれあがっていけばエラー一発で破綻という可能性も出てくるので、そうしたリスクが正しく評価できてないというのはたしかに恐ろしいかもしれません。
投資銀行なんかは、プリンシパル=エージェント問題が典型的に出るところ(品質の低いプログラムでバグが出て会社が潰れても、最悪首になるだけ、もしも品質を犠牲にした開発ですごい利益が出たらボーナスたっぷり)なので、リスクの過小評価の一員になっているかもしれませんね。
通常の金融機関などは普通に保険に入っているかと。つまり、4億4千万ドルなる損失も、丸ごとかぶることはほぼなく、日常的に「品質の高いソフトウェアと品質の低いソフトウェアとの差分」と保険のコストとを天秤にかけているはずです。そして品質が低いソフトウェアが選ばれているのだと思います。
一方、投資銀行やファンドの場合は、膨大な損失で破綻した場合だって、実際にはその損失全部を蒙ることはまずなく、破産手続きの中でその大半は結果的に棒引きされるわけです。つまり、ファンドトレーダーがリスクを過少見積もりするのは基本的には理にかなっている。
これに
つまり、みずほは正しい
費用対効果ならまだ理解できるけどコストバカ高いのに低品質な物があるからこそ問題だと思うけどな。安くて低品質、高くて高品質、なら費用対効果のバランスって言えるけど高くて低品質なら何の意味もない。大体有名所の仕事はそういうものだけど。なにせ有名所といっても直接してるわけじゃなく、自分達は高額で請け負って下請けにその半額とかで回すだけのことだし。その下請けが更に下請けに出して~~、で結局入札額の1/10みたいな開発費で底辺の所が行うだけのこと。あれ、じゃあやっぱり費用対効果はあってるのかw 最終的な一番最後の下請けの開発費でいえばw
つまり中間マージンなくせば全て解決。流通でもなんでもそうだしな。
孫請けなどの多重下請けが問題かなー?それであれば、多重下請けなんてしていないで直接仕事を取りに行けばいいんじゃないの?それができない理由が多重下請である理由だと思うわー。そして、そこに価値があると思っているから、金額があがるんじゃないの?
大手からの二次受けくらいだと、直接取引するには口座がなんとかかんとかというもっともな理由があるんですけど、それ以下になると単に営業のヒエラルキーとメンツによって決まってるだけだと思います。
中間マージンはリスク対策費でもあるので、むやみに削ると後が大変ですよね。最近のアマゾンは発売日に品切れが普通になっているのが悲しい、かと言って街の本屋さんは駆逐されて売ってませんから。
塩梅なので、最終的にはエイヤアと交渉で決めるしかないでしょう。
よくよく考えてみたら、PGとデバッガが”技術的に納得した上で”納品と言うのは、恐ろしく難しいという事に気がつきました・・・。
#予算が潤沢にあり、同じく期間も潤沢にあった場合のみ、条件として当てはめれると思いました。
多くはPGとデバッガなんて段階の問題じゃないのです。仕様確定の段階で遅れに遅れてテストの時間がないとか、決まった仕様通りに作ってテストはじめたら、発注者が見て「うちの言った仕様と違う」で慌てて修正とか。このふたつのコンボとかも当然のようにあったり。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
費用対効果 (スコア:2)
金を湯水のごとくつぎ込んで、
複数の調査会社入れてコードやシステムをレビューしたり、
別の担当者による複数のアルゴリズムで多数決したり、
複数のデータセンターに冗長化された構成にしたり、
することはできると思うけど、
それにかかるコストと、まぁそこそこ動く安いヤツでの費用対効果でしょう。
それでも心配というなら、保険でも作ればいいと思う。
保険会社がコードやシステム、体制の調査して金額弾きだすんだろうけど。
その保険に入るかどうかも、費用対効果だろうけどね。
クソなものと良い物のどっちがいい?っていけば誰だって良い物が欲しいはずで、あとはコスト比較だと思うしね。
あとはそのクソがどこまで容認できるかってのを決めるだけだろう。
んで、そのどこに落とし所を持っていくのかをずばって決めるのが経営の仕事だと思うわー
by rti.
Re:費用対効果 (スコア:5, 興味深い)
リンクされてるThe Atlanticの記事ではアルゴリズム取引なんかを例に出して
プログラムエラーが途方も無い損失を引き起こしうるが、決定権を握っている人たち(男性ホルモンで
行動してるトレーダーとか)はコストを重視しがちでリスクを過小評価しているというようなことを
書いてるみたいです。つまり、
>そのどこに落とし所を持っていくのか
が上手くいかない構造がヤバいよね、みたいな話ですな。
リスクを過小評価するってのは人間の性みたいなものじゃないかとも思いますけど。
仮にエラーが起きる確率が10年に1度程度で、いくらかの損失が出るくらいなら、品質が悪くてもほうっておけ
みたいな判断になるでしょうけど、10年に1度の確率で数億ドル、取引が複雑になるにしがって損失が増えると
すると数百億ドル数千億ドルとふくれあがっていけばエラー一発で破綻という可能性も出てくるので、そうした
リスクが正しく評価できてないというのはたしかに恐ろしいかもしれません。
Re:費用対効果 (スコア:2)
投資銀行なんかは、プリンシパル=エージェント問題が典型的に出るところ
(品質の低いプログラムでバグが出て会社が潰れても、最悪首になるだけ、
もしも品質を犠牲にした開発ですごい利益が出たらボーナスたっぷり)
なので、リスクの過小評価の一員になっているかもしれませんね。
Re: (スコア:0)
通常の金融機関などは普通に保険に入っているかと。つまり、4億4千万ドルなる損失も、丸ごとかぶることはほぼなく、
日常的に「品質の高いソフトウェアと品質の低いソフトウェアとの差分」と保険のコストとを天秤にかけているはずです。
そして品質が低いソフトウェアが選ばれているのだと思います。
一方、投資銀行やファンドの場合は、膨大な損失で破綻した場合だって、実際にはその損失全部を蒙ることはまずなく、
破産手続きの中でその大半は結果的に棒引きされるわけです。
つまり、ファンドトレーダーがリスクを過少見積もりするのは基本的には理にかなっている。
これに
Re: (スコア:0)
つまり、みずほは正しい
Re: (スコア:0)
費用対効果ならまだ理解できるけど
コストバカ高いのに低品質な物があるからこそ問題だと思うけどな。
安くて低品質、高くて高品質、なら費用対効果のバランスって言えるけど
高くて低品質なら何の意味もない。
大体有名所の仕事はそういうものだけど。
なにせ有名所といっても直接してるわけじゃなく、自分達は高額で請け負って下請けにその半額とかで回すだけのことだし。
その下請けが更に下請けに出して~~、で結局入札額の1/10みたいな開発費で底辺の所が行うだけのこと。
あれ、じゃあやっぱり費用対効果はあってるのかw 最終的な一番最後の下請けの開発費でいえばw
つまり中間マージンなくせば全て解決。
流通でもなんでもそうだしな。
Re:費用対効果 (スコア:1)
孫請けなどの多重下請けが問題かなー?
それであれば、多重下請けなんてしていないで直接仕事を取りに行けばいいんじゃないの?
それができない理由が多重下請である理由だと思うわー。
そして、そこに価値があると思っているから、金額があがるんじゃないの?
by rti.
Re: (スコア:0)
大手からの二次受けくらいだと、直接取引するには口座がなんとかかんとかというもっともな理由があるんですけど、それ以下になると単に営業のヒエラルキーとメンツによって決まってるだけだと思います。
Re: (スコア:0)
中間マージンはリスク対策費でもあるので、むやみに削ると後が大変ですよね。
最近のアマゾンは発売日に品切れが普通になっているのが悲しい、かと言って
街の本屋さんは駆逐されて売ってませんから。
塩梅なので、最終的にはエイヤアと交渉で決めるしかないでしょう。
Re: (スコア:0)
契約以降の全ての工程に影響を及ぼすのに、契約に関連する部署や人員が品質管理のコントロール下に存在しないんじゃ、そりゃ皺寄せを受けるところはデスマーチになります。
品質管理の本来のあり方論でいえば、社長だろうがCEOだろうが誰だろうが、品質に影響する者は品質管理のルールに基づいて職務を遂行するはずなんですけどね。
「俺は品質には厳しいよ」
「でも俺はルールには縛られないよ」
は根本的に矛盾している。
Re: (スコア:0)
よくよく考えてみたら、PGとデバッガが”技術的に納得した上で”納品と言うのは、恐ろしく難しいという事に気がつきました・・・。
#予算が潤沢にあり、同じく期間も潤沢にあった場合のみ、条件として当てはめれると思いました。
Re: (スコア:0)
多くはPGとデバッガなんて段階の問題じゃないのです。
仕様確定の段階で遅れに遅れてテストの時間がないとか、
決まった仕様通りに作ってテストはじめたら、発注者が見て「うちの言った仕様と違う」で慌てて修正とか。
このふたつのコンボとかも当然のようにあったり。