システム開発における訴訟事例から学ぶ｜なぜ、システム開発は必ずモメるのか？｜感想
この本を読んだ理由／知りたかったこと
私は以下の理由により、こちらの本を手に取りました。
プロジェクトはユーザー側／ベンダー側の両方からそれなりに見てきましたが、訴訟にまで発展するものは無かったため知識として知っておきたい。
私は業務においてインフラ系におけるシステム開発プロセスを管理するQA担当も兼ねているため、必要なレビュープロセス等に漏れがないかを確認したい。
どのような内容が書かれているのか？
簡単な物語形式で、システム開発におけるユーザー側／ベンダー側の法的な責任範囲の認定事例や、背景にあるIT訴訟における裁判所の考え方が記載されております。
特にベンダー目線においては、訴訟などのトラブルに発展することを避けるための方法や、簡単なチェックリストも含まれております。
感想／学び
IT訴訟について平坦かつ読み易く解説している本は少ないと思いますので、ユーザー側／ベンダー側問わずプロジェクト管理に関わる人は一読する価値はあります。
意外だったのは、法律に沿って機械的に判断されるのかと思いきや、消費者の立場であるユーザー側の権利がかなり守られていること。ユーザーが要件定義書や設計書、検収書などに判を押したとしても、ベンダーが専門家としての責任を十分に果たしていないと見なされた場合には、裁判で負けることも多々あるようです。
トラブルを防止するための各種方法論については教科書的な部分も多いのですが、QA担当を兼ねている身としては「どこかのコンサルが持ってきたプロジェクト管理手法をそのまま使ってはダメ。過去の事例から自社に適した管理プロセスを作ることが必要」という部分が印象に残りました。
その他印象に残った点は以下の通りです。
(利用パッケージの有識者がベンダにいない場合に)「ベンダはそのメンバーに必ずしも十分なスキルが無いことを正直に話して、代わりにプロジェクトの進行に合わせてメンバーを教育するスキルアップ計画を立ててきた」
自社が提案している以上、なかなか「スキルがない」と言いにくいため、実施できたことはありませんでした。
(特にITコンサルにいたときは、「知らない領域でも専門家風に見せながら、急いでキャッチアップして乗り切るのが優秀な人」という雰囲気だったので辛かった。。)
メンバーを育成するためのコストを誰がどの程度払うのかというのはモメそうですが、できるに越したことは無いですね。
「腹を割って話せばいい。相手だって勝っても何の得にもならない裁判なんかより、よほど生産的だって考えるんじゃない？」
確かに私がユーザー側のプロマネだった際にも、モメるたびにベンダのプロマネとコソコソ電話をよくしておりました。
ユーザー側のプロマネにとっては、(勝てるとしても)裁判になる時点社内的な評価は下がるわけで、誰よりも「前に進めたい」と考えます。
オジサンの9割はメンツでできているので、会議などの公式な場ではなく、個別で膝詰めで考えれば妥協案が出る可能性が高いですね。
「プロジェクト管理の費用は税金のようなものですわ。値引き交渉の対象外として考えるべきです」
この本では、全体工数の10％はプロジェクト管理に充てるべきと記載してあります。確かに当社でも同じような基準を持っており、10％以下であれば値引き交渉は概ね実施しておりませんでしたが、一般的なのですね。
著者：細川義洋
エンジニアやITコンサルタントに従事した後に、「東京地方裁判所・IT専門家調停委員」として、数多くのIT紛争事件を解決してきた経歴を持たれております。まさにIT訴訟のプロフェッショナルですね。
まとめ
今回は「なぜ、システム開発は必ずモメるのか？」の書評を紹介させてもらいました。
著者の豊富な経験に基づいており、IT業界の方はだれでも「あるある」と感る部分があると思います。IT訴訟について書かれている貴重な本ですので、一読の価値があると感じました。
ご興味がある方は読んでみて頂ければと思います。