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

 全体像
 目的本書では世界一流エンジニアの思考法やどのように仕事を進めているかについて学べる本です。まとめると、最小の努力で最大の生産性を生み出すための方法を教えてくれます。そのため仕事に限らずプライベートでも役に立つ考え方を学べ、自分がより効率的に成長できるでしょう。
 1. 多くの知識を理解している状態より効率的に生産性を上げるために、より多くの知識を理解していることが必要です。そもそも理解しているというのは、
構造を掴んで、人に説明できること
いつでもどこでも即座に取り出して使えること
知見を踏まえて応用が効くこと
ということ。それには Google などでわざわざ調べたりしたりせず記憶からすぐに取り出すことができ、他の人に説明できる状態である必要があります。
 メンタルモデルを構築するメンタルモデルとは、人々が世界を理解し、予測し、解釈し、新しい状況に適用するための、自己の中のイメージや理論のこと。頭の中で素早く情報処理するために、何らかの脳内イメージ、思考フレームワークを持っていることが有用。

例えば、MVP はソフトウェアの世界でどんなに最良のものを作っても世に送り出してからフィードバックを受け取り改良を重ねる必要がある。そのため製品を作り込まずに実用最小限のレベルに抑えた試作品にしておくべきという考え方をだ。
 アウトプットする ドキュメント駆動開発ドキュメントを書いてから開発をすることには以下の 4 つのメリットがある。
思考整理になる
記憶に定着する
抜け落ちを拾える
あとからドキュメントを書く必要がない
 コーネルメソッドノート1 日の仕事・勉強終わりにコーネルメソッド式のノートを取ることでより頭が体型的に整理され記憶に定着される。
その日に学んだことをまとめる
学んだことにつながる質問を書く
後日に要約する
 ブログを書く本を読んだり、仕事中に新しいことを学んだら、ブログを書くようにする。
 頭の中で整理してからアウトプットする人に説明する時や話を聞いて理解する時、情報を頭のメモリに乗せ処理する必要がある。日頃からすぐに紙に書き出して整理していると、会話中に脳内で処理し切って説明や理解することが難しい。そのため普段からできる限り頭の中で整理してからアウトプットする癖をつける。
 理解に時間をかける何かに取り組んでいると新しく学ぶことやわからないことが出てくる。ほとんどの人がわかった気になって深く理解せず進んだり、そもそも何とかなると思ってわからないことわからないままにしがち。一つずつわからないことを無くして基礎を作っていく必要がある。
 2. やる量を減らすいかに効率的にタスクをこなそうと効果が低いことばかりに取り組んでいては何も生まれない。そのため「Be Lazy（最小工数で最大のインパクトを狙う）」考え方が重要である。
 重要なものだけを一つだけピックアップしてフォーカスするタスク管理については、よくある方法として「バックログに優先度をつけて、どうしてもできないのは無理だから実施しないようしよう。でも時間がゆるせば全部実施したい」と考える。

しかし、沢山の事を同時にやっても生産性は上がらない。最もインパクトのある一つを確実にすることが大切。
 納期絶対主義を捨てる納期以内に終わらせることが成功だと思っている。もし納期ギリギリの場合、品質を落としてでも納期に間に合わせることを優先する。これは長期的に見ると何も生産的でない。品質、量、時間、コストはトレードオフ。量と品質を担保したいのであれば、時間を 3 割ほどバッファを見積もって計画する。もし納期ギリギリになった場合は、量を減らすことも大事。
 MTG の前準備や議事録を取らないMTG の前準備に時間が取られ過ぎている。普段からドキュメントやメモをとっていれば特別に用意する必要がない。

また、MTG 中に議事録を取ると相手の話していることを十分に理解しきれない。相手の話に集中し「あとで人に説明する」ことを意識して、頭の中でビジュアルイメージの構築やメンタルモデルを視覚化することで頭のメモリも増え、理解が深くなる。議事録をあとで想起して書き起こすことで記憶力が定着する。
 ディスカッション中は積極的に質問ディスカッションの場面は意見の交換だけではない、わからないことを聞いて知識や考えを深める場でもある。あとで効くのは効率が悪い。

また、聞かれた相手は説明することで理解さらに深まり、周りは勉強にもなるためチーム全体で有用である。
 エキスパートを頼るわからないことを一人で調べ切るには時間がものすごくかかるし、得られる知識には限界がある。すでにメンタルモデルを構築しているエキスパートに聞くのが生産性を上げる。

しかし、相手に手間を取らせず、すぐに答えられる質問でなければならない。手間を要する可能性がある場合は事前に調査や準備をする必要がある。
 クイックコールわからないことがあった場合にチャットだと文章を考える手間や即座にレスポンスをもらえないケースがあったりと、相互に負担が大きい。Zoom やハドルなど直接話すことで柔軟性高くかつ効率的に情報を交換することができる。

また、聞かれる方にも学びがあることがある。自分の知らない情報や調べるきっかけにもなる。
 分析ファーストエラーや問題が発生した時にあれやこれやと仮説を立ててトライアンドエラーで解決を試みようとしがち。試してから結果が得られるまで多くの時間を要する。計測、可視化など分析してから仮説を立てて検証する方が早く効率が良い。
 3. 集中力・記憶力 UPやること(What)を絞り一つに集中し、どのようにやるか(How)もわかったところでその効率、集中力・記憶力を上げる必要がある。
 マルチタスクをしない質問が来たり、何を頼まれ、タスクが割り込みマルチタスク状態になりがち。4 時間集中する時間をまとめて確保する。他の時間で質問に答えたり、メッセージを返したりする。
 脳を休ませる長時間をディスプレイを見たり、色々な物事を考え過ぎているため、脳が疲れている状態。体もずっと酷使していては最前のパフォーマンスを発揮できない。脳も適度に休ませる必要がある。
 タイムボックス制にする仕事など何事もキリがいいところまでやろうとし、長時間労働など脳を休ませる時間が少なくなっている。時間で強制的に区切ることで集中力と、脳を休ませる時間を確保する。
 瞑想をする何も考えない時間、ぼーっとする時間、自分の呼吸に意識を向ける時間が大切。携帯や SNS など普段から多くの情報に晒されすぎている。
 4. 相談し合えるチーム環境の構築ここからはチーム全体の生産性を上げるための方法。気軽にわからないことを聞けたり、聞かれたりする環境でなければ生産性は低いまま。
 agree to disagree相手と意見が食い違っても、相手の意見を尊重しなければ建設的な議論は行えないし、心理的安全性も下がり、意見を言いづらくなったりして情報が閉じてしまう。育った環境や文化が違うので意見が合わないことがあるのは当たり前。自分の意見を伝えるときは否定案を表さず「自分の意見では〜 (In my opinion)」などと自分の意見を伝える。相手から意見をもらったら「ありがとうございます」などと感謝を伝える。
 細かくあてる相手と認識が違うまま物事を進めていくと手戻りや不要な混乱、やり取りが増える。そのため、内容や方針が変わったりして、相手と認識が揃っていないなと思った段階ですぐに相談したり、話すようにする。

例えば、何か初期設計に問題があり実装方針を変えた場合、相手に共有しなかったら最終的に聞かれることにもなるし、他の良い案があった場合に手戻りが発生する。
 4. 情報が相手がすぐに伝わる環境の構築 普段のメモから相手に見せる意識問い合わせや相手から質問が来た際に、普段からメモを相手に渡せるような形でとっていれば余計な時間を要さずに対応することができる。

また、人に説明する・理解してもらえるように考える意識は、理解を深め記憶にも定着しやすくなる。
 プログラムコードは読み物コードは人が読むものであるため、理解しづらいコードは Pull Request に質問コメントがついたり、無駄なやり取りが発生する。コーディングするときは相手が理解しやすいように実装するべき。コードは読み物。
 5. 高速に PDCA を回すソフトウェアの世界は変更が容易であるため、最初からきっちり最良なものを作り上げようとせずに、早く世に出しフィードバックをもらい改善をする。このサイクルを高速に回し早く成功に辿り着くのがベターである。
 失敗を受け入れるどんなに長く検討しても人は間違える。そのため失敗を恐れず、また他の人が失敗しても責めたり、批判したりせずチャレンジしたことを褒める。失敗から学べる機会とポジティブにとらえる姿勢がチームとしても大事。
 不確実性を受け入れるどんなに考え込んでも計画はあくまで計画であるため崩れ得る。納期に間に合わなくても失敗とらえず、要件を減らしたり、納期を伸ばすことを考える。