Thread by @tsukamoto

予約してた「人が増えても速くならない ~変化を抱擁せよ~」がKindleに配信されてきたので、読む読む。
amzn.asia/d/19603eQ
#人が増えても速くならない

「システムは使い始めてから改善が始まる」
「仕組みはシステムが支えるので、事業の改善を続けていくなら、当然ながらシステムもずっと改修していく前提で作った方がいい」
#人が増えても速くならない 第1章

「ソフトウェアは精緻なジェンガみたいなものだと思ってください。雑に乗っけてしまうほどに、あとから乗せるのが難しくなり、いずれ崩壊してしまいます」
#人が増えても速くならない 第1章

「プロダクトでは、基本的に関わる人たちは変えません」
「プロダクトという共通の成果物と、目指す共通の目標を持つことで、システムは『依頼して作ってもらうもの』から『協働して一緒に作るもの』に変わります」
#人が増えても速くならない 第1章

「安易に解決できる銀の弾丸はないけど、“金の弾丸”なら有効に使える」
#人が増えても速くならない 第2章

ブルックスの法則や人月の神話の話だけど、経営層が想像しやすそうなことに例えるならこうも言える。
「コンサルティングの現場に、さらに三人のコンサルタントを追加したらどうなるか？一貫した思考、一貫した提案を欠いて、現場が混沌とするだけだ」
#人が増えても速くならない 第2章

ソフトウェアに明るい人になら、こうも言える。
「ソフトウェア開発はスケールアップ可能だが、スケールアウトできない。エンジニアを増やすな。いまいるエンジニアの開発効率を最大化するんだ。人を入れるなら、彼らの開発以外の作業を代行する秘書や助手だ」
#人が増えても速くならない 第2章

「プログラミングで手を動かす前に、どういった手順で動くのか、データの保存形式はどうするのか、画面の動きでおかしなところはないか、様々な場面を事細かに考慮して設計をする必要があります。なぜなら、コンピュータはあいまいな指示では動かないからです」
#人が増えても速くならない 第3章

「考慮漏れをなくすためにエンジニアが知りたいのは、プログラムではなく現実世界のことです。（略）なぜ必要なのか、どういう場面で使われるのか、その機能によってユーザーはどういう便益を得ることができるのか……そうした背景です」
#人が増えても速くならない 第3章

「ただ作ってほしい機能について話すだけでなく、
『その機能がなぜ必要なのか』
『事業にとってどういう意味があるのか』
といった思いや理由について伝えた方が、よいプログラムを作ってもらえるはずです」
#人が増えても速くならない 第3章

「あいまいなままの指示が通るのは人間同士だけ」
#人が増えても速くならない 第3章

「プログラムを書く仕事で求められるのは、抽象化能力です」
図3-1で同じような仕事をにさせるのに、命令を100個書く方法と、繰返しを使って命令を3個書く方法を対比して見せてるの、すごく良い。コード量≠生産性だし、優れたコードは生産性100倍なのの端的な例。
#人が増えても速くならない 第3章

「美しいと感じられないと、まず理解するのにとてもコストがかかるし、理解するための時間は苦痛になります。そして、美しくないと感じているプログラムに修正を加えていくのは、さらにストレスになります」
#人が増えても速くならない 第4章

「マネージャーが取り組むべきなのは、誰がやっても同じ結果になることではありません。個々人が成果を発揮しつつも、コードレビューを徹底化して、チームの成果や試験としていくことです」
#人が増えても速くならない 第4章

「一時的な妥協は、永遠の負債になる」
#人が増えても速くならない 第5章

「『ソフトウェアや機能杯、一度作ってしまえば、後は動かし続けるだけなので、それほど人手はかからない』
そう思われがちですが、まったくそうではないのです」
一度作ってしまえば電車は走り続けるか、みたいな感じだな。多くの人が関わり続ける。
#人が増えても速くならない 第5章

「目の前の生産性を上げるのか。それとも、生産性を上げる仕組みを作るのか。どちらが大事なことでしょうか」
「この考え方は、エンジニアに限った話ではなく、現代の多くのビジネスパーソンにも適用できる」
#人が増えても速くならない 第5章

「週に一度、1時間は『振り返り』の時間を取って、仕事を通じて経験したことから抽象化・言語化することで学びにして、次の仕事に活かす」
ああ、そうか、抽象化と言語化の時間だったのか。大切だな。
#人が増えても速くならない 第5章

「見積りの精度を高めるために、どこまでも詳細に考えていくとしたら、その時間はもはや実際にかかる時間と変わらなくなります」
「誠実な人ほど見積りが苦手に感じる人が多い」
#人が増えても速くならない 第6章

「直観に近い感覚でのざっくり見積りは、本当に外すことが多い」
「エンジニア自身でさえも、楽観的な見積もりを出してしまいがち」
「優れたマネージャーは、それを見越してバッファを積むわけですが、エンジニアでない人が積むバッファに全く根拠はありません」
#人が増えても速くならない 第6章

ちょうど流れてきた記事。線路に敷き詰められてる砕石はバラストと呼ばれていて、適度に粗く尖っていることが大事。徐々に細かく砕けたりしていくので、定期的なメンテが必要。
この敷き詰められた砕石まで定期的にメンテすることで、電車は走れる。
gigazine.net/news/20230611-…

「バッファを積まざるを得ない状況」
「それは見積りに“約束”の意味合いを含んでしまっていることがあるから」
「『機能ありきで期間を見積もる』のではなく『期間ありきで機能を見積もる』」
#人が増えても速くならない 第6章

「月額定額の顧問型サービス『納品のない受託開発』」
「サイボウズでは『伴走パートナー』という形で、納品を目的としない継続的な支援」
ITソフトやクラウドベンダーに「TAM」というサービスが広くあって、実は同じこと、身近な形態なのかもしれない。
#人が増えても速くならない 第6章

「ソフトウェア開発において、大規模なプロジェクトにすることのメリットは『ない』」
「小さなプロジェクトを並べたことで、大規模プロジェクトよりも長い計画になるのだとしたら、じつは大規模プロジェクトの見積もりが外れ」
#人が増えても速くならない 第7章

「ソフトウェアの特性を活かした作り方や体制で開発していなかった」
「本来のソフトウェアは、物質に依存するハードウェアと違い、後からでも変えていくことができる」
「見た目は紙芝居のようなものであっても（機能評価には）十分で、後から完成度を上げていく」
#人が増えても速くならない 第7章

「不確実な未来を、少しずつ確実なものにしていく」
「近い未来は解像度を高く、遠い未来は曖昧なまま」
「ロードマップを、一定期間ごとに見直し続ける」
「ゴーイングコンサーン」
「ソフトウェアも持続的にマネジメントしていく」
#人が増えても速くならない 第7章

「ウォーターフォール」
「『完成するまでの開発』と『完成してからの運用』という形で分ける」
「その先には、工場のようにソフトウェアを量産していける“ソフトウェア工場”の夢があった」
「そうは問屋が卸さないのがソフトウェア開発」
#人が増えても速くならない 第8章

「工程を分離してしまうと、部分最適に」
「プログラムを修正し続けていくためには（略）工程を分離してしまうとコミュニケーションコストがかかりすぎてしまいます」
#人が増えても速くならない 第8章

「なんだったら『自分で書き直した方が速い』と思う時さえあります。実際に、速いです」
#人が増えても速くならない 第8章

「役に立って生産性を高めつつ経験を詰める機会が少ない」
「育成か生産性か、狙いをどちらに置くのか考えなければなりません」
#人が増えても速くならない 第8章

「ソフトウェアの場合も設計と製造で分けて考えることができますが、プログラミングは製造にあたると多くの人が誤解しています」
「設計という行為と、それを実際のプログラミング言語で表現する行為を分離するのはナンセンス」
#人が増えても速くならない 第8章

「アジャイルの思想」
「変化を抱擁する思考」
「会社で組織を作り上げることはソフトウェアを作ることにとても似ている」
#人が増えても速くならない おわりに