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

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

A5判/224ページ

定価(本体1,980円+税)

ISBN 978-4-7741-8794-5

電子版

→学校・法人一括購入ご検討の皆様へ

書籍の概要

この本の概要

ITシステム開発は,いまだ成功率が高いとは言えず,裁判にまで発展するトラブルも多くあります。
そこで下される判決はまさに「失敗の宝庫」。

本書では,IT訴訟の専門家の著者が,難しい判例をわかりやすく読み解き,そこから見えてくるトラブルのポイントや,プロジェクト成功への実践ノウハウを丁寧に解説。 契約,要件定義,検収のプロジェクト全体はもちろん,下請け,著作権,情報漏えいのトピックまで網羅し,これからくる約120年ぶりの民法改正も,しっかり押さえました。

こんな方におすすめ

  • ITベンダー,SIerなどシステム開発会社のプロジェクトマネージャーや経営者
  • システムを発注するユーザー企業の担当者
  • ITシステム開発のなかで「裁判やトラブルで困った」という方

著者の一言

「この機能まで開発するって言ったはずだ」
「それは次フェーズでやる約束でした」
「こんなに欠陥だらけのシステムに金は払えない」
「それは,そもそもオタクが要件変更をくり返してプロジェクトを乱すからです」

……数々の IT訴訟の判決文を読んでいると,こんな言葉の応酬が目に浮かんできます。こんなやりとり,ITシステム開発に携わる皆さんなら,1度や2度は聞いたり,もしかしたら,ご自身で経験されたこともあるかもしれません。
そう。裁判になるような紛争と,通常のプロジェクトのトラブルの間には,大きな違いはないのです。というか,その原因や経緯は,ほぼ同じで,

「どちらかが『訴えてやる!』と思ったかどうかだけの違い」

と言ってもよいでしょう。
逆に言えば,裁判になってしまうプロジェクトは,ITシステム開発のための「反面教師」であり,裁判の判決を研究して,その解決法を検討することは,自分のプロジェクトを成功に導くためにとても有効なことです。

「ユーザーが要件を次々に追加してきたとき,ベンダーは,どんなことをしてプロジェクトを救うのか」
「ユーザーにシステムを引き渡したとき,確実に費用の支払いをしてもらうためにはなにをすべきか」
「下請けベンダーと上手に付き合うために必要なこととはなにか」
「著作権でモメないためにはどうしたらよいか」

……そうしたことについてのヒントが,裁判の判決には,たくさん含まれています。
また,この本は,[email protected]元にしていますが,書籍化にあたって大幅に加筆し,連載にはなかった「情報漏えい」の項目も書き下ろしました。
ここにある判例やノウハウを参考することで,ぜひ円滑で快適なITシステム開発プロジェクトを実施していただきたい,この本はそんな思いに基づいて書いています。

(「はじめに」より)

この書籍に関連する記事があります!

失敗したシステム開発のトラブルと裁判
「ITシステム開発の7割は失敗する」数年前,こんな「定説」がありました。

目次

はじめに

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の鉄則』(日本実業出版社)。