ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた

  • 翔泳社 (2024年6月12日発売)
本で見る
3.58
  • (8)
  • (9)
  • (15)
  • (4)
  • (0)
本棚登録 : 298
感想 : 27

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

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

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

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

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

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

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

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

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

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

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

読書状況:読み終わった 公開設定:公開
カテゴリ: 新品を購入
感想投稿日 : 2024年6月22日
読了日 : 2024年6月22日
本棚登録日 : 2024年6月22日

みんなの感想をみる

コメント 0件

ツイートする