BIZREACH DESIGNER BLOG

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

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

浅井 雅彦 (Masahiko Asai)

浅井 雅彦 (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で複数のアプリケーションを素早く展開したいような状況下では、スタイルガイドの策定とデモアプリ化は有効と考えています。

最後に

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

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

さらに、

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

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

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

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