デザインシステム構築におけるオーナーの重要性
こんにちは。ユーザー体験を最高にする活動をしているチーム、通称 Mantle チームのプロダクトオーナー(PO)をしている sakito です。
Mantle チームでは、ユーザー体験を最高にする活動の 1 つとして kinotne のデザインシステムを作っています。この記事では、デザインシステムを作る上での PO の役割や、PO がいることによる効果を実際の事例と合わせて紹介します。
デザインシステムは成長するもの
デザインシステムは作って終わりというものではありません。組織やプロダクトの変化に合わせて、デザインシステムも成長させていく必要があります。初期に設定した課題から導いた理想やロードマップも、その都度修正していく必要があります。
デザインシステムを作ることだけが目的になってしまうと、最初の「完成」をもってメンテナンスされないといったことも起こりえます。
デザインシステムにおけるオーナーの必要性
持続的にデザインシステムを成長させるためには、専属のチームを設けるとともに PO を立て、デザインシステムに責任を持つ人が必要だと考えています。特にデザインシステムを構築する段階では、オーナーの有無がシステムの完成度や、その後の運用に大きく影響を与えるのではと感じています。
kintone のデザインシステムを作っています
冒頭で触れたとおり、現在 kintone のデザインシステムをチームで構築している最中です。このチームで私は PO として、デザインシステムを作る旗振り役やロードマップの策定を行っています。
Mantle チームがどういった構成でどうデザインシステムの構築を進めているか、PO としてどのようなことをやっているかを紹介します。
Mantle チーム全体の取り組みについては以下の記事をご覧ください。
Mantle チームではスクラムで開発を行っています。PO の役割はチームやスクラムの構成に依るところがあるので、まず初めにチーム構成と 1 スプリントの流れを紹介します。
Mantle チームの構成
Mantle チームは、次のような役割で構成されています。
プロダクトオーナー(PO)
スクラムマスター(SM)
デザインテクノロジスト
デザイナー
エンジニア
アクセシビリティ
QA
このうちデザイナーとエンジニアの中には、副業で関わってくれているメンバーも居ます。
1 スプリントの流れ
Mantle チームは kintone フロントエンドリアーキテクチャ（フロリア）プロジェクトの 1 つのチームです。フロリアプロジェクト全体では 1 週間を 1 スプリントとして扱っており、都度必要なスクラムイベントを行っています。
プロジェクト全体のスクラムイベントとは別に、Mantle チームでは次のスクラムイベントがあります。
デイリースクラム
スプリントの進捗などで困っていること、障壁になっていることなどの確認
リファインメント
バックログの優先順位づけ・詳細化・分割・見積もり
プランニング
次スプリントのためのゴール設定、バックログアイテムの選定などの作業計画
レトロスペクティブ
スプリントの振り返りを話し合い、次スプリントの改善などを決める
デザインシステムの PO としての役割
ここからは実際にデザインシステムの PO として行っている役割や効果を紹介します。
自分たちの目指すデザインシステムの姿を明確にする
デザインシステムのプロジェクトを始める際、自分たちのデザインシステムが目指す理想や対象となる範囲を決め、その次に遠い未来の理想を明確にしました。デザインシステムは広い意味を持っている抽象的な概念なので、自分たちがデザインシステムを作ることで何を目指しているのかを明確にすることで、デザインシステムに必要な成分が決まってきます。
これらを明確にすることで、デザインシステムに何を含めるべきか、何を含めないべきかを決める判断基準と、その判断の根拠にもなります。
下記が Mantle チームの理想の一部になります。
デザインシステムの提供
・各アプリケーション開発チームが主体的に品質の高いアプリケーションを素早く開発できるようになることを目指す
・ 貫性のあるユーザー体験やデザインの品質をユーザーに提供できること
デザインシステムのロードマップを決める
自分たちの目指すデザインシステムの理想を元に、まずは 1 年間で達成したい目標を決め、次に 1 年間を 3 か月ごとのクォーターに分けて 1 つのクォーターごとに達成したい目標を決めました。遠い未来の目標は抽象度が高く実現が難しくなるので、直近の目標はブレイクダウンして目標実現のために細かく現実的なロードマップにします。
ロードマップは日々のメンバーとのコミュニケーション、バックログを決める指針になっています。また、目指すべき理想とずれないように、都度メンバーにはロードマップや目標の意図を伝え、メンバーとデザインシステムの目標を照らし合わせています。
目標を正しく共有することで、細かいバックログアイテムの消化や他チームとのコミュニケーション時に PO が不在であっても理想に沿った形で進められるため、理想のデザインシステムに近づいていけています。
バックログの作成と優先度を決定する
ロードマップの策定後、ロードマップを元に具体的なバックログを作成します。
この先 3 ヶ月 〜 1 年のロードマップを明確にしてあるので、それらの達成に向けてのバックログアイテムを作成し、優先順位を決めます。デザインシステムを構築する中で、日々やらないといけないことの優先順位と内容をバックログによって明確にすることで、メンバーたちが日々行動しやすいようにしています。
また、同期的に動くことが少し難しい副業メンバーには 1 つのバックログを渡して、非同期でバックログアイテムを消化してもらっています。
学習をバックログに取り入れる
私は PO としてバックログの内容と優先度に「学習」の要素を入れるように意識しています。Mantle チームでは知識やスキルの向上を目的としたバックログを「学習バックログ」として開発やデザインのバックログアイテムに並べています。
学習バックログアイテムをバックログに組み込むことで、ほかのタスクよりも優先してメンバー全員が学習に取り組めることを明確にでき、チームとして 1 つのスキルを得ることができます。
プロジェクト立ち上げ初期には「デザインシステムの本を読む」という学習バックログアイテムを作成して、最優先のバックログとしました。このバックログに全員で取り組むことで、チーム内でデザインシステムの用語の統一や、取り組んでいる内容の説明・意図に関しての理解が深められ、チームとして目標に向けて走り出すことができました。
学習バックログのほかにも、ドキュメント作成などデザインシステムを構築する上で必要なことをバックログアイテムにしています。こうすることで、デザインシステムに必要な開発、デザイン以外の用意しなければいけないものなどの認識をチーム全体で整えることができています。
デザインシステムにはデザイン、フロントエンド、アクセシビリティなどさまざまな知識が求められます。Mantle チームメンバーは各職能のエキスパートのようなスキルを持っている人が集まっているので、スキルのシェアができる仕組みを作り、メンバー全員が各領域において同じくらいのスキルを持っているチームにしていきたという思いからも、学習バックログの作成以外にも週１勉強会を行い、メンバーで知識を共有し合う取り組みを行なっています。
デザインシステムを浸透させていくために
デザインシステムは作るだけでなく、作ってからどう運用してくかも重要です。今回紹介した取り組み以外にも、関係各所とのコミュニケーションやデザインシステムを浸透させていくためのインナーブランディングについて日々考えています。
これらの役割をこなし、デザインシステムを 1 つのプロダクトのように運営するオーナーがいることは、デザインシステムを運用するために不可欠だと感じています。
デザインシステムを一緒に成長させるメンバーを募集しています
サイボウズではデザインやフロントエンドのスキルを活用し、デザインシステムを通じて kintone のユーザー体験を最高にしていくメンバーを募集しています！
デザインシステムのプロジェクトに直接入らずとも、kintone のプロダクト開発を通じてデザインシステムを一緒に育ててくれる方も大歓迎です！
ご応募お待ちしています！