事例に学ぶ：現場任せがシステム化失敗を引き起こす

先日、大手証券会社（以後客側）とこれも大手のシステム会社（以後受託側）の訴訟事件で、客側が最高裁判所への上告を取り下げていたこが報道されました。両者ともに認めていることなので、取り下げは事実なのでしょう。この事件、当初は客側が有利に裁判を進めていましたが、高裁で客側が逆転敗訴。判決によると、概要は以下のようなものでした。

　要件定義段階終了までは特に大きな問題は発生していなかった

　しかし、概要設計段階に入ってから客側の、しかも業務担当者X氏（ただ一人！）から機能変更の要望が相次いだ

　その追加要望は、設計・開発段階に入っても止まることがなかった

　受託側もたまらず、「仕様凍結」の依頼を出したが、それでも追加は止まることがなかった

　結局納期も追加費用も見えなくなり、開発プロジェクトは中止となった

　契約通りに開発が完了しなかったことを理由に客側は損害賠償請求に踏み切った

もっと細かく複雑な経緯をたどったことは事実だろうと思いますが、概ねこんな感じです。高裁は、客側がのべつまくなしに要求を出し続けたことがこの失敗の原因であると認定し、受託側勝訴の判断を下した訳です。

報道されている情報を見ただけでも、いくつか重要な失敗が見え隠れしますが、その中でも以下の２点がポイントだったのではないかと思います。

（１）客側の担当者X氏１名に業務が属人化しており、X氏が要求を出し続けることを止めることができなかった。（X氏の言うことを聞かざるを得ないぐらい属人化していたということでしょう）

（２）X氏が（担当者であるにせよ）客側の強大な権力を一人で持ってしまっている状況の中で受託側がそれを適切にコントロールできなかった。

高裁が逆転判決を下したのは、この（２）について受託側がきちんと事務的に対処し、「仕様凍結」を依頼し宣言していたことを重視し、契約上の責任を果たしていたと認定した結果だと思います。要するに、相対的に（１）の責任が重かったという考えでしょう。

私はこの高裁判決は１００％ではないにせよ、８割ぐらいの比率で（１）の責任が重いと思います。受託側はそれこそもっと早くプロジェクトの停止宣言をするべきだったと思いますが、おそらく受託契約書に縛られて思うに動けなかったのでしょう。しかし、結果的に大失敗に至ることは当時のプロジェクトマネージャーは知っていたはずです。それを放置した形になるので、受託側の責任がゼロとは決して言えません。しかし、受託側からの仕様凍結依頼にも関わらず、X氏が要求を出し続け、しかもそれを会社側が止めることができなかった、ということはもっと大きな責任があります。従って、この高裁判決は妥当なものと捉えるべきだと思います。

それにしても客側が敗訴する、というシステム開発についての怖さは、この訴訟事件によって如実に物語られています。規模の大小に関わらず、

要求を思いっきり吐き出して良い期間

新たな要求を出すことは我慢する期間

が存在します。例えば皆さんが注文住宅を建てる際に、

　図面や見積の段階ではいくらでも言いたい放題だが、いったんGOがかかったら、その後の変更は

　すべて設計変更とみなされて追加工期と予算がかかる

ことは認識していますよね？システム開発も注文住宅建設とほとんど同じ動きをしているにも関わらず、この「設計が終了しても要求を出し続ける」ということは多くの場合発生しているのです。これは、建設で言う「図面」に相当する「要件定義書」とか「設計仕様書」が素人の目には非常に難解だから、ということもありますし、今回の様にX氏が社内で強大な発言権（職制上の権力ではない）を持っている場合、「そんな資料など関係なく、とにかく私の言っている業務ができるようにしてくれないと困る」という考えだけで身勝手な言動をとることもあるからです。

今回の事件では、その実情が如実に現れており、（当事者の方々のご苦労は偲びますが）非常に貴重な知見を広く示してくれている好例であると思います。

「システム屋の言っていることは良くわからないから、とにかく要求を言い続けよう」とか「当社のあの人は全部知っているから彼に全てを任せればなんとかなるだろう」といった安直な考え方は、会社に大きな損失を与えかねないリスクでしかないのだ、ということを是非よく認識しておきたいですね。