[TOP](https://www.notion.so/shinofara-1a690b35713b45bf8ea599bfa73fb7df?pvs=21) > [[Tags/読書|読書]] - ==index== 📗 購入した本 📖 読書感想文 🏷️ タグ 🗞 登場した用語まとめ ### 📗 購入した本 > [!info] 世界一流エンジニアの思考法 (文春e-book) > Amazon. > [https://www.amazon.co.jp/dp/B0CKSZV5DQ](https://www.amazon.co.jp/dp/B0CKSZV5DQ) ### 📖 読書感想文 インターネット上の声 [https://twitter.com/iwashi86/status/1716931692030734559](https://twitter.com/iwashi86/status/1716931692030734559) > [!info] 「世界一流エンジニアの思考法」は強いエンジニアの習慣がいい感じに言語化されていてよかった件 - Lean Baseball > 界隈で話題になっている（と私は認識している）「世界一流エンジニアの思考法」を早速読んでめちゃくちゃ良かった, とにかく人に勧めたいぞ！ という現役エンジニア（私）による書籍の感想エントリーとなります. > [https://shinyorke.hatenablog.com/entry/how-world-class-engineers-think](https://shinyorke.hatenablog.com/entry/how-world-class-engineers-think) WIPで殴り書きのメモ マイクロソフトでの話がベースとなっている。著者自身は「一流」ではないと自身を定義、またADHDなどもあり、長年の悩みが記憶力の低さだった。 だからこそ「どうやったら不得意なことでも効率よく人並みの事ができるのか」「仕事の生産性を上げる方法を」研究してきた。という話から始まる本 全員が常人と比べて著しく頭の回転が早いわけでも、天才的な記憶力を持つわけでもないが、圧倒的に仕事が早くプロダクトを更新しつづけている。それは「思考法（マインドセット）」が高い生産性を形作っている。 小手先のテクニックや、Tipsなどではなく、思考法によって圧倒的なパフォーマンスを生み出している 「グローバル企業のスピード感で技術導入を目指すビジネスパーソンや企業にこそ、生産性を加速するための西洋文化のマインドセットを学んでほしい」 ペアプロ中 著者は、ログで問題を見つけてから、ここかもあそこかもと試行錯誤するが、チームメンバーのエンジニアは「最初のログだけを見て仮説を立て始めた。その時点ではまだ手を動かしていない」 そのエンジニアは著者が書いているコードベースに関してほぼ知見が無く、著者の方が知っている状態だったにも関わらず。「障害を調査する時、いきなり手を動かして、試行錯誤していろいろクエリを投げかけてはだめなんだ。ログをみて、自分で多分こういう事がおこっていると推測して、その推測にあ > 「「障害を調査するとき、いきなり手を動かして、試行錯誤していろいろクエリを投げてはダメなんだ。ログを見て、自分で多分こういうことが起こっていると推測して、その推測に合ったクエリを投げてそれを証明するんだよ」」 > > —『世界一流エンジニアの思考法 (文春e-book)』牛尾 剛著 いきなり手を動かさない。まずは、事実（データ）を一つ見つける→いくつかの仮説を立てる→その仮説を証明するための行動をとる。 「単に思いつきでいろいろなパターンを試して正解を探しているだけなので、とても時間がかかる上、新しい知識を何も学んでいない。」 —『世界一流エンジニアの思考法 (文春e-book)』牛尾 剛著 [https://a.co/fRQgbE9](https://a.co/fRQgbE9) 「理解が十分でないまま手を動かして努力しても、空回りになるだけで身につかず、あやふやの試行錯誤は取り組んだことも忘れやすく頭に残らない。「何かを早くできるように急ぐ努力」がかえって本質的な理解を遠ざけてしまうのだ。」 —『世界一流エンジニアの思考法 (文春e-book)』牛尾 剛著 [https://a.co/aqoAPkD](https://a.co/aqoAPkD) コードを書く前にドキュメントを書く、Design Docなど。重厚じゃなくてよい。必要な要素があればよい。 ドキュメントを書くことで、自分の頭が整理される。抜け落ちていた視点に気づける。更に考えているときにドキュメントを書けば、あとで書く必要もなくなり、そのまま共有するだけですむ。あとから書くのはだるい １人で悩みすぎず、早い段階でエキスパートに聞く。同期的に聞けるのなら、そのまま聞けばすぐ解決できるかもしれない。もし同期的が難しくても非同期的に聞けば、待ってる間、他の事に脳を使うことができる。チームで解くことが出来るチームであれば難しくないはず。これはチームがそういう状態であることはもちろん重要だけど、個人としてのメンタルがそういう状態になることも大事 Be Lazyというマインドセット。「より少ない時間で価値を最大化するという考え方」 > v\ > > 「・望んでいる結果を達成するために、最低限の努力をする。・不必要なものや付加価値のない仕事（過剰準備含む）をなくす。・簡潔さを目指す。・優先順位をつける。・時間や費やした努力より、アウトプットと生産性に重点を置く。・長時間労働しないように推奨する。・会議は会議の時間内で効率的かつ生産的に価値を提供する。」 > > —『世界一流エンジニアの思考法 (文春e-book)』牛尾 剛著 > > [https://a.co/ek7z3Bw](https://a.co/ek7z3Bw) 40%ぐらいの機能しか使われない。コードが増えるとコードを読む量も増えるし、バグの発生確率も高くなる。「減らす事」事態に勝ちがあるというマインドで、やらないことを決めていく事が、結果として早く価値を最大化することにもつながるあ。 あれもこれも「すべき」というマインドだと必要な時間がどんどん増えていく。「時間は固定して、その中で価値を最大化する」というマインドセットが重要。MTGのときに「あれも、これも重要」とおもっても、全部ではなく、時間の中で価値を最大化することを考えると、この２つにフォーカスしようというマインドに切り替わる。 「準備」「持ち帰り」をせず「会議の場」だけで完結させる。ざっくりとしたアジェンダはある、議事録もその場で要点だけ書く、資料の修正が発生したらその場で修正する、会議にでるのであれば、全員が会議で完結させるという強い意志を持つ事が大事。じゃないと時間を浪費する。 生産性を加速させる上で、重要な第二のマインドセット「リスクや間違いを快く受け入れる」と上げている 成功しようがしまいが、まずはやってみて、早くフィード位バックを得て、早く間違いをしゅうせいしていくーFail Fast 不確実性のたかい現代では、検討ばかりして、さっさと「やらない」ことのほうが最大のリスク 失敗はただの結果。その結果を受けてどんなフィードバックを得たかが大事。失敗から学ぶこと 失敗に学ぶ思考の習慣は生産性を飛躍的に高めてくれる。 フィードバックを歓迎するムードを作る チームメイトが成功したら一緒に喜ぼう。もし失敗しても、フィードバックをしてくれたら、失敗する方法がわかったので、感謝しよう。失敗して「怒り」「批判」するのは、対等なはずのチームメイトを「子供扱い」しているのと同じ 成功事例や失敗事例を共有しよう。共有されたら新しい学びを感謝しよう。つまりは結果を感謝するとか、喜ぶ所は喜ぶとか。チームの雰囲気を良くなるアクションをみんながとるというムードが大切 検討より検証 検討しても意味はないので、検証してフィードバックを得よう。考えは自分の中、自分たちの中でのイメージでしか無く、検証することで初めて価値が生まれる。いい反応をもらうためにぐだぐだ検討するより、早く当て続けて一緒にUpdateしていくような検証が早く勝ちを高められる 早く失敗出来るように考える。 もちろん成功したい、うまくいきたい。だからこそ長く考えて大きく当てるとかではなく、早く失敗するにはを考えて行く事が大事。失敗しなければ成功するので、もし失敗してもそこから学べば本当の正解に早くたどり着ける。もし無意味だなと感じるのであれば早くやめることができる。その分未来の時間を別のことにつかえる バリューストリームマッピングで見える化する大事 ソフトウェアがリリースされる時点から遡って、どんなプロセスがあり、どれくらい時間と人がかかっているか見える化する。 それにより上長承認は作業として1minで終わってるけど、実は承認依頼を出してから見るまでのリードタイムに3,4時間あったりとかそういう無駄な時間に気づける 海外では下級の依頼は「マネジメント能力の欠如」とみなされる。’ 結果を出すより、バリューを出す。 KPIは提示で無理尾無く楽に達成できるものであるべき。という前提があるので、どうしようもない問題に直面したら、期間を伸ばすかアイデアを変更して、進め直す 第三章 脳に余裕を生む情報整理。記憶術 アウトカムを高めるためには、アウトカムだけに向き合うだけではなく、むしろ生産性、技術力といった個人の力を高めていくことが大切。 コードなどを理解するには、書く事や読むことだけではなく、人に話す。ブログに書くなど。整理して伝えるというアクションが重要。人間の記憶は「思い出そうと頑張る」ことで定着する。脳のメモリに蓄積されることで、あのコードどこだろとか、あの問題はこれだなとか、探すアクションを効率化する事ができる。もちろんツールの検索や、AIに任せることも今後の速さでは重要。 ただキーボードで聞く前に、脳内メモリで処理できるほうが速さは早いので、どちらも活用できるとよいよね 最初から全部説明せず、「情報量を減らす」コミュニケーションの仕方がすごく重要 エラーが出てる、バージョンはなに、こんなことをためしたとか付加情報をつけることは多い、海外では孵化情報は聞かれた時でいい。聞かれた時に今から調べますは、時間の無駄だけど、聞かれた時にすぐ答えれればそれでいい 情報の透明性観点でも全部みえると逆に負荷がたかまるので、整理されてるほうがいい。ただ深く知りたいときにしれるかが重要 日頃から人に伝えることを前提とした準備をしておくと、何かを聞かれた際の口数削減につなあgる リモートワークだからこそクイックコールが重要 相手の意見を尊重して、自分の意見を述べさせてもらうねてきなことをいう。たとえばコードが読みづらい時は、処理は理解できるけど、理解までにじかんかかっちゃったので、次にコード見る人が混乱するかも。など 言いたいことを伝える能力と、相手の言いたいことをただしくりきしようと度量苦する能力 コンピューターの整理のポイントは「必要なものをいかに簡単に取り出せるか？」に尽きる ### 🏷️ タグ #### タグ |Name|関連ページ数| |---|---| |[[Tags/読書\|読書]]|58| ### 🗞 登場した用語まとめ #### 用語 |Name| |---| |[[Terminology/アジャイル開発\|アジャイル開発]]| |[[Terminology/DevOps\|DevOps]]| [TOP](https://www.notion.so/shinofara-1a690b35713b45bf8ea599bfa73fb7df?pvs=21) > [[Tags/読書|読書]]