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

• 仮説を立てて検証する （ 試行錯誤はダメ )
• 理解に時間をかける
• ドキュメントはコードを書く前に

どんな人も最初は難しく、理解には時間がかかるというのが真実。
「時間をかけて理解 → できるようになる」を積み重ねることで「自分ならやれる」というマインドセットが作られる。

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

• Be Lazy 「少ない時間で価値を最大化する」
• リスクや間違いを快く受け入れる
  失敗した時は、原因と次に同じことが起きた時の解決策を考える。
  失敗に対して反省や批判は、次のチャレンジの恐れを増幅させ、生産性を下げる
• 納期は柔軟に
• 仕事を断る

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

• 成果に囚われすぎない
  動けばいい・実装できればいいという考え方では、潜在的なバグを発生させ、成長も少ない。
  中長期的に見て生産性が落ちる。
• マルチタスクは最低
  1 日の中でタスクに集中する時間を作るのはいいかも。その時間帯は、メールや他のタスクなどの仕事は一切入れないようにする
• 理解・記憶・反復

頭の中で整理して記憶する

• ミーティングの議事はその場で取らない
• 後で人に説明することを想定しながら聞く
• 考えを整理してから書く

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

• 情報量を減らす
  多くの情報を与えても聞いている側が消化できない。伝えたい最小限を伝えて、付加的な要素は聞かれた時に答える。
• 理解してもらうことに時間をかける
• 相手が求めている情報への感度を研ぎ澄ませる
  要望・タスク・質問に答える時に相手の欲しい情報を理解するのに多くの時間がかかる。
  普段からメモを人に見せられる形式で残しておくとそれをシェアするだけで大幅な時間削減になる。
• コードは読み物
  コードにはコンテキストの情報がない。コンテキストがあって初めてコードの評価ができる。
  コードをレビューする人・未来の開発者がコンテキストを理解し、コードを評価できるようにコードを書く。
• ディスカッションは理解するための場
  理解を重ねるまで会話をし続ける

気軽に聞けると気軽に断れるはセット

「間違えたら恥ずかしい」という感覚は捨てる
知ったかぶりはカッコ悪いし、後からこっそり調べるのは生産性が低い。
意見の違いを是非でジャッジするのではなく、ベストに導くため異なる視点からの考え方や知識として受け入れる。

建設的なディスカッションをするため

• 相手を否定しない
• 相手のアイデアを否定しない
• 自分の考えとして意見を言う
  「自分の意見では、〜〜〜」
  これができなければディスカッションが是非を判断する論破勝負になってしまう。

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

サーバントリーダーシップ

メンバー主体で動き、マネージャはメンバーの障害を取り除く役割。

• スピード感
  実装者が判断し、そのまま実装するので圧倒的に早い
• メンバーのやりがいと成長
• ベストプラクティスが選択されやすい
  実装者がベストプラクティスを選ぶ上での判断材料を 1 番知っている

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

• 仕事は定時上がりで、それ以降は自分のやりたいトピックを勉強
• 時間管理にはタイムボックスを使う
  「完了」に焦点を当ててしまうとズルズルと長引いてしまうことが多々ある

脳への負担を減らす

• 瞑想
• ディスプレイから意識的に離れる
• 睡眠をしっかりとる
• いつもと違うことをする

整理すること

身の回りの整理 → 情報の整理 → 頭の中の整理

エネルギー不足

• 運動する
• テストステロンを増やす

7 章 AI 時代をどう生きるか？

AI に食われないためには？

専門性をもつこと
世界の誰も知らない・知見がない技術は AI も答えることができない

「批判」はチャレンジ精神をなくす

「批判」は開発者のモチベーションを砕き、生産性と活力を奪う。
そんな環境では優秀な開発者は集まらない。

IT の世界は、歴史が浅く、成熟もしていない。
そんな中でのソフトウェア開発で計画も予見も正確に立てることは不可能に近く、「失敗」は必ず起こる。その「失敗」から学べる環境があるかどうかエンジニアの生産性が大きく変わる。