1: ノチラ ★ 2017/07/01(土) 09:18:17.07 _USER
93
ここで1つ、ＩＴにまつわる裁判をご覧ください。

まずは、この争いの経緯から見ていきましょう。
--------------------
（平成16年3月10日　東京地方裁判所判決 より）

原告の発注者と被告のベンダーは、基幹業務システムの開発委託契約を締結した。

しかし、スケジュールが遅延し、期限を数か月過ぎてもシステムは完成せず、発注者は契約を解除。支払済の代金約2億5000万円の返却と、損害賠償3億4000万円の支払いを求めて訴訟を提起した。

しかし、訴えられたベンダーは、開発遅延の原因は発注者による機能の追加・変更、その他の過剰な要求と、発注者が回答すべき懸案事項についての意思決定の遅れによるものだとして、逆に、ベンダーから発注者に対して、委任契約解除における報酬と損害賠償として約4億6000万円の支払いを求めて反訴を提起した。
--------------------

この裁判の判決は後で紹介しますが、これはＩＴ訴訟の中では非常に有名な裁判で、発注者に起因するリスクによって、プロジェクトが失敗した典型例です。

この裁判のように、要件変更や意思決定の遅延などのほかにも、発注者側に起因するリスクというのは、さまざまな形があります。

・プロジェクトの中心となって活躍していた発注者側の担当者が、人事異動で突然いなくなった
・自社の業務プロセスをベンダーに理解させなければならない発注者自身が、実は自社の業務のことをよく知らなかった
・自分が使うシステムなのに、なぜかエンドユーザーとなる社員が協力してくれなかった

そうした理由で、プロジェクトが頓挫することは多いのです。

こうした「発注者の責任によるプロジェクト崩壊」を防ぐためには、どうしたら良いのでしょうか。

「やっぱり、発注者は決めるべき時期までに要件を固めるべきなんだ。一度要件が決まったら、後からいじってはいけないし、意思決定も遅れないようにしなきゃいけない」

初めてシステムを外注する真面目な発注者の方なら、そんなふうに考えるかもしれません。

もちろん、そうできれば一番良いのですが、実際のプロジェクトは、そう教科書通りにはいきません。ＩＴシステムプロジェクトにおいて、要件変更や意思決定の遅延は日常茶飯事であり、そうしたことを絶対に起こさないように、などと考えていたら、ＩＴシステムの導入は事実上不可能であるのが実態です。
中略

さて、先ほどの裁判の話に戻ります。判決文の続きを見てみましょう。

実は、裁判所はベンダー側の責任を認め、ベンダーに多額の損害賠償の支払いを命じています。

簡単に言えば、こういうことです。

「発注者がわがままを言うなら、ベンダーはそれをしっかり断らなければならない」

「どうしても要件を変更せざるを得ないようなことがあるなら、発注者と一緒に検討して、次善の策を考える姿勢が必要だ」

「発注者がプロジェクトを乱すなら、ＩＴの専門家であるベンダーは、それを“リスク”として管理し、発注者が決めることを決めたり、プロジェクトを壊すほどの要件変更をしたりしないように仕向ける義務がある」

発注者が原因となるようなリスクも、ベンダーが管理し、解決に導かなければならないということです。これを「ベンダーのプロジェクト管理義務」と言ったりします。

「なんだ。じゃあ、ベンダーが悪いってことか。発注者に責任はないわけでしょ」

そう思った方は、もう少し、踏み込んで考えてみてください。

ベンダーが、発注者のリスクも含めて管理しなければならないということは、発注者も相当の協力をしなければならないということを意味しています。

「この期日までに要件を決めてくれないなら、この機能はあきらめてくれ」とか、「これは当初の想定にない機能だから、追加の費用と納期の延伸を認めてくれ」とか、そんなベンダーの悲鳴にきちんと耳を傾け、そのまま受け入れないまでも、ちゃんと相談に乗ることが必要です。

そうしたこともせずに「なんとかしてよ。プロでしょ？」などとベンダに突き返すような態度をとると、今度は、逆に「発注者の協力義務違反」に問われることにもなりかねません。

ＩＴ導入は、発注者とベンダーがお互いにわがままを言い合いながら、話し合い、双方が妥協をしてなんとか成功させていくものなのです。
http://diamond.jp/articles/-/133844
引用元: http://anago.2ch.sc/test/read.cgi/bizplus/1498868297/


2: 名刺は切らしておりまして 2017/07/01(土) 09:24:06.72
何のために口が付いてるんだお前はｗｗｗ

できないならデキマセンだろうが
発注者とコミュ取れない時点で自己責任だ

3: 名刺は切らしておりまして 2017/07/01(土) 09:32:39.20
要件定義がめちゃめちゃだったてことか？

25: 名刺は切らしておりまして 2017/07/01(土) 10:52:49.14
>>3
こんな事がやりたいと漠然としたイメージしか持ってないから
実際に動いてるのを見るとこんなはずじゃと仕様が変わる

5: 名刺は切らしておりまして 2017/07/01(土) 09:43:25.69
仕様決まってないのに
立場使って請負単価決めて契約ゴリ押ししてくるんだけど

13: 名刺は切らしておりまして 2017/07/01(土) 10:12:47.47
>>5
そんなアホは切れよw
技術力があるSIerなら、他にいくらでも仕事はあるだろ

62: 名刺は切らしておりまして 2017/07/01(土) 13:27:31.15
>>5
契約前に作業入るのが日本企業の悪いところだね
外資だと「オーダーくれないと作業着手できないから早くしてくれ」と
せっついてくる

6: 名刺は切らしておりまして 2017/07/01(土) 09:47:19.91
まじでエンジニアと話すの頭おかしくなる

98: 名刺は切らしておりまして 2017/07/01(土) 16:42:40.96
>>6
こちとら丁寧に説明しているのに、思考停止してバケツリレーできない人間ですね、わかります。

8: 名刺は切らしておりまして 2017/07/01(土) 09:55:30.02
発注者とのやりとりは全部AIにやらせたいくらいだよな

発注者「ここは適当にやっといて」
AI「適当ではわかりません。具体的な内容を提示してください」

9: 名刺は切らしておりまして 2017/07/01(土) 10:01:45.64
ITシステムなんて受注する方が悪い

10: 名刺は切らしておりまして 2017/07/01(土) 10:07:05.73
すべてオールオーケーしてちゃんと定時で帰る
それに文句を言われたら辞める

14: 名刺は切らしておりまして 2017/07/01(土) 10:20:16.77
>>1
追加変更を受けた時点でスケジュールと費用追加を言わないまま進めるからこうなる
その時点で言えば中止してもそこまでの分は貰えるのに

15: 名刺は切らしておりまして 2017/07/01(土) 10:22:44.68
追加仕様や仕様変更はカネと時間がかかると
発注者が理解しててくれればそうそう崩壊しないけどなー
家の建築と一緒で設計図で来たらなるべくいじらないのが一番良い

「ちょっと修正するだけでしょ？」とか考える人が一番厄介

22: 名刺は切らしておりまして 2017/07/01(土) 10:45:14.46
>>15
「それくらい簡単でしょ」は、
何もかもぶち壊す覚悟で言ってほしいとは常々思うよなw。

21: 名刺は切らしておりまして 2017/07/01(土) 10:43:46.27
弁護士っていちばんの無能

28: 名刺は切らしておりまして 2017/07/01(土) 11:01:10.64
先生「みなさーん、今日のプログラミングの授業は
デスマーチの練習でーす。ちゃんと徹夜してきましたかー？」

30: 名刺は切らしておりまして 2017/07/01(土) 11:10:52.08
プログラムに限らず、Web、デザイン含めて、営業の質の悪さ次第だな。

34: 名刺は切らしておりまして 2017/07/01(土) 11:15:59.70
要件コロコロ変えるやついるよな。
いったいどうしたいのか本人も理解できていないんだろ。

37: 名刺は切らしておりまして 2017/07/01(土) 11:22:35.82
糞みたいなクライアントには、糞みたいなプログラマグループつけます。
上級プログラマの時間の無駄なんで。効率的にするには以下の方法がベスト


締め切り1年前作り始める→揉める→揉める→仕様変更→揉める→揉める→締め切り1.5か月前

出来上がった仕様をもとに上級プログラマが1週間で完成

39: 名刺は切らしておりまして 2017/07/01(土) 11:33:35.64
一時期アジャイルだのが持て囃されたけど、結局定着しなかったな
日本の商習慣には合ってなかったのかな?

45: 名刺は切らしておりまして 2017/07/01(土) 11:49:44.72
>>39
日本でやると永久に収束しないので。

47: 名刺は切らしておりまして 2017/07/01(土) 11:51:50.16
>>39
準委任契約でなら結構ある

41: 名刺は切らしておりまして 2017/07/01(土) 11:41:33.54
SEはアスペ

44: 名刺は切らしておりまして 2017/07/01(土) 11:47:56.76
そりゃ都内の経済構造変えなきゃ無理だわ
都内そのものが多重下請け構造になってんのに

規制産業取り除かなきゃ、こんなもん個人個人の対応で変わるわけがない

49: 名刺は切らしておりまして 2017/07/01(土) 12:04:03.98
よろしく俺にチューニングｗ

56: 名刺は切らしておりまして 2017/07/01(土) 12:27:36.14
要求定義をユーザーにさせなかったベンダーの罪
自分達が困る事ならちゃんとやれ

63: 名刺は切らしておりまして 2017/07/01(土) 13:29:01.92
結局、発注側にとって実はいらないものだったってことなんだよな

66: 名刺は切らしておりまして 2017/07/01(土) 13:59:51.75
出来ない奴に限ってえらそう

74: 名刺は切らしておりまして 2017/07/01(土) 14:34:15.24
こういった話は G. M. ワインバーグの著作にすでに沢山書かれているよ。
特に「オレンジ・ジューステスト」は有名。

80: 名刺は切らしておりまして 2017/07/01(土) 15:09:47.11
仕様打合せで絶対ＮＯというなと技術部長から担当者は事前に言われる
あとで問題になるとなぜＮＯと言わなかったのかと技術部長は担当者に言う

82: 名刺は切らしておりまして 2017/07/01(土) 15:24:11.33
日本には向いてないんだからもうやめろよこんな業界

88: 名刺は切らしておりまして 2017/07/01(土) 15:49:54.04
顧客、元請け、孫請け、ひ孫請けと会社が違うから問題が起こる。

91: 名刺は切らしておりまして 2017/07/01(土) 16:02:47.51
断ろうにも営業が勝手におkしてくるので
エンジニアが聞いた時は終わってるがなw

95: 名刺は切らしておりまして 2017/07/01(土) 16:25:15.86
今日も悲惨な日本のIT業界

100: 名刺は切らしておりまして 2017/07/01(土) 16:49:49.66
エンジニア
下請けや派遣に｢そこをなんとか｣で下手で
最後は｢後はよろしく｣

スポンサード リンク