細川義洋のレビュー一覧

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

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

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

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

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

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

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

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

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

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

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

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

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

システムを「外注」するときに読む本

システムの発注者側としての注意すべき要点について、網羅的ではないが有用な視点が書かれている。

良い点として、小説仕立てで取っつきやすいという点と、あまり他のこの手の本では書かないようなリスク管理の考え方の話が参考になりそう。

登場人物のITコンサルの女性が現実離れしたキャラクター設定なのはアレだが(20代の設定には無理がある、あとクライアントにこんな失礼な態度取る奴は普通いない)

フィーリングマップはこの本で初めて知った手法だが、キャッチーで面白そうだと思った。実務で使ってみたい。

プロジェクトの失敗はだれのせい？ ～紛争解決特別法務室“トッポ―”中林麻衣の事件簿

まさに今、初めてシステムをベンダーに依頼して作っているところ。
勉強のために読んでみようと手に。
色々なケースをストーリーで読めたので素人でも分かりやすい。
そのストーリーも王道の勧善懲悪でなかなか面白かった。そちらは期待していなかった分、得した気分。
難しい指南書よりもよっぽど勉強になる。

システムは今月完成予定。
本書を参考にするとこちらにもベンダーにも問題があったかと。
次回発注の際、同じことにならないようにしなくては。　　

さらに、マネージャーとは？も考えさせられる。
特にp228229

システムを「外注」するときに読む本

基本的なことで、頭ではわかっていることが中心。
ただ、実際は工数の関係やコミニュケーション不足で、できてないことも多い。
発注者、ベンダーで立ち位置は異なっても、プロジェクトを成功させるために、お互い意見を交換して、進めていくことが大切。

システムを「外注」するときに読む本

Appendixに価値がある。発注者の役割や要件定義のチェックリスト、プロジェクト計画書に盛り込むべき項目に、リスクを洗い出すときのチェックリスト等。

全体的に外注する場合の注意点として、主にリスク管理に重点を置かれている。特に、発注者側のベンダの内部に潜むリスクへの対応の仕方やスタンスは参考にする価値あり。

ただ、ストーリーはやや冗長でコスパは若干悪い。

システムを「外注」するときに読む本

例題部分は読み物として物足りなさはあったけど、実用書としては私に土地勘もないので手ごろに役立ちそう。しかしまあシステム関係が地獄になりがちなのはこういう原因があるからなのね。

プロジェクトの失敗はだれのせい？ ～紛争解決特別法務室“トッポ―”中林麻衣の事件簿

本や各話のタイトルから勝手に早とちりしていたのだけれども、
ITプロジェクト関係の法律やノウハウを、ストーリーを楽しみながら学べる本かと思っていたけど、
勧善懲悪のストーリーがメインで、上記のような知識はほんとおまけ程度のでしかなかった。
とは言え、IT屋さんがお客さんと向き合うときの『姿勢』や『心意気』に関しては、結構ぐっと来るものがあった。

また、ストーリー自体はそこそこ楽しめた。

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

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

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

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

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

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

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

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

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

2回目：印象は同じ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと

社内の業務をIT化したいとか社内にシステムを導入したいとなった時、ベンダーに何をどう依頼すればいいのか、発注側の心構えとか発注側が何をしなければならなくて何を知っていなければいけないが理解出来る本。ストーリー仕立てなのでサクッと読める。

エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと

フローや用件定義の書き方などがどういった役割のものなのか？そしてどんなふうに書くのかが分かりやすく物語で書かれている本。ベンダーとのトラブルになりやすい点などもうまく表現されていると感じました。

エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと

私は前職がIT関係の会社だったこともあり、今の会社では一応IT担当者のような役割を担っているのだが、働き方改革における業務の効率化や人材不足への対応、台頭するAIの活用なども含めて、今後自分の会社でも大規模なIT改革が必要であろうということを鑑みて、IT担当者とはいうものの実際のシステム開発におけるプロジェクト管理などにはまったく精通していない自信があったのでネットで検索して目についたこの本を読んでみた。

小説仕立てになっており、会社のシステム開発にITの知識がまったくない若手社員が携わって、発生したトラブルから様々な示唆を得るというものだ。小説風なので非常に読みやすく、1日で読んでしまった。

ただ、想定されるシステムの規模があまりにも大きすぎて、私のような田舎の中小企業に務める人間としては、自分事として捉えるにはちょっと難しかった。確かにシステムの規模に限らず、プロジェクトの本質は大きく変わるものではないだろう。事実、発注側はベンダーに丸投げではダメ、自分たちもプロジェクトメンバーで、一緒にシステムを作り上げていくことが大事、というのは本当にそう思う。自分の会社もシステムユーザー層は、忙しいのかなんなのか知らんが、開発中には何も言わないくせに出来上がったものを見て、思ってたのと違うとか使いづらいとか平気で言うから困ったもんだよね。そういう人たちにこそこの本を読んで、システムが出来上がっていく過程を学んでほしい。

今は特に大きなシステムの刷新を予定しているわけではないので、ただただストーリーの先が気になって一気に読んでしまったが、近い将来システム更新を実施する際はもう一度読み返してみたいと思う。

エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと

システム開発への取り組み方をストーリーから学ぶことができる。ベンダーに任せきりではなく、ユーザーからの主体的な行動や働きかけも必要と理解した。