投稿元：
レビューを見る
個人的には微妙でした
例に使われている開発の話が古くピンと来ませんでした
わざわざ読む必要は無いかなと思います
投稿元：
レビューを見る
ソフトウェア開発の仕事をしている身としてかなり気になるタイトルなので購入して読んでみた。
企画から設計、リリース後まで様々な失敗事例が書かれてあって、とてもいい。
「あるある！」と非常に共感できるものから、自分は経験ないけど気を付けたいと思うものまで、非常に充実した本だった。
最初のコンセプトはシンプルだったのに、いつの間にか複雑になっているというのは、まさに今かかわっているプロジェクトがそうだなと…。失敗しないようにしていきたい。
ソフトウェア技術者は何でも屋というのは、確かに言われてみればそうだよなと思う。コードの実装だけでなく、要件定義したりテストしたり運用・保守があったり…。そう考えると、大変な仕事だよなと思う(ちょっと大きい規模になるとついていけない時がある)。
コミュニケーションが不足するというのは失敗として大きい要因なのだろうなと思った。曖昧なことをいうと伝わらないし、逆に曖昧なことを言われたら推測で判断しなほうがいいのだろうなと。コミュ力ない自分だけど、こういうところ気を付けていきたい。
後は、やっぱり設計力がないと失敗しやすいのだろうなと。設計力はないので、今後身に着けていけるようになりたい。
心理的安全性確保のために、リーダーが先にダメなところを見せるというのは、とてもいいと思った。進捗管理を聞くのに、リーダーが「自分のタスクが進んでなくて…」というと、メンバーも正直に伝えてくれるとのこと。このテクニックは覚えておきたい。
チームの雰囲気をよくするために、会議におやつを持ち込むというのはいい案だよなと思う。ただ、去年入った新人が、ドクターストップかけられいてお菓子を食べれないようで、うちのチームでやるのはなかなか難しいかもしれない(誰かがお菓子を配っていても、その子はいつも断っている)
操作ログが可能なかぎり取得するのがいいというのはわかるのだけど、どこまでログをとるかの基準が難しいとは思う。ログをとる基準って調べてもなかなかでてこないのだけど、ベストプラクティスとかないものなんだろうか…。
後、解析しやすいようにログを取得しないといけないけど、何も考えずに出力しちゃうと読みづらいと怒られるたり…。いいログ出力の方法について、具体例も交えて解説した本とかあれば読んでみたい。
失敗したプロジェクトの振り返りを行うと、「自分の能力不足」という結論になってしまうというのは、すごくよく分かる。ソフトウェア開発で失敗した原因を探ろうとすると、たいてい原因が人にいきついてしまうよう。誰かが悪いといっても何も解決しないわけだし、この本に記載のとおりプロセスに着目して、改善策を検討していくようにしたい。
そういえば、各節にある四コマ漫画も面白くて、誰が描いているのだろうと思って最後のページを見たら、「イラスト・漫画：出石聡史」とあって驚いた。文章だけでなく、漫画も作者が書いてるのか…。すごい。
投稿元：
レビューを見る
ある程度経験のあるソフトウェアエンジニアにとって「あるある」という失敗とどうすればよかっただろう？という学びをまとめた本。各エピソードは架空のプロジェクト進行に基づいて書かれていて、順に読み進めていくことで、実際のプロジェクトのどの段階で発生しがちな問題なのか、というイメージをしやすい。最初に書いた通り「あるある」集であり、新しい知識を獲得できたか？という点では少し期待外れだった。ただ「あるある」を"まとめてみた"というのが本書の価値であり、まとまった情報というのはそれだけでありがたいものである。成功は再現できないが失敗は再現できるので。
投稿元：
レビューを見る
自分はインフラエンジニアですが、普段ソフトウェアエンジニアってどんな仕事してるんだろうと気になり読みました。リアリティ溢れる記載で面白く、一気に読めました。
投稿元：
レビューを見る
「あるある」と頷きながら読める事例や、思わず背筋がコオルような事例など、ソフトウェア開発のプロセスごとの失敗事例と回避策が紹介されている
今後リーダーとしてプロジェクトを回していくときには、コミュニケーションと品質を優先することが大事なのだなと学べた
投稿元：
レビューを見る
タイトルの通り失敗事例集。想定の舞台が、よくある受注型大規模SIではなく、自社開発のロボットアームFWと周辺ツール開発、ということで、わりと今の業務に近く親近感を感じる。中身はよくある感じだが、実際、今の職場で、この本にかかれているようなことは、ほとんどのことが生じている。アタマの良い人達、とくにローテーションで降ってくる管理職の人たちは、なんでも自分たちで考えようとするのか、こういった、本に何度も書かれている典型例でさえも、ゼロから経験しようとしていく。ちょっと本を読めば、先回りして回避できるようなことでも。進捗会議でアレコレ議論するのではなく、(本書に限らず)読書会でもしたほうがいいような気がするが。
投稿元：
レビューを見る
かなり、あるあると思って読んだ。仕様をどのように作るか、人に伝えるか、その難しさを失敗例を元に解説し、対処方法が短くまとめられている。要件定義はソフトだけに限らず難しいこと。1,2章だけでも知っておく価値があると思い、若手に勧めてます。
投稿元：
レビューを見る
タイトル通りの本。
ソフトウェア開発に関わったことはないので想像。
開発に複数人チームで挑む、あるいはまたは、ある部分が終わらないと絶対に次に進めないのが特徴といっていいのかな。
メーカー的な開発も「やり始めないと工数の見積もりが難しい」「後半になってはじめて課題に気づく」は同じなのに、なぜプロジェクトマネジメントの流儀が広く普及してるのか考えてみた。
部署単位で仕事することが多いメーカーと違って、プロジェクトごとのアサインなのでプロジェクトごとに人が動く、プロジェクトの区切りがはっきりしてることなのかと思った。
日頃よりプロジェクトマネジメントの作法がある分、工数管理自体のノウハウもたまっていく、ということかと。
投稿元：
レビューを見る
経験のあることばかりでグサグサ刺さる。
その都度身を削るなり努力と根性で乗り切ったりしてきたが、それで成長してきたのも事実。
良かれと思い手助けすること、ピンチで代わりに対応すること、わき道にそれたものをすべて引き取って片付けてしまうことなど、結果として経験値泥棒してたのかな。
全部入りソフトウェア、ふんわり仕様、ノンポリ、聞くだけ進捗会議、時間泥棒、増殖する会議、カイゼンマニア。
「仕様は間違いなく、間違って伝わっている」面倒だけど併用が一番の解決、とはいえ仕様書がないのはもっとダメ。
250冊目読了。
投稿元：
レビューを見る
ソフトウエア開発現場の失敗事例集。
どれもあるあるで、忙しくなると忘れがちになりそうなものばかり。
特に新人リーダーに読んで欲しい。
投稿元：
レビューを見る
ソフトウェア開発における「しくじり先生」みたい？な本。
失敗事例は共感するところがとても多く、「あったなぁ、こういう失敗」と過去を振り返りながら、楽しく読み進められました。特に、最近はあまり聞かなくなったメモリ管理に関しては、現役エンジニア時代に散々苦労した思い出が多いので、辛い記憶がフラッシュバックしてくる気すらします(笑)
ただ失敗談を集めただけでなく、「どうすれば失敗を回避できそうか」にも言及されていて、勉強になる点も多いです。その中でも、リリース後の対応はIT系ビジネス本ではあまり読んだことがなかったので、印象に残りました。
表紙に「やらかしたくないエンジニア必読」とありますが、本書で書かれている失敗の回避策の実現にはチームのマネージャーや、ゲーム開発なら企画職の人などの協力も必要なので、エンジニアと一緒に仕事をする人たちにも読んでほしいと思いました。
投稿元：
レビューを見る
ありきたりな成功体験ではなく、生々しい失敗経験を知りたくて読了。技術が進歩しても、システム開発は難しい分野であると再確認できた。システム開発プロジェクトのメンバー全員と輪読会してみたい。
まず目次が秀逸。全員一人前計画、文学的仕様書、動けばいいじゃん症候群など、共感できるけど笑えないタイトルが良い。銀の弾丸は無いものの、失敗事例を知っているだけでもプロジェクト的にはプラスだと思う。
投稿元：
レビューを見る
以下に詳細を記載。
https://qiita.com/teddy0801/items/66fb5b15b4ed9bc356ec
投稿元：
レビューを見る
システム開発時の悲哀がとてもよくわかる内容でした。一読するとどのポイントでエラーが生じやすいかなどをうまく説明しているので、クライアントとしてもシステム開発の大変さに共感しやすくなりますし、厳しく締めるところもわかるので、システム開発業者と上手く付き合っていく参考書になるかもしれませんね。
投稿元：
レビューを見る
なんだか見たことあるなぁという事例がたくさん。
オレゴン大学の実験など、ステークホルダーは各々理解がことなるため、結果顧客の欲しかったソフトウェアは出来上がらないなどはお馴染みですよね。
如何にして顧客が本当に解決したい課題を仕様に落とすかが大事だなと。
------------------------------------
以下メモ
- WBSも成果物からブレイクダウンしていきましょう
- OS変化のリスクに備え、メンテナンス体制を整えておく
- メンバーの成熟度も加味した上でスケジュールを構築す るべき
- 用語集を作成しよう
- 仕様は正確に伝わっていないという前提を持ち、コミュニケーションの機会を増やす
- 設計書に設計思想を記載する
- 進捗会議では課題を見つけることにフォーカスし、早期発見に価値を置く
- おやつ等を活用し、会話しやすい雰囲気作りを仕掛ける
- 根本原因に対して包括的な施策を打つ
- 施策の効果を計測し、定期的に見直す
- 要件定義の段階で顧客の利用シーンをもとに非機能要件をリストアップし、それぞれ目標値を設定しておく
- 製品計画に出荷後の運用計画と予算を組み込む
- 継続して運用時の費用を賄えるビジネスモデルを検討する
