[読書メモ]『世界一流エンジニアの思考法』
本書でのポイント
- 理解に時間をかける
- 手を先に動かさず、まず仮説を立ててアプローチを選定してから動く
- 「Be Lazy」というマインドセット
- いかにやることを減らして成果を大きくするか
- フィードバックを歓迎するムード
- 失敗しても感謝する
- 「怒る」という選択肢はなくし、フィードバックを促進するムードを積極的につくる
- 検討に時間をかけずさっさと「検証」の段階に進み、フィードバックを得るようにしよう。
- 不確実性を受け入れる
- バリューストリームマッピング
- 開発プロセスを見える化→改善ポイントを見つける→リードタイムの短縮を目指す
- 結果を出す < バリューを出す
- コードリーディングのコツは極力コードを読まないこと
- インターフェースと構造だけを理解する
- 1日4時間だけは自分だけの時間をつくる
- 書くことのすすめ
- ブログを書く ⇒ 人に説明できるようになる
- e.g. コーネルメソッドのノート
- 情報量を減らすコミュニケーションの仕方が重要
- 最初から全部説明しない
- 付加的な情報は聞かれたとき
- 準備は効く。その場の瞬発力はアメリカのほうが強い
- メモを取る習慣
- 「自分用、自分が見るため」ではなく「見る人がほしい情報はこれだろう」という形で整理する
- クイックコールを頻繁に使う
- ディスカッション
- 自分にとって理解しがたい相手の意見や振る舞いも尊重して、受け入れる。正しいか間違っているかのジャッジではなく、「異なる視点から自分の考えや知識を深めることができて、楽しいよね！」という感覚を育みたい。
- 意見が対立しても否定しない
- 「相手を否定しない」「相手のアイデアを否定しない」、そして「自分の考えとして意見を言う」という鉄則を守れば、互いのメンタルを傷つけることなく、議論を生産性の向上に直結させることができるだろう。
- サーバントリーダーシップ
- ビジョンとKPIは示すが実際どのように動くかはチームが主体的に考えて意思決定していく
- 生産性を上げる秘訣は「学習」
- 仕事を定時で切り上げ、その後で自分のやりたいトピックを勉強したり試したりする
- タイムボックス制で学習の時間を確保する
- 整理の技術
- 新しいことを学んだらブログに書く
- ブログに書くとき、サンプルコードそのままでなく少し変えて試してみる
考察
- 仮説を立ててから行動することは他の書籍でもよく言われているほど重要そう
- 仕事で自分が取るメモは意外と人の役に立ちそう。というより人が理解できる内容をメモでも起こせるようにできると理解力と説明力の2つが上がると思うので一石二鳥な印象を感じた
- 日本のエンジニアではありがちなのかもしれないが、批判的なフィードバック・議論はアメリカをはじめとする多様性を重んじる他国では通用しないことを改めて認識した
本書で得た知識から試してみたい行動
- 業務で Design Docs を導入してみる
- 自分の仕事上のメモをパブリックにする
- 「基礎的なことに時間をかけて理解する」を日常に取り入れてみる
- LeetCodeを毎日やる
- プログラミングの基礎をもう一通り学び直す
- 業務で取り扱っている言語の仕様を学習する
- アウトプットのないインプットを無くす習慣をつける
- タイムボックス制を取り入れてみる
- タスクの進捗度合いではなく時間で仕事を切り上げてダラダラと仕事しないようにする