なぜ、システム開発は必ずモメるのか?
書店で詳細を見る
感想・レビュー(75)
- システム開発におけるユーザ企業、ベンダ企業両社のプロマネ向け。ユーザはベンダへの丸投げはNGだし、ベンダはユーザにリスク（潜在的な問題）や課題（顕在された問題）の示唆が求められる。要素はプロジェクト推進のマネジメントにも適用出来る。関係者間のコミュニケーションが肝。 ■要件書と設計書、テストの漏れ防止には『トレーサビリティマトリクス』 ■テストのケースやデータレビューはテスト自体よりも大切。外字の検知は受入テストならでは。 ■内部テストは今回開発プログラム内。外部テストは周辺システムの接続含めたテスト。
- システム開発におけるトラブルとその対処法について実践的にまとめられた書籍です。 クライアントの要求どおりの複雑な要件を実現するために、専門家である開発ベンダーが 注意すべき点と、クライアント自身が協力すべき点について、網羅的に整理されていて、 おすすめです。Amazon.co.jp: なぜ、システム開発は必ずモメるのか？ eBook: 細川義洋: Kindle Store https://www.amazon.co.jp/dp/B00M84FTDO/
- どのフェーズに於いても、コミニュケーションが大事と言うことですね。会話形式で書かれているので、サクッと読むことが出来ました。開発工程のslaなんて、あるんですね！勉強になります。
- ネタバレIT版バラエティー生活笑百科って感じですね。プロマネ向きの内容だけどSEやPGも読んでおいて損はないと思う。ユーザ、ベンダ、開発者それぞれの立場の視点から描かれているのが良いです。効率がガタ落ちするから設計、実装中は声かけたり会議に出席させたりすんなってのはホントにそう。エンジニアあるあるだけど、意外と分かってない人が多い。
- ネタバレシステム導入における、教科書通りのことをしておかないと、 トラブルに発生する事例が多く書いてあった。 書いてあることは理解できるが、 正直ここまで手が回るか？というところが感想である。 ただ、以下のことは意識しようと心に決めた。 ・ステアリングコミッティの確立（なかなか動いてくれないのが現状） ・プロジェクト管理の重要性を伝える。（未だプロジェクト管理費用なんて見積れるか！という人が多い） ・この本に掲載のあるチェックリストの活用。 ３回は読まないと行けないと思われる作品だ。
- Kindleで軽くざっと読み。全てが全て参考にできるわけではないが、プログラマー にとって業務理解の手助けになる。ただしただ読むだけでは「理想論」になる為、IT関連企業に就いている人は比較しながら読むのが良い。 自分の場合、この本を読んでも業務改善に繋がるようなヒントが必ず掴めるわけではないが、タメにはなりました。
- システム開発における揉め事の判例を読みたいと思い、本書を手に取ったが、物語風の軽いタッチの記述に面を食らった。判例の紹介はあるが、本書は判例の紹介がメインではなくそのサブタイトルにあるプロジェクト管理術の紹介がメインとなっている。ウォーターフォールをベースとした各開発工程毎の判例を交えつつ、揉めないための対策、プロセスを紹介している。それらの対策も腹落ち感のあるものが多く、システム開発のプロジェクト管理に携わる人は必読の書だと感じた。
- 49のシステム開発あるあるを紹介している本。読み物としては面白いんだけど、書名でもある「なぜ必ずモメるのか？」に対しての答えはない。というか、誰でも知っている銀の弾丸はないという結論で終わっている感じ。
- ネタバレ54冊目。 現場でPM経験豊富な先輩にお借りした、システム開発における判例タイムズ。 システム開発をするとき、発注側受注側双方が協力してPJを進める姿勢を取るのがめちゃめちゃ大事だなと、判例もみると理解できる。 「PJの管理工数を減らすのは愚策」というのは胸に刻もうと思います。
- 久しぶりにシステム開発に参画するかも、ということで予習復習のため読んだ。この内容、若造の頃に知りたかった（昔、ある日突然新設のシステム企画職に異動になり、当然乍ら何もできんからしばかれたことがあるので）。
- あるあるなんだけど、でだから？と拍子抜け。いや単なる教科書的なものじゃない、と最初に書いている割に判っててもできないから炎上しとんじゃい、と。勿論、本初の中出かかれている通り、銀の弾丸があるわけないのは百も承知なんですけど。あと、変に登場人物の対談＋物語風にしているのは寒すぎて、なかなか受け付けない。
- 最近の若い人向けに書かれているような気がします。対談調でわかりやすく書かれています。情報も結構詰まっていますが、私は基本的にはユーザー側がしっかりしているシステム開発は成功すると思います。ベンダーにお任せのシステム開発は押しなべて成功していません。東証などはいい例です。RFPも自分たちで書いて（大体ベンダーに任せています）、きちんとコントロールしたのでうまくいったと聞いています。最近ある銀行のシステム開発で要件定義をしっかりしないで、2年ほど延期になったということも聞いています。
- ★★★★☆ ベンダ側にしろユーザ側にしろ一度は経験したことのある、まさに「あるある」という事例が盛りだくさん。 ベンダ側から見えづらいユーザ側の事情や思い、その逆に対しても、非常に分かりやすく書かれている。 新人にも読んでほしいが、ある程度ITPJを経験した年代の方が身にしみるかもしれない。 教科書的な理想論でなく、現場の人間が直面する課題に対して、どのように対峙していけばよいか、非常に勉強になる一冊。
- 契約より実態のほうを重視したり、その逆があったりと、色々なケースがあることが分かって良かった。そして、揉めないためのポイントも記載されているので、業界人は目を通すべき。
- 一開発者だが、ためになる内容が多くあった。 ストーリー形式でするすると読めるが、要所はチェックリストや箇条書きでまとめがあり、後々プロジェクトを始動させる際にリファレンスのようにも使えそうだった。
あなたも読書メーターに登録して感想を投稿してみませんか？
なぜ、システム開発は必ずモメるのか?をシェアする
なぜ、システム開発は必ずモメるのか?の感想・レビュー75件