はじめに
今回、米マイクロソフトでシニアエンジニアとして働かれている牛尾剛さん著の『世界一流エンジニアの思考法』を読みました。
出版直後から人気の本という記憶で、今更感はあるかもしれませんが読んでみました。
感想としては、「めちゃくちゃ読みやすい」「エンジニアじゃなくても学びがある」というところで、読んでよかった本でした！
以降では、私がこの本を読んで思ったことをツラツラとメモ程度に書いていきます。
試行錯誤は「悪」
本書では、デバッグする際にとりあえず手を動かして時間を浪費していた筆者だが、同僚エンジニアは「ログ（事実）から仮説を立てて検証するために手を動かす」ということをしており、時間の浪費がなかったというエピソードが書かれています。
自分もちょっとわかるなぁというところがあり、エラーが出た際など「この辺か？」「それともこの辺か？」みたいな感じで手を動かし始めちゃう時があります。
些細なエラーならそれで解決することも多いですが、場合によっては結構時間を浪費した記憶もあります。
しかし、ログというエラー解消のための手がかりがあるのならば、闇雲に手を動かすよりまずはそこを見た方が良いなと改めて感じました。
正直ログを見てもなんのこっちゃの時もありますが、今はChatGPTなどもあるので、前提・理想・現状・エラー内容を送って壁打ちしたら、大体のエラーに対しては解像度を上げられる気がしています。
心強いAIをパートナーにログと向き合うのが近道かなと感じました。
理解には時間がかかる
本書では、同僚のスーパーエンジニアでも、コードを読んだり仕様を理解したりするのには時間がかかっているというエピソードがあげられていました。
時間がかかるとはいえ、今の自分とは比にならないとは思いますが、それでもパッと見聞きしてパッと理解している感じではないとのことです。
マイクロソフトで働いているようなスーパーエンジニアでも、時間をかけて丁寧に理解を深める。
ただこれを愚直にやっているそうです。
本書では「『基礎』練習は『誰でもできる』ことだが、習得には『時間がかかる』ものだ」と言っていました。
つまり、「コードも理解には時間がかかるけど、日頃から誰にでもできる基礎を着実に行えばちゃんと理解できるよ」ということだと思います。
マイクロソフトで働いているようなスーパーエンジニアでもこのように仕事と向き合っているので、自分なんかがパッと理解できるわけはないと改めて感じ、最近はより一層「認知不可から逃げない」と仕事に取り組んでいます。
振り返ると、普段一緒に働いている頼れるエンジニア達もその傾向があるなと感じます。
アメリカで見つけたマインドセット
本書では「優先順位をつける」と聞いた時に、日本では「やるべきことの全てに優先順位をつけて、優先順位の高いものから着手し、基本的には全てに着手する」というイメージだがアメリカでは「最も重要なものをピックアップして、それ以外のものはやらない」というイメージだというエピソードがあげられていました。
そして、「『納期は絶対』の神話は捨てよう」「品質・コスト・納期・スコープはトレードオフにある」「進捗が想定と異なった場合はスコープを出し入れすることが現実的」とも書かれていました。
「何かを得るためには何かを捨てる必要がある」ということだと思いますが、私が経験してきた開発業務でも、ギリギリまで全てを取りにいこうとして参画メンバーが皆疲弊し切ってしまい、プロジェクトとして好ましい雰囲気ではなくなってしまう みたいなことが何度かあったなぁと感じます。
私は受託開発メインの開発経験なので依頼先の社内事情は分からないことも多いですが、長期的に見たら当初計画より実装機能が少なくなったとしても、実装者がちゃんと考えたコードを反映させて、皆がプロジェクトに前向きな気持ちを継続させた方がメリットが大きい気がしています。
コードリーディングのコツは極力読まないこと
本書では、コードリーディングに悩む筆者が同僚から「コードリーディングのコツは極力読まないこと。実装はちゃんと動くものとして、ダイヤグラムや関係性のグラフを書いたりしながら、インターフェースと構造を理解するようにする」とアドバイスいただいたエピソードがあげられていました。
現在私も日々のコードレビューの際に実装者の書いたコードを読んでいるのですが、最初は人のコードを読むのに慣れておらず、とても時間がかかっていました（結局今も時間はかかっているのですが）。
主にレビュー相手が未経験スタートのエンジニアが書いたコードなので、正直本項のタイトルのように「極力読まないこと」とはいきません（細かく見ないと変なコードが混ざっていたりするので）笑
一方で、一時期ヘルプで入ってくれていたバリバリできるエンジニアのコードもレビューしていたのですが、その時は本書に倣って「もう細かな実装はできているってことにして、パラメータの受け渡しや関数の役割とかを追っていこう」と思ったら、細かく見ていたそれまでと比べてずっとコードが読みやすかったことを覚えています（ちゃんとおかしな点は指摘しています）。
時と場合によってちゃんと細かくコードを読まないといけない場合もありますが、この考え方はちゃんと自分のものにしたいなと思いました。
日米のエンジニアを取り巻く文化の違い
本書では、「日本にとって致命的な足枷になりかねないのが『批判文化』である」とエピソードがあげられています。
まずアメリカでは「アプリケーションはどんなに優秀なチームが開発しようが、必ず何かしらの不具合は存在する」という考えがあり、不具合があったとしても「ここからどうしていくか」という建設的な意見が飛んでくるそうです（コントリビュートする文化）。
そんなアメリカと対比した日本の話として、本書ではコロナ禍にリリースされた接触確認アプリ「COCOA」の例があげられています。「COCOA」はスマートフォンのBluetooth機能を使って、一定時間スマホを持つもの同士が近くにいた場合に、情報を個々の端末に記録するアプリです。
日本マイクロソフトの方が個人的に始めたプロジェクトでしたが、世界各国から理念に共感した方々が開発を手伝ってくださり、非常に短期間でリリースされました。
未曾有の危機の手助けになればと必死に開発そしてリリースされたアプリでしたが、少しの不具合に対してTwitter等で大量の罵詈雑言が飛んできたそうです。皆のためを思って善意で初めて額に汗を流しながら開発を進めたアプリケーションなのに。
このような罵詈雑言を受け、開発者の方々はメンタルをやられてしまったそうです。
不具合があったら解消すれば良いのですが、完璧を求めて少しのミスも許さない批判文化。
決して説教くさく書かれているわけではないのですが、両方の国を経験した筆者からすると、有望なエンジニアは海外企業に行ってしまうのもわかるとのことでした。
勿論ないに越したことはないですが、「不具合が見つかってよかった」くらいの気持ちでいるのが良さそうに感じました。
おわりに
「はじめに」でも記載しましたが、本書は非常に読みやすい本でした。
また、チームビルディングの話や体調面の話も書かれており、現場で手を動かすエンジニアだけではなくPM等の管理職の方にも読んでほしい本だなと感じました。
読んで損はない一冊です。7章構成なので1日1章、1週間で読めてしまうのでぜひ。