Microsoft社にいる凄腕のエンジニア、その名はオラクル


※先日、ゆるWeb勉強会@札幌 #28で話した内容を多少アレンジしたものです。 2024年に読んだ本の感想などを語っていきます。 語るといいつつ、読みながら残した読書メモからトピックを拾ってきてちょっとコメントするだけです。

① 世界一流エンジニアの思考法

世界一流エンジニアの思考法(Amazon)

どんな本?

  • 自身を「三流」と評する筆者が、マイクロソフト社の中で出会った一流のエンジニアから学んだあらゆるノウハウをまとめた本
  • コードの読み方、問題解決の方法、情報整理能力、AIとの付き合い方など、現代のエンジニアリングに必要な教えが詰まっている

オラクル

(本文より引用)

同僚に技術力ナンバーワンのバーラという秀才がいる。彼はあまりに何でも知っていて優秀だから、周りからは「オラクル」と呼ばれているほどだ。

マイクロソフトにオラクルが居るって最高ですね。 ところでこの本、今年かなり売れたみたいなんですが、色々な人の読んだ感想やレビューを眺めてみても、ここに言及している人全然いないんですよね。ここもっと取り上げてほしい。

試行錯誤は悪

問題が起きた時、闇雲に色々試す試行錯誤は良くない。

(本文より引用)

まずは、事実を1つ見つける→いくつかの仮説を立てる→その仮説を証明するための行動をとる。

ということで、

  • 仮説を立てる
  • 合ってるか検証する のサイクルをひたすら回していくと良いそうです。なるほど。

どのタスクをやる?

タスクに優先順位をつけるのは良い。その上で、本当に全部やる必要があるのかを考えよう。 優先度の低いタスクは思い切って捨てて、最も重要なタスクに注力するのも一つの手である。

(本文より引用)

なんにも準備できていないのに急に明日プレゼンをすることになったら、無理なものは諦めて、バサバサと要素を切り捨てているはずだ。

「勉強会の前日あるある」だ!!!

重要なことだけ伝える

プレゼンをする際、可能な限り情報量を多くしようとする人がいるが、これはあまり良くない。聞いている人の頭の中に残せる情報量には限界がある。 ということで、プレゼンでは特に重要なことだけを伝える。細かいところは、質疑応答で聞かれたら答える、ぐらいの気持ちで良い。らしいです。

「勉強会の当日あるある」だ!!!

② SQLアンチパターン

SQLアンチパターン(Amazon)

どんな本?

  • DB設計やSQLの記述において、やるべきでないパターンが25章にわたって書かれた本
  • どの章も、悪い例と良い例がセットで書かれているため理解しやすい

あとパターンの名前がカッコいいぞ!!!

個人的に好きな名前はこのあたり

  • インデックスショットガン
  • フィア・オブ・ジ・アンノウン
  • プアマンズ・サーチエンジン
  • シュードキー・ニートフリーク
  • 砂の城

せっかくなので意味も超適当に紹介

インデックスショットガン

むやみやたらとインデックスを貼りまくってはいけない。かといって全く貼らないのも良くない。適切に使おう。

フィア・オブ・ジ・アンノウン

NULLは「値が不明なもの」なので、これを意味のある値として扱ってはいけない(空、とか0として扱ってはいけない)。比較や演算のときにNULL値があると変な挙動起こすし。

プアマンズ・サーチエンジン

全文検索の機能を実現したい時に、SQLのLIKEによるパターンマッチングを使ってはいけない。インデックスが効かないので重くなる。

SELECT * FROM user WHERE name LIKE '%とかげ%'

全文検索をやりたいなら、素直に何かしらの全文検索エンジンを入れた方が良い。

シュードキー・ニートフリーク

字面だけ見ると元聖騎士の無職っぽいよな

物理削除が発生するような設計のテーブルでは、主キーに欠番が発生することがある。この欠番は無理に埋めようとしない方が良い。 複数行一気に追加する時の欠番探しとか面倒だし、やるメリットもない。

砂の城

システムリリース後の保守・運用時に備えて、あらかじめあらゆるトラブルを想定して対策しておくべき。

③ スタッフエンジニアの道

スタッフエンジニアの道(Amazon)

どんな本?

  • プロジェクトマネージャーや取締役でなく、技術専門職としてのキャリアを積んでいくための教科書
  • 優れたコミュニケーション能力と技術力を持ち合わせたエンジニアになるためのノウハウが満載

要はアーキテクトテックリードになりたい人向けの本かな、と思いました。

リーダー・マネージャーあるあるをまとめた本でもある

こういう話が出てくる。心当たりある人多そう。

  • 疲れている時、優先度度外視で簡単な作業に手を付けてしまいがち (メールの整理、机の片付けとか。本書では「間食」と呼ばれる)
  • 大量の打ち合わせやちょっとした問い合わせ対応で週のほとんどの時間を使ってしまいがち
  • 何回もリスケしてたら、いつまで経っても着手されないタスクが出てきた

スタッフエンジニアになる方法

  • 技術力とコミュニケーション能力をどっちも極限まで高めろ
    • 対話の中で「相手が求めているもの」を察しろ
    • 自分が会社の技術的なデファクトスタンダードになるぐらいの勢いで、社内の色んな案件に首を突っ込め
    • 学習し続けて、その内容を発信し続けろ

「現場」は英単語になっていた!

(主に日本の製造業で)「業務が実際に行われる場所」という意味で「現場」という言葉がよく使われます。 どうやら近年、海外でも同じ意味で「Gemba」という言葉が使われるようになったようです。

日本のビジネスのやり方が海外に広まる過程で普及したみたいですね。

広まり方が「過労死(Karoshi)」と同じですね

まとめ

どれも良い本でした。

今度読みたい本

センスの良いSQLを書く技術 達人エンジニアが実践している35の原則(Amazon)という本が気になってます。2025/01/27発売予定だそうです。