はじめに

■■■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 企業の共存は可能か
■おわりに

著者プロフィール