ソフトウェア開発現場の「失敗」集めてみた。 の商品レビュー

出石聡史(著者)

2025/12/06

これを読んで、現場のリアルな悩み、そして解決策の方針が見えそう？だと思いました。

まず、めちゃくちゃ読みやすい。

「企画、仕様、設計・実装、進捗管理」などで、それぞれチャプターが分かれていて、そこからさらにエピソードという章になっている。
そしてこのエピソードがとても分かりやすい。

エンジニアが書く本なだけあって、理解しやすい＆具体的な解決策 で実用に特化している。

このような本こそ自分の知識の索引に入れておいて、また取り出して読みたいと思った。
とはいえ、実際にぶつからないとこの手の本の有用性はわからない、というところで星4。

- チームを壊されないように社内政治に関心を持つ
- 設計書に想いを書くことで、変更によるアーキテクチャ崩れを防ぐ
- 会議スタート5分前に場を温めるエンターテイナー性
- リーダーから隙を見せて、部下に手伝ってもらう、巻き込む
- 心理的安全性がないと隠される
- 不機嫌なチームが離職を高める、コンウェイの法則しかり、関係性は大事
- チート技「おやつ」、空気が和らぐ。食べることは安全の証

2025/07/29

こんな失敗あるある、だった。
その中でも、失敗してかつ対処法がわからなかった事例については解決法が勉強になった。
まだ出くわしてない&出くわすことないかな〜と思ってピンとこなかった失敗例も、今後の人生でもし出くわしたらもう一度読もうと思う。

2025/07/15

現場で働いていて、リーダーはこんなにも板挟みというか考えなければならないことばかりなのかと思った
平メンバーでも把握しておくと将来役に立つかもしれない

2025/07/08

システムエンジニアとしてどんな問題があるのだろうと気になり買ってみました。
最初の方は自分の会社はすでに対策されているようなことが多く、自分の会社すげーって思ってました。
後半は自分の会社でも起こりうるトラブルも多かったため、とても参考になりました。
またバグは全て治すべきでない。はとても興味深かったです。ビジネスマンとして限られた時間とコストを見極めて仕事をするという姿勢はとてもいいなと思いました。確かにいい物を作りたいという気持ちはあるが、果たして成果に見合った報酬はあるのかなどビジネスにおいては考えることが色々あるのだなと感じました。

2025/05/27

「ソフトウェア開発現場の失敗集めてみた。」
抱きしめて眠りたいレベルに面白かったな、、、

経験不足で「進捗管理」以外の章はピンと来てなかったけど、経験者からしたらあるある話であれば、事前に業務イメージを持っておきたいエンジニアにとって最高の良書。
この話がピンと来るように私も勉強したいな。

私の経験でいうと「進捗管理で失敗」の章が一番面白いし、頷くポイント多し。
・アクションしない「聞くだけ進捗会議」
・会議が会議を呼ぶ「増殖する会議」
・また責められる「怖い会議」
タイトルだけでワクワク（ゾクゾク）する！

巻末にプロジェクト憲章とかあって最高！

お気に入りポイントやアクション
・進捗会議で課題を見つけようとしていない
　→進捗会議では課題を見つけることにフォーカスし、早期発見に価値を置く
　チーム全体の進捗報告で一人一人自由に報告するけど、単に状況を伝えるではなく課題があれば積極的に報告することにフォーカスしようかな？
・課題の発見を喜ぶ
・チート技「おやつ」、お茶会で筆者はご機嫌なチームを作った
職場での実践は難しいけど、プライベートの活動では使える話かも。職場でもできる可能性はあるので、アイデアとして持っておくのは良し。
・会議5分前のエンターテイナー
→会議が始まる前、楽しい話題を振って話しやすい雰囲気を作る
これも職場での実践はハードル高いけど、プライベートのMTGなどで使いたいテクニック

2025/05/06

なんだか見たことあるなぁという事例がたくさん。
オレゴン大学の実験など、ステークホルダーは各々理解がことなるため、結果顧客の欲しかったソフトウェアは出来上がらないなどはお馴染みですよね。

如何にして顧客が本当に解決したい課題を仕様に落とすかが大事だなと。
------------------------------------
以下メモ

- WBSも成果物からブレイクダウンしていきましょう
- OS変化のリスクに備え、メンテナンス体制を整えておく
- メンバーの成熟度も加味した上でスケジュールを構築す るべき
- 用語集を作成しよう
- 仕様は正確に伝わっていないという前提を持ち、コミュニケーションの機会を増やす
- 設計書に設計思想を記載する
- 進捗会議では課題を見つけることにフォーカスし、早期発見に価値を置く
- おやつ等を活用し、会話しやすい雰囲気作りを仕掛ける
- 根本原因に対して包括的な施策を打つ
- 施策の効果を計測し、定期的に見直す
- 要件定義の段階で顧客の利用シーンをもとに非機能要件をリストアップし、それぞれ目標値を設定しておく
- 製品計画に出荷後の運用計画と予算を組み込む
- 継続して運用時の費用を賄えるビジネスモデルを検討する

2025/02/02

システム開発時の悲哀がとてもよくわかる内容でした。一読するとどのポイントでエラーが生じやすいかなどをうまく説明しているので、クライアントとしてもシステム開発の大変さに共感しやすくなりますし、厳しく締めるところもわかるので、システム開発業者と上手く付き合っていく参考書になるかもしれませんね。

2025/01/02

以下に詳細を記載。
https://qiita.com/teddy0801/items/66fb5b15b4ed9bc356ec

2024/12/25

ありきたりな成功体験ではなく、生々しい失敗経験を知りたくて読了。技術が進歩しても、システム開発は難しい分野であると再確認できた。システム開発プロジェクトのメンバー全員と輪読会してみたい。

まず目次が秀逸。全員一人前計画、文学的仕様書、動けばいいじゃん症候群など、共感できるけど笑えないタイトルが良い。銀の弾丸は無いものの、失敗事例を知っているだけでもプロジェクト的にはプラスだと思う。

2024/12/21

ソフトウェア開発における「しくじり先生」みたい？な本。

失敗事例は共感するところがとても多く、「あったなぁ、こういう失敗」と過去を振り返りながら、楽しく読み進められました。特に、最近はあまり聞かなくなったメモリ管理に関しては、現役エンジニア時代に散々苦労した思い出が多いので、辛い記憶がフラッシュバックしてくる気すらします(笑)

ただ失敗談を集めただけでなく、「どうすれば失敗を回避できそうか」にも言及されていて、勉強になる点も多いです。その中でも、リリース後の対応はIT系ビジネス本ではあまり読んだことがなかったので、印象に残りました。

表紙に「やらかしたくないエンジニア必読」とありますが、本書で書かれている失敗の回避策の実現にはチームのマネージャーや、ゲーム開発なら企画職の人などの協力も必要なので、エンジニアと一緒に仕事をする人たちにも読んでほしいと思いました。