成功するシステム開発は裁判に学べ! ~契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック

著者 : 細川義洋

• 技術評論社 (2017年3月7日発売)

感想・レビュー・書評

[rohtさんの感想 · 2017年9月23日]

失敗した例からわかることはあくまで失敗しない方法であって、成功につながるか、、というとまた別。
よくある失敗から学習して、同様の失敗をしないようにしましょう、という示唆を受けるつもりで読んだ。

訴訟になる事例、ということでいずれもひどく（マネジメントの欠如、プロ意識の欠如等）が目立ち、普段の仕事に活かせるか、というとそうではなかった。
同業種の読書会のネタ本だったのだが、参加者は皆”ここまでひどくなる前に手が打てるし、打つ、何をやってるんだ”という感想であった。

個人的には、最新の民法改正の瑕疵担保責任の期限の変更が気になっており、そのへんの記載があると嬉しかったが、一応記載はあるものの薄め。
（実際現時点では事例もないし下手なことかけないのだろうが、、）

また、この本には、説明が不足しており、誤解を生みそうな箇所がある。

契約書記載の仕様書ない機能（チケット販売管理システムのDB操作機能)がない、ということでソフトウェアの完成が認められず、契約解除された事例がある。
仕様書に記載がない機能の実装がない、ことを理由に契約解除というのはITベンダー側からするとかなり厳しい。

この事例（東京地方裁判所平成16年6月23日判決 平成12年（ワ）第23214号、平成13年（ワ）第15547号 ）は、
経産省がまとめている事例集に詳細が記載されている。

http://www.meti.go.jp/policy/it_policy/softseibi/trouble%20cases.pdf
13.業務範囲・完成基準が曖昧なためにトラブルになった事例

この本に記載はなかったが、この経産省の資料では「契約書以外の資料に遠隔DB操作機能の記載があった」
「その機能がない限り契約書記載の開発の目的であるチケット販売管理が不可能」等の理由から、
例外的にDB操作機能が開発対象に含まれるとされた、という記載がある。
こういう理由をちゃんと記載しないと、無意味にベンダー側の危機感を煽るだけなのでは、と思う。

[makaonさんの感想 · 2023年11月28日]

会社のシステム変更の勉強のため購入。

ベンダー、ユーザー、両方に通じる内容なので役に立った。
基本的な知識、心構えなど。

[はっぱこさんの感想 · 2019年8月18日]

一般的に世の中に出てこない話題だし、ちょっと調べてみてもなかなか情報を得づらい内容が一冊にまとまっているので、ITに関わる身としては知っておいたほうがいいなと思う一冊。

そういえば、この間の7pay問題は開発元とまるくおさまったのだろうか・・・。

[amano225さんの感想 · 2019年4月30日]

過去のシステム開発に関わる裁判の判例を紹介したうえで、どういうふうにシステム開発をすすめていけばいいかを書いた本。
この本に書いてある通り、裁判に勝ったとしても、裁判になっただけでプロジェクト失敗だということがよく分かった。
そのためには、技術に疎いユーザー企業ではなく、ベンダー企業がちゃんとしなきゃいけないのだろうなと思った。ユーザー企業に技術的要件を決めさせるのは無謀と考えた方がいいらしい。
後、採用通知だけだと作業に着手しちゃいけないということもよく分かった。そもそも、自分が今の会社にきたのも、あるプロジェクトが採用されるから誘われたのに、結局そのプロジェクトは別の会社になったし。契約書はやっぱり大事ということか。
この本を読んで、ステアリングコミッティという言葉を初めて知った。この本では、「ユーザー側とベンダー側の責任者が相談するば」という定義をしているのだけど、そうすることで話がスムーズに進むらしい。ただの担当者ではなく、責任者がでることで、一気に解決することもあるらしい。まあ、ようは上司同士が出てきて解決ということだと思うけど、そうならざるをえないこともあるんだろうなぁ。
それと、ユーザー側担当者に業務知識がないとしても、ベンダー側は最大限、業務知識を把握するように努力すつ必要があるんだろうなと思った。ただ、業務知識がないユーザー側担当者って、いったい何でその人が選ばれたんだと思わなくない。
ちょっとビックリしたのが瑕疵担保責任について。2017年に民法が120年ぶりに改正されたそうなのだけど、瑕疵担保責任の内容が結構変わっている印象。
今までは納品して1年以内に瑕疵の通知をしなかったら、契約を解除することができたけど、それが納品後1年ではなく、発注者が瑕疵に気づいてから1年以内に変更になったらしい。実際には1年以内かどうかに関わらず修補するベンダーも多いそうだけど、ちょっとこの改正は注意しなきゃいけないような気はする。
後は、セキュリティについては常に情報収集して対策するようにしないといけないのだろうなと思った。これは確かに今後、気を付けていきたい。

[からべーさんの感想 · 2017年8月27日]

■書名

書名：成功するシステム開発は裁判に学べ! ~契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック
著者：細川 義洋

■概要

難しい判例を読み解き、現場で使える実践ノウハウをやさしく解説。トラブル多発の6テーマ
をしっかり押さえ、あなたのプロジェクトを成功に導く。
(amazon.co.jpより引用)

■感想

裁判、調停の判例をもとに、プロジェクトで何が大事かを記載した一冊です。
結論としては、

・プロとして出来る事を積極的にやる事
・契約が完了するまで、作業をしないこと
・契約書をしっかり作る事
・曖昧な言葉は使わない事
・実施する事、しない事を契約時に明記する事

などなどの当たり前の事が記載されています。
ただし、この人はこの当たり前が業界特有の文化により難しい事も理解しており
正論をぶつけるだけではなく、難しい中でもこうやって言った方がいいという書き方
になっています。

正論は、正しいから正論なわけで、やっぱりこの正論を実施できる環境を整える事が
プロマネとして実施すべきことなんだろうな～と思います。

■気になった点

・合意文書に、範囲、金額、スケジュールがないなら、作業は着手すべきでない。
　
・採用通知＝契約ではない！

・採用通知で作業に着手しないべきだが、それができないなら、傷の浅い内に逃げる
　認識をお互い共有しておくことである。

・ベンダーから追加の見積もりがあった時、ユーザが明示的に断るか限度額を提示
　しない限り、ユーザは支払いの義務がある。

・トップ同士の話で一夜で解決する事もある。

・契約前に作業を行うなら、ユーザはベンダに何も約束していない。という点を理解
　しておくべきである。

・ベンダは素人であるユーザがプロジェクトの進行を邪魔しないよう、コントロール
　する義務がある。

・プロジェクト管理費用は、全体の8-15％かかる。

・周囲からしつこいと思われても聞きまわる。それが信頼を勝ち取るコツではない
　でしょうか。

・無償で作業を行う時も、無償契約をすべきです。

・支援という言葉は使わないで、具体的にやることを記載します。

・不具合の有無ではなく、不具合発生後ベンダがどのように対応したか？が判決の
　ポイントとなります。

・ベンダーは何も言われなくても、これぐらいは必要だろうと思われる対策は打たない
　といけないと判決されている。

・セキュリティについては、費用がかかってもベンダがユーザに提示する必要がある。
　それでもユーザが拒否すれば仕方ないが、ベンダとしてユーザに提示したという事実
　が大事である。

・怒鳴られても無視されてもユーザにセキュリティについては言い続けることが大事
　である。

[yusuke0205さんの感想 · 2017年5月14日]

最近の民法改正に触れてある点はよかった。

[shonantokaさんの感想 · 2017年3月20日]

契約、要件定義、検収、下請け、著作権、情報漏えいという観点で、システム開発におけるユーザ、ベンダ（元請け）、下請けといった組織を交えた成功方法について解説している。ベンダはプロとしての振る舞いを求められるため、ユーザには適切に助言やマネジメント、成功に導くための姿勢を見せることが肝要。

著者プロフィール

ITコンサルタント、政府CIO補佐官。システム開発・運用の品質向上や企業のIT戦略立案の支援を行いながら著述、講演も行う。現在は、政府CIO補佐官としてデジタルガバメントの推進やIT化による行政改革などに取り組む他、行政におけるAI活用の研究を行っている。

「2018年 『ある日突然AIがあなたの会社に』 で使われていた紹介文から引用しています。」