はじめに
今回は書籍「ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた」を読みましたので、感想/レビューを書きたいと思います。
ソフトウェア開発現場での様々な失敗事例を集めた本
本書はタイトルの通りソフトウェア開発現場での様々な失敗事例を集めた本になっています。
架空の舞台・プロジェクト・キャラクターを使ってわかりやすく42個の事例を紹介しています。
購入前のイメージでは「ソフトウェアの失敗を集めてそれをどうやって解決するかを真面目に考える本なのかな？」と思っていました。
実際に読んでみると購入前イメージとは違い、各エピソードには4コマ漫画もついていて、コミカルな要素もありつつ、失敗事例の紹介とどうしていけばよかったのか。失敗を防ぐためには何が必要かという内容が書かれていて、すらすらと読み進めることができました。堅い本ではなかったです。
企画からリリース後までにある具体的な失敗事例が書かれており、幅広い事例を扱っている
ここまでいろいろな失敗事例を紹介している本も珍しいのではないでしょうか。
この本には42個の失敗エピソードが書かれています。そして、それは開発の流れに沿って「企画」から「リリース後」までの幅広く収録されています。
各章の項目は下記です。
- Chapter1 「企画」で失敗
- Chapter2 「仕様」で失敗
- Chapter3 「設計・実装」で失敗
- Chapter4 「進捗管理」で失敗
- Chapter5 「品質評価」で失敗
- Chapter6 「リリース後」で失敗
その中で合計42個の失敗エピソードが収録されています。
そして、それぞれのエピソードのタイトルを一部紹介するとこんな感じです。
- ゴールが曖昧な「おまかせ委託」
- リリース版が復元できない「不完全リポジトリ」
- もう開発環境がない「伝説のオーパーツ」
- 今がすべて「動けばいいじゃん症候群」
- 会議が会議を呼ぶ「増殖する会議」
- 職場が戦場になる「不機嫌なチーム」
- 問題は出ないはず「ノーログ戦法」
どうでしょうか？見出しから面白そうだと思いませんか？(笑)
または、「うわ～あるかも。。」と自身の経験から胃が痛くなったりする人もいるかもしれません。
エピソードタイトルにはセンスを感じますよね。ほかにも面白いエピソードがあります。
このような失敗エピソードがたくさん収録されている本はなかなか貴重だと読んでいて感じました。
組み込み分野のエピソードが多い(気がする)
本の内容自体はとても面白かったです。
ただ、失敗事例の内容が組み込み分野をイメージして書かれた本なのかなという印象を受けました。
私は組み込み分野に身をおいてますので、各エピソード「めちゃめちゃわかる！」「そうそう！」という反応でしたが、Web系の分野の方や、アジャイル開発の現場に身を置いている方が、すべての項目に「あるあるだね！」という反応になるか？というとちょっとわからないなと思いました。
もちろん参考になる項目は多いと思いますが、内容の背景が組み込み分野っぽいなという印象を受けました。
キャラや仮想現場の設定がわかりずらい
本書は架空の環境やキャラクターが登場します。
主に4コマでの出番が多いですが、いまいちどのキャラがどの担当なのか？というのがわからいので、ちょっと分かりづらいかも。と思いました。些細な話ですが。。
内容に対する感想
最後に先ほど紹介した本のエピソードについて、読んだ感想を書きたいと思います。
ゴールが曖昧な「おまかせ委託」
完全自社開発の企業ならあまり関係ないかもしれませんが、それ以外の企業だと、ソフトウェア開発を委託するということはよくあることかと思います。
その委託について、甘い見積もりであったり、成果物の基準が曖昧だと、悲惨でしかありません。お互いが不幸になるというのを再認識しました。
委託したらフォローもなしにあとはおまかせ。というのも危ないです。
一番悲惨なのが途中で仕様を変えたり、こんなことは言ってないと言って、ちゃぶ台返しする状況。
私も見たことはありますが、これは結構あるあるなんですかね？
リリース版が復元できない「不完全リポジトリ」
ソフトウェアのリリース版に個人のPCに保存されているなど、必要な情報がきちんと管理されていない状況についての失敗エピソードです。
最近はGitなどのバージョン管理ツールや、Github を使って管理してると会社も多いとは思いますが、左記のようなツールの活用を徹底していない会社では、本の中に書いてあるような担当者だけの PC に入ってたり、ソースが入ってたり、担当者の PCにしか存在ない情報があったりとかそういうこともよくあるなと思ったりしました。
もう開発環境がない「伝説のオーパーツ」
ソースコードがあっても、それをビルドするツールや開発環境が古すぎ、または開発環境がもう失われていてビルドができないという悲惨さが書かれています。
保守が必要と言っても結局予算の都合上だったりして取り合ってくれず。結局そのパソコンが壊れたら壊れたときに考える。このような状況はよくあるかもなと思いました。壊れたときに考えては遅いのに。。。
Web系の業界に例えるとライブラリの保守が終了だった。とか、古いバージョンのライブラリで今までやってきたが、時代の流れでもう使用できそうにない。。。というようなところでしょうか。
保守って難しいですね。ということを感じさせるエピソードでした。
今がすべて「動けばいいじゃん症候群」
アーキテクチャを崩すような実装を避けようという内容です。具体的な話として「グローバル変数は禁じ手」という話が出てきます。
また「なんちゃってクラス設計」として、クラスを使っているけど、実態はグローバル変数のような実装をしている例を挙げていました。
この「なんちゃってクラス設計」のような使い方をしているパターン自分も見覚えあるぞ。。。と思ったのですが私だけでしょうか？
会議が会議を呼ぶ「増殖する会議」
会議関係の悩みはエンジニア業界じゃなくてもあるあるなんじゃないでしょうか。
メインの会議を行うための事前会議。とか、営業会議、全体会議、勉強会、検討会、個別会議などなど。挙げるとキリがありません。
参加する意味がよくわからない会議。だけど参加しないといけない。会議すること自体が目的になっている。。。
この本では解決策として「会議を減らす」というのが挙げられていますが、その通りですね。
職場が戦場になる不機嫌なチーム
心理的安全性が重要な話。
不機嫌なチームって嫌ですよね。でも適切なコミュニケーションというのも難しいなと思ったりしています。会社の文化というのもあるので、なかなかすぐに改善できないよなと思ったりしています。
全然喋ってくれないとか人を整理されたいとかしたいとか、リーダーがチームの雰囲気を作るという風に書かれてて、ちゃんとマネジメントしようねと書いてあるんですけども、その通りだと思いました。
全てのバグを許さないゼロバグ出荷
バグをどこまで直すのか。限られた時間やリソースの中でどこまでバグを修正するのか。それともそのままにしておくのか。そんな優先度の重要性を語ったエピソードです。
どうしてもバグを全部修正しないといけないという義務感にとらわれてしまうんですよね。バグは嫌ですし。
そういう時に大切なのがどこまで割り切るか、何を違う方法で対応しとくかという重要性が書かれています。
小項目の「技術者でありビジネスマンである」という言葉が良い言葉だなと思いました。バランス感覚は自分も大切にしたいなと思いました。
問題は出ないはず「ノーログ戦法」
ログの重要性を説明しています。
現場で不具合が出てしまうのは嫌ですが、ログがないので「不具合が再現しない」「どんな環境や手順で不具合を再現すればよいかわからない」という状況はもっと嫌ですよね。何よりお客さんも困ってしまいます。ですのでログは重要だなと感じました。
これは仮に個人開発でも当てはまるので、私も気を付けたいと思います。
おわりに
個人的にはあるある過ぎて面白く読むことができました。気になるのは「こういった事例はあるあるなのか。それともレアケースなのか。」という部分です。私は組み込み分野に属していますが、個人的には結構あるあるな内容だと思って読んでいましたが、どうなのだろう？という点ですかね。
企業に属しているとその企業の文化が「普通」になるので、こういった「失敗事例」がほかの企業でも普通なのか、はたまた「自分の企業もしかしてやばいのか？」と思うのかで話が異なるかなと思ったりしました。
しかし、どちらにせよ。この本を読んで自分の業務の姿勢や、普段の業務を見直すきっかけになるのではと思います。そしてこういった失敗事例がたくさん紹介されている本は貴重だなと思いました。
