久しぶりにビジネス書を読みました。
なんとなく気が向いたので、本の要約に初挑戦しようかと思います。
また、最後の方で感想も書いています。
どんな人におすすめ？
- 3年目～5年目くらいで、ある程度日本のITが分かってきたエンジニアの方
- 中堅くらいで伸び悩んでいるエンジニアの方
- 日本の文化と世界の文化の違いを知りたい方
個人的には一番上に上げた、若手エンジニアの方に読んでもらいたい本です。新人の方よりは、数年間経験してきた方の方が刺さるのかな（実体験と重なる部分もあるかなと）という印象を受けました。もちろん自分みたいなおじさん層（ゆうて30代半ばですが）が読んでもハマると思います。中間管理職の方は思うところがあるかも。
書籍情報
| タイトル | 世界一流エンジニアの思考法 |
|---|---|
| 著者 | 牛尾 剛 |
| 出版社 | 文藝春秋 |
| 発売日 | 2023年10月23日頃 |
| 商品説明 | 試行錯誤は「悪」。“基礎の理解”に時間をかける、より少ない時間で価値を最大化する考え方とは？「準備」と「持ち帰り」をやめて、その場で解決する、“脳の負荷を減らす”コミュニケーションの極意、コントリビュート文化で「感謝」の好循環を生む…ｅｔｃ．仕事と人生を「自分の手でコントロールする」最高のスキルがここに！ |
| 画像 |  |
※書籍情報は楽天ブックス書籍検索APIを利用して表示しています。
どんな本なの？
日本の大手SIerでエンジニアを経験したのち、米マイクロソフトAzure Functionsプロダクトチームシニアソフトウェアエンジニアとなった、言わば「日本の開発も米国の開発も知ってる」牛尾剛（ウシオツヨシ）さんによるITエンジニアに向けた１冊です。
日本のIT文化と世界のIT文化の違いが実体験に基づいて書かれているので、エンジニアとして仕事をしている人であれば「分かる！」と言うテーマが必ずどこかしらにあるはずです。
なお、著者の牛尾剛さんはもともとnoteやブログで発信活動をしている方で、それがきっかけで本書を執筆するに至ったそうです。（本書あとがきより）
牛尾 剛 | note（https://note.com/simplearchitect/）
要約してみる
ここでは各章のタイトルとその章にどんなことが書かれているかを要約してみようと思います。もしかすると解釈違いが入っちゃってるかもですが、大目に見てください。受け取り方も人それぞれってことで。
第１章 世界一流エンジニアは何が違うのだろう？-生産性の高さの秘密
いきなり試行錯誤をするのではなく、事実をもとに仮説を立てて検証する
プログラムでエラーが発生した際、怪しい部分をパッと修正→検証するより、事実をもとに仮説を立てて検証した方が手数が少なく済む。
だいたいの開発現場では「修正→環境反映→検証」という流れになり、検証の回数が多ければ多いほど時間を食う。修正と検証のセットが少ない方が効率が良い。
優秀なエンジニアは「事実を見つける→仮説をいくつか立てる→証明する」というサイクルでエラーに向き合っている。
優秀な人ほど、理解をすることに時間をかけている
優秀な人は一見理解が早いように見えるが、それは時間をかけて理解を深めており、知識が定着しているからである。
成果を出すだけであれば、例文をコピペするだけでもプログラムはできるが、結局のところ理解をしないままだと、毎回調べに行く時間がかかるし、エラーが発生した際の対応も遅れるしで効率が悪くなる。なので理解をすることに時間をかけるようにする。
では、理解とはなんなのか。
- その構造をつかんで、人に説明できること
- いつでもどこでも即座に取り出して使えること
- 知見を踏まえて応用がきくこと
どれも基礎があってこそ可能なこと。
基礎練習は誰でもできることだが、時間がかかる。時間をかけて基礎を理解するようにする。
小さなドキュメントをコーディング前に書く
ドキュメントを書くと
- 自分の頭が整理され、抜け落ちていた視点などに気づける
- 考えていることをドキュメント化すれば、後にドキュメント化するという作業をしなくて済む
というメリットがある。
第２章 アメリカで見つけたマインドセットー日本にいるときには気づかなかったこと
Be Lazy（怠惰であれ）というマインドセット
無駄なことを減らし、少ない時間で最大限の成果を出すのがという「Be Lazy」という考え方。
日本人の感覚では「やることを減らす」のは悪いことのような気がして、苦手な部分。だけど、重要なのは「減らすこと」自体に価値があるというマインドである。無駄なことに割いていたリソースを優先順位の高い作業に充てることで、より短い時間で価値を最大化できる。
リスク、失敗を受け入れる
失敗に対し懲罰するべきではなく、むしろFall Fast（早く失敗する）であるべき。早く失敗すればその分早く学べる。そのために、避難や恐怖感のない環境を作るのが望ましい。
日本では失敗は許されない風潮があるが、アメリカでは失敗のフィードバックが感謝される。
不確実性を受け入れる
変化に柔軟に対応する必要があるソフトウェア開発の部分では、特に必要とされる思考の習慣。
計画通りにはいかない、すなわち納期は絶対ではない。ここが不確実性となる。
Q（品質） C（コスト） D（納期） + S（スコープ）はトレードオフの関係にある。なので、納期を短縮したければ、品質を落とす、コストを増やす、スコープを減らすかのいずれかとなる。
計画通りにいかず納期が間に合いそうにない場合、そのままのコスト、納期で仕事を実施すると品質が落ちることになる。無理して機能を完成させるよりかは、品質の良いものを作るべき。
なので、納期を固定したままスコープを出し入れするのが現実的な解となる。（無理そうな機能はは次のターゲットに合わせる）
不確実性を受け入れるために
- 楽に達成できる計画で仕事をする
- 「無理・断る」練習をする
- 他の文化の視点を学んでみる
ということを実践する。
結果を出す→バリューを出す
「結果を出す」と「バリューを出す」は似ているようで大きく異なる。
「結果を出す」というのは、一度決めた目標を最後までしっかり守り通すこと。「結果を出す」には、どんな理由であれ一度決めた目標を達成できなければ、失敗と見做されてしまい、それがプレッシャーとなってしまう側面がある。
一方、「バリューを出す」は、どうやったら達成できるかを常に考え、目標達成が困難な場合は、優先順位の高いものをクリアするように方向転換し、できないものはできないと判断する。自分の実力を把握し、実力以上の仕事量にならないように常に考え調整することで、「やってみてどうだったか、改善ポイントはどこか」などのフィードバッグをチームに展開することで価値を生む。
仕事を達成する（結果を出す）ことより、学びのシェアこそがバリューとなり、会社の財産となる。
第３章 脳に余裕を生む情報整理・記憶術ーガチで才能のある同僚たちの極意
コードは極力読まない
コードを全て理解して読み解こうとすると、誰でも時間がかかるし、コード量に圧倒されてしまう。最低限自分で書いたソースを動かせるレベルで解読すべき。
脳の負担を減らす
実装を全て理解しようとすると、脳に負担がかかり、疲労に繋がる。実装を理解する際は、インターフェースや構造を図にしたりしながらそれぞれの役割を理解するようにする。
また、自分にとって難しすぎる作業をしていると感じるときは、脳の使い方が間違っているとき。脳に負担をかけないようタスクを整理して作業するようにする。
ググらずにできることを増やす
仕事を難易度高め別に分けた際、自分の実力ではどうしてもできないことがある。そこをできるようになるより、難易度が低いものをググらずにできるようになったほうが生産性が上がる。その方が脳の負担が減るし、習熟度も上がる。そのためにも、今の自分のレベルを知ることは大切。
マルチタスクをしない
マルチタスクは生産性が最低なのでやらないようにする。人間の脳はマルチタスクに向いていない。一つずつタスクを消化したほうが集中力が上がり、生産性も上がる。
記憶する=説明できる
自分がやってきたことを上手く説明するには、構造を理解、整理、把握する必要がある。つまり、記憶しなければ説明することはできない。逆に言えば、説明できるレベルにすれば、記憶することができる。
第４章 コミュニケーションの極意ー伝え方・聞き方・ディスカッション
情報量を減らす
一般的に情報量は少ないほうが理解する負担が少なく、聞き手に好まれる。話の中で一番重要な要素を決め、そこに絞って説明するようにする。こうすることで、短い時間での情報伝達が最大化する。
相手が何を求めているかを考える
相手が何を求めているか考えることが、コミュニケーションの生産性に繋がる。日頃から誰かに説明するために準備をすることで、何かを聞かれた際のコミュニケーションが円滑になり、工数削減に繋がる。
クイックコールでリモートワークを円滑にする
リモートワーク時はどうしてもテキストでのコミュニケーションが多くなり、一つ一つのコミュニケーションに時間がかかってしまう。そんなとき、ちょっとした質問を通話で行うのがクイックコールだ。音声の方が情報の伝達量が多く、だいたいのルールで映像の共有もできる。よって、テキストよりコミュニケーションが円滑になる。
気軽に質問できる環境を作る
全体が気軽に質問できる環境になれば、組織の効率が相当上がる。分からないことがあった場合、自分で調べるよりか聞いてしまったほうが圧倒的に短い時間で解決できる。
また、「誰でも気軽に質問できる空気」は、「気軽に断れる空気」とセットになる。気軽に質問できるので、そのタイミングで質問できなかったとしても、時間をズラして再度質問すればわけだ。この方が質問する方も質問される方も、気が楽になる。
ディスカッションでの意識
ディスカッションは自分の考えを自分なりに深める行為であり、その場でフィードバッグを貰えるため、短い時間であっても大きな知識と理解を得ることができる。
効果を最大化するために気をつけるのは、「間違えたら恥ずかしい」という意識を捨てること。誰だって知らないものは知らないし、間違える。そんなことを気にするよりは、理解できないことをその場で聞いたほうがバリューが出る。
また、ディスカッション時は相手の意見を否定することをしないように心がける。否定することは少なからず相手のメンタルを傷つけることになる。伝え方を工夫することで、直接的に否定することを避ける。
第５章 生産性を高めるチームビルディングー「サーバントリーダーシップ」「自己組織型チーム」へ
サーバントリーダーシップとは？
リーダーがビジョンとKPIは示すものの、実際にどのように動くかはチームが主体的に考えて意思決定していくのが、サーバントリーダーシップである。一方、リーダーが部下に指示を出し、状況を確認し、把握するのが従来型のコマンドアンドコントロール、いわゆるマイクロマネジメントである。
リーダーが主となるか、チームメンバーが主となるかが異なり、サーバントリーダーシップにおけるリーダーの役割は、メンバーにとって障害となるものを取り除くことである。メンバーが権限を与えられて事業を推進するので、モチベーションの向上が期待できる。日本でよく見るマイクロマネジメントは、メンバーのモチベーションが低下する要因となる。
自己組織チームとは？
自己組織チームは、チームが自ら考えて自分で意思決定をするスタイルだ。以下がその特徴として挙げられる。
- 生産性が高い。
- チームの満足度が高い。
- よりよいソリューションが選択されやすい。
結果としてチームメンバー個々が楽しく作業できる状態となり、楽しければ自主的に仕事に取り組むようになる。これにより、組織全体の生産性が高くなるわけだ。
ボスの役割はサポート
自主的に動くことができるチームのボスは、チームのゴール、ミッションはしっかり共有した上で、メンバーにとっては仕事を遂行する上でのサポーターとなり、メンバーを理解し、困っていれば助けてくれる存在である。ボスのサポートにより、チームが気持ちよく仕事に取り組むことができる。
どうやって自己組織チームを導入するか
人をコントロールして働かせようとする時代はもう終えなければいけない。
とは言え、日本で自己組織チームを導入しようと思った場合、開発チームだけを変えても機能はしない。なぜなら、その上のマネジメント層がチームを管理してしまおうとするからだ。こういった組織の場合、全社を挙げて自己組織型の体制にシフトしなければ、上手く機能しない。
ではどうやって実現するか？
日本は上下関係が強いため、トップ層を相手にする場合、より上層部の人の承諾を得るのが良い。
ミドル層に属する人は、トップ層と比べ抵抗感がある場合が多い。ミドル層は現場に出ており、プロジェクトやサービスごとに数字を持っている。なので、新しいことを取り入れることに慎重になる傾向がある。不安要素を理解した上で導入への道筋を立てると、経験も生きて新しいサーバントリーダーが生まれやすくなる。
失敗に寛容であればチャレンジ精神が生まれる
失敗は自分の能力を超えた作業にチャレンジするからこそ発生する。失敗を糧にすることで、実力が向上していく。
第６章 仕事と人生の質を高める生活習慣術ー「タイムボックス」制から身体づくりまで
生産性を上げたければ定時上がりする
職場に残って仕事をするより、定時で上がって学習に時間を費やしたほうが良い。仕事と学習を切り離したほうが、リラックスしてインプットできる。
タイムボックス制による学習時間の確保
あらかじめ決めた時間になったら、そのタイミングで作業を打ち切る。決めた箱の容量を越えないのがタイムボックス制。
これをすることで、学習や趣味に費やせる時間が増え、徐々に生産性が上がっていく。また、日々仕事に追われるより、精神面でもストレスが溜まりづらい。
エネルギー不足の解消
人は年齢とともに、気力と体力が落ちていく。有酸素運動を日常的に取り入れることで、気力、体力が改善していく。毎日30分でいいので、運動に対する投資をするとよい。
第７章 ＡＩ時代をどう生き残るか？-変化に即応する力と脱「批判文化」のすすめ
AIに食われない職業
身体的なものや対人的なもの、創造的な分野や芸術的な分野はAIに食われない。これらの職業においては、人はAIより人間が作ったものを求める。
だが、エンジニアリングの分野は完璧を求められるので、人間よりAIのほうが向いている。では今後どうしたら良いか。
現時点でのAIはまだまだ完璧ではなく、返答も誤りが多い。この部分に人間のノウハウや専門知識の集積があり、優位であるはず。今はAIを活用しながら、世界が変わっていくのを楽しむ時である。
専門性の強み
誰もやったことがないことに取り組んでいる専門家に、AIは敵わない。AIは世の中に無数に落ちている情報は拾えるが、データが少ないものについては原理的に、まともにサジェストできない。
実際に利用するサービスの提供には、専門性を持ったエンジニアが不可決である。
批判文化にメリットはない
日本では失敗したら責任を追求され、罰を受ける。これが開発者の心を砕いてしまうし、新しいことへチャレンジする気持ちも奪ってしまう。もっと良くしようという気持ちがなければ、良いフィードバッグも生まれず悪循環になる。
完璧な人はいないし、無理なものは無理ということを社会は受け入れなければいけない。
自分の人生は自分でコントロールする
人生と仕事をエンジョイしている人は、どうやったら人生が幸せになるかを主体的に考え、仕事の仕方を選択している。
自分で考え、選択できる人が増えれば悪い状況も変えることができるはず。
感想
Xで見かけたので手にとってみた本書ですが、そこそこなボリュームなのにも関わらず、読み始めてからそのまま一気に読破してしまうくらい自分には刺さりました。
日本で働いていると、いちいち稟議面倒くせえって思うシチュエーションもあるし、勤怠ちょっと適当につけただけで文句言われるし、ルールに従うのが偉い、みたいな風潮がありますよね。
感じ方は三者三様ではあると思いますが、少なくとも私は本書で述べられているような日本特有の文化みたいなのは感じています。ミスを許容できないってのは、まあ場合によりけりですが、これによって生き方が狭まっちゃうのはどうなんかなあと。出来ることしかやらなくなっちゃう人は一定数出てきちゃう。
スキルが無いから転職出来ない→会社にしがみつかなきゃいけない→でも給料は上げて欲しいってのはさすがにワガママが過ぎるわけで。
私はただそれを受け入れるのではなく、せめて自分より若手のエンジニアがこういった文化に嫌気が刺さないように、楽しく作業できるような環境を作っていきたいところです。
アメリカの文化羨ましいな〜とも思いつつ、少し怖さも感じちゃう部分もあるんだよなあ。自責か他責かで争いが生まれるような社会性だし、基本的に責任は取りたくない文化で育っているわけで。変化を恐れてしまうのは日本人の性なのかなあ。
最近は昔と比べて残業を良しとしなくなってきており、その分業務中の作業効率を良くしようという動きも見られるようになってきました。ゆっくりではありますが、少しずつ変化しているように思います。もしかすると、日本人にはこれくらいのスピード感がちょうど良いのかも知れません。
ただ、いつの時代にも変革者がいるわけで。まだまだそういう力を持った人が活躍しやすい社会ではないかも知れませんが、そのうちきっと評価されるときが来ると思います。
ネガティブに考えるより、ポジティブに考えた方が、毎日健康に過ごせることは間違いないし。
とりあえず楽しく生きていこう。
最後に
不労所得で生きてえ。
