虎の穴開発室ブログ

虎の穴ラボ株式会社所属のエンジニアが書く技術ブログです

MENU

ソフトウェア開発現場の「失敗」集めてみた。から学んだこと

こんにちは! 虎の穴ラボのnagaです。

本記事は虎の穴ラボ2024年夏の連載ブログ 21日目の記事です。

前回はy.fさんの「ゲーム好きエンジニアの実践的学習アプローチ」が公開されました。ぜひご覧ください!

次回はS.Sさんの「「システム設計の面接試験」で最適なシステム設計を学ぶ」が公開されます。こちらもご期待ください!

なぜ読もうと思ったか

最近、チームリーダーとして開発をリードする立場になりました。私はなるべく失敗なく開発業務をこなすためには、事前にリスクを洗い出し、それにどう対処するかを考えておくことが大切だと思っています。

本書では、ソフトウェア開発での失敗事例とリカバリ方法が例示されているため、想定外のリスクを減らす助けになると考え、読むことにしました。

本書について

タイトル ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた
著作者名 出石 聡史
ページ数 288ページ
発売日 2024/06/12
発行 翔泳社
ISBN 9784798185187
紹介ページ ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた(出石 聡史)|翔泳社の本

概要

本書は、架空のプロジェクトを通じてソフトウェア開発を遂行するチームが遭遇する42の失敗について、以下の章立てで紹介されています。 それぞれのエピソードには、下記の内容が記載されており、失敗と振り返りを追体験できる構成になっています。

  • 発生した失敗
  • 失敗の原因
  • 回避するためにできる対策案

また、4コマ漫画やキャラクターたちの掛け合いでエピソードが紹介されるため、読みやすい書籍になっています。そのため、ソフトウェア開発で発生する失敗を学びやすい本だと感じました。

Chapter1 「企画」で失敗

要件を決める工程で発生する失敗エピソードが紹介されています。

ステークホルダーの要望を吸い上げ、納期に間に合うレベルで要件を決める方法を学ぶことができます。

Chapter2 「仕様」で失敗

決まった要件に対して、何をどう作るかを決める工程で発生する失敗エピソードが紹介されています。

作成者以外でも設計・実装に落とし込める仕様を定義するための方法や機能間の整合性を取るための方法を学ぶことができます。 また、『仕様は間違いなく、間違って伝わっている』というコラムは必見の内容です。

Chapter3 「設計・実装」で失敗

実際にシステムを作り上げていく工程で発生する失敗エピソードが紹介されています。

設計・実装に関する取り決めやチームの技術力を維持・向上させるために必要なことを学ぶことができます。 技術力のあるリーダーだからこそやってしまうアンチパターンは特に気をつけたいと思える内容でした。

Chapter4 「進捗管理」で失敗

進捗管理だけでなくチーム運営をする上で発生する失敗エピソードが紹介されています。

課題やリスクを早期に発見するために、心理的安全性を高めることの重要性を学ぶことができます。

Chapter5 「品質評価」で失敗

システムが完成した後の品質評価で発生する失敗エピソードが紹介されています。

品質と納期を天秤にかけ、リリースまでにどんなことをする必要があるかを学ぶことができます。 アジャイル開発の現場での例も提示されていました。

Chapter6 「リリース後」で失敗

リリース後の運用・保守で発生する失敗エピソードが紹介されています。

リリース前には想定できなかったバグや振り返りの仕方などを学ぶことができます。

どんな方が読むと良いか

本書は、初めて開発をリードする立場になった方に1番おすすめできると思います。開発を推進する未知の業務に対して、気を付けるべきポイントを事前に知ることができるのは、大きなアドバンテージになるからです。

チームメンバーや開発を依頼するユーザーも、本書を読むことで本当に必要なものを作るために何を意識すれば良いかを学べると思います。

感想

全体を通して、失敗を回避・解決するために大切だと学んだことは下記の2点です。

  • コミュニケーション
  • 仕組みづくり

コミュニケーション

当たり前かもしれませんが、各関係者と適切なタイミングで必要なコミュニケーションを取ることで、解消できる失敗が多いと学びました。中でも対面や文章でのやり取りだけではなく、アーキテクチャを説明した図のようなドキュメントを残すこともコミュニケーションに該当するというのは本書を読んで気づけた視点です。

例えば、新しい人がチームに配属されたときに、ドキュメントがないと毎回同じ説明をする必要があります。ドキュメントがある場合は、それをベースに質問を受け付けたり、補足をする事ができるので、短い時間でドメイン知識を共有することが可能になります。私たちのチームでは、各機能を説明するドキュメントは一部しか作成できていないので、業務的に重要な機能については作成を急ぎたいと思いました。

仕組みづくり

失敗を防ぐための仕組みを作ることも大切だと学びました。

例えば、本書では 『修正が新たなバグを生む「バグ無間地獄」』 という失敗エピソードが紹介されていました。影響範囲を考えずバグを修正した結果、他機能で別のバグが発生してしまうという事例です。 こちらは自動テストを整備していれば、テストが失敗することで事前に影響が出たことを察知することができます。もし、手元で自動テストの実行を忘れてもCIのフローに自動テストを含めておくことで、デプロイ前に異常を突き止めることができます。

このようにヒューマンエラーは起きるものとして、失敗を回避する仕組みをつくることが大切だと思います。私たちのチームでは、CIは整備済みなので他にも自動化できる箇所を探して失敗を防ぎたいと思いました。

最後に

今回はソフトウェア開発現場の「失敗」集めてみたという本を紹介しました。 42個の失敗は、誰しも経験があったり起こりそうと思える内容ばかりでした。本書の中では、失敗に対してどのような回避策があるかまで紹介されていますが、実際のプロジェクトやチームの状況によって有効な方法は異なると思います。 リスク管理について考える良いきっかけになると思いますので、みなさんもぜひ読んでみてください!

採用情報

虎の穴ラボでは一緒に働く仲間を募集中です!
この記事を読んで、興味を持っていただけた方はぜひ弊社の採用情報をご覧ください。
toranoana-lab.co.jp