不作為の罪：『なぜ、システム開発は必ずモメるのか？』

　システム開発というのは、トラブルの集積です。例外なく。大から小まで、パッケージ開発からマイグレーションまで、もめることのないプロジェクトは存在しません。

　みんなそれなりに頭もいいし、人間的にもまともな人たちが集まって仕事をしているはずなのに、「なんでこんなことになっちまったのかな・・・オレたちはただ、幸せになりたかっただけなのに」と敗戦後の焼け野原を見たときのような呟きが漏れてしまうことは、日常茶飯事です。

　それぞれのプロジェクトには、固有の難しさと失敗の原因が存在するでしょう。いわく、新しい技術にエンジニアが慣れていなかった。いわく、客のキーマンがモンスターカスタマーだった。いわく、オフショア先の品質が低くてメチャクチャなコードが上がってきた――これらはいずれも嘘ではありません。「幸福な家はみな同じように幸福だが、不幸な家の不幸には独自性がある」というトルストイの言葉通りです。

　しかし、あたまもやる気も人並みにある人間たちが数十年取り組んできて、それでもなお失敗を繰り返すのだとすれば、それはシステム開発という仕事に何かしら構造的な問題が潜んでいると考えるのが合理的というものです。この問いに対する本書の回答はシンプルです。

　作り手の進め方が悪い

　「……はい、どうもすいませんでした」。いや、「進め方」という書き方をしましたが、これは別に開発の方法論とかプロジェクトマネジメントの技法に欠陥がある、という意味ではありません。システム屋は、何かと物事を技術論に落として考えようとする癖を持っていますが、本書が指摘するのは、もうちょっと違う、どちらかというとメンタルの問題です。「SIerやベンダは、自分たちの立場を勘違いしている」というのが、本書の中心的なメッセージです。

　システム開発がモメる場合、その相手は十中八九が客です。業者間の擦り付け合いというモメ方をすることもありますが、その場合もある程度客が関係しています。開発側と客がモメるとき、開発側は、自分たちは精いっぱいのことはやったのだ、と考える傾向があります。出された要件には従ったし、何度も変更要求を入れてくるワガママにもつきあった。何も分かっていない素人の思いつきに、もう精神と肉体の限界まで付き合った。それなのに何でこれ以上責められなきゃいけないんだよ、と。

　しかし、本書が豊富な事例で示す判例は、そのような開発側に対してかなり厳しいものです。

システムの納入が遅れた原因について要件定義が不十分であったことに対してベンダ責任を認める。（東京地裁平成16年3月10日）
ユーザが威圧的なため開発者が離脱したことでシステムを完成させられたなかったことについてユーザ責任はないと認める。（東京地裁平成19年12月4日）
パッケージに機能が不足していたことを採用したベンダの責任と認める。（東京地裁平成22年1月22日）

　こうした判例におけるポイントは、「ユーザはシステムに関しては素人なのだから、開発主体はプロとして開発プロジェクトをリードする義務がある。ユーザに言われたことや契約書に書いてあることだけやりました、と言ってもその理屈は通らない」ということです。

　開発側は、ともすると「契約書や仕様書に書いてあることだけ満たせばいい」という発想をしがちです（Contract is contract）。しかし、たとえRFP通りのシステムが出来上がったとしても、それが実用に堪えなければ、「常識的にそれはおかしいだろ。プロなんだから、たとえ書面に書かれていなくても柔軟にそこは補えよ」という判断を裁判所は行う、ということです。客の検収が終わった後でも、実用に堪えなかった場合はベンダ側の責任が問われることもある（p.133）。言われてないから知りません、では許されないのです。

　このように開発側から見ると厳しい判断が行われる理由は、システムという分野の専門性が高く、買い手と売り手の間に知識の非対称性が大きいからです。いわば、医療や法曹と同じレベルでの注意義務が、作り手には求められるのです（収入は大分違う気がするが、ドンマイ）。

　最近も、要求仕様に明記されていないセキュリティ対策を行っていなかったことが開発側の責任として認められる判決が東京地裁から出ました。「たとえ明文化されていなくても、やって当たり前のレベルは言われなくてもやるべきだ」ということです。

　確かに、SQLインジェクション対策をやっていないWebシステムを世に送り出したというのは、普通のエンジニアであれば身震いする話ではあります。しかし、ここまで豪快ではなくても、「客は何も言わなかったし、仕様書にも書いていない」という要求を黙って見過ごしたことは、皆さんにもないでしょうか。それは許されない態度だ、と本書は何度も釘を刺します。そこは、プロとして客に注意を促し、コストと便益を情理を尽くして説明し、体を張ってシステムを守らなければならないのだ、と。

　刑法の世界には不作為の罪という概念があります。普通、罪というのは何らかの能動的な行為に対して問われます。しかし、よからぬ事態が出来することを知りながら適切な防止策を怠ることも罪なのです。

プロジェクトのリスク管理なんかもそうだけど、ITの世界では何もしないこと自体が問題ってケースがよくあるわ。いろんな問題をただ待つわけじゃなく、積極的に探し回る神経が双方に必要なのかもね。（p.246）

　これは、技術論というより、プロとしての自覚というマインドセットの問題です。エンジニアには法律や医療の世界と違って排他的な性格を持つ資格がなく、誰でも「自分はエンジニア／プロマネです」と名乗れてしまうため、人材の品質が安定せず、参入障壁も低いためコスト競争に巻き込まれてしまう、というマクロな構造問題もあるのですが、それはまあ、現場レベルで論じるには大きすぎる話です。

　本書は、開発側にとっては耳の痛い紛争の事例が豊富に紹介されています。また、プロジェクト管理やリスク対策にはコストがかかることを理解するべきだ、ということをはじめとして、ユーザ側にとってもSIerやベンダとうまく付き合うためのコツが紹介されており、双方にとって有用な知見が得られます。もっとも、本書をユーザ側が読むと「ふーん、開発サイドってのはそんなに立場が弱いのか・・・なるほどね」と悪用するためのガイドとしても使えそうな予感がするのは・・・気の回しすぎですかね。