スルガ銀行とIBMのシステム開発を巡る裁判、IBMに74億円超の賠償命令 90
ストーリー by headless
堪忍 部門より
堪忍 部門より
あるAnonymous Coward 曰く、
新経営システム開発プロジェクトの失敗をめぐり、スルガ銀行が日本IBMに合計約111億円の損害賠償を求めていた訴訟で、東京地方裁判所は日本IBMに74億円超の支払いを命じた(スルガ銀行の発表、 静岡新聞の記事、 ITproの記事)。
スルガ銀行の発表によると、判決はスルガ銀行の被った実損害を全面的に認めた内容で、「74億1366万6128円並びにこれに対する平成19年7月18日から支払済みまで年5分の割合による金員」を支払うよう日本IBMに命じたとのこと。一方、日本IBMは「当社に責任がある旨の結論になった部分は不合理。当社は義務をすべて果たしている」として、控訴する方針を示している。なお、日本IBMの申し立てにより判決は主文のみが公開されており、判決理由は明らかになっていない。訴訟の経緯については、ITproの特集に記事がまとめられている。
結局金額が書かれた契約書が有効かどうかの問題 (スコア:5, 参考になる)
よくある、営業がむちゃくちゃな条件でよいことばかりの夢物語を触れ回って不用意に契約を結んでしまったと言う話に見える。
顧客は営業の売り文句を信じて待っていたが完成せず、実働部隊はどかんとできあがっている契約に逆らう事もできず。
従来のこういう案件なら、ならIBMが何とか接待攻勢でもなんでもやって、当初契約に書いて中あった不利な条件をのませ、またある程度自社でも損害をかぶって済ませる所なんだろうが、どこかで顧客側と話が拗れたんだろうな。
結局契約書がどうだったかってところが問題なんだが、IBMは途中で監禁されただの、恫喝されただの、一緒に作っていく姿勢がどうの等と寝技に持ち込んでる [nikkeibp.co.jp]感じがある。IBMの弁護士は優秀なんだなーと言う感想しかない。普通なら100％取られてもおかしくはないだろ。
その優秀な弁護士の能力を、こんな結果を招いた契約を結んでしまった営業にも分けてやってほしい所だ。
なんかSIの未来に響く重大な判決などと、わが身に置き換えている人が多いようだが、わが身に置き換える前にこういうクソな契約を取ってくる営業をどう始末するか考えろといいたい。
Re:結局金額が書かれた契約書が有効かどうかの問題 (スコア:5, 興味深い)
>よくある、営業がむちゃくちゃな条件でよいことばかりの夢物語を触れ回って不用意に契約を結んでしまったと言う話に見える。
同意。大方、契約時のすれ違いに双方気付かないまま、見切り発車で走りだしたプロジェクトなんじゃないかと。
こういう話で本当に不幸なのは、実際に請け負った企業の方だろうと思う。どうせ、ISEとか、そういう所に流れた案件だろうし、実働部隊はさらに、そこと契約した全然別の会社が請け負ってるんだろう。彼らにしてみれば失敗プロジェクトで赤字だろうし、不当に使えないという評価されて迷惑してるんじゃないか？
我が身というか、身近にこういうバカ話は結構転がってるんで「またか？」という印象の方が強いな。
単に規模が大きいからニュースになってるだけの話。規模を別にすれば、そこらで起きてるあたり前の場外乱闘っすよｗ
通知の設定いじったから、ACだとコメントされても気づかない事が多いよ。あしからずｗ
Re:結局金額が書かれた契約書が有効かどうかの問題 (スコア:2)
馬鹿な話は多いけど、それが訴訟になったのは珍しいですね。
何しろ証拠物件がほとんどないし、第三者による証言も得られないし。
関係者同士の水掛け論になるのがオチなのが分かっていて、
なにゆえ今回だけ訴訟に持ち込んだのか、その理由が分からない。
Re:結局金額が書かれた契約書が有効かどうかの問題 (スコア:3)
>なにゆえ今回だけ訴訟に持ち込んだのか、その理由が分からない。
おそらくは「踏み倒し」目的じゃないですかｗ
訴訟に至らなかったけど、大マジに踏み倒したくて因縁つけてきたユーザーさんなら知ってますよ。
通知の設定いじったから、ACだとコメントされても気づかない事が多いよ。あしからずｗ
Re:結局金額が書かれた契約書が有効かどうかの問題 (スコア:1)
＞今回はIBMが債務不履行のようですが？
いやそうとも言い切れない。
それは各々の契約内容に依存する話だから。
それも裁判の争点の一つでは。
それから、
IBM「もっと要件を絞り込んでくれ。」
スルガ銀「やなこった。」
ということがあった場合、それはどちらの責任と判断すべきなのかという問題もある。
Re:結局金額が書かれた契約書が有効かどうかの問題 (スコア:1)
いやまったくほんとに身近な話で……
いまはIT系を離れて製造卸売りの会社に入っていますが、一部の営業の求める理想と現場とが全くかみ合わない。
とにかく手広く新しいことやりたい人間が実務上継続不可能な新製品プロジェクトをぶちあげて製造現場に無理難題をおしつけてくる。
現状で出来るわけがないといっても「そこをなんとかするのがおまえの仕事だ」と言い出すし、プライベートな時間なんて捨てて仕事しろと言いきる。
試作してGOサインが出て製品作成したらその後で仕様追加されて「そんな仕様だとは全く聞いてない」といったら「そんなことは常識で判断しろ」と言い出す。
もうね、アホかと。馬鹿かと。
ψアレゲな事を真面目にやることこそアレゲだと思う。
Re:結局金額が書かれた契約書が有効かどうかの問題 (スコア:2)
一般に聞いてみたいけど
要件定義も終わってないのに営業が金額の約束してしまうのが普通なの？
なぜ作るものが決まってないのに金額が決まる？
# もちろん営業が細部のことなんか考えずにあれもできるこれもできるとか
# 言っちゃうのはよくあることだけどさ
Re:結局金額が書かれた契約書が有効かどうかの問題 (スコア:1)
これが最後の糞契約とも思えない。
そういう糞営業との契約を望む顧客がいる限り、
いずれ第二、第三のIBM-スルガ銀事件は起きるだろう。
Re: (スコア:0)
比較的初期バージョンの釈由美子がでてくるのなら上等
Re: (スコア:0)
なにがなんでも仕事を取って来いといわれりゃ、それが営業担当者にとっての要件なんだから、
営業担当者にどういう要件が与えられたのかも分からずに、営業担当者の無能ってことにするのは不公平でしょ。
どの能力の営業をどの顧客にぶつけるのか、どの程度誇張営業をどの顧客にぶつけるのかは、経営者が判断すること
Re: (スコア:0)
だから担当者じゃなくて営業がクソだって言ってるんだろ
Re:結局金額が書かれた契約書が有効かどうかの問題 (スコア:3, 参考になる)
元ACは「営業(人間)をどう始末したって無駄で、取って来た案件の金額しか評価しない営業に対する評価体系がクソ、ひるがえってその評価体系を作った経営者がクソ」って言ってるんでしょ。
近場でも、「単年度5億の契約を持ってくるほうが継続10年間x1億/年の契約を持ってくるより評価される」という問題があってだな、ちっとも経営が安定しないぜべいべーという愚痴を聞いたばかりなので、なんとなくわからなくもない。
＞判決理由は明らかになっていない (スコア:5, すばらしい洞察)
ここが明らかになってれば、裁判所の判断はおかしい or いや妥当だ、とか言えるんだけど、これだと何とも言えませんな。後で公開されるんでしょうかこれ？高裁が終わってから？
まあ、IBMの申し立てで非公開ってことは、IBM側のミスを咎めるようなことが書かれているんでしょうが。
SIの未来に響く重要な判決だと受け取ってる人もいるらしいので、IBMには業界全体のために非公開申請を取り下げてもらいたいものです。
Re:＞判決理由は明らかになっていない (スコア:1)
非公開申請したのは、IBMがいかにろくでもないことをしたか明らかになって、現在進行中の案件に影響があるからなんだよ。いわば、自らの非を自分で認めた格好になっている。89億7080万円でシステム受注しといて、60億円払っても、まだ案件整理をやってたんじゃ、最終的に最初の発注契約の総額を上回ることがわかった時点で、客が起こるのは当然だろうね。おまけに受注時に10約束していた機能が5しか実現できないから、縮小して、これでよろしくなんてやられたら、怒らない顧客の方が異常だろう。
もっとも、本拠地と同じ市内に工場を持つ富士通や沖電気の地元に住んでいるエンジニアと、東京から毎回出張してくるIBMのエンジニアとを同じ扱いをされたら、たまらないのは事実だろう。例えば、帰りの電車の都合で21時にはさっさと帰ろうとするエンジニアが、多少無理を言えば、23~24時まで一緒にいてくれる地元在住のエンジニアと同じ扱いをされれば、不平不満もたまるだろう。
Re:＞判決理由は明らかになっていない (スコア:4, 興味深い)
富士通の下請けでスルガ銀行の仕事をしたことがあるが、IBMの担当者の態度がひどく悪かったようですよ。飲み会で愚痴をよく聞きました。
曰く、打ち合わせが終わってないのに、21時には問題点を曖昧なままにして、IBMのエンジニアのやつらは、勝手に帰る。後日、曖昧なままにしたところを、勝手に自分の都合で決めつけて、解決ずみにする。発注側がそうじゃないだろう、どうしてそうなったのか説明したうえで、問題点を解決してから帰れと言えば、IBMの担当者は監禁されて帰れなくなっただの、恫喝されただの、と騒ぐだけで、顧客の要望を反映しない。
まあ、あんたらは地元の人間だし、やることやってから帰れって、暗に言われただけの話なんですけどね。
昨日までいました (スコア:5, おもしろおかしい)
昨日まで○○○の仕切るプロジェクトで働いていました。すべて最近の話です。
バージョン管理ソフトは去年の年末に最新の管理ソフトであるCVSを導入しました。SVN, GITなんてよくわからないものは使いません。
ちなみにCVSだけでは上手く管理できないため、Excelでの管理もしています。
ソースを編集する際には、Excelの編集するjavaファイルの行全てに名前と日付を入れる完璧な運用です。
もちろん忘れる人もいますが、「今後、徹底します」と気合いと根性があれば大丈夫です。
Javaですが、数字もbooleanも全部Stringであつかっています。"true"と"TRUE"の違いでバグ発生などもよくありました。
計算の度にいちいちlongに変換しています。たまにintに変換する人がいるので桁溢れでバグ発生です。
ジェネリックスが使われたり使われなかったりするため、そこら中がキャストの嵐です。
PHPやRubyなんて動的型付けの言語なんて業務では怖くて使えませんね、まったく。Java最高です。
仕様書は詳細で完璧です。
日本語でプログラミングされているかのようで、「繰返し」という言葉を「for」に直せばいいぐらい詳細です。
データを保持するオブジェクトのプロパティもあまさず記載し、SQLも日本語に変換して仕様書に載せています。
Excel仕様書を見れば処理を完全に追うことができます。
ただ詳細に処理の流れは書いていますが、それが何をするクラスなのかの仕様があまり書かれていないので、
ソースを追うのと大差がないためか、読む人はあまりいません。書いた人に尋ねるのが一番早いです。
伝言ゲームになりますが、最高のチームでコミュニケーション能力があれば仕様書なんていらないのです。
「あいつ、殺す」「なんでこんなことしてんだよ」なんて言葉は聞こえません。聞きません。
もちろんコメントもわかりやすく詳細です。マジックナンバーをハードコーディングなんて初心者みたいなことはしないので、
わかりやすくするためにコメントに定数の中身まで記載します。定数の名前に定数の中身のマジックナンバーを付けるという裏技もありです。
画面単体でバグの存在が判明しているのに、スケジュールに間に合わせるために結合テストをしています。
「なんで結合テストが進んでいないのか？」と問われました。
答えは、バグの直ったソースがあがってくるのが、その質問の1時間後だからです。ちなみに作業の〆切は昨日です。
それでもスケジュール管理表の結合テストは進みます。
スケジュールが最優先です。スケジュールに間に合わせるためには、バグという名の隙間を縫うような職人技でテストを進めています。
そのため爆弾がどんどんふくらんで、直すのがどんどん大変になっていっていますが、スケジュールは守ります。
来月からスケジュール通りにユーザー検証らしいです。
関係のない話をいっぱいしましたが日本IBMはまったく悪くないと思います。日本IBMのプロジェクトは最高です。
# 爆弾がはれつする前に転職が成功してよかったわ
［続報］スルガ銀-IBM裁判、日本IBMが控訴 (スコア:5, 参考になる)
［続報］スルガ銀-IBM裁判、日本IBMが控訴 [nikkeibp.co.jp]
と予定通り控訴したそうで、戦いはまだまだ続くようです。あと、本件をずっと追ってるITProを始め、詳しそうな人による分析やら解析やらも結構増えてきました。
ITPro - “スルガ銀－IBM裁判”の行方 [nikkeibp.co.jp]
Togetter - @tsuchie88さんによるスルガ銀行ｖｓ日本IBM裁判のまとめ [togetter.com]
All About プロファイル - スルガ銀行と日本IBMの裁判について [allabout.co.jp]
カレーなる辛口Javaな転職日記 - 「スルガ銀-IBM裁判、日本IBMに74億円超の賠償命令」 [hatena.ne.jp]
立ち位置によって見方は違いますが、今のところネットではどちらかというと近い立場の人が多いIBM寄りの発言が多そうですね？
Re:［続報］スルガ銀-IBM裁判、日本IBMが控訴 (スコア:3)
特に転職日記さんの記事が面白い。
とはいえ、書いてある経緯は、本当にどこの現場でも起きてる当たり前の状況だなと。
これ、スルガ銀行と日本IBMという図式で書いてあるけど、元請けの日本IBMって、いわゆる旗振り役であって、実働部隊（現場に常駐してた連中）は蚊帳の外だよなぁと（苦笑）
完全に主従の関係は珍しいってあるけど、二次請け以降はどこ行っても、従であることを求められるし、現場入りした時点ではやる事（下手すると組めるかどうかも分からない仕様まで決定してたりするｗ）も全部決まってるか、あるいは責任の大半を丸投げされてて途方に暮れるってのが実際の所じゃないのかな？
なんとなくだけど、日本IBM自体は開発どころか、要件定義にすらタッチしてなかったんじゃないのか？という疑いが湧くのですが？
（実例は過去に経験あるので、そんな事ないとは言い切れませんｗｗｗ）
通知の設定いじったから、ACだとコメントされても気づかない事が多いよ。あしからずｗ
Re:［続報］スルガ銀-IBM裁判、日本IBMが控訴 (スコア:1)
部下のミスに損害賠償を求める会社っぽく見えてしまう。
IT業界の常識は世間の非常識 (スコア:2)
銀行に限らずどんな業種でも本来、自分のとこで使う
IT システムの構築を担当する業者への扱いは、
普通の工場の工作機械を製造し納入する業者への
扱いと同じになるのが当たり前だ。
IBM のいってる「対等な関係」って、その位の意味なのか
どうなのか気になるな。
それ以外の関係がありえると思ってるのであれば
まぁ、不思議な奴らだなとしか思えないな。
特注品は共同成果物だから (スコア:3, 興味深い)
ユーザに合わせたシステムって、そのユーザ固有の特注品だから、
発注元とベンダで双方でリスクを取りましょうっていうのが
「対等な関係」ってことじゃないですか?
でも銀行さんはベンダを業者としかみないんですよね。ただ、
某赤い銀行さんは「業者の不始末は発注元の不始末、だから
俺らが教育してやる!」という形で発注元がリスクをとってくれるから、
対等な関係でなくてもうまく開発が纏まるんですよね。某青い銀行さんの
ように、「俺らはお客様だ。うまくいかないのはベンダが悪い」というように
一方的な立場だと、開発は破たんするんですよね。この場合、ベンダは
泣き寝入りするか、逃げ出すか。今回のスルガ-IBMは青い銀行さんのケースに
似ていますね。
Re:特注品は共同成果物だから (スコア:2, 興味深い)
> でも銀行さんはベンダを業者としかみないんですよね。
これは全く当たり前の話だ。
> 「業者の不始末は発注元の不始末、だから俺らが教育してやる!」
こんなふうに客が思ってくれるという前提が間違ってる。
勿論、痛い客というのはいる。銀行じゃなくたってそこらへんの
八百屋や魚屋にだって来る。そういう客は相手にしなけりゃ
それでいいんだ。
「この客はあれな感じだ」と思うなら受注しなきゃいい。
どこの SIer からも相手にされなきゃそいつらだって
なんか考えるだろう。
なのに「取り敢えず受注してしまって後から寝技で
なんとかすりゃいい」と考える SIer が後を絶たないから
デスマーチもなくならないんだ。
Re:IT業界の常識は世間の非常識 (スコア:2)
> いやきょうび工作機械だってンなターンキー契約で引き渡して終わりって商売じゃないよ。
> 客は加工したい部品があって発注するんだから、要求性能詰めたりカスタマイズ施したり
> 調整したり場合によっては加工プログラム作るところまで込みの商談になるよ。
最初からそんなことは含めて話してるよ。
ってゆーか、どう読めば俺がターンキー契約の
こといっていると読めるんだ？
次のターゲットは (スコア:1)
TSOL、お前だ！ [srad.jp]
IBMが全面的に悪いとは思えない。経験的に。 (スコア:1)
要するに、客と営業と実働部隊の間で所謂ホウレンソウができてない
IBMに対して支払い命令が出たのは、
システム発注 → 期限までに完成しなかった → IBMが悪い
という単純な理由だと思うけど、それじゃIBMがかわいそうだ
＃そろそろ本気でウォーターフォールを何とかしないといけないと思う
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:4, すばらしい洞察)
言ってることの大筋には同意するけど、
ホウレンソウとかそういう言葉がそもそもダメなんだと思う。
報連相ってお題目を掲げていればなんか密なコミュニケーションしているイメージは持つけど
実際には何の価値もない情報の垂れ流しがほとんど。
大切なのはそういうコミュニケーションの「手段」の話じゃなくて
何をコミュニケーションすべきかっていう「対象」の話。
今回の件で言うと、客と営業で、何を共有できて何をできなかったか、どこに認識の不一致があったかとか
中身の話をすべきなんだけどね、こう言ってもなかなか理解してくれないんだ。
うちの会社の人間もよくこういうトラブル起こすんだけどさ、
上司部下ともに自分たちの何が悪いかわかってない。
だいたい「ちゃんとお客さんとホウレンソウできてたのか」「毎週必ず報告あげてましたよ」とか
そういう低いレベルで終わって良しとしている。
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:3, 参考になる)
日経のアカウントないと読めないけど「ホウレンソウとか言ってるから行動が戦略じゃなくて戦術・手段レベルになってる」という指摘
http://www.nikkei.com/access/article/g=96959996889DE1EAE5E1E3E5E4E2E3E... [nikkei.com]
あともうすこし古いけどこちらにも「欧米の考え方」的トーンで似たようなことが書かれている
http://d.hatena.ne.jp/favre21/20080827 [hatena.ne.jp]
ホウレンソウそのものがNGとまでは思わないが，○○至上主義とか一点に囚われるとダメということですかね
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:1)
実施は担当者の裁量でできるけど責任は上司にある
今回の問題は
それぞれが相手の立場を理解して話をすることができなくて、単なる要望の言い合いのようになったのだと思いますよ
幹部で話し合った結果がスルーされてるとかもひどい
問題の本質はコミュニケーションの破綻がどこで起こったかでしょう 悪い雰囲気作ってしまったヤツか話を巻き戻してまとめられなかったヤツか、そもそも意思疎通もできない連中から仕事受けてきたヤツか
銀行がどこまでニーズを明確にしていたかなんだろうけど、どうせ後々「役員がこう言うからこうしないと」とかのレベルの低い要求出していったんじゃないかと予想
どちらの会社も悪くて どちらの会社の社員も時間を無駄にして会社に損害を与てるのだから 逸失利益を請求するスルガの神経は理解に苦しみます
銀行以外でも嫌がるようなかなりキツいローンでも実行するような銀行だからどうせ金額ふっかけてる。
まだまだ金額吊り上げていくんでしょうね。
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:2)
いや全くその通りで、何をどうしたいのか、そのために何が必要なのか、とかの
具体的なところが曖昧なまま納期が迫ってくるのがデスマーチなんだよね
確かに現場で「ホウレンソウ」とか言ってるオジサンは駄目だと思うｗ
＃SE上がりの管理者にマネージメントを理解しろとか無茶振りだとは思うけどね
経験的にIBMがチョンボをやらかしたと思う (スコア:1)
柔軟なスケジュール対応はどんなプロジェクトにも必要だけど
むしろ銀行のような社会的な基幹系は完璧なウォーターフォールにすべき
中途半端に色気を出して仕様変更（未策定含め）出す/受け入れるから問題なだけ
プロジェクトが計画通りに行かないわけではなく、計画がプロジェクトに合ってない
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:1)
報連相がどうとかの問題じゃないと思うな。
日本のクソなシステム開発がいつものように失敗例を生み出しただけでしょ。
要件定義は発注側の責任でやらないとならないってのが国際標準だってのは
結構前から言われているけど、未だ何も変わってないよね。
CIOってのが何で必要なのか理解出来ない馬鹿経営者と、
そいつらを説教できないSIerしかいない内は駄目なんでしょう。
そんなことをしているうちに、日本はどんどん沈没してくのでしょうか。
ま、自分もそんなSIerの末端な訳ですが。
Re: (スコア:0)
セールスフォースに頼めば、納期８分の１、開発費４分の１で出来た気がする
#日本ITのベンダーは高すぎる
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:2)
ホントに依頼した事ありますか？
下手すると、LotusNotes以上に制限ありまくりで、何も出来ないという話すら聞いたことありますよ？
通知の設定いじったから、ACだとコメントされても気づかない事が多いよ。あしからずｗ
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:1)
>欧米では、経営スタイルをシステムにあわせるんじゃないですか？
よく勘違いしている人がいますがそれは極論過ぎる間違いです。
欧米でも経営スタイルをシステムに合わせることはしません。
だってそれしちゃったら他社と同じになるだけでしょ？
欧米でも、守るところはきっちり守り内製しますし、
攻めるところもきっちり攻めて内製します。
ちなみにこれをやる開発者はたいていが正社員で雇用された人間です。
その上で、「守るところじゃないところ」「攻めるところじゃないところ」を
出来合いのシステムに合わせるわけです。
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:1)
日本のシステム発注は「細部」までシステムをあわせるじゃない
「紙の帳票とフォーマットを完全に一致させる」とか「電子帳票を自動印刷」するとか
狂気の要望に満ち溢れてるし
自分の経験だと「システム化」が「作業効率の向上」ではなくて「パソコンをつかうようにしただけ」って
要求があまりにも多すぎる気がするし、SEが業務効率の向上となるワークフローを提示しても、
多くの場合が「管理職」レベルの協議になった段階で「紙の業務」と一致している方に倒れる案件が多すぎる
その実態を考えれば日本は「紙の電子化がシステム化」ってパターンが支配的だし
それに比べれば欧米は「業務の効率を考えたシステム化」を行っていると思うよ
紙の帳票が重視される日本の企業って担当者にハンコ押させるもんね
管理職が管理してれば「ハンコ」って担当者の作業担保は不要だとおもうんだけど
担当者が紙にハンコを押す事を「エビデンス」と呼ぶアホさと非効率を是正出来ないと
業務の効率化もシステム化も無理だと思うんだな
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:2)
紙の帳票は慣例として、それがそこにあるだけで証拠になることが実績によって証明されたもんだけれど、ソフト屋はどうやって保証してくれるだろうか？弁護士や税理士に頼んでそのコストを見積もらせるより、紙に同じように出力する仕様をソフト屋に見積もらせた方が安いなら、仕方ないだろう。
電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律施行規則
http://law.e-gov.go.jp/htmldata/H10/H10F03401000043.html [e-gov.go.jp]
同様のものが、税務関連法だけでも、消費税法、所得税法、地方税法etc...と、それぞれの施行規則などによって規定されていて、さらに事業別にいくつも書面の保管方法についての規定がある。それらは、毎年更新される可能性がある。
仮に電子データと、あなたが考える合理的なインタフェースを用意したとして、税務調査のときに、税務署員にレクチャーできるか？そのとき自社が雇っている立ち会いの税理士に理解させて、対等な立場で証拠の正当性を説明させられるか？そんなことしらねって言っても現実には、そういうことが起こるし、そのときたまたまやってきた担当者を理解させることに失敗すれば、場合によっては訴訟を行わないと正当性を説得できないかもしれない。そのときには、正当性を実証するために人月コストが発生することになるだろうし、業務にも影響がある。
万が一にも正当性を証明することに失敗すれば、７年の税法上の時効に遡って課税されてしまうかもしれないし、２倍とか３倍の重加算なんてされれば、年間売り上げを超えるような追徴が発生するかもしれない。それをソフト屋が補償してくれるわけでではないよね。
そんなリスクをちゃんと予想して、必要なシステム要件をだしてくれて、しかも安かったら、そりゃぁお客さんは大喜びですよ。
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:2)
>同じ時間(お金)で品質の高いシステムが提供できるわけです
客先が業務への影響範囲を検証するなら、当然客先の業務リソースが使われるんだから、「同じ金を払っている」という話にはなりません。
客先負担を前提として、システムを提案するっていうなら、それを含めて最初に査定して契約しないといけないでしょう。
仕事がすでにある、予算がきまってるという前提で、そこから相談して決める話ではないです。
Re:IBMが全面的に悪いとは思えない。経験的に。 (スコア:2)
あなたの言っていることは、300円でカツ丼を提供するという約束をしながら、300円で足りるように卵かタマネギかかつのどれを選ぶか考えましょうなんて言い始めるのと一緒だよ？
客からしたら営業もSEも関係なく、おたくの会社と取引してるんだよね、いくら払ったらどれだけのものを実現するっていう契約をしているわけだよね。で、完成させることが債務になってるわけだよ
予算が決まっているなんてのはあなたの会社の都合であって、お客さんにとっては関係のない話でしょう？
銀行なんかと仕事するからだよ。 (スコア:1)
IBMも結構非道いが、銀行はその上を行くからな。
出入り業者は基本として奴隷として扱う。
なにせ、奴隷として扱っていることを上司にアピールすると、昇進するんだぜ。
スルガシステム (スコア:1)
スルガ 銀行とIBMの システム 開発なら、デスマーッチってもしかたない [wikipedia.org]と思ってしまった…
このリンクを貼らなければいけない気がした (スコア:0)
tree swing pictures
http://www.businessballs.com/treeswing.htm [businessballs.com]
Re:このリンクを貼らなければいけない気がした (スコア:1)
最近はここまで拡張されているらしい。
http://www.projectcartoon.com/ [projectcartoon.com]
あなたがたはこういいたいのですね (スコア:0)
「いつも俺たち（プログラマー/エンジニア）は悪くない。悪いのは営業かマネージャーか顧客だ」
Re:あなたがたはこういいたいのですね (スコア:1)
半ばその通りかな。
技術的に開発に失敗したとかなら別だけど、今回はそういう話ではない。
現場技術者は最高責任者ではない。
プロジェクト全体に決定権を持つのはマネージャーや顧客。
糞仕事を取ってくる部分に関してだけなら営業も責任者になり得る。
しかし技術の側は、そういう意味での責任を持たされることは絶対にない。
Re:あなたがたはこういいたいのですね (スコア:1)
技術者がそれならできるといったので営業がとってきて結果出来なかったというなら技術者が悪いが
それ以外なら営業かマネージャーだわな。
無理と言ってるのい取ってきたり、そもそも何も言ってないのに勝手に取ってきてやれとか言い出すバカが多くて困る。
技術者だってピンキリなんだから、それにあった仕事を取ってくるのが営業の役割。
どこもかしこも天才技術者ばかりじゃないんだからな。
話を聞いた後持ち帰って担当者と相談してみます、というのができる営業。
その場で勝手に決めるのがカス営業。
その営業自体が技術者も兼任していて、自社の技術力や他の技術者の力量全てを把握している、というなら別だけどな。
Re: (スコア:0)
運用で十分カバーできるものも技術技術とか言ってやれっていうのも悪いと思うね。
納期を守れるように顧客にちゃんと説明できないでホイホイ顧客の言うことを聞けばいいという
営業が多いような気がする。
費用対効果というか優先順位とかそういうのを考えられる営業をおいたら良いと思うね。
後、営業の評価だけど、売り上げじゃなく利益で評価するようにしたらいいと思うんだけど、
なんでさっさとやらないのか理解できない。
Re: (スコア:0)
つまり「自分に営業させろ」ってことですね。
Re: (スコア:0)
もちろん「でもできない」だけどさ。
＃他人への要求は厳しく自分への要求は甘い。
＃特にこの業界はその傾向が著しい。
Re: (スコア:0)
プログラマ/エンジニアが悪いことが原因でプロジェクトが失敗するのって、そもそもからして難しい気がするんだけど。
Re:あなたがたはこういいたいのですね (スコア:1)
技術的な問題で大混乱したことありましたよ。
顧客DBをSIerさんが新式に移し替える時、電話番号をコンバートしたら頭の0が全部欠け
てて検索しても使い物にならなかった。
聞いたら「データを一度Excelに落として新しい方に流しました」との事。
電話番号が数値扱いになったら、そりゃ頭の0なくなりますわな。
単純に、Excelの初歩の初歩の技術的仕様(デフォルトが数値扱いのセルで、明示的に文字
扱いにしておくべき)をSEがうっかり忘れてたのか、疲れて眠かったのか何なのか分かりません
けどね。
# テストデータでコンバートしてみなかったのかな。
# ちなみに2000万のプロジェクトで、あまりに困ったから余所様に出したら桁が一個減った。
はじける加齢の香り！orz