書評：「世界一流エンジニアの思考法」 主にソフトウェアエンジニア向けだが良書！
お久しぶりです。年末、今年一番じゃないか？という良書にであったのでご紹介です。
著者のかたはMSエヴァンジェリストとして成功しながら、MSのazure開発チーム（多分）にソフトウェアエンジニアとして参加します。周囲の同僚がおしなべてハイパフォーマーという不思議な環境の中で、どうやったら生き残れるようにパフォーマンスを上げられるかを試行錯誤した、その上澄みの経験を分析して共有してくれています。
全体的な感想
著者のかたの苦しい経験に基づく上澄みの話なので、基本的にソフトウェアエンジニアリング業務についてのお話になります。
周囲のエンジニア仲間が全員ハイパフォーマー（エースに頼り切るチームでない）という状況で、なぜ再現性のある形で圧倒的な生産性をあげられるのか、マインドセットの持ち方、チームメンバー内のコミュニケーション、生活習慣などについての経験と要点を説明してくれます。
日本と違って、ソフトウェアエンジニアから自然とマネージャーへあがるキャリアラダーはないので、マネージャーは完全に別職種です。また、ソフトウェア開発業務の以外の職種にはそのまま汎化できない部分もありますし、自分一人では変えられない職場環境あるいは文化に立脚する部分（どうしようもないね）もありますが、個人としては実感をもってうなずける内容が多かったです。
生産性のはなし
個人的に一番のtake home messageはここでした。個人的結論は「基礎・基本・王道を徹底して突き詰めることが高い生産性につながる」と捉えました。いくつかエピソードを書いておくと
2-8の法則、つまり一番価値のある２０％の稼働業務が、８０％の価値を持つという話があるが、ドリームチームの同僚たちはひたすらこの２０％の業務だけをやっている。
- ここに優先順位の付け方の違いがあると考えている。優先順位の高いタスクからやっつけましょう、というのは日本でも当然のように言われますが、そこでは上から順番にすべてのタスクに優先順位をつけて、できるだけたくさん上位のタスクをやっつけようとします
- 著者の同僚たちはそうではなく、一番重要なタスクだけにフォーカスします（重要20%)。それが終わったら、残りの優先タスクを埋めるのではなく、別タスク・再評価後の一番重要なタスク（２０％）を見定めて、そちらに移ります。完成させようとしない。
- 結果として、４０％の稼働で１６０％の価値を生み出せる。理論的には。
自分の場合、優先順位をつけて上からやっていく、というのは実践しているところではありますが、いつもタスクがあふれてやりきれないことが日常化してしまっていました。
また積み残しタスクは翌日に基本的に持ち越しするのですが、そこが思考停止していたことにも気づかされました。
2-8の法則はもうあらゆる本で述べられていて、自分も知識としては知っていますが、本当のハイパフォーマーがそれをどう行動に適用しているかの実例はショックが大きかったです。
もっとフォーカスして、「いちばん」だけに集中するようにしていかないといけないですね（でもタスクリストを減らすのは怖さがある、自然です）
手を動かす前に考える。考えるとは、仮説を立てること。仮説検証のために手を動かす。精度の良い仮説を高速に生成するための基礎の勉強がキモ
- バグ取りのエピソード。著者はログメッセージをみて、「あそこが悪いかな」「ここかな」と思いつくところから検証していきますが、検証の作業それぞれにも時間がかかる。一方エースの同僚は、ログを見てから原因の仮説をたてて、「この仮説が正しいならここはこう動いてこうなっているはずで・・・」という考察を続けます。いくつか仮説を検討後、チェックのためのクエリをひとつだけ投げて、見事に原因をみつけます
- また、同僚たちは著者なら見飛ばしてしまうような長いログも丹念によむし、コードも隅から隅まですっかり理解しています。そのため、立てる仮説の精度が高く、また高速で仮説の構築と検証ができます。これはさらに生産性をたかめるポイントになっています。
- これらのenablerは、誰でも通り一遍はしっているような基礎を徹底的に習得するコストを払って「理解」すること、です。だれもがハイパフォーマーということは、彼らすべての脳みその理解力が常人離れしている、ということではないことがポイントです。
手を動かす前に考えよう、というのは、これもやはりあらゆることで言われます。が、バグをみつけると「あれかな」「これかな」となって時間ばっかりかかっているのが実情ですね・・・。
あれかな、これかなは仮説のタネになるはずで、あれかなこれかなの修正ソースを書く前に、「あれが間違ってるとすると、コードの他の部分ではこうなっているはずで・・・」という次のステップを考える癖をつけることが大事かな、と思いました。それがlogから検証できるのであれば良い、と。そして、その仮説を複数束ねて、一番キモとなりそうな部分から検証する。
また、ここの仮説の部分の精度を高めるための基礎の勉強も大事ですね。ただ、拾得すべき「基礎」をどう定義するか。プログラミングの１００本ノック、みたいなのは分かりやすいですが、たとえば研究職ではどうか（プログラミングが時間かかるのはその通りなので、１００本ノックも有効ではある）、マネージャー職ではどうか、となると、日々鍛えるべき基礎とは・・・？となってしまいます。
その他
スクラムベースのアジャイル開発環境ではそれぞれがオーナーシップをもって働く、fail fastで素早く修正していく、失敗したことを責めずに歓迎してそこから最大限学ぶカルチャーなどは、今の職場環境をさらに突き詰めた型を実践していて、いいなあと思います。
コードのまえにドキュメンテーション、というのも、研究の前にまず論文下書き、というイシュードリブン手法として知ってはいますが、やっぱり実践できてないですね。。。（だから研究者として３流に終わっている）
いきなり全部はできないし、今までトライしてできなかったことをまた同じやり方をしても出来ないままなので、まずは2-8の法則の部分だけでも取り込みたいと思います。
