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

「成功するシステム開発は裁判に学べ!」のカバー画像
著者
細川義洋ほそかわよしひろ 著
定価
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の鉄則』(日本実業出版社)。