UI Componentsライブラリを開発したことによるメリット
ライブラリを作る側
-
フロントエンド実装ができるデザイナーは、エンジニアを介さずともUIの微修正をアプリケーションに反映できる
- 見た目に関わる実装、改善をデザイナー自らメンテナンスできるように。
ライブラリを使う側
-
レイアウト構成と使うコンポーネントが決まっていれば、デザイン知見があまりないエンジニアでもスタイルガイドに準拠した画面を実装することができる
- CSSの実装が苦手なエンジニアでも作業を完結できるように。
UIに関わるコードがUI Componentsライブラリとして1か所に集約され、利用アプリケーションを実装する体制が整ったことで、前述の課題は「似たようなUIが別々に作られることはなくなり、結果として画面の一貫性が保たれる」ことで解決できたかなと思っています。
なにより、Angularアプリケーションのエンジニアが、アプリケーションロジックの実装に専念できる環境を整えられたことがメリットとして大きかったと感じています。
最後に
Angularの知識が少ない中でUI Componentsライブラリの開発に着手するのはチャレンジングな取り組みであり、リソースの面でも身の丈にあっていないアプローチを採ってしまったのではないかと不安を感じた時もありましたが、およそ1年をかけてHRMOS採用管理で使われている主要なUIを揃えることができました。
ライブラリとして独立させたことで、部署内の有志が取り組んでいるサイドプロジェクトの管理画面にUI Componentsライブラリを用いることで開発工数が短縮できた、といった効果もありました。
エンジニアがUI Componentsライブラリを活用して管理画面をサクっと作ることも。色々揃っていて便利とのお声もいただきました。
コンポーネントの粒度や切り方に関しては様々なアプローチがあり、私たちもこれでベストだとは思っていません。
特にMoleculesとOrganismsの分類は悩ましく、私たちは内部に状態を持つかどうかを分類の基準の1つにしていますが「MoleculesとOrganismsのヒエラルキーが逆転しているのでは？」と感じるケースも実際にあったりします。
ただ、分類にあたっては厳格な運用は行なわず、迷ったときはコンポーネントを実装する際にフロントエンドエンジニアメンバーで話し合った上で決めています。
以上、Angularのコンポーネント開発の一例として、参考となれば幸いです。お読みいただきありがとうございました。
