はじめに

この記事は、僕が世界一流エンジニアの思考法（著：牛尾剛さん）を読んで、個人的に印象に残った考え方をまとめたものです。
世界一流エンジニアの思考法（Amazon）

本書は、牛尾さんが米Microsoftの一流エンジニアと一緒に働いて彼らの思考法が凝縮された一冊です。
技術的な難しい話も無く、新人から熟練エンジニアまで幅広くおすすめできると思います。

対象読者

これは少ない時間で最大限の価値を生み出す考え方が根本にあります。
ここでは、be lazyを達成するための習慣を一部抜粋します。

望んでいる結果を達成するために、最小限の努力をする

不必要なものや付加価値のない仕事（過剰準備含む）をなくす

優先順をつける

ここだけ見ると、当たり前のように感じます。
しかし、僕が感銘を受けたのは次のマインドです。

これは優先順位に関する内容ですが、本書では数あるタスクから重要なことを1つだけに集中する。それ以外はやらないという考え方です。

ありがちな優先順位をつけて、できるだけ全部やろうとはしない。ことです。

パレートの法則にもあるように、20%の仕事が80%の成果を支えているなら、20%の仕事をしっかりやればOK。
100%やろうとすると、工数・時間ともに足りなくなってしまいます。

僕は 「優先順位は着手する順番であって、基本全部やる」ものだと思い込んでいたので、この考え方は特に感銘を受けました。

「どれだけたくさんやるか」の足し算ではなく、「やることを削って重要なことだけフォーカスする」引き算の考え方ですね。

少し話がそれますが、マルチタスクは生産性が最低だからやらない と本書には書かれています。
これも、引き算の考え方が根幹にあると感じました。

日本では失敗にネガティブなイメージがありますが、アメリカではむしろポジティブに捉えているそうです。
これは、早めに失敗するフィードバックを得ることが重要視されているためです。

この考え方のメリットは、問題に対して柔軟な対応が取れることです
開発の終盤になってインパクトのある課題が見つかってしまうと、対策にかかる時間や労力も増加してしまいます。
開発初期段階で見つかれば、対処できる選択肢や時間もあるため余裕を持って対応ができます。

特に印象的だったエピソードは、牛尾さんがシステムの不具合を見つけて担当者へ報告すると、「フィードバックをありがとう」と感謝された話です。

バグに対して、そこまで寛容になれるのはすごいですね...。

特に難しいと感じたのが、フィードバックを歓迎するムードを作るところです。
他人や自分がミスをしたり失敗すると、つい責めがちになってしまいます。
批判ではなく感謝の心を持って、Fail Fast思考を育てていきたいと感じました。

アメリカでは、オリンピック等の特別なイベントを除いて納期という概念が存在しません。
（これもかなり衝撃でした）

これは、システム開発において不確実性はつきものという考え方に由来しているそうです。
システム開発には予測不能がつきものです。
開発初期段階で計画を立てても、途中でスケジュールを変更するなんて珍しいことではありません。

そのため、あえて納期を決めていないそうです。

それでも、ある程度のリリース時期は決まっています。
リリース時期に間に合わなかった場合は、その機能を削ってリリースするそうです。

このやり方にも、焦って検証もできずにリリースするより、自信を持った品質でリリースする考え方が根幹にあるようです。

個人的にはかなり羨ましいです...。
ちなみに、納期廃止をチーム単体で実施しても意味はない。と書かれていました。
会社単位で実施しないと、結局ほかのチームが提示した納期に縛られるためです。

複数会社の絡む下請け構造が主流の日本では、この考え方をはやらせるのはかなり骨が折れそうです...。

個人的には、読んで良かったと思える一冊です。
今までの固定観念を覆される感覚がありました。

記事では詳しく紹介できませんでしたが、アメリカでは、プログラマーがシステムの仕様・設計への意思決定を行うそうです。
これは、ものを作っている現場に裁量権を与えることで、変化に柔軟に対応できると感じました。

日本では、よくマネージャが一番偉い。と思われがちですが、アメリカではプログラマーは医者と同じくらいの地位があるとも言われているそうです。

詳細は、以下のおすすめ動画をご覧ください。
この動画を見て面白いと思った方は、是非本書を読んでみることをおすすめします。

ここまで読んでいただきありがとうございました！