タイトル

ソフトウェア開発現場の「失敗」集めてみた。
イメージ

感想

ソフトウェアの現場でよく起きる失敗談が数多く紹介されており、
読んでいて「あるあるだな」と何度も当時の光景がよみがえりました。
文章はとても読みやすく、本来なら実際に失敗して身につくような知見を、
事前に学べて失敗を回避できる点が大きな魅力だと感じました。

ピックアップ

本を読んでみて、印象に残ったことを残します。

Chapter1 「企画」で失敗

  • 01：なんでもできる「全部入りソフトウェア」
  • 02：みんなの願いをかなえたい「八方美人仕様」
  • 03：顧客要望通りの「使えないソフトウェア」
    • 顧客から「何が欲しい」のかではなく「なぜ欲しい」のかを聞き出す
  • 04：製品のことしか記載のない「足りない成果物」
    • 必要な成果物を漏れなく確認し、成果物ベースでWBSを作成する
  • 05：ほっとくだけで大問題「新OS地獄」
    • 対応OSを事前に確認する
  • 06：リーダーも新人も一緒「全員一人前計画」
    • 教育コストも計画に含める

Chapter2 「仕様」で失敗

  • 07：実装できない「ふんわり仕様」
    • ユーザーストーリー・マッピングを作成する
  • 08：解読が必要な「難読仕様書」
  • 09：ユーザーを迷わす「オレオレ表記」
  • 10：知らんけど「知ったかぶり技術」
    • 機能実現性を検証する
  • 11：カタログだけで判断する「スペック厨導入」
    • ソフトウェアの購入先の選定条件にサポート体制も含める
  • 12：行間を読ませる「文学的仕様書」
    • 「仕様は正確に伝わっていない」を前提として小さいサイクルでレビュー/フィードバックを回す
  • 13：ゴールがあいまいな「おまかせ委託」
    • ゴールがあいまいだと委託元、委託先の両方が不幸になる、委託時に受入検査仕様書でゴールを明確にする
  • 14：業界用語でイキる「玄人向けUI」
    • 用語集を作成する

Chapter3 「設計・実装」で失敗

  • 15：自在に解釈可能な「形だけインターフェース」
    • アーキテクチャの設計思想を文書化する
    • なぜそうしたのか、なぜそうしなかったのかを言語化、
  • 16：自分だけの都合で変更する「自己中改造」
  • 17：リリース版が復元できない「不完全リポジトリ」
    • ソースコード以外のツールやドキュメントなどすべての情報をGitで管理する
  • 18：もう開発環境がない「伝説のオーパーツ」
    • 開発環境も残す
  • 19：夜な夜な数えるbyte数「メモリ怪談」
    • 組み込みソフトウェア開発ではメモリマップが重要
  • 20：つい自分でやってしまう「経験値泥棒」
    • 設計力は経験からしか得られない
    • 若手を成長させるには手を出し過ぎない
  • 21：バグ修正が新たなバグを生む「バグ無間地獄」
  • 22：今がすべて「動けばいいじゃん症候群」
    • 長い目で見れば目先優先より正しいアーキテクチャに従う方がコストは低い
  • 23：チームを守れない「ノンポリリーダー」
    • 上司にも部下には見えないミッションがあり無理難題、解決困難な課題を持っているもの（今の体制で売り上げアップ、最重要案件を任せられる、エース級の引き抜き）

Chapter4 「進捗管理」で失敗

  • 24：アクションしない「聞くだけ進捗会議」
    • 課題を早期発見したい
    • 課題の発見を喜び、課題に対して予防措置する
  • 25：残業も計画に織り込む「時間泥棒」
    • 1日8時間を前提とせず、実際の作業可能時間を1日5時間などとして、見積もり時間をもとに日程を計画する
  • 26：会議が会議を呼ぶ「増殖する会議」
  • 27：また責められる「怖い会議」
    • チームの心理的安全性を確保する
  • 28：職場が戦場になる「不機嫌なチーム」
    • 「不機嫌な職場」という
  • 29：メールが業務の起点「メールドリブンワークスタイル」
    • メール（チャット）は残るので賛成、会話と併用が大事
  • 30: 変更されない「完璧な計画書」
    • 計画通りに進まない
    • 計画は見直すもの
    • 計画の見直しタイミングを定期的に設定する
  • 31：施策を打ち続ける「カイゼンマニア」
    • 課題の根本原因を改善する
    • 施策の効果を計測し定期に見直すべき
  • 32：世の中どうあれ「初期企画至上主義」
  • 33：リリース直前に発覚「ステルス課題」
    • 04と同じ、成果物ベースでWBSを作成する

Chapter5 「品質評価」で失敗

  • 34：バグが出ない「開発者バイアス」
    • 顧客のユースケース（ユーザー観点）をテストに含める
  • 35：作ってみてのお楽しみ「でたとこ性能」
    • 非機能要件はPDCAを小さく回す
  • 36：すべてのバグを許さない「ゼロバグ出荷」
    • バグの修正コスト、重要度を考慮し修正するかしないかを判断する
    • すべてのバグを修正するとは限らない
  • 37：こっそり直す「ステルス修正」
    • 勝手に修正しない
  • 38：リリース日が来たので「とにかく出荷」
    • 品質ファースト
    • 品質を確保できる計画を立てる

Chapter6 「リリース後」に失敗

  • 39：出荷したので解散「出しっぱなしプロジェクト」
    • 出荷後のハードウェアは簡単に変えられない
    • ソフトウェアで何とかして
  • 40：正しい動作かわからない「ライセンスの迷宮」
  • 41：問題は出ないはず「ノーログ戦法」
    • ログは残す
    • 残せるものは残す
  • 42：犯人を追い込む「お呼びでない名探偵」
    • 原因分析はプロセスにフォーカスする