けけずん積読消化記録

本書が発売されたときからX（旧Twitter）などでよく拡散されているのが目についた。タイトルから若干の胡散臭さを感じるものの、気になったので読んでみた。
本書は米マイクロソフト社のAzure Functionsチームに所属する牛尾剛さんが、一流のチームの中で、三流として一流に近づくための取り組みや、思考方法について記載されている。

著者は「できない感」から脱却するために模索し続けてきたが、「できる」感覚を得られなかった。そんな中で、周りの一流エンジニア達に相談したりペアプロをしたりすることにより、自分と彼らの「思考の習慣」の違いに気づくことができた。本章は一流エンジニアの「思考の習慣」について記載されている。

• 事実を見つける → 仮説を立てる → 仮説証明のための行動をとる
  • 思いつきによる試行錯誤は時間がかかり、学びがない
• どんなに頭がいい人でも理解には時間がかかる
  • 「早くできるように頑張る」ことはむしろ生産性を下げる
• 学習における理解の3要素
  • 構造をつかみ、人に説明できること
  • いつでも即座にとりだして使えること
  • 知見を踏まえて応用が効くこと
• コードの意図とその背後のアーキテクチャを理解する
  • 雰囲気で分かった気になり読み飛ばさず、時間をかけて検証し、理解を深める
  • 理解には時間がかかるものとし、急がずに徹底的に理解する習慣をつけること
• コードを書く前に小さなドキュメントを書く
  • 2つの利点
    • 自分の頭が整理され、抜け落ちいていた視点に気づける
    • 考えてるときに書くことで自動的にドキュメントになり、シェア可能になる
  • 「デザインドキュメント」の例（物理本P.42）
• メンタルモデルをつくる
  • 人々が世界を理解し、予測し、解釈し、新しい状況に適用するための、自己の心の中のイメージや理論のこと
  • 固定の型があるわけではなく、人それぞれ

著者の気持ちに共感できる話が多かった。エンジニアとして技術に自信がない、「できない感」から脱却するために頑張るが、空回りをする。空回りすることで自信がなくなり、また頑張ろうとするが再び空回りをし、という悪循環。

また、一流エンジニアは短時間で全てのものを理解することができ、息をするようにコードを読み書きできる、といった勝手な印象があった。本章を読んで、頭のいい人でも理解には時間をかけているのだな、という発見があった。

本章では、一流エンジニアのマインドセットについて、具体的にどうすれば仕事に導入できるかが記載されている。

• 「Be Lazy」 より少ない時間で価値を最大化するという考え方
  • 結果を達成するために、最低限の努力をする
  • 不必要なものや付加価値のない仕事をなくす
• 「優先順位をつける」という言葉のイメージの違い
  • 日本人「列挙したやることに優先順位をつけ、順番よく実施、可能なら全部やる」
  • 海外「一番重要なやることを1つピックアップし、それ以外はやらない」
    • 2-8の法則
      • 20%の仕事が80%の価値を生む
      • 20%の仕事を終えて80%の価値を生んだ後は、再度80%の価値を生む20%の仕事に取り組む
• リスク、失敗を受け入れる
  • 「挑戦 → 失敗 → フィードバック → 修正」のサイクルが早いほど価値がある
• 失敗を受け入れる具体的な方法
  • フィードバックを歓迎する
  • 検討ではなく検証をする
  • 「早く失敗」できるように考える
• 心理学「鏡の法則」
  • 自分に適用しているルールを無意識に他人に適用してしまう
  • 人に寛容になりたかったら自分自身へのルールも緩やかにするほうがいい
• 「結果を出す」 ≠ 「バリューを出す」
  • 前者は失敗したらおしまい
  • 後者は結果はどうであれ、取り組みの中で得た学びのシェアこそがバリューとなる

これまでの仕事はクライアントワークがメインで、いかに短い時間の中で仕事を終えるかが重要だった。自社サービス開発がメインとなる今の職場では、タスクの量は多くはないものの、作業をしていて得られる学びは多い。そういった学びを周りに共有するという意識を常に持つようにしたい。

本章では、脳の負荷を減らすために一流エンジニアが意識していることや、著者が記憶をするために行った取り組みとその効果について記載されている。

• コードリーディングのコツは極力コードを読まないこと
  • 読めないのは自分の能力の低さではなく、脳の使い方の問題
  • 実装は見ず、インターフェースと構造を理解するようにする
• マルチタスクは生産性が最低である
  • マルチタスクにより生産性40%低下、完了までの時間が50%増加、ミスの発生が50%増加
• 人に説明可能な状態にもっていく訓練 → ブログを書くこと
  • 記憶するために有効な方法は、思い出そうと頑張ること
  • 「コーネルメソッド」（物理本P.121）
    • アウトプットを意識したノート
    • 学んだこと、それに対する質問を書くことで、復習をする際に思い出す練習になる
• 理解・記憶・反復という黄金則
  • 物事をできるようになる3つのファクター
  • 脳の負荷を減らす、という発想に基づいている

コードを全部読まないと理解できないと思い、読み進めるも全然読めなくて自分に落胆するということはよくあった。そしてその読み方をするとかなり疲れる。インターフェースと構造の理解から入るなど、脳に負荷をかけないようにしていきたい。

本章では、生産性を上げる伝え方や聞き方、ディスカッションの意義について記載されている。

• 人に伝えることを前提として、情報を残す
  • 実装の説明、便利なコマンドやクエリ、参考となるPRなど
  • 説明する時間を省けるため、シェアするだけで工数削減になる
• 音声の方が情報量があり、インタラクティブ性があり、フィードバックが速い
  • 自分にメンタルモデルやコンテキストがなければ、すぐにエキスパートに聞く
    • 相手が労力を要するかどうかは配慮する
• ディスカッションはいいぞ
  • お互いの意見を交換して、短い時間で知識と理解を深められる
  • 自分の考えを自分なりに深めるための行為
• 合意できないことに合意する
  • 意見に賛同する・しないではなく、相手のことを理解して認める力
  • シンパシーではなくエンパシー
• 相手の意見を尊重した上で自分の意見を伝える
  • In my opinion〜〜〜〜
• 会話力を育む
  • 気合と慣れ
  • 互いが知識をシェアして高め合うことを助け合い、エンジョイすることに集中する

ロジックを考えているときや問題が発生した際など、自分のための非公開なノートに記載しておくことが多い。同じことでハマる人がでてくる可能性のことを考えると、その人が見ても理解できるように情報を記載しておくのはよさそう。ただ、人に見せる前提で書いてしまうとキレイに書こうとして時間がかかる上に、納得できるものが書けなければ結局お蔵入りにしてしまうことがあるので、雑でもいいのである程度書いたら公開するようにしたい。

本章では、生産性を高めるためにチームやメンバーがどのような状態であることがよいか、会社としてどのような体制であるほうがよいか、その体制にするためにはどうすればよいか、といったことが記載されている。

• サーヴァントリーダーシップ
  • メンバーが主体的に動き、マネージャは彼らの障害を取り除く役割
  • いかにメンバーが幸せに働けるかに高い関心を寄せ、エンパワーする
  • サーヴァントリーダーシップ制は、優秀な人が揃っていない環境でも効果を発揮する
    • 新人でも、できるものとして扱えば周りの助けを借りつつきちんとやれる
    • スキルの習得も速く、実力以上のことは周りが助けてくれるという安心感から堂々と自信を持つことができる
• 自己組織チーム
  • 生産性、チームの満足度が高く、よりよいソリューションが選択されやすい
  • メンバーが楽しんでいることが重要視される
    • 面白さを感じて、主体的に考えてする仕事は生産性が高くなる
• 「仕事は楽しむもの」というカルチャー
  • 🇯🇵まさかりを投げ合い、七難八苦を乗り越えて圧倒的成長を目指す
  • 🇺🇸自他ともにハッピーでいるために生きている
• 困ったら気軽に助けを求め、他の人がすぐ助ける
• 失敗に寛容であれ
  • 自分の能力を上回ることに挑戦するからこそ失敗は起きる、これは当然のこと
  • 失敗しても、ポジティブな態度でいる方が周りの人たちは心地が良い
• 休暇は貴重で、尊重するもの

入社したての新人がコマンド&コントロール下で動いているのをしばらく見ていたが、基本的には指示を受けるだけで、成長することに関しても指示の範囲内でしか変化がないように見えた。当時は勉強をさせるという意味であれをやったほうがいい、これをやったほうがいいと伝えられていたが、おそらく本人からすると楽しくなかっただろう。後日、別プロジェクトではその新人に具体的に指示を出すのではなく、困ったらいつでも相談できるような体制にしてタスクを任せていた。そのときの新人の成長ぶりがすさまじく、気がつくと主体的に且つ楽しそうに動くようになっていた。

仕事を楽しめるようにする、というのは一見すると仕事を舐めているのかのように捉えられるかもしれないが（特にIT以外の業界だと）、実際はパフォーマンスを発揮するために最も大切なことなのかもしれない。

本章では、仕事のパフォーマンスを上げるための日々の生活習慣について記載されている。

• 身体が資本
  • 仕事に臨むマインドは身体から生まれる
  • 生活面を含めて心身をどう整えるかが、仕事のパフォーマンスに直結する
• 生産性を上げるためには学習だよ
  • 長時間労働はサステナブルではない
  • 仕事ばかりだと短期的なアウトプットはあるが、根本的な生産性は上がらない
• タイムボックスの導入
  • 学習する時間、PCを触らない時間、本を読む時間など確保する
  • 業務以外のプライベートな行動をスケジュールにし、区切りを遵守する
    • 完了することにこだわらず、その時間は集中するというのがコツ
• 瞑想はいいぞ
• 脳を休めるには、全く違うことをするのも効果的
  • 1日に1つのことに集中できるのは4時間、4時間過ぎて疲れたら違うことをする方がいい
  • 休み方を上手くすることで、生産性を上げることができる
• 幸せを感じるから成功するのであって、成功したら幸せになるわけではない
  • 人が幸福感を覚えているとき、ポジティブであるときに、頭もよく働き、やる気も生じ、結果的にものごとがうまくいく
• 何かをしたら必ず完了まで一息でやるよう意識する
  • さわりだけやってやりきらない場合、「あとでやろう」が溜まって気が散るので
• 筋トレと散歩はいいぞ
  • テストステロンを増やして活力を取り戻す
  • 負荷をかけるとしんどくなってやらなくなるので、心地よい感覚だけ残すようにする

デスクワークをしていると作業に夢中になってしまい、身体を動かさないことが多い。これが続くと筋肉がこわばり、積もりに積もって身体に不調をきたすことがある。定期的な運動が難しいという人は、作業中に細かい休憩時間を設けてストレッチなどをするのもオススメ。あとはデスクワークをする際の作業環境も大事。机と椅子は良いものを使って、首と腰を労わろう。

本章では、ChatGPTなどAIが台頭してきた中でどのように生き残るかや、日米でエンジニアを取り巻く文化の違いについて記載されている。

• 🇯🇵日本の悪しき「批判文化」
  • 有志によるコロナアプリ、短期間でリリースできたにもかかわらず、不具合をボロカス叩かれて心が折れる
    • 新しいことへ挑戦する精神を奪われる
  • 「どんなシステムでもバグはつきもので、改善していくしかない」ことは理解されるべき
• 🇺🇸アメリカはコントリビュートする文化
  • 人に期待せず、自分がどういう貢献ができるか、という公共性がベース
  • コントリビュートとフィードバック
    • 失敗からは批判ではなくフィードバックが生まれる
• 小さな貢献から始める
  • 素敵なアプリを見つけたら、つくってくれた人に対する感謝を発信する
• 自分の人生や幸せに責任をもって、自分でコントロールする

コントリビュートする文化で、まずは小さな貢献から始めるというのはとても良いと思った。なんらかのアプリを利用した際にたまにでてくるアプリに対するアンケート入力フォーム、面倒なので大体はスキップすることが多いが、小さな貢献を意識して回答するようにしたい。

つよつよエンジニアになるためには辛く苦しい修行に耐えなければならない、というわけではなかった。単に考え方や習慣の違いであって、それらを積み重ねた結果つよつよになれただけ。一日一日を大切に過ごすようにしよう。