この記事は、WHITEPLUS Advent Calendar 2021 5日目になります。
こんにちは。デザイングループマネージャーの野末です。
ホワイトプラスでは主にクリエイティブの制作・ディレクションから、デザインチーム全体のマネジメントまで幅広く担当しています。
誰に向けての記事なのか
- ホワイトプラスに興味のある方
- デザイナーのチームづくりをしている方
- デザインチームの動きが分からない！と感じているホワイトプラスの中の方
はじめに
ホワイトプラスのデザインマネージャーになって2年が経ちました。
入社当時3名だったデザインチームも、今では6名になり、これまでできなかった事にも少しずつチャレンジできるようになってきました。（まだまだ道半ばですが）
今回は2021年にデザインチームで行った3つの取り組みを紹介しようと思います。
1.スクラム導入
スクラムって？
一言でいうと「チームで仕事を進めるための枠組み（フレームワーク）」です。
「スプリント」という期間単位（1週間等）ごとに「達成すべき目標」を決めてチーム一体となって仕事を進めます。
短い期間で区切って業務を進めるため、プロジェクトの要件変更に対して柔軟な対応がしやすいのと、作業の工数を予想しやすいため、全体の納期を比較的短縮できるメリットがあります。
小さなゴールを積み重ねて、軌道修正しながら最終ゴールに到達するようなイメージですかね。
（「スクラムとはアジャイル開発手法の一つで〜」みたいな、小難しい話は長くなるので割愛しますmm）
背景
業務を進める中で以下のような課題が発生していました。
チームのキャパシティ（業務の許容量）を把握しにくい
デザインチームは大小様々な業務を日々同時並行で進めています。
少人数だった頃はコロナ渦前だった事もあり、コミュニケーションの質と量によって、チームのキャパシティを把握できていました。
しかし、人数が増えてリモート中心の働き方になった事もあり、チームの許容量と業務量とのバランスを把握しづらくなったのです。
デザインチームの業務量がオーバーしたり、許容量がブラックボックス化して、チーム内外を混乱させてしまいました。
業務の属人化
特定のメンバーだけが業務を把握していると、
当人以外にその業務の内容や進め方がわからなくなってしまいますよね。
少人数の時は属人化による弊害は表立って問題になることはありませんでした。しかし、チームを拡大していくうえで、業務の分業や仕組み化の整備は必須です。属人化の解消は避けて通れません。
デザイナーという専門性を活かしつつ、誰でも同じように取り組める業務を、マニュアルや仕組みによって、中長期的に標準化する必要性がありました。
エンジニアチームのサポート
そんな課題を抱えていた中、エンジニアチームがスクラム開発で業務を進めていたこともあり、その知見を取り入れられないか相談したところ、導入に向けてサポートいただける事になりました（エンジニアチームの皆さんありがとうございましたmm）
色々と相談していく中で、スクラム導入はあくまでも手段であって、それが目的になってはいけないなと気付かされました。
そのため、エンジニアチームのスクラムを完璧にトレースするのではなく、デザインチームの課題を解決できるように最適化する事が重要だよね、という結論に至りました。
さらに、すべてを同時に解決しようとすると、チームの負担が大きくなってしまいます。仕組みとして形骸化しないために、まずは解決する課題対象を絞って取り組む事にしました。
目的
前述の理由で、目的を「キャパシティの把握」に絞り、
「属人化の解消」については今回の解決対象から外しています。
- スクラムの仕組みを利用してチームの業務量と許容量を可視化するため
実施したこと
スクラムの成功にはスクラムマスター（スクラムの進行役）の力が不可欠です。この重要な役割をデザインリードの秀島さんに担っていただき、全体の仕組みを構築していきました。
①業務量の把握
まずはタスクごとの工数見積もりの仕組みを取り入れました。
プロダクトバックログ（作業リスト）のタスクに対して、チーム全員で工数見積りを実施します。
見積もりの単位は、時間ではなくストーリーポイントという相対的に工数を算出するための指標を取り入れました。
②許容量の把握
スプリント期間を1週間で設定して、その期間のデザインチームの許容量を把握します。ベロシティチャート（各スプリントの達成量を可視化したグラフ）で、計画と結果の差異を毎週確認して、デザインチームの平均許容量を可視化しました。
③振り返り
1週間のスプリントに対して、見積もりの甘さや改善方法をチームで会話します。デザインチームが継続的に成長するためにどうすればいいかをGKPT（Good / Keep / Problem / Try）というフレームワークを使って会話することにしました。
※このフレームワークはエンジニアマネージャーの杉本さんに教えていただきましたmm
振り返りはGood、Keep、Problem、Try、Actionごとに付箋を使って整理
結果
- チームの許容量が定量的に把握できるようになった
- 業務の優先順位付けがしやすくなった
- チーム全員の業務内容を把握しやすくなった
- チームのコミュニケーションの場が増えて業務の改善が日常的に行われるようになった
業務量と許容量を把握しやすくなった事に加えて、チーム全員で振り返りを行う機会ができたのは大きいなと感じています。
2.デザインレビューの仕組み化
デザインレビューって？
一言でいうと「デザイン（成果物）を確認・評価する事」です（本当はもっとちゃんとした定義がありますが長くなるので割愛します）
背景
今までのデザインレビューは、マネージャーやディレクターがデザインに対してフィードバックをしていましたが、いくつか課題がありました。
- レビューする人が固定化して、客観的な視点が薄くなりがち
- デザインの品質について、チーム全体で目線合わせをする機会が少ない
- 個々人で持っているナレッジの差があり、それを共有し合う場がない
このような背景によって、チーム全員が参加するデザインレビュー（評価）の仕組みを導入しようとなったわけです。
（こちらは今年入社したUIデザイナーの日髙さんが発起人になって仕組み化を進めてくれました）
目的
仕組み化するうえで、チームで目的の認識合わせをしました。
- 多角的なフィードバックによるデザイン品質向上のため
- デザインの判断基準や価値基準の共通認識を作っていくため
実施したこと
デザインレビューの仕組みとして、毎週デザイナー全員が集まり、クロスレビュー（相互レビュー）を行う事にしました。
- デザインレビューを依頼する前に、レビュー対象の目的やゴール、デザインの意図、見てもらいたいポイント、現状の段階（完成度〇〇%）等を説明
- レビュアーは「レビューの心がけるポイント」を意識してレビュー
・ユーザーの視点でデザインを体験しレビューすること
・いい点・悪い点は理由も合わせて伝えること
・感情的にデザインを否定しないこと
・多数決で決めないこと - もしその場でレビューできない場合は別途Slack等でレビュー
- レビューの内容を担当デザイナーが咀嚼してデザインに反映
結果
- 自分以外のデザインを目にする機会が増え、チーム全体の動きが把握しやすくなった
- 言語化することのトレーニングになる
- デザインレビューによって、新たなアイデアが創出される事も
- 何をもって品質向上なのかが不明確なので品質の定義を決める必要はある
課題はあるものの、個人的には導入して良かったと感じています。レビューされる側だけでなく、レビューする側にもメリットがあるため、今後も改善を重ねながら継続していきたいと思います。
3.業務マニュアルの整備
背景
デザイナーが増えていく中で以下のような課題がありました。
- オンボーディング（新入社員を育成する施策やプロセス）の体系的な仕組みがない
- 社内wikiの膨大な情報からデザインチームの業務資料を探す手間
- 人によって知っている情報に差がある（各々のルールで業務を進めている事も）
目的
- オンボーディングをスムーズに行うため
- 知りたい情報に誰でも迷わずアクセスできるようにするため
- ゆくゆくは業務の属人化を無くすため
実施したこと
新卒2年目の坂本さん、新卒の小髙さん中心に、チーム全員で業務マニュアルのアップデートを行いました。
- Google Sitesを利用してデザイン業務に関わるマニュアルを集約
- 誰でも簡単に情報を編集・更新できるように
- マニュアル作成の業務をタスク化して継続的にアップデートする仕組みを作成
- マニュアル作成方法をルール化
結果
- デザイン業務に関わるマニュアルを集約する事ができた
- マニュアルの鮮度をチームで維持する意識が芽生えた
- マニュアルを作る事によって、業務だけでなく事業全体の理解が深まる
- 誰が見ても分かるマニュアル作成の訓練になる
おわりに
その他にもここでは書ききれないほどデザインチームでは日々業務改善をしています。
- UIコンポーネントの整理
- ファイルの命名規則の整理
- 業務フローの整理
- コードレビューのルール化
- データ管理のルール化
ホワイトプラスのデザイナーは全員が組織・チームを良くするために日々行動しています。
チーム全体が高いパフォーマンスを発揮するためには、デザインのスキルアップだけでなく、このような地道な改善が必要ですよね。
これからもチーム一体となって業務改善に取り組んでいきたいと思います。
ホワイトプラスに興味がある方、デザイナーのチーム作りを進めている方の参考になればうれしいです。
明日は弊社エンジニアによる「コードレビューの観点を言語化してみる試み」です。
クリーニングのリネットなど「生活領域×テクノロジー」で事業を展開する、ホワイトプラスではエンジニアとマーケッターを募集しています。
