KENTEM TechBlog

建設業のDXを実現するKENTEMの技術ブログです。

IT未経験から3年間React開発を行った振り返り

フロントエンド テスト カルチャー 言語 設計

UnsplashのYannik Zimmermannが撮影した写真

こんにちは。フロントエンドエンジニアのT.C.です。私はITエンジニア未経験でKENTEMにキャリア入社し、React歴も4年目になりました。

どのくらいのスキル感で入社して、各年次ごとにざっくりどの程度のスキルを持つようになったのかを共有します。

スキルの成長は具体的な数値で測りにくい部分もありますが、当時の感覚や経験したことを中心にお伝えできればと思います。

また、後半ではアトミックデザインやフロントエンドテストを導入した際に学んだことも書かせていただきます。

主観の多い記事にはなりますが、Reactエンジニアを目指している方やReact初学者の方の参考になれば幸いです。

スキル感

入社前

技術 経験
HTML/CSS/JavaScript 基本的なコードリーディングはできた
TypeScript 聞いたことはある…程度
React 聞いたことはある…程度。動画と少しの実戦でVue.js(v2)はわずかに触れる？くらい。
Next.js 聞いたことはある…程度

その他

  • Git操作はかろうじて定型作業ならできる程度
  • Node.jsは言われるがまま環境構築しただけ
  • 他にPythonやPerlなどのスクリプト言語は前職や大学時代に触っていたことがあった

趣味レベルでWeb系のプログラムに触り始めてはいたものの、呪文として理解していたところがかなりありました。

この頃はまだVue.jsもバージョン2だったので、TypeScriptもまともに触ってませんでした。

1年目

技術 経験
HTML/CSS/JavaScript FlexboxやGrid Layoutの理解が少し深まった
TypeScript プリミティブ型やシンプルなオブジェクトの型付けはできた
React useStateやuseEffectなどの基本的なフックの使い方がわかっていた。ToDoアプリをサクッと自作できた。
Next.js 環境(静的解析やスタイリング基盤等)構築も経験した

その他

  • C#を通してオブジェクト指向という概念を知った
  • Gitの基本的な操作の裏で何が起きているかを理解した
  • Node.jsによってサーバーサイドやReactの開発ができることを理解した
  • APIリクエストができた
  • デプロイまで自力でできた
  • Storybookを勉強しながら書き始めた
  • コンポーネントレベルのフロントエンドテストを勉強しながら書き始めた

業務でコーディングを経験することで成長速度はかなり上がった感覚がありました。

機会に恵まれて新規プロダクトの立ち上げに携わることができたのもかなり大きかったです。

コーディングルールを一人では決められないことや設計にどうしても例外が出てしまうことなどから理想通りにはいかないこともあるということをここで感じました。

一つ一つは浅いものの広く色んなことにチャレンジできた年だったと思います。

2年目

技術 経験
HTML/CSS/JavaScript テストコードのためにセマンティックHTMLを意識し始めた
TypeScript ユーティリティ型などまで積極的に使い始めた。ジェネリクスは使えていなかった。
React フックの正しい使い方を考え始めた。設計も意識し始めた。TanStack Query、Zustandなどの状態管理ライブラリを触り始めた。
Next.js Reactとの差分をおよそ理解し、サーバー側の概念も理解した

その他

  • Node.js(Express)でバックエンドを最低限作れるレベル
  • APIのベストプラクティスを考え始める

初めは小さかったプロダクトが徐々に大きくなっていくことで、気軽にコードを修正できなくなっていく難しさを経験しました。

広く学んでいた知識を一段深く学ぶことができたと思います。

この頃から生成AIが世間一般に普及し始めたので、少しずつ成長速度が上がっていきました。

3年目

技術 経験
HTML/CSS/JavaScript Setオブジェクトや連想配列などJSのテクニックによるパフォーマンスも意識し始める
TypeScript Type Challengesの初級レベルの型パズルができるようになった
React コンポーネントの状態をどこで保持するかであったり、無駄なuseEffectを使わないなどのReactの根本的な設計を無意識で行えるようになった
Next.js サーバー側を触ったり、App Routerの新機能も経験

その他

  • プロジェクトマネジメントや後輩サポートが増え始める

知識が深まってくると同時に、プロジェクトマネジメントや後輩のサポートも増え、プログラムに触ることは少なくなってきました。

ビジネス視点も出てきて、きれいなコードが全てではないということも感じ始めました。

純粋にプログラミングを楽しんでいた時から比べると、子供から大人になったようで少し寂しい気持ちもあります。しかし、それは同時に新しい役割への挑戦であり、エンジニアとしての幅を広げる貴重な経験でした。

また、後輩を教えていると、私の過去のスキル感を一瞬で抜いていくのでとても羨ましかったです。私も負けずに学び続けなければ…という気持ちにさせられました。

挑戦して得た学び

細かく挙げたらキリがないので、Reactエンジニアに刺さりそうな二つのトピックについて少し掘り下げます。

アトミックデザイン

1年目の後半で運よく新規プロダクトの立ち上げに携わることができたのですが、そこでNext.js(Pages Router)をベースにアトミックデザインを採用しました。

会社としてもReactを導入してからあまり知見が溜まっていなかったこともあり、1年目の前半で携わっていたプロダクトではコンポーネントをあまり分割せずに1ページ1コンポーネントのような構成になっていました。

そこで新たに立ち上げるプロダクトではコンポーネントの分け方がシンプルそうなアトミックデザインを採用して、コンポーネントを初めから分けることで再利用性を向上させました。

その際のコンポーネントの分け方は大きく以下の通りです。

分類 ビジネスロジックを持つ/持たない 配置場所
Atom 持たない components配下
Molecule 持たない components配下
Organism 持つ components配下
Template 持たない components配下
Page 持つ Pages配下(Next.jsの機能に準拠)

Atomは基本的に一つのHTMLタグと対応していて、表の自分類より下のものを内包することはできないというルールにしていました。

マッチしたところ

複数のコンポーネントと関連するときに配置場所に悩まない

→ 機能ごとに分けると複数の機能にまたがるコンポーネントのときに配置場所に困ると思いますが、そういうことはありませんでした。

他プロダクトに渡せるレベルの限界(Molecule)が明確でわかりやすい

→ 他プロダクトに流用したい際にどこまでが有用かパッと見てすぐわかるようになっていました。

APIを呼び出してよい場所が明確

→ テストを書く際にモックを活用するなどの注意するべきコンポーネントがわかりやすかったです。

マッチしなかったところ

Organismが増えすぎてしまった

→ 想定ほどコンポーネントの再利用が多くはなかったため、一か所からしか呼ばれないコンポーネントが数十個Organismとして生まれてしまいました。

Atomの定義が難しかった

→ カラーピッカーのように小さいパーツでinputでも完結するようなものが、デザイン仕様に合わせるために複数タグを使用したのですが、Atomに置いてよいものか非常に悩んでAtomにしました。

失敗したところ

Moleculeの命名がLabeledInputのようになってしまった

→ 結局意味のないAtomの集合を作っているだけになってしまっていたので、複数のコンポーネントが合わさったことでどう意味が変化したかを考えてコンポーネントを分けつつ命名した方が良いと思いました。

テーブルコンポーネントの構成要素をバラバラにしてしまった

→ 関連が強いコンポーネントなので、一つに固めた方が良かったと思っています。また、関連が非常に強いのでuseContextなどの活用も検討してもよかったと思っています。

ダイアログの扱いに困った

→ やっていくうちにダイアログはただの1コンポーネントではなく、Pageと対を成すような大きなジャンルの一つだと思うようになりました。これは大きめの一つの機能を追加する際にページを追加するかダイアログを追加するかを考えることが多かったからです。ですが、ページは一つのフォルダに固められているのに対し、ダイアログはOrganismとして他のOrganismとまとめてしまっていたので分け方が適切ではなかったなと反省しています。

マッチしていなかったところや失敗したところもありますが、チームメンバーに助けられながらも結果的には比較的いい感じで運用できていると思います。

ただ、App RouterのPrivate foldersなどが使える場合は特に、アトミックデザインで全てを完結させるより、共通して使いたいものはアトミックデザインで管理しつつ、専用コンポーネントはPrivate folderとして管理するなどハイブリッドの構成の方が良いと考えています。

フロントエンドテスト

コンポーネントテスト

プロダクトの新規開発の初めは意気揚々と全てのコンポーネントの入出力に対してテストを書いてやるぞ！と息巻いていましたが、そのとき採用していたのがVitestとReact Testing Libraryでした。なぜか入出力のテストがうまく書けず、ちゃんと調べてみるとReact Testing Libraryではそれを推奨していないようでした。

この経験からライブラリ等を使う際にはコンセプトを調べるようになりました。

またこのとき、入出力のテストをする別の手段がないのかも調べていて、それはEnzymeというライブラリを使えば実現できるということのようでした。

いずれにせよ周りに有識者も少なかったため、よく使われているReact Testing Libraryをまずは使うことに決め、そのコンセプト通りユーザー視点のテストのみに注力するようになりました。

今考えると大きな理由もなく始めてしまっているので、今後はもっと課題感を持ってテストの導入を進めていきたいですね。

E2Eテスト

ある程度開発が進んできて、画面遷移のテストを書きたいというフェイズが来たのですが、コンポーネントテストではどうにも対応できませんでした。

そこで頭の片隅にあったE2Eテストのライブラリを調査し、こちらも良く使われているPlaywrightを採用しました。本来Playwrightは他にも色んなテストに使えるはずですが、現状ほとんどは画面遷移が正しくできるか確認するために利用しています。「ほとんど」と書いたのはファイル入力用のinput要素が正しく動くかをテストするためにも実は少し使っているからです。

他にもコンポーネントレベルとアプリケーションレベル双方のVRTも普段使っているのですが、こちらは別のチームメンバーが導入を進めてくれたものなので割愛します。

基本的にコーディングレベルではESLintやPrettierなどの静的解析を高頻度で行いつつ、コンポーネントテストとE2EテストとコンポーネントレベルのVRTはプルリクエスト単位で実行しています。また、アプリケーションレベルのVRTは基本的に1回/日で実行するようにしています。

フロントエンドテストは慣れないうちはそもそも記述方法がわからなくて苦戦するところから始まりましたが、テストのためというのが大きいもののセマンティックなHTMLの知識も身についてきました。

重複したテストをなるべく書かないように意識したり、実行時間が長くなりすぎないように注意したり、非同期処理の待ち時間を長くしすぎないようにしてフレーキーテストをある程度許容したり、こちらも多くの学びを得ることができました。

まとめ

振り返ってみると、年を重ねるごとに着実にスキルアップしてきたことを実感しています。

3か月間の研修から始まり、その後も手厚いサポートがありながらの業務だったので、安心してスキルを伸ばしていけたと思います。

また新規プロダクトの立ち上げやマネジメント業務にも携わらせていただけたので、コーディングスキル以外も多くの経験を積むことができて、とても感謝しています。

もらったものをより大きくして返していけるように今後も努力していこうと思います。

おわりに

KENTEMでは、様々な拠点でエンジニアを大募集しています！ 建設×ITにご興味頂いた方は、是非下記のリンクからご応募ください。 recruit.kentem.jp career.kentem.jp