世界一流エンジニアの思考法

1章メモ

最小限の情報で仮説を立てる

試行錯誤は悪

理解の３構造

• その構造をつかんで人に説明できること
• いつでもどこでも即座に取り出して使えること
• 知見を踏まえて応用が効くこと

自分でログなどを検証して問題解決をするようにしないと「思い込み」の穴に落ちる。

デザインドキュメント（Design Doc）を書く

ひとつのことで2時間以上ブロックされたら他の仕事を進めていったほうが生産性が高い

2章メモ

会議の場だけで完結する。
→ざっくりしたアジェンダはあるが、準備に時間をかけて会議にのぞむことは一切しない

「楽に達成できる」計画で仕事をする
→火急の依頼は「マネジメント能力の欠如」とみなされる

「無理・断る」練習をする
→「無理を承知で」のお願いの連鎖はみんなの疲弊を生み、チームや組織の業務改善に全く繋がらない

現実を見てフィードバックを受けて納期や仕様が変わっていくのはむしろ「善」

3章メモ☆☆☆

コードリーディングのコツは極力読まないこと
読むことを減らして、脳に余裕を生む
人が自分にとって難しすぎると感じるケース

1. 基礎的な学力が足りていないもの
2. 自分が無理なやり方をしているケース。

仕事難易度別の図がわかりやすい
いかにしてレベル2 → レベル1にしていくか
＝生産性とはいかに「レベル1」を増やすか？

プログラマの場合は、細かい技術の積み重ねが勝負であって「アウトカム」が勝負ではない
アウトカムに集中すると一時的にはよくても、中長期の「生産性」は上がらない
コピペすればすぐに成果はでるが、中身を理解していないからコントロールできている感はないし、応用が利かない
技術は地味な積み重ねにこそ真価が宿る。
→技術を徹底的に理解し、理解した情報の整理をして、すぐに取り出せるレベル1の状態にしてこそ、長い目で見た際の生産性は上がる

必ず問題をその場でかいけつする、「WIP=1」→「今手をつけている仕事を１つに限定する」
会議で自分に関係ない話が続くところでも、一切他の作業をやらず、チャット返信すらしない
→その場で問題のあたりをつけたり、あたりがつかない場合もとにかく「何かを進めようとする」
１つのことをやっているときは、他のことは一切せず集中する。

「マルチタスク」はしないほうが絶対に脳の生産性が高まる

☆毎日4時間をブロックして、チャットやメールなどを一切閉じて、自分の作業だけをする
→別にレスを早くする必要はない
時間のアサインメントを工夫するのが大切

「書く」すすめ
ブログ書くことはやはり大切。
「コーネルメソッド」
＝「ノート・キュー・サマリー」の形式で作業を記録し、その日のおわりに整理し、「作業内容を人にそらで説明できるかどうか」を記憶できたかのチェックポイントにする

記憶しやすくなる復習のタイミングを習慣化する

☆頭の中のみで整理する

• ミーティングの議事をその場で書かない
• 人の話を聞くときは、他の人に説明することを想定して、聞きながら頭の中で整理する
• 文章を書き出して考えるのではなく、頭の中で考えて、完全に整理し終えてから文章に書く

物事ができるようになるためには

• 理解
• 記憶
• 反復
  が大切

4章メモ

「情報量」を減らす。質問などでも少ないに越したことはない

「読んだ人がどう感じるか？」を意識しながらコードを書くことが大切
コードもまた「読み物」
クイックコールを頻繁に使うことも意外と効率が良い
→音声のほうがたしかに情報量多くてインタラクティブ性があってフィードバックはやい
自分にその分野の「メンタルモフ出る」や「コンテキスト」がなければ、すぐさまエキスパートに聞いたほうがよいという文化があるくらい
→相手が忙しいかどうかは考える必要は特にない。メッセージを送ってスルーされたら忙しそうと思うようにすればよい

気軽に聞ける空気の大切さ
→知らないことは簡単に隣の人に聞くらしい。全員が気軽に質問することを実践すると組織全体の効率が相当あがるのは確か
→この「気軽に聞ける仕組み」は「気軽に断れる空気」とセットになっている

ディスカッションは「どちらが正しいか」はどうでもよく、「自分の考えを自分なりに深めるための行為」なので初心者こそやった方が良い

自分にとって理解しがたい相手の意見や振る舞いも尊重して、受け入れる
正しいか間違っているかのジャッジではなく、「異なる視点から自分の考えや知識を深めることができて楽しいよね！」という感覚を育むことが大切