生産性を上げたいなら、定時に帰れ：『世界一流エンジニアの思考法』を読んで得た素敵な言葉

2025年5月24日

はじめに

お世話になります、hosochinです。
今回は、牛尾剛さんの著書『世界一流エンジニアの思考法』を読みました。
マイクロソフトに入社した筆者が、一流のエンジニア達から学んだ思考や習慣を綴った一冊です。技術の話というよりも、「どう考えるか」「どう働くか」といった根本の部分にフォーカスされています。
この記事では、特に自分が素敵だなと思った言葉や考え方を中心に紹介していきます。

・「生産性を上げたければ定時上がりが効率が良い」

タイトルにも入れましたが、これが一番刺さりました。
周りにいるのは一流のエンジニアばかり。そんな中で成果を出すにはただ頑張るしかなかった筆者。
毎日仕事して寝るだけの生活が続き、どうしたら生産性を上げられるかメンターのクリスに相談します。

「生産性を上げるためには学習だよ。だから、僕は仕事を定時ぐらいで切り上げる。その後で、自分のやりたいトピックを勉強したり試したりする。」
…省略…
ああ、そうか….生産性が上がる秘訣は「学習」なのか。仕事ばかりしていては短期的なアウトプットは上がったように見えても、根本的な生産性が上がらないんだ

本当に生産性を上げたければ長時間労働をやめないといけない、というシンプルな事実に気付かされたという話。
いやー分かる。ついついやってしまう。僕も明日から絶対定時で上がるマンになります。

・頭が良くても「理解」には時間がかかる
・「理解に時間をかける」を実践する

なんとなく雰囲気でやっちゃってること多いんですよね。。理解するってのは時間かかるし体力もいるし。
ただ一流のエンジニアたちも、そうした1つ1つの「理解」の積み重ねで成り立っているんですよね。

皮肉なことに「早くできるように頑張る」ということが最終的な生産性をむしろ下げていた

・Be Lazy（怠惰であれ）というマインドセット
・より少ない時間で価値を最大化するという考え方
・時間を固定して、できることを最大化する

このBe Lazyを達成するための習慣として以下のようなことが挙げられていました。

• 最低限の努力で達成する
• 不必要なものを無くす
• 簡潔さを目指す
• 優先順位をつける（インパクトの大きいモノ以外やらない）

いかにやることを減らすか、「減らすこと自体に価値がある」という言葉が素敵でした。

・リスクや間違いを快く受け入れる
・Fail Fast（早く失敗する）

挑戦→失敗→フィードバック→修正→挑戦…というサイクルが早いほど価値があると書かれています。
そして「リスクや失敗」を恐れる体質は生産性の面で劇的な低下をもたらすと。

今の時代、検討ばかりして、さっさと「やらない」ことのほうが最大のリスクだということを肝に銘じてほしい。やらないほうが必ず失敗する確率が増えるのだ。

思い当たるところがありすぎる。。。たとえば個人開発で何か作ろーとか思っても、どのクラウドサービスの何で構築しようかとか、料金体系どうなってるとか調べ始めてなんか結局中途半端に終わるやつ…w
って思って読んでたんですが、数ページ先で刺されました。

アーキテクチャやツールが数種類あってどれにするか決めあぐねているパターンがあるとしたら、意思決定は簡単だ。
答えは「どちらでもいい」。
…省略…
そんなことの選択にだらだらと時間を使うべきでない。

😇

・いかに脳みその負荷を減らすか
・コードリーディングのコツは極力コードを読まないこと

「コードリーディングのコツは、極力読まないことですよ。他のデベロッパーのことを信頼して、実装はちゃんと動くものとする」

なんかいい言葉。

・ディスカッションで鍛えられること

ディスカッションは「どちらが正しいか」はどうでもよく、「自分の考えを自分なりに深めるための行為」なので、初心者こそやったほうがいい。
コツは、「間違えたら恥ずかしい」という感覚は一切捨てること。

分かってはいるんですが、中々捨てきれてないなあ。。ただこれも「Fail Fast」の精神ですよね。
知ったかぶりしてる方が恥ずかしいですし、早く失敗できれば早く成長できますね。

・メンバーが「楽しんでいるか」が非常に重要視される

基本的にはリーダーがいろいろ言えば言うほどチームは指示待ちになっていくということ。

日本では、組織で「我慢できる」のが大人、インターナショナルな職場では、「自分で自分の考えや人生に責任を持つのが大人」

我慢する方が楽だから逃げちゃってるときあります。。自分がコントロールしてる感があるときって仕事楽しいし、「大人」であるときなんでしょう。

・不確実性を受け入れよう
・その第一歩として、「納期は絶対」の神話は捨てよう

ソフトウェア開発の見積もりってむずすぎるんですよね〜。やってみないと分からないこともたくさんありますし。
僕もどうしたら精度の高い見積もりが出せるか、みたいなことを考えていた時期がありましたが、もしかしたらそれは全く本質的ではなかったのかもしれません。

「計画通り」いかないことは決して「失敗」ではない。そもそも未来を正確に予見できる人なんてこの世の中に存在しないし、なぜ「計画通り」でなければならないのだろうか？むしろ、スピーディーに軌道修正をかけていける柔軟性のほうがはるかに大切だ。

「批判」の文化がすべてをぶち壊しにする

日本では「責任の所在」や「完璧」を求める文化があるが、これがソフトウェアの開発に関しては少しも良いようには働かない。むしろ足を引っ張っている。

筆者はこの文化を痛烈に批判しています。筆者の熱い思いが非常によく伝わりました。少しでも欠陥があると批判したがる傾向はXを見ていても良くわかりますし、社会的問題にもなっていますよね。。。

おまけ

アジャイルについて触れているコラムがあるのですが、面白かったでので載せておきます。

マイクロソフトのソフトウェアプロセスの専門家サム・グッケンハイマーが来日し、
…省略…
「ウォーターフォールとアジャイルのメリット・デメリットは何ですか？」と尋ねたお客さんに、彼はこう言い放った。
「ウォーターフォールは一切メリットがないのでやめておきなさい」

👍