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

出石聡史(著者)

2024/11/03

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

2024/10/28

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

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

2024/10/23

タイトル通りの本。

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

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

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

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

2024/10/23

タイトルの通り、失敗のパターンを並べた本。
ほとんどの内容がちゃんとアジャイル的に開発すれば解決改善できるような気がするので、アジャイル開発を学ぶ際に補完的に読むと良いのかも。

2024/10/09

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

2024/08/31

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

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

2024/08/26

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

2024/06/23

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

2024/06/22

ソフトウェア開発の仕事をしている身としてかなり気になるタイトルなので購入して読んでみた。

企画から設計、リリース後まで様々な失敗事例が書かれてあって、とてもいい。
「あるある！」と非常に共感できるものから、自分は経験ないけど気を付けたいと思うものまで、非常に充実した本だった。

最初のコンセプトはシンプルだったのに、いつの間にか複雑になっているというのは、まさに今かかわっているプロジェクトがそうだなと…。失敗しないようにしていきたい。

ソフトウェア技術者は何でも屋というのは、確かに言われてみればそうだよなと思う。コードの実装だけでなく、要件定義したりテストしたり運用・保守があったり…。そう考えると、大変な仕事だよなと思う(ちょっと大きい規模になるとついていけない時がある)。

コミュニケーションが不足するというのは失敗として大きい要因なのだろうなと思った。曖昧なことをいうと伝わらないし、逆に曖昧なことを言われたら推測で判断しなほうがいいのだろうなと。コミュ力ない自分だけど、こういうところ気を付けていきたい。

後は、やっぱり設計力がないと失敗しやすいのだろうなと。設計力はないので、今後身に着けていけるようになりたい。

心理的安全性確保のために、リーダーが先にダメなところを見せるというのは、とてもいいと思った。進捗管理を聞くのに、リーダーが「自分のタスクが進んでなくて…」というと、メンバーも正直に伝えてくれるとのこと。このテクニックは覚えておきたい。

チームの雰囲気をよくするために、会議におやつを持ち込むというのはいい案だよなと思う。ただ、去年入った新人が、ドクターストップかけられいてお菓子を食べれないようで、うちのチームでやるのはなかなか難しいかもしれない(誰かがお菓子を配っていても、その子はいつも断っている)

操作ログが可能なかぎり取得するのがいいというのはわかるのだけど、どこまでログをとるかの基準が難しいとは思う。ログをとる基準って調べてもなかなかでてこないのだけど、ベストプラクティスとかないものなんだろうか…。
後、解析しやすいようにログを取得しないといけないけど、何も考えずに出力しちゃうと読みづらいと怒られるたり…。いいログ出力の方法について、具体例も交えて解説した本とかあれば読んでみたい。

失敗したプロジェクトの振り返りを行うと、「自分の能力不足」という結論になってしまうというのは、すごくよく分かる。ソフトウェア開発で失敗した原因を探ろうとすると、たいてい原因が人にいきついてしまうよう。誰かが悪いといっても何も解決しないわけだし、この本に記載のとおりプロセスに着目して、改善策を検討していくようにしたい。

そういえば、各節にある四コマ漫画も面白くて、誰が描いているのだろうと思って最後のページを見たら、「イラスト・漫画：出石聡史」とあって驚いた。文章だけでなく、漫画も作者が書いてるのか…。すごい。

2024/08/11

個人的には微妙でした
例に使われている開発の話が古くピンと来ませんでした
わざわざ読む必要は無いかなと思います