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

投稿元：

レビューを見る

ストーリー形式なので読みやすい。裁判ネタが主ではなく、中立な立場でシステム開発のべしべからずをまとめることを目指した感じか。ストーリーが邪魔な人もいるかもしれない。

投稿元：

レビューを見る

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

投稿元：

レビューを見る

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

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

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

投稿元：

レビューを見る

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

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

投稿元：

レビューを見る

芝居仕立てで、いささか冗長に感じた。

ベンダのプロとしての心構えの大切さと同時に、ユーザの役割の大きさがよくわかる。

投稿元：

レビューを見る

この類の本は一般論や理想論に終始しがちだが、本書は改善の具体策も書かれていて実践に向けてのヒントが満載である。「オーダメイドのシステム作りはベンダと顧客との協同作業である」という判決文はまさに金言。
私はユーザ側のシステム担当者であるから、(ユーザ側の視点に立ちながらも)どこかではベンダとユーザの双方が合意できる落とし所を模索しなければならない。
そういう意味では、協同作業が出来なくなり、裁判まで行き着いてしまった泥沼プロジェクトに対して、裁判所という第三者がどういう視点でジャッジし、または調停でどういう落とし所に持って行っているかを知ることが重要である。
本書に書かれていることは、プロジェクトが無益な泥沼陥らない為に、陥る前に引き返せるように、ベンダ側、ユーザ側の双方が知っておくべき基礎知識なのだと感じた。

投稿元：

レビューを見る

自分は、プロジェクトらしいプロジェクトには関わったことないのだけれども、この本だと『プログラミング』の章は身近に感じた。
とくに、ソースコードのチェックリストを見てみると、全然意識できてないなと実感。
意外だったのは、IT紛争はユーザーとベンダーのお互いに高い信頼を寄せているほうが起こりやすいという話。逆だと思ってた。

それにしても、最近、小説(ちなみに、この本は台本形式の小説)だと思わずに読んだら、小説だったという場面に遭遇することが多い気がする。

投稿元：

レビューを見る

プロジェクトを管理する立場の人だけでなく、管理される側の立場にある人にも、なんとなくでもプロジェクトベースでの働き方がわかる本。
作中の、達成できない理想論 v.s. 現状から抜け出せない現実論、達成できなくとも目指すことで結果が引っ張られることもあるし、一方でいつも達成できなくて士気の低下やら目標の形骸化、これはプロマネ業務に限らずどこでもある話だなあ、とも。

ストーリ形式なので、好き好きは分かれそう。

投稿元：

レビューを見る

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

投稿元：

レビューを見る

結構面白かった。物語形式で読みやすかったし。

こういうちゃんと手順を踏んだ開発って、なかなかやろうと思っててもできない。けど、だからって何もしなければいつまでも変わらない。

こういう取り組みこそ、組織として取り組むべきことなんだろうな。会社(チーム)に属してる意味合いの一つだと思うし。

今後の良い参考にさせてもらいます。

投稿元：

レビューを見る

全体通して読んでみてモメる原因は「人と人との意思疎通」が根本だなあと思った本。

具体例を交えて登場するキャラクターの会話からモメる事例とその対策について説明していく内容です。

個々の事例についてはあまり覚えてませんが、企画、要件定義、設計、テストと各フェーズでモメる根本原因は意思疎通だと思いました。

ブログはこちら。
http://blog.livedoor.jp/oda1979/archives/4709064.html

投稿元：

レビューを見る

プロマネとしての内容に目新しさはないものの、裁判事例が豊富にあり、トラブルが裁判まで進むとどうなるんだろうという疑問に答えてくれる、ありそうでなかった一冊。
ただ、この本の想定読者を考えると、もう少し硬派な作りにしてもらえたら情報量が多くて読みやすかった。

投稿元：

レビューを見る

某切り込み隊長をして“熱い涙なしには読めない”と言わしめた本著。
http://kirik.tea-nifty.com/diary/2013/11/49-3e8d.html
タイトルもかなりグッと来るキャッチーなフレーズのため本を開くのが楽しみな一冊となった。

要件定義～設計～契約と開発プロセスの全てを網羅した上で、起きがちなトラブル、事例をストーリー仕立てで紹介、対処方法や考慮すべきリスクなどを丁寧に教えてくれる。弁護士、ベンダ、ユーザ、プログラマ等様々な立場で架空のキャラクターが登場し、本筋とは関係ない日曜劇場さながらのドラマ（茶番）が本著の半分を占めており、「そんなことはいいから早く要点を･･･」とイライラしながら読み進めるも、進むうちにそのメロドラマの方が気になってくるというステキな仕立てになっている。

システム開発が絡むプロジェクトで働いた経験のある人はすべからく、思い当たる節が一個二個どころではない頻度で登場してくるので、読みながら実際の現場を思い出しつつ「うわ～あの時そうだったわ～」と感心せざるを得ないこと必至である。

これは2013年屈指の良著。

投稿元：

レビューを見る

システム屋あがりの地裁民事調停員が書いたシステム開発におけるトラブル集。
W/F型開発を例に、各工程で起こりがちなトラブルが実際にあった判例と共に紹介されておりイチイチ恐ろしい。
例えば、ユーザに「直接」DBを更新させるなんてシステム屋からしたらアリエナイと思っていたが、某業界では不可欠の機能であり、「要件に無くとも」実装されていないのは業界常識を知らなかったベンダに非がある、との判決があったそうな。怖すぎ。

また、裁判所は杓子定規に契約書の記載内容だけで判断するのではなく、それ以上にベンダ・ユーザとも「如何に誠意があったか」に重きを置くということも知った。
どの工程においても組織間でセクショナリズムに陥ることなく、ベンダ・ユーザが協力＝互いに気遣いながらベストな解を模索することが、成功したプロジェクトの共通点だと。
（組織内のセクショナリズムなど論外すなぁ…）

会話形式でさっくり読める割に内容もしっかりしていてお勧めできる一冊。