見出し画像

プロダクトのデザイン負債と対峙する君へ 〜1.マネジメント編〜

デザイン負債を適切に解消することは、組織の俊敏性とプロダクトの品質を高めることにつながるよ!というエピソードです。いつかあなたが悩める日が来たとき、思い出していただければ嬉しく思います。

今回はクックパッド・デザイン推進部での活動事例をもとに「デザイン負債」について向き合ってみたいと思います。全3部作のnoteで、第1弾はマネジメント、第2弾はデザイン第3弾はエンジニアリングの観点からお届けします。この記事は倉光 @transitkix によるマネジメント編です。

デザイン負債とは

デジタルプロダクトにおけるデザイン負債とは、歴代のプロダクト開発者たちの無数の改善活動の果てに生まれるもの、または時の流れや技術発展により相対的に生まれるものです。

負債にはいくつかタイプがあって、ざっくり発生レイヤーで分類すると目に見える「表層」と目には見えない「構造」の2種類があります。

長年運用されてきた大規模サービスにおけるレガシーデザインは大きな価値を生み出してきた一方で、表層/構造の保守には多大な労力がかかります。

補足
ここから先、便宜上「負債」と表現していますが、事象として捉えているだけであり、そこにネガティブな気持ちは一切ありません。

・・・

デザイン負債は解消しづらい?
私自身、これまでの人生で生んだデザイン負債は数知れず。

デザイン負債をうっかり生んでしまったり、それを自ら解消しようとしても優先度が上がりにくいのは、プロダクト開発現場が以下の性質を持っているからではないかと考えています。

🚀 リーンスタートアップ的なカルチャー
作って壊してを繰り返しながら考えるタイプの開発組織では、非連続な成長に寄与する施策が優先されやすい

⚖️事業上の優先づけ
限りあるリソースの中で、他の課題と並列に扱い、事業として優先づけをしなければならない

💀バッドエンド予測の難しさ
デザイン負債は、解消しない場合の具体的なリスクが予測しづらい

工数
フロント領域の設計変更を伴うことが多く、エンジニアも共に稼働する必要がある

👨‍👩‍👧 ユーザーへの影響
プロダクト品質を高めようとする活動だが、ユーザーへの影響をゼロにすることは難しい

🤝組織内の合意形成
汎用コンポーネントを改修すると影響範囲が広大になり、様々なチームを跨いだ合意形成が必要になる

デザイン負債と対峙するコツ

デザイン負債やデザインシステムと向き合う中で、負債と対峙する際のいくつかのコツが見えてきました。

1.検討タイミングを予め設定する
いつも脳裏に負債のことがよぎるのはつらい。ならばいっそのこと、集中的に考えるタイミングをつくってしまいましょう。

何から手をつけていいのかわからない人は、まずは年1回チームメンバーでInterface Inventoryを実施することを一歩目にしてみると良いかもしれません。

既存サービスのデザイン課題発見のためにやっておきたい「Interface Inventory」(Yahoo!Japan Tech Blog)

クックパッドにはデザインシステムが以前から存在しており、この10年の間に「Sara」→「Citrus」→「Apron」と3世代交代してきました。世代交代は何らかの課題や負債解消から出発しており、まずは定期的に検討の場を設けることがバッドエンド回避の第一歩だと思います。

2.やるなら集中する
経験上、メイン業務を抱えながら隙間時間でコツコツ行うデザイン改修は根本的な構造部分の問題は後回しになることが多いです。負債の蓄積度合いによりますが、負債解消を行う場合には「集中して取り組む期間」もしくは「チーム」を用意した方が良いでしょう。

3.専門家を引き入れる
下記のような人々がチーム内もしくは周囲にいると、プロジェクトの速度が加速します。

デザインエンジニア
エンジニアリングとデザインを日頃から反復横跳びしているプレイヤーがチームにいると、デザイントークンの特定やしくみ化への構築が捗ります。

プロダクトの技術基盤の歴史を知る人物
社歴の長いデザイナーやエンジニアがこれに該当します。これまでの経緯などを知っているので、技術課題に直面した時にそれを紐解く情報を提供してくれます。

他社でデザインシステムを発明・浸透させてきた人
デザインシステムにはある程度共通化された型があります。自プロダクトのフェーズにおいて、どこまでやるか、どうアレンジするかのポイントを相談することができます。

4.期待する品質水準を定める
デザインシステムや各種ガイドラインをつくるのは、プロダクト・ブランド戦略の中の目指す姿や体験水準を明確にするためです。クックパッドでは、デザインシステム「Apron」や社内アクセシビリティガイドラインが存在します。

5.目的を誰もが理解できるようにする
前述した通り、デザイン負債はこのまま解消しなかった場合のリスクが具体的に予測しづらいです。事業活動において、負債解消活動がどのような意味づけなのかは誰もがわかるように言語化しましょう。

この時にポイントとしては、事業責任者や経営者からも理解できる言葉になっているかを見直してください。

6.ついでの機能改善は我慢する

意外とこれが一番重要かも知れません。

いざ着手できても、機能面で「もっとこうしたいよね!」というアイデアも次々に思いついてしまい、気づけばプロジェクトが壮大になってしまうことも…しかしこうなってしまうと、プロジェクト完遂までの変数が増え、デザインの難易度もステークホルダーとの交渉に費やす時間もぐんと上がります。もし機能改善をしたいなら、まずはデザイン負債の解消が一区切りついた後に対処してください。

7.ユーザー影響を事前察知する
リリース前の事前ユーザーインタビュー・新デザインについての印象調査・ユーザビリティ調査、打てる手があればできるだけことはやりましょう。特に何も起こらなかったとしても、「問題はなかった」というファクトが得られます。

8.完璧を目指さず、段階的に対処する
既存プロダクトにおけるコンポーネント設計への変更は数百〜数千ページに影響を与えるため、バタフライエフェクト的な予期せぬ不具合に発展することもあります。ユーザー影響を最小限にするため、セクション単位やコンポーネント単位で順次リリースしていくことも選択肢の1つです。

最近の事例

さて、なぜデザイン負債について語ってきたのかというと、先日クックパッドPC版の主要画面のデザインスタイルがアップデートされたのです。

今回裏側で稼働しているCSSまわりの刷新も行っており、私はPdMとしてこのプロジェクトの発起からリリースまでを率いました。

クックパッドPC版の歴史
1998年に前身となるサービスが誕生したクックパッド、今年でなんと26年目。PC版がはじめに生まれ、2010年代のスマートフォンの普及によって主な利用環境はPC版からモバイル版Web/Appへと推移していきます。これにより新しい価値検証や改善活動はモバイルを中心に行われるようになっていきました。

世代交代するデザインシステム
2021年に「Apron」という新しいデザインシステムが誕生します。これはブランドのアイデンティティからCSSフレームワークまでを内包しているシステムです。

徐々に導入が進み、モバイル版では各事業部の施策とともにプロダクトへの浸透がなされていきました。

マルチプラットフォームがゆえの悩み
事業とは選択と集中により運営されており、PC版はここ数年は選択から外れた状態でした。その結果、「表層」にどこか懐かしさを感じるくらいに時が止まった状態になっていました。

また第3弾エンジニアリング編にて詳しく説明しますが、「構造」の点ではレガシーになってしまった旧デザインシステムの仕組みが土台として残っているために、PC版に手を加える時にはCSS上で新しいビジュアルを上塗りして作ってしまうケースが増えていきます。こうなると表層の表現は新しいものの、構造は古いままで、更に負債がこねくり回された状態に仕上がってしまうのです。なんてこった・・・

これまでも隙間時間で有志が解消に取り組んでいましたが、それでは抜本的な解決はできないのが悩みでした。

着手のきっかけ

じゃあPC版はこのままでいいのか?というと、「よい!」とは言えません。

なぜならばPCは業務利用する性質のデバイスであるため、料理で生計を立てているクリエイター・クライアントである食品メーカーの担当者・採用候補者・クックパッド社員…といったステークホルダーにとっては、依然としてPC版がタッチポイントとして機能しているのです。

ステークホルダーは、「毎日の料理を楽しみにする」というミッションに共感し共に新しい価値を生み出していく方々です。彼らにこそクックパッドの目指す世界をいち早く体感してほしいですし、それが停滞しているのであればブランドイメージとしてのリスクにも繋がっていく恐れがあります。

やったこと

そこで今回は、「ブランド観点」でのデザインの一貫性実現を通した価値向上、「アジリティ観点」での開発効率の向上を目指すことを掲げ、4ヶ月間の期間限定の負債解消チームを結成することにしました。

責任者 倉光 @transitkix
デザイン 市原 @ichinii3
エンジニアリング 見上 @kchil_chan / 藤井 @kenshir0f / 出口 @dex1t
QA 亀口

UIデザイナーにはデザインシステム自体を開発・担当したデザイナー、実装者にはデザインエンジニア属性のメンバーをアサインすることができたため、「あとはやるだけ」のスムーズな進行でした。

現場での動きについては、次回以降で公開されるデザイン編・エンジニアリング編で詳しく触れていきます。

成果

今回対象となったのはトップページ・検索結果画面・レシピ画面など主要画面ですが、これらについてはデザイン負債の解消・開発効率の向上については一定の成果を得ました。

レシピ作者さんから「PCのレシピ画面がかわいくなって、画像が高画質になって嬉しい!」などの声や、社内からも「デザインの力ってすごいですね」という言葉をいただいています。

また副次的な効果ではありますが、対象画面のサイト評価でほぼすべての項目でスコア改善が見られました。

※LightHouseにより計測。また計測タイミング/環境によって多少のブレがあります

特にレシピ画面においては、アクセシビリティとSEOのスコアは大幅に評価が向上しています。これは以下のようなポイントがLightHouse的には評価されているようでした。

Performance
デッドコード削減や、CSS参照の効率化などリファクタリングを実施
Accessibility
ariaやalt属性の付与などマークアップの見直し
SEO
アクセシビリティ改善や画像のRetina対応した

…とはいえあくまでスコア上の話であり、クックパッドでのアクセシビリティへの取り組みは始まったばかりです。

アクセシビリティについて
クックパッド社内でも、2021年にアクセシビリティガイドラインが誕生しました。今回のQAでも、アクセシビリティに関する項目を追加しています。

アクセシビリティガイドラインは Ameba Accessibility Guidelinesをかなり参考にしており、作成時には外部アドバイザーとしてデザインエンジニア谷さんにご協力いただきました🙏

さいごに

デザイン負債と対峙して適切に解消することは、デザイン組織の俊敏性を上げ、プロダクト品質を高めることにつながります。このプロジェクトのウラ話やデザイン組織について聞きたい方はぜひMeetyへどうぞ。

ここからさらに、デザイン編・エンジニアリング編に続きます👇


素敵なzineをつくりたい