デザインシステムで解消するさまざまな分断

デザインシステムを導入・制作する際にチームが体験した障害をどのように解決していったかについてお話しします。

Transcript

1. デザインシステムで解消する さまざまな分断 合同会社DMM.com プラットフォーム事業本部 フロントエンドグループ 平田彩夏
2. 自己紹介 平田彩夏 デザイナー5年目。主に事業会社でtoC向けのサービスのUIを担当 2022年4月中途入社 プラットフォーム事業本部 フロントエンドグループ所属の最初のデザイナー DMMのサービス全体を支えるデザインシステムTurtleを開発・運用
3. 目次 - 導入 - DMMの紹介 - デザインシステム「Turtle」の紹介 - 本題 - チーム内の分断 - 利用者との分断 - 今後の展望
4. まず私たちDMMについてお話しさせてください。 私達は、「誰もが、見たくなる 未来。」をコーポレートメッセージに掲げ、様々な事業領域でサービスを展開しています。
5. 具体的に言うと、60以上の事業を展開し、ゲーム事業から水族館まで、やっていることは多岐にわたります。会員数はざっくり4100万人で、たいへん多くのユーザー様にご利用いただいています。
6. そんなDMMのサービスの基盤を支える部署が、プラットフォーム事業本部です。プラットフォーム事業本部では、決済やユーザーページ、ポイント管理など、DMMサービスに必要な裏の部分をメインで支えています。
7. そのなかで、今回お話しするデザインシステムの制作を行なっているチームがプラットフォーム事業本部 第3開発部フロントエンドグループのエコシステムチームです。 メンバーは、デザイナー4名、エンジニア1名です。
8. 「最高のプロダクトをエンドユーザーに最速で提供する」をチームミッションに据えて日々、業務に勤しんでいます。 主務は、monorepoというフロントエンドのエコシステムの提供や、コードレビューによる技術水準の向上をおこなっています。フロントエンドグループという名の通り、メインはフロントエンドの技術向上をおこなっていますが、フロントエンドを整備する一環として、デザインシステムの開発も行っています。
9. それでは、私たちが製作するデザインシステムTurtleについて、紹介させていただければと思います。 「Turtleデザインシステム」は、先ほども説明した通りプラットフォーム事業本部が制作した、デザインシステムで、主にフロントエンドの煩雑化を防ぐために開発されました。 では、DMMにデザインシステムがなかったのか？というと、そうではありません。ただ、事業部ごとにデザインシステムが存在し、それぞれ事業部のデザインにトンマナが寄っていたり、事業部特有のUIに特化していたりして各サービス毎に見た目が大きく違い、UIの品質にバラつきがある状態でした。それ を解決するべくDMM全体のサービスを支えるデザインシステム「Turtle」が作られました。
10. 「Turtle」の現状 Turtleでは、基本的なDesign Token 、たとえばタイポグラフィーやスペーシングなどが、Figmaのデザインデータ、実装、仕様ドキュメントが提供されています。
11. 「Turtle」の現状 また、カラーパレットも意味付けがされているaliasTokenと呼ばれるものと、より汎用的に使用できるGlobalTokenと呼ばれるものが用意されていて、利用者によって、カラーのカスタマイズが行える状態になっています。カラーはlightとdarkが対になり提供されているため、Turtleのカラーシステムを使用することで、勝手にダークモードに対応するようになっています。
12. 「Turtle」の現状 また、MUIはAdobe Spectrumのように、標準となるコンポーネントも20個近く制作されており、利用者はこのUIコンポーネントを使用することで、簡単に画面設計ができるようになっています。 そして、コンポーネントはwcag2.1 達成基準シングルAの基準に一部準拠しているため、利用者にアクセシビリティの知識がなくともアクセシビリティが考慮できるようになっています。 既に、プラットフォーム事業本部が開発しているマイページやポイントクラブなどで導入されており、 今後は、DMM全体に広げていきたいと考えています。 出典 https://www.jidaikobo.com/archives/34.html
13. ここまでの話で、Turtleはかなり成熟したデザインシステムであるように感じた方もいるかもしれません。 しかし、そうでもないんです。 なぜ、Turtleはまだまだ伸びしろのあるデザインシステムなのかを説明するには、プロダクトライフサイクルに当てはめるとわかりやすいかもしれません。 プロダクトライフサイクルとは、プロダクトの成長過程を4つの段階に分けることができるフレームワークです。 段階は、「導入期」「成長期」「成熟期」「衰退期」の4つに分けられます。
14. 導入期は：製品を市場に投入する段階で、需要も小さく売上も大きくありません。そのため利益はほとんど出ません。
15. 成長期は：売上と利益が急拡大する段階で、競合他社も増加します。消費者ニーズも多様化するため、製品改良や差別化戦略が重要になります。
16. 成熟期は：市場の成長が鈍化し、売上も利益も頭打ちになる段階です。
17. 衰退期は：値引き競争が頻繁に行われるなど、撤退時期を判断することもあるフェーズになります。
18. では、プロダクトライフサイクルがわかったところで、この4つの段階をデザインシステムの開発に置き換えて見ましょう。 デザインシステムとしてのアイデンティティを確立する DesignToken/必要最低限のコンポーネントなどの提供する などの開発は。導入期に行われる作業です。 導入期では、デザインシステムのプロダクトとしての最低限の機能や品質が求められ、デザインシステムを一つのプロダクトとして見た時に、そのプロダクトの完成度を高めることが必要とされます。 ひとつのプロダクトとして、市場に投入しようと準備をしている段階なので、ここでは売上はありません。 そういう点でいうと、複数のプロダクトに組み込まれた実績があることから、Turtleは導入期は過ぎたと言えるでしょう。
19. では、Turtleは成長期にいるのでしょうか？ 社内を市場に見立てた場合 DesignToken/コンポーネントの拡充 をし、製品は改良されている段階になっています。ほかにも、消費者（利用者）の声を受け、 既存/新規プロダクトへの組み込み 利用者へのサポート が行われてきました。 成長期で期待されること、「デザインシステムのプロダクトとしての品質向上」と「事業に組み込まれていくこと」はクリアしています。 しかし、「社内の認知拡大」にはまだまだ改善の余地があり、成長期にいききれない形になっています。
20. デザインシステムで解消される分断 1 チーム内の分断 2 利用者との分断
21. 私たち、フロントエンドグループは、2022年の初めの方はデザイナー2名、エンジニア2名のチームでしたが、1番多い時はデザイナー4名、エンジニア6名までチームメンバーが増えました。 メンバーが増えたことで、グループとしてやりたいことができるようになったり、Turtleの開発はより加速化すると思っていました。
22. しかし、人数が増えるとメンバーそれぞれで、タスクに対する優先度が異なり、デザイナーだけに絞っても、ひとりはドキュメントの整備を優先すべきタスクだと考え、ひとりはアクセシビリティの確保が最も重要なタスクだと主張するなどチームは混乱していました。
23. このような状況はレビュー時にとくに顕著に表れ、「何でその作業が必要なの？」と言った質問がされるようになりました。結果として、タスクがスムーズに進行せず、手戻りを生むこととなり開発の進行に大きく支障をきたしました。 このような状況は、タスク以外にもミーティングの発言が一部の人に限られるなどチーム内の空気に影響しました。 チーム内で分断が起きていることが明らかになりました。
24. そこで、仮説を立ててチーム内の分断を解消することになりました。 まず、仮説1つ目は、 「ゴールイメージ」の共有がされていないので、作業のゴールがずれてしまったのではないか？
25. なぜそのように考えたかと言うと、Turtleのプロダクトゴールが不明確になっていたためです。 プロダクトとしてのゴールが常に明確になっていれば、チームメンバーは迷わないはずです。しかし、当時はPOが不在で、ロードマップも古いまま放置されているなど、問題が放置されている状態でした。 チームが小さいうちは、チーム内で情報が断裂することはありませんでしたが、チームが大きくなっていくとともに、大きな問題に発展していったとかんがえました。
26. 2つ目は、思考プロセスが個人にとどまっているので、作業途中のミスに気づけないのではないか？です。
27. こちらも、仮説に至った経緯をお話しさせてください。 私たちは、完全リモートワークのチームです。そのため、その人がどう考え、どのように仕事をしているのか？について、オフラインのチームよりキャッチアップが難しい状態です。また、仕事以外にも、何気ない会話やメンバー間の個人的な交流機会が少ないため、「この人だったらこう考えるかもしれない」「あの人だったら、こうするだろう」といった推測がしづらい状態でした。そのため、思考プロセスが自分のなかだけにとどまることは、成果物がでてくるまでがブラックボックスになることと同じ意味になってしまい、大きな手戻りが発生する原因になっているのではないか？と考えました。
28. 2つの仮説を立てましたが、そもそも、チームが混乱している状態は正常なのか？疑問に思った私は、チームの成長段階を見える化できないか？と思いました。 そこで役に立ったのが、チームの発展段階をタックマンモデルというフレームワークに当てはめてみることでした。
29. タックマンモデルとは、チームの発達や進化を説明するための理論です。このモデルは、チームが経験する5つの主要な段階を説明しています。 この図に私たちチームを当てはめると、混乱期にいるのではないか？と考えました。 なぜなら、混乱期というのは、チームメンバー間の意見の相違や目標の違いがはっきりと現れ、対立や争いが頻発するのが特徴的な時期と書かれていたからです。 混乱期を脱出し、次のステージへチームをもっていくのに重要になってくるのが、「共通のゴールを設定すること」「オープンに知識を共有し合うこと」「コミュニケーションの量を増やすこと」です。これにより、チーム内で共通言語が確立し、意思疎通がスムーズに行えるようになると書かれていました。 そんな訳で、2つの仮説と、タックマンモデルからヒントを得て、私たちはいくつかの改善施策を行いました。
30. まずは、Turtleの存在意義をブレストしました。 「Turtleのゴールとは何か？」「誰に使ってほしいのか？」というプロダクトの価値に関わる大きな議論から「ドキュメントの言葉遣いのレベル感」「Figmaの運用方法」など、チームの運用に関わる具体的で小さいことまで、とにかくTurtleについてチーム全員が解像度の高い状態になっていることで、タスクの優先度が明確になりました。 Turtleの存在意義をブレストすることは、チームが目指す方向性を合わせていく第一歩になりました。
31. その第一歩を踏まえて、次に行ったのが「Turtleのプロダクトビジョン」の決定です。ここでは全チームメンバーが、自分が思うTurtleが目指すゴールやプロダクトの価値を議論しました。 その結果からプロダクトオーナーがTurtleのプロダクトビジョンを策定し、一緒に目指すべき最終的な成果を明確にしました。 ゴールを明確にすることで 最初はミーティングで発言をするのは、特定のメンバーのみに絞られるといった状態でしたが、次第にチームメンバー全員が発言する環境へと変化していきました。 また、何を達成すべきなのか、どんな結果を目指すべきなのかを共有することで開発効率が向上し、認識齟齬が起こりにくくなりました。
32. やったこと3つめとして、「Work Out Loud（WOL）」というアプローチを導入しました。WOLとは、自分の取り組みや考え方をチームメンバーに共有し、プロセスを見える化し、フィードバックを得ることです。 具体的には、新しいコンポーネントの作成や実装に取り組む際、Slackチャンネルでラフに発言します。これにより、メンバーは自分の今行っているタスクを見える化することができます。そして、場合によっては、意見を交換がされたり、アドバイスが行われたりと、そのタスクをWOLした人以外のメンバーが、方向性の違いを初期段階で察知できます。そして、「いまどう言う状態になっているのか？」「あ、ここの解決策しってる！」といったふうなコミュニケーションに繋がります。 特に私たちのグループのデザイナーは、「Figmaの使い方に精通したメンバー」、「アクセシビリティに詳しいメンバー」、など技術レベルにばらつきがあるのが現状です。専門分野が異なるメンバーの集まりなので、それぞれが自身の知識を共有することで、作業効率があがったり、それぞれが、これまでの失敗経験を共有することで、同じ失敗を予防したり解決策を見つけたりすることも可能になりました。
33. 4つ目は、「FIKA」です。 　FIKAとは、「甘い物と一緒にコーヒーを楽しむ」というスウェーデンの文化です。 私たちも「FIKA」を、毎週木曜日の14時から30分間行っています。この時間になるとDiscordに集まって、たわいもない会話から、仕事で困っていることなどどんなTOPICも自由に楽しみます。 というのも、先ほどもいった通り、私たちは基本的にリモートワークをしているため、メンバーの顔を見る機会がほとんどありません。お互い、意識して会話をする時間を設けないと、1日中だれとも口頭で会話することがない日もあります。そうなってくると、メンバー同士の距離感は縮まりませんし、発言するときの心理的安全性も低い状態になります。 パーソナリティを知る メンバー同士の心の距離を近づける 話すきっかけを作る 思考プロセスをオープンにする ↓ そして、心理的安全性が高い状態にすることで、リモートワークでもラフに会話や相談が出来るようになりました。 私たちは、チームとして最高のパフォーマンスを発揮するためには、メンバー同士が互いを深く知り、尊重しあうことが極めて重要だと考えています。
34. これら4つの施策の結果、 Turtleとしての優先度が決まったことで、タスクのゴールが明確になり、手戻りは少なくなりました。
35. しかし、課題は残っています。 レビューポイントが増えたことで、タスクの手戻りは少なくなったものの、リリースまでの時間は短縮しなかったり、WOLやFIKAなどの施策は人の意識の上で成り立つものなので、形骸化しないように目的を常にみんなが意識できるように発信していくことが必要があるといった課題です。 また、最初の課題は、手戻りが多いことをあげましたが、手戻りが少なくなった結果、私たちが本当に解消したかったことは、リリースまでの時間を短縮することだと気づくきっかけになるなどしました。
36. 次にTurtleの利用者との分断を、どう解消していったのか？についてお話しします。
37. セッションの最初のほうでもお話ししたのですが、Turtleは、プラットフォーム事業本部のプロダクトを制作する際の中心的な存在になっていき、複数のプロダクトに導入もされました。 そのとき、Turtleが導入されたプロダクトのデザインは、別の部署のデザイナーさんがおこなってくれていたのですが、
38. そのデザイナーさんたちからTurtle利用時に質問がほとんどありませんでした。 はじめてデザインシステムを使う方もいるなかで、ドキュメントが整備されているとはいえ、質問がもらえないというのは、なにかおかしいと思った私たちでしたが、こちらからどうコミュニケーションをしていけばいいのか？についてあまり考えられていなかったのが現状でした。 そのため、利用者が、どのようにTurtleを使用し、どのような場面でつまづいているのか？について、解像度が低い状態でした。
39. その結果、独自実装が進んでいる箇所があったり、ドキュメントの読み合わせを開発者である私たち抜きで行っていたりなどの事象がありました。 そこで、こちらも仮説を立てて行動に移すことで、問題を解消できないかと試みてみました。
40. まず、1つ目の仮説は「知らないことを知らないので、質問やフィードバックが浮かばないのではないか？」です。
41. なんでこの仮説をたてたのか？というと、 皆さんも共感できるところがあるんじゃないかな？と思うのですが、勉強をしていて「どこがわからないか、わからない」状態に陥ったり、わからないことを調べていたら、わからない単語だけでその文章が構成されていて、やる気が一気に落ちた。といった経験はありませんか？ 今出した例は、わかる事柄から派生したことですが、そもそも「わからないこと」「知らないこと」を知らないと、質問がでてきません。 たとえ、知らない箇所がわかっていたとしても、わからないことを別の部署の人にわからないというのは相当なハードルがあるはずです。 そのため、皆言い出せないだけで、「知らないことを知らない」状態なのではないか？と考えました。
42. 2つ目は、「心理的な障壁があるのではないか？」です。
43. 当初、私たちはTurtleを利用して制作を行ってくれているデザイナーや、エンジニアとコミュニケーションをとる機会がほぼなく、関係性も気づけていなかったことから、私たちがそもそも「なんでも質問してください」というスタンスでいることは、伝わっていませんでした。それにより、相手も「こんなちょっとしたことは、質問したらまずいかな？」「知ってて当然と思われていたらどうしよう」といったような遠慮や不安があったはずです。また、DMMはデザイナーやエンジニアが部署ごとに分かれて配属されていることから、部署が別の同僚と気軽に会話できるような雰囲気ではありませんでした。その結果コミュニケーションの希薄化が発生しました。 この問題に対しては、開発者である私たちがコミュニケーションの戦略を立て、積極的にコミュニケーションを行う必要がありました。
44. そこでまず行ったのが、「オンボーディング資料の作成」です。 同期的なコミュニケーションは必要なものの、利用者が多くなった際に対応しきれないこと。ちょっとした質問をする心理的なハードルを考えると、無人化されているものがあったほうがいいため、まずは無人でサポートできる基盤を整えようと始めました。 いままでは、オンボーディングは有人で同期的に行われており、その場でしか得られない情報が多々存在しました。そのため利用者は、必要な時に使い方を思い出す必要がありました。 これを改善すべくオンボーディング資料を作成しました。 これにより、利用者は振り返りたい時に、随時必要な情報を再確認できるようになりました。 また、オンボーディングがあることにより、利用者が1番はじめに読むべきTurtleのドキュメントが明確になりました。
45. 2つ目は「利用者からの質問をドキュメントにまとめる」です。 内容としては、 - カラーパレットのカスタマイズ方法 - WAI-ARIAの学習ドキュメント - OSによるfont-weightの差異を調査したドキュメント など、利用者からの質問をドキュメント化して、知見にしていきました。 質問内容からコンテンツを作ることで何度も同じコミュニケーションを繰り返す必要がなくなり、より本質的なコミュニケーションに時間を割けるようになっていきます。 そして、ドキュメントとして残っているということは、同じ疑問を持つ利用者にも有益なコンテンツを提供できるということです。 これは、情報を口伝するといった、生産的でないコミュニケーションを防ぐことができます。
46. 3つ目の改善策は「Turtle 質問専用チャンネルの作成」です。 いままでは、情報を内側に閉じたくないといった理由で、参加者の多いフロントエンドグループのチャンネルで、質問などを受け付けていましたが、その前提が浸透していなかったことや、人数の多いチャンネルで発言する心理的ハードルを鑑み、情報発信や質問への受け答えができるTurtleの専用のチャンネルを作りました。 情報の集約箇所を明確にすることで、Turtleに関する質問も集まりやすくなり、こちら側からのアップデート情報なども発信しやすくなりました。
47. 4つ目は「ユーザーインタビュー」の実施です。 この施策はもっとも最近行った施策です。手順としては、 - Turtle のヒアリングの目的を決め、情報の一元化による業務効率の向上を仮説としてヒアリング設計 - ヒアリング手順書の作成 - チームメンバーがインタビューを実施しやすくなるよう、ドキュメントにナレッジを貯める ということを何度か繰り返し、結果として、現在は4〜5名のデザイナー、エンジニアにヒアリングをしてフィードバックをもらうことができました。 そして「定期的にこういう意見を言える場面があったら嬉しい」という声もあり、主体的なコミュニケーションを利用者も希望していることがわかりました。
48. これら4つの施策の結果、 利用者から、フィードバックが少しずつくるようになり、問い合わせも数件だが来るようになりました。
49. しかし、チーム内の分断をお話ししたときと同様、今後の課題は残っています。 現状は、こちら側からコミュニケーションを取りに行く形がフィットしているようですが、最終的には利用者からもラフにコミュニケーションをとってもらえるようになるのを目標にしています。 また、いまは「〇〇を追加しました」など報告型のコミュニケーションの取り方が多いのですが、「〇〇をやります。〇〇を企画しています。」といった形で企画段階からコミュニケーションしていくことで、意見が言いやすいのではないか？と考えています。 また、まだまだ専用チャンネルに入ってくれている人は少ないので、より多くの人にTurtleに触れてもらう機会を作りたいと考えています。
50. では、最後にTurtleの今後の展望についてお話しさせてください。 1つ目は、プロダクトの拡張。これは、よりTurtleデザインシステムをプロダクトとして成熟させていくために、ロゴやブランディングに力を入れていくことを目指しています。それに伴い、フロントエンドグループの働き方もよりブランディングが掲げる方向性に沿わせていく必要があるとかんがえています。 2つ目は認知の拡大。 これは読んだままなのですが社内だけでなく社外への認知拡大を目標に、TurtleのWebサイトを開設するなどを行いたいと思っています。 3つ目はチームをより良い状態にしていくこと。です 私たちは、日々スクラムで開発を進めていますが、専任のスクラムマスターがいないなどといった改善の余地があります。 いかがだったでしょうか？ デザインシステムという言葉を聞くと、「見た目の統一」や「サービス体験の一貫性を保つ」ことにフォーカスされがちですが、プロダクトを横断するデザインシステムに大切になるのは、そのデザインシステムを使うことでもたらせる機能や体験といった目に見えないものなのかもしれません。 私たちはこれからも、デザインシステムを通したユーザー体験の向上に努めていきます。
51. 今後の展望 これらを実現するために、新しいメンバーを募集しています！ 興味がある方は、ぜひお話しさせてください。