ソーシャルメディアで流れていた記事を読んだ話。5月から連載されていたようだけど気づいていなかった。ソフトウェア開発における訴訟解説の話である。別に自分はこういった訴訟沙汰に関わったことはないのだけれど、いろいろと勉強になる。
- 「ジェイコム株誤発注事件」に見るシステムの瑕疵判断とその対応（前編）：「訴えてやる！」の前に読む IT訴訟 徹底解説（1）（1/2 ページ） - ＠IT
- 「ジェイコム株誤発注事件」に見るシステムの瑕疵判断とその対応（後編）：「訴えてやる！」の前に読む IT訴訟 徹底解説（2）（1/3 ページ） - ＠IT
- ベンダーはどこまでプロジェクト管理義務を負うべきか：「訴えてやる！」の前に読む IT訴訟 徹底解説（3）（1/2 ページ） - ＠IT
- 検収後に発覚した不具合の補修責任はどこまであるのか（前編）：「訴えてやる！」の前に読む IT訴訟 徹底解説（4）（1/2 ページ） - ＠IT
「ジェイコム株誤発注事件」について
上記記事の本論ではないのだけれども、バグの仕組みの説明がちょっと分かりにくい。調べてみたらWikipediaの説明が詳しかった。
開発ベンダーは債務不履行を問われなかったがサービサーは問われたという点、および提供機能の重大性に応じて問われる責任も変わるというところがポイントという理解。リスクベースドテストなど、もっと真面目に考えなけばいけないかもしれない。
つまり、コンピューターシステムによるサービスを提供する者には、システムの不具合を前提とし、人間系の処理も含めた回避策をとるという、「人的なプロセスも含めたシステム運用責任」があるということだ。コンピューターシステムは、結局のところ道具にすぎない。大切なのは、「約束したサービスを問題なく提供し続けること」であり、道具自体が技術水準を満たすか否かは問題ではないとする、至極当然の判断といえる。
難い。難しすぎる。システムに不備があるという前提での運用訓練まで行わなければいけないということなのだろうか。
「プロジェクト管理義務」について
「要件の凍結についてベンダーがより積極的に関わり、ユーザーを導くこと」「追加・変更された要件について、追加費用やスケジュール見直し、場合によってはその撤回をユーザーに求めること」もベンダーの義務である、という話。あー、お腹痛い。
もちろん異論はないし、当然やるべきことではある。むしろ訴訟のことをよく勉強しておいて「こんなことは言いたくないけれど、プロフェッショナルとしてあえて言います」と訴訟の中身を引き合いにして喋れるようになっておきたい。
検収後に発覚した不具合の補修責任
現状での最新記事。前後編のうちまだ前編しか公開されていない。
「システムを完成させても、指摘された不具合をきちんと補修しなければ、たとえ検収を受けていたとしても契約解除の原因となる」
これは納得、というか「検収書」なるものは所詮紙切れにしかすぎず、やることはやらないといけない、ということだ。
元ネタの訴訟を見ると、「不具合を認めると大変なことになるから、一切認めない」という初動が問題あったように見える。どちらかというと「費用措置は別途調整するが、まずは止血する」という動きをとればよいんじゃないかと思う。
マゾではないのだけれども、こういった記事に目を通して胸を痛めることも時には必要じゃないだろうか。ソウルジェムが濁ろうとも。
