今回の想定読者
今回のネタは、「世界一流エンジニアの思考法」という書籍を読んで学んだことやそのディスカッションです。本記事を読んでいただけると、「世界一流エンジニアの思考法」の概要を知ることができます。
以下の様な方が想定読者です。
- 「世界一流エンジニアの思考法」はまだ買っていないが、内容に興味がある
- 既に「世界一流エンジニアの思考法」を読んだが、他の人の解釈が気になる
- 一流エンジニアになりたい
ログビーの勉強会について
ログビー（Logbii）では、月一回オンラインの社内勉強会をしています。直近のものと、2025年以降のアーカイブを順次公開していきます。
ざっくりと、以下のルールで運用をしています。
- 月イチで、ランチタイムにオンライン開催（1時間）
- テーマ自由
- 持ち回りで開催
- ランチ代支給（2000円まで）、飲食可
- 業務時間扱い（業務時間を削る形）でOK
今回の勉強会について
今回は、2025年11月の勉強会アーカイブです。
フロントエンジニアのYoshidaさんが発表しました！
それでは、以下本編です。
世界一流エンジニアの思考法を読んだ
どんな本か
米マイクロソフトで活躍されている牛尾剛さんという方が書かれた本
自分のことを「一流ではない、謙遜しているわけではなく三流だ」と評価している
不器用で記憶力がなく容量が悪い、いわゆる「要領の悪い」人間だったらしく、大人になってからADHDと診断を受けた
マイクロソフトで働いているエンジニアは「一流」だが全員が常人と比べて頭の回転が速い、記憶力が良いというわけではない
一流の思考法を観察したり真似ることでスキルアップしていき最高峰のチームで活躍
その時に実践したことがまとめられた本。
作業効率
Be Lazy(怠惰であれ)というマインド
より少ない時間、労力で価値を最大化するかというマインド
- 望んでいる結果のために最低限の努力
- 不要なもの、付加価値のない仕事をなくす
- 簡潔さを目指す
- 優先順位をつける
- 上から順につけるわけではなく本当に大切な1つだけをピックアップ
- 仕事で重要な仕事は大体20%位。その20%にフォーカスして価値の高いものを作る
- 費やした時間、努力よりもアウトプットと生産性を重視
- 長時間労働しないよう推奨
- 会議は時間内で効率的に
- 宿題、後で検討することをなくすことで会議の時間のみで完結できる
試行錯誤は悪
自分でログをみて理解、仮説を立ててから手を動かす
事実(ログ)を見つける→仮説→検証
手あたり次第に試すのは時間のロス
エキスパートに頼る
１つのことで２時間ブロックされたら質問を投げて自分では別の作業をする方が効率がいい
特に複雑な既存システムの場合は特に
４時間は自分の時間を
メールなどを一切確認せず集中する４時間を自分で作る
マルチタスクを避ける
コミュニケーション・雰囲気づくり
リスク、間違いを受け入れる
- 間違いを批判したり懲罰したりしない
- 大きな失敗をしたときでも報告すると「フィードバックありがとう！」と感謝される
- チャレンジをしない方が会社にとってリスク
- 失敗から学ぶ態度
- Fail Fast(早く失敗する)
- まずはやってみてフィードバックを得る
- 時間をかけてから絶対失敗しないわけでもない
- 検討してばかりで動かない方がリスク
- 実験が推奨されている
- フィードバックを歓迎する空気を作る
- 怒ったり批判はしない。メンバーを子供扱いしているのと同じ
- 検討をやめて検証
- アーキテクチャやツールが数種類あって迷っているならどっちでもいい
- 圧倒的な差があるなら検討するまでもなく決まるから
- 不確実性を受け入れる
- 日本では一度ゴールを決めたらそれを守るのが正義だが状況は常に変化する
- 納期が間に合わないならスコープを出し入れする
- 品質を重視
仕事を楽しむ
1on1では仕事を楽しんでいるかを確認される
楽しくない場合は、どうしたらエンジョイできるかの相談に乗ってもらえる
いかにメンバーが幸せに働けているかを重視、仕事は楽しんでなんぼというカルチャーがある
ミスコミュニケーション
ミスコミュニケーションを感じた時点で話す機会を設けるべき
あとになってからすれ違いや認識の違いが発生するため
クイックコール(予定されていないビデオ通話)を活用
生産性の高い人ほど活用している
一人で悩んでいるよりも知ってる人と１０分作業するだけでも速度は上がる
また、音声の方が情報が多くフィードバックが早い
相手が忙しいかを考える必要はない
気軽に聞ける空気は逆に気軽に断ることができる空気を生む
(日本では自分が分からないことでも任されたら最後まで時間をかけてしまう。)
否定しない
自分の理解を助けてくれたありがとうの姿勢
自分の意見を述べるときには「私の意見では」をつけると柔らかくなる
習慣・文化
脳の負担を減らす
コードリーディングのコツは脳の負担を減らすこと
自分にとって難しいと感じるときは自分の基礎学力が足りないか脳の使い方が間違っているか
才能の差ではなく脳に余裕がない状態で酷使していることが多い
米と日本の文化の違い
- 米と日本の文化の違い
- 日本
- 批判文化
- 接触確認アプリのCOCOAが出てきたときも開発者の人格否定までするような罵詈雑言がひどかった
- もともと日本マイクロソフトの廣瀬さんが有志で開始
- 開発者の心を砕く文化
- できもしない完璧と責任の所在、面子ばかり気にする
- アメリカ
- 自分がどんのことが貢献できるかという文化
- 批判ではなくフィードバック
- 「ありがとう」、「助かった」などポジティブな言葉ばかり
- 大事なシステムが落ちりしても「仕事にならない、遊びに行くか」くらいのノリで誰も責めない
- githubでもいろんな人が集まって批判ではなくフィードバックをレベルを上げている
- 仕事中は感謝しかされない
- 自分がどんのことが貢献できるかという文化
- 日本
- 自分で人生をコントロール
- 日本向けに米企業流の開発システム、マインドの導入を進めると「会社のルールで無理」、「経営層が分かってくれないから無理」と言われた
- 外的要因だけを言ってるだけで、本当にいいと思っているなら自分がどうすれば進められるかとか主体的に進められる
- 自分の人生を自分で決められないと思っている人が多い
- 本当に嫌なら会社を辞めるのも手段
- どうやったら自分が幸せになれるかを考えて仕事を選択している
感想
- あとがきにも書かれていましたが、何かをするというよりは～するのをやめるという内容が多く実践しやすそうだった
- Solution先で実施しているものが多く、だからストレスなく働けていたのかと腑に落ちた
- ログビーが目指している「最高のエンジニア環境を作る」に参考になる部分が多かったのでは？とエンジニア視点で思った
- 日本全体でみると批判文化はどうしてもあるが、会社レベルのコミュニティであれば変えられるので、そういところから変えていくのが大事かなと思った
- もう一周読みたいと思う位には面白かった
ディスカッション
- 業務効率のために取り入れていること
- 高橋さん：上司が怒ることで報告をしなくなる。フィードバックする環境、怒らない環境は大事だと思った。
- 久米さん：ログビーもなるべく批判ではなくフィードバックにしていけたらいい。
- 冨樫さん：ソリューション先でも怒られる文化がなくて良い。生成AIを活用して業務効率化されている方もいらっしゃる。
- おすすめの本
- 達人プログラマ(石倉さん)
- より良いプログラマになるための考え方をまとめられた本
- 達人プログラマ(石倉さん)