【感想・ネタバレ】ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかたのレビュー

出石聡史

やらかしたくないエンジニアに贈る「失敗の教科書」!
失敗事例で学ぶ、よくある落とし穴の回避策

ソフトウェア開発は、どんなときも順調に進むとは限りません。チームで開発を進めるエンジニアたちは、開発の足を止める「落とし穴」の数々と向き合わなければなりません。

「いつのまにか機能が肥大化していて、手がつけられなくなった…」
「仕様がまったく共有されていないまま、開発が進んでいた…」
「ちょっとしたコード変更が一日分の工数を奪った…」
本書は、このような落とし穴にハマってしまった開発現場の「失敗エピソード」を面白おかしく紹介する、失敗事例集です。事例は架空の開発現場を舞台にしたフィクションですが、著者自らが体験した経験をベースに構成しているので、臨場感たっぷり。読んでいるだけで冷や汗が浮かびます。

また、失敗につながる落とし穴を回避したり、抜け出すための方法も解説しています。新しく開発チームを率いることになった新任リーダーや、チームで開発に取り組むエンジニアが、失敗に直面した際にどのようなアクションを起こせばよいか、現場で役立つ具体策がわかります。

エピソードは「企画」「要件定義」「実装」「品質管理」といった開発の工程別に42篇を収録。各エピソードの冒頭には、4コマ漫画を掲載しているので、楽しく読み進められます。

【収録エピソード（一部抜粋）】
●機能がてんこ盛りで実装が間に合わない「全部入りソフトウェア」
●お願いされた機能を断れない「八方美人仕様」
●ユーザーを迷わす自分ルールのUI「オレオレ表記」
●カタログだけで判断する「スペック厨導入」
●行間を読ませる「文学的仕様書」
●リリース版が復元できない「不完全リポジトリ」
●つい自分でやってしまう「経験値泥棒」
●修正が新たなバグを生む「バグ無間地獄」
●アクションしない「聞くだけ進捗会議」
●施策を打ち続ける「カイゼンマニア」
など全42篇！

【目次】
Chapter1 「企画」で失敗
Chapter2 「仕様」で失敗
Chapter3 「設計・実装」で失敗
Chapter4 「進捗管理」で失敗
Chapter5 「品質管理」で失敗
Chapter6 「リリース後」に失敗

※本電子書籍は同名出版物を底本として作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。

[ブクログ · ★★★★★]

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

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

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

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

[ブクログ · ★★★★★]

かなり、あるあると思って読んだ。仕様をどのように作るか、人に伝えるか、その難しさを失敗例を元に解説し、対処方法が短くまとめられている。要件定義はソフトだけに限らず難しいこと。1,2章だけでも知っておく価値があると思い、若手に勧めてます。

[ブクログ · ★★★★★]

ソフトウエア開発現場の失敗事例集。
どれもあるあるで、忙しくなると忘れがちになりそうなものばかり。

特に新人リーダーに読んで欲しい。

[ブクログ · ★★★★★]

自分はインフラエンジニアですが、普段ソフトウェアエンジニアってどんな仕事してるんだろうと気になり読みました。リアリティ溢れる記載で面白く、一気に読めました。

[ブクログ · ★★★★☆]

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

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

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

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

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

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

[ブクログ · ★★★★☆]

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

[ブクログ · ★★★★☆]

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

[ブクログ · ★★★★☆]

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

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

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

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

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

[ブクログ · ★★★★☆]

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

[ブクログ · ★★★★☆]

「あるある」と頷きながら読める事例や、思わず背筋がコオルような事例など、ソフトウェア開発のプロセスごとの失敗事例と回避策が紹介されている

今後リーダーとしてプロジェクトを回していくときには、コミュニケーションと品質を優先することが大事なのだなと学べた

[ブクログ · ★★★☆☆]

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

[ブクログ · ★★★☆☆]

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

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

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

[ブクログ · ★★★☆☆]

タイトル通りの本。

ソフトウェア開発に関わったことはないので想像。
開発に複数人チームで挑む、あるいはまたは、ある部分が終わらないと絶対に次に進めないのが特徴といっていいのかな。

メーカー的な開発も「やり始めないと工数の見積もりが難しい」「後半になってはじめて課題に気づく」は同じなのに、なぜプロジェクトマネジメントの流儀が広く普及してるのか考えてみた。

部署単位で仕事することが多いメーカーと違って、プロジェクトごとのアサインなのでプロジェクトごとに人が動く、プロジェクトの区切りがはっきりしてることなのかと思った。

日頃よりプロジェクトマネジメントの作法がある分、工数管理自体のノウハウもたまっていく、ということかと。

[ブクログ · ★★★☆☆]

タイトルの通り失敗事例集。想定の舞台が、よくある受注型大規模SIではなく、自社開発のロボットアームFWと周辺ツール開発、ということで、わりと今の業務に近く親近感を感じる。中身はよくある感じだが、実際、今の職場で、この本にかかれているようなことは、ほとんどのことが生じている。アタマの良い人達、とくにローテーションで降ってくる管理職の人たちは、なんでも自分たちで考えようとするのか、こういった、本に何度も書かれている典型例でさえも、ゼロから経験しようとしていく。ちょっと本を読めば、先回りして回避できるようなことでも。進捗会議でアレコレ議論するのではなく、(本書に限らず)読書会でもしたほうがいいような気がするが。

[ブクログ · ★★★☆☆]

ある程度経験のあるソフトウェアエンジニアにとって「あるある」という失敗とどうすればよかっただろう？という学びをまとめた本。各エピソードは架空のプロジェクト進行に基づいて書かれていて、順に読み進めていくことで、実際のプロジェクトのどの段階で発生しがちな問題なのか、というイメージをしやすい。最初に書いた通り「あるある」集であり、新しい知識を獲得できたか？という点では少し期待外れだった。ただ「あるある」を"まとめてみた"というのが本書の価値であり、まとまった情報というのはそれだけでありがたいものである。成功は再現できないが失敗は再現できるので。