「世界一流エンジニアの思考法」オススメの一冊
ども、カニカマです。カナダでITデベロッパーとしてアプリ作ってます。がんばってます。
今日は最近読んで面白かった本。
エンジニアならぜひ読んでほしい本の紹介。
TL;DR
一流のエンジニアはどういう風に生産性をあげてるか
いいエンジニアとしてのどういった思考法を心がけているか
アメリカと日本のソフトウェアへの取り組み方の違い
北米のエンジニアの働き方
AI時代のエンジニアの思考法
エンジニアの普段の仕事の取り組み方
エンジニアとしてのチームのあり方や関わり方
とりあえず上記のことに興味があるならばぜひ読んでいただきたい。
技術的な話ではなくてエンジニアのマインドセットの話。
エンジニアだけじゃなくPMやソフトウェアの会社に関わってる人にはぜひ見ていただきたいな。
感想
筆者の方はアメリカ・シアトルのマイクロソフトのAzure Functionsというクラウドのチームに所属されてる方。
渡米前も大手SIerからエンジニア、コンサルタントなどをいろいろ経験されていて日本、アメリカ両方のエンジニア文化を理解されています。
それだけでも自分からみたら超すごいのだが、驚いたのは自分のことを「三流エンジニア」だと認識されているところ。実際はすごい方なのだろうが、確かにGAFAクラスのエンジニアだとレベルがちがう頭脳が世界中から集まってくる。そう思っても仕方ないなっていう環境であるのは間違いない。
その筆者の方が普段世界で活躍するエンジニア達と仕事をしていて気付いた点やどうやってキャッチアップしていったか、日本とアメリカのチームの違いなどをわかりやすくまとめてあるのがこの本。
とにかく読みやすかった。
実際の体験をベースに書かれているのでイメージもつきやすかった。難しい内容はほどんど無かったので時間もかかることなくスッキリ最後まで読むことができた。
一部抜粋
構造を理解する
どんなに頭がいい人でも理解には時間がかかるものなのだ。頭のいい人が理解が早いように見えるのは、そうやって時間をかけて基礎を積み重ねているので、既に理解していることに関して頭のメモリにコンテキスト（文脈）が載っているからだ。
<中略>
「早くできるように頑張る」ということが最終的な生産性をむしろ下げていたように思う。
僕の周りのエンジニアにも優秀なやつがたくさんいる。どうやってそんなに素早く物事を理解しているんだろうと思っていた。
なるほど。理解のアプローチが確かに違うのかも。
時間をかけてもいいので構造を理解することに力をいれる。
先に構造を理解することでどこでも使える知識になるし応用も効くようになる。
ドキュメントを先に書く
・ドキュメントを書くことで自分の頭が整理される。抜け落ちていた視点などに気づくことができる。
・考えているときに書けば、自動的に〝ドキュメント〟になるので、それをシェアするだけですむ。後でまとめて退屈なドキュメントを書かなくてよい。
エンジニアならドキュメントの大切さがわかっているはずだが、ドキュメントだけを書くのは大変で退屈だ。なのでコードを書いている時に先に書いてしまおうと。
人に聞け！
「自分や、ドメインエキスパートに対して質問するのを恐れないように！ エンジニアがより賢くなるのはチームの幸せにつながるよ」
一つのことで ２時間以上ブロックされたなら、質問するなり相談するなりして寝かせておいて、他の仕事をやっておく方が断然生産性が高い。
<中略>
日本は、「ググれ、カス」という言葉があるぐらい、自分で調べてから人に聞くべきという文化だが、少なくとも私のやっているクラウドの中身をつくるような複雑なシステムの場合、どう考えても全体的効率が悪い。
この本で繰り返しでてくるのだが、わからないことがあったらチャッチャと人に聞けってことがある。
ある程度自分で調べて多少悩んでそれでも分からなかったら聞くっていうのが当たり前だと思っていたが、そうでもなさそう。
もちろん内容によるので初歩的なことを聞くのはどうかと思うが、多少ドメインの知識が必要になることやそのコードの歴史が必要を知る必要があることはさっさと聞いてしまったほうがいい。
僕も人に聞くことをためらってしまうことはよくあるのだが、自分で無理やりなんとかしようと無駄な時間をかけて生産性を落とすより詰まったらドメイン知識がある人に聞くことにするように心がけたい。
生産性を高めるためにやることを減らす
「Be Lazy」（怠惰であれ）
プログラマーはいかにサボって機械に仕事をさせるかが鍵となる。
プログラマーなら当たり前だと思うかもしれないが案外これができていない。
例えば優先順位をつけるなんてのも海外と日本の感覚が違う。
日本では優先順位をつけるけれども、それでもできる限り全部やろうとする。
しかし海外ではもっとも重要なやつだけに集中してあとはやらない、みたいな判断になる。
２０％の仕事が８０％の価値を生むことを理解していて、全部やろうとするのではなく少ない量で価値を最大化させるのである。
仕事を減らすこと自体に価値があり、いかにやることを減らすか？みたいなマインドセットが重要みたいだ。
これは僕が働いていてもある程度実感しているところで、出来ないタスクはマネージャーがあっけなく次のプランニングの時に外して出来ることに集中する。
それによってリソースも確保できて不測の事態も備えれるし、集中してそのタスクにとりかかれる。結構合理的だと思う。
というわけで
ダメだ。上手くまとめきれない。
本当はもっといろいろメモしている所はあるのだがとても長くなりそうなのでここまでにしておくが、是非エンジニアかマネージャーなら手にとって読んでみてほしい。
エンジニアの勉強の方法
コミュニケーションの取り方や質問の仕方
フィードバックを歓迎する雰囲気
一流エンジニアの仕事の仕方
どういったチームの雰囲気がいいか
生産性の高いチームをどう作るか
仕事をいかに楽しむか
AIとの付き合い方
などなどを実際の体験の例などを交えて分かりやすく書いてくれている。
確かにそうだよなーって事がいっぱい。
特に途中で出てくるメールやメッセージなどに即レスしなくてもいいという話。
即レスすることが、仕事できる人の当たり前だと思っていたがそれもどうやら違うのかもしれないと思ったのが結構私にとっては衝撃だった。
日本は生産性が低いと言われて久しいが、日本のエンジニアは優秀な人が多いので、すこしでも働き方や考え方が変わればもっと生産性は上がるはずである。
あとがきにもある「〇〇をやめる」ということにはかなり納得しました。
面白かったです。
オススメの一冊になりました。
ではでは。
この記事が気に入ったらサポートをしてみませんか？