私は米国の超大手クラウドベンダーの中の人をやっており、普段はアメリカに住んで気づいたことをブログに記録しているのだが、今回は趣を変えて、日本で出会った凄い人からの学びを書いてみようと思う。

プリンシパルを目指して

前回の下記のブログで、マネージャにならずに、プリンシパルというレベルを目指し始めたので、少しづつ自分のふるまいを変えることにしているが、これはそれの一環だ。

人生最後の大きなチャレンジの戦略を考える｜牛尾　剛 (note.com)

筋肉の豊富なケンさん

　私が日本に居たときの同僚で、ケンさんという人がいる。筋トレ仲間として、筋肉がものすごいので、凄いなと思っていたのだが、彼は筋肉だけではなくプログラミング力もえげつなかったことを覚えている。
　あるハッカソンで普通の人なら１つか２つの機能を試すところを、彼は１０個ぐらい、それもものすごく高度に組み合わせてすごく短い時間に凄いアプリを作った。もう、圧倒的だった。

　そんな彼と最近話したところ、「最近暇なのが良くないので、もっと忙しくなるようにチームを変えた」と言っていた。彼のいたチームは暇なはずなどないのだが、彼曰く「３か月ぐらい時間かけれるんだけど、２週間でおわるんだもん。暇だよ」と本当に自慢気でもなんでもなく、悩んでる様子だった。マジ化け物。

自分の武器を探す

プリンシパルのレベルは半端ないので、地道な努力と積み重ねだけでなく、自分の強みを見つけるのが重要だと思う。上司のプラグナもみんなスタイル違うから、君の良いところを見つけるべきと言われた。また、先日たまたまスキップマネージャのAnirud に、日本のソフトウェアの現場はあまりよくないという話をしていたときに、彼が「でも、日本の職場やエンジニアにだっていいところはあるだろう？」と聞かれて正直ことばに詰まった。
　自分たちのいいところっていったい何だろう？世界に通用することってなんだろう？

ケンさんのメソッド

　日本人にもたくさん世界に通用しまくる人はいる。自分は才能無いけど海外のプログラマがやってるのを見かけたことないけど、日本人のイケてるエンジニアが結構やっていることがある。それは例えば、Azureの資格の完全制覇とかだ。めっちゃくちゃたくさん資格あるけど、それ全どりしている人がちょくちょくいる。意味がわからないけど、海外では少なくとも私のまわりでは見かけないタレントだ。
　ケンさんもその一人で、しょっちゅうAzureとかの資格を取っていた。だから、彼のメソッドを聞いてみることにした。

　彼曰く、彼のメソッドは次の通り。学ぶトピックを決める。例えば Storage Account。でどうするかというと、、、

• Storage Account に関する公式ドキュメントを全部読む

• それに関するビデオを１０個ぐらい見る

• コミュニティのカンファレンスでそのトピックに関して発表する

• 最後に資格を取る

という作戦らしい。彼曰く、それで理解が３０％ぐらいと言っていた。結構がっつり詳細まで調べてからしかコード書かないですよと言っている。１週間ぐらい勉強に時間を使うようだ。彼にいろいろ質問をして、私も趣味で書いているプログラムがあるので、今までと考え方を変えて ケンさん方式でやってみることにした。

ケンさんメソッドの実践

　私のケースでは、足りないことばかりなので、Azure SDK の認証部分ということをターゲットに調査をすることにした。思えば今までは「早く終えなければ」という思いから、理解が中途半端だった気がするが、この方式に切り替えてから、「公式ドキュメントを全部読む」作戦の有効性がまずわかってきた。これによって、設計が良くなる。なぜなら、全機能を覚えてないかもしれないけど、一通り読んでいるので、「こういう機能がある」とすでに何となくでも把握できる。
　だから、設計を考えるときに、「今のライブラリの構成から行くと、あの方法でやったらベストだから、その方法で行こう」という判断がしやすくなったし、車輪の再発明的なものが激減している気がする。こちらではコミュニティがあまり盛んではないので、それに変えて「満足するまで徹底的にしらべてブログを書く」にすることにした。

　スピードを置いておいて、理解中心でゆっくり調べながら公式を読んでいるだけでも相当知識が付く感じはする。わからないことは、しらべたり、GPTに聞いてから原著に当たったり、チュートリアル部分は自分もコードを書いてアレンジしたり、デコンパイルしたり、ライブラリのリポジトリをクローンしてコードを読んだりしながら、理解して、ピアノを弾くようにコードが書けるように練習している。時間はかかるが、自分の 「コンフィデンス」がかなり増している気がする。明確にどの方法でやるのが正解か分かる。
　そういえばイケてる技術者の人が良くＡＰＩリファレンス全部見るとか言ってたよな。

　まだ始めたばかりで、このブログは自分が忘れないように思い出して書いているため、自分に向いているかわからないが、これやればかなり抜きんでたコーディング力になりそうな気がしている。やっぱ筋肉凄いわ。

ヤクの毛がりに対応する

さて、この方法はコードの前に徹底的に調べる方法なので、フォーカスしているトピックだけど、チュートリアルで出てきたインターフェイスや、ツールを使ったことが無くて、そこを調べると、そこからまた知らないことが出てきて、、、、という無限ループに陥ることがある。そういう時はケンさん曰く

と言っていた。

クリスのアイデア

クリスにはメンタリングセッションで前回すでにたくさん素晴らしいアドバイスをいただいているが、今回は、プログラミングのスピードアップに関するアドバイスを求めて、ケンさんのメソッドを実施することもお話してみた。するとかなり好感触だった。

あと、加えて彼が言っていたのは、「まず、自分が何が遅いのかを把握しないといけないよ」と言ってくれた。確かに自分は「遅い」という自覚と事実があるが、「どこが遅い」かはいまいち把握していない。だから、躓いた部分を記録していこうと思う。

　さらに、彼はコードを前にしていると、「設計」に時間がかかることが多いよ。いまいちな設計でPR作ってやり直して、とかやってたら時間がかかるじゃない？
　そういう時は「コード」を離れて「設計」した方が良い。と言ってくれた。最近のテクノロジーでは、設計とコードが混然一体となっているので、明確な設計フェーズとかは無いし無い方が良いと思うが、自分のタスクの中でホワイトボードや、紙を使って、設計を先に考えるのはいいよ。ＴＤＤも同じノリだよね。と言っていた。
　また、設計をするには、要件が重要なので、それをリストアップをするとよいとのこと。確かにＴＤＤでも Kent Beck が TODO リストを書いてそれを消しながら作業を進めていた。

　他にもクリスはツールのサポートをお勧めとしていた。Copilot Chat をもっと有効活用すること。Copilot Chat はサジェスチョンが間違ってることも多いが、自分が思っても無かったようなソリューションを出すことがあるので、ブレインストーミングにも有効とのこと。確かに。だから、自分ももっと頻繁に、Copilot Chat と会話するようになってきた。
　そして、効率が上がるようなツールはどんどん使っていくことをお勧めしていた。

　私はまだ、どこが遅いとかのボトルネックは見えていないが、これもメンタリングセッションを記憶するために、ここに出力しておこう。

才能ある人に対する才能のない自分の戦略

　実施してみた結果で変更する可能性もあるが、プリンシパルへの一歩として、上記のメソッドを実践してみたい。自分の作戦としては、日本人以外の人がやらないような「日本人」の素晴らしい技術者の特徴を真似する。（多分彼らより自分は日本人だから向いているので差別化になるかも）そして、自分の技術的な強みである TDD や DevOps 系技術を極める事。そして、こちらの人は自分の専門にフォーカスするので、複数のコンポーネントにまたがって全体を詳細に理解するとか、こっちの人がいかにもやらなさそうなポイントで差別化をしてみることにした。

　さて、効果あるかどうか、一年、いや三か月後のお楽しみだ。