見出し画像

デザインシステムを開発の文化にしたことで専任チームを解散できた話

MYB

こんにちは。Uniposプロダクトデザイン責任者のmybです。

こちらの記事はSaaS Designアドベントカレンダー9日目の記事になります。遅刻して大変申し訳ありません！！！🎄

2021年のUIリニューアルをきっかけに、サブプロジェクトとして発足させたデザインシステムPJ。

もともとの目的がデザインシステムを開発の品質基盤にすることだったので、PJ発足時からチーム解散を一つの大きな目標にしており、
今年、ついにデザインシステムチームの解散をし、コミュニティ的に現場でissueのある有志で更新&管理されるようになりました🎉🥳

どんなことをやっていたか、ざっくり振り返ってみます。
一つ一つの細かい話をすると長々してしまうので、ゆるゆるシリーズ化します！気になるテーマがありましたら、Xで教えてください！


全体的に目指していたこと

▼大元のきっかけ
2021年の春に、UniposはUIのリニューアルをwebアプリ及びスマートフォンアプリにて実施しました。
そのPJ自体は、持続的なUI構築やアクセシビリティを目的にしていて目的達成はできたのですが、
唯一の失敗が、スピードをとりすぎて、デザイン-システムの一環したコンポーネント設計の優先度を下げたことで、その後の品質管理が超しんどくなり、カオスな状態へ。

▼PJの目的設定

デザイナー、エンジニアにヒアリングしたりアンケートを取ってまとめたもの

▼その他の仕込みや思想
個人的には、品質管理はなるべく環境や仕組みになった方が価値を届けることに集中できていいよね〜という思想もあり、デザインシステムチームが解散して最低限の投資だけでいい状態にしよう！ということも目指していました。

そこに加えて、自分やリーダー層が扱うissueが増えてきたのもあり、仕組み化することでissue管理コストも減らしたいというマネジメント観点もありました。
（権限委譲でもいいのですが、弊社の規模で品質管理ミッションのみを誰に渡すか？という議論がずっと付き纏ってしまうと、門番的になってしまってあんまり本質的解決ではないなーと。）

▼解散マイルストーン
・プロダクトの基盤になるコンポーネントたちが実装できている状態（=ツールがある状態を作る）
　・Unipos独自のコンポーネント
　・一般的なコンポーネント
・現場の開発チームで、デザインシステムを活用できる人が過半数を超える状態(=マジョリティになった）
　・アイテムの開発で、UniposUIを使っていることが当たり前品質になっている
　・各チームの開発を通して、UniposUIを更新・追加できる

さらなるマネジメントの裏目的として、
当時新卒1-2年目のエンジニアが多かったことと、開発の流れ的にデザイナーがエンジニアに仕様を渡すというプロセスになっていたため、エンジニアとデザイナーで共通のissueを捉えることで、職能間の対話力を上げられるといいな〜！というのも考えていました。
それもあって、mtgではissuteに対する目的の合意をとことん話したり、メンバーからもアウトプットしてもらうということを意識的に実施していました。


~以下、やったことを羅列していきます。詳細はちまちま連載していきます~

2021年：課題設定〜PJ発足

2021年 上期（4月〜）：課題合意と投資対効果を対話して予算をゲットする

  • 開発のデザイン〜フロントにまつわる生産性のネックになっている部分を洗い出して課題設定

  • storybookをchromatic使ったり、notionで管理するかなどの技術要求の検討 w/フロントテックリード

    • そもそもElmでstorybook使えるかの調査

    • figmaで管理しているコンポーネントはデザインコンポーネントと呼び、実装が反映されているものをデザインシステムとし、UniposUIと呼ぶことに決定！！

    • UniposUI（デザインシステム）を開発プロセスの中でどのような位置付けにするかの検討

  • フロントテックリードがまさかの退職。でも何とかしないとと仲間集めに奔走する。

  • prodboard(戦略意思決定の座組み)と課題合意&予算調達

    • プロダクトのサイズや事業フェーズ的にもデザインシステム100%コミットするチームを組成するほど大々的に投資できないため、
      Qで20-30人日の予算としてサブプロジェクト的に細く長く実施する。

    • 完全運用フェーズになったら10人日/Q以下を目指す


2021年 下期（10月〜）：初期メンバーチームの組成

  • pjへの要求が固まったのでpjチームを再構築

  • 最初の準備としてstorybookに、頻出x定義が簡単なコンポーネントからライブラリを作ってみるところを開始。

    • checkboxなど

    • なお、ブランドやデザイントークンなどは、UIリニューアル時に言語化済みだったので実装から開始。

  • プロマネ：開発リソースも潤沢ではないので、サブプロジェクトとして実施する、細く長く系pjとしてマイルストーンを設計をしました。

  • デザイナとエンジニアで課題感を高めていく＆コラボレーションをしていくために、HIGの輪読会を定期開催

  • デザインコンポーネントを粛々と言語化

雑でもいいのでユースケースを言語化し切る


2022年：UniposUIの拡大×現場で使われる実績を作る

2022年 上期（4月〜）

  • 開発チーム全体に対して、デザインシステム（= UniposUI）を構築します&使ってみてください・使ってみてFBください、というアナウンスの実施し、現場で使うためのキックオフを実施

  • デザインシステムへの温度感が高いメンバーとそうでないメンバーがいるので、フォロワーになってくれる人を中心に使ってもらい、カイゼンを回す。

    • バイネームで、このチームのこの開発で使ってください！とオファーして、使ってみてどうだったか？をヒアリング

  • Unipos独自のUIに対して、コンポーネントの設計と実装。webが激重

  • スマホのライブラリがMVPで完成したので、スマホの投資をSTOP

  • デザシスの定例mtgを、バックログのリファイメントとプランニングを中心に実施する形に。

  • チームのQの目標設定を、メンバーと一緒にワーク形式で決めていく。

2022年 下期（10月〜）

  • だんだん、使ってみてどうか？の事例があつまる

  • Unipos独自のUIコンポーネントの最難関部分のデザインと実装計画


2023年：PJチームは解散し、コミュニティ化へ

2023年：上期(4月〜)

  • 難易度の高い最後の難関を頑張ってやり切る

  • チーム解散を目標に設定し、そのために必要なissueを策定

    • コミュニティのその時々の有志でissue管理&対応などのプロセス決め

  • 8月に、解散&コミュニティ化し、自律的にデザインシステムを取り扱えるように！！！！🎉🎉

解散時のUnipos
私はpj解散後UniposUIから離れたのですが、めっちゃコンポーネント増えて進化しててすごい


〆

複数プロダクトがたくさんある開発環境だったりすると100%デザインシステムチームが必要だったりすると思いますが、
弊社の場合はまだそのフェーズではなかったので環境化してみた結果、かなり良かったよ！という結論です。

結果、開発のどのチームからも「UniposUI使ってる？」「定義更新した方がよいかな？」という会話がエンジニアとデザイナーの中で耳にするようになり、文化になりました。最高〜

一つ一つの細かい話は今後の発信ネタにしていきたいので、
「この話気になる！！」というものがあれば、私のXまで雑にメンションください！

デザインシステムはいいぞ！！


この記事が気に入ったらサポートをしてみませんか？