Findy Engineer Lab

エンジニアの"ちょい先"を考えるメディア

楽しさも怖さも成長の糧になる。独学からスタートしたフロントエンドエンジニアとしてのキャリア

2016 年 HTML5 カンファレンスでの講演

はじめまして、小林(@koba04)です。現在はソフトウェアエンジニアとしてサイボウズで週4日、SmartHR で週1日働いています。2021 年 3 月に東京から静岡県の富士市に移住してフルリモートワークという働き方をしています。OSS では React 関連のライブラリのメンテナンスなどを行っています。

この記事では、私がこれまでのキャリアで Web の面白さを感じソフトウェアエンジニアとして働き始め、フロントエンドエンジニアとして働くようになる中で考えたことや大切にしていることを紹介します。

Web エンジニアとして働くということ

私が Web の面白さを感じるようになったのは、好きな音楽を伝えようと始めたブログやホームページ作成がきっかけでした。誰の許可を得る必要もなく自分の書いたものを公開でき、それに対する反応がある世界。今では当たり前のことですが、当時はとても興奮したことを覚えています。 また、同時に仕事で使っていたシステムの刷新があり、最初はとても使いづらかったシステムが少しずつ使いやすくなっていくことを体験して、システムを作る仕事も面白そうだなと感じたこともきっかけのひとつです。

そのような経験を通じて、システムを作ることを仕事にするにはどうすればいいのだろうと考え始め、独学で勉強を始めました。大学は文系でありシステム開発に関する基礎的な知識が全くなかったこともあり、最初は IPA(独立行政法人 情報処理推進機構)が実施している試験の勉強から開始しました。それと同時にプログラミング言語として Java の勉強を始めました。この頃に学んだ内容は、基礎として今でも役に立っていると感じます。

独学での学習を続けた後、開発未経験でも雇ってくれる会社を探して転職しました。この際、ずっと住んでいた関西ではなく東京で働くことにしました。面接の度に東京へ行く必要があり大変でしたが、せっかく働くなら東京でという思いと、これまで積み上げてきたものを捨ててイチからやるぞという気持ちからでした。

学べば学ぶほど強まった、知らないことへの怖さ

最初に入った会社は小さな SIer で、業務を通じてプログラミング以外にもシステム開発全般を学びました。当然ですが最初は知らないことばかりで、学ばせてもらっているという気持ちが強くありました。結果的にこの気持ちはこの会社に所属していた約 5 年間ずっと変わりませんでした。

また、仕事をすることに対して常に「怖い」という気持ちがありました。この「怖い」という気持ちは任された仕事が全くできなかったらどうしようという気持ちから来ていました。当初、独学で学び知らないことだらけな状態によりこの気持ちはもたらされていると考えていましたが、ここからソフトウェアエンジニアとして働いていく中でずっと持ち続けることになります。

「怖い」という気持ちを払拭するために、休日もプログラミングや IPA の試験のための勉強をしました。東京に1人で出てきてほとんど知り合いもいない状況だったので、勉強するための時間を作りやすいことは幸運だったと、振り返ってみると感じます。ですが「怖い」という気持ちを払拭するために学べば学ぶほど「怖い」気持ちは強くなっていきました。それは、何かを学べば学ぶほど自分が知らないことに対する認知が広がり、自分が何も知らないということを再認識する結果になっていたからでした。

多くの出会いを通じて知った、コードを書くことの楽しさ

一方、コードを書くことに対する楽しさも少しずつ感じるようになりました。きっかけは勉強会でした。当時は Perl を主に使っていたため、 Perl 関連を中心にいくつかの勉強会に参加しました。勉強会を通じて少しずつ知り合いも増えてくる中で、すごい人たちに出会えたのは本当に幸運でした。この出会いを通じて、その人たちの技術的なすごさはもちろんですが、何より技術を楽しんでいる姿に一番刺激を受けました。刺激を受けた結果 LT で発表したりブログを書いたりと、プログラミングとアウトプットが楽しいと感じるようになってきた時期でした。

そして、もっとコードを書きたいという気持ちが強くなり、自社サービスをやっている会社を中心に転職活動をしました。この時の転職活動が一番大変でした。おそらく 10 社以上は落ちました。転職活動は苦労しましたが、幸運にも自社サービスを作っている会社への採用が決まったのです。コードを書くことに集中できる環境での仕事は本当に刺激的で、日々多くの学びがありました。

この時期は優秀な同僚に囲まれついていけるのかという気持ちや、要件をちゃんと実装できるのかという「怖さ」がありました。好き・楽しいというポジティブな気持ちだけでなく、恐怖を払拭するために学習していた部分も少なからずありました。一方、仕事や環境に慣れて「怖さ」のない状態が続くと、別の「怖さ」を感じるようになったのです。これは持っている能力の範囲で同じことを続けた結果としての、将来に対する「怖さ」でした。そのため、「怖い」という気持ちはこれからもずっと持ち続けるんだろうなと感じました。

Perl から学んだ技術との向き合い方

Perl には TMTOWTDI(There's more than one way to do it、やり方はひとつじゃない)というスローガンがあります。Perl は文法の自由度が高いため、書く人のスキルや言語に対する理解度によってコードの可読性が大きく変わります。そのため、Perl という言語を通じてコードの可読性を強く意識するようになりました。例えば、変数名や関数への切り出し、制御構文の使い分けといった基本的な部分です。これらは他のプログラミング言語にも適用可能です。

Perl では日本にも多くの著名なライブラリの開発者がいます。勉強会などでライブラリ開発者と直接話すうちに OSS を身近なものと感じるようになり、OSS 活動に対するハードルも下がりました。 また、stfuawsc(Shut the fxxk up and write some code、うだうだ言ってないでコードを書け)という言葉も Perl を通じて知りました。この言葉は書いたコードをオープンにすることに対して抵抗があった自分の背中を押してくれました。

Perl からは、実装をシンプルに保つことと、OSS 活動は遠い世界の話ではないことを学びました。

インプットするためにアウトプットする

アウトプットをするようになることで、アウトプットとインプットは表裏一体であることを学びました。最初はアウトプットすることに対する怖さがありましたが、一次情報など事実に基づいて書くことにより怖さを払拭しました。結果的に曖昧な部分や疑問を感じた部分に対してさらに調べるようになり、インプットの質が明らかに変わりました。 また、アウトプットへの意識があることでこれまで以上にインプットへ意識が向くようになりました。技術的なインプットとアウトプットは、呼吸のようにバランスをとることが重要なのです。

アウトプットをすることの利点は他にもあります。それはアウトプットを見た人からさらなるインプットやフィードバックがあることです。これによりアウトプットをさらに深めることができます。 自分が学んだことをそのままアウトプットすることはもったいないと感じる人もいるでしょう。しかしながら、学んだことの結果を共有しても、それを得るまでの過程での経験は自分の中にしかないものです。アウトプットを見た人があなたと同じ学びを得られるわけではありません。そのため、アウトプットは出し惜しみせず行うことが大事です。

OSSの楽しさと学びがチャンスをもたらす

フロントエンドという未開拓地

私がフロントエンド開発を担当するようになった 2010 年当時は、ガラケーからスマートフォンへの移行時期でした。スマートフォン向けのアプリケーションを Web 技術で作るために、シングルページアプリケーション(SPA)の開発を担うようになったことは、私にとってのターニングポイントでした。 それまではサーバーサイド中心に開発を担当していたため、SPA を作るための知識及び経験はありませんでした。また、当時はまだ React や Vue など SPA を作るための材料が整っておらず、Backbone.js などのフレームワークを用いて自分で View の初期化や破棄を管理する状況でした。そのため、正解がわからない状態で学びながら開発を続けていました。

業務としてはサーバーサイドとフロントエンドのどちらも担当していましたが、興味としてはフロントエンドのほうに向きつつありました。振り返ると 2014 〜 2016 年頃のフロントエンドは大きな転換期でした。現在では当たり前になっている宣言的 UI やモジュールバンドラ、非同期処理、型チェックなどに関連してさまざまなアイデアが生まれたタイミングだったのです。そのため、技術面で日々大きな刺激を受けながら開発を楽しむことができました。

React との出会いをどうチャンスにつなげたのか

さまざまなフレームワークを触りながら SPA を作るためのベストプラクティスを探している中で出会ったのが React でした。最初に見た時は JSX の奇妙な構文を見てスルーしてしまったのですが、後日 Atom Editor が React を使いパフォーマンス改善した記事を読み、再度興味を持って触ったのがきっかけでした。
https://blog.atom.io/2014/07/02/moving-atom-to-react.html

その後、Pete Hunt 氏の 「React: Rethinking best practices」の動画に衝撃を受けました。
https://www.youtube.com/watch?v=x7cQ3mrcKaY

このトークはタイトルにある通り、自分にとってもこれまでの考え方を大きく変える内容でした。テンプレートエンジンを用いてマークアップとロジックを別々のファイルに書くことは、技術による分割であり関心の分離ではないこと。コンポーネントを用いて宣言的に UI を記述し部分的に書き換えるのではなく全体を再レンダリングするという発想。コンポーネントにより凝集度を高めて結合度を下げるといった内容など、現代のフロントエンドで当たり前になっていることがこのトークには多く含まれています。

React に対して「これだ」という気持ちを強く持つようになり React に関する記事を書いていく中で、自分の理解に曖昧な部分が多いことに気づかされました。そのため、アウトプットするには React の細かい部分の挙動についても調べる必要がありました。結果としてコードを読んでいる中で見つけた React 本体のバグや、ドキュメントが不正確な部分を修正することを繰り返していました。最初はドキュメントの修正が多かったです。

この時期は、「何か書く」⇨「それについて議論したり勉強会で話したりするようになる」⇨「話している中で曖昧な部分が気になって調べる」⇨「コントリビュートする」というサイクルがうまく回っていました。前述したインプットとアウトプットのバランスがうまく取れていました。

こうして React に対するコントリビュートを重ねていった結果、海外からもさまざまなチャンスが来るようになりました。言語の壁によって多くのチャンスを逃すことになると気づき、英語の勉強をするようになったのもこのタイミングです。React の開発元である Facebook(現 Meta)のリクルーターの方から GitHub での活動を見て連絡をもらったのは本当に嬉しかったです。

React にコントリビュートすると言うとすごいと思われることがありますが、私がコントリビュートした内容を見ればわかる通り、そんなに難しいことをしているわけではありません。
https://github.com/facebook/react/commits?author=koba04
注)現在の React は、当時と比べてもライブラリとしての完成度が高く実装も複雑化しているため、コントリビュートするのは当時に比べてかなりハードルが高くなっています。

実態としては、できる人はたくさんいたけれど、やっている人がほとんどいなかったというだけだと考えています。私自身、自分が特別に優れたスキルを持っているわけではないことを理解しているため、「自分しかできないことはないけれど、自分しかやらないことはある」ということを意識しています。

React Europe 2016 に参加した時にもらったマグカップ。メッセージが気に入っていて今でも使ってます。

OSS に貢献する方法

OSS に貢献する方法には実装に対してプルリクエストを送るといったわかりやすいものだけでなくさまざまな形があります。ドキュメントに対する貢献、Issue や Discussion への回答による貢献、ブログや記事を書くことによる貢献、経済的な貢献などがあります。 もしあなたが好きだとか貢献したいと思える OSS があれば、コードによる貢献にこだわらずさまざまな形での貢献を考えてみることをオススメします。ブログを書くことも立派な貢献です。その際は伝聞をもとに書くのではなく事実かどうかをしっかり確認することが重要です。そういった確認作業がさらなる貢献につながることもたくさんあります。

また、リポジトリをウォッチして Issue や Discussion に回答するのもオススメの方法です。Issue や Discussion に投稿される内容は再現するための情報が不十分なものや、確認が難しいものもあります。そういった内容を実際に確認して再現ケースを作成したりテストコードを書いたりすることは、実装を理解するのに非常に有効です。そこから実装を修正する貢献につながったり、足りないテストの追加やドキュメントの修正につながったりすることもよくあります。

Issue や Discussion にはたくさんの貢献のための種があるため、それらへの参加から始めるのはとても良い方法です。コードによる貢献をしたい場合には、足りないテストケースの追加や不安定なテストの修正などから始めてみるのもオススメです。テストから始めることで外部から見た振る舞いを起点として内部の実装に触れることができます。複雑な OSS のコードを理解する際には、何か特定の目的のためにコードを読み始めるほうがスムーズです。

世界中のエンジニアとコードを書ける楽しさ

私自身、OSS への貢献は楽しいからやっている部分が多いです。 例えば React へ Pull Request を送ることで Meta のエンジニアと一緒にコードに関する議論ができます。最近よく関わっている SWR の場合は、Vercel のエンジニアと一緒にコードを書くことができます。これらの会社に入ることなく所属しているエンジニアと一緒に開発できるのは、本当にすごいことだなと日々思っています。

OSS における経験は私自身にとって貴重な学びの機会だと考えています。OSS から学んだ設計や技術は業務においても有用であり、技術的な引き出しとなっています。個人的にこのことが OSS をやる大きなモチベーションのひとつであり、個人で新しいライブラリをいっぱい作るのではなく、すでにある OSS に貢献することが好きな理由です。

OSS に対してハードルの高さや「怖さ」を感じるという声を耳にすることがあります。私自身最初はハードルの高さを感じていたこともあり、そのことも理解できます。その場合、テストの追加やバグ修正など、やることが明確で議論の余地が小さいものから取り組むことをオススメします。メンテナ目線から見た場合でも、これまで貢献がない人からの Pull Request に対しては慎重になります。機能追加であれば尚更です。一方、テストコードの追加やテストコードを一緒にしたバグ修正については、レビューもしやすくマージしやすいです。ハードルが高い、怖いと感じる場合は、こういった小さなところから成功体験を積み重ねていくのが良いのではないかと考えています。

フロントエンドをやっていく上で意識したこと

フロントエンドエンジニアとして働く

その後、サイボウズに入社し、はじめてフロントエンドエンジニアとして働くようになりました。これはフロントエンドのみを今後やっていきたいという気持ちではなく、フロントエンドに対して専門性を持ちたいと考えたからです。 フロントエンドといっても、HTML、CSS、JavaScript の知識だけでなく、ネットワークやパフォーマンス、セキュリティ、デザインまで幅広いです。私自身これらのうちカバーできている部分は一部です。そのため、フロントエンドを中心に自らのスキルや経験を深め広げていきたいと考えました。

成熟していくフロントエンドにおいて

フロントエンドは React や Vue、Angular といった手段の話から、パフォーマンスやアクセシビリティといったユーザー体験に話題が移りつつあるなど成熟を感じます。 また、ライブラリやフレームワークも成熟しており、これまで以上にエコシステムを利用した開発が可能になっています。
これは結果として作る人と使う人を分けることになっています。 例えば 普段の開発において DOM の API について意識する機会が以前と比べて減りました。昨今ではさらにさまざまな UI ライブラリが利用可能になっており、これらを使うことでアプリケーション開発者はリッチで使いやすいアプリケーションを素早く構築できるようになりました。これはライブラリ作成者がマークアップや DOM API について理解しアクセシビリティを考慮した上で開発をしているからです。

1 つ下のレイヤを掘り下げる

この「巨人の肩の上に立った開発」が可能な状況においては、エンジニアにとって「作る側」になることも重要だと考えています。 例えば React に貢献することで、利用者としてはあまり意識しない細かい DOM についての知識やスケジューリングに対する知識を学べます。React のライブラリである SWR のようなライブラリに貢献することで、React についての細かい知識や非同期処理、複雑な UI を作るパターンを学べます。

また、こういったライブラリレベルの実装においては、アプリケーションレイヤとは異なる知識が求められます。以前に「Algorithms in React」というタイトルで発表したように React の内部ではさまざまなコンピューターサイエンスの理論やアルゴリズムが用いられています。
https://speakerdeck.com/koba04/algorithms-in-react

利用しているだけではこれらの知識は必要ありませんが、貢献しようと考えた時には必要となります。私自身、Doubly Linked List といったデータ構造は知識としては知っていましたが、普段のアプリケーション開発において使うことはありませんでした。React がコアな部分のデータ構造として使っているのを見て、はじめて実践的なユースケースとして学びました。 他にも React v18 においては Tearing について学びました。

reactwg/react-18#69
https://en.wikipedia.org/wiki/Screen_tearing

同様のテーマについて Wordle の作者である Josh Wardle さんが Syntax. という Podcast で話していたので紹介します。
https://syntax.fm/show/430/creator-of-wordle-josh-wardle

Josh さんは React を通じてフロントエンドを学び始めて Pinterest で働いていました。Pinterest のような企業だと、自分よりも賢い人たちが作ったツールやコンポーネントライブラリがすでに整備されており、それらをレゴのように組み合わせるだけで質の高いアプリケーションを作れます。そのため、これらのライブラリがやっていることはブラックボックスになっており知る必要はありません。これはとても素晴らしいことですが、こういったライブラリがやっていることを理解したいと考えて Wordle はライブラリを使わずに、ピュアな JavaScript、HTML、CSS で作ったそうです。

最後に

やりたいことを強みにする

この記事では、私がエンジニアになってから現在までを振り返ってきました。さまざまな経験が自分にとっての糧になりましたが、数々の取り組みのなかでも、エンジニアが成長する上で特に大切だと感じる要素があります。それは「やりたいこととやるべきことを一致させること」です。 ソフトウェアエンジニアとしてやるべきことはたくさんあります。世の中に目を向けてみると「学ぶべきこと」で溢れています。これらをすべて学べたらよいのですが、現在の自分にとって優先度が低いものもあります。これらのやるべきことに追われて自分が本当にやりたいことに時間を割けないとしたら、それはとてももったいないように感じます。時間は有限であるため取捨選択が重要となります。そのため自分がやりたいことを中心としてやるべきことに手を広げていくのがいいと考えています。 これは世の中に溢れるやるべきことから自分にとってのやるべきことを抽出する作業と言えます。

React のコアメンバーである Dan Abramov さんが自身のブログで「Things I Don't Know as of 2018」という記事を公開しています。この中で、自身にも多くの知らないことがあることを書いています。”People often assume that I know far more than I actually do.” から始まるこの記事は、きっと多くの人を勇気づけてくれると考えています。

Things I Don't Know as of 2018 (日本語翻訳)

自分のやりたいことを見つけ強みを作ることによって、さまざまなチャンスが広がり、そこからさらに学びを広げることできます。

怖さと楽しさを積み重ねる

これまでのキャリアを振り返ってみると、「怖さ」と「楽しさ」の 2 つの感情が常に自分の中にありました。「怖さ」は現状に満足せず新しい挑戦をしているのかの目安になっています。「楽しさ」は強みを伸ばす活動ができているかの目安になっています。一見するとネガティブとポジティブで相反する感情ですが、私自身の中ではどちらも自分に欠かせない大切な感情です。

これからも、怖さや楽しさといった感覚を大切にして日々積み重ねていきます。

最後に。私自身、独学で勉強してソフトウェアエンジニアとして働くようになりました。キャリアを通じて難しいなと感じることはたくさんありましたが、ずっと楽しいなという気持ちを持ち続けています。そのため、今後さらにさまざまなバックグラウンドを持った人がソフトウェアエンジニアとして働ける世界になるよう貢献したいと考えています。

著者近影

編集:中薗昴