システム開発のトラブル回避は裁判に学べ！ [単行本]

システム開発のトラブル回避は裁判に学べ！ [単行本] の 商品概要

• 目次

  はじめに
  
  ■■■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 企業の共存は可能か
  ■おわりに
  
  著者プロフィール

• 内容紹介

  進化を続けるIT技術とは裏腹に、今も絶えず起こるシステム開発の失敗。その責を巡る争いが裁判所へ持ち込まれることも珍しくありません。どうすればトラブルを回避し、プロジェクトを成功に導けるのか？
  
  ・従来からトラブルになりがちな「要件定義」「契約」の責務と要点
  ・昨今でますます重要視される「セキュリティ」「知的財産」の管理、コロナ禍以降で多様化した働き方に対応するための「労務知識」
  ・開発が激化する中で重要な「AI」開発に関する法的知識
  
  これらをIT訴訟のプロが判例からやさしく読み解き、さまざまな知識、注意点、工夫を解説します。プロジェクト現場必携の1冊です。

• 著者について

  細川 義洋 (ホソカワ ヨシヒロ)
  元東京高等裁判所専門委員（IT）、経済産業省デジタル統括アドバイザー、独立行政法人情報処理推進機構専門委員。筑波大学大学院修了（法学修士）。国内ソフトウェア開発企業にて金融業界向け情報システムおよびネットワークシステムの開発・運用に従事した後、外資系コンサルティングファームにて、システム開発・運用の品質向上を中心に、ITベンダーおよびITユーザー企業に対するプロセス改善コンサルティング業務を行う他、裁判所においてシステム開発をめぐる法的紛争の解決支援にあたる。内閣官房政府CIO補佐官を経て、現在は経済産業省においてデジタルガバメントの推進および情報セキュリティの整備を支援している。著書に『成功するシステム開発は裁判に学べ』（技術評論社）、『なぜ、システム開発は必ずモメるのか？49のトラブルから学ぶプロジェクト管理術』（日本実業出版社）、『システムを外注するとき読む本』（ダイヤモンド社）、『エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと』（ソシム社）　他。

システム開発のトラブル回避は裁判に学べ！ [単行本] の商品スペック