細川義洋のレビュー一覧

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

細川義洋

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

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

細川義洋

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

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

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

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

細川義洋

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

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

細川義洋

本書は各章でよく起こりそうな問題をストーリ仕立てで紹介しており、解決に導くにはどうしたらよいか？を考えさせる内容になっている。とはいうものの所々に「Hint」が記載されており、理解の助けとなっている。読み物としてみればなかなか面白いが、よくある一般的な管理手法等を体系的に学びたい人には不向きである。
また合間合間にチェックリストの付録があり、自分が使用しているひな形と比べる事が出来た。
開発側としてはプロジェクトスタート時には無関心でいられ、出来上がってから文句を言われるのが一番困る。システム開発はあくまでも協調作業という事がこれを読んで広まればうれしい。

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

細川義洋

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

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

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

細川義洋

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

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

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

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

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

細川義洋

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

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

細川義洋

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

2回目：印象は同じ

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

細川義洋

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

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

細川義洋

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

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

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

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

細川義洋

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

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

細川義洋

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

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

細川義洋

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

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

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

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

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

細川義洋

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

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

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

細川義洋

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

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

細川義洋

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

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

細川義洋

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

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

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

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

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

細川義洋

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

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

細川義洋

とあるシステムを市民開発することになり、PJメンバー間の認識ズレが気になっていたところに、参考にしようと手にとりました。読みやすくするためのストーリー展開に古さを感じましたが、押さえるべき要点が理解しやすく書かれていると思いました。

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

細川義洋

ストーリー仕立てで、システム導入時の注意点が学べる本。

いまだに世間ではシステム導入は博打であり、当たるも八卦、当たらぬも八卦といった風潮が見られる。

しかし実際はベンダ側にknowledgeが蓄積されつつも、肝心の導入企業側の理解が高まっておらず、いまだに下請けを扱うかのような高慢な態度でシステム導入を進める結果、失敗しているケースが多い。

本書で書かれているような、業務フローの作成方法、そもそもの業務理解、ベンダ選定やその後のリスク管理、ベンダとの連携、社内協力、情報漏洩への対処、などを理解しておけば、大きな失敗は防げるのではなかろうか。