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

著者 : 倉貫義人

• 技術評論社 (2023年6月10日発売)

感想・レビュー・書評

[おぬまさんの感想 · 2023年12月24日]

図書館で借りた。
ソフトウェア開発に関する、「中々上手く行かないよね」なビジネス書。分かりやすい文章でシンプルにまとまっている。
「ソフトウェアとか分からん」な経営者向きかと感じた。専門である私にとっては実りは少なかったかな。

[flasksrwさんの感想 · 2023年11月19日]

ソフトウェア開発の性質をエンジニアではない経営者や管理職向けに説明した本。エンジニアにとっては当たり前のことしか書かれていない。
本の主題よりも文章の質のほうが気になった。メインターゲットを高校生程度の知能と仮定して文章を書いているように見える。参考文献は付いているが、具体的なエビデンスはない。管理職は大抵大卒の筈なのに、ここまで平易な文章でないと読めないほど知能が低いと言うことなんだろうか。日本のDXが進まないのは管理職のレベルが低すぎるから？

[japapizzaさんの感想 · 2023年11月18日]

　システム開発がプロジェクトからプロダクト中心に変わると、関わる人たちの関係性も変わることになります。これまでの完成を目指したシステム開発であれば、「システムを依頼する人たち」と「システムを開発する人たち」という形で分かれていました。しかし、社外に限らず社内であっても受発注のような関係では、変化に柔軟に適応していくシステムは手に入りません。動かし始めてから、次々と直したいところが出てきても、その度に発注するように依頼することになってしまうからです。プロダクトという共通の成果物と、目指す共通の目標を持つことで、システムは「依頼して作ってもらうもの」から「協働して一緒に作るもの」に変わります。そして、システムは完成を目指すものでなく、事業と共に改善を続けるものになるのです。成長し続けるために、変化に適応できるソフトウェアの作り方と考え方を身につけましょう。

■なぜ正確な見積もりが出せないのか
・詳細までの仕様を把握しきれなかった
・例外的な処理を把握しきれなかった
・想定していた技術が使えなかった
・担当する人によってばらつきがある


　事業側と開発側が受発注の関係ではなく、共通のゴールを目指す同じチームとして協働の関係を築くためには、システムを作ることだけを目的とした体制やマネジメントをしないことです。あくまで事業や活動があり、その成長や成果のためにシステムを作るとするのです。
　そのためには、まず「大きな機能の見積もりは、あくまで見通しである」というスタンスでいることです。一度に機能も期間も大きな約束をして、あとは出来上がるのを待つのではなく、1~2週間の単位で少しずつ確認しながら作っていくのがいいでしょう。それぐらいの期間であれば、どれくらいの進捗を出すことができるのかは精度を高めに見積もることが可能です。エンジニアではない人間からすると、エンジニアたちが何をしているのかわからないため、きちんと頑張っているのかどうか不安になるわけです。しかし、ある程度の頻度で、作るべきサイズを小さくすれば、進んでいるかどうかは確認できます。


　大規模なソフトウェアは、一度に作るのではなく、小さなソフトウェアに分解し、小さなプロジェクトとして何回かに分けて進めていくことで、失敗のリスクを小さくすることができます。それも、実際に動くところまでをゴールとしたプロジェクトにすることが肝要です。ソフトウェアは動いてこそ価値があり、使ってこそ直したい箇所が見つかるからです。
　そして、何度も打席に立ち、自分たちのプロセスや取り組み方に学びを得ることで、ソフトウェア自体の不確実さは解消されないにせよ、進め方のノウハウが溜まることで成功確率を上げていくことができます。同じチームで、小さなプロジェクトに何度も挑戦していくことで、チームビルディングも進むでしょう。

[to4ikiさんの感想 · 2023年11月16日]

本書は、サブタイトルに「変化を抱擁せよ」とある通り、変化が起きる前提でどのような姿勢で向き合うかエンジニア誰もが感じる部分を言語化している。

以下は、気になった文章のメモ

・ある一点の完成を目指すことは逆に言えば一度だけ完成すればいいということになる。そうなると、完成後のことより完成させることに力学が働く。
・プログラムは現実の理解の上に成り立つ
・プログラムを書く仕事で求められるのは抽象化能力
・一時的な妥協は永遠の負債になる
・シンプル化する。借金を返済し続ける
・目の前の生産性を上げるのか。それとも、生産性を上げる仕組みを作るのか。
・大きな機能の見積もりは、あくまでも見通しである
・不確実な未来を、少しずつ確実なものにしていく
・ソフトウェアを作ると言うことは新規事業の創出や研究開発のようなもの。レシピを作る仕事に手を動かすだけの人は不要
・プログラムは最も低い品質に引っ張られる

[bob-taniさんの感想 · 2023年10月28日]

ソフトウェア開発のクセを知る。
なんにもわからなくてもそうなんだとなる作りで丁寧。
変化を受け入れるチームづくりに必要なギャップが並んでいる。
ソフトウェアを人間に見立てる考えはヒントになる。
違う手術を二人の医者が同時にやる難しさはたしかに。
人間と違って24時間動くことができるから完全無欠に見えるけど、
栄養やら経年による変化や時には手術やら無理したことで古傷残るのような変化があるメタファーをうまく使えたらなと思えた。

[ryokucha334さんの感想 · 2023年10月17日]

アジャイルの考えを平易かつ簡潔に説明した本。アジャイルの勉強を始めたばかりの自分にとっては、これまでの学びを別の表現で復習できた。

◾️覚えておきたい標語
近い未来は解像度を高く、遠い未来は曖昧なまま

◾️見積もり
・見積もり精度を高めるために、どこまでも詳細に考えていくとしたら、それはもはやそれは設計である。つまり、限りなく正確な見積もりは、実際にやってみることでしか出せない。
・大きな機能の見積もりは、あくまで見通しである。1〜2週間の期間であれば、どれくらいの進捗を出すことができるのかを、高めの精度で見積もることができる。

◾️本書のテーマ外だけど覚えておきたいこと
・コードレビューは属人性の排除に有効。優れたエンジニアに指摘してもらうことで品質の向上が見込め、かつ、良いプログラムの書き方を学ぶことができる。
・週に一度、1時間を「ふりかえり」の時間にして、仕事を通じて経験したことを抽象化、言語化する。これを学びとして、次の仕事に活かす。

[wahleeさんの感想 · 2023年10月14日]

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

[tyさんの感想 · 2023年10月12日]

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

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

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

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

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

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

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

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

[fraserlibさんの感想 · 2023年10月12日]

請求記号　007.61/Ku 53

[tattyammさんの感想 · 2023年9月30日]

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

著者プロフィール

株式会社ソニックガーデンの創業者で代表取締役社長。1974年生まれ。京都府出身。小学生からプログラミングを始め、天職と思える仕事に就こうと大手システム会社に入社するも、プログラマ軽視の風潮に挫折。転職も考えたが、会社を変えるためにアジャイル開発を日本に普及させる活動を個人的に開始。会社では、研究開発部門の立ち上げ、社内SNSの企画と開発、オープンソース化をおこない、自ら起業すべく社内ベンチャーを立ち上げるまでに至る。しかし、経営の経験などなかったために当初は大苦戦。徹底的に管理する方法で新規事業はうまくいかないと反省。徐々に管理をなくしていくことで成果をあげる。最終的には事業を軌道に乗せて、その社内ベンチャーをマネジメント・バイ・アウト（経営者による買収）することで独立を果たして、株式会社ソニックガーデンを設立。ソニックガーデンでは、月額定額＆成果契約の顧問サービス提供する新しい受託開発のビジネスモデル「納品のない受託開発」を展開。その斬新なビジネスモデルは、船井財団「グレートカンパニーアワード」にてユニークビジネスモデル賞を受賞。

「2023年 『人が増えても速くならない　～変化を抱擁せよ～』 で使われていた紹介文から引用しています。」