本記事の要約
『世界一流のエンジニアの思考法』の個人的ポイントをまとめたもの。
自分にとっての備忘録を兼ねている。
はじめに
本書は現在Microsoftで勤務する著者による現地での経験に基づいて、世界基準のエンジニアに求められる点を詳述している。
また、Amazonでのランキングも上位に位置しており、読者のバックグラウンドを問わず、各方面から高い評価を得ている。
今回はそんな本書について、プログラミングを始めて間もない自分が印象に残った点を列挙する。
仮説思考の重要性
著者はプログラミングでエラーに遭遇した際、一度手を止めてログを観察し、トラブルの原因を突き止めるための「仮説」を考えることを勧める。
自分は真っ先に思い当たる可能性を片っ端から検証していくタイプだが、どうやらこれが本質的理解の妨げになっているらしい。
また著者は、手当たり次第に可能性を試すことは、逆に将来の時間のロスを増やすことにも繋がりかねないと指摘する。
本書が勧める正しいエラーに対するアプローチは以下の通りだ。
1. まず事実（データ）を一つ見つける
2. いくつかの仮説を立てる
3. その仮説を証明するための行動をとる
タスクを捨てる勇気
自分は何かとプロジェクトに取り掛かると、「最後までやらなきゃ…」と思うタイプだ。
しかし本書は、例えば5個のタスクがあったとしても、実行するのは最重要な1個のみに絞ることを勧める。
最重要な2割のタスクに80%の価値が含まれており、それさえ終えれば残りの8割のタスクはやらず、さっさと次に移る。
そして80%の価値を生む2割の新しいタスクに取り組む。
『いわゆる「2-8の法則」でも、20%の仕事が80%の価値を生むのだから、20%をしっかりやればよくて、100%全部やろうとすると工数もかさむし、時間が足りない。』
「Fail Fast」の原則
日本には「ググれカス」という言葉があるように、何かわからないことがあればまず自分で調べることを推奨する空気がある。
しかしインターナショナルチームでは早く失敗（Fail Fast）し、フィードバックをすぐに得ることが効率的だとみなされる。
「こんなことで聞いてもいいのかな？」という疑問こそ、エキスパートに尋ねれば、かなりショートカットできると筆者は説く。
『相談される側もわずかな手助けでプロジェクト全体がスムーズに進むので、結果的に自分の仕事も楽になるのだ。』
生産性を上げるための休息
本書は仕事の効率を上げるための方法論として、仕事の完了度合いを問わず、時間きっかりに切り上げることを勧める。
著者は仕事が未完了だと休まずに働くタイプだったが、『Time Off』という本をきっかけに思考が変化したという。
この本の要点について、本文では次のように述べられている。
- 水泳をするときに、息継ぎせずに泳ぐことはできない
- 発想のブレークスルーは、その仕事をしていないときに発生する
- 一日に一つのことに集中できるのは4時間。4時間過ぎて疲れたら、単に休むのではなく、違うことをするのが良い。
「Be Lazy」が推奨される文化
インターナショナルチームでは、「いかに作業量を減らしてインパクトのあるタスクに集中できるか」が仕事の焦点だ。
そのためたくさん仕事をするのでなく、楽に効率よく良い成果を出すことがメンバーのモチベーションだという。
また、休暇を尊重する空気も特筆すべきものがあり、たとえ仕事の途中で休暇を取ろうが誰も批判しない。
日本でみられる「仕事を終わらせてから…」といったプレッシャーは存在しないと筆者は語る。
インターナショナルチームには前提として、「仕事は楽しむもの」というカルチャーがある。
- できる人たちにのびのびとパフォーマンスを発揮してほしかったら、何よりもチームメンバーが「仕事を楽しめる」環境をつくることだ。
まとめ
本書はエンジニアの思考法やカルチャーについて、日本のチームとインターナショナルチームの比較を通じてその違いをまとめている。
初学者の自分にとっては、特にエラーとの向き合い方、理解に対する姿勢、タスクの優先順位に関する項が参考になった。
何か今後の学習やキャリアで迷ったことがあれば、いつでも戻って読み返したい。