PdDiv.テクニカルルームのShohei Ootaniです。

今回は、最近読んだ『世界一流エンジニアの思考法』について、個人的な学びと感想をご紹介します。

エンジニア系の用語は出てくるものの、働き方や考え方は職種に関わらず、学びがある内容ではないかと個人的には思います。

• 参考：「世界一流エンジニアの思考法」牛尾 剛【著】- 文藝春秋

本書の概要

　著者である 牛尾 剛 氏（以下、「牛尾氏」と呼称）は、アメリカのシアトルでシニアソフトウェアエンジニアとして、マイクロソフト社に勤務しています。Azure Functions チームに所属し、クラウドサービスの中身をつくっています。

自称「三流」エンジニアの牛尾氏が、周りの一流エンジニア達の思考法に触れ、自身（日本）との決定的な違いや一流達のメソッドを研究し、自分なりの思考法を確立していく様が記載されています。

内容は大きく 3 つのセクションに分かれており、

1. 日本とアメリカの文化（思考法）の違い
2. より良いチームビルディングのために
3. 生活習慣術

というテーマに基づいた全 7 章で構成されている。ボリュームとしては 250 ページ程です。

本書を拝読し、今回は特に印象的だった 3 つの思考法について、紹介と個人的な感想をご紹介します。

学び

「 Be Lazy 」（怠惰であれ）

「 Be Lazy 」＝「より少ない時間で価値を最大化するという考え方」

　この考え、私自身も常に「仕事が楽にならないか？」を思慮しながら実践はしてみるものの、なかなか納得いくところまでは行かずじまいで終わっていました。

　本書では、日本とアメリカの生産性について、下記のように述べています。

　日本は、サービス（付加価値）の細かい部分まで見ようとする傾向にあるが、そこには生産性という観点で工数の 無駄が多い。

　一流エンジニア達は「いかにやることを減らすか？」に頭を使っている。一般的にたくさんの機能を速く実装することはいいことだと思われがちだが、本当は「悪」である。なぜなら、統計によると実際はソフトウェアの機能のうち 40% ぐらいしか利用されていないからである。100% を全力でつくっても 60% は使われないし、しかもそこでバグが発生したらその都度直さないといけなくなり、コードベースが多くなるので、変更があったときにコードを読む量が増えてしまう。

　このことについては、耳が痛い限りです。しかも、薄々は感じてはいるものの機能の 40% しか使われていないという統計データまであるなら、全てがそうではない（その考えも悪かも？）としてもいかに「無駄」な工数に力を割いているのかが分かります。

　本書では、＜ 2-8 の法則 ＞ というのを活用しています。

　＜ 2-8 の法則 ＞とは、100% のタスクを全部やろうとすると工数もかさむし、時間が足りません。20% のタスクで 80% の価値を生むのであれば、価値ある 20% をしっかりやり、残りの 80% はやらずに、次の 80% の価値を生む 20% の新しいタスクに取り組むといった方法です。

　Be Lazy の精神で「やることを減らす」のは大変素晴らしいことです。ところが日本人の感覚からすると、全部やらないのは何となく悪いことのように感じてしまい、現行の手続きやすでに決まっているタスクを「減らす」のがとても苦手だ。しかし、重要なのは、「減らすこと」自体に価値があると、マインドをリセットすること。

　アメリカで生産性が高いのは、こうした理論により、実施すべき「物量」が少なく「価値」が高いものを如何につくっていくかの思考に全力を注いでいる点なんだと学びを得た記事です。

不確実性を受け入れよう

一生懸命未来を予見し、緻密な計画を立てることに時間を使ったあげく、商品やサービスが世の中の実態にそぐわなくとも、当初の「計画通り」に遂行しようとして、プロジェクトをのものが炎上してしまう場面はしょっちゅうある。

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

その第一歩として、「納期は絶対」の神話は捨てよう。

日本の場合、納期に、予定された機能がすべて搭載された製品を、予定された品質で納品することが求められる。

しかし米国では、「納期は柔軟」だ。多くの案件は期日通りリリースしているが、実は中身は予定よりも少ない量に変更されていることはよくある。納期を守るために、徹夜する人たちも見たことがない。日本人は納期に厳格すぎて無理をしすぎる傾向にある。だが、そこにどれほどのバリューがあるだろうか？

アメリカでは納期が近くなっても、「無理して機能を完成させなくていいから、品質の良いものをつくるようにしよう」とマネージャから言われる。

さほど問題になりもしない納期とリリース機能を守るために、プログラマの生活や健康を犠牲にしてまで取り組むことは、中長期的には疲弊して生産性が低下してしまうことになるので、マネジメント的に効率が悪いのだ。

決して無理はしないほうがいい。なぜならチームの適正な生産量を超えた量を一定期間で達成した結果、組織の問題を覆い隠すことにつながるからだ。「今回できたのだから、次回もこれぐらいできるよね」と、無理が積み重なる悪循環に陥りがちだ。チームの実態が上層部や周りに伝わらず、問題点も改善されない。

チームのリソースを超えているときは、現実を見て「物量を減らし、より大きな価値を生み出す工夫」が必要だ。Be Lazy の精神でいかに「やらないこと」を見つけるかがポイントとなってくる。

　こちらも耳が痛い話しです。私自身も上記の神話の信者でした。

　アメリカでは、無理に納期に合わせることを悪として捉えており、先にも述べたように「実態を見て、如何に負担を減らし、大きな価値を生むか」に力を注いでいるのかを知り、衝撃的かつ自身の考え方の価値を見直すきっかけを得た記事です。

　また、牛尾氏の仕事環境では、「失敗」を許し、すぐさま失敗をフィードバックして軌道修正を図ることに称賛される風習があるそうです。無理なく柔軟に働き、かつ失敗しても怒ることはせず、すぐさま軌道修正へと対応を進めている辺りが、個人でもチームでもとてもモチベーションが保たれた環境であることが容易で想像がつきます。

　未来の出来事は不確実であって当然であり、納期が絶対なんてことは、不自然です。その辺りも踏まえ、今後の仕事の進め方を改めて考え直す機会かも知れません。

複雑な技術をコントロールできている感覚を得る

　こちらは、私自身もそうであるし、自分が出来ない人間だと思い込んでいる人たち向けに紹介したい記事です。

　基礎的なことに時間をかけて理解する大切さは、プログラミングでもまったく同様だった。

　ミーティングに出るときも、普段なら理解をあきらめて自分のパートだけでもなんとか対応する感じだったのが、「理解しよう」という意識を持つことで、わからない英単語を聞いたらその場で調べるようになったし、わからなかったら聞き直すようになった。同僚をみならって、会議の間にわからなければレコーディングし、AI で生成されたスクリプトを時間をかけて見直し、理解するように努めた。

　「理解は時間がかかるもの」として、急がず、徹底的に理解する習慣をつけていくと、自分の人生でかつて経験したことがないことが起こった。以前はメモを取りまくっていたコードリーディングもゆっくり理解することで、100% 挙動が理解できているし、その確信がある。

デバッグ（プログラムのバグ取り作業）のときも少ないログをゆっくり観察して、従来読み飛ばしていたようなログの他の項目も見ることで、圧倒的に試行錯誤が減って問題を一直線に解決できるようになってきたのだ。

　本書では、一流プログラマの方達とのやり取りが何度か出てくるのだが、その一流プログラマ達もいきなり何でも出来たわけではなく、しっかりと時間をかけて基礎を理解するといった事を実践しています。小手先だけで、その場を上手くやり過ごせても、やはり基礎をしっかりと理解している人との差は、身をもって実感はある。基礎を身につけ、コントロールできることで試行錯誤の手間が省けることも納得です。

　とは言え、私自身も基礎がしっかり出来ているわけではなく、今回のことで今一度初心に戻り、基礎を見直すきっかけの記事です。もしこのことに共感を得ている方がいるのであれば、「基礎はやはり大事」ということを切に伝えたいです。

まとめ

　今回は『世界一流エンジニアの思考法』から得た個人的な学びと感想をご紹介しました。

　このような社会学概論のような学びを、もっと早く学んでいれば、これまでの人生もどうだったのだろうと思いにふけることもあるが、牛尾氏の行動や思考が、私にとってはすごく活をもらえました。

　全部はご紹介することは出来ませんが、刺さる記事がいくつもあり、学びが多く、個人的にはかなりの良書でした。

　今回きっかけに、いまは「メンタルモデル」について書籍を読み始めており、自分の、自社の、日本の働き方を見直したいと考えております。