プロダクト開発の中心になるデザイン組織への再編

ラクスのデザインチームでマネージャーをしている小林です。

ラクスでは「楽楽精算」「メールディーラー」といった中小企業向けのBtoB SaaSを提供しています。多くのお客様にご利用いただいていますが、デザイン面ではまだ課題も多く、UIデザイナーはどうすればもっとうまく課題を解決できるのか悩んできました。

デザインチームの組織名は「UI開発課」といいます。徐々にメンバーも増え、やっと10名の組織になりました。チームの編成や、役割について何度も議論を重ね、ようやくMissionを定義することができました。

UI開発課がどんな組織で、何をやっているのか、何を目指しているのかをご紹介しようと思います。

UI開発課について

UI開発課は、UIデザイナーとフロントエンドエンジニアという２つの職種の混成チームです。現在はUIデザイナー4名、フロントエンドエンジニア5名、マネージャー1名の計10名です。

ラクスのプロダクトはおもに8つあり、それぞれ開発チームが存在します。UIデザイナーとフロントエンドエンジニアは、開発チームに所属するのではなく、UI開発課という横断チームに所属しています。

なぜこのような組織形態になったのか、今までの課題や取り組んできたことをお話しようと思います。

課題1. なかなか進まないUIの改善

UIデザイナーのチームを立ち上げたのは8年ほど前でした。
当時はUIデザイナーのみで構成されたチームで、フロントエンドエンジニアは社内にはいませんでした。

立ち上げた当初は、UIにどんどん手を入れて、すべてのプロダクトをわかりやすいUIにしていきたいと思っていました。改善案をコツコツとつくっていけば、デザインの品質も上がりそのうち統一感も出るだろうと思っていました。

今考えると非常に甘い考えでした。HTML/CSSを実装する課題が認識できていませんでした。

ラクスのほとんどのプロダクトでは、機能追加のたびにCSSファイルに新しいclassが継ぎ足され徐々に肥大化し、エンジニアもデザイナーも、誰もCSSの全貌を把握できていませんでした。

特に苦労したのは新しいデザインのUIを作るときでした。

HTML/CSSに詳しいエンジニアは少なく、UIデザイナーが新しいUIのHTML/CSSモックを作成しグラフィックとセットで提供していました。エンジニアがHTML/CSSをコピペすれば、手軽にフロントエンドを実装できるようにするのが目的でしたが、デメリットはありました。

UIデザイナーは既存のCSSをすべて把握しているわけではないため、モックのために新しいclassが生成され、さらにCSSファイルは肥大化していきました。HTML/CSSのモック作成は、CSSの肥大化を助長してしまったと思います。

新しいUIだけでなく、既存のUIのちょっとした改善も簡単ではありませんでした。CSSの影響範囲が正確にわからず、CSSの知見も少ないため、ちょっとした修正でも時間がかかり、改善が先送りにされることもしばしばありました。

課題2. 表面的なデザインだけの依頼

デザインの業務フローについても課題がありました。
UIデザイナーは各プロダクトの開発チームから、要件が確定してからデザイン作成の依頼をもらうというフローでした。

ExcelやPowerPointで書かれた依頼のドキュメントには、あらかじめ画面遷移やUIパーツの配置が書かれており、UIデザイナーができることは、文言を手直ししたり、パーツの順番を少し並び替える程度にとどまりました。

ユーザーの課題を解決するには、この画面遷移やUIでいいんだろうか？と気になることはありましたが、開発のスケジュールは迫っており、その場でちゃぶ台返しできるような時間はありませんでした。

UIデザイナーがこのような形で作業を依頼されるのには理由がありました。

新しい機能をつくる際、製品企画チームはエンジニアに最初に相談します。
プロダクトの仕様や内部構造には当然詳しく、実際に形にしてくれるのもエンジニアですので非常に頼りになる存在です。

一方UIデザイナーは、仕様や顧客の業務理解が十分ではありませんでした。
UIデザイナーの業務・仕様理解をエンジニアや製品企画・サポートと比較すると知識面で大きな差がありました。顧客の業務で何が課題になっているのか、プロダクトの仕様がどうなっているのか理解が不十分では、的を射た解決策の提示はできません。

本来UIデザイナーがやりたいことは、顧客の要件定義をおこない、顧客課題を解決するUXを提供することですが、そこにはまだまだ遠い状態でした。

顧客の課題を解決するチームを目指して

自分たちでUI改善を実装することもできず、要件定義にも関われず、UIデザイナーの業務は社内受託のようになっており、依頼されるのをただただ待つというのは、デザイナーにとっては、非常にツラい状況でした。

このような状況をなんとか脱しようと、チームで何度もミーティングを重ね、チーム体制の見直しと役割の再定義をおこないました。
そして以下の取組を実施することにしました。

課題1. なかなか進まないUIの改善
  ↓↓↓
取り組み1. フロントエンドエンジニアとUIデザイナーの混成チームにする

課題2.  表面的なデザインだけの依頼
  ↓↓↓
取り組み2. 要件定義できるデザイナーになる

取り組み1. デザイナーとフロントエンドエンジニアの混成チームにする

HTML/CSSをスピーディに実装するには、フロントエンドエンジニアの力が必要だと痛感し、採用を開始しました。

UIデザイナーとフロントエンドエンジニアとの混成チームにすることで、密に連携をとり、デザインの意図を正しく汲み取り、スピーディに形にすることができます。

UIデザイナーとバックエンドエンジニアとのあいだをつなぐのは、HTML/CSSのモックではなく、フロントエンドエンジニアでした。

取り組み2. 要件定義できるデザイナーになる

UIデザイナーがやりたいことは顧客の課題解決、要件定義です。

表面的なデザインの作業だけでなく、顧客が普段の業務で何に苦労しているのかを深く理解し、解決するためにはどうすればよいのか、UXを考える工程に関わっていくことを目指します。そのため、UIデザイナーは顧客の業務やプロダクトの仕様の理解を深めなければいけません。

また、UIデザイナーはプロダクトに関わる多くのメンバーとコミュニケーションをとることも必要不可欠です。顧客の要望や痛みを知っているカスタマーサポートや、プロダクトの方向性を示すプロダクトマネージャー、プロダクトをつくるエンジニアなど、多くの職種が関わっています。

UIデザイナーは、それらの職種からの声をとりまとめ可視化し、解決策を考え、プロダクト開発の中心となることを目指します。

Mission

UIデザイナーもフロントエンドエンジニアも少しずつ採用によって増やすことができました。チームメンバーと何度もミーティングを重ね、みんなの目線を合わせるために、それぞれのMissionをようやく定義することができました。

UIデザイナーMission

プロダクト開発の中心になり、顧客の課題を解決する優れたUXを提供する

キレイなUIを提供するだけではなく、顧客課題を解決するUXを提供する役割を担います。UIデザイナーがプロダクトの仕様や顧客の業務・課題を深く理解し、関係者の意見を集約し、要件定義することでプロダクトの価値を高めていきます。

フロントエンドエンジニア Mission

デザイナーとバックエンドをフロントエンドの技術でつなぎ快適なUXを実現する

フロントエンドの技術力によって、デザイナーが考えたUXを実現し、柔軟性の高いソースコードを実装することで、プロダクトの進化・成長を高速化させます。

最後に

このような経緯で、UI開発課はプロダクト開発の中心となるデザイン組織への再編をおこないました。

この体制になるまでに、長いあいだ苦労がありましたが、今回メンバーとしっかり議論をしてMissionを定義できたことで、今後とるべきアクションについてもMissionからズレていないか確認しながら検討することができました。

UI開発課は、プロダクトの品質を向上するために、もっと大きなチームを目指しています。我々のMissionに共感していただけたら、カジュアル面談もやっていますのでお気軽にご連絡いただけるとさいわいです。

ラクス デザイナー紹介
https://career-recruit.rakus.co.jp/career_designer/