どんな本？

「要するに何が言いたいの？」と上司に真顔で聞かれて冷や汗をかいた経験、きっと誰にでもあるはず。この本はそんな「話が伝わらない病」を外科手術レベルで治してくれる一冊です。MECEとSo What?/Why So?という武器を手に入れると、ダラダラしていた障害報告が三行で済むようになり、ピラミッドストラクチャーで書いた設計ドキュメントにレビュアーが何も言えなくなる。エンジニアに論理は要らない、コードが雄弁に語るから。……と思っていた時期が、読み終わる頃には遠い過去になっています。

どんな本？

「とりあえずやってみます！」と言って三日後に炎上させた経験、ありませんか。この本はコンサル本の顔をしていますが、中身はエンジニアにも刺さる「仕事の基礎体力」ドリル。結論から話す、事実と意見を分ける、数字で語る、といった当たり前を当たり前にやる技術が詰まっています。Slackの長文ポエムが急に構造化され、議事録から「〜だと思います」が消え、PRレビューで論点がブレなくなる。読後、昔の自分のチャット履歴を見返して悶絶するまでがセット。

どんな本？

git add . して git commit -m "とりあえず" を繰り返してきた人生に、そろそろ向き合う時が来ました。本書はGitの生みの親・濱野純による解説書で、「なぜgit rebaseはこんな挙動をするのか」が腑に落ちる瞬間を届けてくれます。CVSやSVNの「差分を保存する」思想を引きずったまま使うと永遠にGitが謎のままなのですが、コミットグラフをオブジェクトの連なりとして捉え直すだけで、あの呪縛がすっと解けます。読み終えると「git logが怖くない」どころか「歴史を自在に書き換えられる人間」になれます。ただし、その力を本番ブランチで使うかどうかは自己責任で。

どんな本？

「Gitってなんでこんなに概念がわかりにくいんだ」と思ったことがあるなら、その違和感はあなたのせいではありません。CVSやSVNという前時代の呪縛を引きずったまま説明されてきた歴史的経緯が原因で、Gitは最初から「わかりにくく見える」宿命を背負っています。この本はそもそもオープンソース開発の思想的な地図を描いた一冊で、バザール方式という言葉が指す「なぜ分散して開発するのか」の根っこを教えてくれます。読み終えると、Gitのブランチ戦略やコラボレーションの作法が「道具の使い方」ではなく「文化の産物」として見えてくる。技術書というよりほぼポエムなのに、なぜかコードが書きたくなるのが不思議なところ。

どんな本？

積読タワーがそびえ立ち、買った瞬間に満足してしまうエンジニアの悲しい習性に、そっとメスを入れてくれる一冊。技術書を「全部読まなきゃ」と気負って3章で挫折した経験がある人ほど刺さります。シントピックリーディングや知識の三分類といった読書術を、エンジニア視点で実用レベルに落とし込んでくれるのがありがたい。選び方、読み方、アウトプットの仕方まで網羅されていて、読了後はQiitaに感想を書き始める副作用つき。ちなみにこの本自体も積んだら本末転倒なので、まずは目次から眺めるのがおすすめです。