課題図書を事前に決めた締切で読み切り感想を投稿するデッドライン読書会。今回で69回目です。課題図書は『ソフトウェア開発現場の「失敗」集めてみた。』です。
概要
副題が「42の失敗事例で学ぶチーム開発のうまい進めかた」です。筆者の経験に基づく架空の会社での架空の題材として失敗事例を集めています。架空の会社の社員がロボットだったり、失敗事例の先頭に四コマ漫画でイメージがしやすい要約が入っていたり、筆者の（生々しい）現場での経験が書いてあったり、読みやすくなる工夫が取られています。
42の失敗事例は以下でカテゴリー化され章わけされています。
- Chapter1 「企画」で失敗
- Chapter2 「仕様」で失敗
- Chapter3 「設計・実装」で失敗
- Chapter4 「進捗管理」で失敗
- Chapter5 「品質評価」で失敗
- Chapter6 「リリース後」に失敗
ちなみに舞台は自社の組み込み型のシステムを開発する企業です。受託開発での観点は少し少ないかもしれませんが（たまに登場します）、十分参考になると思います。
感想
どの失敗事例も構成は同じで、
- 失敗事例の名称
- 四コマ漫画
- ちょっとした小話（失敗がおきた現場事例）
- 著者の解説
- 解決策・対応策
- まとめ
となっています。「ちょっとした小話」である現場の発言や態度が「あるある」で面白い…。とても人間味（ロボットだけど）が溢れています…。
さて、すべてを総括するほどまとめ力はありませんので、この42の失敗事例から興味深かったものをピックアップして感想を書きます。
Episode 6. リーダーも新人も一緒「全員一人前計画」
この失敗事例、類似したものがいくつか出てきますが、言うならば「見積もりミス」系です。リーダー業をやっているような人はプロジェクト外のワークも多いし、新人は育成のオーバーヘッド（？）も見込んでおく必要がある。当初見積もり時点ではアサインは決まっておらず、なんとなく「中級」な人を想定しておいて、あとからアサインをしてみて困るパターンもありますね。（企画時に調整が大変なアサインを先送りにしているっていう問題が隠れている。）
Episode 24. アクションしない「聞くだけ進捗会議」
これは頭が痛い…。コミュニケーション不足系。「進捗会議」で共有すべきはツール等でもわかりやすい「進捗」ではなく、深堀りしないと明らかにならない「課題」だと。頭痛い…（2回目）。あるあるの進捗会議として、まずは進捗の共有と対策、その後に課題の整理、と思ったら時間切れ（続きは次回）なんてことも良くあります。作業の進捗はなるべくツール化・自動化して、本当に共有・解決すべき課題にフォー化するような運営が必要ですね。あと「進捗会議」っていう名前もより適したものに変えるのが良さそうですね。
Episode 27. また責められる「怖い会議」
プロジェクトの会議では深堀りがよく行われますが、それが「怖い」っていうパターン。心理的安全な環境を用意して、ハードな問いも気軽に行えるような場を作るのもリーダーの役目。「怖い会議」が怖いからって「なあなあ」でも良いわけでもないっていうのが難しい。リーダーシップやチームの色が出るシーンですね。
Episode 31. 施策を打ち続ける「カイゼンマニア」
これは良い示唆。改善はとにかく重要だけど、それを個別に対応するために施策がたくさん出てきても、どうせやれないっていう問題。（私はアクションを1つだけピックアップしましょうっていうのはよくやる）。改善のための施策をどのように良い感じに抽出するか・抽象化するか、チームの熟練度によりそうです。
さて次は何ですかね？
次の本は何にしましょうか。これですかね^^
コメント