あらすじ
ユーザー数が伸びるにつれて多くの要望が出てきても、新しい機能をスピーディーに追加できなくなってきた。
ちょっとした修正のはずなのに、ものすごく時間がかかる。
――そのようなことが起こる原因は、ソフトウェアが変化に適応できないから。
プログラミングを学んでも理解できないソフトウェアの本質を、プログラマーとして12年、経営者として12年の経験を持つ著者が集大成。
・完成しても終わりではない
・人が増えても速くならない
・たくさん作っても生産性が高いとは言えない
・人に依存せず同じ品質にはできない
・プレッシャーをかけても生産性は上がらない
・見積もりを求めるほど絶望感は増す
・一度に大きく作ると得に見えて損をする
・工程で分担しても効率化につながらない
これからの事業の成長に欠かせない思考法がわかる。
■目次
はじめに
1章 完成しても、終わりではない
システムは使い始めてから改善が始まる
なぜ、ソフトウェアなのに固くなってしまうのか
プロジェクトからプロダクトの考え方に変える
2章 人を増やしても速く作れるわけではない
2倍の予算があっても2倍の生産性にはならない
遅れているプロジェクトに人を追加するのはやめて
銀の弾丸はないが"金の弾丸"なら有効なときがある
速く作ることはできないが、速く作れるチームは作れる
チームの哲学や文化が揃っていることが大事
3章 たくさん作っても生産性が高いとは言えない
あらゆる状況を考慮するのに時間がかかる
プログラムは現実の理解の上に成り立つ
影響範囲に気をつけて、重複をなくすことも仕事
同じソフトウェアを複数人で同時改修するのは非効率
生産性は、手を動かした時間で測らない
4章 人に依存せず同じ品質で作ることはできない
ソフトウェアは一品モノ、1つずつ中身が違う
外から見える品質と、見ることのできない品質
エンジニアにしかわからないプログラムの美しさ
クリエイティブな仕事の属人化を解決する
5章 プレッシャーをかけても生産性は上がらない
急がせたところで速く作ることはできない
一時的な妥協は、永遠の負債になる
作れば作るほど、生産性は落ちていく
生産性が上がる仕組みを作ることは投資
楽をするための苦労はいとわない
6章 見積もりを求めるほどに絶望感は増す
なぜ、正確な見積もりが出せないのか
見積もりを守るためのバッファの功罪
見積もりと約束が"受発注"の関係を作ってしまう
事業側と開発側が"協働"の関係を築く
「納品」をなくせばうまくいく
7章 一度に大きく作れば得に見えて損をする
プロジェクトが大きくなるとうまくいきにくいのに、なぜプロジェクトは大きくなってしまうのか
ソフトウェア開発はギャンブルのようなもの、大きく賭けると大きく失敗する
小さくすれば不確実さを下げられる
小さく作って、大きく育てられるのがソフトウェア
プロジェクトを小さくするために、作ろうとする機能の範囲を限定する
不確実な未来を、少しずつ確実なものにしていく
8章 工程を分業しても、効率化につながらない
工程を分離しても生産性は上がらない
猫の手を借りても生産性は上がらない
プログラムは最も低い品質に引っ張られる
ソフトウェアの設計はだれのものか
おわりに
感情タグBEST3
Posted by ブクログ
人が増えても速くならない、人に依存せず同じ品質で作ることはできない、プレッシャーをかけても生産性は上がらない、見積もりを求めるほどに絶望感は増す、などグサグサ刺されるような内容ばかり。特に印象に残ったのは、相互コードレビューをし合うことで、1人の成果をチームの成果に昇華させるというところ。1人のインプットやアウトプットをチームや、組織の成果に昇華させるという意識を持ち、普段から共有し合うチーム文化、組織文化を作ることに貢献したいと思いました。
Posted by ブクログ
タイトルが現場のエンジニアからは当たり前であることから伝わるように、ソフトウェア開発の現場向けというよりも、そこに発注する方に向けた内容と言えます。
その文脈において開発に対して想像していることと、実際に発生する内容との違いが明確になっており、かつシンプルにまとまっています。
Posted by ブクログ
経営層に向けたソフトウェア開発の特性とビジネスとのギャップに関する書籍。というか、Devと事業側という構図がある限りどういった組織でも発生しうる問題であり、対象範囲はとても広いと感じた。協働を目指していくにあたり広くお勧めしたい一冊。ボリュームが程よくとても読みやすい点も良。
Posted by ブクログ
ページは少なく図なども無いが、内容としてはソフトウェア開発で陥りがちな誤った意思決定を指摘した堅実な本だと思った。
パーキンソンの第一法則とブルックスの法則は必ず念頭に置くべき法則と思う。
特にブルックスの法則に関しては、同じ過ちを繰り返す企業が多いので要注意だ(ソフトウェア人材を〇〇人補充、みたいなやつ)
また、工程を分けても生産性は上がらないというのもなかなか面白い意見だと思う。ウォーターフォールモデルで作る限り、全ての工程は相互に作用し合っている。工程間でエンジニア力に差があるとそこに引っ張られて生産性が上がらなくなる、という話だった。
Posted by ブクログ
見事に受託開発の問題点を示している。
素晴らしい本だった。
* 人を増やしたからといって、速く作れるわけではない
* 正確な見積もりを求めたら、見積もりが膨らんでしまう
* 一度に大きく作ろうとするほど、結局は損をしてしまう
第1章
完成しても、終わりではない
システムは使い始めてから改善が始まる
システムが動き始めてからの修正を難しくする原因
①行きあたりばったりで改修を加えてしまう。ソフトウェアは精緻なジェンガみたいなもの
②一度きりの完成を目指してしまう
プロジェクトからプロダクトの考え方に変える
協働して一緒に作るもの
第2章
人を増やしても速く作れるわけでない
エンジニアの行っているプログラミングは、家の設計士のやっている仕事になる、とても頭を使う仕事なので、増やしたからといっても生産性が上がるわけではない
「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」
『人月の神話』「ブルックスの法則」
遅れる３つの理由
①あとから入った人の情報や知識のキャッチアップと、その人たちへの教育にコストがかかる
②関わる人数が増えると、メンバー同士でのコミュニケーションにかかる時間が増えてしまう
③タスクを分解するにも限度がある
この問題解決には2つの方法（金の弾丸）
①高い生産性を出せるような環境を用意する
②クラウドに移管したうえで、クラウドの性能を増強する
速く作れるチームは作れる
第3章
たくさん作っても生産性が高いとは言えない
あらゆる状況を考慮するのに時間がかかる
その機能がなぜ必要なのか、事業にとってどういう意味があるのかが、伝わると効果的
影響範囲に気をつけて、重複をなくすことも仕事
同じソフトウェアを複数人で同時改修するのは非効率
プログラムは、どれだけ書いたのかの量ではなく、中身の質こそ大事
機能も少ないシンプルなものでいた方が良い
第4章
人に依存せず同じ品質で作ることはできない
ソフトウェアは、すべてが一品モノ
属人化を解決し、中身の品質を担保するためには、コードレビューが良い
第5章
プレッシャーをかけても生産性は上がらない
一時的な妥協は、永遠の負債になる（技術的負債）、対策としては少し作っては、シンプルな状態を維持できるように手を加え続けること
バージョンアップは動作確認が必要なので相当なコストがかかる
動作確認の自動テストは最初のコストがかかるが、後々いい
週に一度、1時間は「ふりかえり」の時間を取って、仕事のやり方やプロセスを見直すのがオススメ
第6章
見積もりを求めるほどに絶望感は増す
ソフトウェアを開発するのに、どれくらいの時間がかかるのかをざっくり知りたいという、事業側の気軽な発言が、エンジニアにとってはとてつもなく難しいことだとは知られていません
ざっくりの見積もりだと外れてしまうのは、次のようなケース
・詳細までの仕様を把握しきれなかった
動かしてみてはじめて必要な機能がわかることがあります
・例外的な処理を把握しきれなかった
・想定していた技術が使えなかった
・担当する人によってばらつきがある
エンジニアにしてみると、見積もりは"約束"に近い感覚があるため、かんたんには出したくない
そこからバッファを積まざるをえない、そしてマネージャーはさらに根拠なくバッファを積む、「パーキンソンの第1法則」
見積もりと約束が"受発注"の関係を作ってしまう
システムはマイナスからのスタート
システムは、事業や活動が内包している一部
システム開発で目指したい姿は、事業や活動のミッションを達成するための"協働"の関係
システムを作ることだけを目的とした体制やマネジメントをしないこと
まず「大きな機能の見積もりは、あくまで見通しである」というスタンスでいることです。一度に機能も期間も大きな約束をして、あとは出来上がるのを待つのではなく、1~2週間の単位で少しずつ確認しながら作っていくのがいいでしょう。それぐらいの期間であれば、どれくらいの進捗を出すことができるのかは精度を高めに見積もることが可能です。
ポイントは、「機能ありきで期間を見積もる」のではなく、「期間ありきで機能を見積もる」ことです。限られた人員と期間の中で、できる範囲で動くシステムを作っていくこと。それを、エンジニアだけで進めるのではなく、事業側の役割を持った人間も含めたチームとして確認して進めていくことです。
チームとなることで、「何を作るのか」を決めてからエンジニアに依頼するのではなく、「何を実現したいのか」から相談することになります。
開発したシステムは順次使い始め、フィードバックを得て改善していく
「納品」をなくせばうまくいく
ソニックガーデンでは月額定額の顧問型サービス「納品のない受託開発」を提供
第7章
一度に大きく作れば得に見えて損をする
ソフトウェア開発において、大規模なプロジェクトにすることのメリットは「ない」と断言しても過言ではありません。
ソフトウェア開発はギャンブルのようなもの、
大きく賭けると大きく失敗する
ソフトウェア開発のプロジェクトは、不確実さとの戦いでもあります。“プロジェクト”と言いつつも、ソフトウェア開発は製造ではなく、試行錯誤が不可久な研究開発に近いため、予算と期間の中でまちがいなく進むことを管理するスタイルのマネジメントは向いていません。
小さくすれば不確実さを下げられる
大規模なソフトウェアは、一度に作るのではなく、小さなソフトウェアに分解し、小さなプロジェクトとして何回かに分けて進めていくことで、失敗のリスクを小さくすることができます。それも、実際に動くところまでをゴールとしたプロジェクトにすることが肝要です。
小さく作って、大きく育てられるのがソフトウェアだが、ソフトウェアの特性を活かした作り方や体制で開発していないと難しいとなる
少しずつ確信を持ちながら少しずつ進めていくのは、新規事業や業務改善において欠かすことのできないアプローチになります。
作ろうとする機能の範囲を限定し、技術や仕様で不明確な部分を無くすと見積もりが正しくなりやすい。そして仕様を明確にすると言って設計書を用意する必要はない。そもそも、仕様を把握する人間とプログラミングする人間は同一人物であるべきなのです。
優先順位を決めてスコープを狭め、不確実性を下げた状態で作り出し進めていく
第8章
工程を分業にしても、効率化につながらない
ソフトウェアを作るということは、新規事業の創出や、研究開発のようなものです。
ソフトウェア開発には雑用がないし、1～2ヶ月ほど現場にいたからといって慣れてできるようになる仕事もありません。
おわりに
「変化に対して管理やコントロールをしようとするのではなく、あるがまま受け入れつつ柔軟につきあっていくこと」が著者の主張
Posted by ブクログ
本書は、サブタイトルに「変化を抱擁せよ」とある通り、変化が起きる前提でどのような姿勢で向き合うかエンジニア誰もが感じる部分を言語化している。
以下は、気になった文章のメモ
・ある一点の完成を目指すことは逆に言えば一度だけ完成すればいいということになる。そうなると、完成後のことより完成させることに力学が働く。
・プログラムは現実の理解の上に成り立つ
・プログラムを書く仕事で求められるのは抽象化能力
・一時的な妥協は永遠の負債になる
・シンプル化する。借金を返済し続ける
・目の前の生産性を上げるのか。それとも、生産性を上げる仕組みを作るのか。
・大きな機能の見積もりは、あくまでも見通しである
・不確実な未来を、少しずつ確実なものにしていく
・ソフトウェアを作ると言うことは新規事業の創出や研究開発のようなもの。レシピを作る仕事に手を動かすだけの人は不要
・プログラムは最も低い品質に引っ張られる
Posted by ブクログ
＜本のタイトル＞
人が増えても速くならない ～変化を抱擁せよ～
＜本の紹介＞
・完成しても終わりではない
・人が増えても速くならない
・たくさん作っても生産性が高いとは言えない
・人に依存せず同じ品質にはできない
・プレッシャーをかけても生産性は上がらない
・見積もりを求めるほど絶望感は増す
・一度に大きく作ると得に見えて損をする
・工程で分担しても効率化につながらない
＜何が書いてあったか（誰でも書ける）＞
・システムは使い始めてから改善が始まる。リリースはスタート地点に過ぎない
ー想定外の新しい要望が出てくる
ー使い始めたらかえって生産性が落ちてしまったとかもありえる
ーユーザーが増えると負荷が高まってパフォーマンスが落ちる
ー法律が改正されて業務フローの変更を余儀なくされる
・ソフトウェアは精緻なジェンガみたいなもの。
行き当たりばったりの改修ではどんどん複雑になり、混乱の極みにやがて陥る
「とにかくシンプルに作ること」と「少しずつ作って手を加え続けること」が大切。
・システムは完成を目指すものではなく、事業とともに改善を続けるもの
また「依頼して作ってもらうもの」ではなく、「協同して一緒に作るもの」である。
・メンバー同士の信頼関係があり、心理的安全性が高く、開発哲学やポリシーが
そろっている状態になれば高い生産性を発揮することができるが、一朝一夕では築けない。
ソフトウェアを育てると同時に、開発チームも同時に育てることで、
持続的にスピード感をもって変化に適応できるソフトウェアを手に入れることができる。
＜そこから何を学んだか（自分自身のオリジナルの意見）＞
・メンバー同士の信頼関係があり、心理的安全性が高く、開発哲学やポリシーが
そろっている状態になれば高い生産性を発揮することができるが、一朝一夕では築けない。
ソフトウェアを育てると同時に、開発チームも同時に育てることで、
持続的にスピード感をもって変化に適応できるソフトウェアを手に入れることができる。
＜それをどう活かすか（アウトプットによる実践経験の蓄積）＞
信頼関係や心理的安全性だけではまだ十分ではなく、
開発哲学やポリシーというのを明文化する動きも必要と感じた。
Posted by ブクログ
人が増えても速くならない ～変化を抱擁せよ～
株式会社ソニックガーデンの創業者である倉貫義人 氏の著書です。
ソフトウェアエンジニアの常識は、非ソフトウェアエンジニアの方には全然理解されていません。結果、プロジェクトを進める上で共通認識を持つことができずに難航することはあるあるだと思います。
この本は著者の経験に基づき、非ソフトウェアエンジニアの方にもソフトウェアの特性、本質を理解してもらえるように解説した内容になっています。
経験の浅いエンジニアにもおすすめです。
【本書で学べること・考えること】
- プロジェクトとプロダクトの違い
- 開発速度に関する、人やお金の考え方
- 生産性の考え方
- 品質（外から見える品質、内部品質）
- プレッシャーと生産性
- 正確な見積り
- 小さく、シンプルに作るメリット
- ソフトウェアの分業と生産性
読んでみての感想です。
量も少なく、内容も平易なのがハードルが低くて良いです。
私自身、仕事で非エンジニアの方と見積りや仕様などの調整も行いますが、ソフトウェアの内部構造的な問題点を伝えるのに苦慮します。
本書は、非エンジニアの方にもわかりやすく書かれていて、ソフトウェアの本質や特徴を理解してもらう一助になると思います。
また、経験の浅いエンジニアにも理解の一助になります。
今後、この本の説明をベースに非エンジニアの方にわかりやすく説明していきたいと考えています。
Posted by ブクログ
ソフトウェアエンジニアリングの仕事について、ありがちな誤解やアンチパパターンを経営者や事業責任者にも分かるように説明されている。特に生産性やモチベーションを悪気なく下げてしまうケースに言及されており、思うように開発が進まなかったり、人材の流出に悩んでいるなら本書を学ぶと良いだろう。
全体的に表現が平易でわかりやすく、ページ数が少ないので負担なく読める。著者の倉貫さんの本は毎回読みやすくなっているが、その中でも本書は特に読みやすくなっている。
書いてある内容はエンジニア目線で共感できるものが多い。また、逆に多くのエンジニアができていないことへの言及もある。エンジニア以外の人にぜひ読んでもらいたいし、エンジニアも読んで態度を改めるべきだと思う。「そのやり方、誰も幸せにならないからやめませんか？」という対話をしていこう。
Posted by ブクログ
かなり凄い本
この著者の方は何冊か本を出版しており、それの最新作
内容がかなりシンプルかつ濃厚で、時間があまり取れない人でも読めるようになっている
Posted by ブクログ
令和の「人月の神話」。
意図的に平易な表現が使われ、ページも少なく、30分あれば一通り読み切れるサイズ感。
エンジニア経験者なら「何を当たり前のことを」というような内容で、コンパクトにまとめたがゆえの語り落としもある(スクール出たてのエンジニアが戦力にならないとしたら、彼らはどう育てるの？とか、急かすと将来に影響があるのはわかるがビジネス的に守らなければいけない日程とはどう向き合うの？とか)。けれども、そんなハンデを背負いつつも「届きやすさ」に勇気を持ってふりきった本書に心から敬意を表する。
Posted by ブクログ
読みながら感じたのは、すごく頑張って平易な表現を貫いていて感服すると同時に、強調するが故にちょっと言い切り過ぎかなと思う部分もあった。エンジニアが詰められた時にうまく返せたり、そもそもうまいこと説明するのに役立ちそうなので、エンジニアじゃない人の感想が知りたい。
Posted by ブクログ
エンジニアの様子を横目で見てきた立場なのですが、この本を読んでだからつらそうなのか、、、ということがわかりました。
自分の会社の具体プロダクトを考えた時に、どうしたらより生産性をあげられるか、の想像があまりつかなかったので、思考を深めてみようと思います。
Posted by ブクログ
経営者向けのVUCA時代におけるUP開発の心得。今の自分には全く関係ないが、現役時代にこれをお客が読んでいたらかなり楽になっただろうなと思われる。
Posted by ブクログ
システム開発を進める上での「啓蒙書」である。
人が増えても速くならない、というタイトルが既に真理を述べている。遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけになりかねない。人を増やすことで、教育コストやコミュニケーションコストが嵩むし、タスクを分解するにも限度がある。マネジメントの難易度も高まる。
ソフトウェアのプログラミングにおいては、人数と生産性に必ずしも短期的には相関関係がない。工程を分離するよりも、できるなら、1人の人間が一気通貫で担当する方が、動的なソフトウェアを維持しながら変更していくには都合が良い。
そう考えると、既にいる人たちの生産性を上げることの方が有効な場合がある。高い生産性を出せるような環境の用意やクラウドの性能の増強など。給料や受注金額を上げ、そのプロジェクトに関わる少数に振り分ける方が、人を増やして、一人当たりの取り分を減らすよりもよほど有効だと思う事は多々ある。しかし、組織は特例を作りたがらず組織の慣習に従うのが常だ。既得権化させたくないし、他者からも同様な要求を受けかねないからだ。インセンティブ制度は、事程左様に難しい。
プログラムは単純に手を動かすだけでは開発できず、プログラムを書く仕事で求められるのは抽象化能力である。「近い未来は解像度高く、遠い未来は曖昧なまま」。肌感覚で分かっていた事を言葉にしてくれたような本だ。
Posted by ブクログ
エンジニアの考え方や事情をただ記述するような、いい意味でで思っていたような本ではなかった。エンジニアをマネジメントする場合の考え方を示してくれる良き本でした。
Posted by ブクログ
システム開発がプロジェクトからプロダクト中心に変わると、関わる人たちの関係性も変わることになります。これまでの完成を目指したシステム開発であれば、「システムを依頼する人たち」と「システムを開発する人たち」という形で分かれていました。しかし、社外に限らず社内であっても受発注のような関係では、変化に柔軟に適応していくシステムは手に入りません。動かし始めてから、次々と直したいところが出てきても、その度に発注するように依頼することになってしまうからです。プロダクトという共通の成果物と、目指す共通の目標を持つことで、システムは「依頼して作ってもらうもの」から「協働して一緒に作るもの」に変わります。そして、システムは完成を目指すものでなく、事業と共に改善を続けるものになるのです。成長し続けるために、変化に適応できるソフトウェアの作り方と考え方を身につけましょう。
■なぜ正確な見積もりが出せないのか
・詳細までの仕様を把握しきれなかった
・例外的な処理を把握しきれなかった
・想定していた技術が使えなかった
・担当する人によってばらつきがある
事業側と開発側が受発注の関係ではなく、共通のゴールを目指す同じチームとして協働の関係を築くためには、システムを作ることだけを目的とした体制やマネジメントをしないことです。あくまで事業や活動があり、その成長や成果のためにシステムを作るとするのです。
そのためには、まず「大きな機能の見積もりは、あくまで見通しである」というスタンスでいることです。一度に機能も期間も大きな約束をして、あとは出来上がるのを待つのではなく、1~2週間の単位で少しずつ確認しながら作っていくのがいいでしょう。それぐらいの期間であれば、どれくらいの進捗を出すことができるのかは精度を高めに見積もることが可能です。エンジニアではない人間からすると、エンジニアたちが何をしているのかわからないため、きちんと頑張っているのかどうか不安になるわけです。しかし、ある程度の頻度で、作るべきサイズを小さくすれば、進んでいるかどうかは確認できます。
大規模なソフトウェアは、一度に作るのではなく、小さなソフトウェアに分解し、小さなプロジェクトとして何回かに分けて進めていくことで、失敗のリスクを小さくすることができます。それも、実際に動くところまでをゴールとしたプロジェクトにすることが肝要です。ソフトウェアは動いてこそ価値があり、使ってこそ直したい箇所が見つかるからです。
そして、何度も打席に立ち、自分たちのプロセスや取り組み方に学びを得ることで、ソフトウェア自体の不確実さは解消されないにせよ、進め方のノウハウが溜まることで成功確率を上げていくことができます。同じチームで、小さなプロジェクトに何度も挑戦していくことで、チームビルディングも進むでしょう。
Posted by ブクログ
アジャイルの考えを平易かつ簡潔に説明した本。アジャイルの勉強を始めたばかりの自分にとっては、これまでの学びを別の表現で復習できた。
◾️覚えておきたい標語
近い未来は解像度を高く、遠い未来は曖昧なまま
◾️見積もり
・見積もり精度を高めるために、どこまでも詳細に考えていくとしたら、それはもはやそれは設計である。つまり、限りなく正確な見積もりは、実際にやってみることでしか出せない。
・大きな機能の見積もりは、あくまで見通しである。1〜2週間の期間であれば、どれくらいの進捗を出すことができるのかを、高めの精度で見積もることができる。
◾️本書のテーマ外だけど覚えておきたいこと
・コードレビューは属人性の排除に有効。優れたエンジニアに指摘してもらうことで品質の向上が見込め、かつ、良いプログラムの書き方を学ぶことができる。
・週に一度、1時間を「ふりかえり」の時間にして、仕事を通じて経験したことを抽象化、言語化する。これを学びとして、次の仕事に活かす。
Posted by ブクログ
他の一般的な業務では通用することでも、システム開発では通用しないことがまとめられている。システムをわかってない上層部にどう言えば伝わるのか？参考にしたくて読んだ。
手伝いを入れると生産性が下がるってのは、自分が言いたかったことをちゃんと言ってくれた感じ。育成と生産性向上の両立は、システム開発では難しすぎる。システムを知ってるはずのシステム開発会社のマネージャでもこういうことをわかってない人は多いと思う。
Posted by ブクログ
ソフトウェア開発におけるよくある勘違いについて、実際の開発での難しさを説明している。ソフトウェア開発に対して完全に素人レベルのユーザーや管理職であれば得るものがあると思う。自分としてはそういう人たちがどんな勘違いをにているのか知ることで役に立つかと思ったが、あるあるネタ中心なのであまり参考にならなかった。
