【読書メモ】人が増えても速くならない ～変化を抱擁せよ～

書籍名

人が増えても速くならない ～変化を抱擁せよ～

こんな人にオススメ（Amazonの説明＆主観）

エンジニアでもあり、経営者でもある著者が「はじめに」でも書いている通り、エンジニア以外の人向けに平易な言葉でサクッと読めるように書かれていると思います。

• 起業家
• 経営者
• 事業責任者
• マネージャー
• 人事（エンジニア採用にあたって８章だけでも読んでほしい）

エンジニアが読む意味があるとすれば、６〜８章あたりで経営側と開発側が協働していくための考え方や、全体を通して、非エンジニアに通じやすい例え話の仕方などかなと思います。

概要（Amazonの説明より）

ユーザー数が伸びるにつれて多くの要望が出てきても、新しい機能をスピーディーに追加できなくなってきた。
ちょっとした修正のはずなのに、ものすごく時間がかかる。

そのようなことが起こる原因は、ソフトウェアが変化に適応できないから。

プログラミングを学んでも理解できないソフトウェアの本質を、プログラマーとして12年、経営者として12年の経験を持つ著者の集大成。

• 完成しても終わりではない
• 人が増えても速くならない
• たくさん作っても生産性が高いとは言えない
• 人に依存せず同じ品質にはできない
• プレッシャーをかけても生産性は上がらない
• 見積もりを求めるほど絶望感は増す
• 一度に大きく作ると得に見えて損をする
• 工程で分担しても効率化につながらない

これからの事業の成長に欠かせない思考法がわかる。

目次

目次

1章 完成しても、終わりではない

• システムは使い始めてから改善が始まる
• なぜ、ソフトウェアなのに固くなってしまうのか
• プロジェクトからプロダクトの考え方に変える

2章 人を増やしても速く作れるわけではない

• 2倍の予算があっても2倍の生産性にはならない
• 遅れているプロジェクトに人を追加するのはやめて
• 銀の弾丸はないが「金の弾丸」なら有効なときがある
• 速く作ることはできないが、速く作れるチームは作れる
• チームの哲学や文化が揃っていることが大事

3章 たくさん作っても生産性が高いとは言えない

• あらゆる状況を考慮するのに時間がかかる
• プログラムは現実の理解の上に成り立つ
• 影響範囲に気をつけて、重複をなくすことも仕事
• 同じソフトウェアを複数人で同時改修するのは非効率
• 生産性は、手を動かした時間で測らない

4章 人に依存せず同じ品質で作ることはできない

• ソフトウェアは一品モノ、1つずつ中身が違う
• 外から見える品質と、見ることのできない品質
• エンジニアにしかわからないプログラムの美しさ
• クリエイティブな仕事の属人化を解決する

5章 プレッシャーをかけても生産性は上がらない

• 急がせたところで速く作ることはできない
• 一時的な妥協は、永遠の負債になる
• 作れば作るほど、生産性は落ちていく
• 生産性が上がる仕組みを作ることは投資
• 楽をするための苦労はいとわない

6章 見積もりは求めるほどに絶望感は増す

• なぜ、正確な見積もりが出せないのか
• 見積もりを守るためのバッファの功罪
• 見積もりと約束が「受発注」の関係を作ってしまう
• 事業側と開発側が「協働」の関係を築く
• 「納品」をなくせばうまくいく

7章 一度に大きく作れば得に見えて損をする

• プロジェクトが大きくなるとうまくいきにくいのに、なぜプロジェクトは大きくなってしまうのか
• ソフトウェア開発はギャンブルのようなもの、大きく賭けると大きく失敗する
• 小さくすれば不確実さを下げられる
• 小さく作って、大きく育てられるのがソフトウェア
• プロジェクトを小さくするために、作ろうとする機能の範囲を限定する
• 不確実な未来を、少しずつ確実なものにしていく

8章 工程を分業しても、効率化につながらない

• 工程を分離しても生産性は上がらない
• 猫の手を借りても生産性は上がらない
• プログラムは最も低い品質に引っ張られる
• ソフトウェアの設計はだれのものか

感想

著者が「はじめに」で書いている通り、プログラミングを知らない多忙な経営者や事業責任者が、ソフトウェアを作る上で知っておくべき本質の最低限の部分について理解できるよう、簡単な言葉で書かれているなという印象です。
全体を通してわかりやすい例えがあって、更に読みやすくなっていると思います。
本文から抜粋してみます。

※なぜリリース後に改修が難しく、コストがかかってしまうことがあるのかを説明する場面においての例え
ソフトウェアは緻密なジェンガのようなものだと思ってください。雑に乗っけてしまうほどに、後から乗せるのが難しくなり、いずれ崩壊してしまいます。

※なぜ正確な見積もりが出せないのかということを説明する場面において
例えば東京に自宅があるとして、そこから富士山の頂上まで登ることを見積もってみるとしたらどうでしょうか。地図があって直線距離が分かったとしても、途中の道筋は直線ではないし、高低差だってあるし、どの乗り物に乗るか、それを何人で行くのか、行く人の年齢や体力によっても変わってきます。さて、ざっくりと見積もれるでしょうか？

このように誰にでも感覚的に分かりやすい例えがあるので、エンジニアもこのような例え話を参考にしてみると、エンジニア以外の人とも話がしやすくなるのではないでしょうか。

「エンジニア」「非エンジニア」という括りでの話というよりは、「ソフトウェア開発に携わる全ての人」がこの本に書いてあることを理解した上で開発に携わると、関係者全員の幸福度が上がりそうです。

エンジニアの皆さんの中には「どうせ言っても分かってもらえないし…」と諦めている節が半ばあって、「どこまで説明するべきか・妥協しないべきか」については悩ましい部分もあると思います。しかし、この本を読めば、技術負債の先送りや、大きく一度に完璧を目指して作ろうとしたりすることを求められた時に、それがいかに危険で事業に悪影響を及ぼすかなどを根気よく説明することも開発者としての責務であると思えるのではないでしょうか。
協働するためには相互理解が絶対条件となりますので、この本がその相互理解の架け橋になるでしょう。１〜２時間もあれば読めてしまう本なので、ぜひ忙しい方も読んでみてほしいと思います。