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

倉貫義人

ユーザー数が伸びるにつれて多くの要望が出てきても、新しい機能をスピーディーに追加できなくなってきた。
ちょっとした修正のはずなのに、ものすごく時間がかかる。
――そのようなことが起こる原因は、ソフトウェアが変化に適応できないから。

プログラミングを学んでも理解できないソフトウェアの本質を、プログラマーとして12年、経営者として12年の経験を持つ著者が集大成。
・完成しても終わりではない
・人が増えても速くならない
・たくさん作っても生産性が高いとは言えない
・人に依存せず同じ品質にはできない
・プレッシャーをかけても生産性は上がらない
・見積もりを求めるほど絶望感は増す
・一度に大きく作ると得に見えて損をする
・工程で分担しても効率化につながらない

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

■目次
はじめに
1章 完成しても、終わりではない
システムは使い始めてから改善が始まる
なぜ、ソフトウェアなのに固くなってしまうのか
プロジェクトからプロダクトの考え方に変える
2章 人を増やしても速く作れるわけではない
2倍の予算があっても2倍の生産性にはならない
遅れているプロジェクトに人を追加するのはやめて
銀の弾丸はないが"金の弾丸"なら有効なときがある
速く作ることはできないが、速く作れるチームは作れる
チームの哲学や文化が揃っていることが大事
3章 たくさん作っても生産性が高いとは言えない
あらゆる状況を考慮するのに時間がかかる
プログラムは現実の理解の上に成り立つ
影響範囲に気をつけて、重複をなくすことも仕事
同じソフトウェアを複数人で同時改修するのは非効率
生産性は、手を動かした時間で測らない
4章 人に依存せず同じ品質で作ることはできない
ソフトウェアは一品モノ、1つずつ中身が違う
外から見える品質と、見ることのできない品質
エンジニアにしかわからないプログラムの美しさ
クリエイティブな仕事の属人化を解決する
5章 プレッシャーをかけても生産性は上がらない
急がせたところで速く作ることはできない
一時的な妥協は、永遠の負債になる
作れば作るほど、生産性は落ちていく
生産性が上がる仕組みを作ることは投資
楽をするための苦労はいとわない
6章 見積もりを求めるほどに絶望感は増す
なぜ、正確な見積もりが出せないのか
見積もりを守るためのバッファの功罪
見積もりと約束が"受発注"の関係を作ってしまう
事業側と開発側が"協働"の関係を築く
「納品」をなくせばうまくいく
7章 一度に大きく作れば得に見えて損をする
プロジェクトが大きくなるとうまくいきにくいのに、なぜプロジェクトは大きくなってしまうのか
ソフトウェア開発はギャンブルのようなもの、大きく賭けると大きく失敗する
小さくすれば不確実さを下げられる
小さく作って、大きく育てられるのがソフトウェア
プロジェクトを小さくするために、作ろうとする機能の範囲を限定する
不確実な未来を、少しずつ確実なものにしていく
8章 工程を分業しても、効率化につながらない
工程を分離しても生産性は上がらない
猫の手を借りても生産性は上がらない
プログラムは最も低い品質に引っ張られる
ソフトウェアの設計はだれのものか
おわりに

• カテゴリ: ビジネス・実用
• ジャンル: ビジネス・経済 / 経営・企業
• 出版社: 技術評論社
• タイトル: 人が増えても速くならない ～変化を抱擁せよ～
• タイトルID: 1368080
• ページ数: 136ページ
• 電子版発売日: 2023年06月10日
• コンテンツ形式: EPUB
• サイズ(目安): 3MB

[ブクログ · ★★★★★]

人が増えても速くならない、人に依存せず同じ品質で作ることはできない、プレッシャーをかけても生産性は上がらない、見積もりを求めるほどに絶望感は増す、などグサグサ刺されるような内容ばかり。特に印象に残ったのは、相互コードレビューをし合うことで、1人の成果をチームの成果に昇華させるというところ。1人のインプットやアウトプットをチームや、組織の成果に昇華させるという意識を持ち、普段から共有し合うチーム文化、組織文化を作ることに貢献したいと思いました。

[ブクログ · ★★★★★]

タイトルが現場のエンジニアからは当たり前であることから伝わるように、ソフトウェア開発の現場向けというよりも、そこに発注する方に向けた内容と言えます。
その文脈において開発に対して想像していることと、実際に発生する内容との違いが明確になっており、かつシンプルにまとまっています。

[ブクログ · ★★★★★]

経営層に向けたソフトウェア開発の特性とビジネスとのギャップに関する書籍。というか、Devと事業側という構図がある限りどういった組織でも発生しうる問題であり、対象範囲はとても広いと感じた。協働を目指していくにあたり広くお勧めしたい一冊。ボリュームが程よくとても読みやすい点も良。

[ブクログ · ★★★★★]

ページは少なく図なども無いが、内容としてはソフトウェア開発で陥りがちな誤った意思決定を指摘した堅実な本だと思った。
パーキンソンの第一法則とブルックスの法則は必ず念頭に置くべき法則と思う。
特にブルックスの法則に関しては、同じ過ちを繰り返す企業が多いので要注意だ(ソフトウェア人材を〇〇人補充、みたいなやつ)
また、工程を分けても生産性は上がらないというのもなかなか面白い意見だと思う。ウォーターフォールモデルで作る限り、全ての工程は相互に作用し合っている。工程間でエンジニア力に差があるとそこに引っ張られて生産性が上がらなくなる、という話だった。

[ブクログ · ★★★★☆]

見事に受託開発の問題点を示している。
素晴らしい本だった。

* 人を増やしたからといって、速く作れるわけではない
* 正確な見積もりを求めたら、見積もりが膨らんでしまう
* 一度に大きく作ろうとするほど、結局は損をしてしまう

第1章
完成しても、終わりではない
システムは使い始めてから改善が始まる
システムが動き始めてからの修正を難しくする原因
①行きあたりばったりで改修を加えてしまう。ソフトウェアは精緻なジェンガみたいなもの
②一度きりの完成を目指してしまう
プロジェクトからプロダクトの考え方に変える
協働して一緒に作るもの

第2章
人を増やしても速く作れるわけでない
エンジニアの行っているプログラミングは、家の設計士のやっている仕事になる、とても頭を使う仕事なので、増やしたからといっても生産性が上がるわけではない

「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」
『人月の神話』「ブルックスの法則」
遅れる３つの理由
①あとから入った人の情報や知識のキャッチアップと、その人たちへの教育にコストがかかる
②関わる人数が増えると、メンバー同士でのコミュニケーションにかかる時間が増えてしまう
③タスクを分解するにも限度がある
この問題解決には2つの方法（金の弾丸）
①高い生産性を出せるような環境を用意する
②クラウドに移管したうえで、クラウドの性能を増強する

速く作れるチームは作れる

第3章
たくさん作っても生産性が高いとは言えない
あらゆる状況を考慮するのに時間がかかる
その機能がなぜ必要なのか、事業にとってどういう意味があるのかが、伝わると効果的
影響範囲に気をつけて、重複をなくすことも仕事
同じソフトウェアを複数人で同時改修するのは非効率
プログラムは、どれだけ書いたのかの量ではなく、中身の質こそ大事
機能も少ないシンプルなものでいた方が良い

第4章
人に依存せず同じ品質で作ることはできない
ソフトウェアは、すべてが一品モノ
属人化を解決し、中身の品質を担保するためには、コードレビューが良い

第5章
プレッシャーをかけても生産性は上がらない
一時的な妥協は、永遠の負債になる（技術的負債）、対策としては少し作っては、シンプルな状態を維持できるように手を加え続けること
バージョンアップは動作確認が必要なので相当なコストがかかる
動作確認の自動テストは最初のコストがかかるが、後々いい
週に一度、1時間は「ふりかえり」の時間を取って、仕事のやり方やプロセスを見直すのがオススメ

第6章
見積もりを求めるほどに絶望感は増す
ソフトウェアを開発するのに、どれくらいの時間がかかるのかをざっくり知りたいという、事業側の気軽な発言が、エンジニアにとってはとてつもなく難しいことだとは知られていません
ざっくりの見積もりだと外れてしまうのは、次のようなケース
・詳細までの仕様を把握しきれなかった
動かしてみてはじめて必要な機能がわかることがあります
・例外的な処理を把握しきれなかった
・想定していた技術が使えなかった
・担当する人によってばらつきがある

エンジニアにしてみると、見積もりは"約束"に近い感覚があるため、かんたんには出したくない
そこからバッファを積まざるをえない、そしてマネージャーはさらに根拠なくバッファを積む、「パーキンソンの第1法則」

見積もりと約束が"受発注"の関係を作ってしまう
システムはマイナスからのスタート
システムは、事業や活動が内包している一部
システム開発で目指したい姿は、事業や活動のミッションを達成するための"協働"の関係
システムを作ることだけを目的とした体制やマネジメントをしないこと
まず「大きな機能の見積もりは、あくまで見通しである」というスタンスでいることです。一度に機能も期間も大きな約束をして、あとは出来上がるのを待つのではなく、1~2週間の単位で少しずつ確認しながら作っていくのがいいでしょう。それぐらいの期間であれば、どれくらいの進捗を出すことができるのかは精度を高めに見積もることが可能です。
ポイントは、「機能ありきで期間を見積もる」のではなく、「期間ありきで機能を見積もる」ことです。限られた人員と期間の中で、できる範囲で動くシステムを作っていくこと。それを、エンジニアだけで進めるのではなく、事業側の役割を持った人間も含めたチームとして確認して進めていくことです。
チームとなることで、「何を作るのか」を決めてからエンジニアに依頼するのではなく、「何を実現したいのか」から相談することになります。
開発したシステムは順次使い始め、フィードバックを得て改善していく

「納品」をなくせばうまくいく
ソニックガーデンでは月額定額の顧問型サービス「納品のない受託開発」を提供

第7章
一度に大きく作れば得に見えて損をする
ソフトウェア開発において、大規模なプロジェクトにすることのメリットは「ない」と断言しても過言ではありません。
ソフトウェア開発はギャンブルのようなもの、
大きく賭けると大きく失敗する
ソフトウェア開発のプロジェクトは、不確実さとの戦いでもあります。“プロジェクト”と言いつつも、ソフトウェア開発は製造ではなく、試行錯誤が不可久な研究開発に近いため、予算と期間の中でまちがいなく進むことを管理するスタイルのマネジメントは向いていません。
小さくすれば不確実さを下げられる
大規模なソフトウェアは、一度に作るのではなく、小さなソフトウェアに分解し、小さなプロジェクトとして何回かに分けて進めていくことで、失敗のリスクを小さくすることができます。それも、実際に動くところまでをゴールとしたプロジェクトにすることが肝要です。
小さく作って、大きく育てられるのがソフトウェアだが、ソフトウェアの特性を活かした作り方や体制で開発していないと難しいとなる
少しずつ確信を持ちながら少しずつ進めていくのは、新規事業や業務改善において欠かすことのできないアプローチになります。
作ろうとする機能の範囲を限定し、技術や仕様で不明確な部分を無くすと見積もりが正しくなりやすい。そして仕様を明確にすると言って設計書を用意する必要はない。そもそも、仕様を把握する人間とプログラミングする人間は同一人物であるべきなのです。
優先順位を決めてスコープを狭め、不確実性を下げた状態で作り出し進めていく

第8章
工程を分業にしても、効率化につながらない
ソフトウェアを作るということは、新規事業の創出や、研究開発のようなものです。
ソフトウェア開発には雑用がないし、1～2ヶ月ほど現場にいたからといって慣れてできるようになる仕事もありません。

おわりに
「変化に対して管理やコントロールをしようとするのではなく、あるがまま受け入れつつ柔軟につきあっていくこと」が著者の主張

[ブクログ · ★★★★☆]

＜本のタイトル＞
人が増えても速くならない　～変化を抱擁せよ～

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

＜何が書いてあったか（誰でも書ける）＞
・システムは使い始めてから改善が始まる。リリースはスタート地点に過ぎない
　ー想定外の新しい要望が出てくる
　ー使い始めたらかえって生産性が落ちてしまったとかもありえる
　ーユーザーが増えると負荷が高まってパフォーマンスが落ちる
　ー法律が改正されて業務フローの変更を余儀なくされる

・ソフトウェアは精緻なジェンガみたいなもの。
　行き当たりばったりの改修ではどんどん複雑になり、混乱の極みにやがて陥る
　「とにかくシンプルに作ること」と「少しずつ作って手を加え続けること」が大切。

・システムは完成を目指すものではなく、事業とともに改善を続けるもの
　また「依頼して作ってもらうもの」ではなく、「協同して一緒に作るもの」である。

・メンバー同士の信頼関係があり、心理的安全性が高く、開発哲学やポリシーが
　そろっている状態になれば高い生産性を発揮することができるが、一朝一夕では築けない。
　ソフトウェアを育てると同時に、開発チームも同時に育てることで、
　持続的にスピード感をもって変化に適応できるソフトウェアを手に入れることができる。

＜そこから何を学んだか（自分自身のオリジナルの意見）＞
・メンバー同士の信頼関係があり、心理的安全性が高く、開発哲学やポリシーが
　そろっている状態になれば高い生産性を発揮することができるが、一朝一夕では築けない。
　ソフトウェアを育てると同時に、開発チームも同時に育てることで、
　持続的にスピード感をもって変化に適応できるソフトウェアを手に入れることができる。

＜それをどう活かすか（アウトプットによる実践経験の蓄積）＞
信頼関係や心理的安全性だけではまだ十分ではなく、
開発哲学やポリシーというのを明文化する動きも必要と感じた。

[ブクログ · ★★★★☆]

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

株式会社ソニックガーデンの創業者である倉貫義人 氏の著書です。

ソフトウェアエンジニアの常識は、非ソフトウェアエンジニアの方には全然理解されていません。結果、プロジェクトを進める上で共通認識を持つことができずに難航することはあるあるだと思います。
この本は著者の経験に基づき、非ソフトウェアエンジニアの方にもソフトウェアの特性、本質を理解してもらえるように解説した内容になっています。

経験の浅いエンジニアにもおすすめです。

【本書で学べること・考えること】
- プロジェクトとプロダクトの違い
- 開発速度に関する、人やお金の考え方
- 生産性の考え方
- 品質（外から見える品質、内部品質）
- プレッシャーと生産性
- 正確な見積り
- 小さく、シンプルに作るメリット
- ソフトウェアの分業と生産性

読んでみての感想です。

量も少なく、内容も平易なのがハードルが低くて良いです。

私自身、仕事で非エンジニアの方と見積りや仕様などの調整も行いますが、ソフトウェアの内部構造的な問題点を伝えるのに苦慮します。
本書は、非エンジニアの方にもわかりやすく書かれていて、ソフトウェアの本質や特徴を理解してもらう一助になると思います。
また、経験の浅いエンジニアにも理解の一助になります。

今後、この本の説明をベースに非エンジニアの方にわかりやすく説明していきたいと考えています。

[ブクログ · ★★★★☆]

非エンジニア向けだけれども、事業側とのコミュニケーションをかんがえる上でもヒントになるような卓越した言語化

[ブクログ · ★★★★☆]

非エンジニアの経営層、事業部長レイヤーの方々に是非読んで頂きたい一冊だ！例えがとてもわかりやすく、1時間程度でサクッと読めてよかった！

[ブクログ · ★★★★☆]

ソフトウェアエンジニアリングの仕事について、ありがちな誤解やアンチパパターンを経営者や事業責任者にも分かるように説明されている。特に生産性やモチベーションを悪気なく下げてしまうケースに言及されており、思うように開発が進まなかったり、人材の流出に悩んでいるなら本書を学ぶと良いだろう。
全体的に表現が平易でわかりやすく、ページ数が少ないので負担なく読める。著者の倉貫さんの本は毎回読みやすくなっているが、その中でも本書は特に読みやすくなっている。
書いてある内容はエンジニア目線で共感できるものが多い。また、逆に多くのエンジニアができていないことへの言及もある。エンジニア以外の人にぜひ読んでもらいたいし、エンジニアも読んで態度を改めるべきだと思う。「そのやり方、誰も幸せにならないからやめませんか？」という対話をしていこう。