なぜ、システム開発は必ずモメるのか？

細川義洋

「完成させたんですから費用を払ってください!」
「こんなヒドい出来のシステムに金なんか払えない!」
システム開発プロジェクト上で起きたトラブルが、5年以上にわたる裁判や、数千万円もの損失につながることがあります。
ストーリー形式でまとめられた本書では、そうしたトラブルの本質を“ぶっちゃけ女性IT弁護士”がズバッと指摘! トラブル対処法と事前対策を学ぶことができます。
著者は、東京地方裁判所でIT案件専門の調停委員を務める細川義洋氏。ソフトウェア契約書の記載項目例など、今すぐ使えるチェックリストや参考資料も満載です。

• カテゴリ: ビジネス・実用
• ジャンル: IT・コンピュータ / インターネット
• 出版社: 日本実業出版社
• タイトル: なぜ、システム開発は必ずモメるのか？
• タイトルID: 273953
• ページ数: 272ページ
• 電子版発売日: 2014年08月01日
• コンテンツ形式: EPUB
• サイズ(目安): 4MB

[ブクログ · ★★★★★]

20160417
受注を受けてから納品するまでの流れとプロジェクトマネージャに要求されるスキルを理解するのに適した本だった。
参考資料も目を通す。

[ブクログ · ★★★★★]

素晴らしい内容だった。
どのページも重要で、ピックアップが出来ないぐらい。
定期的に読むべき本である

[ブクログ · ★★★★★]

事例を用いた解説で理解しやすい。1つのトピックが4ページと短く、会話形式で読みやすいので読んでいて面白い。ベンダ側・ユーザ側、元請け・下請けと相対する立場でそれぞれ気をつけること、押さえておくべきチェックポイントが参考になる。システム開発をするうえで手元に置いておいて何度も読み返したい本。

[ブクログ · ★★★★★]

これは名著！
この本に書かれていること、全てが重要で付箋だらけになってしまった。
タイトルに引かれて手に取ったが、
書かれているのは、システム開発の流れの中で何に気をつけて進めていくのか、どういう箇所が後々問題のポイントとなるのかを説明している。

・何度も要件を追加するユーザ
・ベンダ任せにするユーザ
・ユーザの参加意識をどう高めるか
・プロジェクト完了は何を基準に判断すればよいのか

・・・など、耳は痛いが重要なことばかり。

しかも、これは解説書ではなく、小説形式で物語が進行していくので、
ユーザ・ベンダの立場を理解しやすい。

小説形式だが、トピックは見開きというわかりやすさ。
章末、巻末に収められているチェックリストは、実務に大いに役立ちそうだ。

たぶんこれは後日購入するだろう、
プロジェクト管理の基本として自分の会社でも広めたい本。

【ココメモポイント】
＜要件定義＞
・定期的に要件変更に関する会議を開く
　P.20

・その場しのぎで取り繕って、問題先送りにする態度こそ、不誠実この上ない
　P.21

・業務フローに載る人の意見をすべて収集する必要がある。
　（中略）失敗プロジェクトの９割は、要件定義が関連してる
　P.29

・要件はお客さんの責任って風潮が最近は強すぎる
　P.40

・トレーサビリティマトリクス
　要件定義、設計項目などにＩＤを振って、１つの表にまとめる
　
P.48

・ユーザの業界における“常識”は無視できない
　P.60

＜プロジェクト計画と管理＞
・定量的なプロジェクト管理方法をユーザにもしっかり理解してもらって、定例会の場で認識を共有すること
　P.83

・“紙芝居”をつくってユーザに触ってもらったり、（中略）
　ユーザの興味や参加意識を継続させる
　P.90

＜設計＞
・困ったときには、周りの人と会話したり、考えていることを口に出したり、書いてみるだけでも頭は回転し出すもの
　P.121

・システムで大切なのは、それを使った業務がつつがなく行えることであって、中身じゃないって考え方が一般的
　P.133

＜テスト＞
・システムの品質を守る最後の砦は受入テストではなく、それに向けたテストケースやテストデータのレビューだと思ってる
　P.178

・ＩＴ紛争は、そのすべてが開発中にユーザがベンダに不信を募らせることが土台になってる
　P.186

＜契約と仕事の完成＞
・ベンダは契約書に書いてある事柄を全うするギリギリの作業をして引き揚げる
　P.210

・メンバの机がいつもより乱雑になっていることに気づく細かい神経も求められます
　P.213

・プロジェクト計画をユーザと検討する際には、実力以上の役割を負わず、双方がある程度妥協もしながら役割分担を決めていくことが紛争に発展しないポイント
　P.258

[ブクログ · ★★★★★]

東京地裁のit専門の調停委員によるトラブル事例
とはいってもしっかりpmbok cmmi itilなどの模範的マネージメント概説もある
数時間で読める

[ブクログ · ★★★★★]

お仕事で読みました。発注側です。
堅苦しくなく、大切な部分は強調されていて、
読みやすかったです。
ただ、受注側、発注側それぞれに特化した本を
書いて頂ければなお嬉しいです。発注側としては
不要と感じる部分がありました。

[ブクログ · ★★★★★]

いわゆるべからず集。顧客と折衝するような立場にある人は一読の価値あり。一度読んで終わりではなく、事あるごとに参照したい内容でした。しかし、思った以上に情報ベンダの責任は重いんだな•••

[ブクログ · ★★★★★]

各工程におけるユーザ・ベンダ間の問題について、法律観点で解説されている。
IT契約は、契約書の文言云々よりも、実態ベースで判断がされることは覚えておいたほうがいい。
設計書に書いているから大丈夫！承認貰ってるから大丈夫！という甘い考えでは、後々大トラブルのタネとなること請け合い。

「信義則義務」「善良なる管理者の注意義務」など、プロジェクトをマネジメントする側で参画する立場の人は知っておくべき。

それにしても、結局塔子と一郎はどうなったのだろう…
まあ一郎は有能なPMのようなので、大丈夫かな。

[ブクログ · ★★★★★]

名著！
プロジェクト管理云々より最初に、「ベンダはプロフェッショナルなのだから、プロフェッショナルとしてユーザの目的達成に協力しなければいけない」ということに気づかされた。

例えば、建築家が、お客さんがリビングを広げたいというからと言って、リビングを広げる代わりにトイレをなくして、後で「あれっ、図面見せましたよね」なんて言ってはいけないのだ。

[ブクログ · ★★★★★]

システム開発を請負、マネジメントする立場になった私にとって、本書はとてもわかりやすく、有意義なポイントが整理され、とても勉強になりました。