ベンダーよ、シェルパの屍を越えていけ 〜　細川義洋×山本一郎「なぜ、システム開発は必ずモメるのか？」：Developers Summit 2014 リポート（2/2 ページ）

細川義洋さん
東京地方裁判所 民事調停委員（IT事件担当） 兼IT専門委員
IT企業勤務を経て、2007年IT事件担当の民事調停委員に着任。現在に至るまで数多くのIT紛争事件の解決に寄与する。現在、＠IT自分戦略研究所で「美人弁護士 有栖川塔子のIT事件簿」を連載中。

著書：『なぜ、システム開発は必ずモメるのか？』（日本実業出版社）
ブログ：IT紛争のあれこれ（ITmedia オルタナティブブログ）

　「かつて西洋の登山家たちは、現地のシェルパを下に見る傾向があった。たとえ今、晴天でも、風の匂いや雲の流れで、シェルパには天候の変化を予測できる。そのときに彼らは登山の中止を申し出るのだが、登山家たちには『ここまで来るのに幾ら掛かってると思ってるんだ、行け！』と、聞き入れてもらえなかった。（山本氏「いいですねー、デスマーチ待ったなしですねー」）そして無理をしたシェルパたちが災難に巻き込まれ、登山家とともに死んでいった」（細川氏）。

　そういった不幸な事故の数々を経験して、シェルパたちは今、一定の権限を与えられるようになった。それと同じように「ベンダーもユーザーからリスペクトされ、権限を与えられるべきだ」と細川氏は訴える。「それを認知してもらうためにも、私はこの本を書きました」（細川氏）。

　「中断を勧告しなければならないタイミングはプロジェクトが遅延してるときがほとんどだ」というのが、山本氏の実感だ。クライアントからガンガン詰められている最中に「中断です」とはなかなか言えない。それができずに押し切られると、デスマーチが始まる。

　その問題については、「最初にプロジェクトの『開始基準』と『中断基準』を決めることが必要だ」と細川氏は説明する。ITのプロならではの知見を生かして、中止基準を数値化して契約書に盛り込むなど、ある程度、客観的に線引きができる中断基準や再開基準を、プロジェクトのスポンサーも含めて合意しておくのが美しいやり方だ。こじれてしまったら、外部のコンサルタントを投入するのも有効だ、というのが細川氏の考えだ。

　しかし山本氏は、「でもベンダーの上役は、システムだけを考えているのではなく、事業全体を想定しているため、システムに対する要望についてはシステム部門と違うことを考えるじゃないですか。最たる例が、損得勘定でやめるべきものをやめられない、とか。そうなると、中断基準に達していてもプロジェクトが続行してしまいますよねえ」と、またまた食い下がる。

　「その場合の判断をすべきは、ステアリングコミッティ※より上のレイヤーかもしれないですね。このプロジェクトで5000万円の赤字が出ても、このクライアントは太いから今後10年付き合えば元が取れるとか、メンバーが疲弊していたら変更が必要とか。ベンダーのお偉いさんは、中止基準が来たらそういった判断をしなくてはならないでしょう」（細川氏）。

　「しかしお偉いさんにはどうしても状況が分からないから、判断をしてもらうためには、現場の声を上に上げるべきなんです」（細川氏）。「そして上から『そこは死ぬ気でやれ』とか言われる。もう死んでるんですけどね」（山本氏）。「それでも根気強く、何度も何度もエスカレーションし続けるしかないんです。年配の人は頭が固くなっているので、刷り込みしなければならないんです」（細川氏）。

　…… （会場ため息）

※ステアリングコミッティ＝プロジェクト全体の利害調整を行い、意思決定を行う運営委員会。

どこまでが「重過失」か

　最後に紹介するキーワードは、「ベンダーはつらいよ」だ。話は「ジェイコム誤発注事件」を例に挙げて進められた。ご存じの方も多いと思うが、簡単に説明しよう―― ある証券会社の社員が、ジェイコム株を「1株61万円で売る」つもりで、間違えて「61万株を1円」とシステム端末に入力してしまった。間違いに気づいた社員はすぐに「取り消し」処理を行ったが、システムトラブルで、取り消しが実行されなかった。証券会社は数百億円の損失を出し、発注システムを提供した証券取引所を訴えた、という事件だ。

　細川氏の解説によると、原因はハッキリしている。このシステムは2本のプログラムが非同期で動いているもので、ある一定の条件が重なったときにだけ発生するバグがあった。そのバグが不幸にも誤発注時に初めて発生してしまった、というわけだ。これを裁判所はどう判断したのか。

　証券取引所のサービス契約には、損害発生時の責任の取り方がこのように書かれていた。「過失、もしくは重過失による損害を与えた場合以外は免責とする」と。問題になるのは、このバグが「重過失」当たるか否かだった。難しかったのは、重過失の参考とした判例が、昭和30年代のものだったということだ。IT技術は存在したが、一般企業がソフトウェアのバグで係争するようなことがなかった時代だ。

　システムのバグはあり得る。では事件を引き起こしたバグは瑕疵（かし）に当たるのか。

　バグは正常系か異常系か運用系か、システムの目的に照らして必要なものか、テストで発見できなかったのか。この事件の訴訟では、さまざまな視点から「そのバグを発見できなかったことが重過失か否か」が検討された。

　このときの裁判では「IT技術者であればおおむね知っていることは責任の範囲内、それを越えた想定外のことは範囲外」と判断され、「責任はベンダーにある。しかし免責」として、「責任割合はベンダー7対ユーザー3」の判決が下された※。

　本件では、ベンダーが圧倒的に不利というわけではない判決が出た。しかし特殊なケースだったにもかかわらず、その後この判例がいろいろなIT訴訟のベースとなっていることは問題であり、ITに関する法律の整備が必要だ、と2人はうなずきあった。

※ちなみに、トラブル時に「ベンダーがどれだけ一所懸命、対応したか」も判断に響くそうだ。「半年間も放置していた」などは心証を悪くするらしい。皆さん、ご注意を。

　セッションは、来場者への応援メッセージとともに締めくくられた。

　「ベンダーは、ユーザー企業と良い人間関係を構築していくことが大切です。そのためにも、ユーザーに信頼され、リスペクトされるようになって、今のシェルパのような位置を勝ち取ってください」（細川氏）。