【書籍】世界一流エンジニアの思考法
はじめに
初めまして。中小企業のSIerで働いているHorowitsと申します。
シニアエンジニアの方から、「人に見せるアウトプットをすることでフィードバックがもらえるので、ブログを書くのがおすすめだ」とアドバイスをいただき、今回、初めてブログを投稿させていただきます。
至らない点もあるかと思いますが、ご意見・ご感想をいただけると嬉しいです。
第一章（メモ）
1.「できるプログラマ」と「できないプログラマ」では、生産性に25倍もの差があると言われています。
2.闇雲に手を動かすのではなく、まず事実を一つ見つけ、それをもとに仮説を立て、検証を行った上でコードを書くことが重要です。
3.理解に時間をかけ、本質的に理解することが大切です。
4.初歩的な学習を「簡単だ」と決めつけず、一からやり直すことで、自分が「なんとなく理解しているつもり」でも、実際にはしっかり理解できておらず、「即座にコーディングできない」ことが多いと感じています。
5.顧客の発言には不確かな情報も多いため、話を聞く際には疑問を持ち、事実を検証する姿勢を大切にしています。
6.優れたプログラマは、手を動かす前に理解を深めるための強力な手法として、ワード数ページ程度の設計アイデアや大まかな仕様をまとめた「デザインドキュメント」を最初に作成しています。
7.エンジニアの成長は、チームの生産性向上にもつながるので、エキスパートに質問することを恐れず、積極的に学んでいく姿勢を大事にしています。
8.複雑な情報を素早く処理するためには、何らかの「脳内イメージ」を持つことが重要であると学び、自分なりのメンタルモデルを意識するようにしています。
9.一つの課題に2時間以上つまずいたら、質問や相談をして一旦置いておき、別の作業に切り替えたほうが生産性が高いです。
10.既存システムがある場合は、まずエキスパートに頼るのが最善。肝心な情報を無駄なく理解できるためです。
第一章の感想
2.が私の中でとても刺さりました。
上司に「手を動かしながら実装しなさい」と言われた事があり、その言葉を鵜呑みにして実装していたのですが、同期でかなり出来るエンジニアは鵜呑みにせず、自分で仮説を立て、キチンと自分で理解してからコードを書いていた事を思い出しました。どちらが正しいのか迷っていたのですが、2.の方法で試しに実装してみると、深いレベルで仕様を把握する事ができ、実装内容に不備が出てきた際に今まで以上にすぐに解決する事が出来ました。手を動かしながら実装をすると理解が浅くなるので、今後は2.の方法で実装に取り組んでいきます。
・サンプル
問題：
問題に対しての修正方法：
修正方法の問題点：
修正方法の改善点：
動作確認パターン1：
動作確認パターン2：
動作確認パターン3：
上記のようなサンプルを作成し、実装する前に問題と修正方法を文章化してから実装に取り組みました。
プルリクエストを出す時のコメントにも使えるので、私は今後この方法で今度実装します。
第二章（メモ）
1.「怠惰であれ」という考え方に触れ、最小限の労力で最大限の成果を上げる方法を模索し、常に効率的に思考・行動しようと意識するようにします。
2.2-8の法則（パレートの法則）」を学び、全体の成果の80%は20%の重要な仕事から生まれるということを理解した。日本人の感覚として「全ての業務に取り組まないこと」は悪いことのように思われがちだが、不要な業務を減らすこと自体に価値があるというマインドを持つことが重要だと学んだ。そのため、価値の高い20%の業務にフォーカスし、無駄なことには極力手を出さないようにしようと考えました。
3.「リスクや失敗を快く受け入れる」という考え方を学んだ。人間は間違える生き物であり、「リスクや失敗を恐れる体質」は生産性を著しく低下させてしまう。常に正解を求めて検討ばかりしていては前に進めない。むしろ、「失敗しないように何もしない」ことこそが最大のリスクであることを学んだ。「失敗はただの結果に過ぎず、そこからどんなフィードバックを得たかが重要である」という考え方を学んだ。また、職場では「怒る」という選択肢をなくし、フィードバックを促進するような雰囲気づくりを積極的に行うべきだと知った。誰もが最初から正しい方法を知っているわけではない。だからこそ、まずは試して、失敗し、フィードバックを受けて素早く方向修正していくことが大切だと思った。失敗をそのままにしておくことは確かにマイナスだが、気づきに変えることができれば、それはプラスになると感じました。
4.未来を正確に予測できる人は存在せず、計画通りに物事が進まないのが当然だということを学んだ。そのため、完璧を目指すことをやめ、柔軟性を持って取り組む姿勢の大切さを実感しました。
5.たくさんの物量をこなすことが生産性の高さを意味するわけではなく、生み出すものの価値こそが重要であると学びました。
6.心理学には「鏡の法則」というものがあり、自分自身に課しているルールを、無意識のうちに他人にも当てはめてしまう傾向がある。たとえば、納期を厳守して仕事をしている人は、他人にもそれを当然のように求めがちだ。特に日本人は、骨の髄まで納期厳守のDNAが刷り込まれている。寛容であるためには、まず自分自身へのルールを緩めることも必要です。
無理な要求が連鎖すると、結果的に疲弊を生み、チームや組織の業務改善にはつながらないです。
7.他国の文化や視点を学ぶことで、自分にとっての「常識」が、他国では「非常識」であることに気づかされることがある。多様なスタイルを知り、常識を疑うことで、今自分がしていることが本当に価値があるのかを見直すきっかけになるかもしれないです。
第二章の感想
6.について上司が残業して無理な依頼を引き受けている姿を見ていたことがあり、私自身も、残業して無理な依頼をこなすのが当たり前だと思い込んでいた。しかし、無理をすればミスも増え、プログラムの質も落ちてしまう。だからこそ、「無理なことは無理だ」と断る勇気が大切なのだと感じました。
（とはいえ、日本的な働き方が根強い企業と取引している場合、「無理です」と言ったことで仕事を失うリスクもあるのではないか、とも思った。）
令和の時代になっても昭和的なやり方を続けている会社は、新しい世代の人たちがついていけず、いずれ社会の変化に対応できなくなるのではないかと思いました。
第三章（メモ）
1.コードリーディングのコツは、クラスの役割やパターン、インターフェースの理解など「必要な部分」だけを読む事であり、端から端まで実装を読む必要はない。読む量を減らすことで、脳に余裕を生み出します。
2.人が「自分には難しすぎる」と感じるものには、主に2つのケースがあります。
1つ目は、自分の基礎的な学力が不足しているケースであり、これは地道に積み上げるしかなく
2つ目は、自分に合わない方法で取り組んでいるケース。つまり、「自分には何かが足りない」「才能がない」と思い込んでいる状態です。
「難しすぎる」と感じるときは、たいてい脳の使い方が間違っているサインであり、才能の差ではなく、脳に余裕がない状態で酷使している可能性が高いです。
3.仕事の難易度をレベル分けして考える。生産性とは「レベル1」の仕事をいかに増やすかです。
レベル1：自分が何も見ずにサクサクとコーディングできることを増やしていく
レベル2：何も調べずに即実装できる
レベル3：調べれば解決できる
レベル4：スパイクソリューション（課題把握のための大まかなプログラム）があれば、何とかなる
レベル5：自分では解決できない
4.構造を把握する際に重要なのは、自分にとって「しんどい」と感じるような努力は一切やめることです。
「楽しくなくて苦しい」と感じるときは、それは「無理をしている」というサインです。
自分のレベルに合っていないことに取り組んでも、上達にはつながらないです。
大切なのは、「今の自分では解けない」と見極める力です。
5.何かを変えたければ「住むところ」「付き合う人」「時間配分」のいずれかを変えるべきです。
6.人に説明可能な状態にもっていく訓練として最良の手段の一つはブログを書いてみる事です。
サンプルコードはそのまま使うのではなく、自分なりに変えたものを作る事です。
7.人間が記憶をするために有効な方法は、思い出そうと頑張る事です。
アウトプットを意識したコーネルメソッドの方法でノートに書くのがおすすめです。
次の日に見直して覚えているか確認するようにします。
8.会議は文字に頼らずその場で記憶するというつもりで聞く、人の話を聞くときは後で人に説明する事を意識します。
第三章の感想
3.について「レベル１」が出来るように意識しているのだが、これが中々難しいです。
Paizaを使用してD級問題から解いているのだが
自分が如何にAIに頼って実装してきたのかが、分かりショックを受けた。C級問題が解けるようになってはきているが、もっと自分の実力でサクサクコーディングが出来るように基礎力を向上させます。
第四章（メモ）
1.相手が本当に欲しい情報は何か？を普段から意識することで生産性を向上させる鍵となリマス。
2.自分が学んだこと、試したことを整理して、OneNoteでチームに共有します。
その際に「自分用の、自分がわかるため」の書き方ではなく、見る人が欲しい情報はこれだろうと整理しておきます。
3.日頃から人に伝えることを意識しておくことで、何か質問された際の工数削減に直結します。
4.プルリクエストのレビューを減らす為には「読んだ人がどう感じるか？」を意識してコードを書く必要があります。
第四章の感想
2.について仕事で資料を作成しているのだが、膨大な量で見にくい資料になってしまったので、見る人を意識して資料をOneNoteで作り直します。
4.について今まで読んだ人の事を考えずにカオスなコメントを書いてしまった事があったので、意識して気をつけます。
第五章（メモ）
1.チームが自ら考えて自分で意思決定をするスタイルにしていかないと、リーダーが色々と言えば言うほどチームは指示待ちになって、自分たちで考えなくなります。
2.チームメンバーが楽しんでいるか、幸せに働いているかに高い関心を持つことで、仕事は楽しんでなんぼの心地の良いムードが生まれます。
アメリカではみんな「ハッピーかどうか？」が重要であって、仕事で「辛さに耐える」と言う発想が全くない
できる人たちにのびのびとパフォーマンスを発揮して欲しかったら、何よりもチームメンバーが「仕事を楽しめる」環境を作ることが大事です。
3.新人に「できないもの」として簡単な仕事を振るのではなく、「できるもの」として大人扱いすると、周囲の助けを借りつつきちんとやれるようになります。
4.失敗は恐れなくていい、私たちはいつも未知のことをやっているから、気にしなくて良いです。
5.少ない工数で、多くのバリューを出すことに高い価値を見出す事が大事です。
第五章の感想
3.についてだが、まずは簡単な仕事を振ってその内容が正しければ重たいものを振るのが良いんじゃないかと思いました。
5.に関してはまさにそうだと思った。日本人は無駄に働き過ぎていると思いました。
第六章（メモ）
1.生活面を含めてトータルで心身をどう整えて行くかが、仕事のパフォーマンスに直結します。
世界のトップエンジニアたちはみな身体のコンディションに気を配り、ワークライフバランスを組み立てています。
仕事に臨むマインドはどこから生まれるかといったら「身体」にほかならないです。
2.生産性を上げたければ定時上がりが効率が良いです。
仕事を定時ぐらいで切り上げて、その後で、自分のやりたいトピックを勉強したり試したりします。
たとえ同じプログラミングでも、仕事と切り離したものはリラックスしてできます。
3.睡眠時間が7時間確保できている人が最も死亡率が低くて長生きします。
睡眠不足は脳の集中力、処理能力、記憶力に悪影響を与えるため、脳を十分に休めることは、生産性を上げるための絶対条件です。
4.一日に一つのことに集中できるのは4時間、4時間過ぎたら違うことをする事、休息するのは何もしないことではなく、いつもと違う事をするのが重要です。
5.幸せを感じるから成功するのであって、成功したら幸せになるわけではないです。
第六章の感想
5.について、幸せを感じる事に対して進んで行動し幸福度を高める事が人生において一番重要ではないかと思いました。
第七章（メモ）
1.AIに奪われにくい仕事は、少なくとも当面の間は、身体を使う仕事、人との関わりが中心となる仕事、そして創造的な仕事や芸術の分野です。
2.アプリケーションはどんなに優秀なチームが開発しようが、必ず何かしらの不具合が存在します。
3.日本の批判文化では、いいところが９あって、問題が１であっても、１をクローズアップして批判さレます。
4.日本は、できもしない完璧主義とメンツが重要視される。精神論で発破をかけ、納期厳守で徹夜でやらせるような、管理はグローバル基準でいったらプロのマネジメントではないです。
5.海外チームにいて感じる日本の会社との一番大きな違いは、「不幸そうな人がいない」
どうやったら自分の人生が幸せになるかを主体的に考えて、仕事の仕方を選択しています。
6.お金儲けや成功と幸せに相関関係はない
自分が幸せになる方向に人生の選択をする。自分が好きだからするように考え、自分が幸せだと思う方向に舵を切る選択を続けていくと、ちょっとずつそちらに近づいていきます。
第七章の感想
6.について、そのままだが自分が好きだからするように考え、自分が幸せだと思う方向に舵を切る選択を続けていこうと思いました。一般的に見て成功している経営者の人も幸せように見えない人が多いと書いてあり、私の中で成功とはお金を稼ぐ事が一番ではないがかなり重要な所だと思っていたのだが、そうではなく自分が幸せだと思う事に対して自ら行動する事が大事なのだと改めて感じました。
最後に
メモの所でAIを何度か使ってしまい章によって見にくいところがあるので、次からは気をつけます。
日本と海外の働き方の違いについてかなり書かれていて、海外の文化をかなり魅力的に書かれていたが
海外で働く事のデメリット部分があまり記載されていないように感じられたので、海外起業で働く事の全てが良いわけじゃないと思いました。
ただ、読んでいて特に日本社会の批判文化に対しては良くない事だと思い、自分がもし上の立場になった際は寛容になろうと思いました。
拙い文章ですが、読んでくださった方には感謝します。
Discussion