VisionalのHRMOS（ハーモス）事業部 デザイナーの三田です。人財活用プラットフォーム「HRMOS」シリーズのプロダクトデザインをしながら、HRMOSのデザインシステム「Polyphony」の運用改善を行うチームに所属しています。
2020年3月に生まれたPolyphonyは、現在開発チーム内で浸透が進んでおり、デザインシステムを使うメンバーからの要望が多く出ています。多岐にわたる要望をPolyphonyの改善に活かすための仕組みをつくったので、それについてまとめていこうと思います。
デザインシステムへの要望反映の仕組みについてまとめる前に、前提情報として「HRMOS」シリーズとデザインシステム「Polyphony」、その運用改善を行う「Polyphonyチーム」について説明します。
人財活用プラットフォーム「HRMOS」シリーズは、採用管理や従業員データベース、目標・評価管理、サーベイ、勤怠管理や経費精算など、様々なプロダクトから構成されています。
HRMOSのデザイナーは、プロダクトごとにアサインされています。そのため、プロダクトごとにデザインや管理方法が属人化し、アウトプットの品質にバラつきが生まれていたことが大きな課題になっていました。
それら課題の解決のためにUI Kitの整備から始め、デザイン原則やコンポーネントの定義をまとめて、2020年の3月にデザインシステム「Polyphony」が誕生しました。
Polyphonyが誕生したのはいいものの、当初はプロダクトデザイン業務の合間に新規コンポーネントの定義や既存コンポーネントの改善を行う体制になっており、なかなかPolyphonyの開発が進みませんでした。また、当初Polyphonyの誕生に合わせて定められたデザイン原則も浸透しておらず、形骸化していました。
そこで誕生したのが、デザインシステムの改善や浸透を行う専門の「Polyphonyチーム」です。プロダクト開発の業務と兼務という形で、私を含むデザイナー4名、エンジニア2名でスタートしました。
チームの立ち上げや運用についてはこちらにまとめているので、ぜひご覧ください。
仕組みが整備され、より複雑で多機能なコンポーネントを開発できるようになり、Polyphonyでまかなうことができる箇所が増えていきました。
その一方でプロダクトチームからの改善要望の数も増えていき、Polyphonyチームのリソースが逼迫するように。改善が追いつかず、プロダクト開発のブレーキになりかねない状態になっていました。
HRMOSの各プロダクトの開発メンバーから、月に数件、デザインシステムに対して要望があがっており、以下のように対応していました。
Slackで要望があがる
要望の詳細をヒアリングする
複数回のMTGで解決策を話し合う
というステップを行っていて、月に数件の要望といっても、要望対応の検討には巻き込む人が多いケースもあり、日程調整やコミュニケーションのコストがかなりかかっていました。
また、要望をあげる専用のチャンネルがなく、要望が各所に散らばっていて、数が増えたら取りこぼす可能性があるような運用になっていました。
「要望が来ては応える」ということを続けていくうちに、次第にPolyphonyチームが受託的な働き方になり始めていて、依存関係を脱却する必要性を感じるようになりました。
というのも、Polyphonyチーム内で当初から掲げていた「やらないことリスト」にある「Polyphonyチームが必要なものを全部つくる」状態に陥ることを危惧していたためです。Polyphonyチームがボトルネックになり、Polyphonyが各プロダクトチームにとって使うメリットがなくなったり、使われなくなる状態は避けなければなりませんでした。
やらないこととして定義していた「Polyphonyチームが必要なものをすべてつくる」状態に陥っていました
この状況を解決するために、
Polyphonyチームとしてのスタンスの表明
対応決定・改善対応までのフローの整備
の2つを行いました。
それぞれ具体的に説明していきます。
まず、Polyphonyのプロダクトオーナー（PO）を務める私と、マネージャー、テックリード、デザインリードとMTGを行い、Polyphonyの対応方針（スタンス）を決めました。
そこで主に決めたのは、
開発要望はコントリビュートを推奨
コントリビュートかPolyphonyチームで開発するかはTシャツサイズのコストで判断
の2点。
コントリビュートにした理由は、Polyphonyチームの開発工数削減はもちろん、
Polyphonyが理由で開発が遅れる
機能不足でPolyphonyを使えない
ということが起きないよう、Polyphonyチームへの依存関係を解消することを狙っていたためです。
次に、要望が出てから実際に改善にいくまでの流れを整備しました。
まず、開発メンバーに要望をSlackのワークフロー機能で作成したフォームからあげてもらいます。
その際の項目は以下の通り。
該当するコンポーネント
要望の内容
ユースケース
対象プロダクト
期日
規模感（Tシャツコストで回答）
記載してもらうフォームの項目は、Polyphonyチームが回答結果を見て、対応の優先度や要望のイメージを理解できるように設定しました。 対応を決めるうえで、より詳細に知りたい情報があれば、Slackで機能の具体的な挙動や実際の利用シーンを詳しくヒアリングします。
開発コストや他プロダクトへの汎用性を踏まえて、コントリビュートが最適と判断したら要望をあげたメンバーに依頼。Jiraでチケット化してもらい、実装に入るという流れです。
Slackのフォームで要望をあげてもらうことで、前提がわかったうえでスムーズに開発検討できるようになり、コミュニケーションコストが大きく削減されました。 また、フォームであがった要望をスプレッドシートに蓄積されるようにしたことで、開発要望を取りこぼすことが減りました。
コントリビュート形式によって、Polyphonyチームの開発コストの逼迫状況が緩和しました。すぐにできる開発コストの低い改善は、開発メンバーによって行われるようになり、Polyphonyの進化が早まったように感じます。
その結果、「依頼されたものを改善する」状態から、今は短期的な影響が少なくても中長期的に見ると重要な改善ができるようになりました。
例えば最近では、Polyphonyコンポーネント（≒HRMOSプロダクト）全体のクオリティを底上げするマイクロインタラクションなどを含む品質改善や、今後プロダクトとして実現したい世界観を表現するための新規コンポーネントの作成・定義などに取り組んでいます。
コントリビュートを推奨することによるプロダクトチームへの負担については、まだ顕在化していませんが今後の課題となりうると思っています。そのため、プロダクトチームへの利用者アンケートや普段のコミュニケーションによって、より良いやり方を模索し続けたいと考えています。
しかし、前よりもPolyphonyに直接コミットする人が増えてきて、「みんなでデザインシステムをつくっている」当初考えていた理想の状態に近づいている実感があります。これからもっとPolyphonyを進化させて、全プロダクトでアクティブに活用されている状態をつくり、事業成長へ貢献していきたいです。