世界一流エンジニアの思考法 の商品レビュー

牛尾剛(著者)

2023/12/22

とても含蓄のあるいい本でした。自分が実践していたことの裏付けもでき、人生観にもいい影響を与えてくれた良書です。

2023/12/22

ライフハックのエンジニア版。著者自身が強いエンジニアとの差に悩み、その分析・言語化をしてくれています。印象に残ったのは、まず「理解に時間をかけること」。強いエンジニアも即座に理解しているわけではなく、同じように時間をかけています
。そこにおいて重要なのは、「無闇に試行錯誤せず、自分の中で仮説を立てて、それを検証する」「難しすぎる、つらいとかんじるときは、その手前の学習から始める」。脳にどれくらいの負荷がかかっているかを意識することです。自分と同じくADHDの傾向もあり劣等感など悩みどころにていて、文章も読みやすく、とても楽しく読めました。

2023/12/20

生産性はもちろん、自分が辛くならないための考え方やメソッドであると感じた

著者がとてものびのびと仕事していることが伝わってきたし、とても羨ましい職場環境と思った

少しでもそんな働き方に近づけるよう、できることから意識していきたい

2023/12/18

プログラミングの専門用語が出てくるので、スムーズに読めるとは言えないが、社会人として応用の効く汎用的なことを学べる。

以下３つを実践したい。
①マルチタスクは避ける
30分から1時間で区切る。タスクをどうしても中断する場合は、どこまで進んでいて、どこから取り掛かるのかを必ずメモする。タスクが完了したら、気移りする前に残骸は消す。
②理解は時間がかかるものとして、急がず、徹底的に理解する習慣を身につける。
③Be Lazy 怠惰であれ、を実践する。
より少ない時間で価値を最大化するという考え方。2-8の法則で、20%の仕事が80%の価値を生む。本当に大切なことに時間を使う。そのために時間を固定して、その中で価値を最大化する。

2023/12/14

1番の発見は、頭がいい人でも理解は難しいということだ。難しいものは難しい。本質の理解は、難しいからといって、なんとなくで過ごすと高くつく。新入社員だが、いらない会議には出ない、自分の時間を確保する。これを続けたい。

2023/12/13

その場しのぎの早さではなく「理解」に重心を置いたほうが、結果的に「早い」つまり生産性が高くなる。これからエンジニアとして働くうえで、この本に出会えて良かった。ありがとうございます。

2023/12/11

自分にも活かせる部分と組織全体で変えていかないといけない部分のどちらもあり参考になった
マイクロソフトのような職場で働いてみたい気持ちと日本の残念な感じの職場への絶望が湧いてきた

2023/12/11

人に説明可能になるまで理解する方法は、学んだことを自分なりの形でブログに書くこと。
作業内容を空で説明できるか。

タイムボックスを作って生活する＝時間枠を決めて生活する。
瞑想について。５～１０分のタイマーをセットする。鼻から吸って口から吐く。動く空気に集中する。
テストステロンブースター

2023/12/10

マイクロソフトのトップエンジニアの思考法について書かれた本(一部は、その人に受けた著者の思考法)。

後書きにあるように、何かをプラスでやるのではなく、いろんなことをやめて身を軽くするというのが大事なのだろうなと思った。

著者はADHDらしいのだけど、自分もADHDの傾向があるので、共感できるところもあった。本当、気づけば、部屋が散らかってるんだよね…。
著者は、整理をしてADHDの症状が改善したそうだけど、自分もちゃんと整理していきたい。身の回りの物を減らしていったほうがいいのかな。
オススメされてた『あなたの1日を3時間増やす「超整理術」』も読んでみたい。

仮説が重要というのは、本当そうだよなと思う。思いつきの試行錯誤は悪とのことだけど、今年入ってきた新人がそういうタイプだなと思う。プログラミングはかなりできるほうなのだけど、コードが試行錯誤した感じで、コードの説明を聞いてもうまく説明できないことがある。

ちゃんと理解できないことがあったら、初歩の学習からやり直したほうがいいというのは、なんとなく分かる。先ほどの今年の新人も、プログラミング能力高い割には、たまに基本的な知識が抜けていたりするので基本から学びなおしてほしかったりする(for文の3つ目の式が分かってなかったり。「i++」と書くものだと思ってたらしい)。業務時間内にできるものでもないので、軽くお願いするのも難しい。

ドキュメントを書くというのが、どういうものなのかもう少し例を知りたかった。コードにJSDoc形式のような感じで、コメント書いておくだけじゃダメかな…なんて思ったりする。

優先順位なんて立てずに、一つだけピックアップするというのは、分かるような分からないような感じ。優先順位を決めて、一番目をまず注力するのと何が違うのだろう。

ミーティングの議事録はその場で書かないというのは、よく分からなかった。記憶力があるならともかく、無いならその場で書いた方がいいと思うのだけど、そういう問題ではないということなんだろうか？

質問する場合に、情報が多いと嫌がられるというのは、結構驚き。自分は、多く書いちゃうし、部下にも多く書いてほしいと思っちゃうタイプだなぁ。
情報量が多いと分かりにくいというのは分かるけど、少ないと漠然としてそれはそれで分かりにくいと思うんだけどなぁ。なかなか、難しい。

ググったらすぐに分かる内容も、マイクロソフトでは気軽に聞けるし、嫌がられないというのも結構驚き。アメリカでは「ググれ」なんて言われることはないのだろうか。

それにしても、日本はすぐに相手を批判する人が多いのだろうなと。バグなんて、どんなエンジニアでもだしてしまうことなのに、すぐに批判するとか。エンジニアにとって、日本は生きにくい社会なのかな。そのへん、うまく変わってほしいものだと思う(海外で働きたいとは思わないので…)。

2023/12/10

タイトルの通り、一流エンジニアの思考法がわかりやすくまとまった良書でした！

Microsoftのエンジニアなんて雲の上の存在で、自分とは頭の作りから違うんだろうなと思っていましたが、本書に載っている思考法は真似できそうなものばかりで、一つ一つ取り入れていけば自分も一流に近付けるのではないかと思わせてくれました。

とっても便利なライブラリを見つけたときのような感動がありました。
わかりやすく一冊の本にまとめてくださった牛尾さん達に感謝です。

以下、思考法のメモ

・闇雲に手を動かすのではなく、仮説に対して検証する
理解には時間が掛かることを前提とする
・感覚で決めつけるのではなく事実をベースにする
・Be lazy 怠惰であれ
・バックログから一つだけピックアップして他はやらないと決める
・リスクを受け入れ、失敗を歓迎する
・検討するよりさっさと検証する
・批判よりフィードバックを大切にする
・知識は頑張って思い出すことで記憶に定着する
・エキスパートに聞いてすぐ解決できそうなものはすぐに聞く。逆に相手も時間が掛かりそうなことは自分で調べる。
・気軽に聞ける空気の大切さは気軽に断れる空気とセット
・意見が対立しても否定はしない。"In my opinion" 僕の意見はこうだけど、最後に決めるのは君だ。だから僕の意見は捨て置いてくれて構わないよ。
・仕事は我慢するものではなくエンジョイするもの
・タイムボックス制。絶対に定時で上がると決める。
・気力の無さは体力の無さから
・自分の人生や幸せに責任を持って、自分でコントロールして生きていく