12冊目 世界一流エンジニアの思考法

概要

項目	内容
タイトル	世界一流エンジニアの思考法
発表年	2023
読んだ日	2023/10/30
お勧め度	⭐️⭐️⭐️⭐️

読んだ理由

• X(twitter)でちょいちょい流れてきていた
• Howというよりも思考というタイトルで心の持ち方が学べそうだと思った

狙い

• 効率の良い学習や実行の思考を学ぶ
• エンジニア組織との付き合い方を学ぶ

実践

• 質問するのに相手の時間を気遣ってしまう人に対して、「あなたの成長はチームの成長だよ」って伝える。
  → そのメンバーもハッピーだし、チームも成長したメンバーと一緒に働けてハッピーというマインド。
• どんなFBにも感謝を伝える。
  → FBで指摘をもらうことは自分やチームの幸せにつながると思う。
• FBに対して感謝することをグループに伝える。自分からFBに感謝する。
  → チームにこの考え方を伝える。自分でこれを実践することで示す。FBを正面から受け止めた時の成功体験を自分で語れるようにする。

刺さった言葉たち

彼らはなにも全員が常人と比べて著しく頭の回転が速いわけでも、天才的記憶力を持つわけでもない。
主に「思考法」（マインドセット）が高い生産性を形づくっているのだ。
小手先のテクニックでもなければTipsでもなく、その圧倒的なパフォーマンスは思考法から生まれているという事実。

ハイパフォーマーは、小手先のテクニックではなく考え方が異なると改めて認識。
最近、自分自身のスキルについて考えるが、おそらく日々大切にしていることとか自然とやっていることが重要だと思った。

そもそも学習における「理解」とはなんだろう。
様々なレイヤーがあるが、私の考える〈理解の３要素〉とは次のようなものだ。

・その構造をつかんで、人に説明できること。
・いつでもどこでも即座に取り出して使えること。
・知見を踏まえて応用がきくこと。

これが狙うべき状態なんだと思う。
すなわち、人に説明できるレベルに認識を具体化し、直ぐに思い出して実践できること。
無意識でできることを増やすってウメハラも言っていたなぁ。

手を動かす前に理解を深めるもう一つの強力な方法として、
デザインドキュメント（Design document）を最初に書く、というコツがある。

「ドキュメントはコードを書く前に書くんだ。だって、コード書いた後にドキュメントだけ書くなんて退屈だろ？」

これはその通りだなぁあ。
ドキュメントを書くのはいつもリリース後だったけど、リリース前に書くことにこんなメリットがあるとは、と改めて思った。

「自分や、ドメインエキスパートに対して質問するのを恐れないように！
エンジニアがより賢くなるのはチームの幸せにつながるよ」

これはみんなに言いたい言葉。
「エンジニアがより賢くなるのはチームの幸せに繋がるよ」って超いい言葉。こういう組織に所属したいものだなぁ。

つまり、一つのことで２時間以上ブロックされたなら、
質問するなり相談するなりして寝かせておいて、他の仕事をやっておく方が断然生産性が高い。

 とくに既存システムがある場合は、あれこれ考えて調べる前に、
まず「エキスパートに頼る」というのはベストプラクティスだと思う。

これも基本だけど忘れたくない。
つい自分でやりたくなるけど、既存を活用してそれの理解を高めれば良い。

実施すべき「物量」が少なく「価値」が高いものを如何につくっていくかの工夫を常日頃からしているのだ。

ハイパフォーマーの思考性。
まさにエッセンシャル思考。これを体現しているんだなぁ。

重要なのは、「減らすこと」自体に価値があると、マインドをリセットすることだ。

ここまで振り切れないんだよね、通常。
失うことが怖いから。チャンスを逃すのが怖いから。けど、それには価値があると信じる。
昔は、どっちもやりましょ(ニコッ)て言っていたが、反省すべき。。

パフォーマンスを引き出すための方法

1 一つだけピックアップする
2 時間を固定して、できることを最大化する
3 「準備」「持ち帰り」をやめてその場で解決する
4 物理的にやることを減らす

端的に言えば、やることを絞るのと意思決定の速度を上げるってことだね。
やることが多いと脳みそのリソースが持っていかれるので、物理的に減らすってのが全体として重要っぽい。

生産性を加速するうえで重要な第二のマインドセットとして、
「リスクや間違いを快く受け入れる」というのを挙げたい。

失敗に気づいた後に、本社に報告すると、「フィードバックをありがとう！」と大変感謝される。

日本ではあんまりこの思考がないなぁと思う。
間違っても大丈夫、指摘を受けたらありがとう！という気持ちでやるってこと。
大事だよねぇ。特にフィードバックに対する感謝は本当に大切だと思う。
この気持ちで毎日仕事をするだけで、かなり周りと差が出るという確信がある。

むしろチャレンジしないほうが、会社の将来のリスクを高める。
だから成功しようがしまいが、まずはやってみて、
早くフィードバックを得て、早く間違いを修正していく──FailFastの精神だ。

これもFBをもらうことがハッピーという前提でのFailFast。
この前提を除いて、失敗しよう！とか言ってるパターンが結構ある気がする。
失敗とFBをペアにして伝えていきたい。

失敗はただの結果であり、そこでどんな「フィードバック」を得たかのほうがはるかに重要だ。

これよ。めっちゃ頻出なので、自分なりにこの考え方を命名したい。
「ウメハラ思考」。失敗こそ成功の親。偉大なる先人の言葉。

「フィードバック」を歓迎するムードをつくる

チームメイトが何か成功したら当然喜ぼう。
もし失敗して、フィードバックしてくれたら、失敗する方法がわかったので、感謝しよう。

成功したら喜ぶは当たりまえ！
フィードバックに対して感謝しよう！を伝えよう。

失敗を快く受け入れるマインドはそのまま、
業務全体の「不確実性を受け入れる」ことにもつながってくる。
変化に柔軟に対応する必要のあるソフトウェア開発の分野では
とくに必要とされる第三の思考の習慣だ。

これは開発だけでなく、応用が効くって話。
ポータブルスキルとして位置付けて考えたい。

日本では「なるはやで」とか「明日までに」というオーダーで仕事を依頼されることが多いが、
海外ではそうした火急の依頼は「マネジメント能力の欠如」と見なされることを覚えておいてほしい。

こういう相談はしないようにしたい。
やるのもやられるのも全体の効率に悪影響だよね。

ＡＩに書いてもらったり、既存のコードをコピペすればすぐにアウトカムを出せても、
中身を理解していないからコントロールできてる感はないし、
その後何度も調べることになり、応用が利かない。

作業ばかりが続くので、自分が知らないことや、
新しいことのキャッチアップなどもできない、つまり「成長していない」ということになる。

chatGPTで動くものを早く作ること自体はできるが、それを自分で説明できたり活用できる状態にならないと成長につながらないってことね。
そうだよね。これはしっかり肝に銘じとく。

成長のためには、時にはじゃぶじゃぶ時間を使うことだって必要だ。
そうやって技術を徹底的に理解し、理解した情報の整理をして、
すぐに取り出せるレベル１の状態にしてこそ、長い目で見たさいの生産性は上がる。
だから、アウトカムを急いではいけない。

早く汚くではなく、じっくり取り組んで自然とできる状態(レベル１)にすることの大切さ。

「マルチタスク」はしないほうが絶対に脳の生産性が高まる。

ここまで言い切ってくれると気持ちいい。
マルチタスクはマジで敵だと思う。
やってる時は俺TUEEEEになるけど、振り返るとあんまり良くない。。

キャリアが長くなればなるほど、自分がコンテキストを持っている分野が増えるから、
他の人をサポートする仕事も増える。
それを他の人にシェアしてあげるのは立派な仕事なのだが、
自分のプライオリティの高い仕事が進まないのであれば、意味がない。

これは、他者からの質問や相談へのレスポンス速度をどうするかという話の中で、
毎回を最高のレスポンスにする必要はないって話。
本書では、4時間を自分の時間として確保して、そこでは一切他のことをしないと決めるのが有効と書いてある。

つい、他の人からの質問に「早く答えないと」って思ってしまうが、
そうじゃないってのはありがたいし、他の人にも早いレスポンスを求めないようにしよう。

「そうか、自分がやったからといって、理解できてるとは限らないんだ」という事実に行き着いた。
そこで、時間は気にせず、自分がやったことをクリアに説明できるよう時間をかけて言語化してみる。

自分がやったことを説明できるレベルに理解を高めることって重要だよね。
これの積み重ねが成長なんだなぁ。

人に説明可能な状態にもっていく訓練として最良の手段の一つは、ブログを書いてみることだ。

これもいいよねぇ。こんな感じで自分もZennにまとめているけど、説明できるレベルに理解を高めるのがいいんだな。

話を聞きながらビジュアルのイメージをつくったり
メンタルモデルを脳の中で視覚化したりして、
自分が理解できているか確認するのが有効だった。

なるほど！ビジュアルイメージを自分の頭で描いてみるのをやってみるか。

つまり、最初から全部説明せず、
「情報量を減らす」コミュニケーションの仕方がすごく重要だったのだ。

いきなり盛り盛りで説明するときついので、情報量を減らすことを意識するとコミュニケーションが楽になり、質も上がるってこと。

「相手が本当に欲しい情報は何か？」──これを普段から意識しておくことが、
生産性を抜本的に向上させる鍵となる。

相手に説明できることが理解のファーストステップなので、常にこれを意識して仕事するってことね。
これは難しいけど、訓練したいなぁ。

私がメモをとるときは、つい「自分用の、自分がわかるため」の書き方をしがちだが、
彼女のメモは、見る人が欲しい情報はこれだろうという形で整理されている。

相手に説明することを無意識に日々の仕事でできている例。
ここまでできたら凄すぎるけど、やりたいなぁ。

ではどうやってチームメンバー同士、
オンライン上のコミュニケーションの欠点を補ったらいいのだろう？
答えは、クイックコール（QuickCall）を頻繁に使うことだった。

オンラインでの仕事でのコミュニケーションの鍵は、QuickCall(アドホック通話)。
これを発生させて、進めることでテンポ良く仕事が進む。

助けになれない場合は、すぐに「ごめん」でクールに済ませたほうが、
聞く方も聞かれる方も気が楽なのだ。

これもカッコええなぁ。つい、質問してもらったら解決したくなって
必死に考えちゃうけど、自分で解決が難しいならごめんって言い切ろう。

ディスカッションは「どちらが正しいか」はどうでも良く、
「自分の考えを自分なりに深める行為」なので、初心者こそやった方が良い。
コツは、「間違えたら恥ずかしい」という感覚は一切捨てること。

心の持ち方。超大事。歳を取ってもいつまでもこうありたい。

「Agree to disagree」とは、合意できないことを合意するという意味。

どちらが正しいとか間違っているとか、意見に賛同する・しないではなく、
「相手のことを理解して認める力」と言ってもいい。
「あぁ、君は同意しないんだね」ということを理解するのだ。

言われて恥ずかしいとかじゃない。考えは違って当たり前。
人と意見は分けて考える。

「相手を否定しない」「相手のアイディアを否定しない」、
そして「自分の考えとして意見を言う」という鉄則を守れば、
互いのメンタルを傷つけることなく、議論の生産性の向上に直結させることができるだろう。

ほんと繰り返し、言い方を変えて、議論の時の心のあり方を説いてくれる。
何度も刻もう・・・。

マネージャーの主な仕事は「アンブロック」だ。
つまり、開発者がどこかで詰まっている状態になると、ブロックされるものを取り除いてくれる。

マネージャーは障壁を取り除くもの。意識意識。

マネージャーは絶対に急かさない。
私は一度も「早くしてください」と言われたことがなく、
「なんだか遅くてごめんな」というと、「いや気にすんなよ」「よくあることだよ」と励ましてくれる。

納期順守はもうやめた方が良い。
納期が重要で間に合わないなら、その機能を排除してリリースした方が良い。
だから、急がせない。んですって！素敵だなぁ