何を得るために読んだか？読んだ目的
受託開発の現場が納品の間際に疲弊する原因と、「納品をなくす」という別のやり方の中身を知るため。
読んでどう感じたか？読了後に一言
ゴールを納品に置かないだけで、受託開発の常識がここまで変わる。
実際に得たものは何か？刺さったポイント
- 根っこにあるのは、顧客にムダづかいしてほしくないという思い
- ソフトウェアは完成しただけでは価値がない。使い始めてからどれだけ使えるかに意味がある
- 人月の最大の問題は、誰が担当しても同じソフトウェアができるという前提に立っていること
- 「絶対に納期を守る」と約束すると、各段で見積りにバッファが積まれ、本来の価値より高くなる
- 作らなくてすむものを作らないよう提案するのも、プロの価値ある仕事
- 顧客を契約で縛るより、信頼関係をつくる努力を惜しまない方が健全
- 要件を定義するのではなく、事業の目的を共有する
- 顧客には解決方法ではなく、解決したい問題を話してもらう
- 止まらないサーバより、止まってもすぐ復旧できるサーバを目指す。必要になるまで作らない
- 管理したくなっても信頼して任せ、任された側がそれに応える循環で自己組織化されたチームができる
- エンジニアの採用は履歴書ではなく作品を見る
- 知識労働の成果は「何をやらないか」で決まる。「なぜなぜ」より「そもそも」の目的から考える
- 会社は、目の前のパンを分け合える程度の大きさが理想
目的を満たしたか？読んだ結果
受託開発の現場が疲弊する原因は、技術ではなく「納品」をゴールにする一括請負の商売の形にあり、要件定義の無理や見積りのバッファ、人月の評価もそこから生まれていた。別のやり方の中身は、月額定額で開発と運用を同じエンジニアが続け、作らないものまで顧客と一緒に決める「納品のない受託開発」だった。
今日から何をするか？読了後の第一歩
- 次の打合せで機能の追加を頼まれたら、作る前に「それは何のために必要か」を1つ聞く
