はじめに

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