牛尾 剛 牛尾 剛
見出し画像

凄いやつになる方法

 私の勤めるマイクロソフトにも、レイオフがやってくるようだ。それもパフォーマンスベース。つまり、今首になると、「この人はローパフォーマー」とわかるので、再就職が難しくなるだろう。

 自分はマイクロソフトの仕事が面白いし、職場も最高なので、こんな中途半端に首にはなりたくはない。ただ、自分がハイパフォーマーとはとても言えない。周りの人はめっちゃ優秀やから。

 私は今までは、自分の性能が「三流」であるけど、ダメな自分を「戦略」でカバーして何とかしてきた。しかし、この流れを見ていると、「三流」のままでは早晩解雇されてしまうだろう。たとえ今回のレイオフを生き延びても、記事を読むと、ワークフォースは減らさないと書いてあるし、出来ない人はいらないという流れなのだと思う。

「優秀」になるしかない

 今まで、自分がダメなのは受け入れていたが、これからはそうもいかないのだと思う。「優秀」になるしかない。この面白い仕事、職場にいるためには、「めっちゃ出来る人」になるしかない。これはもしかすると、Azure Functions に入った時、もしくはそれと同等ぐらいのチャレンジかもしれない。それは、ADHDでもある自分にはとてつもないチャレンジなのだが、同時に「これが出来たら、自分の人生の一番の夢が叶う」という話でもある。

 私は幼少のころから本当に何やってもダメで、何やっても人の3倍ぐらいやって人並みぐらいだった。少なくとも自分がやることに関しては。だから、自分が「何かを出来るようになる」というのは人生最大の願いであり、これが叶ったら死んでも良いといったものだ。

5 ways to Train Yourself to Be a Genius

 今回は偶然次のビデオに出会って、自分なりの Ah-a モーメントを迎えたので、ここに記録をしておきたい。

 このビデオは最高で、日本語に訳すと、「天才になるための5つの方法」と言ったところだろうか。天才とはどういうものかがすごくよく言語化されていてとても参考になった。ありがとう。Justin さん!

凄く出来る人は何が出来ているのか?

 まず、彼の定義で、ものごっついできる奴、つまり天才は何ができるから天才に感じるのか?というと次の2つらしい。

  • 記憶力

  • 深い理解

 記憶力に関しては確かにそうで、よく出てくる Paul も、Pragna もめっちゃくちゃ記憶力が強力である。確かにみんな出来る人は記憶がいい感がある。ただ、記憶に関しては去年読んだ「科学的根拠に基づく最高の勉強法」が決定版で、最近は記憶が苦手という感覚はほぼなくなったと言ってよい。

 まず、ビデオで学んだこと、そして、具体的な対策に入る前に、この戦略を立てるにあたって、ランニングをしている時にふと気づいたことがある。それは、自分を「三流」と思ってはいけないということだ。

自分を「三流」と思う事から脱却する

 これはプライドを持つべきとかそういう話ではなくて、自分の「妥協」を辞めるためだ。今から「一流」にならないと生き残れないとなった時に、「自分は三流だから、戦略でカバーしよう」と思っていたとする。そうしたら、出来なくても「自分は三流なのだから仕方ない」と妥協してしまう。他の例で挙げると、例えばギターを弾いている時に、「自分はプロじゃないから」と思っていると、多少粗いところがあっても、「まぁ、アマチュアとしては上々じゃね?」と妥協してしまうからだ。

クオリティに妥協しないために

 自分が「一流」になりたいのであれば、実際そうなので「三流」と考えていたが、それは一切捨て去ることにした。自信とは根拠のないものだし、Holy spirit もそういってたので、まずはおごらず、「自分は努力すれば一流になることが出来る」と思い込むことにした。ギターも「自分はプロ」と思い込むことにした。すべては一流、プロクオリティに到達するために、自分の妥協をしないためだ。
 また、例えば、自分が一流にならなくてはと思う事で、数式が沢山はいった技術論文も普通に読めて当然と考えるようになるので、そうなれば出来ない場合は無理せずどういうことを理解すればUnderstand出来るようになるかと考えることが出来る。今までは、自分には無理とやる前からあきらめていたようなものだ。

脳にコグニティブ的な負荷をかける

 さて、話を戻して、「記憶力」の話だが、今自分はもうどうやって記憶をしたらいいのかを理解できているし、実際にやろうと思ったら出来る。いつも、Paul や Pragna の無限の記憶力を見て、本当にすごいなぁ、いいなぁ~と思っていた。ビデオでインスパイアされた内容に、「脳にコグニティブ的な負荷をかける」という話があった。私の本でも「議事録をとらずに頭で整理する」というプラクティスを偶然紹介していたが、そういう作戦だ。私はなぜそれが有効なのかわからなかったが、これは「脳に負荷をかけて、脳の処理能力を挙げることにつながる」からだ。

 記憶に関しても、今はすでにメソッドは明確なのだ。確かに今の自分は記憶力は、圧倒的に Paul や、Pragna には及ばない。これが才能の差か…とあきらめるのではなく、自分が学んだ記憶の技術を使い尽くせばよいのではないだろうか?自分たちは受験勉強時代死ぬほど暗記したはずだ。しかもずっと難しい事を。だから、仕事中の事を覚えておくような習慣を身に着けるとよいと考えた。

秀才のように振る舞う習慣

 例えば、仕事終わりに、理解したこと、今日やってることを整理して、思い出すようにする。出来れはまず頭で整理してから、書き出すようにする。翌朝もう一一度思い出すようにしてみるといった具合だ。もし、それでも足りなくても、例えば、自分のタスクの話をするミーティングの前に30分ぐらい時間をとって事前レビューしておくと、自分の記憶力が「良いように」相手には見えるだろう。

 次に「深い理解」確かにすごい人ってなんでもすぐ出来るように感じる。自分は一生懸命やっても、時間かけても、なんかそこが浅い感じがする。その辺が自分が一流と思えない部分だ。つまり、この部分を克服すればよい。ほんまこのビデオありがとうございます。その方法が解説されていた。

 私がこの辺の「深い理解」が凄いなと思うのは Skip Manager の Anirudhだ。彼はなんでもがっつり理解する。そして、理解が深い。マネージャだから自分がやってるとは思えないのに。多分理解が彼みたいになれば、自分に感じていた薄っぺらさが解決できるだろう。

 そのキーポイントは下記の通り。彼によると短期の対策と長期の対策がある。それぞれについて学んだ事、そして、自分にあてはめたものを整理していきたい。

短期の対策

短期の対策は、下記の3つである。

  • 1つづつレベルを上げる

  • 事前学習で構造を知る

  • ノートをとるのを遅らせる

このビデオでは、学生を主に対象にしていると思うので上記の3つだが、これは全然エンジニアに適用できると思う。エンジニアとしてのレベルとしては、一流であれば、論文や、RFCを読んでさっと実装とかそういうのが当然になってくるだろう。つまり、エンジニアにとっては「勉強」は物凄く重要なリテラシになる。

1つづつレベルを上げる

 まず、1つづつレベルを上げることの重要性で、ビデオの中で彼は、いろんな学生を見てきたが、最初に「速く問題をこなす」人は将来あまり成績がよくなくて、よくできる人はことごとく、「最初は遅い」らしい。つまり理解に時間をかける。私の観察と同じようだ。だから最初はゆっくり深く理解だけど、深い理解とは?どうすれば良いだろう。

 1つづつレベルを上げるという例で語られたのはマインドマップの話で、まず、文章ではなく、マインドマップを書き始めるというレベル1、マインドマップを整理して書けるレベル2、そして、マインドマップを簡潔に、直感的で美しく書けるレベル3がある。実はマインドマップレベル1では効果があまりない。だから多くの人がそれで辞めてしまう。でも、レベル2になると効果があがり、2から3に移行するとさらに効果が出るというものらしい。つまり何かをやるときは、たいして効果が出ないという状況、うまくできない状況が普通にあること。でも、一気に3になれないので、この居心地わるい状態を経ないと、レベル3にはなれないので、慌てず、一歩一歩が良いとのことだ。

事前学習で構造を知る

 事前学習で構造を知るというのは、勉強では始めた日が一番重要で、実際の勉強に入る前に、目次やオーバービューを見て、概要をつかんでおくと効率が高くなるらしい。
 自分が技術を覚える際も、それを真似してみようと思って、やり始める前に、オーバービューをマインドマップで整理する癖をつけてみたら良い感じだった。Justinによると、具象と抽象と行き来できるようになって脳の効率が上がるらしい。

ノートをとるのを遅らせる

 ノートをとるのを遅らせるという事に関しては、長期の対策の「コグニティブロード」を高くすることにつながる。ノートをすぐに書いたら実は脳の負荷はそれなりで、考えなくなる。でも頭の中だけで覚えておこう、整理しようと頑張ることで、コグニティブロードが高まる。自分がかつてコグニティブロードを意識して鍛えようと思ったことが無い。もし自分以外もそうだとすれば、これを意識してやれば相当な違いを出せるかもしれない。

 私のチームでも賢いみんなは持ち帰りせずその場で解決しようと頑張るし、その場で覚えようと頑張る。

習慣化したほうが良さげなもの~マインドマップ

 この短期の対策で、習慣化したら良さそうとビデオを見ながら思ったことは、3つで

  • 理解を深めるために、マインドマップを使う

  • 長期的な視点でプランニングする

  • ゆっくり理解して学んで自動化する

まず最初の「マインドマップ」だが、私も昔からADHDと相性が良くて使っていたが、これは「理解を深める」ための最強ツールじゃないかと思うようになってきた。

深い理解をするために必要なこと

 というのも、深い理解をするために必要な事で彼が上げていたのが

  • 関係性を知る

  • グルーピングをする

  • 独立させる

  • 理由を考える (Why)

  • サマライズする

 自分は、いつも「あーわかった」って物事がちょっと浅く理解出来たら、思っていた。でも、理解が深い人周りの人を見てたら、簡単に分かったと言わないし、ものすごく質問もする多分これが私と彼らの大きな違いだと気付いた。

 だから、自分が物事を「簡単に理解できる」と思ったら大間違いで、自分が分かったと思ったら、わかってないぐらいの感じで良いと思った。いままでだと、わかった!と思ったら終わりだったが、その分かったと思ったことに似てる事象に思いをはせたり、どういう使い道をするのだろう、なぜこれは必要?とかいろいろ考えたうえで、グルーピングしたり、関連付けたり、サマライズしたりするのが結局理解を深めるステップのようだ。

 そこまで考えると、実はマインドマップでそれがすべてそろったツールじね?と再発見した。関係性が明確で、グルーピングせざるを得ないし、独立性もある、サマライズして書くしかない、why はプラクティスでカバーだろうか。物凄く相性が良い。ちなみに、これが今回のビデオと自分の思考を整理したものだ。しかも、見返すときに文章より楽だ。

画像
今回の学びのマインドマップ

自分も昔からマインドマップを書いていたが、一つ変えたところが、マインドマップを書いた後、整理をするようになったことだ。昔は、内容が書かれていればいいという程度だったが、理解を深めるために、関連を考えたり、グルーピングをするために、何回もリファクタリングしたり。昔はそういう「きれいにする行動」は無駄と思っていたが、むしろ逆だったようなので、そうするようにしている。人は簡単に物事を理解できない。だから、こねくり回して、整理して、いろんな視点からみて、思いついた疑問を調べて、そういうことをちょっとづつして、理解を深めることが出来る癖が出来る感じがしている。
 このハビットを始めてから、もしかして、行けるのではという実感がそうとうに生まれている。

長期の対策

  • 脳に負担をかける (コグニティブロード)

  • リフレクション

 リフレクションは定期的な振り返りで、これは習慣として定着しているので、自分的には特に変化はない。 

 最初の長期的な観点での、コグニティブロードこれが一番重要なハビットかなとも思う。彼が言う通り、これを鍛えれば「天才は創れる」。

ギター演奏にコグニティブロードを上げるを適用する

 例えばギターで今練習してる、コグニティブロードの上げ方は、今までは、自分は演奏しても、「感覚」で弾いているだけで、今自分はどのコードの上でソロ弾いていて、どの小説の曲の構成のどのあたり、2,4のポケットの位置はどこ、また、弾いているソロの音はコードの構成音のどれ?みたいなことって、なんとなく知ってるけど、弾いている間に意識していることはなかった。なんとなく。いつも。

 でも、それをあえて、全部意識しながら演奏できるように今練習している。ブルースの曲でいうと、最初の12小節だけを繰り返しそれを完璧に出来るように練習してみた。最初はめっちゃ大変だった。まだ、大変だが、だんだん少しづつ出来るようになってきた。スリーコードのブルースを聞くだけで相当なコグニティブロードがある。

 すると、今まで感じたことが無い「コントロール出来ている感じ」と強烈グルーブ付きで感じて、コードの雰囲気を感じられるように変わってきた。これはマジ凄い。
 何十年も「そんなん自分のレベルでは出来ない」と思ってたけど、1小節づつからやったら出来るやん。そしたら演奏がめっちゃ楽しくなってきた。

周りの秀才を理解する

 これを仕事に応用してみる。仕事で、Anirudh 凄いな~ Bala 凄いなぁ~と思ったら、それを言語化して、なぜ凄いと思ったのかを明確化する。それが理解できたら、どういうコグニティブロードをかけたら良いのかと、もう一つは自動化だ。あまたに負荷をかけなくても出来るようにする。

1学んだら5練習して自動化する

 ちなみに Justin 曰く、新しい事を1学んだら5ぐらい練習して、「考えなくても出来るようにする」という事を教えてくれた。多分まさに自分がやらないといけないのはきっとこれだ。
 私は、どうやってコードが書けて理解できたら終わりだったが、そのあとに5倍練習したらどうなるんだろう。
 例えば Bala はめっちゃ良いコードが高速に書ける。コードリーディングも正確かつ高速だ。

コードの読み書きの高速化

 これを達成するためのコグニティブロードと自動化は、例えばこんな感じ

  • 妥協せずコードリーディングする。時間を最初はかけてオッケー

  • 出てくるメソッドなどを暗記するようにしてみる、思い出してみる

  • コードリーディングをして、コードの意図が読み取れるか、なぜそういうコードを書いたのかを考えてみる

  • 似ているコードはあるか、違う書き方はないだろうか?メリットとデメリットはどうなるだろうか?

  • そのコードのブロックを少しづつ速く読めるようにコードリーディングする

  • コードを開かず、コードブロックがどんなだったか思い出してみる

Anirudh の理解力

 まだ、これは試行段階の仮説なので、上手くいくかはわからない。でもやってみようと思う。 Anirudh の強烈な理解力は、彼はわからなかったら質問する。最近は質問しないというのは理解が浅いのだとわかってきた。そういえば研究者の人も良く質問するなぁ。

 余談になるが、最近デプロイメントのレビューを受けることになった時に、私が準備した内容をしゃべっていると、メッセで Anirudh がしゃべりすぎ。相手が質問してくれるのを待つといいよと教えてくれた。日本のレベルでは、説明しすぎではないと思うが、こちらだと、最小限しゃべって質問を待って答えるというスタイルが好まれるようだ。

Anirudh に教えてもらったこと

 後彼は、昔にメンタルモデルが良いといってたので、思考のフレームワークをよくつかって、思考に揺さぶりをかけるのを習慣にしているのかもしれない。自分も昔思考のフレームワークをコンサル時代に学んだので、それを再度使うようにしてみても良いのかもしれない。

質問が出来るようになる方法

 では、なぜ彼らはあんなに沢山質問出来るのだろう。初見であっても、ああ、そうか、これがコグニティブロードだ。つまり、彼らは質問する習慣があるのだろう。質問をしようとすると理解するしかない。つまり質問は簡単ではなく、頑張って、頭働かせてするものなのではないか?自分も質問する癖をつけるのはどうだろうか?自分は無理と思ってたけど、もしかすると彼らも幼少の頃から訓練して身に着けたのかもしれない。

 あと、世界一流エンジニアの Paul はなぜ凄いのだろう。彼は適切なアーキテクチャを一瞬で提案出来て、原因分析はスーパー早くて正確、ものすごく大きなシステムを細部まで正確に把握している。あれは何なんだ…

凄腕のアーキテクトになる方法

 おそらく、彼の経験、そして、アーキテクチャの学習、あとは、そういうものを「考える」コグニティブを鍛える姿勢、理解に一切妥協をしない姿勢。その場で理解する姿勢。ああ、めちゃくちゃコグニティブロードかけてるやん。あと、システムの細部を正確に把握しているのは記憶力では。つまり、自分としては単純に記憶する努力をする。思い出す。

   前回ご紹介したなんでもできる Ken さんの時間管理法は今もやってるけど、自分にめっちゃフィットしている。めっちゃ有効。Consistency 的にはいまいちやけど、自分の場合、納得するまで、やって次に移るはガチで成果出てる感がある。

 優秀な奴ばかりの、うちの組織で、その中でも抜きんでて凄い Nick という人がいる。マジ溜息が出るほど凄い。Paul は「思考」が凄いのだが、彼は、「実践」が凄い。物凄いスピードでめっちゃ複雑なPRを一日に沢山書いたり、ものすごく難しくて長年誰もできなかったことを、あっさりやり遂げたりもう意味が分からない。

凄腕のエンジニアになる方法

 彼を分析すると何なのだろう。まず、彼はテクノロジーがめっちゃくちゃ好きだと感じる。趣味と仕事が一致している感じ。息を吸うようにセンスの良い素敵なツールを使いこなしている。C#についてめっちゃくちゃ奥の方まで理解している。
 だから、C#のライブラリのAPIの内部挙動まで正確に理解している。一度そういう風な姿勢に驚いて何で知ってるん?と聞いたら、「いや、今コード読んだだけやで」と言っていた。

 似たタイプの人としてはしばやんとかが挙げられるけど、こういう人は物事を深く知る事に妥協がなく、それを楽しんでいるのが大きいのかも。彼らのようになるためには、自分で試して、考えて、妥協せず内部が気になるならコード読んでという事を自分のペースでゆっくりしていく一見遠回りな姿勢が5年も続ければ、少し近づけるようになるかもしれない。また、ツールを手になじませる練習をするというのも近づくコツかもしれない。

メンターの Chris の優れた所

 最後に最高にイノベーティブで最高に成功しているけど、そんなに「天才感」が無い Chris はどんなところが凄いのだろう。自分に似ているけど、Strategy は超一流。でも、彼はアーキテクチャやプログラミングに対する理解が深い。提案がセンスがあって適切。

 おそらく、自分は3流と考えず彼のようになれると考える事、そして、彼のようにセンスがあるアーキテクチャや、API デザインの選定をするためには、おそらく学習と、簡単に妥協しない、深い思考かもしれない。知能的な凄さは感じないのだが、彼の場合、彼の行動のすべてが最適解であるのが凄いのだと感じた。
 おそらく、無駄な事をしないとか、使ってもらえるデザインはどんなのかをすごく考えて学んでいると思う。例えば彼は、アプリをデザインするときはデモ駆動。どんなデモを見たいかを考えてデザインすると言ってたし、API の設計は、APIの使い方を先に考えて、めっちゃ使いやすそうな書き方を思い付いたらそういうインターフェイスにするみたい。ポイントを外さないという事は、重要なことは何かを常に考えていると思う。

 自分の周りの凄い人がどう凄いかを考えて、言語化してみた。彼らを真似した行動をいきなりレベル3にはなれないので、彼らのコグニティブロードのかけ方を真似するところから始めよう。最初は出来ないだろうけどそんなもの。トランジションは数年かかるだろう。でもそれで良い。

自分の利点の分析

 逆に自分の優れたところは、戦略的であるところと、このように言語化ができて認識できるところだろう。逆に問題の大半は、アウトカムを出したいがあまり「急ぐ」癖がいろんなところに浸透してしまっているところだろう。この癖を完全に取り除いて、深い理解をするように完全にスタイルチェンジしてみる。あとは新しいことに取り組むのに躊躇が無いというのは、日本人はそういう人多いけど、ここではそうでもないので、ちょっと良いかも。コミュニティが無ければ作るところも自分の良いとこかも。

自分の人生の夢に向かって

 ギターでも片鱗見えてきたし、仕事でも実践していると、かなり手ごたえを感じるので、このままやってみる。首にならなかったらいいなぁ。

自分の人生の夢が叶いますように。

ちなみに、おかげさまで私の本は10万部行くことが出来ました!ありがとうございました!ちょっとベストセラーっぽくて嬉しい。IT系の本で10万部ってあんまりないと思うので、ちょっと嬉しいかも。沢山読んでいただいてありがとうございます!


 

いいなと思ったら応援しよう!

ピックアップされています

#エンジニア 系記事まとめ

  • 1,203本

マガジン2

  • 3,896本

エンジニア

  • 868本

web勉強

  • 69本

Scrap and Build

  • 121本

コメント

8
牛尾 剛
牛尾 剛

まりあさん、シリコンバレーで働いてるとかそれこそ凄いですわ。イタリア系夫良いですね。自分はそんな自信ない方なので、そういう自信ある人いいですよね!

牛尾 剛
牛尾 剛

やまびこさん もしエンジニアやと、astah は前からのお気に入りです。昔はマインドマップ専用のプランとかあったのですが、今は無さげですわ。

Kazuma Ito
Kazuma Ito

うん、覚悟を決める!ということが大事なんだと、改めて思いました!ご紹介にあった「記憶術」の本、勉強に大変役に立ちそうなので、早速購入しました。ありがとうございます。また、この記事を何度も読んでみたいなと思います。

なないもる
なないもる

たまたまこの記事を読みました。色々あったもので、手探りで自分用の方法を考えています。まだ答えをみつけれてませんが参考にします。ありがとうございました。

ログイン または 会員登録 するとコメントできます。
凄いやつになる方法|牛尾 剛
word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word

mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1