エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

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

書籍情報

きっかけ

翔泳社のセール対象の一覧を見ていて、目に入ったので読んだ。
特に、これを知りたいみたいな感覚はなく、娯楽的な要素を求めて読んだ。

印象に残ったポイント

  • カイゼンカイゼンを呼び、施策だらけ。
    根本原因が特定できてない可能性がある。
    施策効果を測定できていない

    • トヨタ信仰が強いんだよな、ソフトウェア開発の現場って。
    • 個人的には猿真似してるだけで、ちゃんとしたカイゼンができているケースはそんなにないイメージがある。
  • 三者評価で想定以上のバグ
    開発者は無意識にバグを避ける。

    • 視点が開発者とユーザで違ってるのが、原因としてある。想定してなかった動きで発生することがおおい。
  • ゼロバグ出荷

    • 運用回避可能なら対応の優先度考えて対応でも可だとは思う。
  • ステルス修正

    • 俺はステルスアップデートと呼んでいた。基盤チームがライブラリを勝手に直したせいで、ビルドエラーが大量に発生するようになったときは、キレそうだった。。。
    • やっぱり、ステルス〇〇って呼びたくなるんだよなぁ。。。
  • リリース後に失敗

    • リリースは終わりじゃなくてスタートだからな。。。
    • 「俺達の戦いはこれからだ」ってタイミングがリリース。結局、リリース後も残れるのは、主要メンバーか中核にいた人何だよなぁ。チームが解散するのは、ガチでやばい。
  • ノーログ戦法

    • 保守する側としては最悪。自分は、最近保守対応がメインだが、事象だけってのが多くて、ソースと再現方法をにらめっこして解決していることが多い。
    • 再現方法を確立させるためにも必須。ただ、どんなログが必要なのか考えるのは、かなり面倒。
  • なぜなぜ分析の恐怖
    原因が人に行きがち。 人は間違えるものという前提が必要。プロセスの問題点を見つける。

    • 振り返り会は、基本的に参加したくないんだよなぁ。。。
    • 人に原因行きやすいってのは、よく分かる。俺が若い頃は、よく俺のせいにされた記憶が。。。
    • 自分のせいにされないためにも、知識が必要だと思ってる。じゃないと、誘導されちまうからな。ちゃんとした知識があれば、相手の意見に反論して論破できる。身を守れる程度には、事例を確認してどうするかを考えたほうがいい。

感想や気付き、学びなど

意外と、似たようなことを思っているんだなとは感じた。
ステルス修正は、自分が思いついていたステルスアップデートと、語感と意味合いが似ていたのでビビった。

残念ながら、本に出ていたことは大抵経験済みだった。。。
たぶん、10年やれば、一通りコンプリートできる気がする。