当社では、デザインやコーディングのブラッシュアップの為、お互いのデザインやコードをレビューし合う「相互レビュー」を取り入れています。デザイナー同士の関係がフラットだからこその取り組みですが、今回は、「相互レビューを文化に！」と取り組むデザインチームに、そのフローやメリットなどを聞いてきました。

左：S／デザインチーム責任者 エンジニアマネージャー｜2013年新卒でウエディングパークに入社。Wedding Parkサイトやブライダル特化のCMSツール「Webつく」の開発に携わる。

中央：Y／Webデザイナー｜2017年中途入社。ソーシャルゲームやアプリなど、幅広いデザイン・ディレクションを経て、現在はWedding Park海外・Wedding Park DRESSのデザイナーを担当。

右：N／Webデザイナー／2015年中途入社。制作会社での経験を経て、現在はWedding Parkのデザイナーを担当。「ハナレポ」などの新規コンテンツ開発にもメインデザイナーとして携わる。

チームでのスキルアップを目指し、相互レビューを文化に

ーまずはウエディングパークのデザインチームについて教えてください。

S：デザインチームは、ウエディングパークが運営する5つのWebメディアのデザイン・コーディングがメインミッション。それ以外にも、社内のデザイン業務や組織づくりに幅広く貢献しています。また、事業部づけではあるものの、“デザインチーム”としての目標を持っていることは、ひとつ特徴かもしれません。その中で、チーム全体でのスキル向上を目指して、レビューを文化にしようと取り組んでいます。

ー現在どんなレビューをしているのでしょうか？

S：コードレビューとデザインレビューを、デザイナーのメンバー同士が相互にしています。コードレビューは数年前から、デザインレビューは約1年前にはじめました。

ーなぜ相互にレビューというかたちに？

S：ウエディングパークでは、アートディレクターを置いておらず、デザイナーはそれぞれが担当している領域には自分自身が責任を持つスタイル。複数のメディアを、担当が変わったとしてもクオリティを担保して継続的に運営するためには、現状だと相互にレビューするのが一番有効だったんです。ちなみに、デザインレビューに関してはYさんが組織提案してくれたのがきっかけでした。

ーどんな背景で提案したんでしょうか？

Y：経験の浅いメンバーを、途中でもっとフォローできないかなと思ったことがきっかけでした。当時の開発フロー上、リリース前に他のデザイナーの制作物を細かく見る機会はなかったので、そういう機会をつくりたいなと。自分の任されていることを個々に頑張るのも大事だけど、デザイナー同士「横」で連携して、チームとしてスキルを向上させていきたい、お互いの業務把握もしたいということで提案しました。

ーコードレビューはいかがでしょう？

N：コードレビューは、チーム全体のコーディングのクオリティ担保のために始めました。デザイナーの定例ミーティングで、制作物を共有する場はありましたが、もっと途中段階でフォローや情報共有をしたかったんです。コードレビューをする中でUIの面も指摘することがあって、そうするとデザインもコーディングもやり直しで2度手間になるんですよね。そこから、デザインレビューもしたいという話が出てきました。

デザインレビュー

ーまずは、デザインレビューのフローを教えてください。

Y：デザインを作ったものをAdobe XDに上げて、コンセプトなども含めてスプレッドシートで一覧にしています。そこから、デザインチームのslackチャンネルで共有します。そこからデザイナー全員でレビューをしています。

N：レビューに出すときに悩んでいる部分があれば、slackで共有する時に言ってますね。指摘以外にも、このボタンの表現良いなとか、間の取り方いいなとか、メンバーのデザインを見て、自分のデザインの参考にすることも多いです。

S：レビューという名前からも、初めは穴を埋めることを目的に始めたんですが、デザイナーはデザイナーに褒められるとうれしいよね！という話がメンバーからあって、良し悪しどちらも言うことを、途中からルールにしているんです。

Y：指摘ばかりされていると否定されている感じでテンションが下がるし、ポジティブな取り組みなので、褒められる所はあえて言葉にしてどんどん褒めていこうとなったんですよね。

デザインレビューしていく中で、細かいデザインのクオリティが上がったり、新しく入った人がサイトのトンマナに合わせたデザインをキャッチアップできたり、フォローがしやすくなって良かったなと思ってます。コードレビューに出すときにはデザインの意図が完成前にわかっているので、どういう意図で作ったデザインなのか、前提を共有できるのも良かったです。

ーレビューに出して良かった！と思うことってありますか？

N：作っていて少し迷いがある時ですね。他のデザイナーからの反応が見えて、“やっぱりそうか”と共感出来たり、やっぱりデザイナーからデザインの面を後押しされると自信が持てますし、一緒に開発しているディレクターに企画へのデザイナー目線での提案を持っていきやすくなります。デザイナーならではの、こだわりやトレンドに気づいてもらえる時も嬉しいですね。

Y：私は、UIの取捨選択をする時にデザイナーにしかわからない変化に気づいてもらえて助かってます。あとは、デザイン案を複数作った時に、自分にとっての捨て案にレビューで好評価が集まったり、ディレクターには違う案が好評価だったりと、それぞれの観点の違いが判ることもあります。

S：デザインに関してはデザイナーに権限がある分、自分たちで責任を持って判断しないといけないんですよね。そういう時、デザインの相互レビューに効果があると思います。

コードレビュー

ー続いて、コードレビューはどのように行っていますか？

N：コードレビューに関しては、メディアごとに担当のレビュアーをおいています。デザイナーは、デザインにOKが出たらコーディングしてGitlabに上げ、各メディアの担当レビュアーをアサインしてレビューにまわします。レビューの観点としては、セマンティックかどうか※。効率の良い書き方ができているか、といったところです。（※その情報が適切なタグでマークアップされてるか）

ーコードレビューを始めての気づきや変わったことってありますか？

N：元々コード規約はあったんですが、class名のつけ方とか同じような指摘が増えてきた時期があって、見直しをするようになりました。あとは、レビューによって、ただコーディングをするんじゃなくて、サイトのパフォーマンスを意識して設計する意識がついてきたことは大きいですね。細かい所だと、その人のクセとかも掴めるので面白いです。

Y：私も、軽量化することとか、どうやったらパフォーマンスを意識したコーディング・設計ができるかという意識がつきましたし、色々な背景を経てウエディングパークにいる人たちのコードを見ることで、それぞれのバックグラウンドで書いたものを統一するためには規約が大切だと改めて感じています。レビューの中で気づきを書き留めるスプレッドシートを作って、デザインチームの定例ミーティングでディスカッションしています。

S：レビュー自体も、通常の開発に＋αで工数がかかるものではあるので、効率的なフローや方法はブラッシュアップして変わっていっています。

まとめ

ー相互レビューで感じているメリットを教えてください！

Y：単純にミスも減るし、スキルが上がると思います。コードの書き方ってその人の考え方に近いものがあって。一人だけでやると凝り固まるけど、新しい考えを取り入れられたり、とにかく気づきが多いです。

N：そうですよね。あとは、言語化にも役立っています。レビューをする中で、チーム全体で、“細かい部分を言語化するのって難しいよね。”という話になって、チームの言語化強化期間に突入したんです。例えば、“何でそのデザインにしたのか”自分のつくったデザインに関するコンセプトや目的を書きますし、レビュアーとして見る時も、“なぜいいのか？”、“なぜ違うのか？”を、感覚ではなく言葉できちんと表現することになるので、言語化のスキルは上がってきたなと思います。ほかにも、メンバーAさんとBさんは相互に理解しているけど、Cさんには共通認識としては伝わってなかった…というような認識のズレもわかりました。

Y：今後は、レビューだけに頼るんじゃなくて、事前にメンターに相談したりという対面でのコミュニケーションも大切にしながら、レビュー自体も良くしていきたいです。

N：メリットなのかわからないのですが、チームで考えた時にも、レビューをやっていく中で、レビューの仕方など改善しなきゃいけないことがどんどん出てくるので、未然に防げないかとチームで話し合うことが増えて、チームとしてもどんどん良くなってきているんじゃないかな…？

S：僕も、メリットとして一番感じているのは、チーム感ですね。一人ひとり別のプロジェクトにアサインされているので、日々の業務の中でチームで何かをやる機会は少ないんですが、デザイナー全員の共通言語をつくれることで、“デザインチーム”というチーム作りに大きく貢献していると思います。もうひとつは、先ほども出ましたが、デザイナーじゃない人にデザインの大切さを伝えていくときに、デザインチーム全体の言語化能力があがったこと。これは、社内にデザインを浸透させていくための文化づくりにも大きく貢献してくれていると思います。

▼最後に、こちらもご参考に。