ユーザーファースト推進室 デザイナーの橋本（＠hashcc）です。
クックパッドでは、安定した品質のモバイルアプリケーションをユーザーさんに届けるために、デザインリリースマネージャ という試みを2015年秋頃から始めました。
今回はこの試みについて発端や成果などをお話しします。
「あれ、なんでこんなデザインになってるの・・？」
クックパッドには日々多くのコード変更が加わっています。そうした中でも品質を安定させる（クラッシュや機能破壊を起こさない）ために、テストエンジニアなどが取り組んでいます。
デザイナーも「デザイン変更が伴う修正は必ずデザイナーがチェックする」というルールを作り、デザイン品質の安定化に努めていました。
にも関わらず、リリース直前/直後になって「あれ、なんでこんなデザインになってるの・・？」と、想定外の変更・不具合に気づくということがありました。
振り返りをしてみると以下のような原因がありました。
- チェック方法に漏れがあり、特定環境で意図せぬ表示になっていた
- デザイン変更のない修正が実は不具合を起こしていて、表示が崩れてしまっていた
- 変更によっては一部のデザイナーだけが把握していた（他の人は把握できていなかった）
また、漏れ/不具合の見過ごしがないようデザイナーが頑張ってみるにも、クックパッド内での開発量が多いため、レビュー対象を大きく広げるのは難しい状況でした *1
そのバージョンのデザイン変更に責任をもつ人を決める
チェック漏れや意図せぬ不具合は、事前に皆でさわってみればわかりますし、共有不足やお見合い事故は全体をきちんと俯瞰して見る人がいれば解決できそうです。
エンジニアは「リリースマネージャ」という形で、そのバージョンの担当者として全変更の進捗確認などを主に進める人を立てていて *2 、デザイナーもこれに倣って、そのバージョンのデザイン変更に責任をもつ人＝デザインリリースマネージャを立てて進めてみることにしました
デザインマネージャの役割
※ Github Issueとは加える変更についてデザインなどを議論する掲示板のことです
実際に、これでデザイン上の問題を抱えたままリリースしてしまうことはある程度防ぐことが出来ました（と同時に後述しますがデザイン標準化という課題も見つけました）。
影響が大きい不具合を見つけた場合は、リリースするために修正が必要な不具合として、修正を依頼して進めていきました。
導入後の成果
この仕組みを試してみて、いくつか良いことがありました。
リリースサイクルへの理解が深まった
以前はアプリのリリースサイクルがあまり理解できておらず、開発期間が終了後に駆け込みで必要な実装をお願いするなど、迷惑をかけてしまうことがありました・・。
デザインリリースマネージャは、リリースサイクルにある新規Issue締切日・新規プルリクエスト締切日などを意識してIssue巡回や進捗確認をしていきますが、このお陰でリリースサイクルが行動レベルで理解できました。
現状と未来を振り返りやすくなる
各デザイナーは個々得意なエリア・サービスで仕事をしています。 もちろんそうしたエリア以外でも日々ドッグフーディングによりサービスに触れてみて改善していくことは重要です。ただ、サービスも増えてきていて、隅々まで触ることもなかなか難しくなってきました。
デザイナーが集まって最新バージョンをさわるデザイン確認会を定期的にやることで、「そもそもここってなぜこうなっているんだろう」「こうあるべきじゃないの・・？」という現状への理解と未来像を気軽に共有できるようになりました。
デザイン標準化の必要性に気づけた
デザインリリースマネージャが様々なデザイン関連Issueや画面デザインに目を通す中で、デザインルールが適用しきれていないところがあることがわかってきました。
そこで、ユーザーさんがより自然にコンテンツを見ていけるように、デザイン標準化Issueを立てて順次統一を進めています。
デザイン品質基準の共通理解が必要だと気づけた
前述のように、デザイン確認会で影響の大きい不具合が見つかった場合は、修正されるまでリリースしないようにしています。
何がそうした不具合にあたるかは現在はデザイナーが判断していますが、エンジニアが自律的に判断し動けるようなフローの方が望ましいでしょう。そのためにはデザイン品質の共通理解が必要で、それにむけて不具合の事例を積み上げたり、大事にしたい体験を明確にするといった取り組みを進めています。
この頃同時に行われた取り組み
デザインマネージャの取り組み以外にも、同時にデザインレビューフローを改善する取り組みもいくつか進んでいました。
デザインレビュー対象のIssueに気付きやすくする
一部のエンジニアがデザイン変更を含むIssueに review_designというタグをつけてデザインレビュー対象であることをわかりやすくしていました。
実はあるIssueにデザイン変更があるかはパッと見てわからなかったりして見過ごしもあったのですが、そうしたことが減りました。
ただ、だんだん対象が増えて見過ごすことも増えてきたました。そこで、このタグが付けられた際に全デザイナーに通知がされるような仕組みへ改善することで、見過ごしづらくすることが出来ました。
個別機能のデザインレビューを行いやすくする
新機能のデザインレビューをする際、以前はエンジニアからスクリーンショットをもらうか、試せるように専用のビルドを作ってもらうよう依頼していました。
ただ、スクリーンショットですと一連の利用の流れで見ていくと不自然だったり、映っていない部分で問題が起きていることに気づけないなどの問題があります。また、専用ビルドを作ってもらうようお願いするのも、チェック回数が増えてくるとお互いに大変です。
そこで、新機能の実装毎＝プルリクエスト毎にビルドを構築し配信できるようにして、普通にアプリを使っているようにレビューできるようにしました。また、プルリクエストのコメントに配信先URLが書き込まれるようになり、依頼しなくても気軽にレビューできるようになりました。
おわりに
以上、デザインリリースマネージャ導入の背景、施策、成果についてご紹介しました。
試して半年でまだまだ改善する点は多いのですが、以前に比べデザインチェック漏れなどによりデザイン品質を低下させてしまう事態は減らすことができました。
クックパッドでは、今はない価値をユーザーさんに届けるために日々試行錯誤を繰り返しています。 ただ、そのためには土台として、安定した品質で継続的に価値を届けられる体制と、的確な現状認識・未来像を持つことが必要になります。その土台を作るためにデザインリリースマネージャは有用だと考えていますが、この他にもできることがあるのか考え続けていきたいです。
クックパッドでは、より良いユーザー体験を届けていきたい！というデザイナーを募集しています。 クックパッド株式会社 採用情報
*1:細かな変更も考慮しますと、デザイン変更はiOS&Androidで 20-30前後/1リリースのデザイン変更があります。実際はレビューと修正のイテレーションになるので、この2,3倍くらいの回数を確認していきます
