世界一流エンジニアの思考法 - 読書感想文

はじめに

最近 世界一流エンジニアの思考法 という本を読んだので、備忘録と読書感想を兼ねてこちらへ投稿させていただきます。

<注意事項>

本ブログ記事はあくまでも個人的な読書感想文でしかないので、個人の意見や感想が多分に含まれております。その点ご了承ください。

読書のきっかけ

以下について知りたいと思っていたところ、それらを一挙に学べそうな本書のことを某学習プラットフォームで紹介されていたため、興味を持ち読んでみたというのがきっかけとなります。

1. 率直にエンジニアとして1流になる方法を知りたい
2. 家庭（特に子育て）と仕事の両立に加え、SIerから自社企業に転職した結果めちゃくちゃ苦労していることもあり、もっと楽しくかつ生産性高く仕事をできるようになる方法を知りたい

こんな人におすすめ

個人的には以下のような方におすすめかなと思います。

• 世界のトップエンジニアになるための「習慣」を知りたい
• 仕事の生産性を上げ、楽しく仕事ができるようになりたい

本書の概要

<目次>

**第１章　世界一流エンジニアは何が違うのだろう？
第２章　アメリカで見つけたマインドセット
第３章　脳に余裕を生む情報整理・記憶術
第４章　コミュニケーションの極意
第５章　生産性を高めるチームビルディング
第６章　仕事と人生の質を高める生活習慣術
第７章　AI時代をどう生きるか**

第１章　世界一流エンジニアは何が違うのだろう？

• 試行錯誤は「悪」、仮説を立てて検証する

  • 障害調査の際には試行錯誤で手当たり次第で当たるのではなく、以下の流れで仮説→検証を実施する。
    1. 「事実（データ）を１つ見つける」
    2. 「いくつかの仮説を立てる」
    3. 「その仮説を証明するための行動をとる」

  ※そのためには基礎に対する深い理解が必要

• 頭が良くても「理解」には時間がかかる

  • １流エンジニアの１流たる所以は、時間をかけて積み重ねて得た基礎レベルの深い理解
    • 物事に対する深い理解があるからこそ、コード一つ読むにしても圧倒的にアウトプット量に差が出る
  • そのためには以下**「理解の３要素」**を押さえることが重要である。
    • 人に説明できること
    • 即座に使えること
    • 応用が効くこと

• 複雑な技術をコントロールする感覚を得る

  • 「理解には時間がかかるもの」として基礎の学習を急がず徹底的に理解する習慣をつける
    • その結果、物事に対する理解力が高くなり、問題が発生しても試行錯誤が減って解決スピードが早くなる（当然仕事も早くなる）

• 「感覚」ではなく、「ファクト」を積みかねる

  • 問題が発生した際は、「ファクト」ベースで問題解決しないと「思いのみ穴」に落ちてしまう。（特にログなどを解析する習慣はめちゃくちゃ重要）

• 物事を深く理解するためには

  • 複雑なソフトウェアやアーキテクチャの仕組みを整理し、問題発見に至るプロセスを高速化するには、メンタルモデルを作ると良い。

  • メンタルモデルとは…

    （以下一部本書から抜粋）

    メンタルモデルとは、人々が世界を理解し、予測し、解釈し、新しい状況に適用するための、自己の心の中のイメージや理論のこと

• 「偉大な習慣を身につけたプログラマ」になる

  • 偉大なプログラマとは、当たり前のことを当たり前のようにできる**「偉大な習慣」**を身につけたプログラマのことである。

第２章　アメリカで見つけたマインドセット

• 「Be Lazy」というマインドセット
  • 最小限の努力で最大限のアウトプットを出す。

    • 優先度が高いもののうち上位20%に集中する（2-8の法則）

      ※2-8の法則とは、20%の仕事が80%の価値を生むという法則のこと

    • 付加価値のない仕事をなくす

    • 「アウトプット／生産性」 > 「時間」と心得る

  • そのためには、やることを減らして生産性を上げることに集中する。
    1. 最重要な「一つだけ」に集中する
    2. 時間を固定し、その中で価値を最大化する
    3. 不要な仕事（「準備」「持ち帰り」）をやめて会議の場で解決する
    4. 物理的にタスク量を減らす（意外と不要なタスクは多い）
• 失敗・不確実性は当然として受け入れよう
  • 最大のリスクは、失敗を恐れてチャレンジしないこと。

    • チャレンジがたくさん生まれるには、Fail Fast（はやく失敗する）精神の土壌が整っていてこそ（検討 > 検証 」）

      • 特に以下のループを素早く回すことが重要

        挑戦 → 失敗 → フィードバック → 修正

    • Fail Fastの土壌を作るには、失敗を非難せず、たくさん失敗し、そこから学ぶ文化・環境（フィードバックを歓迎するような）を作ると良い

  • 不確実性の高い時代だからこそ、「計画通り」に行かないのは当然。
    • QCDはトレードオフなので「納期」を絶対視しない
    • 詳細な計画をバリューストリームマッピングを活用すると、開発プロセスを効率的に見える化でき、リードタイムを短縮できる
  • 不確実性を前提とした以下の「思考回路」を形作る。
    1. 「楽に達成できる」計画で仕事をする
    2. 「無理・断る」練習をする
    3. 他の文化の視点を学んでみる
• 「結果を出す」 → 「バリューを出す」に転換する
  • 無理に結果を出すことではなく、「取り組みの中で得た学びのシェア」が仕事にとってのバリュー（財産）である。
    • よって目標達成のために無理するのではなく、「作業量」は定時で終わる程度とし、あくまでも今の自身の実力でできる範囲内とする
    • 無理に働いてまで達成できるような目標を立てても、現場を追い詰め、働く意欲を失わせるだけ

第３章　脳に余裕を生む情報整理・記憶術

• 脳の負担を減らすためには
  • コードリーディングで脳の負担を減らすためには、デベロッパーを信頼して極力コードを読まないことがコツ。
  • そのためには、以下のうち**「レベル１」のものを増やすことが生産性向上**に繋がる。
    • レベル1：何も調べず即座に実装できるもの
    • レベル2：問題を解決する方法は思いつくが、具体的な方法はすぐに出てこないもの
    • レベル3：解決方法を知らないが、課題把握のために実装しようと思えばできそうなもの
    • レベル4：自身だけでは解決が難しい、もしくはものすごく時間がかかるもの
  • WIP（今手をつけている仕事）を一つに限定し、シングルタスクで仕事する。
    • 具体的には、一日４時間は自分だけの時間を確保すると良い（これは職種によるかも）
  • 脳への負担を減らす早道は**「理解 → 記憶 → 反復」**を繰り返すこと。
• 記憶力を向上させるためには
  • やったことを構造を整理・把握することにより、人へ明確に説明できるように言語化しておくこと。
    • 人に説明可能な状態に持っていく訓練として最も効率的な手段は、ブログを書くこと。（そのためにはコーネルメソッドを活用するのが効率的）
  • 打ち合わせ等では「頭の中」でのみ整理してみる。
    • 整理にあたっては、まず話を聞きながらビジュアルイメージやメンタルモデルを脳の中で視覚化しておき、後で文章としてまとめる。
    • また、以下2点を意識しながら話を聞くと集中力や記憶力が向上する。
      • 「その場で記憶する」
      • 「後で他人に説明する」
    • 例えばミーティングのの場合…
      • 議事はその場で書かず、人の話を聞くときは、「人に説明することを想定」し、聞きながら頭の中で整理する。
      • 文章には書かず、頭の中で考え、完全に理解し終えてから文章を書く。

第４章　コミュニケーションの極意

• 「伝える情報量」を減らし、脳への負担を減らす
  • 説明するものは知ってほしい必要な情報のみに絞り、付加的な情報は聞かれたときのみ答える。
  • そうすることにより、「簡単なこと」の説明に注力し、本質的な理解を促すことの説明に時間を使えるようになる。
• 「相手が求めている情報は何か？」という感度を研ぎ澄ましてメモを整理しておく
  • 労力のかかる問い合わせ対応や障害調査等に備え、「欲しい情報は何か？」という視点でメモを整理しておくと工数削減に繋がる。
• ”コードを「読みもの」” として扱い、レビューの工数を減らす
  • 「コードを読んだ人がどう感じるか？」を意識し、”コードを「読みもの」”として書く。
    • 背景が分かり辛い場合、補足説明も入れるとやり取りを減らせる
• リモートワークにおけるコミュニケーションでは “クイックコール” を頻繁に使う
  • 自身にその分野の「メンタルモデル」や「コンテキスト」がなければ、すぐにエキスパートに聞いた方が効率が良い（クイックコールされる側にも最小限の手助けで完了するので効率的）
• 「気軽に聞ける空気」と「気軽に断れる空気」で効率を上げる
  • 「気軽に聞ける空気」は「気軽に断れる空気」はセット。
    • 総じてイケてる技術者ほど「知らないことを知らない」と素直に明かして気軽に質問する
    • 逆に知らない場合、「ごめん」くらいで済ませた方が聞く方も聞かれる方も気楽だし、効率が良い
• ディスカッションで鍛えられること
  • その場でフィードバックがあるので、ディスカッションは短い時間で相当深い知識と理解を深めることができる。
    • 「自分の考えを自分なりに深めるための行為」なので、「間違えたら恥ずかしい」という感覚は一切捨てて初心者こそやった方が良い
    • どちらが正しいとか間違っているとか、意見に賛同する・しないではなく、「相手のことを理解して認める力」をつけるため行為である
    • 意見のが食い違っても「自分の理解を助けてくれてありがとう」といった空気が大切
  • 意見の対立があっても批判しない
    • 「相手を否定しない」「相手のアイデアを否定しない」そして、「自分の考えとして意見を言う」ことが重要である。（切り出しは「自分の意見では〜」がポイント）
  • 感謝の気持ちを忘れず、楽しんだもの勝ち
  • ディスカッションに参加し、「会話力」を育てよう
    • 会話力は「気合い」と「慣れ」の要素が大きい
    • 会話を通じてお互いが知識をシェアして高め合うことで助け合い、楽しむことに集中する

第５章　生産性を高めるチームビルディング

• 「サーバントリーダーシップ」「自己組織チーム」へ移行する
  • 従来型の「コマンドアンドコントロール」というスタイルが一般的だったが、昨今は信頼を起点とした「サーバントリーダーシップ」が流行になっている。
    • 「コマンドアンドコントロール」とは、リーダーが部下に指示を出し、部下の状況を把握・確認し、管理していくスタイルのこと
  • サーバントリーダーシップとは
    • リーダーは ＜ビジョンとKPI＞ は示すが、実際にどのように動くかはチームが主体的に考えて意思決定していくマネジメント手法
    • 現場のメンバーがかなりの権限を与えられており、どう実行するかは各自で考えて実行する。
  • 自己組織チームとは
    • 自己組織チームの特徴
      1. 生産性が高い（自身のやりたい仕事をやれるため）
      2. チームの満足度が高い（「楽しんでるか」が非常に重要視されるため）
      3. より良いソリューションが選択されやすい（現場で技術を選択できるため）
• 「サーバントリーダーシップ」「自己組織チーム」のある会社とは
  • 「自分で自分の考えや人生に責任を持つのが大人」であることが前提
  • 開発者それぞれが責任を持って設計し、実装する。
    • マネージャーから渡されるタスクは基本的に開発者が使用を自分で明確にし、デザイン・実装する。
  • 「仕事を楽しんでいるか？」を確認する文化がある。
    • 「仕事は楽しむもの」とういカルチャーのもと、如何にメンバーが幸せに働けているかに関心を寄せてくれる
  • 「ボスの役割 = サポート」が前提となっている
    • 困って相談をすると色々とアドバイスをくれるが、細かく指示することはない
    • 開発者がどこかで詰まっていると、ブロックされているものを取り除いてくれる
    • また、中長期的なキャリアアップについても相談に乗ってくれる
  • 納期はなく、マネージャーも急かさない。
    • あるのはバックログと大きな予定のみである。
    • マネージャは一度仕事を任せたら、あとはもう信頼するしかないので急かさない。
    • みんな「自分」が一番大切で、自分の幸せを第一に考えているので、「自分以外のもの」になることは期待されていない。
  • チーム内の上下関係をなくす。
    • スキルや経験に関係なく、全員が同じ責任を持っているフラットな「仲間」として振る舞うことがポイント
      • 仕事を依頼するときは基本「お願いモード」
    • 全ての仕事を「プル型」とする （困ったら主体的に気軽に助けを求めて、他の人がすぐ助ける）
  • 失敗に寛容な職場がチャレンジ精神を生む。
    • 自身能力を上回る領域へのチャレンジに必ず「失敗」はつきものであるという空気が次なるチャレンジを生む
  • 「Be Lazy」を推奨し、休暇を尊重する。
    • 多くのバリューを出すことに集中するからこそ、作業量を減らして、積極的に休暇を取る
  • チームにパワーを持たせることの価値
    • チーム自らが考えて意思決定し、判断していけば新しいチャレンジも増え、チームにパワーを持たせることができる
      • 自分の意思で決められず、指示されてやる仕事は面白くもなんともない
    • チームメンバーが「仕事を楽しめる」環境を作ることにより、できる人たちにのびのびとパフォーマンスを発揮してもらえるようになり、組織が活性化される
• いかに「サーバントリーダーシップ」「自己組織チーム」を導入するのか
  • 「自己組織チーム」を作るためには、ソフトウェアチームだけではく、会社全体に対して導入する必要がある。
    • マネジメント手法が「コマンドアンドコントロール型」であれば、それでもってチームを管理しようとしてしまうため
  • それぞれの階層に対して、以下のように導入を進める。

    • トップ層に対して

      導入により、リードタイムの短縮などどれだけの効果があるかなど「目にみえる効果」を提示する。

    • ミドル層に対して

      現場のマネージャーたちの不安を汲み取って、会社としての支援体制を作る。自己組織チームへの移行により、管理負担が減り、より本質的な仕事に注力できるようになるというメリットを十分に理解してもらう。

    • チームメンバーに対して

      ”指示待ち”の体質からの脱却が最優先。「ファシリテーター」役を儲けて、メンバーたちの行動を促す質問をし、「決定」はあくまでも本人にさせる。慣れないメンバーには「Ask For Help」の大切さを繰り返し伝え、「気軽に質問しても良いという雰囲気」を作る。

第６章　仕事と人生の質を高める生活習慣術

• 生産性を上げる働き方とは
  • 人の働き方は千差万別なので、本人にって一番生産的になれて家庭やライフスタイルに合わせて働き方を選択すると幸せになれる。（これは職場環境次第）
  • 生産性を上げるための秘訣は ”学習” であり、そのための時間を確保するためには仕事を定時で切り上げる。
    • 実働時間が減ったとしても、結果として生産性は上がる
    • 加えて、生活リズムを朝型にシフトすると朝の時間を学習時間に充てることもできるようになる。（結果として頭も冴えて生産性が上がる）
  • 定時で上がるためには「タイムボックス」制で仕事をする。
    • 残業をしないためのソリューションは、決めた時間になったら仮に途中でもきっちり終わるようにすること
• 「脳の酷使をやめる」をやめて効率的に休むためには
  • 以下の三つの工夫を実践することにより脳を十分に休ませる。
    1. 瞑想をする（マインドフルネス）
    2. ディスプレイから意図的に離れる
    3. しっかりと睡眠時間をとる
  • リフレッシュには違うことをすることが効果的。
• 「人生のコントロール感覚」を取り戻すには
  • 人生がコントロールできていない感覚から脱却するためには、まず幸せを感じることが重要。
    • 幸せを感じるから成功するのであって、成功したから幸せになるのではない
    • 「幸せが、人の成功の指標となる重大な結果に先行する」ことは研究者たちも断言しているらしい
  • まずは脳に負荷がかからず小さく幸せを感じる方法として、「掃除」をしてみると良い。
    • 小さくても「完了」した体験を重ねることにより、「人生のコントロール感覚 = 幸せ」を感じることができるようにある
    • 仕事も掃除同様、「整理され、検索せずにすぐに取り出せる状態になっていること = 完了」と捉えるようにすると、仕事のコントロール感が生まれる強力な足がかりとなる。
  • 仕事で成果を出すためには情報を「整理」をする
    • コンピュータの整理のポイントは主に以下の二つである
      1. 必要なものを如何に簡単に取り出せるか？
         • フォルダやドキュメントの場合、テーマごとに整理
         • 仕事でよく使うWebサイトやリポジトリ、チケット管理システムなどの場合、ワンクリックでアクセスできるように整理
         • よく使うクエリの場合、ダッシュボードにして整理（あるいは自動化）
         • 仕事のプロセスも整理
      2. 自分がどこに情報を置いたかを記憶する癖をつける
         • 検索するのではなく、一発で辿り着ける検索用キーワードを覚えておく
    • 良いプログラマになるための情報整理術
      • 新しいことを学んだらブログを書く
      • ブログを書くとき、サンプルコードをそのままではなく、少し変えて試してみる
    • 整理力を高めるためには、「身の回りの整理」→「情報の整理」→「頭の中の整理」という流れを意識する
      • 「身の回りの整理」として、まずはデスクトップを整理し、行動した時間を OneNote などで記録すると作業効率が改善できるかも
    • 整理力を鍛えることにより、理解力・観察力を同時に高め、結果的に時間を効率的に使えるようになる
      • 整理の仕方一つでタスクの進捗や優先順位への理解が高まることに加え、着手までの時間を削減できる
      • 物理的に「整理する」のは時間がかかるが、頭の中も整理され、「細かいこと」への目配りが利くようになる
    • 「完了」と「整理」はレバレッジが高い
      • 「完了」まで含めて「整理」するようにしたら、「仕事のコントロール感」を得られるようになるかも
  • 物理的なエネルギー（やる気）不足の解消するためには「運動」と「食事」が重要。
    • テストストロンの増強により、物理的なエネルギー（やる気）不足を補える
    • そのためには以下のやり方に絞ると良い
      • 低負荷で良いので、毎日30分有酸素運動を含む運動をする
      • ランニングしている場合、辛くなったらすぐ歩く
      • 毎日30分の運動を全てのことに対して最優先とする
    • テストステロンを意識的に増やす
      • 食事の面では、意識的に肉類や玉ねぎ、加熱されたニンニクなどテストステロンを増やすのに効果のあるものを食べると良い
      • 仕事中に軽くつまむものとしてはナッツ類がおすすめ（低GIなので）
      • 他にはサプリメントで補うという方法もある

第７章　AI時代をどう生きるか

• どんな職業ならAIに食われないか？
  • 少なくともしばらくは対人的なもの（想像的な仕事や芸術などの分野）は大丈夫
  • AIと「対立」するのではなく、「共闘」する（自身の強みのある分野のコンテキストでどうしたらAIとアラインできるかを見つけ出す）ことこそが生き残る道
  • よってソフトウェアエンジニアは少なくとも今後もインテグレーションの主役であり続ける
• 「専門性」こそが強みとなる。
  • 時流に惑わされず誰にもやったことのないものに取り組んでいる「専門性」を追求する姿勢こそ、AI時代における一番の強み
• 「批判」の文化が全てをぶち壊しにする。
  • 「どんなシステムにはバグがつきものであり、改善していく外ない」ということを前提にしないと、新しいことへのチャレンジ精神を奪ってしまう
  • 特に日本の「批判文化」（9個良いところがあっても、1個の悪いところをクローズアップして批判してしまう風土）はイノベーションを全て破壊してしまう
    • 「異常な完璧主義」、「先陣を切ってトライする人に対する嫉妬にも似た口さがない批判」、「冷笑」、「中傷」といった批判が全ての土台（チャレンジする文化）を根本から破壊してしまう
    • 「お客様は神様」（「人がこのぐらいやって当然」「専門家なら完璧な仕事をして当たり前」）という風土・土壌は、社会全体の生産性と活力を奪い、結局は自分の首を絞めることになる
  • 一方アメリカでは、自分がどういう貢献ができるのかという公共性をベースとした「コントリビュート」文化がある
  • ソフトウェアという分野でイノベーションを起こすためには、「批判」ではなく、失敗しても現場の心が砕かれない文化的素地が重要
• 日米エンジニアを取り巻く文化の違いから見る光景
  • アメリカの場合
    • 「専門性を高める」という蓄積に価値が置かれ、スピードはそこまで重視されない
    • 「アプリケーションはどんなに優秀なチームが開発しようが、必ず何かしらの不具合は存在する」ということが前提にある
    • アメリカでは ChatGPT の出現を歓迎し、ユースケースを絞り要所を押さえた上で積極的に利用している
      • 「破壊的なテクノロジー」を禁止するとなると、数年後に世界から取り残されてしまう
      • したがって、ただ漠然と怖がったり焦ったりして、「禁止」や「排除」をしてしまう方がよっぽど危険
      • それよりもAIテクノロジーを活用して楽をしたり、自分の開発サービスに統合して生かそうとエンジョイする姿勢が大切
  • 日本の場合
    • IT先進国になるために致命的な足枷になりかねない独特の「批判文化」である
      • 例えば、コロナ禍における政府主導のマイナンバーカード導入に対する日本のSNSで巻き起こった「批判」は、開発者たちの心を折ってしまう。
• 自分の人生は自分でコントロールする。
  • 日本と海外との一番大きな違いは、どうやったら自分の人生が幸せになれるかを主体的に考えて、仕事の仕方を「選択」していることである
    • 日本の場合、自分の人生が自分で決められないと思っている人があまりに多い
  • 自分の人生を自分でコントロールするためには、常に自分が幸せになれる方向に人生の選択をする決意をすることが第一歩
  • そのため、まずは「自分の人生や幸せに責任を持って、自分をコントロールする」というマインドセットを持とう
• 日本再生への道筋
  • 日本のソフトウェア産業は「実際に手を動す人」より「政治的な人」を重視したため、技術力が低くなり、イノベーションが生まれにくくなった。
    • 日本の技術力が諸外国と比べて低く、低迷している大きな理由は「自分でやらないから」に尽きる
    • 「プログラミング」を低レベルがやることと見做して外注し始めたことが、日本の大手SIer衰退の分岐点になってしまった
  • 日本を再生していく上での喫緊の課題は「政治的な人」から「実施手を動かす人」へシフトしていくこと
    • 革新的なイノベーションは「素人」が何人集まっても生まれない
    • 失敗しながらでも「世界の市場に挑戦」し、「自らの手で一流のソフトウェアを開発する力」を付けることが今後の鍵となる
    • また、その第一歩として技術軽視の風潮を改め、ソフトウェアの技術者を専門家として大切に扱い、彼らが働きやすい職場環境へと刷新していくことが何よりも重要である
  • コントリビュートと感謝のループが武器となる
    • 「今からどうやったらできるのか」「自分は何をしたら貢献できるだろう」という考え方が今後重要となる
      • まずは、SNSを鬱憤ばらしに使うのではなく、素敵なアプリを見つけたら、作ってくれた人に対する感謝を発信してみよう
    • 開発者に限らず、日本のあらゆる業界・業種において、批判ではなくポジティブフィードバックで現場の心が満たされるような好循環が生まれたら、間違いなく日本は生産性は抜本的に変わる

おわりに

初めて知った際はタイトルが仰々しくかったため、ちょっと怪しそうなイメージがありましたが、本書はエンジニア以外にとっても非常に有益な情報が詰まった本でした。
色々と試したいことは出てきましたが、まずは以下に4つに絞って実行しつつ、少しずつ手を広げていきたいと思います。

• 「タイムボックス制」で生産性高く仕事して定時で退社する
• 「何も知らなくても即座に実装できる」レベルの基本的なことを学習する時間を確保する
• 頭の中でのみ整理する習慣をつける
• ディスカッションを楽しむ（苦手意識が強いため）