自分のエンジニア人生を変えた本を一回ちょっとまとめておこうという本当にただのスクラップ記事。
徐々に書いていく。

クリーンアーキテクチャ

ボブおじさんの原理原則の本。

• 我々が作っているものは「ソフト」ウェア＝変更しやすいものである
• めちゃくちゃ雑に言うとポリモーフィズムと不変性で境界をうまく引けば変更しやすいものになるよねって話
• この境界の弾き方を知るまでは「全てのシステムには心臓部（例えばフレームワーク）が存在する」って思い込んでたけど、境界をうまく引くとこれを避けれるから「心臓部を修正すると影響範囲がでかい」みたいなのを避けれる
• この本で言う「アーキテクチャの叫び」、DDDで言う「ドメイン」、どれも結局「何を作ってるのか」が重要でそれを見誤ると境界の弾き方もきっと見誤る

クリーンアジャイル

再度ボブおじさんの原理原則の本。

• 顧客が言葉に出さずとも、望んでいるのはどんどんよくなる（変更容易性が上がっていく）システムである。納品後ちょっと仕様変更したくても「0から作り直す必要があります」というシステムは求められてない
• スケジュール、コスト、クオリティ、スコープ。これらを計測するのがアジャイル、計測を基に調整するのがマネージャーの仕事
• 「どれだけうまくいってないか」を知るためのアジャイルである、アジャイルにしたからって早くなどならない
• 個人的に強烈だったのがソフトウェアと人命の関係性。「人命に関わるシステムでもあなたは自動テストなしにリリースするのか？」みたいなのを言ってるところは強烈だった
• 社会（ビジネス）にとって価値ある行動をすることがエンジニアリングという仕事の本質であり、守られるべき権利、みたいなエモい話は個人的に結構好きだった

Kaizen Journy

(ちょっと忘れ気味だから読み直し中)
日本のエンジニアで似たような境遇の経験した人とか苦しみに共感できる人は多いんじゃないかと思う。
これ読んで顧客とチームのために走り切る勇気を貰えたし、スクラムのhowもストーリーから頭に入ってきやすかった。
スクラム初学者はスクラムブートキャンプよりこっちが先のがいいのかも？
僕がエモい話が好きなだけかも。

人月の神話

まだ読んでる途中、この本は人月を単に語る本ではない。
3年でOSを作るプロジェクト(結果的に5000人年かかったらしい)をどうやって見積もり、どう分担しどう組織していったのかという話に始まる。単純な横分解ではもちろん成り立たないのでオペチームを作るべきっていのは面白かった。
開発なんて小さなチームでやるのが絶対正義だと思ってたけど、組織のスケーリングってこうやってるのかと衝撃を受けた。