フロントエンドの歴史変遷

どうも！Baseconnect のエンジニアの山本です。

さて、今回はBaseconnectのプロダクトである、営業リスト作成から営業管理までを一括管理できる法人営業支援データベース「Musubu」のフロントエンドの歴史についてご紹介させていただきます。創業当初の様子はわかりませんので、物語は私が入社した2018年から始まります。

大雑把にフロントエンドの技術スタックの変遷を絵にすると、こんな感じです。

2018年入社当時

私が入社したタイミングのムードと言えば、プロダクトが成功する兆しが見えてきたぞ...という感じでした。ヨシ、プロダクトに新機能を追加していくんだってね。

当時は代表がすべてを掌握し、指示を出し、レビューをするという超中央集権的指揮系統で、デザイナーがデザインからコーディングまでを担当し、エンジニアもフルスタックで様々な業務をこなしていました。

こりゃえげつないフローだなぁとビックリしましたが、一気にプロダクトを具現化するタイミングで必要なダイナミックさでもあったなぁ。

React / Redux でスタイリングは Sass、バックエンドは Ruby on Rails という当時としては鉄板構成だったんじゃないかな？でもまぁ、フロントエンドのコードのカオスぶりはナカナカのものでした。様々なスキルレベルのエンジニアが、コードを追加しているような感じ。特にCSSの上書き合戦による膨大化には遠目になりました。

膨大なコードを目の前に、どうしたものかと躊躇しながら、Typescriptを採用し、JSX(js) から TSX(ts) への移行が始まっていました。

Atomic Design / Storybook

フロントエンドのコードは、それぞれが一つ一つ心を込めて作っている工芸品のようでした。とても似ているボタンが無数にあり、デザインルールも明確ではありませんでした。

まず、UIコンポーネントを整理・掌握し、再利用性を向上させる必要がありました。当時、コンポーネントの分割手法として盛り上がっていた Atomic Design、コンポーネントカタログとしてStorybookを採用しました。

フロントエンドエンジニアとしての専業化も、ジワジワ進んでいきます。

2019年 : プロダクトリリース期

しかし、コンポーネントの整理はあまり進捗しなかったかもしれません。プロダクトとして方向性を変える、いくつもの機能を実装することに奔走していたからです。

Styled-Components

Sass でスタイリングをコントロールすることが難しくなっていました。人力による命名規則でスタイリングのスコープをコントロールするってのは無理になってきたのです。Styled-Components を採用し CSS in JS へ移行していきました。

そしてついに、2019年11月11日に「Musubu」をリリースしました。

2020年

2020年は、あるべき姿にしていこうという動きが徐々に活発になってきていた。これまで自由なインスピレーションと創意工夫でこさえてきたが、世のベストプラクティスを学び、適用していこうという流れでしょうか。

Redux Toolkit

Reduxにおいて、より効率的に開発を行うためのライブラリで、Reduxの公式サイトでも強く推奨されています。「Reduxを簡潔に書くためのスターターキットである」というよく見る解説も納得できますが、Reduxにおけるベストプラクティスが取り入れられた、Reduxを利用する時の間違いを防止し、正しく利用するための知恵の集合とも言えます。これはプロダクトをより安全・堅牢にしてくれるでしょう。

React Query

データ同期については長らくフロントエンジニアの悩みのタネでした。取得、キャッシュの扱い、更新、ポーリング、エラー処理... 「SPAあるある」な、それらの憂鬱を解消するライブラリとして登場したのが、おなじみ TanStack の React Query でした。

React Hook Form

バリデーションルールは、整理・共通化されていたり、そうでない箇所もあったりと、とっ散らかっていました。React Hook Form を採用し、そのバリデーションスキーマに Yup を使用し統合・再利用性を向上しました。

xstyled

CSS in JS ライブラリとして既に Styled-Components を採用していましたが、互換性のある props ベースのフレームワークを採用しました。参照：[CSSフレームワーク「xstyled」について]

Styled-Components はなんだかんだ言って、ベタなCSSの記述が必要です。あぁ、本当はこう書けたらかっちょいいのになぁ、を実現してくれるのが「xstyled」です。

プロダクトのテーマカラーを刷新するというプロジェクトで、広範囲で適用され、しぶとく残っていた Sass によるスタイル指定を大量に排除することができました。

Atomic Design を破棄

Atomic Design に沿ったコンポーネント分割を放棄しました。理念にはとても共感するのですが、多数のレイヤーに分類する方法は、私たちにはマッチしませんでした。

2021年 : 主要機能のUI刷新とリファクタリング

フロントエンドのリファクタリングがとても進捗した年です。

プロダクトのビジョンを具現化するための大規模改修が計画されていました。その要件化を緻密・詳細に行った結果、フロントエンドとしては停滞したタイミングがありましたが、その時間を利用して大規模なリファクタリングに着手したのです。（タイミングを虎視眈々と狙ってた）

リファクタリング

一定のリソースを担保し、コツコツと負債を解消に取り組むことで、劇的にコードの透明性が向上しました。

RTK Query & Aspida 組み込み
テスト改善
ディレクトリ構成
FC 化

...などなど

RTK Query

APIとの通信やキャッシュ管理に React Query の適用に着手していましたが、Redux Toolkit との相性が抜群に良い RTK Query に仕切り直すことにしました。

Aspida

また、HTTPクライアントのラッパーである Aspida を採用し、APIリクエスト/レスポンスが型安全になりました。パス/URL、クエリ、ヘッダー、ボディ、レスポンス...全てに型を指定でき、axios にも対応しています。

UI & Frontend Meeting

デザインチームとのディスカッションの機会で、アイデアや意図が共有され、早期からその実現性やレンダリングの負荷、使い勝手について検証しました。そのためのツールの模索も行われ、デザインツールは figma に変更。実装の共有・ディスカッションツールとして chromatic を採用しました

主要機能のUI刷新

主要機能のUI刷新は無事にリリースされ、ユーザーに好意的に受け入れられました。

リファクタリングという地ならしによって、コードの透明性・開発体験透明性が向上した。
デザインの目的・意図を汲み取り、その実現方法についてデザインナーとエンジニアが知恵を出し合った。

難工事に取り組んでくれたメンバーに感謝しています。

現在

現在、Musubuの新機軸となる機能群を、モリモリ実装中です。

その中で、これまで模索してきたことをさらに昇華し、より良い体験をユーザーに提供できるよう取り組んでいます。

デザインシステムの構築 / DesignOps
ユーザーの視点に立った継続的改善
より良い方法・手法を積極的に採用していく

一流のフロントエンドと胸を張るには、あと何ステップか成長しなければなりません。ご興味を持たれた方は、ぜひ覗いてみてください。

2018年 入社当時