【感想】世界一流エンジニアの思考法
あけましておめでとうございます。今年もよろしくお願いいたします。
今年は、知識の地盤を固める年にしようと思いまして、その一環として積読を消費していこうと思っております。
その第一弾として、この本を読んだので記録しておきます。
目次
どんな本？
2023年10月に発売された、米マイクロソフトの現役エンジニアの方（日本人）が書いている本です。Azureの開発に関わっている方で、アメリカのマイクロソフトで働くようになってから気づいたこと、周りの凄腕エンジニアがやっていることなどを分かりやすく解説してくれています。Amazonでは★4.7でめちゃくちゃ人気の本です。
内容を一言でいうと、色々な無駄なことをやめれば仕事の生産性高まるぜ！空いた時間で筋トレして幸せになろう！ という感じでしょうか。この「無駄なことをやめれば」というところの考え方が、色々と載っていて面白いです。ここからは、個人的に気になったポイントをピックアップしていきます。
気になったポイント
一つだけピックアップする
生産性を高めるための考え方の一つとして、「Be Lazy」（怠惰であれ）というものが紹介されています。これは、より少ない時間で価値を最大化するという考え方とのこと。その中の一例として、この「一つだけピックアップする」ということが挙がっていました。
書籍では、エンジニアなのでバックログの中から一つだけピックアップして実装するという例が出ていましたが、なんにでも当てはめられるなと思いました。
私はとりあえずなんでも手を出したり、「あれもこれもやりまぁす！」と言って結局全部中途半端になったりということが良くあります。なので、この考え方は役に立ちそうだなと感じました。「いくつかをピックアップする」とかではなくて、「一つ」なのが良いですよね。曖昧さがない。そういう意味では、今回も書籍からピックアップする箇所は一つにしようかなと思いましたが、「一つ」選ぶことを6回やったと考えることにしました。
試行錯誤ではなく、仮説を立てる
とりあえず何でもかんでもやるのではなく、ある仮説を立ててみてそれを検証する行動をとるべし、という内容でした。書籍ではプログラムのバグを解消する際の例が載っていました。
自身のコンサルで置き換えて考えてみると、特にお客さんへのヒアリングや提案の際に使える考え方だなと思いました。ヒアリングの際は、事前情報（営業からの話や資料、会社のHPなど）から課題の原因や背景を仮定して、それを検証するようなヒアリング項目を準備する。提案の際は、ヒアリングで聞いた情報をもとに仮定を更新して、それを解決するような提案をまとめて持っていく。今思うとそういうことをしているなと思いつつ、改めて意識していきたいなと思います。
少し脱線しますが、仮説を立てるには想像力が必要であり、この「想像力」が仕事において結構大切だなと感じています。例えば仕事の見積もりをするときにも必要ですし、上記のお客さんへの提案の際にも必要になりますよね。この想像力を向上させるために、仕事だけではない様々な経験が必要になるなと思いました。
理解には時間をかける
他の章ではとにかく「時間を短縮せよ」と言っていますが、ここは逆です。どんなに天才でも理解するのには時間がかかるから、ささっと読んで分かった気になるなよ、ということです。特に「構造」を理解することが重要だと著者は言っています。プログラムやアーキテクチャの理解ではもちろん構造は重要ですが、それ以外でもまずは全体の構造を理解することは重要ですよね。
この章も、結構自分に刺さりました。最近は、あまり書籍を読み込んだり自分で手を動かしたりすることが少なくなってきていて、ブログ記事やXの内容をさらっと読んでいることが多くなっていたからです。おそらく飽きっぽいのだと思いますが、今まで業務でやってきたところは「まぁ詳しいからええやろ」と結構そのままになっているところが多いです。今年は、そのあたりも改善していかないといけないですね。
メンタルモデルを構築する
本書のp.45から引用すると
メンタルモデルとは、人々が世界を理解し、予測し、解釈し、新しい状況に適用するための、自己の心の中のイメージや理論
とのことです。さらに本書では、いくつかのフレームワークを頭に入れておいて、それに従って仕事をすることが例として挙げられていました。簡単にいうと、「仕事のカタを持っておこう」ということでしょうかね。仮説を立てる、の章で出てきた内容も、ある意味メンタルモデルの一つでしょうか。というか、それ以外の章もすべて最終的にはメンタルモデルに落としていけそうですね。
個人的には、このメンタルモデルというものをまず構築して、あとは所属している会社、お客さん、チームメンバーなどに合わせて調整していくイメージを持ちました。前職で構築したメンタルモデル（プロジェクトの進め方や資料の作り方など）を今でも大体受け継いでいますし、新しい会社のやり方を少し混ぜています。ただ、その比率（自分のメンタルモデルと、会社のやり方などの環境によるもの）は個人に依存しそうですね。私は環境に引っ張られがちなので、もう少し自身のメンタルモデルを確立しても良いかもしれません。
意見が対立しても否定しない
アメリカだと、「In my opiniton」というフレーズが頻繁に出てくるとのこと。何か否定するのではなく、「私の意見はこれなので、参考程度に～」的なニュアンスで指摘されることが多いらしいです。言われる側も少し楽だし、何より言う側も楽になりますよね。
ただ、例えば自身がリーダーのプロジェクトでお客さん向け資料をメンバーに作ってもらっている、かつ納期がギリギリというときでもこの姿勢を貫けるでしょうか。どうしても、その評価が自分に跳ね返ってくると考えてしまって、自分の思い通りの資料になっていてほしい！と考えてしまい、「これはこう直してください！」という口調になってしまいそうですよね。それか、「もうこれは自分でやった方が良い」となってしまいそう。
本書で推奨されているサーバントリーダーシップと呼ばれるマネジメントでは、メンバーは「結果に対して報いを受ける」とあります。自分の成功は自分の成功だし、逆に失敗は自分の失敗になります。つまり、チーム構成とタスクの割り振りの時点で、そのタスクの責任の所存をそのメンバーに返ってくるようにすべきであり、そうすればおのずと「In my opiniton」的なニュアンスで指摘ができそうだなと思いました。 上記の例では、そのお客さん向け資料作成は自分でやるべきなんだと思います。
そうなると、従来のピラミッド的な構造のチーム割は結構難しいですよね。少人数で入って、それぞれがxxxの専門家です、という感じで担当するのが理想になりそうです。
仕事を楽しんでいるか？を確認する
上記のサーバントリーダーシップと同じくチームビルディングについての話ですが、自己組織チームという方法が近年日本でも取り組まれているらしいです。上司が指示するのではなく、メンバーが自分で考えて意思決定するチームが「自己組織チーム」であるとのこと。そのチームの特徴の一つに「チームのエンゲージメント（満足度）が高い」というものが挙げられています。これに関して、ここに挙げている「仕事を楽しんでいるか？」がとても重要視されるとのことでした。
これは、外資だからか今の会社でも重要視されていますね。そして、自分を含め同年代や周りのメンバーも、仕事を楽しんでいそう。個人的には、技術に関わることを結構な時間できていることが大きいのかもしれません。自分で試しに検証してみたり、色々調べて比較の提案資料を作ってみたりする作業は純粋に楽しいです。あとは、会社の仕組みとしてめっちゃ褒められることもあるのかも。周りからのフィードバックがとにかく多いので、もちろん直すべきところも指摘されますが、それ以上にすごい褒められる。褒められると嬉しいですよね。
おわりに
上記以外にも、色々と参考になることが載っていたので、仕事のやり方とかに迷っている人には結構おすすめです。ただ、個人的には「ノートなどは使わず頭の中だけで試行整理する」「納期は絶対ではない」という2点だけは、余り納得できていないポイントです。ただ、本書で学んだおかげで「こういう意見もあるんだなぁ」というスタンスでいます。このように、すぐに役立つところが多いのも良いところですね。
今回のように、今年は書籍の感想もいくつか書いていきたいですね。大体この記事書くのに1.5時間くらいかかった（読むのは別にして）ので、それくらいは時間使っていきたいと思います！
