目次

• はじめに

Part 1　要件定義のカギを押さえる

1-1　製造工程に入ってるけど、やっぱこの機能も追加してくださーい。

• 要件定義まで請負契約にしてしまったプロジェクトの失敗
• 追加機能はRFPにもなかったが、既存システムにはあった。
• 要件定義を請け負うことは、すべてを請け負うこと

1-2　仕様書どおりにシステムを作りました。使えなくても知りません。

• ユーザーの示した要件が不備だったことに起因する紛争の例
• 要件を間違えたユーザー企業が悪いのか、間違いを見抜けなかった専門家の不備か
• 要件を満たせばいいってもんじゃない
• そもそも要件定義書は完璧ではない

1-3　業務をパッケージに合わせると言ったけど、めんどくさいからやっぱりやめた。

• システム開発契約に大切なのは「要件」と「目的」と……?
• 「パッケージに合わせる」と言ったのに!
• フィッティング方式とカスタマイズ方式
• 基本方針の途中変更はNG

1-4　何で仕様も教えてくれないんですか!

• ITプロジェクトの成否のカギは誠実な情報共有
• 仕様確定なしに進めるベンダーと費用を払わないユーザー企業
• 「ベンダーが勝手に進めている」というユーザー企業の言い分
• 勝手に進めるなら勝手に支払いを止めるという理屈
• ベンダーにも反省の余地

1-5　パッケージソフトだか何だか知りませんが、現行システムと同じの作ってくださいよ

• 「現状どおり」とまとめられた要件は有効か?
• 「現状」という言葉のあいまいさ
• 結局は、両者が一緒に要件を詰めること

Part 2　契約でトラブルにならないために

2-1　お前とは絶交だ!　契約も解除してやる!

• 信頼関係が崩れれば契約は解除される
• 社長同士のケンカは契約解除の理由になるか
• 裏を返せば、開発に関係する信頼の棄損は解除につながるということに……

2-2　契約の範囲外でも対応してください。

• 受注者と発注者の間のポテンヒット
• 契約にはないが、ベンダーにしかできなかった仕事
• 「契約になければ責任はない」が法律上の判断
• 守備範囲外でも拾いにいけばメリットも

2-3　契約書にも民法にも書かれていませんが、「義務」なので履行してください。

• 契約に存在する「見えない義務」
• 契約書に書かれていない成果物の納品義務はあるのか?
• 契約の目的達成に必要なものは成果物

2-4　この契約は、請負でも準委任でもありません。

• それって本当に準委任契約?
• 発注者は請負だと思い込み、受注者は準委任だと信じた開発契約
• 契約の内容からは、どちらとも言えない
• 大切なのは契約タイプを決めることより双方の合意

2-5　やったぶんはお金ください。納品してないけど。

• 中途解約でもお金はもらえる?
• 中途解約時の賠償金額が問題となった事件
• 「終了部分」を巡る認識の違い
• その契約書に「終了部分」の定義はあるか?

Part 3　セキュリティの要点を押さえる

3-1　ファイアウォールの設定を、すり抜け放題にしました。

• システム化要件が書かれていない契約書
• 契約書に記されていなかったセキュリティ要件
• 契約書だけがすべてではない

3-2　技術的に不可能でも、セキュリティ対策は万全にしろ!

• 暗号資産のセキュリティが問題となった事件
• 争点はNEMのセキュリティ対策
• 技術的な限界で十分な対策が打てない場合
• 善管注意義務の限度
• 学び続ける責任

3-3　従業員が作ったセキュリティホールの責任を会社が取るなんてナンセンスです。

• 不備の責任は企業と従業員のどちらが取るべきか?
• 従業員にだけ責任があると主張するベンダー
• エンジニア個人に不法行為があったとする判決
• エンジニア個人に求められる責任感

3-4　顧客情報は秘密情報なんですか?

• 営業機密の漏洩を巡る裁判
• 営業秘密と認められるためにすべきこと
• IT部門と法務部門の連携が鍵

3-5　営業秘密を漏洩しても罪に問えない?

• 企業の営業秘密をライバル会社に漏洩した社員
• 管理体制に不備があると「営業秘密漏洩」に問えない?
• 十分な管理と周知があればこそ……

Part 4　知的財産の権利を守る

4-1　似たようなデータベース作ったからって、泥棒よばわりするのやめてもらえません?

• 退職社員が前職のデータベース構造を著作権侵害した?
• 平凡でも、ありきたりでも、ソフトウェアの権利は開発者のもの

4-2　プログラムの著作権違反、その基準はどこにある?

• 創意・工夫を機能で見るか、独自開発の分量で見るか
• 今までありそうでなかった「分量」による判断
• ユーザーも「独自部分」とその量は知っておく

4-3　DOS版をWindows用に書き換えただけで著作権?

• プログラムが著作物かの判断
• 独自の工夫とアイデアがあれば、とはいうが……
• 開発者が独創的と思っても、他人から見れば……
• 作り方が十人十色のようなものであれば……
• それでも著作権の主張は難しい
• GPLの考え方

4-4　ソフトは転売していません。マニュアルを販売しただけです

• 自分が作ったソフトを勝手に転売されたら、訴えてやる?
• そもそもどんな法律に引っ掛かるのか
• 相手方に事の重大さを認識させる

4-5　データベースをパクられたので、著作権侵害で9億円請求します!

• データベースの著作権
• どのようなデータベースに著作権が認められるのか
• データベースの著作権を巡る裁判の例
• データベースの著作権が認められる可能性は高い
• 作った人へのリスペクトを

Part 5　多様化する働き方に適応するための労務知識

5-1　こんな裁量労働制は嫌だ!

• 現実は甘くない裁量労働制
• 裁量の余地のない裁量労働制
• 「契約は契約」とはいうものの……
• おかしな納得をしてはいないか

5-2　業績の悪い社員を解雇して何が悪いんですか?

• ドライになった会社と社員の関係
• 業績評価が持ち直した矢先の解雇
• 昭和は遠くなりにけり

5-3　退職するなら、2,000万円払ってね。

• 無能だった代償に、2,000万円払いなさい
• 社員の失敗は会社の責任
• 社員は毅然とした態度を、会社は常識をわきまえて

5-4　同僚を引き連れて起業するなんて、この恩知らず!

• 転職はソフトウェア業界の日常茶飯事だけど……
• 元従業員の不義理を訴えたソフトウェア企業
• 在職中の引き抜きは不法行為の可能性も
• 経営者に対する教訓

5-5　メンバーの体調不良まで我が社のせいにするのか!

• 開発遅延を責められたベンダー担当者
• メンバーのプロジェクト離脱はユーザー企業の責任か
• “不作為は罪”

5-6　あるエンジニアの死。

• あるシステムエンジニアの死
• エンジニアの死の責任は企業にあるのか
• 基準や一般論との比較ではなく個々の事情を酌む
• 社員の健康は社員と企業の協業

Part 6　AIを使った開発で失敗しないために

6-1　AIシステム導入の落とし穴：プロンプトインジェクション攻撃の脅威と対策

• プロンプトインジェクション攻撃とは?
• AIが自分をハッキング
• Vanna.AIリモートコード実行脆弱性
• 学術論文レビューシステムへの攻撃
• Webアプリ向けの対策は役立たない
• 企業が直面するリスク
• 実践的な防御策
• AIと共に脅威も進化し続ける

6-2　AIの判断ミスが招く深刻な損害：医療から自動運転まで広がる責任問題

• 保険審査AIの機械的拒否が招いた悲劇
• 診断AIの見落としが医療過誤訴訟を急増させる
• Tesla Autopilot事故が示すAIの限界
• 緊急車両を認識できないAIの危険性
• なぜAIの判断ミスは深刻な損害につながるのか―過信と責任のあいまいさが生む隙
• 統計的判断の落とし穴
• 企業が直面する法的・経済リスク―巨額損害賠償の現実
• レピュテーション損失と規制強化
• IT技術者が学ぶべき教訓と対策―「AI 万能論」からの脱却
• 実践的なリスク軽減策
• 保険とコンプライアンス体制の見直し

6-3　AI時代の著作権紛争：創作者vs.技術企業の新たな戦場

• 史上最大の著作権和解：Anthropic事件の全貌―15億ドル和解が示すAI 業界の転換点
• 和解の背景にある戦略的判断
• 画像生成AI 訴訟：創作の本質を問う戦い―アーティストの反撃
• 音楽業界の反撃：AI vs. レコード産業―音楽生成AIの法的限界
• 報道機関の挑戦：情報の価値を巡る攻防―ジャーナリズムの生存をかけた戦い
• Perplexity AIの新しい脅威：検索型AIの著作権問題
• AI時代の著作権法理：従来の枠組みでは解決困難な問題―フェアユース論争の新展開
• 「学習データ取得の適法性」という新基準
• 企業が直面する法的・経済リスク―数兆円規模の潜在的損失
• ビジネスモデルの根本的見直し
• 規制環境の厳格化
• IT技術者・企業が取るべき対策
• 今後の展望：創作者とAI 企業の共存は可能か
• おわりに

• 著者プロフィール