カオナビのデザイン組織は、ブランド / プロダクト / マーケティングの3つのデザインチームに分かれています。
その中の一つ、プロダクトデザインチームでは、いわゆる「DesignOps」と呼ばれる取り組みを継続的に行ってきました。特に2023年の夏頃から、より一層力を入れ始めています。例えば、Figmaの運用方針の整備やチーム内のコミュニケーション機会の改善など、大小様々な改善を行ってきました。
その目的は「誰もが使いやすいUI、心地よいUXを目指すことによってカオナビのファンを増やしていく」というカオナビにおけるプロダクトデザインの役割に対して、無駄なことに時間を使わず、100%集中できるように、様々な障壁を取り除いていくことにあります。
なぜこのようなことに力を入れているのか、その背景や取り組んできたことをまとめたいと思います。
カオナビ プロダクトデザインチームには現在10数名のデザイナーが所属しています。また、現在カオナビには20以上の機能があり、常に10数チームの開発ラインが走っています。開発チームは担当機能ごとに縦割り型になっていて、PO、エンジニア、デザイナー、QCがそれぞれに所属しています。
2022年1月時点ではデザイナー4名体制でしたが、2024年7月には10数名体制になるなど、プロダクトデザイナー数が一気に増加していきました。
メンバー数が増えることは、それだけカオナビにおけるプロダクトデザイン領域の重要性が増していることの表れであり、身が引き締まる思いです。
一方で、少数のデザイナーで活動していたフェーズから、一気に10名以上の体制となったことで、今までのチーム運営ではうまく回らないことも増えてきていました。
カオナビは機能数も多く、前提としてキャッチアップするべきことが多い ( どんな機能があるか、どんなコンポーネントがあるか、機能ごとの整合性は...など) 性質にあります。
また、前述の通り、複数の機能や開発ラインに分かれてデザインをすることが多いため、カオナビ全体のUIや体験の統一感を生むためにもデザイナー同士の連携が重要です。
しかし、新メンバーが増えていく中で、人によってUIの作り方が違っていたり、こまめなコミュニケーションが取りづらくなることで、似た機能だけどUIが違う...といった状況が生まれていました。
機能ごとにUIの差分があることで、導入を検討するお客さまから、競合サービスとのUIのクオリティを比較され失注してしまうことも起こっており、このタイミングから上記のような課題を解消していかないと、カオナビのプロダクトとしても、デザイナーとしても苦しい状況になってしまうと考えました。
カオナビは人事の方だけでなく、経営層、社員の方々に日々ご利用いただくサービスですから、誰もが使いやすいUI、心地よいUXを目指すことによってカオナビのファンを増やしていく。それがプロダクトデザインの役割です。
特に現在は、「UI改善」「ウェブアクセシビリティへの対応」「未来のカオナビのUIを描く」といった、ユーザビリティを高めつつ将来に向けて投資していくことに注力しています。
一方、プロダクトが成長したり、人員が増えたり、ツール等の環境が変わっていくと、今までのやり方ではうまく回らないことも増えていきます。
その中で、生まれてくる障壁を取り除き、本来プロダクトデザイナーが担うべき役割にまっすぐ向き合えたり、余計なことに時間を割かなくても良い状態を保つことが大切だと考えています。
このような考えで、今まで取り組んできたことをピックアップしてまとめていきます。
プロダクトデザインチームで使用している、Figmaファイルの構造や運用方針を整備しました。
デザイナー数が少なかった時は、(カオナビ歴が長い人も多かったので) ファイルの切り方やデータのまとめ方など、ある程度の共通認識を持って運用することができていました。
ただ、デザイナー数も増え、カオナビの機能も増えていく中で、Figmaの運用方針が定められていないことによる課題がいくつか生まれはじめました。
特にFigmaファイルはディレクターやエンジニアなど様々な職種の方も扱うため、個々人が自由にファイルやデータを作ってることで「Figmaのどこを見たら良いのか分からない」「人によってデータの作り方が違っていて、分かりづらい」といった声も生まれていました。
そこで、Figmaのファイル構造や運用方針を整備することで、効率的にカオナビのUIを作ることができたり、誰が見ても分かりやすい状態を目指しました。
例えば、ページ構造について。最新のマスターデータ、検討中のデザイン、ボツ案、その他の資料など種類やステータスによって使用するページを切り分けることで、全体像を把握しやすくしています。
また、デザインのステータス管理についても、デザイナーやエンジニアなど、誰が見てもすぐに「開発準備が完了しているか」が分かるような工夫を取り入れています。
他にも、人によって書き方がぶれがちなデザインメモ ( デザイン仕様の補足や、意図の記載、修正点のメモなど ) 書き方についても、推奨方法をまとめておくようにしました。
プロダクトデザイナー全員で、毎週1時間実施している「デザイナー定例」の運用方針を見直しました。
今までは「進捗確認」「対応中チケットの確認」「困りごとの確認」という全ての項目に対して、全員が各々の状況を共有しながら話すような時間の使い方をしていました。
一方、参加メンバーが一気に増えていく中で、有効に時間を扱いづらくなってきていました。
デザイナーが各機能やプロジェクトに分かれて活動する中で、チーム横断で集まって注力の認識を揃えたり、各々が抱えている問題を素早く解決していくためにも重要な機会であるため、より有効な時間の使い方にできないか？と考え、運用方針を見直すことに。
主な変更点としては「部ごとに話すべきことと、全体で話すべきことを分けて扱う」「定例の時間内で結論を出すのが難しいトピックは、決定会という別の機会を設けて扱う」の2点です。
結果として、定例ミーティング内での会話量もぐっと増え、ただ単に情報共有をするだけでなく、意思決定も行いやすい場になってきています。
カオナビ プロダクトデザインチームでは、隔週で30分の「デザイナー勉強会」を開催していました。週ごとに予めテーマを決めておき、有志がテーマに対して学びになるような資料やアウトプットを持ち寄って共有するような場として運用していました。
一方で、メンバーが増えていく中で、参加ハードルが少しずつ高くなってきていました。謙虚な方も多いため、「皆にとって学びになることを、自分が話せるほどじゃないかも...?」と思ってしまう場面もあり、結果として勉強会が開催されず流れてしまうことも増えていました。
そこで、勉強会の位置づけを「有志がナレッジをシェアする場」ではなく、もっとラフに「話したいことを話せる場」に変更することで、気軽に参加して会話したり、困り事を解消しやすいようにしました。
企画名も「ユンタク (※ 沖縄で「おしゃべり」という意味。食後にお茶を飲みながらおしゃべりするイメージ)」 に変え、話したいことについても予めストックしておくことで、気軽に参加出来るようにしています。
結果として、「〇〇について話したいです！」というメンバーも増えていき、デザイナー間で気軽なコミュニケーションを取れる重要な機会になっています。
上記に加えて、大小様々な課題を解決するために取り組んでいます。
先日リニューアル・公開したカオナビのデザインシステム「sugao」もその1つです。
同時に公開したCocodaの事例にも記載している通り、デザインシステムの位置づけを「コンポーネントを整理し、開発効率を高める」から、「開発組織全体で”お客さまにとって使いやすい体験”に共通認識を持つ」へとアップデートしていきました。
他にも、新メンバーのオンボーディングコンテンツとして「sugaoチャレンジ」を開始しました。
入社したてのメンバーに対して、sugaoについての説明を行ったあと、実際にsugaoを使った簡易なデザイン作成をしてもらう時間を設けています。
メンターが隣で一緒に作業しながら「こういうコンポーネントの作り方をしています」「こんな時はこのパーツを使います」など、細かい説明を交えながらsugaoに触れ合ってもらう時間を作っています。
さらに細かい改善なども、日々気づいたときに取り組むようにしています。例えば、Figmaファイルのサムネや、作業用コンポーネントの整備などなど...。
色々と取り組んできたことをまとめましたが、このような仕組みを「作ったことで満足」しないように気をつけています。実際に運用してみて、振り返りをして、必要あらばもっと改善していくというスタイルを大事にしていきたいと思っています。
改めて、プロダクトデザインの役割は「誰もが使いやすいUI、心地よいUXを目指すことによってカオナビのファンを増やしていく」ことにあります。
今まで取り組んできているDesign Ops活動も、ただ単に効率化しよう、無駄を省こうといった「仕組みをつくること」が目的ではなく、デザイナーが本来の仕事に集中できるようにすることが目的です。
また、「個」の力が開かれ、誰もが社会で活躍できる未来を思い描くカオナビだからこそ、カオナビで働くメンバーにとっても、個の力をしっかり発揮できるような環境を作っていきたいという思いもあります。
これからも、カオナビを素晴らしいプロダクトにするために、チームで協力しあいながらデザインに取り組んでいきたいと思います。