今回は世界一流エンジニアの思考法を知りたかったので、この本を読みました。
「世界一流エンジニアの思考法」
そのまんまですね（笑）
僕も普段エンジニアのようなことを仕事でしているので、響くものがありました。
この本では日本企業の問題点を的確にしています。
今回は同じエンジニアとしてこれは確かにやっておいた方が良いなと共感したところと、日本企業のダメなところで共感したところをアウトプットしていければよいと思います。
やっておいた方が良いと思うところは蔑ろにせずに、ダメなところがすぐにやめることをするだけだけで優秀なエンジニアは育っていくと思います。
【共感したこと】やっておいた方が良いこと
今回僕がやっておくと良い事だと共感した項目は以下です。
- ログを見ること
- 理解に時間をかけること
- まずドキュメントを書くこと
- 不確実性を受け入れること
- コードを読む際は脳みその負荷を減らすようにしてみること
- WIP=1をすること
- コードを読み物として扱うこと
一つずつ見ていきます。
ログを見ること
障害もそうだけど、何かエラーとか問題が起きた時どうするでしょうか？
何が問題かを調査しないといけません。
その調査はどうしますか？
手を動かして、print文を出したりして試行錯誤とかしませんか？
それでは効率が悪いです。
まずはログを見ましょう。
どういうことが起こっているかを推測してから（仮説を立ててから）その推測や仮説を証明するようにするのが良いです。
理解に時間をかけること
僕もこれは陥りがちになりますが、理解するときに時間をかけないようにすることです。
要は、仕事で生産性を上げておかないといけないと思って、理解に時間をかけないことはいけないってことです。
ただ、理解に時間をかけた方が最終的な生産性は高くなります。
どんなに頭がいい人でも理解には時間がかかるものなのだ。頭のいい人が理解が早いように見えるのは、そうやって時間をかけて基礎を積み重ねているので、既に理解していることに関して頭のメモリにコンテキスト（文脈）が載っているからだ。
「世界一流エンジニアの思考法」
理解が十分でないままに手を動かそうとすると、空回りをすることが多くなります。
さらには、取り組んだことも忘れやすいです。
ただ、手を動かしてアウトプットをすることも理解に繋がるのでとても大事だと僕は思います。
これは「学びを結果に変えるアウトプット大全」という本を記事にした時に書きましたが、
黄金比率はインプット（暗記）：アウトプット（問題集）= 3 : 7
だからです。
アウトプットは理解のために必須だと思います。
ただ、早くできるように急ぐ努力はダメだということです。
本書では「理解」の3要素は以下だと述べられています。
- その構造をつかんで人に説明できること
- いつでもどこでも即座に取り出して使えること
- 知見を踏まえて応用がきくこと
この3つを目指して、アウトプットしながら理解をしていきたいですね。
まずドキュメントを書くこと
コードを書く前にドキュメントを書くということです。
利点として以下の2点が書かれていました。（以下2点は本書からの引用です。）
- ドキュメントを書くことで自分の頭が整理される。抜け落ちていた視点などに気づくことができる。
- 考えているときに書けば、自動的に”ドキュメント”になるので、それをシェアするだけですむ。後でまとめて退屈なドキュメントを書かなくてよい。
僕はドキュメントを書く前に手書きのメモを書くのがオススメです。
手書きはかなり物事が整理されます。
それを整えたのをwordやパワポのドキュメントに起こします。
そこからコードにすると良いと思います。
不確実性を受け入れること
「不確実性を受け入れること」は失敗を受け入れられるマインドに関係してきます。
変化の激しい時代だからこそ、必要不可欠な考え方です。
具体的に以下の考え方を指します。（以下は本書からの引用です。）
- マネジメントは詳細まで細かく練られた計画を期待しない
- 予算と報告のプロセスは精密な結果の予測を要求しない
- 内部プロセスは計画や優先順位の変更に柔軟である
- 事前に全ての問題分析が完了せずとも新しいことに挑戦する姿勢を持つ
- システムとプロセスは柔軟で、複数の頻繁な変更を受けいられる
- 学びに基づいて、変化を精力的に行う
無理しすぎる日本人には必要な考え方です。
そもそも納期を絶対視しているから無理をしてしまうのです。
今は変化の多い時代ですので、納期はあくまで目安にすぎません。
コードを読む際は脳みその負荷を減らすようにしてみること
頭をできるだけ使わずに済むところは使わないようにするのが良いですね。
コードの読込みをする際も同様です。
コードは全て読んでは行けなくて、余計なコードは読まずに飛ばしましょう。
ではどこを読めばよいのかと言うと、使っているインターフェースと構造を理解しようとするのが良いようです。
僕も無意識にやっていたかもしれないですが、全部は読んではいません。（ただし、インターフェースを理解しようと読んではいなかったです。ここはやってみたいと思います。）
インターフェースと構造を理解するためには、ダイヤグラムや関係性のグラフを書いたりすることがいいです。
WIP=1をすること
「WIP」とは「Work In Progress」の略で、今やっている仕事のことを指します。
これを1つにする、つまり、WIP=1にすることが良いということです。
マルチタスクはするなと言うことです。
マルチタスクは逆に生産性を下げます。
この本にはポイントとして以下が書かれていました。（以下は本書からの引用です。）
- どんなにすごい人でも、時間がかかることはかかる。焦らずに時間をかける。
- 30分から1時間を割り当てたら、そのこと「のみ」に取り組む。すぐに終わらないものは、人に問い合わせるなど、物事を進めておいて、待ち状態にして、次のタスクに進む
- 一つのことをやっていることきは、他のことは一切せずに集中する。
- 一つのタスクを中断する場合、次に再開するときに、すぐにその状態に戻れるように記録したり、整理しておいたりする。
- タスクの残骸は消しておく
- 例えばブラウザのタブは、そのタスクが終わったら閉じて、必要なものは記録する（そうしないと、気移りしてしまう）
コードを読み物として扱うこと
これは他人が自分のコードを読むということを意識しながらコードを書く必要があるってことですね。
チームで開発するには他の開発者がレビューしやすいように可読性のよいコードを書くことが大事です。
【共感したこと】日本企業のここがダメ
この本にはアメリカの一流エンジニアと日本の会社のダメなところが対比して書かれているところが幾つかあります。
その中でも僕が共感した日本企業のダメなところを書いておきます。
共感した一覧が以下です。
- 全部やろうとし過ぎ
- 失敗は許されない精神がある
- 決断までが遅すぎる
- 決断までが「なるはや」で精神はある
- 反省や改善点の要求が多すぎる
- 新人に雑用をさせる
ひとつずつ見ていきます。
全部やろうとし過ぎ
日本の進捗会議を覗いてみると、何ができていて、何が遅れているかを報告をしています。
つまりスケジュールがあり、その予定を全部こなすにはどれだけ人を投入すればよいかに頭を使います。
全部やろうとするわけです。
でも世界一流エンジニアはマネージャが重要じゃないタスクを省いていくれると言います。
何でもかんでも全部やるんじゃなくて取捨選択が必要になってくるという訳ですね。
失敗は許されない精神がある
これは上記で記載した「不確実性を受け入れること」に反することです。
どんだけ準備しても失敗は発生します。
ただ日本のおかしなところは客も怒りだすところです。
納期も守らないと許されないというところにも似ているなと思います。
決断までが遅すぎる
米国でのある体験として、
リュックを一つだけ背負った兄ちゃんが上司に会いに来て1時間ぐらい話したあと、「やろう」と言って、500人規模のプロジェクトをその場で決定した
というエピソードが載っていました。
日本の場合はどうでしょう。
ベンダーが提案を行い、Excelで質問票を作り、、、、最悪、実施せずにやめてしまったなんてこともあります…。
当然、慎重になるのは大事ですが、決めるまでの時間が遅すぎるというのはめちゃくちゃ共感します。
決断までが「なるはや」で精神はある
もう、why Japanese people !?!?!?って感じ。
ここは引用して終わります。
日本では「なるはやで」とか「明日までに」というオーダーで仕事を依頼されることが多いが、海外ではそうした火急の依頼は「マネジメント能力の欠如」と見なされることを覚えておいてほしい、納期を割る確率が高い賭けをしているようなものだし、依頼先にも相当な負荷をかける
「世界一流エンジニアの思考法」
「なるはや」でっていうオーダーはマネジメント能力がない証拠
反省や改善点の要求が多すぎる
マナーとかもそうだけど、日本では社員としてこうあるべきみたいな姿勢（というか要求）がとても多いです。
仕事に対しても、反省点や改善点が多くて、そのような多い要求から現場のエンジニアの労働を増やし、働く喜びをも失わせていっています。
新人に雑用をさせる
日本では新人はエクセルのスクショをとらせるような簡単な仕事しかふらないようなことを見ることがあります。
これは、仕事はできない人として扱っています。
しかし、実際はある程度はできるわけで、できる人として扱うと、周囲の助けも借りたりしてきちんとやろうとします。
成長も速いです。
おわりに
今回は一人のエンジニアとして、「世界一流エンジニアの思考法」から共感できるところをまとめてみました。
正直、共感がとてもある本で今回の記事で取り上げた箇所以外にもまだまだあります。
日本の企業もこれを見習って実践していってほしいと願うばかりです。
ただ、願っているだけでは駄目なので、少なくとも自分はこうならないように気を付けていきたいと思っています。
たくさんの優秀なエンジニアが育つように願いを込めて今回は終わります。🙏🙏
