成功するシステム開発は裁判に学べ! ~契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック

著者 :
  • 技術評論社
3.11
  • (0)
  • (4)
  • (2)
  • (3)
  • (0)
本棚登録 : 39
レビュー : 5
  • Amazon.co.jp ・本 (224ページ)
  • / ISBN・EAN: 9784774187945

感想・レビュー・書評

並び替え
表示形式
表示件数
  • 失敗した例からわかることはあくまで失敗しない方法であって、成功につながるか、、というとまた別。
    よくある失敗から学習して、同様の失敗をしないようにしましょう、という示唆を受けるつもりで読んだ。

    訴訟になる事例、ということでいずれもひどく(マネジメントの欠如、プロ意識の欠如等)が目立ち、普段の仕事に活かせるか、というとそうではなかった。
    同業種の読書会のネタ本だったのだが、参加者は皆”ここまでひどくなる前に手が打てるし、打つ、何をやってるんだ”という感想であった。

    個人的には、最新の民法改正の瑕疵担保責任の期限の変更が気になっており、そのへんの記載があると嬉しかったが、一応記載はあるものの薄め。
    (実際現時点では事例もないし下手なことかけないのだろうが、、)

    また、この本には、説明が不足しており、誤解を生みそうな箇所がある。

    契約書記載の仕様書ない機能(チケット販売管理システムのDB操作機能)がない、ということでソフトウェアの完成が認められず、契約解除された事例がある。
    仕様書に記載がない機能の実装がない、ことを理由に契約解除というのはITベンダー側からするとかなり厳しい。

    この事例(東京地方裁判所平成16年6月23日判決 平成12年(ワ)第23214号、平成13年(ワ)第15547号 )は、
    経産省がまとめている事例集に詳細が記載されている。

    http://www.meti.go.jp/policy/it_policy/softseibi/trouble%20cases.pdf
    13.業務範囲・完成基準が曖昧なためにトラブルになった事例

    この本に記載はなかったが、この経産省の資料では「契約書以外の資料に遠隔DB操作機能の記載があった」
    「その機能がない限り契約書記載の開発の目的であるチケット販売管理が不可能」等の理由から、
    例外的にDB操作機能が開発対象に含まれるとされた、という記載がある。
    こういう理由をちゃんと記載しないと、無意味にベンダー側の危機感を煽るだけなのでは、と思う。

  • ■書名

    書名:成功するシステム開発は裁判に学べ! ~契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック
    著者:細川 義洋

    ■概要

    難しい判例を読み解き、現場で使える実践ノウハウをやさしく解説。トラブル多発の6テーマ
    をしっかり押さえ、あなたのプロジェクトを成功に導く。
    (amazon.co.jpより引用)

    ■感想

    裁判、調停の判例をもとに、プロジェクトで何が大事かを記載した一冊です。
    結論としては、

    ・プロとして出来る事を積極的にやる事
    ・契約が完了するまで、作業をしないこと
    ・契約書をしっかり作る事
    ・曖昧な言葉は使わない事
    ・実施する事、しない事を契約時に明記する事

    などなどの当たり前の事が記載されています。
    ただし、この人はこの当たり前が業界特有の文化により難しい事も理解しており
    正論をぶつけるだけではなく、難しい中でもこうやって言った方がいいという書き方
    になっています。

    正論は、正しいから正論なわけで、やっぱりこの正論を実施できる環境を整える事が
    プロマネとして実施すべきことなんだろうな~と思います。

    ■気になった点

    ・合意文書に、範囲、金額、スケジュールがないなら、作業は着手すべきでない。
     
    ・採用通知=契約ではない!

    ・採用通知で作業に着手しないべきだが、それができないなら、傷の浅い内に逃げる
     認識をお互い共有しておくことである。

    ・ベンダーから追加の見積もりがあった時、ユーザが明示的に断るか限度額を提示
     しない限り、ユーザは支払いの義務がある。

    ・トップ同士の話で一夜で解決する事もある。

    ・契約前に作業を行うなら、ユーザはベンダに何も約束していない。という点を理解
     しておくべきである。

    ・ベンダは素人であるユーザがプロジェクトの進行を邪魔しないよう、コントロール
     する義務がある。

    ・プロジェクト管理費用は、全体の8-15%かかる。

    ・周囲からしつこいと思われても聞きまわる。それが信頼を勝ち取るコツではない
     でしょうか。

    ・無償で作業を行う時も、無償契約をすべきです。

    ・支援という言葉は使わないで、具体的にやることを記載します。

    ・不具合の有無ではなく、不具合発生後ベンダがどのように対応したか?が判決の
     ポイントとなります。

    ・ベンダーは何も言われなくても、これぐらいは必要だろうと思われる対策は打たない
     といけないと判決されている。

    ・セキュリティについては、費用がかかってもベンダがユーザに提示する必要がある。
     それでもユーザが拒否すれば仕方ないが、ベンダとしてユーザに提示したという事実
     が大事である。

    ・怒鳴られても無視されてもユーザにセキュリティについては言い続けることが大事
     である。

  • 最近の民法改正に触れてある点はよかった。

  • 契約、要件定義、検収、下請け、著作権、情報漏えいという観点で、システム開発におけるユーザ、ベンダ(元請け)、下請けといった組織を交えた成功方法について解説している。ベンダはプロとしての振る舞いを求められるため、ユーザには適切に助言やマネジメント、成功に導くための姿勢を見せることが肝要。

全5件中 1 - 5件を表示

成功するシステム開発は裁判に学べ! ~契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブックのその他の作品

細川義洋の作品

成功するシステム開発は裁判に学べ! ~契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブックを本棚に登録しているひと

ツイートする