ganyariya blog
「世界一流エンジニアの思考法」を読みましたはじめに
本屋で見かけて気になった「世界一流エンジニアの思考法」という本を買って読みました。
著者は米マイクロソフトで働かれている牛尾剛さんです。
この記事では 「ganyariya がこちらの本を読んで参考にしたいな」と思った点を定期的に思い返すようにまとめます。
本書のテーマについて
本書では「米マイクロソフトにいる超優秀エンジニアの思考法（マインドセット）」を紹介しています。
というのも、牛尾さんが米マイクロソフトで仕事をしてしんどくなっていたときに、同僚の優秀エンジニアの働き方と思考法に着目し真似することによって、仕事の質と生産性が向上したそうです。
この経験をもとに、米マイクロソフトのエンジニアの思考法を本書では紹介しています。
ただし、「思考法」と本書のタイトルにありますが、「早く寝る・残業しない」といった思考法ではなく「テクニック」も多く扱われています。
第 1 章: 世界一流エンジニアの生産性が高い秘密
試行錯誤をできるだけしない
なにか問題に詰まったときに、エンジニアは色々な試行錯誤をすることが多いです。
具体的には、コードの一部分を変更してみたり、ログを追加してみたりします。
しかし、検討を立てずにとりあえず手を動かしてしまうと、時間と体力だけが多く取られてしまいます。
そのため、今の現状を理解するためにきちんと情報を収集し、あらゆる仮説を立てて検証します。
そのうえで、適切な仮説を立てられたら実際に手を動かして問題を解決します。
試行錯誤しないことを ganyariya も意識していましたが、「色々な仮説を立てる」が苦手で「バグの原因これかな〜」と決めつけてしまうことが多いです。
きちんと色々な仮説を立ててから行動するようにします。
「理解」には時間をかける
コードを書くとき、きちんとソフトウェアサイエンスの知識・枯れた技術の知識を理解しておく必要があります。
この「理解」には以下の 3 段階があります。
- 他の人に（理由と改善方法を）説明できる
- その技術をいつでも使える
- その技術を発展・応用できる
「技術を真に理解する」には時間がかかるもの・労力がかかるものという前提にたって、きちんと時間をかけて理解するようにしよう、と本書で紹介されています。
ganyariya もこれにはすごい賛成で、真に理解しないと結局毎回調べて多くの時間を有してしまうなと考えています。
きちんと理解することで、技術の活用範囲がぐぐっと広がり、競プロでいう「典型テク」として利用できると考えています。
理解の種類においえ、「他の人に説明できる」というのがありましたが、 ganyariya は「他の人に理由と改善方法を説明できる」ということを意識しようと思いました。
たとえば、 Kubernetes Deployment における labelSelector がなぜ必要なのか？という理由や、機能 X を実現するために構築したアーキテクチャ Y がすでにあったときに自分ならどういうアーキテクチャ Z にするか？を説明するなどです。
「技術・構成 X は X のままでなくてはならない」ではなく「なぜ X なのか」「自分なら X ではなくどのような Y にするか」を説明できるように心がけようと思います。
コードを書く前には、自分なりのメンタルモデルを構築し、小さなドキュメントを用意しておくほうがいい、と本書で紹介されています。
メンタルモデルとは、実装しているサービス S の自分なりに解釈したモデル M です。
たとえば、 Kubernetes, ArgoCD, Jenkins の CI/CD デプロイパイプラインがどう動いているか？を自分のなかでモデル化したときの、その概念的なモデルになります。
サーバサイドなのか、クライアントサイドなのか、インフラサイドなのかによって、同じシステムでもメンタルモデルが異なります。
自分が解釈できる最適なメンタルモデルを構築します。
メンタルモデルを構築したら、今回構築する機能 Y に対する簡単なドキュメント・図を構築します。
これによって、設計のミスにいち早く気づけたり、プランナーさんやクライアントの方に分かりやすくお伝えできる概念図を提供できます。
ここ最近 ganyariya もメンタルモデルを構築すること、ドキュメント（というかイラスト）を用意することを意識しています。
最終的なアウトプットは「コード」ですが、コードを理解するのには時間がかかります。
（そのため、 Reviewer からすると「どうしてこのコードがいるんだ…?」というレビュー負荷が高い）
しかし、概念的なイラストがあったり、メンタルモデルを図示化して他の人に共有できれば、レビュワーの負担が減ったり、プランナーとサーバの認識の齟齬を減らせます。
これからはもっと意識してメンタルモデルを構築し、分かりやすく相手に伝えられるようなドキュメントを用意したいです。
第 2 章: アメリカで見つけたマインドセット
Be Lazy
とにかく「怠惰」であろう、というものです。
具体的には以下のようなものです。
- 残業しない
- MTG 内ですべての事項を決定させる
- 価値のあることだけをやって、そうでないことは容赦なくやめる
- スケジュールが間に合わないなら、その施策で出す機能を減らす
このあたりは「エッセンシャル思考」そのままでした。
できるだけやることを減らして、もっとも価値のあることだけに時間を費やそう、というものです。
失敗を許容しよう & できるだけ早く失敗しよう
日本人は失敗することを恐れがちですが、アメリカ人は失敗することを褒め称える習慣があります。
というのも失敗しないこと = 「誰でもできる簡単なことであり、挑戦的でない」という考え方があるためです。
そのため、失敗することをチーム・会社で奨励していき（怒らない）、喜ばしいことであるとしましょう、と述べています。
ただし、失敗するのであればできるだけ早く実行して失敗しましょう、とも述べています。
実行するのが後になればなるほど、失敗の規模がどんどん大きくなり取り返しがつかなくなります。
議論・検討も大事ですが、小さくはじめて (MVP)はやく失敗し、フィードバックをもとに改善する、というサイクルを増やそう、というものです。
ganyariya は失敗することを恐れがちなので、もっと難しいことに挑戦して、失敗することに慣れて、かつ成功する体験を増やしたいです。
第 3 章: 情報整理・記憶術
マルチタスクをやめる
マルチタスクは効率がとても悪いです。
自分が今やるべきもっとも大切なことだけをやりましょう。
とはいっても Slack の返信だったり、実装の相談だったり、緊急対応だったり、やり取りしないといけないことが多いです。
そのため、そのような割り込みのタスクなどについては、紙に一時的にメモしてマルチタスクをできるだけ避けるようにしたいですね。
自分の時間を確保する
マルチタスクに似た内容として、自分のタスクの時間を先に確保する、というものです。
自分のコーディングの時間を先に確保して、その隙間に MTG や Chat 返信を行います。
というのも本書では、 すぐに対応が必要な緊急度が高いものは少ないことが多いため、 1 時間といったような定期的にまとめて返す、でも問題ないとしています。
ここ最近 ganyariya も仕事において、安定して作業の時間を確保できておらず、不定期でやってくる Slack のメッセージ確認を気にしてしまっています。
集中力を落とさない、という意味でも Pomodoro の Work 中はコーディングをして、 Rest 中に軽い運動やチャット返信などを行おうと思います。
第 4 章: コミュニケーションの技術
情報量を減らす
仕事のコミュニケーションにおいては、できるだけシンプルに情報量を減らすことが大切、と本書で述べられています。
必要になったら追加で説明をすればよく、それまでは最小限かつ分かりやすいイラストのみにすればよいです。
この「最小限にする」は自分も最近重要だなと思っていて、なんでもかんでもいっぱい説明したり、タスクを管理するのはオーバーだなと気づきました。
伝える情報が多すぎると相手も理解に苦しむため、 1, 10, 100 のように段階的に情報を共有するほうがよいなと思いました。
オモコロチャンネルも必ず最初に趣旨を一言で述べていて、こういうことだなと思いました。
相手と相手の考えを否定しない
議論をする際に、あくまでも自分の意見だけど… と相手を否定しないで相談する。
人によって考え方やアイディアが異なることはいいことであり、その差を否定するのではなく、あくまで自分は XX だけど… という提案をする。
お仕事をするうえで間違い…という方法や考え方はないため、お互いの意見を吸収してよりよい方法を見つけ出せるようにしたいです。
（本書を読んで、自分も否定してしまっているかも…? となったため気をつけます。）
気軽に質問する・ Quick Call を心がける
わからないことを質問することはいいことなので、わからないこと・不明なことは積極的に聞くようにしましょう。
人間の多くは「教えたがり」が大半なので、質問するほうが得です。
また、 チャットで相談するよりも zoom huddle といった同期的なコミュニケーションを優先するようにします。
というのもチャットではうまく自分の考えを伝えられなかったり、不明な点を明らかにするまで多くの時間がかかります。
そのため、 Quick Call を優先するようにしましょう、と述べられています。
社内でも Quick Call が部分部分で利用されていますが、コミュニケーションの多くはチャットになっています。
Quick Call 便利だなぁ〜と思っているため、もっと積極的に活用していきます。
第 5 章: 生産力を高めるチームビルディング
サーバントリーダーシップ
アメリカのアジャイル開発においては、「サーバントリーダーシップ」をマネジメントに取り入れているところが多くあるようです。
サーバントリーダーシップマネジメントにおいては、マネージャはビジョンの共有や KPI, 大まかなスケジュールの提供のみを行います。
実際のタスクの割り振りや実装方法、工数などはメンバーがそれぞれ相談しながら行います。
これによって、メンバは「やらされている感」が少なくなり、相互に助け合いながら「うまく機能 X を実現するぞ」というやる気が出るようになる、というものです。
また、マネージャはチームメンバが「仕事を楽しんで行えているか？」とキャリアのサポートを行うのみにとどめて、余計な口出しはできるだけ減らすようにします。
「サーバントリーダーシップ」という概念を ganyariya は知らなかったのですがとてもいいマネジメントの方法だなと思いました。
というのも日本におけるマネジメントは「工数・スケジュール・コストを絶対に守る」という感覚が強く、チームメンバが楽しく自主的に開発できているか？を考慮しているものが少ないためです。
一方サーバントリーダーシップは徹底的にマネージャはメンバのサポートにとどまっていて、具体的なタスク内容やスケジュール・工数は各メンバにお任せします。
この信頼関係がとてもいいな〜と思いました。
また、「仕事を楽しめているか？」という、工数やタスク内容以外の「やる気」「やりがい」「キャリア」に全力を尽くしているのもいいな〜とおもいました。
失敗を推奨する & Be Lazy を推奨する
マインドセットにもありましたが、失敗することを推奨しましょう、と述べられています。
失敗してもその失敗を責めるのではなく、失敗を称えて次はどうその失敗を防げるようにするかをチームで相談します。
また、 Be Lazy もチームで推奨するようにします。
できるだけタスクをチーム全体で減らして重要なことだけに取り組み、また休暇は自由に取れるようにします。
第 6 章: 仕事と人生を充実させる生活習慣術
これです。
最後に
本書で紹介されている内容は具体的かつ仕事において取り組みやすいものが多くてよかったです。実際に明日の仕事から記事でまとめた内容を意識していきたいです。
(P.S. )色々な啓発本を読んでいると自分は最終的にエッセンシャル思考にたどり着くのだなぁと思うなどをしました。