20年以上続くシステムのフロントエンド開発～スピードと品質両立の取り組みとは？～

Works Human Intelligence（以下WHI）が提供する統合人事システム「COMPANY」は、20年以上にわたって進化を遂げ、約1,200の大手法人および公共・公益法人でご活用いただいています。この進化の裏には、技術的負債に向き合う多くの努力があります。

「COMPANY」の強みとなる機能の豊富さを実現するために、これまで開発者たちは法改正や複雑な人事業務に合わせて「業務機能の網羅性」を重要視した開発を行ってきました。その一方で、フロントエンドでは20年以上前にシステムの基盤を形作ったDelphiの見た目・操作性をほぼそのまま踏襲したデザインとなっていました。加えて、バックエンドとフロントエンドが過結合した技術基盤といった技術的負債が積み重なり、デザイナーとの協業やデザインからの実装が困難な状況が続いていました。

今回は、フロントエンド開発環境の技術的負債に立ち向かい、改革へ導いたエンジニア、前川さんに焦点を当て、その取り組みについて詳しくお話を伺います。

1. フロントエンド開発環境を取り巻く社内意識の変化

豊富な機能で大企業の複雑な人事業務を支えるCOMPANYですが、年々、直観的な操作が可能なUI/UXが重要視されるようになってきました。特に設定の容易性や画面のわかりやすさに関するユーザーの期待は日々高まっています。また、法改正などの外部変化への対応や網羅性の維持も求められてきました。
これら全てを両立し、より良いものを提供し続けることが、これから先何十年、COMPANYが提供できる価値だという社内意識が高まり、フロントエンドの開発環境に目を向けるきっかけになりました。

2. フロントエンド開発環境改善への挑戦を決意

当社では、デザイナーが設計したデザインシステム「NEON」によって基本的なデザインルールは整備されていましたが、課題が大きく2つありました。

1つ目が、UI実装のばらつきです。COMPANYは各プロダクトごとに使っている技術や開発環境、製品の技術的歴史も大きく異なるため、各プロダクトの状況にあった実装が求められます。そのため、同じコンポーネントでも微妙に異なるスタイルだったり、複数のパターンでコードが作られていました。また、開発者のスキルによってもUIの実装が左右されるため、デザイナーがチェックを行う必要があり、プロジェクトの進行にも影響を及ぼしていました。

2つ目が、非効率性です。各プロダクト側でデザインルールの変更、NEONの更新に対応する必要があったため、スタイルの変更に多くのリソースを割くこととなり、開発者にとって大きな負担となっていました。少し色を変更するだけでも、変更に伴う影響範囲を簡単に把握できなかったり、いざ修正に取り掛かっても、すべてが抜け漏れなく統一して修正できているかという把握も難しい状況でした。

これらの課題を放置してしまえば、開発者がUI/UXのデザインをより良いものにしたいというWillがそもそも生まれにくく、生まれても優先度が下げられてしまう、そのようなフロントエンドの開発環境ができてしまいます。Willを生み出す、Willを後押しする、そして今まで機能性でユーザーのことを一番に考えてきた開発者たちがフロントエンド開発でも価値が生み出せる、そんな環境を作りたいという思いで走り出しました。

3. NEONライブラリの誕生

そこで行ったのが、『NEONライブラリ』の開発です。

NEON Design System の全体像

NEONライブラリは、デザイナーが作成したFigmaのデザインキットを元に、様々な開発コンポーネントを集約する仕組みを整えようとする試みです。

まずは、neon-design-tokensを用いてカラー、フォント、スペースといったデザインの基本単位を統一し、スタイルの統合性を確保しました。

neon-design-tokens

続いて、具体的なスタイルとアイコンセットを、neon-stylesとneon-iconsによって標準化することに取り組みました。これにより、各サブプロダクトの開発者が重複したスタイル設定に頭を悩ませることなく、迅速にNEONスタイルに沿った開発が可能になります。

NEONライブラリのコンポーネント例

最終的に、neon-reactを通じてReactコンポーネントを提供し、効率的な開発環境を実現しました。これらのライブラリは、デザインシステムとの乖離を防ぎ、開発者が安心して一貫したUIを構築できるようにサポートしています。

開発を始めた当初は、どこから手を付ければいいかわからない状況でした。最初はReactを使ってライブラリを作成していましたが、実際にはReact以外のフレームワーク、例えばjQueryやVueでもこのライブラリが必要とされていることに気づき、各役割に応じてライブラリを分割することにしました。

フロントエンドが比較的レガシーな技術で構成されているプロダクトでは、neon-design-tokens、neon-stylesから徐々にスタイルを統合していく。一方、新規で作る製品は、neon-reactから一気に導入することで開発効率を上げる。そんな風に様々なフレームワークや製品のフェーズに導入しやすくしました。

4. デザイナーとの協力体制

当初は一人でボランティア的に作業を進めていたため、孤独を感じることが多かったです。開発を進める中で、「デザイナーの協力が不可欠だ」と思い、デザインチームに参画、デザイナーと協力しながら開発を進める体制を作りました。その結果、ライブラリを使う開発者やデザイナーにもコントリビューターとして参加してもらえることになりました。フロントエンドの技術がレガシーであるため、npmなど比較的モダンなフロントエンドの開発技術についてあまり知識がない開発者もいる中で、ライブラリの使い方を説明することは大変でしたが、今では多くの協力を得ることができています。

5. NEONライブラリがもたらした価値

NEONライブラリの開発によって、実際に開発効率性が上がったと実感できる場面も出てきました。

その1つがアクセシビリティ向上の取り組みです。

もし、NEONライブラリがなかった時にアクセシビリティの取り組みを始めていたら、各開発者が独自で実装していた箇所をそれぞれ確認して、修正を加える必要があり、場合によっては、大きくスタイルが変わってしまう可能性もあります。実装コストもかなりかかるため、取り組みの優先度を下げられてしまうかもしれません。

しかし、NEONライブラリを使って開発すれば、ライブラリ側で修正を加えるだけで、プロダクトをまたいで一斉に修正を加えることができるため、非常に効率的な開発が可能になります。

その結果、アクセシビリティ向上も短期間で一気に取り組むことができました。

製品にまたがって使用されるグローバルヘッダーのアクセシビリティの向上を実現

6. 共に未来を創る仲間を求めて

NEONライブラリの導入によって、実際にいくつかの機能が開発されています。その成果を目にすると、努力した甲斐があったなと感じます。

デザインシステム開発に関わる仲間も着実に増えており、会社全体としてもこの取り組みへの意識が高まっています。私たちの設計方針は、コンポーネント単位でのデザインの大幅な更新や、アクセシビリティの準拠など、多方面での標準化を実現することです。その結果として、フロントエンドの開発工数の大幅な削減を目指しています。

とはいえ、まだ道半ばです。今はまさにチャレンジしがいのある時期で、新たなアイディアを試行できる機会が山ほどあります。それと同時に、もっと多くの仲間が必要だという課題も抱えています。

技術的負債と向き合いながら、新たな時代に向けて新しい技術を取り入れていく。そんなワクワクする挑戦に一緒に挑んでくれる仲間を募集しています。

自分自身も歩み続けながら、新しい仲間に出会えることを楽しみにしています。