【感想・ネタバレ】なぜ、システム開発は必ずモメるのか?のレビュー

\ レビュー投稿でポイントプレゼント / ※購入済みの作品が対象となります
レビューを書く

感情タグBEST3

Posted by ブクログ 2016年04月17日

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

0

Posted by ブクログ 2018年11月25日

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

0

Posted by ブクログ 2015年07月11日

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

0

Posted by ブクログ 2014年04月26日

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0
ネタバレ

Posted by ブクログ 2014年03月19日

システム開発のもめるポイントを主に法律的観点から見て注意点や意識することがわかる本。
システム開発の経験がない人が読んでもハテナとなるかもしれないけど、経験ある人が読んだら納得できることが多い。
そして、訴訟の時に問題になるポイントはそのまま円滑なシステム開発成功の鍵にも当然つながっていくので、法律...続きを読む的観点とはいったら、システム開発に携わる人ならぜひ読んだほうが良い本。

敏腕女性弁護士、中小ベンダ女性SE,ユーザー企業の御曹司、大手ベンダの男性PMを中心としたストーリー仕立て。
「要件定義」「プロジェクト管理」「設計」「プログラミング」「テスト」「契約終了」の章立て。
「要件定義」「プロジェクト管理」のところが個人的には興味をもった。
というか筆者がだんだん疲れてきたのか後半は登場人物のストーリー展開の割合が増えてきた気がする(それはそれで面白かったが)

0

Posted by ブクログ 2014年03月09日

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

0

Posted by ブクログ 2014年02月22日

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

0

Posted by ブクログ 2014年01月17日

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

0

Posted by ブクログ 2013年11月23日

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

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

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

0

Posted by ブクログ 2013年11月17日

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

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

0

Posted by ブクログ 2013年11月02日

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

0
ネタバレ

Posted by ブクログ 2019年10月22日

池袋のジュンク堂で気になりかなり前に買った。
キャラクターとのやり取りを通して、システム開発の難しさを学べる。理想ではあるが、分かりやすく為になる。
何箇所か絵に誤植があった。

・・・・・・
■要件定義
要件定義と契約が結びついてないと
ユーザー「自分たちの希望を全て叶えてくれるはず」
ベンダー「...続きを読む費用と期間でできるところまでやる」
って争いになり泥仕合になる
→大事なことは要件と契約書をちゃんと繋げておくこと
→でも要件は開発中に変わるから、契約書の別紙にしておいた方が良い

IT紛争って、お互いの責任分担のモレやちょっとした理解不足、確認不足が原因のものが多い

業務プロセスから業務要件におとしても
例外プロセスが抜ける可能性があるから注意
→オペレータから学ぶ

■テスト
システムの品質を守る最後の砦は、受け入れテストではなく、それに向けたテストケースやテストデータのレビューだと思ってる。
→要件定義直後とテスト直前に行う

ベンダのテストは網羅的でしっかりしてるけど、セキュリティや時間の都合で実データを使わずに行うことが多いから、想定外のデータへの漏れが見つかることがある

テスト計画書
・体制、要員
・テストに必要な資源
・使用ツールと仕様と使用法
・進捗把握方法
・開始、完了基準
・テストデータの準備
・結果の検証方法、明確、妥当
・前提条件、環境
・テスト計画に影響するような大きな設計変更がないか
・十分なロングラン、耐久テスト
・リグレッションを計画したか
・パフォーマンスを計画したか
・ストレステスト(入力量、処理量、処理時間)
・見やすさ、使いやすさ
・ユーザとベンダの役割分担、協力事項
・テストデータ・本番データの管理方法は明確か

■プロ管
→リスク管理こそプロ管で最も重要
プロジェクト管理はベンダの責任
リスクの抽出や対応策の検討らユーザがやる
→ガイドしてあげるのはベンダ

・進捗は着手と完了で管理する
→記述、コードレビュー、後修正、単体テストと修正

PMの上司の役割
→体調管理や、PMの能力を図ること
→→足りなければ新規参画者をつけたり、指導したりする
→継続的にやる
→1日一度は会話する時間を取る

破綻したプロジェクトほど、苦しいため
「この会議だけは無事におわりますように」と目先だけ考えがち
目的は、安く早くうまくやり、企業の生産性向上や、コスト低減を実現すること
→プロジェクト中、ユーザーに笑顔でいてもらうことじゃない

・ステアリングコミッティ
→双方トップの会議
→スケジュール変更、中止、再開などを決める権限を持っている

・思考の継続性
→その人しかやれない仕事はその人にやってもらう

SPI =ev/pv
→一以下なら遅延、一以上なら前倒し

ユーザーは綺麗なプログラムが欲しくて
多額の投資をするわけじゃない
システムによってもたらされる経営的なメリットを求めているのよ。

世界初のコンピュータ
→諸説あるが
→ENIAC 1946年間
→アメリカの陸軍の大砲の弾道計算のために設計された
→プログラムを組み替えることでさまざまな計算ができた

最初の自動車
→1769年にフランスで作られた
→フランス陸軍の技術大尉キュニョー
→時速約3キロしか出なかったらしい笑

外字
→元々コンピュータに登録されていない特別な文字

・錦の御旗
→戊辰戦争の際薩長軍が、自分たちこそ官軍であると示すために、朝廷に頼んで作らせてもらったものが有名。
→精神的な効果が大きく、旧幕府軍は大いに動揺したと言われる

0

Posted by ブクログ 2017年12月31日

大抵のシステム開発プロジェクトは、
上手くいったと言っていながら品質、コスト、納期の
いずれかを達成できずに終了している。

また、プロジェクトを進めていくにあたり、
問題が出ることはやむをえないことだが、
そもそもソフトウェアが無形の成果物であるため、
何が問題でどれくらい影響があるのかを説明しに...続きを読むくい。

よって、システム開発プロジェクトは、
何らかの形で揉めることが多い。

本書は、それぞれの工程における事例をベースに
まとめられており、その揉め事に対する対策案を
書いてくれているので分かりやすいし参考になった。

すべての揉め事を無くすことは難しいと思うが、
少しでも揉め事が起きないよう施策を打っていきたい。

【勉強になったこと】
・要件変更要望があった際は、
 必ずメリット・デメリットを提示すること。

・要件定義工程では、ベンダは積極的に
 ユーザの決めること、調べることを支援すること。
 ユーザは技術的な仕様まで抑えているわけではなく、
 システム要件として実現不可能な内容も要件として
 取り込まれてしまいかねない。

・優秀な管理者は、問題を早期発見し、
 上手く損切りしながら最終的に組織に利益を
 もたらす。

・プロジェクト管理の責任はベンダにあると考えて
 ユーザを支援していくこと。

・一般的に6カ月のプロジェクトで10日遅れた場合、
 メンバーの努力だけでは解消することは出来ない
 と言われている。

・品質改善とは、優秀な人の生産性向上ではなく、
 9割の普通の人でも品質改善出来るようにすること。
 全体として生産性が上がる施策を打つこと。

・プロジェクト管理費用や要件変更に必要な費用は、
 プロジェクト全体の2~3割必要。
 ここは値引きしてはいけない部分。

0

Posted by ブクログ 2020年12月30日

興味本位で買ってみたけど登場人物の会話で展開していくのでとても読みやすくて良かった!!!

自分は要件定義、プロジェクト管理、契約関連、プロマネが行うことなどは、「言われてみれば行ってたかもれないけどあまり意識してなかった」ことばかりでためになった。

CASE44での彩音と一郎の会話の中の、
一郎...続きを読む「自分の管理で人より早く危険を発見したり、その対策が奏功してプロジェクトが成功するのは傍目で見るより面白く達成感もある」
の言葉が、いいね(^◇^)
希望が湧く。笑

-------------------------------
・定期的に要件変更に関する会議を開く
・実際の業務に当てはめてのシュミレーション、他の接続システムの担当者との確認などをしてくださいと促すのも仕事
・本当に今やらなきゃいけないこととそうでないことを色分けして前者だけを決めれば要件定義工程は完了
・プロジェクト管理の価値をユーザに認めてもらう
・プロマネの上司はプロマネの心身と健康に気を遣う
・ユーザーの意欲を維持するために会議で催し物を実施する
・ユーザーや上司の顔色を見ながら「頑張ります」はその場しのぎでしかない
・開発順はプログラミング視点からだけではなく業務上必要な機能や使用頻度も考慮して決める
・トラブル改修の順序は損得を計算してから
・組織的な品質改善の仕組み向上は、「優秀な人」ではなく「普通の人」の生産性をあげるため
・テストケースレビューは要件定義後とテスト直前とで2度行うとよい
・プロマネは言葉を鵜のみにせず周囲の状況や気持ちを察する
・プロマネはメンバの前でも身なりに気を遣う(くたびれてるように見えないように)

0
ネタバレ

Posted by ブクログ 2015年05月27日

良書です。会話形式で、システム開発の課題、解決策、判例について解説されています。
自身で学ぶためにも良いと思いますが、誰かに教えるための参考書としても、使える本です。
(登場人物同士のやりとりで無駄な内容もあります。そこだけ残念かも。)

0

Posted by ブクログ 2014年11月14日

早々に入手していたのに、時間がなくてなかなか読めなかった。
これまでシステム開発で遭遇したトラブルやトラブル手前と似た事例がたくさん取り上げられており、非常に臨場感がある。
また、実際の裁判の判例等も取り上げて、リアルと言う意味で深みがある。
少しソフトなストーリー仕立てにしているのは、賛否が...続きを読むあるところだと思うが、内容が非常に良いものなので、個人的にはもう少し固い論調で書いてくれた方が良かったかなとも思う。
(なので☆マイナス1なんだけど本心は5点)

2回目:印象は同じ

0

Posted by ブクログ 2014年03月05日

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

0

Posted by ブクログ 2014年02月02日

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

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

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

0

Posted by ブクログ 2013年12月31日

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

0

Posted by ブクログ 2013年12月27日

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

0

Posted by ブクログ 2013年12月22日

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

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

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

今後の...続きを読む良い参考にさせてもらいます。

0

Posted by ブクログ 2013年12月10日

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

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

0

Posted by ブクログ 2018年04月07日

裁判での判決をもとに、トラブルになる前に対応すべき事例が記載されている。49の事例があるがそれぞれ独立しているため、読みやすい一方で繋がりがないといった印象。

0

Posted by ブクログ 2016年01月11日

システム開発現場のあるある。プロジェクトの揉めるポイントについて原因と対策をまとめている。具体的なストーリー仕立てになっており読み物としても面白い。

0

Posted by ブクログ 2014年11月08日

⑴この本を手にとった理由
タイトルどおり、なぜもめるのか、が知りたかったからです。
⑵感想
とっつきやすすぎて、伝えたいメッセージが教科書すぎてつまらなかった。
⑶こういう人におすすめ
システム開発の受注・発注にまったく関わったことがない人には良いのではないでしょうか。

0

Posted by ブクログ 2014年09月23日

勤務先でいきなりソフト開発を命じられたので泥縄的に読んでみた。
漫才会話調でシステム開発の裁判事例を紐解く話。自分でツッコミをいれているが、そんなにうまいこと行くわけない、という話が散りばめられている。以外にも分かりやすかった。類書を一冊も読んだことがなければ楽しめると思う。

0

Posted by ブクログ 2020年07月27日

もしドラ風で読みにくい。◆言っていることは至極真っ当だが、これだけリスクヘッジをしていたら、コストは鰻上りだな。小回りが利かないしな…

0

「IT・コンピュータ」ランキング