成功するシステム開発は裁判に学べ!
~契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック
- 細川義洋 著
- 定価
- 2,178円(本体1,980円+税10%)
- 発売日
- 2017.3.7
- 判型
- A5
- 頁数
- 224ページ
- ISBN
- 978-4-7741-8794-5 978-4-7741-8875-1
サポート情報
概要
ITシステム開発は、いまだ成功率が高いとは言えず、裁判にまで発展するトラブルも多くあります。
そこで下される判決はまさに「失敗の宝庫」。
本書では、IT訴訟の専門家の著者が、難しい判例をわかりやすく読み解き、そこから見えてくるトラブルのポイントや、プロジェクト成功への実践ノウハウを丁寧に解説。 契約、要件定義、検収のプロジェクト全体はもちろん、下請け、著作権、情報漏えいのトピックまで網羅し、これからくる約120年ぶりの民法改正も、しっかり押さえました。
こんな方にオススメ
- ITベンダー、SIerなどシステム開発会社のプロジェクトマネージャーや経営者
- システムを発注するユーザー企業の担当者
- ITシステム開発のなかで「裁判やトラブルで困った」という方
目次
はじめに
Part 1 契約で地雷を踏まないためのポイント
1-1 要件定義も設計もしてもらいましたが、他社に発注します。もちろんお金は払いません!
- 契約書がないプロジェクトは、訴訟のタネ
- 1億円の仕事も、他ベンダーにさらわれて大赤字に
- 契約書はなくても、ユーザーとベンダーとの合意は「文書化」して残すべき
- 合意文書には、「なぜ契約できないか」についても書いておく
1-2 採用通知=正式契約、ですよね?
- 「貴社を採用します」と言われて着手したのに、プロジェクトが中止に
- いくら作業しても、採用通知だけではお金はもらえません!
- いざとなったら、逃げることも大切
- 社内ルールで、アブない案件をふるいにかける
1-3 見積もりに合意してないから、要件追加分のお金は払いません!
- 契約から無事に作業スタート、でも油断は禁物です
- 合意がないから、費用を払う理由がない!?
- 作業を続けてほしいユーザーと、続けたいベンダー
- 見積もりをスルーされても、お金がもらえることがある
- 最後は「エラい人同士」で話し合ってもらう
1-4 締結5日前にユーザーが白紙撤回! 契約は成立? 不成立?
- “上”と“下”で言っていることが違うユーザー
- わからないときは、“上”の意思を問う
- 契約までのリスクを負うべきは、だれか
Part 2 要件定義・変更の責任を理解する
2-1 ベンダーはどこまでプロジェクト管理責任を負うべきか
- いつまでも続く要件の変更・追加・削除……、ついにプロジェクトが破綻
- 「お客様の希望するとおりに」のプロらしさが、じつは管理義務違反?!
- 身銭を切ってでも、予算にはゆとりを持つ
- プロとしての信頼が、最後にモノを言う
- プロジェクト管理のための費用は8%~15%
2-2 最低限の知識も理解もないユーザーと渡り合うには?
- 協力義務があるといっても、ユーザーにまったく知られていない現実
- “ソクラテス”のような会話術で要件を聞き出せ
- プロマネよりエラい責任者が、体制づくりののキーパーソン
2-3 定型外業務も自主的に調べるのが、ベンダーの努めです
- ユーザー独自の専門業務を理解する高いハードル
- ベンダーの常識だけでは、ユーザーが使えるシステムは作れない
- 「裏メニュー」まで用意して、成功したシステムとは
- 現場の「リアルな声」に隠れた定型外業務を発見せよ
2-4 ユーザーが資料をくれないのは、ベンダーの責任です
- 協力義務があるからといって、任せきりではダメ
- 結局、必要な作業はだれができるのか?
- 「ユーザーのお手伝い」まで見積もりに織り込んでしまう
2-5 2年超も仕様が確定しないのは、ベンダーの責任か?
- 試作、修正、見積もり、何度もそろえたのにOKしてくれない
- スムーズに要件定義を完了するための3つのポイント
Part 3 検収と瑕疵にまつわる誤解を知る
3-1 検収後に発覚した不具合の補修責任はどこまであるのか
- 1度OKをもらったのに、「やっぱり、こんなシステムにお金は払えません」
- 検収書は、仕事を完了した証じゃないの?
- 無事に支払いを受けるための4ステップ
3-2 不具合が残ってしまっても、うまくプロジェクトを完遂するためには?
- とりあえず使えるモノだったら、支払いが受けられるのか
- モメずにプロジェクトを終える3つのポイント
- 「プロとして仕事をやり終えた」と言えるか?
3-3 「契約不履行」と訴えられないように、ベンダーがすべきこと
- 作業範囲はどこまで? すれ違いが無益なトラブルを生み出す
- お互いが納得できる、作業と費用の見積もりのコツ
- プロジェクト成功のカギは、「まだ決まっていないこと」
- 技術者こそ、自分の作業を契約書で確認するべき
3-4 もしもシステムの欠陥により多額の損害賠償を求められたら
- どんなに優秀でも、損害賠償の危険からは逃れられない
- ベンダーの真価は、「不具合発覚後」に問われる
- その不具合を損害賠償にしないための3つの工夫
Part 4 下請けと上手に付き合うには
4-1 作業は丸投げ、支払いは? ――元請けvs.下請け裁判の行方
- ユーザーよりもやっかいな、ベンダー同士の醜い争い
- 使えないモノを作った下請けにも、支払いをしなければならなかった!
- “丸投げ”だけなら、元請けなんて価値がない
- どんなに嫌われても口出しするのが元請けの仕事
4-2 下請けが現場をトンズラ。取り残された元請けの運命は?
- 不満は少しずつ、知らないうちにたまっていく
- 積もった不満が爆発、下請けは蒸発
- 元請けと上司の板挟みになった、下請けプロマネの苦悩
- 「赤字か中止か」判断できるのは上司だけ!
- エラい人同士の「大人の会話」で、トラブル解決と生産性向上をねらえ
4-3 契約では「設計以降」をお願いしていますが「要件定義」もやってくださいね。下請けなんだから
- パッケージソフトの導入に潜む落とし穴
- 下請けに任せた工程が大失敗。それでも元請けの責任?
- 「このソフト、よくわからないから任せるね」はもう通用しない
Part 5 著作権で保護される範囲を心得る
5-1 個性的ならOK? ――著作権法で守られるソフトウェアの条件とは
- ソフトを真似されたのに、なにも違反にならない!?
- 独創性がなくても、とにかく自分の個性が見えるモノならいい
- ほしい権利は、契約書に書いておくべき
5-2 プログラムの「盗用」は本当に阻止できる?
- 個性なんて求められない現実で、著作権はどうなるか
- 著作権を勝ち取った「パックマン事件」
- 「個性があるか」の基準はかなりあいまい
- あとから権利でモメないための契約書モデル
5-3 業務で作成したソフトウェアの著作権は、だれにあるのか?
- 自分が作ったソフトを持ち出したら犯罪者!?
- 仕事で作ったモノは、会社のモノ
- 名前が書いていないモノは、だれの著作物でもない?
- 作ったソフトの報酬は給与です
5-4 頭の中も著作権の対象になる?
- 記憶に残るプログラムも、転職先では使えないのか
- 判断のポイントは、「似ていても仕方ないよ」と許されるかどうか
- 権利問題は複雑、だからこそ社内で話してみよう
Part 6 情報漏えいとセキュリティの要所を押さえる
6-1 セキュリティ要件のないシステムから情報漏えい。その責任は?
- 「システムの不備だ!」とベンダーを訴えるユーザー
- 要望どおりに作ったはずなのに、損害賠償1億円
- 提言だけではダメ、セキュリティ対策がないシステムは未完成
- 増え続ける攻撃に、いったいどこまで対策すればいいの?
- 「備えあれば憂いなし」セキュリティ対策の5か条
6-2 「お金も時間もありません」とセキュリティ対策を拒むユーザーに、どう渡り合うか?
- ユーザーの甘えが、情報漏えいを引き起こす
- セキュリティ対策をしないのは、不法行為です
- 嫌われても言い続ける「プロ意識」を持つ
6-3 対策していてもリスクは0じゃない。万が一の賠償は、いくらになるの?
- 相場は、1件あたり500円~数千円の“罰金”
- 個人情報の価値は、種類によって差があることも
- あなたのシステムの情報は、いくらですか?
- ITシステム開発に関わる民法の改正(1) 準委任契約でもプログラムを納品物にできる?
- ITシステム開発に関わる民法の改正(2) 成果物の一部納品でも費用の請求ができる?
- ITシステム開発に関わる民法の改正(3) 瑕疵担保責任の考え方
おわりに
コラム
プロフィール
細川義洋
ITプロセスコンサルタント。政府CIO補佐官。
1964年神奈川県横浜市生まれ。立教大学経済学部経済学科卒。大学を卒業後、日本電気ソフトウェア(現NECソリューションイノベータ)にて金融業向け情報システムおよびネットワークシステムの開発・運用に従事した後、2005年より2012年まで日本アイ・ビー・エムにて、システム開発・運用の品質向上を中心に、ITベンダー及びITユーザー企業に対するプロセス改善コンサルティング業務を行う。現在は、ITプロセスコンサルタントとして、ITベンダーやユーザー企業にITシステム開発の品質向上を支援するほか、経済産業省において電子行政推進を支援している。
著書に『プロジェクトの失敗はだれのせい?』(技術評論社)、『なぜ、システム開発は必ずモメるのか?49のトラブルから学ぶプロジェクト管理術』『「IT専門調停委員」が教えるモメないプロジェクト管理77の鉄則』(日本実業出版社)。