freeeの開発情報ポータルサイト

チーム全員で取り組む「デザインガイドライン輪読会」のすすめ

サムネイル

この記事は freee Developers Advent Calendar 2024 の6日目です。

adventar.org

こんにちは! freeeで基盤プロダクトのデザイナーをしているnachanと申します。

ちょうど今日誕生日です 🎈 昨年と一昨年も12/6にアドベントカレンダーを投稿し、誕生日に投稿するのはこれで3回目になります。すごいですね。


本題ですが、デザインガイドラインは、プロダクト開発の一貫性や品質を支える重要な基盤です。 しかし、その存在を知りつつも、実際の現場では十分に活用されていなかったり、形骸化してしまうことも少なくありません。 この記事では、私が開発チームのメンバーと一緒に実践した「デザインガイドラインの輪読会」の取り組みとその成果についてご紹介します。

ガイドラインの現状と課題

私は元々エンジニアでしたが、デザイナーに異動したキャリアがあります。 異動した当初、ガイドラインの内容や背景を十分に理解しておらず、結果的にその意図に沿わない設計をしてしまうことがありました。 このような状況は、チーム内だけでなく組織全体で以下の課題を引き起こしていました。

  • ガイドラインが抽象的な部分が多く、実務での適用方法がはっきりしていない
  • 職種やチームごとにガイドラインの理解度や認識に差がある(存在を知らない人もいた)
  • ガイドラインの管理チームが曖昧で、有志による追記や修正が行われページによっては情報のばらつきが生じている
とある画面の例:

権限についてガイドラインには下記のような記載がありますが、ガイドラインと反した設計がされている画面が存在していたりします。

権限によりその機能を使うことができないユーザーには、機能を非表示にします。 権限は(管理者でない限り)自分で変更できず、かつ頻繁には変更されません、そのため、ユーザーは「自分の権限の有無」を意識せず、意識しないものは表示する必要がありません。

実際に存在する画面

「該当する操作のアクセス権限がありません。」とエラーで大きく表示されている
機能を非表示にすべきなのに、表示してしまっている

全社的に課題となっていましたが、まず自分のチーム内でガイドラインの理解を深める必要があると感じ「デザインガイドライン輪読会」を始めることにしました。

輪読会の目的と効果

輪読会の目的は以下に設定しました。

  • みんなで知見を深め、認識を統一する

ガイドラインに書かれた内容の意味を互いに理解し共有し、知見を深める

  • ガイドラインの背景も理解する

ただ内容を把握するだけでなく、「なぜその記載になっているのか」という背景も学び、納得してからプロダクト開発に落とし込む

  • ガイドラインを全職種で活用する

エンジニアやPM、QAなど、すべての職種がガイドラインを活かせるようにすることで、より一貫性のある開発体制の構築を目指す

輪読会の進行方法

開催頻度と時間

週1回、1時間

参加メンバー

PM、エンジニア、QA、デザイナー

(つまり開発チーム全員)

進行方法

当日読書型

事前読書型だと読んでくるのを忘れてしまったり、作業負担になる可能性があるため当日読書型を選びました。 私が毎回読む範囲を指定し、参加者が10分間で内容を黙読します。 それぞれが感想や意見をまとめ、一人ずつ発表し、他のメンバーがコメントや意見を追加する形式にしました。

輪読会が終わったらガイドラインに関するフィードバックを整理し、必要に応じてドキュメントの修正をバックログに追加したり、私が直接修正してレビューを依頼することもありました。

輪読会の成果

ガイドラインに基づく開発ができるように

チーム全員がガイドラインを現状の開発しているプロダクトに適用する方法を検討することで、具体的な適用方法が明確になりました。 実際に、エンジニアが実装中にUIについて疑問に感じたことがありましたが、ガイドラインを参照することで即座に解決した例があります。

(slackの会話)「grooveに書いてあった。操作だからEscで消せないが正しいらしい。 選択しているアイテムに関する編集操作 例: 自動で経理で選択している明細の取引登録モーダルを開く モーダルを閉じる:Esc Vibes のタスクダイアログのような、モーダル上でユーザーに操作を要求するようなものの場合は Esc で気軽に消せないようにする 中身を見て終わりのものは Esc で消せるようにする 」「たしかにGroove輪読会で見覚えがある :sore: 1 」「やっててよかったgroove輪読会」
デザイナーに問い合わせしなくてもエンジニア同士で解決した事例

※Groove=デザインガイドライン。今は改名して"デザインガイドライン"となりましたが前までGrooveと呼称されていました

古い記載や構造の改善

ドキュメント内の不整合や古い記載を発見し、次々修正を行いました。ガイドラインとして歴史が長いのと運用チームが曖昧だったので直すべきところは非常に多かったです。

例: 全社的に方針が変わったがガイドラインは追従していないページの修正、使われていない古いツール名の更新や、不要なSlackチャンネル名の削除。(そもそも固有名詞をガイドラインに書くこと自体あまり良いことではない)

チームビルディング効果

過去の経験や視点を共有する場としても機能し、チームの一体感が高まったように感じました。当初予想していなかったですがチムビルとしても副次的効果がありました。

参加者からのポジティブフィードバック

デザインガイドラインをテーマにした輪読会を通じて、参加者から多くの前向きなフィードバックが得られました。

  • デザインガイドラインを自分たちのプロジェクトと重ねて議論することで、開発領域の理解が深まった。
  • 知らないことが多いことに気づいたが、議論を通じて具体的な事例や適用の精度が向上した。
  • 自分とは異なる視点(開発やQAなど)から様々な観点を内容に落とし込めた。一人では思いつくことがなかった。
  • 身近なプロダクトを例に出すことで、共通の課題や性質をより深く理解することができた。
  • 単純に良いプロダクトにするぞという意識が高まる時間になっていた。
  • freee全体での課題や、デザインガイドラインの適用可能性について新たな視点を得られた。

次のステップ: 新しいデザインシステムへ

「デザインガイドラインの輪読会」を通じて、プロダクト全体の一貫性や品質向上に一定の成果を得ることができました。 そして、現在freeeでは次のフェーズとして、コンポーネントレベルでのデザインシステムではなく、パターンレベルでのデザインシステム「標準UI」の整備を進めています。「標準UI」ができることでデザインガイドラインも新しく生まれ変わる予定です。 「標準UI」は、プロダクト全体の統一性をさらに高め、デザインと開発のスピードを向上させることを目指しています。このシステムにおいても、ガイドライン輪読会で得た経験を活用していきたいと考えています。

標準UIについての詳細資料

未来へのビジョン

「標準UI」を活用することで、次のような未来を実現したいと考えています。

エンジニアでも画面が作れる環境

ガイドラインに沿って標準UIを利用することで、デザイナーの関与がなくてもエンジニアが一貫性のある画面を構築できるようになります。

プロダクトのスピードアップと品質向上

デザインと開発がシームレスに進むことで、開発効率が大幅に向上し、より高品質なプロダクトを迅速に提供できるようになります。

この未来を実現するために、新しくできるデザインガイドラインと標準UIの両方の理解が必要不可欠です。 新しいデザインガイドラインがスタートしたら今回の経験を活かして輪読会を実施し、プロダクト開発の品質向上に努めたいと思います!