サービスの一貫性と高速開発をもたらす「動くスタイルガイド」

10月18日（水）に、株式会社ベーシックで行われた「Nextstage Nite vol.2 – 実践されるデザインガイドライン –」に、HRテック（HR × Technology）で採用を強くする「HRMOS（ハーモス）採用」（旧：HRMOS採用管理）のフロントエンドエンジニアの浅井が登壇しました！

浅井 雅彦 (Masahiko Asai)
大手のWeb企画・制作企業にて、ナショナルクライアントの大規模なWeb制作を行う。自社のサービス開発でのやりがいを求め2015年にビズリーチに参画。HRMOS採用管理事業部のフロントエンド開発を牽引している。

当日は、

• ウォンテッドリー株式会社
• 株式会社ベーシック
• 株式会社クラウドワークス
• グリー株式会社
• 株式会社ビズリーチ

の5社の現場で実際に作られている（作っている最中である）デザインガイドラインやスタイルガイドをLTで発表するもので、それぞれの現場の苦労や背景、プロセスなどが見れて、私たちにとっても学びの多い時間となりました。

今日は、当日お話しさせていただいた内容をお伝えしようと思います！

当日のスライド

当日取り上げたサービスは、採用業務の一元管理と、データでの可視化・分析を通じて戦略的に採用を行うためのクラウドサービス「HRMOS（ハーモス）採用」です。

HRMOS採用ではスタイルガイドを策定するにあたり、Atomic Designの概念を取り入れて作成しています。Atomic Designとは、ページ単位でデザインするのではなく、UIコンポーネントの合体によってページを構成していく考え方で、下記のようなメリットがあります。

• 再利用性を意識しているため拡張性があること
• デザインに一貫性が生まれる
• UIコンポーネントの粒度が小さいため変更の影響範囲が少ない
• 実装単位が明確なためエンジニアとのコミュニケーションが取りやすい

参考：新しいデザインシステムの手法 Atomic Designとは

後ほどご紹介しますが、HRMOS採用のスタイルガイドはWebで作っており、インタラクションまで確認することができます。

今でこそこの形ですが、それまでに課題が色々ありました。

Sketchによるスタイルガイドの課題

当初は、Sketchファイルでスタイルガイドを管理していましたが、Sketchファイルをもとにフロントエンドの実装を進める中で、課題もいくつか出てくるようになりました。

課題①：100％再現されない
新しい機能が追加され、新しいUIやルールが追加された場合は都度、Sketchファイルをアプデートしていたのですが、実際の画面を実装するのはフロントエンドエンジニアで、100％意図した通りに再現されるかは、技術力とリソースに左右されされしまうこと。

課題②：同じUIなのにcssが複数存在する
スピード優先のサービスの場合によくありがちな、同じUIコンポーネントなのにも関わらず同時に複数人で開発することで、同じUIを再現するcssが複数存在し、さらには微妙に違うということ。

課題③：スタティックなファイルでは再現できないインタラクション
細かいインタラクション（例：アニメーションなど）など、感覚で判断するしかないものが多いこと。

課題④：Sketchファイルのアップデートが面倒
機能改修や色変更などが発生した場合、スタイルガイドの対象箇所を変更せねばならず、アップデートが面倒であること。

開発メンバーが増えるにつれ、上記のような課題が顕在化するようになり、なにかしらの対応が必要な状況になりつつありました。

お客様にHRMOS採用のUX/UIを評価頂いてる中、サービス全体で一貫性を保ち、良質な体験を提供するためには、ますますスタイルガイドが重要になってくることがメンバーの中で課題に上がりました。

とはいえ、スタイルガイドを整えて運用していくにはリソースがかかります……。日々の業務をやりながら、サービス内のUIを見直すことは簡単なことではなく、なかなか着手できずにいた中、あることがきっかけで着手することになります。

AngularJS→Angularへのアップデート

HRMOS採用はこれまでAngularJSで開発を行なっており、現在はAngularへのアップデートを進めています。このアップデートをきっかけに、上記の課題を解決できないか考えることにしました。

特に、アプリケーションの規模が大きくなるにつれ、UI（見た目）の部分とアプリのロジックが混ざり、お互いメンテナンスしづらい状況が増えてくるようになりました。また、UI（見た目）の修正はデザイナー＋フロントエンドエンジニア自身の手でアップデートしたいなど、長期的にサービスを運用していく観点でもこのタイミングで課題を解決すべく、UIとアプリを分離することにしました。

UIとアプリの分離

これまでUIとアプリケーション間が密接に繋がっていたのを、UIコンポーネントライブラリとアプリケーション本体で、次のような指針に沿って分離するようにしました。

UIコンポーネントライブラリ

• コードが書けるデザイナーとUI実装に強いフロントエンドエンジニアで開発運用を行う
• デザインに関わるルールはすべてこのライブラリに集約
• （アプリに関わる）実データや状態は持ってはいけない

アプリケーション本体

• 設計に強いフロントエンドエンジニアとサーバサイドエンジニアで開発運用を行う
• アプリケーション内で用いるUIは、UIコンポーネントライブラリから読み込んで使う
• アニメーション、色、フォントなどを指定したい場合は、UIコンポーネントライブラリ側で用意されたSassの変数を利用する
• デザインに関するルール（色・フォントサイズ等）や独自のUIコンポーネントを記述してはいけない

UIとアプリケーションの分離を進めていく中で、メンテナンス性も徐々に上がり、デザイナーとエンジニアの協業体制が少しずつ出来てきました。ただ、どんなUIコンポーネントが揃っているのか、全体像を把握しにくい状況でしたので「デモアプリ（＝動くスタイルガイド）」も合わせて開発しようということになりました！（やっと本題です笑）

動くスタイルガイド

まずはデモをご覧ください。

動くスタイルガイドのデモ

このように実際に稼働しているサービスとは別に、UIコンポーネントだけを網羅的に見れる動くスタイルガイドにしたことで、たくさんのメリットがあります。

• 見た目だけでなく、インタラクションまで含めて確認ができる（例えば、クリック/ドラッグしたらどう変化するのか把握できる）
• デザイナーはUIカタログ集として利用でき、UIが意図通りに実装されているか確認できる
• エンジニアは、UIをどうやって実装すれば良いか、ソースコードの見れるリファレンスガイドとして活用できる
• 新メンバーが加わった際も、一貫性を保つことができ、理解を早めることができる

プロジェクトメンバーからも良い反応があります。

デザイナー：

• 見た目の軽微な修正・改善を行なう開発タスクに参加しやすくなった
• デモアプリによって、多数のUIコンポーネントを網羅的に見えるようになり、一貫性を保つ努力がしやすくなった

フロントエンドエンジニア：

• UI側とアプリ側の分業ができるようになり、それぞれの得意分野に専念できるようになった
• UIコンポーネントを活用することにより、新しい機能を高速開発できる土台にできる

サーバーサイドエンジニア：

• フロントエンドもやってみる気持ちが湧いてきた
• デモアプリのコードの書き方を参考にすれば、意識せずともスタイルガイドに沿うかたちで画面を実装できる

今後の課題

これまで良いことばかりを述べて来ましたが、もちろん課題や改善点もあります。
特に、フロントエンドエンジニアにタスクが集中しやすいこと、開発工数がかかることが欠点として挙げられます。

スタイルガイドにリソースを割くべきか問題は、どこでも起こり得ることだと思いますが、サービスにおいて長期的なビジョンがあり、統一したUIで複数のアプリケーションを素早く展開したいような状況下では、スタイルガイドの策定とデモアプリ化は有効と考えています。

最後に

以上、当日イベントでお話させていただいた内容をお届けしました！

当日感じたのは、どこもスタイルガイドの必要性を感じていて、色々試行錯誤しながら作っているんだなということでした。

さらに、

• 日々の業務に追われて、スタイルガイドを作る時間を捻出することが難しい
• スタイルガイドの作成にリソースを割くことを会社に理解してもらうにはどうするか

といった声も多く聞きました。

しかし、スタイルガイドの必要性を一番に感じているのは現場であり、サービスの拡大やメンバーの増員など長期的な視点で見たときには、スタイルガイドがあることが強みとなることは確か。わたしたちも道半ばですし、まだまだ課題があって試行錯誤を重ねている中で、まずはできることからはじめてみようと日々改善中です！

イベントではお伝えしきれなかった詳細は、今後ブログでスタイルガイドの作り方というシリーズでお伝えしていこうと思いますので、ぜひお楽しみに！

※2019年6月14日に「HRMOS採用管理」は正式名称を「HRMOS採用」に変更しました。