2019卒デザイナーがマークアップ研修で学んだこと

はじめに

はじめまして!みんなのウェディング、2019年新卒UXデザイナーの小板です。

公立はこだて未来大学の情報デザインコースを卒業し、この春にみんなのウェディングに新卒入社しました。大学ではほとんど独学でマークアップに触れていた私ですが、今回新卒向けマークアップ研修を受けたことで、大きな学びを得ることができました。

今回は、そんなマークアップ研修での学びについて、新卒デザイナー目線でふりかえっていきます。

なお、今回は研修内容などについて詳細な紹介はしませんが、カリキュラムはデザインシステムをのぞいてほとんど昨年度と同じようなので、2018卒エンジニアの先輩によるこちらの記事を合わせて見ていただけると良いかと思います。

ちなみに、社内では基本的にHaml/SCSSでマークアップを行なっております。

なんのために研修で学ぶのか?

ではまず、なんのためにマークアップを研修で学ぶのか、についてです。

みんなのウェディングのデザイナーとして

今回のマークアップ研修は、UXデザイナー研修の一環として参加しています。UXデザイナー研修全体のゴールとして、「『正しいものを正しくつくる』ができるUXデザイナー」というものが設定されています。そんなゴールの、「正しくつくる」を学ぶのが、このマークアップ研修です。この他には、UI研修やグラフィック研修など、デザインに関する様々な研修も受けていますが、今回は割愛します。

みんなのウェディングはWebサイトです。WebサイトにおいてHTML/cssはユーザーとの接点となる部分であり、ユーザー体験が左右される大きな一因となっています。ユーザーが見たいものがどんな環境でも当たり前に表示される、そんな当たり前品質を実現できるようになるのも、この研修の目的でした。

きちんと学ぶことの重要性

これは研修を終え、振り返る中で気づいたことですが、改めてマークアップについてきちんと学ぶことにより、「なんとなく」を潰せたという大きなメリットがありました。

現在、インターネット上には多くの知見やサンプルコードが溢れており、少し検索して出てきたものをコピペすれば、それっぽいものを作ることができてしまいます。しかし、それでは予期せぬエラーが発生したり、仕様変更などがある際に「今あるものがどうしてそうなっているのか」がわからず手を出せないということも起きてしまうかもしれません。なんとなく分かった気になっていた、あるいはよく知らないまま使っていたプロパティなどをきちんと理解することにより、「正しくつくる」ができるようになったと感じています。

また、「なんとなく」を無くすことによって、どうしてそうなっているのか?を理解することができ、結果的に読みやすく、わかりやすいコードを書くことにつながると考えています。ずっと続いていくサービスですから、変更や修正はこの先どんどん発生します。その時に、「これはどうなっているのか」と、自分以外の人がコードを見るということを常に意識しなければなりません。

プロダクトをマークアップするということ

さて、今回のマークアップ研修を通して学んだ最も大きいポイントである、「プロダクトのマークアップ」についてです。

誰かが作ったデザインを元にマークアップする

Webページをマークアップする際、他の人が作ったデザインを元に作ることがあります。弊社ではデザインツールとしてSketchが使われています。Sketchで作られたファイルは、Zeplinというツールで詳細なCSSの値を確認することができます。基本的には、このデータを元に実際にページをマークアップしていきます。

誰かが作ったデザインをマークアップする際に重要なことは、コミュニケーションです。デザインには、必ずデザイナーの意図が反映されています。実装の際にそれらを捻じ曲げていては、デザインする意味がありません。しかし、細かな数値など、「これはミスなのか?」「どんな意図でこうしたのか?」「ここはどのような動きをする想定なのか?」といったような疑問を持つこともあるかもしれません。そういったときは、自分で解釈して進めるのではなく、デザイナーにしっかり確認をすること、そして時には議論をすることも重要です。

実務の中では、私がデザイナーとしてデザインをエンジニアに渡すというケースが想定されます。もちろん、デザイナー同士でマークアップをお願いする・されることもあるかもしれません。「自分の意図を伝えること」「相手の意図を汲み取ること」両方の重要性について、改めて認識することができました。

保守を意識する

「きちんと学ぶことの重要性」でも触れましたが、みんなのウェディングはこれからもずっと続いていくサービスですので、変更や修正がどんどん発生すると予想されます。コードは、書くよりも読まれることの方が多いです。また、自分で読み返すのではなく、別の誰かが読むということになります。当然、自分が誰かのコードを読むことにもなり得ます。その際にわかりづらいコードや、規則がめちゃくちゃなコードの場合、「コードを理解する」「何が行われているのかを調査する」などのタスクが発生してしまい、効率が低下してとても辛くなってしまいます。それらを防ぐために、社内ルールは設定されています。社内ルールを理解し、保守を意識したコードを書くことも重要なのです。

さて、ここで、いくつかの社内ルールを紹介します。

デザインシステム「Oshidori」

現在は開発途中ですが、弊社では新しくデザインシステム Oshidoriを導入しています。発展途上ではありますが、コンポーネントのデザインなどが旧デザインよりブラッシュアップされていたりします。また、サンプルコードが用意されているなど、実装面での利便性がより高くなっています。

デザインシステムを導入すると、社内のサービスのデザインが統一され、作業効率もアップするというメリットがあります。しかしながら、デザインシステムを作り上げることは容易ではなく、デザインシステムの定義そのものも難しいというのが現状のようです。今回の研修では、実際にOShidoriに用意されたコンポーネントを利用しながらマークアップをする実習を通して、「自分もデザインシステムに関わっていくこと」を考えていました。より良いユーザー体験を届けられるように、いつか積極的に関わってみたい分野です。

クラス命名規則

弊社ではクラスの命名規則として、BEMをベースとしつつ、Modifierは使用せずECSSの名前空間の概念とRSCSSのVariantsを採用しており、「Block__Element.-Modifier」という規則で、クラスの名前をつけます。Blockは大きな情報のひとかたまりで、Elementはそれを構成する様々な要素です。Modifierは、それらの状態を表すために用います。

例として、結婚式場の情報一覧ページがあるとします。

これは私が作ったサンプルです。それぞれハッピーウェディングとスペシャルウェディングという式場があるとします。これを元に説明していきます。

まず、各式場の情報の塊を、「place」というBlock(情報の塊)と捉えます。 すると、式場の名前やリード文(紹介文)などの要素は全てElementとなり、「placename」「placelead」などのクラス名をつけることができます。また、Blockのなかに小さな情報の塊があるとして、式場の名前とリード文を囲む「place__infomation」といったElementを用意することもできます。さらに、ある式場だけ特別な状態にあるとしたい場合、「.-special」のようなModifierを用意することで、そこだけspecialな状態用のスタイルを反映させることができます。

実際にHaml上でクラス指定する際は

.place
  .place__infomation
    .place__name ハッピーウェディング
    .place__lead ハッピーな式場です! アットホームな挙式ならここ!

.place.-special
  .place__infomation
    .place__name スペシャルウェディング
    .place__lead スペシャルな式場です!スペシャルな挙式ならここ!

のようになります。

SCSS上では、

.place{

  &.-special{
    //placeのspecialな状態のスタイル指定
  }

  .place__infomation{
    //式場名とリード文を囲む枠のスタイル指定
  }

  .place__name{
    //式場名のスタイル指定
  }

  .place__lead{
    //リード文のスタイル指定
  }
}

と書きます。  重要な点としては、Haml(HTML)上の入れ子構造と、SCSS(CSS)上の入れ子構造が一致していないということです。 これにより、「意図せずCSS詳細度が上がってしまい、思うようなスタイルが指定できず強引な手段を用い、結果的にSCSSの中身が混沌とする…」ということを防ぎます。また、どこに何を書いているかなどが統一されるので、コードが読みやすくなるというメリットもあります。

どの塊を1つのBlockとするかや、HamlとSCSSでのネストの違いでハマりがちなポイントですが、ある程度わかってくると、規則がある意図や利点もわかってきます。コンパイル後のCSSを見ることも、理解につながると思います。

コードレビュー

マークアップしたコードは、自動テストの他に、必ず誰かのコードレビューを受けます。これにより、先ほどの命名規則が守られているかや、もっと良い書き方がないかなどを見てもらいます。

コードレビューでは、「自分ならこうするかも」といったようなレビューを受けることもあります。そういった場合は、実際にレビューしてもらった人に意図を聞きにいくことや、「いや、私はこう思うのでこうしました」というのを伝えることなども必要になってきます。レビューにおいて大切なことは、ただ言われたら直せばいいという訳ではないということです。どうして指摘されたのか?この人はどう考えているのか?を意識しながら、コードレビューを受けると良いと思いました。もちろん、最初からLGTM(よさそう)を頂けたらそれはそれで良さそうです。

ちなみに、研修では新卒全員のコードを、スクリーンに映し出しながら講師の松久さんがレビューしていく、というカタチで行いました。実際にほかの人のコードを見ることは、レビュイーだけでなくレビュアーのスキルアップにもつながります。さらに、みんながどのような指摘を受けていて、どんな風に指摘をしているかなども見ておくと、自分がマークアップするときに同じような指摘を受けてしまうことを防げるとも思います。他の人のコードレビューもGithub上で見れますし、まずは目で見て盗むのも大切かもしれないですね!

おわりに

他にもまだまだ大切なことはありますが、今回紹介する学びは以上になります。

今回は、研修内容よりも、学んだことへフォーカスを当てて振り返ってみましたが、いかがでしたか?今回の研修を通してわかったことは、ルールには意味があるということです。そして、そのルールがどうして生まれたのかを含めて理解することで、実装にうまく取り込んでいくことができるとも考えています。もちろん、まだ整っていないルールや、意味の不明瞭なルールも存在するかもしれません。そういったものに気づいた時は、積極的に「これはどうしてですか?」と質問することも大事です。

弊社では研修中だけでなくとも、「どうしてこれはこうなっているんですか?」と聞くと、優しい先輩が気軽に答えてくれます。時には一緒に議論をすることもあります。そこには先輩としての優しさだけではなく、「君たち新卒も一緒にサービスを作り上げていく仲間なんだよ」という意志を感じる時があります。

現在、新卒研修は架空の案件に1ヶ月取り組むパイロットプロジェクトがスタートしています。その後はOJTが控えており、着実にステップアップしているのを感じています。まずは基礎をしっかりと固め、みんなのウェディングを、サービスだけでなく色々な面からもっともっと良くしていける、そんなUXデザイナーを目指して頑張っていきたいと思います。