2023年6月10日に『人が増えても速くならない～変化を抱擁せよ～』が出版されました。
書評
ソフトウェア開発の新視点：非専門家でも理解できる洞察と改善の鍵
ソフトウェア開発の新視点：非専門家でも理解できる洞察と改善の鍵
ソフトウェア開発に関する知識が少ない方でも、内容が洞察に富んでおり、複雑さを剥ぎ取り、本質へと導く形になっています。著者はエンジニアリングと経営の両方を経験しているため、それぞれの視点からソフトウェア開発の深遠さを明らかにしてくれます。
重要なポイントは、ソフトウェア開発が事業の一部であり、それゆえに絶えず改善し続けるべきだということです。ただし、これは単に開発チームを増やすだけではなく、複雑さを管理し、シンプルで効果的なソフトウェアを作るための手法として重要であると強調されています。
品質維持のために必要なことは、シンプルな設計と継続的な改善だけでなく、開発チーム内のコミュニケーションと関係性の管理も含まれます。開発の時間やコストの予測は必ずしも正確でないため、開発チームとビジネスチームが協力し、共通の目標に向かうことが不可欠であると指摘されています。
また、開発プロジェクトを小規模から始め、段階的に改善していくことを推奨しています。さらに、変化を恐れず、受け入れるという重要な考え方を強調しています。この考え方は、ソフトウェア開発だけでなく、ビジネス全体や組織全体にも適用可能であることが示唆されています。デジタルトランスフォーメーションや人材管理に取り組む企業にとって、これは非常に有益な内容となっています。
内容がコンパクトにまとまっているため、数時間で一気に読むことが可能です。そのため、忙しい経営者や管理職にも最適な一冊です。さらに、ソフトウェア開発を学びたい初心者から、経験豊富なエンジニア、さらにはビジネスリーダーまで、幅広い読者にとって、有益かつインスピレーションに満ちた一冊だと思いました。
マインドマップによる整理
要約
はじめに
ソフトウェア開発において変化に適応できないことが問題であることを指摘し、エンジニア以外の人たちにとってもとっつきやすく、本質を知ることのできる書籍が少ないことを説明。本書は、多忙な人たちでもサッと読めるように、専門用語を使わずに平易な表現で大事なポイントを押さえた内容となっている。
1章 完成しても、終わりではない
システムは導入しても、使い始めてからが本番であり、改善が始まる。システム開発はプロダクト中心に変わり、依頼して作るものから協働して一緒に作るものになる。システムは事業と共に改善を続けるものであり、改修には多大なコストがかかることがあるが、事業の成長にはシステムが支えるので、システムもずっと改修していく前提で作るべきである。
2章 人を増やしても速く作れるわけではない
人数を増やしても生産性が上がらないことがある。遅れているプロジェクトに人を追加すると、情報共有や教育にコストがかかり、コミュニケーションにも時間がかかる。また、タスクを分解するにも限度がある。生産性を上げるには、高い生産性を出せるような環境を用意するか、クラウドに移管したうえで性能を増強することが有効。チームの哲学や文化が揃っていることが大事で、チームワークとコミュニケーションは欠かせない。チームの共通体験が必要で、時間がかかるが、築かれたチームがプロジェクトごとに解散されると生産性の高いチームは存在し続けられない。
3章 たくさん作っても生産性が高いとは言えない
プログラムを書く際には、現実世界のことを理解し、抽象化してプログラムに変換することが重要。また、プログラムの生産性は量で測るべきではなく、抽象化の質で測るべきである。複数人で開発する場合は、影響範囲を限定するように分離して設計することが効率的。ソフトウェア自体を分けることも有効。シンプルで小さなソフトウェアであるほど、不具合の数も少なく、変化に適応できる。
4章 人に依存せず同じ品質で作ることはできない
ソフトウェアは、すべてが一品モノであり、外から見える品質と見えない内部品質の2つの観点がある。内部品質は、後々の生産性に影響するため、エンジニアたちは「美しさ」と表現することもあり、コードレビューを通じて中身の理解と品質の向上を図っている。ソフトウェア開発は、属人性の高いクリエイティブな仕事であり、個々人が成果を発揮しつつも、コードレビューを徹底化して、チームの成果や知見としていくことが重要である。
5章 プレッシャーをかけても生産性は上がらない
プログラム開発において、プレッシャーに負けて一時的な妥協をすることが技術的負債と呼ばれ、放置すると返済にかかるコストが大きくなる。生産性を上げるためには、最初からシンプルな状態を維持するか、少しずつ手を加え続けることが必要。また、システムや機能が増えるに従って、お守りをするコストがかかるため、人を増やし続ける必要があるが、人数を増やすとコミュニケーションコストや人間関係の複雑さが増すため、適切にシステムを分割していく必要がある。生産性を上げる仕組みを作るための時間を用意することが重要であり、仕事のやり方やプロセスを見直すことが必要。
6章 見積もりを求めるほどに絶望感は増す
ソフトウェアの見積もりには不確実性がつきもので、バッファを積むことが必要になるが、それが見積もりの精度を下げてしまう。受発注の関係になると、確実な見積もりと約束を取りたがる依頼側と、期限内に作ることだけを優先する開発側になってしまう。そこで、事業側と開発側が協働関係を築き、共通のゴールを目指すことが重要である。大きな機能の見積もりはあくまで見通しであり、期間ありきで機能を見積もることが必要である。また、依頼ではなく相談することで、より開発のコストがかからない実現方法を選ぶことができる。そして、開発したシステムは順次、使い始めていくようにし、ユーザーからのフィードバックを得て改善することが大切である。
7章 一度に大きく作れば得に見えて損をする
プロジェクトを小さく分割して、スコープを狭めて不確実性を下げることで、生産性を高めることができる。ソフトウェアは小さく始めて、動きを試すことで必要な機能を見極め、少しずつ育てていくことができる。開発体制も分割することで、継続的な保守や運用も考慮した体制が必要になる。プロジェクトの成功は不確実性をコントロールすることにかかっており、優先順位を決めてスコープを狭め、定期的にプランの見直しをすることが重要である。
8章 工程を分業しても、効率化につながらない
ソフトウェア開発には分業が向かない。プログラムは設計作業であり、プログラミングスクールの卒業だけでは良いプログラムを書けるようにならない。プログラムは最も低い品質に引っ張られるため、コードレビューは必要不可欠。ソフトウェアの設計は、ソフトウェアを欲している人とエンジニアが一緒に行うことが重要。事業とソフトウェアが不可分の時代には、事業側の人間とエンジニアもワンチームになることが必要。
参考文献
ゆとりの法則
トム・デマルコ著/伊豆原弓訳/日経BP刊ピープルウェア 第3版
トム・デマルコ、ティモシー・リスター著/松原友夫、山浦恒央、長尾高弘 訳/日経BP刊デスマーチ 第2版
エドワード・ヨードン著/松原友夫、 山浦恒央訳/日経BP刊ザ・ゴール
エリヤフ・ゴールドラット著/三本木 亮訳/ダイヤモンド社刊小さなチーム、大きな仕事
ジェイソン・フリード、デイヴィッド・ハイネマイヤー・ハンソン著/黒沢健二、松永肇一、美谷広海、祐佳ヤング訳/早川書房刊ライト、ついてますか?
ドナルド・C・ゴース、ジェラルド・M・ワインバーグ著/木村泉訳/共立出版刊システムの問題地図
沢渡あまね 著/技術評論社 刊エンジニアリング組織論への招待
広木大地 著/技術評論社 刊Joel on Software
ジョエル・スポルスキー 著/青木靖訳/オーム社 刊Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方
エリック・シンク著/青木靖訳/オーム社刊人月の神話 【新装版】
フレデリック・P・ブルックス J・著/滝沢徹、牧野祐子、 富澤昇訳/丸善出版 刊達人プログラマー 第2版
デビッド・トーマス、 アンドリュー・ハント著/村上雅章 訳/オーム社 刊XP エクストリーム・プログラミング入門(現在は第2版がオーム社刊)
ケント・ベック著/長瀬嘉秀監訳/飯塚麻理香、永田渉訳/ピアソンエデュケーション 刊
目次の俯瞰（マークダウン形式）
# 人が増えても速くならない ～変化を抱擁せよ～
## はじめに
## 1章 完成しても、終わりではない
### システムは使い始めてから改善が始まる
### なぜ、ソフトウェアなのに固くなってしまうのか
### プロジェクトからプロダクトの考え方に変える
## 2章 人を増やしても速く作れるわけではない
### 2倍の予算があっても2倍の生産性にはならない
### 遅れているプロジェクトに人を追加するのはやめて
### 銀の弾丸はないが〝金の弾丸"なら有効なときがある
### 速く作ることはできないが、速く作れるチームは作れる
### チームの哲学や文化が揃っていることが大事
## 3章 たくさん作っても生産性が高いとは言えない
### あらゆる状況を考慮するのに時間がかかる
### プログラムは現実の理解の上に成り立つ
### 影響範囲に気をつけて、重複をなくすことも仕事
### 同じソフトウェアを複数人で同時改修するのは非効率
### 生産性は、手を動かした時間で測らない
## 4章 人に依存せず同じ品質で作ることはできない
### ソフトウェアは一品モノ、 1つずつ中身が違う
### 外から見える品質と、見ることのできない品質
### エンジニアにしかわからないプログラムの美しさ
### クリエイティブな仕事の属人化を解決する
## 5章 プレッシャーをかけても生産性は上がらない
### 急がせたところで速く作ることはできない
### 一時的な妥協は、永遠の負債になる
### 作れば作るほど、生産性は落ちていく
### 生産性が上がる仕組みを作ることは投資
### 楽をするための苦労はいとわない
## 6章 見積もりを求めるほどに絶望感は増す
### なぜ、正確な見積もりが出せないのか
### 見積もりを守るためのバッファの功罪
### 見積もりと約束が〝受発注〟の関係を作ってしまう
### 事業側と開発側が“協働”の関係を築く
### 「納品」をなくせばうまくいく
## 7章 一度に大きく作れば得に見えて損をする
### プロジェクトが大きくなるとうまくいきにくいのに、なぜプロジェクトは大きくなってしまうのか
### ソフトウェア開発はギャンブルのようなもの、大きく賭けると大きく失敗する
### 小さくすれば不確実さを下げられる
### 小さく作って、大きく育てられるのがソフトウェア
### プロジェクトを小さくするために、作ろうとする機能の範囲を限定する
### 不確実な未来を、少しずつ確実なものにしていく
## 8章 工程を分業しても、効率化につながらない
### 工程を分離しても生産性は上がらない
### 猫の手を借りても生産性は上がらない
### プログラムは最も低い品質に引っ張られる
### ソフトウェアの設計はだれのものか
## おわりに
## 参考文献
