世界一流エンジニアの思考法を読んだ
読んだきっかけ
ちょっと話題になっていたので手に取ってみた。
たしかIwashiさんがXで言及してたのを見かけたのが最初で、社内でも読んだって言ってた方がいらっしゃったので。
https://m.media-amazon.com/images/I/41PjuwcEzYL._SY445_SX342_.jpg
生産性の高いエンジニアの行動パターン、思考パターンについて整理している。
著者は米マイクロソフトで働くエンジニアで、業務の中で出会った「イケてる」エンジニアたちの行動や思考を分析して紹介している。
代表的な例として、以下のようなものがあった。
できるだけ自分で調べてから質問するんじゃなくて、カジュアルに質問する
カジュアルにお願いする分、カジュアルに断れる雰囲気がある
確かに自分で調べてから質問する、はあるある。
チーム全体の生産性を考えた時、自分で散々調べて行き詰まるよりも、ドメイン知識が豊富だとか技術に精通しているとかの理由で自分が知りたいことを即答できる人がいる場合、その人が知ってることを教えてもらうほうがチーム全体として生産性高いんじゃない?という話。質問される側もカジュアルに知っていることを答えるとのこと。しかも、最初からいろんな情報を詰め込まず、雑に(=ラフに)聞いちゃう、とのこと。
またそれとセットで大事なのが気軽に断れる雰囲気がある、ということらしい。気軽に聞く代わりに気軽に断る。あっさりと返されることもあるそうで、そうなるともちろん自分で調べることにはなる。
なるほどなー、と思う一方で、結城先生の技術系メーリングリストで質問するときのパターン・ランゲージに記載されている有名なプラクティスの通り、発生している問題に対する状況や試したこと、質問の背景などを揃えて質問することで少ないラリーで的確に答えてもらえるし、実際自分も回答する立場としては答えやすいなーというのもあり。 心情的にはラフな質問のメリットも理解できるけど、実際に自分がざっくり質問されるシーンを考えると...。状況をまとめてもらってた方が効率いいし、人に聞く前のトライアルアンドエラーにも価値があったりするよなとも思う。
特に、エンジニア歴が浅かったり初心者だったりすると、エラーに向き合う耐性みたいなものがまだまだ鍛えられてないので「思考停止で脳直質問」みたいなアクションに対してプラスのフィードバックが働きすぎることにもなるんじゃないかなと思った。プログラミングの初学者を相手にしていると、エラーなどを元にして自分で仮説検証を回すループが確立できていないため、やりたいことやエラーの状況を自分一人では言語化できず、周囲からの質問によって引き出してもらっているケースをたくさんみる。最初は何もわからないのでそこから始まるのは当然仕方がないが、それを抜け出せないままなのは問題だなと思う。著者の方の周囲には優秀な方ばかりなので、おそらくこのようなタイプの人がいないから想像がつきにくいだろうけど...。
粘り強く自分で調べる力も大事だし、困ったときに人に聞くのも大事。使い分けができればいいんだけど、それが結局「バランス」だとか「臨機応変に」みたいな話になっちゃうので、一括りにして語るのは結局難しいよなーと。
ただ、著者の方の言う通り特に仕事は期限があるものなので、自分のやり方に固執して成果が出ないような状況は避けるべきであるというのは当然同意する。
USでは(というか著者の方の環境では)、質問時に情報が多すぎると読むのに時間がかかるので読んでもらえない、みたいなことも書いてあって、なるほどお国柄なのかなーなどと思ったりもした。
取り入れたいこと
いきなり手を動かさない
まずは事実を一つ見つけて仮説を立てる→仮説を検証するための行動をとる
でたらめに手を動かすのではなく、考えて最短ルートを通れるようにする
理解に時間をかける
難しいことを理解するのは時間がかかるということを認識する
時間をかけて基礎を積み重ねることでコンテキストを蓄積しておく
コンテキストが頭のメモリにのっているとどんどん理解がしやすくなる
つまり、複利ってことmochi5o.icon
コードのロジックを読むのではなく、コードの意図とそのアーキテクチャを理解するために読む
マルチタスクをやめて一つずつ完了させる(小さなこと、日常のことであっても)]
机が片付く、部屋が片付く、資料が片付く
小さなドキュメントをコードの前に書く
ドキュメントを書いてからコードを書く
頭の中にメンタルモデルを作る
思考の型のようなものを持つ、ということ
この辺苦手だなmochi5o.icon
思考のフレームワークとか覚えられない
タイムボックスで動く
長時間仕事をして成果を上げるのではなく、成果を上げるために仕事を切り上げて勉強する(=スキルアップする)時間を取ること
仕事ではなく、新しい技術を学んだり知らない技術を学ぶ時間に充てる
生産性を上げるには「学習が必要」
日常的に運動習慣を優先して朝型になること
自分の人生を自分でコントロールすること
メモしておきたいコンセプト
レベル1:何もググらずに即座に実装できるもの。
レベル2:問題をどう解決するかはすぐに思いつくが、具体的な方法は忘れているので、ググる必要があるもの。
レベル3:自分は解法を知らないが、スパイクソリューション(課題把握のための大まかなプログラム)をしたらできそうなもの。
レベル4:自分だけでは解決が難しい、もしくはものすごく時間がかかるもの。
〜中略
そこでふと、生産性とはいかに「レベル1」を増やすかではないか──レベル2がそこそこある私の場合、レベル3や4の増加を目指すよりも、レベル2案件をレベル1に向上させたほうが生産性が高いのではという気づきを得た。