今まで自分が一緒に仕事した人で、最も凄いとおもったのは、しばやん(@shibayan) さんで、何回かご一緒させていただいているが、あらゆる面でなんであんなに出来るんだろう？と思う。彼と一緒に仕事をしていると、「つまる」ということがほぼ存在しない。問題解決にかかる時間がものすごく短くて、しばやんさんにとって３０分つまると、相当はまっているという感覚らしい（私は数日のオーダーなんすけど、、、orz) 私の師匠のかずきさんとあわせて、２人のプログラマとしての力は、海外の同僚とくらべても突出している。
ありがたいことに、ハックフェストでご一緒させていただいて、いくつか気づいたことを整理したい。私が観察したことに対しての考察が、間違っているのでは？と思う場合は是非コメントをいただきたいと思います。
1. コードを読み取るスピードと正確さ
しばやんさんを観察していると、ドキュメントやサンプルがあろうが、世の中に情報がでてようが、なかろうが、問題を解決して、方針を決定できるように見える。
観察した事実
しばやんさんを見ていると、ドキュメントを読んで解決するというより、コードを読んで、プログラムの仕様や意図を正確に読み解いている。ReShaperや、リファレンスソースを読んでいる。あるライブラリが存在するか否かという場面でも、私はドキュメントやGitHubリポをなどをざっと見て、「無い」と決めつけてしまったものを、しばやんさんは、GitHub のプルリクエストを見て、「ここにあるよ」と一瞬で教えててくれたりする。しばやんさん本人もコードが一番正確とお話しされていた。なんでそんなことができるの？と聞くと、うまくあたりがつけられるのかな？とお話しされていた。
考察
しばやんさんは、きっと、コードを読んで、その意図を正確に読み取る力があると思われる。それをプログラミングのために、楽しんで毎日やっているので、高速化していると思われる。PRなどは、キーワードで検索して、普段から、よく読まれているのではないだろうか？
一歩近づくための対策
ドキュメントを読んでも見つからない、わからない、もしくは、ドキュメントがあるときも自分が把握していない箇所はコードを読む癖をつけるといいかもしれない。どれか一つのリポジトリに限定して、issueやPullRequest、そして、そのコードを読むようにすると、いいかもしれない。とにかくコードを読む力が大きなキーの気がするので、それに慣れるためには、英語のように、多読、文法の理解、自分でも書いてみるなどをしてみる。あとは、それも楽しんでやることかもしれない。しばやんさんは私が見逃してしまうような、小さなワーニングや、ちょっとした動作にも疑問をもって問題を解決されておられた。
他の速さの項目に関しては、「すでに試したことがあるから」ということもあるかもしれない。新しい技術をためしたら、簡単でもいいので試して、触ってみる、そして、疑問があるところは、自分で遊んでみるのがいいかもしれない。
2. 作者の意図したコードを書く力
私だったら、作者の意図するコードを書くためには、ドキュメントやリファレンス、サンプルなどがないときつい場面でも、コードのみで作者が意図するコードが書ける。
観察した事実
自分と、しばやんさんが同時に同じソリューションでスパイクをしたとき、しばやんさんのは動いて、私のは動かなかった。一人でやっていたら、「できない」と結論付けしているかもしれかった。彼はコードを読んで、「このように動作するはず」「このように実装すればいいはず」というあたりをつけて実装していた。また、私だったら「できる」解決策で、汚いコードを書いていたような場面でも、しばやんさんが書いたコードは、常にきれいで、作者の意図すると思われるコードの使い方をしていた
考察
これも、最初のと同じだが、コードを正確に読み取る力が大きいように感じた。しかし、たぶん今の私が同じことをしても、たぶんうまくコードが読み取れないだろう。（実際に私も真似してコードは読んでいる）おそらく、しばやんさんがコードを読んだときに把握できる解像度と、わたしの解像度が違うからかもしれない。おそらくそれは、「理解」の差かもしれないし、作者の意図がどうだったのか？と考える癖かもしれない。正直よくわからない。
一歩ちかづくための対策
これもコードを読むということになるのだが、挙動を理解するというところから、一歩深めて、アーキテクチャ、クラスのロール、役割、作者がどういう意図で使ってほしいと思ったのかを読み取るよう意識するのがいいのかもしれない。また、コードの読みがしばやん先生みたいに出来るはずもないので、ゆっくりから、焦らず、しかし、正確に読むように努力する。
3. アーキテクチャの正確な理解と応用
しばやんさんは、AppServiceなどの基盤の内部の仕組みも詳しく知っている。それだけでなく、問題が発生したときに、その知識を、問題解決にむすびつけることができる
観察した事実
FunctionAppのプロキシの挙動で、一緒に構築しているときに、スロットA、Bに分割して、DNSのCNAMEで、AからBにルーティングを変更しても、振る舞いがかわらなかった。キャッシュを疑って、クロームや、クロームのネットワークツール、シークレットブラウザ、Curlなどを試したが、切り替わらない。しばやんさんは、突然閃いて、内部アーキテクチャを考えると、スロットA,Bは、同一IPアドレスであり、そのフロントのロードバランサが、リクエストURLを見て、振り分けているというアーキテクチャなので、CNAMEをつかって切り替えても、当然のごとく切り替わらない（同じリクエストURLだから）。AppServiceは、ScaleUnitに分割されており、それごとにIPを持つので、違うスケールユニットに割り当てられないと、IPがかわりようがないので、解決のためには、別のロケーションにすると、確実に違うスケールユニットに割り当てられるはずと推定し、まさにそのとおりだった。
考察
スケールユニットの存在は私もしっていたが、上記のような細かい部分（IPの割り当てなど）は把握していなかった。しばやんさんは、そういう部分もしっかり理解されおられたうえに、自分がもし仮に知っていたら、この結論を導けたかわからない。小さなワーニングや、画面のちょっとしたメッセージなどにしばやんさんは興味をもって、問題を解決していたが、これと同じで、自分では、IPの割り当てとか聞いても意識しなかっただろうけど、かれにはどうそれが効いてくるかが見えているのかもしれない。
一歩近づくための対策
アーキテクチャを学ぶ時が、それが実践になったら、どういうときにそれが影響するのかの思考実験をするといいいかもしれない。また、問題にあたったときに、絵をかいてみて、自分が理解できていない部分を明確にして、その部分を聞いてみるなりして、理解するとよいかもしれない。
4. 問題解決の高速さ
しばやんさんは、問題解決がとてつもなく速い。一緒にやっていると、つまるという場面が存在せず、時間がかかっている場面でも、「つねに進捗している」感がある。
観察した事実
しばやんさんは、画面のメッセージの小さな変化に敏感だ。FunctionAppのホストが立ち上がらないときも、私が気づかなかった、ランタイムバージョンのところのバージョンが出てなくて、読み取り中ですになっているとか、そういうのや、小さなワーニングや、ログメッセージから、起こっていることを正確に把握していた。
行動がすべて「意図」をもっており、「わからないけど、これが、うごかなかったから、この方法でやってみよう」といったような行き当たりばったりの解決は決して取らない。コードを速やかに読んで、わからない場合は、診断ログを自作して、それでログとシステムの振る舞いを観察して、意図をもった実験を繰り返して、問題に一歩一歩近づいていた。また、無駄な動きがすくなく、何回も同じようなことを試すようなことはしない。しばやんさんが私に「このようにテストしてください」といった指示にすべて意図が含まれている。
一つの例として、DNSのキャッシュクリアをテストしているときに、「15秒おきに、POSTMANでリクエストを送ってて2分でキャッシュクリアされるか見てみましょう。2分ぐらいほっておいて、もう一度リクエストをためしてみましょう。」というご指示をいただいた。
後から考えると、このテストで.NetCoreのDNSキャッシュのクリアの挙動のうち、Keep Aliveが影響しているか？ということと、キャッシュのクリアのコードが正確に動いているか？の２つを同時にテスト出来ている。私の端末ではうごかなかったので、診断ログを仕込んで、プールの開放がちゃんとされているかを調査し、問題を解決した。自分だったらそのログを入れようともおもわなかったし、ログを見ても、プールの開放がされていないという問題にきづいたかもはなはだ疑問だ。ログが見にくかったらフィルターして、見やすくもしていた。じぶんだったら、フィルターをしようとも思ってないだろう。
考察
私の場合、動かないから違う方法みたいな「理解を前提としない」スパイクが多いが、しばやんさんは「コードで理解（仮説の場合もある）」 -> 「意図をもった振る舞いの確認」を積み重ねて問題を解決しているように思えた。もちろん思った通り動かない時があるが、その時でも、次の仮説を立て、検証していた。つまり、先にコードを読んで、こう動くはずとあたりを立てたのち、それを裏付けるようなテストを実施するとよいかもしれない。ログメッセージの読み解きは、数をすくなくして、Overwhelmed しないようにして、ログメッセージをちゃんと読むようにするとよいかも。
近づくための一歩
ここでもやはりコードを先に読んで「理解したうえでテストする」癖をつけるのが重要であり、その理解したことを裏付けるために、テストをするのが正しそうだ。ログメッセージも、全部読む必要はないので、要らない部分はフィルタして、出てくる部分に関してはログを時間をかかっても読む癖をつけると、よいメッセージに気づけるようになるかもしれない。またコードを読んでいると、ログがどこで出ているかわかるので、何を確認したいかを読み解けるかもしれない。
まとめ
こうやって観察してみると、プログラミングとその問題解決には、次の３つの行動が重要に感じた
- コードを読む
- 理解する
- 理解を裏付ける行動をする、理解していないのに行動しない
多分、一歩ちかづくためには、コードを読む練習だ簡単なところから、一歩づつ、PullRequestぐらいから読んでいくのがいいかもしれない。一歩一歩。
たまたま、ご一緒させていただいて、最高の背中を見せてくれたしばやんさん、そして、それをオーガナイズしてくれた三宅さんには、感謝しかありません。これからもまたハックしましょう！ほんま最高です！
追記
しばやんさん本人によると、しくみを知りたい欲が強くて、子供のころはすぐ分解して怒られたりしたそうです。自分も知りたい欲がありますが、アウトカムを出す欲のほうが強いので妨げになっているかも。