MEGUMI SHIMABUKURO

「世界一流エンジニアの思考法」を読んだ。マイクロソフトで働いているエンジニアの方が書かれた本で、ソフトウェアエンジニアのメンタルモデルや働き方、思考法について書かれた本だ。

�����f�����������Ă��܂��I

https://amzn.asia

口コミでの評判が良さそうで気になって読み始めた。想像以上におもしろい内容で読み終わる頃にはメモだらけになってしまった。日本とアメリカ（マイクロソフト）のアジャイルに対するマインドセットの違いや優秀なソフトウェアエンジニアの考え方が知れるとても良い本だった。世界の一流と呼ばれるエンジニアの働き方やメンタルモデルについて知りたい人におすすめの一冊だ。

• （自分自身の）情報整理のため
• 本の内容を後から思い出しやすくするため

• 世界一流エンジニアの思考法 の本が気になってる人
• 世界一流エンジニアの思考法 をすでに読んで他の人の感想が気になる人

第１章　世界一流エンジニアは何が違うのだろう？―生産性の高さの秘密

第２章　アメリカで見つけたマインドセット―日本にいるときには気づかなかったこと

第３章　脳に余裕を生む情報整理・記憶術―ガチで才能のある同僚たちの極意

第４章　コミュニケーションの極意―伝え方・聞き方・ディスカッション

第５章　生産性を高めるチームビルディング―「サーバントリーダーシップ」「自己組織型チーム」へ

第６章　仕事と人生の質を高める生活習慣術―「タイムボックス」制から身体づくりまで

第７章　ＡＩ時代をどう生き残るか？―変化に即応する力と脱「批判文化」のすすめ

以下、本の感想。特に良かったところをピックアップした。

むやみやたらに手を動かして、その場限りの解決策で対応しても学びにはならない。しっかり考えて仮説をたて動いて理解することが重要。しっかり考えて解決したものは、次に似たようなことが起きたときに同じように解決できるし、応用が効く。個人的にすぐ手を動かしたくなる方なので、とても参考になった。実際にコードを手で書いてみたいないとわからないと思ってしまうことが多いので、プログラミングの基礎やLeetCode など、あらためて基礎力上げる時間を取りたい。

📝 理解の３要素とは

• その構造をつかんで、人に説明できること。
• いつでもどこでも即座に取り出して使えること。
• 知見を踏まえて応用がきくこと。

📝 実装前に簡単なデザインドキュメント（Design Doc）を書く

手を動かす前に簡単なドキュメント（Design Doc）にまとめて、手を動かし始めると自分の頭が整理されるのでおすすめ。考えてるときに書けば、自動的にドキュメントがが生成されるので後からまとめてドキュメントを書く必要がない。後から書くとなるととてもめんどくさいので、実装する前にドキュメントを書く習慣をつけたい。

章立ての例

• スコープ（Scope）
  • このデザインドキュメントの範囲を書く
• 背景（Background）
  • なぜこのプロボーザルを行っているかの背景を書く
• 問題（Problem Statement）
  • 解決したい問題を書く
• 提案（Proposal）
  • どういうデザインにするか、またその選択をした理由を書く

自分で調べて人に聞くという文化が効率が悪いと書かれてて、まあ人に聞いたら方が手っ取り早いよねと思った。一方で、個人的には、一度自分で調べて、わからないところを詳しそうな人に聞くっていうアプローチを取ることがく、ある程度前提知識があった方が話を聞く分にも効率良さそうと思ってる。ただ、何も調べずに聞くのが相手の時間を奪ってる感覚があって遠慮してる節もあるので、マインドセット変えて行っても良さそう。

アーキテクチャやライブラリなどの技術選定で、どちらにするか決めかねてる場合の意思決定は簡単で、選定としては、どちらを選んでも良くて趣味で選べばいいと書かれてて衝撃だった。決めかねてるということはどちらでも大差ないということなので、どちらでもいいという考え方。どちらかというと、どちらでも良いから早く決めて早く検証を始めることが重要。早く失敗してフィードバックを得て、素早く修正することのほうが価値がある。XP（エクストリームプログラミング）の原則にも似たような話があったので、確かになと思った。

コードを読むのが遅い理由は、コードを見たときにどんな挙動をするか想像できないことや構造を把握できないことが原因。これを解決するためには、まず何もググらずに実装できる範囲を広げていくと良いとのこと。コードを見たときにどんな挙動になるのか、ググらずに想像できると、脳への負荷が減り、コード読むのも早くなる。個人的にも僕自身コード読むのが遅いな思っていたので、とても参考になった。脳内で挙動を想像できると、すぐ手を動かさずにすみ、仮説を持ってアプローチを選定しやすくなることにも繋がるんだろうなと思った。

記憶力が悪い、例えば自分で書いた実装もしばらく経つとそらで説明できなくなるといったこと。僕もすごく思い当たることが多いので、耳が痛かった。この本では理解力が足りてないからだと説明していて、そうだよなーと思うので、人に説明できることが最低限の理解だということを意識してやっていこうと思った。

口頭だけで済ますコミュニケーションがすごく苦手でとても刺さった内容だった。コミュニケーションをとるとき、口頭だけのコミュニケーションだと、認識にずれがあったりするので、事前にアジェンダ準備したり、話終わってからテキストでまとめて認識あってますかというようなやり方をすることが多い。これ自体は、あとから見返したりできていいことだと思うけど、ディスカッションの瞬発力的な意味で、口頭だけのやりとりを上達させるのために、頭の中のみで整理する考え方は参考になった。

📝 頭のみで整理するトレーニング方法

• ミーティングの議事をその場で書かない。
• 人の話を聞くときは、他の人に説明することを想定して、聞きながら頭の中で整理する。
• 文章を書き出して考えるのではなく、頭の中で考えて、完全に整理し終えてから文章に書く。

初歩的なことだと、え、そんなこと聞く？という感じで、質問しずらかったりするが、例えば「Azureって何？」みたいな質問でも、知らないことを知らないと素直に気軽に質問したほうが、組織全体の効率が上がるとのこと。僕も初歩的なことすぎたら、質問しずらいと感じるので、気軽に質問できるようにする、を実践したい。質問しずらいのは、自分がそう思ってるからというのもありそうなので、自分のマインドセットを変えれるようにする。

事前知識がないと、間違えたら恥ずかしいと思ったりして参加しずらい感じがするが、知識がないからこそ知識がないことをオープンにし、フィードバックをもらうことで知識がつき、自分の意見をより深めることができる。知識ゼロでもディスカッションすることの意義はとてもあるとのこと。気軽に質問する話とも通ずるが、相手の時間を奪ってしまうとか、こんなこと聞いて恥ずかしいとか、そういう感覚とバランスをとっていきたい。

個人的にこの本で一番印象的な言葉で「agree disagree」という言葉がある。意見が対立して納得できないことがあった場合、相手の気持ちに立って、その意見に対して納得できるように頑張りがちだけど、相手のことを理解して認めることができれば、相手の意見自体には納得しないという選択肢もありなんだなと思ったりした。

基本的にリーダーはビジョンとKPI だけを示して、何をするかはチームの各メンバーの責務。指示ばっかりだと、誰かの指示がないと動けない集団になってしまう。ビジョンとKPIだけを提示されて、あとは自由に開発するスタイルで開発したことがないが、そうでなくても指示がないと動けなくなる、ということはない気がした。実際どんな感じになるのでやってみたい。

マイクロソフトで働くエンジニアのマインドセット、メンタルモデルを知れるとてもいい本だった。