この流れです。

前提

基本的に自分はGoのサーバーサイドが主戦場で、カンファレンスにはよく顔を出します。最近はOSSを公開すればいい感じにGithub Trendsの上の方にきて目立つような、芸人っぽいムーブができるようになりました。

ですが、直近プライベートではGo以外にTypeScript(Next.js) でGraphQLのクライアント書いたり、仕事だと前はSwiftやらC++やらPerlやら色々使っていたので、他の方と比べると広く浅い経歴です。

また、大学に入ってから学習を始めましたし、当時はドットインストールが出始めたくらいで、基本的には書籍で勉強していました。大学では授業でFORTRANの授業を取りました。内容は意味わからなかったので同級生に寄生してました。

Progateとかプログラミングスクールとかには頼ってませんでした。無かったので...。なので、「幼少期からBASICを触っていました！」とか言われると、この職業を選んでしまってすいませんという気持ちになります。

また、実践の機会は大学の2年の中頃からアルバイトをさせていただいて、そこで見習いとして色々な会社で勉強させてもらいました。

技術で詰まったこと、時系列順。

技術ベースで切り分けられるほど、綺麗に技術を乗り換えてきたわけではないので、「どのタイミングでどんな困り方をしたか」という書き方をしたいと思います。

完全な混乱期

勉強し始めて1年くらいは、本当に何もわかってなかったと言えます。数年経ってもひどかったですが、1年目は複雑怪奇でした。才能は皆無だったと言えます。

ブロックだのスコープだのポインタだのデリゲートだの、住所を指差す人間だの、クラスは鋳型でインスタンスはその鋳型からできた鯛焼きだの、本当に勘弁してくれと思っていました。何食ったら人間が住所を指さしたくなるんだ？鯛焼きは食うものであり、初期化されるものではない。

「自分が実現したい機能」を「自分にわかるレベルから、徐々に専門用語に関連づけて説明してくれる人」が周りに誰もいなかったことが非常に辛かったです。

それでも、手探りでrails newしちゃえば動いて謎のブログができちゃうんですよね。だから自分がどれくらい無知なのかを掴めなかったし、「ググったらわかる」「公式ドキュメントがある」って言われてもキーワードが浮かばないので何もできなかったです。読み解こうと思っても、英語学習のように自分が理解できるレベルの解説が見当たりませんでした。

一番最悪だった思い出は、アルバイト先でiOSアプリを（まともなコードを書いたことが一度も無かったのですが）書くことになり、社員の方に質問しに行ったときのことです。「ああ、ここがデリゲートされてないね。あとはAppleの公式のドキュメント読めばわかる」「ポインタがどっかでnilになってるからデバッグしてみたら？」という返事が返ってきて、その時に継承だのデリゲートだのがまともにわかっていなかった自分は、Objective-C、ひいてはネイティブアプリ開発に3年くらいトラウマを抱えることになりました。（当時の社員さんは僕がそこまで理解できないとは思っていなかったのでしょうし、単純に忙しくもあったのでしょう）

この時期を振り返ると、早期に言語化能力が高く、レベルに応じて抽象度を調整して解説してくれるメンターが獲得できた奴が勝ちなのだ、と思います。

レールから脱出できない期

アルバイトでコードを書かせてもらって、徐々にPR出せるようになったのは2年くらい経ってからです。すごく時間がかかりましたね。

当時はSNS戦国時代。やれソーシャルネットワークだなんやかんやで、どこもかしこもrails new。そうするとミーハーな僕は自然とRails触っちゃうんですが、まともに素地ができてない人間がRailsを書くと、責務とか意識せずなんとなく動くコードを量産してしまうことは明白でした。

また、Railsの、様々な苦難が隠されたMVCに乗っかってコードを書くと、それ以外のアーキテクチャやデザインパターンを理解する方法が全くわかりませんでした。でも、サンプルコードはRailsだと結構見つかってしまうので、そのコピペで「意外と動くじゃん！」という自己満足感を得ていました。書いててめちゃ危険だったなと思います。

実際のところ、ActiveRecordが裏側でどんなクエリを吐くのか、それを実行するためのコードがどこに書かれているのか、ルーティングはどのようにマッピングされていくのか、何一つとしてわかっていなかったです。

そういう輩がサービス層への処理の分割をしていったりすると、「そのためのフレームワークを探す」ことから始めてしまうものです。コンテキスト境界を定義するのは自分ではなくフレームワークの役目だと、逃げの戦略に走ってしまうという、まさしくアンチパターン野郎だったと言えます。

そのため、業務で扱うコードで「デザインパターンを適用して責務を綺麗に分割しましょう」とか言われても発想できませんでしたし、ゴリゴリのDSLでエラーが出た時に追う能力などは全くついていませんでした。

OSSコンプレックス期

ちょっとだけ他の言語でも実装できるようになって、専攻の都合でPythonを書くバイトを教授から請負ったり、趣味でGoも触ったりしていました。

ただ、OSSのコードを読んで理解しようとしても、mapやreduceを駆使してお洒落に書いてあるコードや、カンファレンスでよく話されてるトピック、公開されているライブラリのどれをみても、自分が一から発想できる気がしませんでした。

そういう期間が1年くらい続いたため、「OSSに貢献する」「カンファレンスに出る」というエンジニアとしての"ステータス"のような面に強い憧れ、ないしコンプレックスを持つようになりました。

立ち直り期

社会人の2年目になるくらいまでは本当に技術的には実力が乏しく、社会人2, 3年目に一気にプライベートの開発が功を奏して技術力を伸ばせたな、と思っています。課題を設定して解決するというサイクルをどれだけ踏んだかが重要だと考えてまして、そう言う意味ではプライベートの方がレベル設定が柔軟にできたため、役に立ったと言えます。

・動画配信基盤一式
・入力時の文字コードを自動判定してエンコードするツール
・自前のスクレイピングフレームワーク
・DBマイグレーションツール
・Google Cloud Datastoreのラッパークライアント
・静的解析ツール
・テスト用のモック生成フレームワーク

などを作り、そこからやっとカンファレンスとかにも出ても事故はないかな、という開発ができるようになりました。一歩進んでGoにコミットしたり、自作のOSSを海外向けに公開して自信をつけたりしました。その頃からようやく、言語自体でどこにも資料が乗ってないバグや不明点に遭遇し始め、Issueでメンテナに問い合わせるのが当たり前のようになってきました。

やってよかったこと

上記の問題点以外にも色々ありましたが、乗り越えるためにやってよかったことを書きます。

簡単なAPIをできるだけプレーンな書き方で実装する

フレームワークを使わずに何かを実装する経験を早期に積むべきでした。新卒のときに時間を頂いて取り組めたことは後々資産として効いてきたと思います。

こういう経験があったせいか、GoのAPIは基本的にnet/httpで書くべきという原理主義的発想はそこそこ好みだったりします。また、テストフレームワークやプロファイラなど、テーマを決めて定期的にホットなOSSを覗くようにしたり、HackerNewsで話題になったライブラリのコアな機能だけでもコードに目を通しておくとか、そういうことをしていると他のところでもプレーンな書き方ができるようになるな、と感じます。

毎日コードを書き、難易度と規模を徐々に上げる

もう4年以上毎日コードを書き続けてコミットしていますが、継続は力なりという言葉はある種真実だと思います。ただ、継続の過程でレベルを徐々に上げて、「次は別の基盤を使ってみよう」「今実装してる機能はライブラリが無かったから、副産物として公開しよう、その成果を発表しよう」と、調整をかけ続けているのがうまく効いてると思います。

また、この過程ではほぼ写経をしていません。写経不要論者です。もちろん初期はしていましたが、表現したいものに対してどんなパーツを使えばいいか気づく能力は、写経によって培われると全く思えず、途中からやめました。ただ惰性で書くよりも直近解決できない問題の参考例を何十個も探したりIssueを追うことに時間をかけることにしています。

時流に流され過ぎない

Reactがワイワイ言われはじめて僕が書こうとしたのは、確か0.16.xくらいのバージョンだった気がしていて、その頃はライフサイクルも結構おぼつかなかった記憶があります。Fluxのフレームワークが群雄割拠していた時期だったので、それを追うので精一杯になってしまいました。その間技術力が高まっていないことと、自分はJavaScriptを専門で追うほどの覚悟はないな、と感じて距離を取りました。

これは結果的に良かったと思っていて、今改めてJSフロントエンドを触っても、以前ほどのカオスさは感じません。自分が主戦場としない場所で、"技術に使われている"ような状況を自覚したらすぐさま距離を取り、別の言語などで素地を整える方に時間を割いた方がいいと思います。（そういう意味で変化が緩やかなGoはオススメですよ！）

RFCを読む

ある程度の時期を過ぎたら、コードそのものや公式ドキュメントを読むのはあると思います。僕自身は、新卒の時に半強制的にOIDC周りやHTTPのRFCに触れ続ける（内容ほぼわかってなかったですが）時期があったのは良かったと思っています。

「認証認可などの周辺も含めて、あらゆるプロトコルは全て人と人のコミュニケーションが原型なのだから、対話に置き換えてみるといいんだよ」と言ってくださった先輩社員の言葉は今でも忘れることができません。自分が書こうとしているものの登場人物を日本語で整理するようにしています。

運用を前提としたプライベートプロジェクトを持つ

これはmizchiさんも書いていたことですが、小さいプロジェクトを自分で持っておくべきだと思います。僕の場合は運用前提で、予算や速度、誰かに移譲する場合も加味して技術選定もして、フロントもバックエンドも全部書いてリリースまで持っていくので、実験の要素は薄いのですが、許される範囲で回り道するための学習機会を自分で用意するのは大切だと思います。

また、例えば直近だとHooksゴリゴリに活用してNext.jsでフロントエンドを書いていて、GraphQLのGoのサーバーとTypeScriptのクライアント、というまあまあな堅実な構成でコードを書いているのですが、「将来的に絶対使う人増えるのに、あんまりノウハウも出てなさそうだし発表とかブログに使えそうだな」という当たりが数個付けられるような技術選定をするのはありかなと思います。

たくさんの師匠を持つ

僕の1番の心の師匠は、リブセンスという会社でアルバイトをしていたときのメンターの方です。長いこと連絡を取っていないですが、大変な人格者であり解説能力が非常に高い方でした。あの人がいたから、「エンジニアも悪い人といい人がいる」と確信しつづけられました。何か辛いことがあっても、そういう確信があることは救いになります。

心の支えという意味合いだけでなく、実際の技術解決という意味でも師匠を持っておくのは大切です。

コミュニティに入り込んだり、DMで面識のない有名な技術者に、特定の分野についての質問を投げることは、非常に大切だと思っています。具体的に言うとNode.js界隈の古川さんには大変お世話になりました。急に長文をSlackで送りつけてくる学生は、不審に思えたことでしょう。

一定程度エッヂが立った技術を使う場合、標準ライブラリの実装者とその他数名しかノウハウを公開してない場合があります。具体的に顕著だったのは、Goの静的解析でした。マジで日本語のドキュメントが一番充実してるのには笑います。人によっては聞く相手を見つけないと何もわからないと思います。

よりエッヂが立って活躍している人の集まりほど、人格者の割合が多く、丁寧に教えてくださいます。もちろん時間をいただくのですから、前提となる状況となぜ連絡したかとか、コミュニケーションとして当たり前のことは共有すべきですが、だいたいが教えてくれます。悩んだらキャリアのことでも技術でもなんでも聞いてみると良さそうです。DHHにエンジニアになるか迷ってるってメールして、答えてくださったときは笑いました。純粋にうれしかったって意味で。

おわりに

こういうポストを目にするたび、「みんないつも綺麗な下積みをしているな、なんで始めて数ヶ月とか数週間で用語を理解しているんだろう」と不思議に思っていました。

カンファレンスに出たって、憧れていた言語へのコミットをしたって、その局所的な事例以外はどうしようもない回り道をしていた気がします。今ではあまり口に出しませんが、文系コンプレックスも強かったです。同じような回り道をしている人があれば、少しだけ引っ張り戻すくらいの力添えができればいいな、といつも思いますし、同じような考えを持つ人のドロドロした話を聞きたいな、と思ってもいます。