とても参考になりました。

副題が「非効率な日本のSIを変革する実践的ベストプラクティス」とあるとおり、理想論的ではなく現場の課題に立脚した"実践的"な書籍でした。

僕が本書の対象（5年以上の業務経験など）にだったのもあり、「それあるある」と肌感覚も伴って読むことができました。

システム開発は複雑で一点もののものも多く、社内には開発標準はありますがそれは必ずテーラリングが必要になります。どうやってテーラリングしていけばいいのかの関しての書籍はほとんどなく、OJTで死にかけながら体得して（しばしば体得できない）いく人が多いのではないでしょうか。テーラリングの方法論や開発標準と実際のプロジェクトの乖離の埋め方が本書のメインテーマではありませんが、OJT経験が少ない若手にはその部分に関しても本書から学べるところは大きいかと思う。

以下印象に残った部分。雑多だけど、この文章は誰かにこの本の内容をわかりやすく伝えることではなくて、要所要所で自分がなるほどーとかここは勉強しなきゃだなーとか思ったことを自分のためにかいている。

初級エンジニアの引き上げに必要なのは、基本動作の徹底、常識の徹底である。

自分の経験としても、最初からこれやってみてと投げられることが多かったが、その時に何度も常識を教えてほしいと思った記憶がある。この場合はこう設計しとかないと後で問題になるといったような常識は、その常識がある人には簡単なかもしれないが、ない人にとっては調査は時間がかかり、大きな手戻りも発生する。

イミュータブルインフラストラクチャ：一度サーバを構築したらそのあと一切変更しない運用方式。これにより運用環境の秘伝のタレ化などを防ぐ

既存環境のよみときが非常に大変なのは、以前のPJで実感した。継ぎ足し継ぎ足しで改修されたシステムは手順書がバラバラなフォルダにおいてあり手に入らなかったり、粒度にばらつきがあったり、すべて手に入ったとしてもどういった順番で実行すればいいかわからなかったりする。

Infrastructure as Code

この最大のメリットはインフラチームの作業をノウハウ蓄積型のワークスタイルに変えていくことができることであるとのこと。いまは個別PJで場当たり対応になっちゃってるからね…。その時の対応ノウハウをまとめようとしてもそんな時間なかったりするのがよくあること。また、まとめる人によって粒度にばらつきがあったり。コードで蓄積できればこのばらつきの抑制にもつながるね。

バッチジョブ：日本の現場では多いが、管理が大変になるのでなるべく避ける。

ほんとこれ

古く慣れ親しんだ方法しかしらない部課長クラスへのナレッジ移転を重点的に行う。

課長はほんとに頭が固いんだから～、課長に話しても無駄とかそういう風に思うのは簡単だけど、お互いに協力しあう姿勢がないと現状っていうのはいつまでたっても変わらないんだよね。近々、課長にPJ報告の場があるけど、こういった場のためにしっかり準備し、理解をしてもらうためにコストをかけることは長期的にみて大事なんだなって。

現場エンジニアが新しい技術を提案してもマネジメントから「今のやり方を変える必要などない」と一蹴されてしまうといった問題はよくある。

振り返ると弊社はあまりこういうことないなと。話をきいてくれて改善してくれることも多い。自社のいいところってあんまり言えないけどこういうところもいいところと言っていいのかも。

現場から距離のある経営層がトレンドワードを取り入れた施策を打ち出し、中間管理職が内心おかしいと思いながらも形だけ実行する（あるいは実行したふりをしてつじつまを合わせる）こともある

あるあるすぎる。まわりみてると本当によく感じるしはじめて感じたときの違和感がどんどん薄れていってるのを感じる。なにか問題がおきて責められて社会人が生き残るためには施策の通りやりましたって主張するしか結局ないもの…。ただ本当に改善活動をしていこうとしている社員も数人いるのも確か。そういう人たちが会社を引っ張っていってるんだなって。

多くの場合新技術を提案するのは若手である。

中堅ももとは若手だったはずなのにどうしてこうなるんだろう。世の中のトレンドとなっている価値観の部分っていうのはやっぱりそのムーブメントを起こしている世代以外からは受け入れにくくなるのかな。若手もいつかは中堅になるんだから中堅以降でも自分の力が発揮できるような環境があることが必要だなあと。