あらすじ
ユーザー数が伸びるにつれて多くの要望が出てきても、新しい機能をスピーディーに追加できなくなってきた。
ちょっとした修正のはずなのに、ものすごく時間がかかる。
――そのようなことが起こる原因は、ソフトウェアが変化に適応できないから。
プログラミングを学んでも理解できないソフトウェアの本質を、プログラマーとして12年、経営者として12年の経験を持つ著者が集大成。
・完成しても終わりではない
・人が増えても速くならない
・たくさん作っても生産性が高いとは言えない
・人に依存せず同じ品質にはできない
・プレッシャーをかけても生産性は上がらない
・見積もりを求めるほど絶望感は増す
・一度に大きく作ると得に見えて損をする
・工程で分担しても効率化につながらない
これからの事業の成長に欠かせない思考法がわかる。
■目次
はじめに
1章 完成しても、終わりではない
システムは使い始めてから改善が始まる
なぜ、ソフトウェアなのに固くなってしまうのか
プロジェクトからプロダクトの考え方に変える
2章 人を増やしても速く作れるわけではない
2倍の予算があっても2倍の生産性にはならない
遅れているプロジェクトに人を追加するのはやめて
銀の弾丸はないが"金の弾丸"なら有効なときがある
速く作ることはできないが、速く作れるチームは作れる
チームの哲学や文化が揃っていることが大事
3章 たくさん作っても生産性が高いとは言えない
あらゆる状況を考慮するのに時間がかかる
プログラムは現実の理解の上に成り立つ
影響範囲に気をつけて、重複をなくすことも仕事
同じソフトウェアを複数人で同時改修するのは非効率
生産性は、手を動かした時間で測らない
4章 人に依存せず同じ品質で作ることはできない
ソフトウェアは一品モノ、1つずつ中身が違う
外から見える品質と、見ることのできない品質
エンジニアにしかわからないプログラムの美しさ
クリエイティブな仕事の属人化を解決する
5章 プレッシャーをかけても生産性は上がらない
急がせたところで速く作ることはできない
一時的な妥協は、永遠の負債になる
作れば作るほど、生産性は落ちていく
生産性が上がる仕組みを作ることは投資
楽をするための苦労はいとわない
6章 見積もりを求めるほどに絶望感は増す
なぜ、正確な見積もりが出せないのか
見積もりを守るためのバッファの功罪
見積もりと約束が"受発注"の関係を作ってしまう
事業側と開発側が"協働"の関係を築く
「納品」をなくせばうまくいく
7章 一度に大きく作れば得に見えて損をする
プロジェクトが大きくなるとうまくいきにくいのに、なぜプロジェクトは大きくなってしまうのか
ソフトウェア開発はギャンブルのようなもの、大きく賭けると大きく失敗する
小さくすれば不確実さを下げられる
小さく作って、大きく育てられるのがソフトウェア
プロジェクトを小さくするために、作ろうとする機能の範囲を限定する
不確実な未来を、少しずつ確実なものにしていく
8章 工程を分業しても、効率化につながらない
工程を分離しても生産性は上がらない
猫の手を借りても生産性は上がらない
プログラムは最も低い品質に引っ張られる
ソフトウェアの設計はだれのものか
おわりに
感情タグBEST3
このページにはネタバレを含むレビューが表示されています
Posted by ブクログ
本書は、サブタイトルに「変化を抱擁せよ」とある通り、変化が起きる前提でどのような姿勢で向き合うかエンジニア誰もが感じる部分を言語化している。
以下は、気になった文章のメモ
・ある一点の完成を目指すことは逆に言えば一度だけ完成すればいいということになる。そうなると、完成後のことより完成させることに力学が働く。
・プログラムは現実の理解の上に成り立つ
・プログラムを書く仕事で求められるのは抽象化能力
・一時的な妥協は永遠の負債になる
・シンプル化する。借金を返済し続ける
・目の前の生産性を上げるのか。それとも、生産性を上げる仕組みを作るのか。
・大きな機能の見積もりは、あくまでも見通しである
・不確実な未来を、少しずつ確実なものにしていく
・ソフトウェアを作ると言うことは新規事業の創出や研究開発のようなもの。レシピを作る仕事に手を動かすだけの人は不要
・プログラムは最も低い品質に引っ張られる
