リクルートのデザインマネジメントユニットでは、事業におけるデザイン活用の課題構造をモデル化し、課題の特定と解消に取り組んでいます。
今回は『リクルートエージェント』のデザイン事例から、大規模デザインリニューアルにおける課題とそれを突破した学び、そこから組織構造の最適化課題をどのように解決したかを紹介したいと思います。
先日、『リクルートエージェント』の大規模改修に伴って、3ヶ月弱という短期間で、初回リリースに関するデザインリニューアルプロセスを進めました。
具体的には、約250もの画面の要件定義からビジュアルデザイン（VD）の再検討を行い、並行してデザインシステムの構築まで行っています。
『リクルートエージェント』は、キャリアアドバイザーが転職希望者の転職をサポートする、転職成功実績No.1（*）日本最大級の「転職エージェント」です。自分で求人を探し、応募する求人サイトとは異なり、キャリアアドバイザーが転職に関する相談や非公開求人を含めた求人の紹介、企業への応募や面接の日程調整なども行います。
大規模なサービスにおけるデザインリニューアルを3ヶ月弱という短期間で推し進められた裏側には、既存の慣習に囚われない、体制や進め方の工夫がありました。ここからは、具体的な課題や、どのようにそれらを突破したかを紹介したいと思います。
『リクルートエージェント』のデザインリニューアルは、プロダクト全体の大規模改修と同時に行われました。
今回必ず押さえるべき要件として「3ヶ月弱の短期間で全ての画面設計・UI制作を完了させる」「今後のプロダクト開発・運用を考慮したリニューアルにする」という2点がありました。単純に画面自体の品質を高めるというよりも、事業要求を踏まえた課題解決の一環としてデザインリニューアルを実施しています。
『リクルートエージェント』は求職者と募集企業を繋ぐために、さまざまなステークホルダーが介在する大規模なサービスです。そのため、今回改修を行った画面数は合計約250画面ありました。
しかもプロジェクト開始当初は、それらの画面要件もまだ固まっていない状況で、約250枚の要件一つひとつをFIXさせ、さらにデザインをリニューアルする、非常に大規模なプロジェクトとなっていました。
一方でリリースまでの時間も短く、そこから開発着手するタイミングも同様に逆算されていたので、デザインに使えるスケジュールにも厳しい制約がありました。
実際、プランニングからデザインの検討・制作にかけられた時間は、約3ヶ月弱です。
『リクルートエージェント』のプロダクトは画面数も多く、現行の画面と同じ画面を設計をするだけでもかなり時間はかかってきます。
それに加えて、デザインリニューアルのため、スタイリングを従来のプロダクトから大きく変更する必要があります。またUIの横展開や開発連携、リリース後の運用性などを考えると、短期間であってもしっかりとしたデザインシステムを構築したい。
これまでのやり方では絶対に間に合わないと考えて、リニューアルプロジェクトが始まる前に、リリースに間に合わせるための制作スピードとクオリティを両立させるための仕組み・体制を用意しました。
もう一つの要件として「今後のプロダクト開発・運用を考慮したデザインリニューアル」があります。
長年にわたり積み重なったエンハンスにより、関連するWebサイトやプロダクトは多岐にわたり、開発ラインが複数走る複雑な構造となっています。エンハンス・開発体制が複数あり、ユーザー体験がバラバラに設計されていました。
実際、私も2021年5月から1人目のデザインディレクターとして、『リクルートエージェント』に参画してから、デザインの不揃いや、ルールが整備されていない状況を変えたいと思っていましたが、事業優先度から、一貫性のあるユーザー体験をなかなか提供できていませんでした。
しかし、今回はシステムのアーキテクチャからプロダクト全体を大きく改修するため、表層のデザインだけではなく、デザインシステムを一から創るための条件が揃っていました。また、この規模のサービスでは、今回のようなリニューアルの機会を逃すと次のチャンスが訪れるのはいつになるかわかりません。
このタイミングで、今後のプロダクト開発を支える一貫したデザインシステムをつくれるかどうかが、今回のリニューアルだけでなく、今後の『リクルートエージェント』におけるプロダクト開発全体に影響するはずで、短い納期なのは分かっていつつ、意地でも取り組もうと決めて取り組みました。
3ヶ月弱という短期間で、多くのステークホルダーを巻き込みながらデザインリニューアルを完遂し、今後の運用も加味したデザインを構築するという要件を踏まえると、プロジェクトの進め方から見直していく必要があります。
そこで取り入れたのが、あえて明確にデザインチーム内の役割を分業する「工場的なワークフロー」でした。
通常は、『リクルートエージェント』を担当するデザイナーは、案件ごとに要件定義から伴走して、開発への連携までをデザイナー1人で担当します。
一方で、今回は大きくプロセスを変更し、デザインチームのコミュニケーション系統を１箇所に集約、デザインチーム内の役割も明確にしていく分業体制を取っています。
ここからは、このような進め方を取った意図や、具体的な進め方についてまとめてみます。
このワークフローの大きなポイントの1つは、デザインチーム内でステークホルダーとのコミュニケーションを行う担当を、デザインディレクターである亀田1人に集約していることです。
今回のプロジェクトは、3ヶ月弱で約250枚という多くの画面の要件定義・デザインを並行で進めつつ、デザインリニューアルやデザインシステム構築も同時に進める必要がありました。
そして、これらを実現するためには、コミュニケーションパスをデザインディレクター1人に集約させる体制が最適だと考えます。
前述の通り、『リクルートエージェント』の通常の案件では、担当のデザイナーが1案件を全て担当するフローを取っており、案件の企画段階から参加して、モック・デザイン要求・VDなどを開発組織に連携するまでの一切を担当しています。
実際、この進め方ではデザイナーが上流から一貫して案件に関わることで、仕様理解を深めてアウトプットのクオリティを高めることができます。また、コミュニケーションの面でもPdM・デザイナー間での伝言ゲームを防ぎ、コミュニケーション効率を高めるなど、メリットの多いプロセスです。
今回のリニューアルでももちろん、一旦は通常の体制で対応することを考えました。
しかし、今回はデザインをゼロから全て作り変えるため、作成する画面の多さと期間の短さから、通常のエンハンス体制では間に合わないと判断し、あえてワークフローを分担して進めることにしています。
例えば今回は、要件を素早く固めるために、ワイヤーフレーム（WF）を用いてデザインチーム側からステークホルダーに対して提案を行い、要件の合意形成をリードしています。そして、このステークホルダーと要件を固めるステップを私一人で担当します。
まず、PdMとプロダクトの方針をすり合わせながら、既存のUIの情報項目を踏襲して、優先度の高いものから、約50画面程度WFを作成します。
WFをPdM・開発（フロントエンド・バックエンド）との会議に持ち込み、開発要件を決めていきます。追加が必要な機能、初期スコープから外す機能などを決めていき、要件定義での議論からWFを修正してFIXします。
要件が固まったWFから、どんどんスタイル検討の工程に送ります。そちらはデザイナー2名で担当して、私がWFを用いて要件を固めている間にも、必要なスタイルがどんどん整えられていきます。
WFについてあらかた合意形成し終えた段階で、再度固まったスタイリングをもとに、私の方でVDを設計し、これを再度PdMや開発とすり合わせていきました。
これがいつものように、1つひとつの画面単位でデザイナーがアサインされ、要件を固めVDを設計し...と進めていくフローだったら、約250枚もの画面設計は確実に終わっていなかったでしょう。
私一人にコミュニケーションを集約させることで、複雑な要件もまとめやすくなり、かつ、ステークホルダーは誰とコミュニケーションを取れば良いかが明確になり、3ヶ月弱で全てのデザイン工程を完遂することができました。
「工場的なワークフロー」を取り入れたもう一つの意図として、スタイリングと並行し、今後の運用を見据えたデザインシステムを構築することを想定していました。
システムごとアップデートするので、必要なデザインアセットが揃っていない状態からプロジェクトは始まります。
そこから大量のVDを構築しつつ、かつ今後も運用しやすい状態にするため高速でデザインシステムを構築する方法を模索しました。
まず、前述の通り、ステークホルダーとの議論を経て固まったWFは、優先度の高いものから五月雨で2名のデザイナーに連携していき、スタイルの検討を行ってもらいます。
これは、デザインチーム内で、デザインクオリティの担保とデザインシステム基盤を構築することが目的です。
ポイントとしては、細かく画面全体のデザインの最適化を検討することはせず、あくまで画面単位でスタイリングを調整することです。実装のしやすさなども一旦考慮せず、仮のデザインとしてスタイルを整えたデザインデータが揃っている状態を目指します。
さらに、この時点でデザインシステムの構築も並行して実施。以下のような内容を定義していきます。
スタイリング
『リクルートエージェント』らしいビジュアル、タイポグラフィ、カラーリング、スペーシングなど
UIコンポーネント（Web/APP）
『リクルートエージェント』の全プロダクトで共通で利用できるモジュール
アイコン、イラスト
すべてのWFの要件が固まり、必要なスタイルが構築されてきた段階で、私の方で各画面のVDを整えていきます。
WFを元に以下の内容を確認して、開発に連携するためのVD作成と修正・整備を行います。
要求事項と開発要件が反映できているか
画面単位で、前後のユーザー体験と一貫性があるか
UIとして機能しているか
必要なパターンが揃っているか（インタラクション、ステータス、画面パターン）
Figma・デザインデータが開発スピードを向上できる作りになっているか
レイヤー構造
レイヤーの命名
Devモードでの確認
また、デザインシステムについても追加で整備を行いました。
開発と連携できるコンポーネント構造になっているか
各コンポーネントの作り方は適切か
InteractiveComponents化
State定義
共通アセットとして他画面・機能で使えるか
ここから、スタイルの追加・修正がある場合にデザイントークン化してフロントエンドに連携します。デザイントークン化して連携することで、複数画面がある場合にも後から簡単に調整することが可能になっています。
これが私たちが取り入れた「工場的なワークフロー」の全貌です。工場と言いつつ、決められた範囲だけ行うのではなく、責任範囲を明確にしつつ、有機的に連携しながら約250枚の画面構築とデザインシステム設計を非常に短い期間で進めていくというプロセスでした。
合計で約250枚の画面要件とスタイルを再設計し、初期リリースに必要な全画面のVDと、運用性の高いデザインシステムが構築されました。その後、開発も完了し、第一段階のリニューアルをリリースしています。
現在は、検証を進めている期間で、ユーザーの反応や事業状況を見ながら段階的にリリースしていく見込みとなっています。
今回のプロジェクトは、デザインリニューアルの絶好の機会だったのに対し、これまでのプロセスに囚われない柔軟な考え方により、この機会を逃さずリニューアルできたことが良かったと考えてます。
期限がある中で大規模なデザインリニューアルを行うのは非常に難易度が高いことです。その前提を捉えて「情報流通・合意形成のプロセスを一新し」「あえて工場的なワークフローを採用する」ことにより、これまでにない大胆な役割の変更ができたことが成功のポイントだったように思います。
PdMと伴走して上流の要件から組み立てるだけでなく、目的達成のためにそもそものデザインチームの体制や役割分担すら変えていけるのは、リクルートのデザインマネジメントの特徴かもしれません。
事業状況に応じて、デザインマネジメントにおける課題はさまざまです。リクルートには多くの事業領域があり、各領域の課題に合わせ、デザイン活用のサイクルに沿ったデザインマネジメントが行われています。
ぜひ、他の事例も見てみていただき、組織や事業状況に合った事例を活用してもらえると嬉しいです。