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

はじめに

こんにちは、レバテックCTO室でテックリードを担当しているかわうそです。

今回は、夏といえば夏休みの宿題、夏休みの宿題といえば読書感想文ということで読書感想文を書いてみました。

読書感想文の対象読書として選んだのは、”ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた”になります。

特に選んだ理由とかはないんですが、
読書感想文を書いてみようと思ったタイミングと読もうと思ったタイミングがたまたま重なったのが理由です笑

感想

読んでみて最初に思ったことは「うわーそれあるあるだわぁ」がたくさんあったことですw

ソフトウェア開発をしていると幾度も失敗をしてしまうことはあると思いますが、こういった失敗を他のエンジニアたちもしているんだなと思うと、少し気が楽になりましたw

その上で、この本を読んで一番に感じたことは 「いかに失敗から学べるか」 ということです。

ソフトウェア開発には失敗は付きものだと思います。
だからといって失敗してもOKというわけでもありません。
失敗をたくさん重ねてしまえば、顧客の機会損失になってしまい、売り上げは厳しくなってしまいます。

ただ、失敗のケースをたくさん持っておくこと、失敗の経験をしておくことで、今後起きえるだろう危険や失敗を察知することができるようになり、なにかしらの対策の一助にもなると思います。

ですが、失敗の経験をたくさん積むということはなかなかできることではありません。
（むしろ、たくさん失敗しちゃうと会社をクビになっちゃうかもしれないのでw）

そんな中で、この本はソフトウェア開発における多くの失敗エピソードをわかりやすく伝えてくれており、経験したことのない失敗も自分が失敗したかのように学べる本になっています。

おすすめ読者

未経験、経験者、ベテラン、どんな方にもおすすめの一冊になると思います。
全部の失敗ケース知っているよ！ってなる方もいるかもしれませんが、改めて今まで起こしてきた失敗の振り返りにもなるのでおすすめです。

また、業界問わずソフトウェア開発に関わっている方なら誰でも読める本になっています。
この本で取り扱っている架空のプロジェクトでは、ソフトウェア、ハードウェア、自社開発、受託開発などを取り扱っています（逆に、普段、Web開発をしている人にとってはハードウェア的な悩みは逆に学びになりますw）

印象的だったエピソード

この本の中で印象に残ったエピソードを紹介しつつ、そのエピソードから感じたことなどについて紹介してみようと思います。

EPISODE 01：なんでもできる「全部入りソフトウェア」

簡単にエピソードを紹介すると、

顧客の要望を満たすために「あれも」「これも」と機能開発の要望がやってきて、さらに各機能のスケジュール要望もやってきます。開発側はそれを満たすためのスケジュールをアバウトに立ててしまい、その結果、スケジュールが遅延するという内容です。

すべての機能をスケジュール通りにリリースするのは簡単なことではありません。機能が増えると、想定外の技術的な課題が発生し、さらに遅延する可能性が高まります。また、無理に妥協してリリースするという判断を下すと、技術的負債を生み出し、今後の機能開発に悪影響を及ぼす可能性もあります。

そのため、できる限り早い段階でこの問題を検知するために、企画や要求の検討段階から開発側も参加して、実現可能性について議論することは重要です。
（企画側が「そんなに開発工数がかかると思っていませんでした」みたいなことも多々ありますよね）

さらに、こういった問題を未然に防ぐためにも、スケジュールはきちんと見積もりを行った上で計画したり、開発する機能（スコープ）を小さくして不確実性を減らすことも必要です。

こういった話はt_wadaさんの質とスピードでも出てくるお話と近い部分がありますね。

EPISODE 02：みんなの願いをかなえたい「八方美人仕様」

EPISODE 01に続き、追加の要望を次々に受け入れてしまい、結果としてスケジュールがさらに遅延してしまうという内容です。さらに、リファクタリングなどに含めていた期間も機能開発の時間に当ててしまい、技術的な課題と向き合う時間も無くなってしまいます。

やっぱり ソフトウェア開発ではすべての機能を実現することが難しい ですよね。
それでもたくさんの要望がやってくるので、どの機能を開発するのかについて検討するプロセスは必要だし、見送りにするという意思決定も時には必要だと思います。

ここで良いことが書いてあったので、紹介します。

ソフトウェアは機能を追加しやすいので、様々なステークホルダーから常に要望を受けます。その一方で、受けた要望のすべてを定められた期間で開発することはできません。幾百の要望の中から実装すべき機能を厳選しなくてはなりません。顧客課題を解決し、売り上げを拡大させ、年末のボーナスを勝ち取れる要望はどれなのか。開発、販売、企画が一体となって仕様を見直し、ソフトの価値を最大化するのです。

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

つまり ”たくさんの要望の中から本当に何が顧客に求められてるのか素早く見極める” ことが必要ということです。
アジャイルにおける肝の部分でもありますよね。

（すべての機能を実現するのは難しいという前提で進めたら、説明とかが少し楽になるかもですね）

COLUMN：何を、なぜ作るのかが最重要

ソフトウェア開発において一番の失敗は 「作るものを間違えること」 と紹介しています。

まさにその通りだと思います。
どんなに品質が優れていても顧客の要望を満たせてなければ意味がありません。
なので、ソフトウェア開発において 「何を、なぜ作るのか」 が最も重要ということです。

この「なぜ」を紐解く時に、以下の項目を考えると良いでしょうと紹介しています。

顧客：顧客は誰か
課題：顧客の課題は何か
理由：なぜその課題は未解決なのか
価値：その解決手法を導入することで顧客にどんなメリットがあるのか
解決手法：どうやって課題を解決するのか
優位性：その解決手法の優位性は何か
実現性：なぜ自社で取り組むのか。なぜ自社でできるのか

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

EPISODE 15：自由に解釈可能な「形だけインターフェース」

アーキテクチャ図やインターフェースのAPIだけ記載していても、アーキテクチャは崩れてしまい、品質だけでなく事業の継続性にも影響するという内容です。
さらに、アーキテクチャにおいてモジュール間の「疎な関係」を保つだけでも難しいと紹介しています。

アーキテクチャを保ち続ける難しさは、テックリードとしてアーキテクトを担当する中ですごい痛感しています。
特に思想や背景が伝わっておらず、思ってもいないような実装が誕生し、徐々にこの実装がアーキテクチャの破壊を進めていくみたいなこともあります。

そこで、この本が勧めているのが 設計思想を伝える/残すために「設計書を文書化する」 ことです。
最近では、ADR（Architecture Decision Record）と呼ばれているものになるかなと思います。

「なぜ、このようなアーキテクチャになっているのか」
こういった情報は時が経つとともに失われていきやすい情報かと思います。
特に後から参画したメンバーはよりキャッチアップしづらい情報になります。

この情報があるかないかで、設計や実装における意思決定は大きく影響を受けるので、できる限り残していくべきだなと改めて感じました。

（ADRってどこまで残すかの判断が難しいなぁっていう気持ちもありますが、ここでは抑えておきます笑）

EPISODE 20：つい自分でやってしまう「経験値泥棒」

この本の中で最も自分が共感したエピソードになります。

特に僕が共感できた部分が 「設計力は経験からしか得られない」 になります。
本当にその通りだと思います。アーキテクチャや設計に関する知見は世の中に数多くありますが、それらを現場で実践し、そこから学ぶことで初めて習得できるものだと考えています。

元FacebookエンジニアのEvanPriestleyさんが「どうやってプログラミングを学んだかを教えてください」という質問に答えている内容が紹介されており、とても共感しました。

私が開発力を養うために最も役に立ったのは、「よい判断力」だと思う。プロとしてプログラミングをしていた最初の2～3年は、システム設計で多くの「悪い決断」をしてしまっていた。だがFacebookに採用されるころには十分な経験を積んでいたので、自分で行った設計のほとんどで単純さと洗練さの適切なバランスが取れていたし、他のエンジニアの作ったシステムの問題点をかなり確実に見つけることができた。この力は鍛えることも教えることも大変に難しいが、非常に価値があるものだ。私が知る限り、「よい判断力」を向上させる最良の方法は、自分が設計したシステムの保守を、その要件が変化するぐらいの長期間にわたって、強いられることだ。

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

「よい判断力」＝「悪い設計か見分ける力」なのかなと思っています。
この力があるかないかはエンジニアとして大きな差になる部分であり、特にリーダーを担当している方には求められるスキルだと思います。
（”自分が設計したシステムの保守を、その要件が変化するぐらいの長期間にわたって、強いられる”という経験はなかなかできないことが多いですが笑）

また、このエピソードの中で伝えたかったこととして 「設計の経験は技術者の成長機会になる」 もあるのかなと思っています。

ベテランが設計を担当し、メンバーが実装を行うという開発現場はよく見かけます。しかし、これはメンバーの成長機会を奪っているという側面もあります。設計力は経験を通じてしか身につかないものであり、メンバーが育たなければ組織全体の成長も望めません。
そのため、設計をメンバーと一緒に進めたり、設計を任せてみる機会を設けることも重要です。

EPISODE 35：作ってみてのお楽しみ「出たとこ性能」

このエピソードも個人的に良かったので、思わずXに投稿しちゃいました笑

https://x.com/_syoryu89/status/1824720461244273108

内容としては、そもそも非機能要件（エピソードではスループット）を決めておらず、実際に開発した機能があまりにもパフォーマンスが悪く、致命的な問題になってしまったというエピソードです。

パフォーマンス問題って意外と根深い問題になっていることが多くて、いざ対応しようと思っても時間がかかることが多いんですよね...

なので、最初から 「非機能要件の目標を立て、継続して計測する」 ことが重要なんだと改めて感じました。
非機能要件の目標次第で設計・実装が大きく変わることもありますし、一度、設計・実装してしまうと改修コストが高くなり修正するのが大変になることもあります。

EPISODE 36：すべてのバグを許さない「ゼロバグ出荷」

すべてのバグを修正しようとして、1つのバグ修正がまた新たなバグを生み、なかなかリリースができないというエピソードです。

「すべてのバグ・不具合が解消するまでリリースができない」みたいなことはけっこうあるあるなのかと思います。
アーキテクチャや設計が良くないせいで、バグがバグを生むなんてこともよくあるので、解消するかどうかの判断が難しいときもあります。
また、クリティカルなバグ・不具合を残したままリリースしてしまうと、ユーザーが利用できない、ユーザーに利用してもらえないなんてことも起きてしまいます。

このエピソードを通して伝えていたのが、エンジニアは 「技術者でもありビジネスマンでもある」 になります。

これは自分自身とても感じていることで、いくら開発を頑張ってたとしても、世の中に届けなければユーザーの課題解決に繋がらないし、ビジネスチャンスを失うことにもなります。また、届けたものが本当にユーザーが必要なものかもわからないので、提供するのが遅くなればなるほどリスクにもなります。

｢要はバランス｣とは言いたくはないですが、ビジネスはインプットとアウトプットのバランスが求められます。
インプットをどれだけ頑張ってもアウトプットがいまいちなら価値は低いし、インプットにめちゃくちゃコストをかけてアウトプットの価値がすごかったとしても時すでに遅しみたいなこともありえます。

なので、エンジニアはバグ・不具合をどう対応していくのか基準があると良いかもしれませんね。
（作成するのが難しいですが、"品質基準"みたいなものがあると良いですね）

おわりに

今回、初めて”読書ノート”的なことをはじめてやってみました。
Notionに気になったこと・感じたこと・考えたことをメモっておくというやり方です。

実際、いつもの2倍ぐらい時間がかかりましたが、後から見返した時に、どんな情報があったかとかどんなふうに考えたかなどを簡単に遡れるので、たまには”読書ノート”をやってみるのも良いかもしれません。