「世界一流エンジニアの思考法」を読んだ

---

最初に最も大事な学び

「理解するとは何か」ということ
今まで僕が理解したと言っていた行為は多分「ただ知っただけ」という行為。
「理解する」の意味がまるっきり変わった。

---

世界一流エンジニアの思考法を読んで、
個人的に学んだ部分をまとめる。

仮説を立てて初めて手を動かす

• ログなどの事実から論理的に原因の仮設を立ててから手を動かす。
• 手当たり次第に試行錯誤すると時間がかかりすぎる。
• 感覚ではなく、事実を積み上げる。

[感想]
自分も実際に経験して同じような結論にたどり着いた。
自分の仮説をメモしてから、検証に入るようにしている。
そして、検証するために現象をしっかり理解していることが必要。
ただ、明確に事実を積み上げると考えられてはいなかった。

理解とは

理解とは

• 説明できること
• いつでも使えること
• 応用できること

どんな人でも理解は時間がかかるもので、時間がかかっていいもの。

[感想]
理解の解像度が一段低かった。
なんとなく自分の中で「わかった」と思ったものを「理解した」としていた。
でもそれは説明できるものではなかった。
個人的には「説明できること」は他二つを含んでいると思うから、
わかりやすく「説明できること」を理解したとしようと思う。

コードを書く前に簡単なドキュメントを書く

• 書くことで整理されて、抜け落ち等に気付ける
• 後で説明用のドキュメントを書かなくて済む

記載事項

• 目的
• 背景
• スコープ

[感想]
難しい部分はやっていたが、頭で思い描ける部分ではやっていなかった。
書くことで初めて抜け落ちがわかることがある。
実装してレビューが終わった後、リリースに際して説明が求められるときがある。
その時に説明用の簡単な資料があるとすごく楽だ。
一石二鳥

エキスパートに頼っていい

2時間以上時間がつぶされそうならすぐにエキスパートに聞いて、待ち時間で他のことをやった方がいい

[感想]
新卒でエンジニアを始めたときから意識してやっっているが、割と煙たがられる可能性もある。
私のどこかに他の原因があるかもしれないが、日本のおじさんエンジニアは自分にリターンがないとあまり協力しない傾向にある。
結局ひとりのエキスパートに負担が集まるという問題もありそう。

自分がエキスパートになったときにはできるだけ協力したいと思っている。

be lazy

最小限の努力で求める結果を出す

[感想]
「効率化」、「生産性の向上」と聞くと仕事感が出て嫌だが、
「怠けろ」というか「楽をしろ」と言われたら何だか取り組みやすい。

優先順位をつける

• 日本　　：やることすべてを洗い出して、それらのやる順番を決める
• アメリカ：優先順位が最も高いもの一つを取り組み、それ以外はいったん忘れる

[感想]
チームでたまったタスクの優先順位付けはいつも大変で時間がかかる。
何でかと言ったらすべてのタスクを精査していたから。
全部のタスクをやろうとしても無理な場合が多いし、
重要なタスクならそれを片付けただけで相当な成果が上がるはずだ。

ただ、タスクを忘れたり、思い出すのに時間がかかると大変だから、
すぐに思い出せるようなメモをする必要がある。

やることを減らすことに価値がある

[感想]
これは大きな学びだった。
「これはやらない、やらないに倒す」は日々やっているが、明確に価値があることと認識していなかった。
考えて見えればやることが減るってことは、何もしないのに完成に近づく。
精査して不要なら積極的にやることを減らすべき。

タスクドリブンではなく時間ドリブンで考える

「これだけタスクがあるから今日はここまでやらないといけない」ではなく、
「今日はあと4時間だからここまでできるな」と予定を立てる

[感想]
「今日は8時間、だいたい割込みが3時間あるから残り5時間。出来ることは何か？」
こんな感じで毎日タイムアタックするべき。
時間を区切ってタイムアタックするとすごく成長する。
そしてゲームと同じように楽しかったりする。

ただ毎日タイムアタックしていると疲れちゃうので最近は逃げていた。
気合いを入れなおさなきゃ

間違い、変更が生まれるかもしれない「不確実性」を許容する

• 失敗、変更前提で動く
• 早くに失敗する
• フィードバックをありがとうの気持ち

[感想]
全部自分に足りない部分。
そして日本のIT企業に足りない部分。
予定外は起こるもの。

まずうまくいく想定で計画を立てがち（新人の時より改善しているが・・・）
自分をよく見せたい気持ちが出ちゃう。
でもだいたい何かが起こるから計画より遅くなる。

早くに失敗するは最重要な学びの一つ。
早くに失敗すればそれだけ対応しやすい。
どうせ失敗するのだから、早く失敗できるように動くべき。
そして、早くに失敗するということは早くにフィードバックをもらえるということ。

フィードバックをありがとうの気持ちはあるつもりだけど、本場のアメリカ人に比べたら30%くらいだと思う。
フィードバック内容が的外れだと負の感情が湧くこともある。
フィードバックをしてもらえるようにしたいし、相手のためのフィードバックをしたい。

検討ばかりでさっさとやらないのは危険

• 検討よりも検証を

  • わからない未来の予測ではなく、検証してしまう

• どっちか迷うときは「どちらでもいい」

  • 迷うくらいの差は大した差ではない、好みで決めろ

[感想]
検証する前の仮説思考をしたうえで、
やらない限りは失敗できない。
早く失敗するためにも早く手を動かしたい。

変更は善

• 変更があるということはフィードバックがあったということ

[感想]
気持ちが楽になってすごくいい言葉。

失敗をシェアするのがチームのためになる

[感想]
余裕があるときはできていたが、継続が難しい。
自分発信ではなくそういう仕組みがあればいいなと思った。

生産性を高めるとは

• ググらなくても即できることを増やすことが生産性を高めるということ

[感想]
プログラムの勉強をするときに、文法を見るだけで書かないことがほとんどだったが、
それを実際に書くとき結局また調べてる。
それは生産性を高める学習とは言わないと思った。
手になじむまで使って、初めて習得した → 生産性があがる

自分の機能はコントロール感が生まれるくらい理解するべき

[感想]
「コントロール感」は本書でよく出てきたが、機能をすべて説明できる程理解するということだと思う。
自分の機能は自分の手足のようになじませて理解するべき。
そうしないと「不確実性」に対応できないし、結局苦労する。

マルチタスクをしない

• 一つのタスクに集中する、集中できる環境を作る
  • 他タスクのウィンドウ、アプリを閉じるなど

[感想]
マルチタスクをしないは意識していたが、環境づくりは明確に意識できていなかった。
1つのことに集中する環境を作る。

記憶力がないのは理解をしていないから

• 完璧に説明できるまで理解するべき
• 思い出すということが記憶の定着に重要である

[感想]
私は本当に記憶力がない。
特に短期記憶は終わってる。
でも考えてみると説明もそんなにうまくない。
こうなるとやはり理解していないということになってしまう。

前述したが、「説明できるほどの理解」に挑戦しようと思う。

自分用のメモは書かない

• メモはすべて共有できるように書く

[感想]
面白い考え方だったから、実践しようと思う。
自分用のメモを見返して、誰かへの説明資料を作るときが多い。
コピーもできるけど少し二度手間、そして、相手を少し待たせる。
だったらすべてのメモを誰かに見せるように書いてしまえばいい。
そうすればメモ渡すだけで説明の工数も減る。

知らないことは恥じゃない

[感想]
わかってはいるけど気にしちゃう。なんだか萎縮しちゃう。
でもマイクロソフトエンジニアが言ってくれると力になる。
知らない人にやさしくいたい。

技術的に詳しいのは担当者なのだから担当者に決めてもらった方がいい

[感想]
そうするべきだと思う。
でも決める準備ができていない、決めれるほど理解していない担当者も多い。
常に自分の機能がよくなる方向を考えておきたい。

新人でもできるものとして接して、タスクも渡す

スクショ撮るだけの簡単な作業を渡すのではなく、
信じてまとまったタスクを渡すと案外できたりする。

[感想]
自分が思ったよりもう一つ大きいスコープでタスクを預けてみようと思う。

結局はメンタルが仕事に影響する

幸せだといい仕事ができる
どんなことがあってもやる気をなくさせることをしてはいけない
チームが不利益を被るから
体の不調もメンタルに影響するから私生活の健康も重要

さいごに

本屋でなんとなく目について買った本だったが、学ぶことが多い本だった。

ただ、全体的にチームビルディングやコミュニケーションなど個人の範疇を超える内容は実践が難しいと思った。
マイクロソフトのやり方が正しかったとしても、
そのまま日本の企業に持ってきてもうまくいかない想像がついてしまう。
やっぱり組織全体で変わらないとメンバーの慣習を変えるのは難しい。

だから個人のスコープで取り込もうと思った部分だけ取り込もうと思った。
それこそチームや組織を変えるモチベがある人ならやれるのかな？