寺子屋未満

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術

posted with amazlet at 14.08.09

細川 義洋
日本実業出版社
売り上げランキング: 11,137

Amazon.co.jpで詳細を見る

読了しました。
本書は、長年大手ベンダに勤務した後、現在はIT関連訴訟の調停委員としてご活躍されている筆者が、実際に起きたIT関連訴訟の判例等を引用しながら「モメない開発方法」についてのアプローチ方法を説いていくものです。

「要件定義」「プロジェクト計画と管理」「設計」「プログラミング」「テスト」「契約と仕事の完成」、それぞれの段階でもめ事になりそうなこと、気をつけなければいけないことが、ユーザー視点（発注側）・ベンダ視点（受注側）双方の立場で書かれています。
いわゆる”上流行程”の経験が少ない自分にとっては特に、要件定義・プロジェクト計画・契約と仕事の完成の章は、得るものが多かったです。（ちょうど要件定義書を書いていた、というのもある）

※ 以下、発注・受注の関係は全て、ユーザーとベンダという用語を使用します。

共通して本書で訴えていたのはこの3点。

ベンダとユーザーはシステムを協力して完成させる義務がある
何度も出てきたのがこれ。訴訟になる原因のほとんどは、ベンダとユーザーの信頼関係がこじれることがトリガーになっているようです。

• ユーザーがベンダに言いくるめられてだまされていた
• ユーザーが直前までベンダに隠し事をしていた
• ユーザーが「全部お任せします」と丸投げし、最後に結果を見たら思っていたものと全然違うものが出来上がり「裏切られた」と感じる
• ユーザーに「これを実現してくれないなら、御社との契約を切っていいんだよ」と言われ、Yesしか言えないベンダ
• 画面の確認等をユーザーにお願いし、毎回「問題ない」と回答がきて安心していたら、実は全く内容を確認していなかったことがリリース直前に発覚、怒るベンダ

いろんなパターンが出てくるのですが、どれも共通して言われているのが「丸投げしないで、状況はオープンにして、協力してプロジェクトを進める必要がある」ということ。
ただし、ベンダは不慣れなユーザーを協力させる、協力しやすく導く義務はある。
上記の最後の例なんかは、ベンダがもっと誘導してあげないといけない典型例（一緒に確認するとか、使い方を教えるとか）。
訴訟になると敵対関係になってしまうのだけど、プロジェクトの完遂という意味で同じ船に乗っている乗組員だと言う意識を忘れてはいけないね。

面白かったのが、筆者の目から見た時

• あのユーザーはしっかりしていないから、こっちが主導権を握ってやらないと
• あのベンダはどうも信用ならないから、こちらが積極的にうごかないと

一見、信頼関係は築けていないように思えるのだけど、このパターンは意外と上手く進むということ。
これはどちらも「プロジェクトを成功させる為にできること」を第一に考えているから、なんだろうなあ。

裁判所は杓子定規に判断することはない、全ての状況を総合的に判断する
裁判所の判例を見ると、割と一般的感覚に近いものが多い。
判子を押してしまったからひっくり返せない、とか、この書類を受領しているから同意したと見なす…とか「決定的証拠でアウト」みたいな判例はあまりなかった。
全ての出された証拠（議事録やメール、設計書）から、総合的に状況を判断して「これはあなただけが悪いとは言えない」「これはあなたに責任がないとは言えない」とかを判断していた。
法律はバランスである（民事系は特に）という通りだなあ。出てきた判例で、納得いかないものはありませんでした。

でも「かなりの数のIT系の訴訟がある（東京だけで年30件）」このことにはびっくりしました。

訴訟なんて起きないのが一番いい
そりゃそうです。
いったん訴訟になると、決着がつくまで数年かかる場合がほとんど。
「日本人的あいまいさ」と言われても、和解して、痛み分けで終わらせることを勧めることが多いとのこと。

そうならないように何ができるか？ということを自分たちで考えるために助けになるのが、本書です。

本書ではプロセスを重視し、プロセスごとに必要な書類・チェックリストが大量にでてきます。
正直、現場の感覚で言うと、そこまでプロセスガチガチで、大量のドキュメントがあるような状態での開発はしたくないなあと考えながら読んでいました。形骸化しているプロセスがたくさんあるという経験をしたからかもしれません。
しかし、その思いも本書の中で的確にある登場人物に突っ込まれていました。現場の感覚とかけ離れている、と。
本書の見解としては、全てを実行する必要はない、これだけモメる可能性がある中、自分たちの組織では何ができるかを考え、取捨選択し、ブラッシュアップすること（孫悟空の天竺への道のり）が大切だ、ということです。

個人的にひやっとした事例

• DBの設計が悪く、保守費用が当初ベンダが見積もりで出してきていたよりも倍近くかかる（保守会社はシステムを受注したベンダとは別）、システム納品と検収は完了しているがユーザーはベンダに追加費用を請求できるか？
• 仮契約書を取り交わしている段階で先行作業を進めていたら、プロジェクトが中止になった。進めていた作業分の支払いはどうなる？
• リプレイスしたシステムを本番環境で実行したら、今まで2時間で終わっていた処理が10時間かかっても終わらない。ベンダは「要件定義書にはそんなスペックの低いマシンだという記載はなかった。複数台のマシンを使って並列処理するなど回避してくれ。」というが複数マシンを購入するような予算はない。ユーザーは要件を満たしていないとして改修を要求できるか？

学生時代に法律関係の勉強をしていたこともあり、今の仕事と昔勉強したことが繋がった本を読めたというのが、なんか興奮しました。
「IT関連訴訟を専門に行う調停委員」というキャリアプランがあることを知れたのも良かった。すごく魅力的な仕事だ。
将来的（調停委員として信頼を得られそうな年齢になった頃）に、そういう人生設計に舵をとれるといいのかもしれないなあ。

物語形式で（最初は登場人物が鼻についたが、後半はなぜか応援したくなった）読みやすく、一つ一つも短いのでシステム開発に関わっている人は軽い読み物として一度読んでみることをおすすめします。