目次

はじめに

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）　瑕疵担保責任の考え方