CSS Nite LP58「Corder’s High」に参加してきました
9月29日、大崎にて行われたCSS Nite LP58「Corder’s High」に参加してきました！
今回はタイトルの通りコーダーに向けての講演が９セッションと、みっちりと向き合ってきました！
とりとめない感じで感想をダララッと書いていきますね〜
この記事の目次
CSS Niteとは
CSS NiteはWeb制作にかかわる様々なテーマで開催されているセミナーイベントです。
デザイン、コーディング、制作ツール等の技術的なテーマや、ワークフロー、ディレクション、Web業界トレンドなどのテーマまでWebに関することなら多岐に渡っており、各地方でも開催されていたり、年末にはその年のWeb業界を振り返る大きなイベントがあったりと、年間を通して各地で開催されています。
登壇されている方も、Web業界のトップで精力的に活躍されている方が多く、Webの最新の動向や新しいツールの使い方などに敏感になれます。
言うなれば、他のWeb制作者や会社さんの知恵やテクニックを知れるというまたとない機会です。
Web制作に関わる人間でしたら一度は足を運んでみることをオススメします。とっても勉強になりますよ！
前回のLP57にも参加してきたのでその時のレポもどうぞ〜！
今回のコーディングセミナーに参加した背景
わたしのWebの業務ではデザインとコーディングで2:8ぐらい、コーディングに偏ってます。
デザインももっと伸ばしたいんですが、一緒に案件をやってるディレクターが兼デザイン担当で、それをコーディングとWP構築するわたし、という体制であることが多いです。
コーディングについては、基本的に日々の案件では困っていないものの、
このままでいいのだろうかという気持ちがあり、知識のアップデートや他のコーダーさんがやってる小技などを仕入れるために今回参加しました。
今回学んだこと
ひとことで言うと、「今やっていることにプラスアルファでいいんだ！」と思えたことです。
最新技術って学んだ方がいいの？？
いままで何度かCSS Niteに参加していると、登壇者さんによってはわたしが全く知らないツールやフレームワークを活用していることが多く、調べて見てもさっぱりで「こういうのも使えないとダメなのかなぁ」「最新のツールとかちゃんと追わないとダメなのかなぁ」と思うことがありました。
BEM？？なにそれ？？
CSS設計思想・・・？
グラント？？ガルプ？？
JSフレームワーク・・・・？？？？？？
みたいな感じで「置いてかれてる！！！」という気持ちになってたんですが、
ようするに、どんな案件をやっている会社なのか(Webサイトなのかアプリ開発なのか)、サイト規模はどうなのか、という会社それぞれの状況に合わせて採用するものを決めるにすぎないということ。
中小企業や自営の小規模サイト中心で、コーディングを1人で担当することが多いわたしの場合、現状困っているのでなければ無理に取り入れる必要はないってわかりました。当面アプリ開発等に関わることもなさそうだし。
必死にあれもこれも覚えないとWebコーダー失格だ〜！みたいなことにはならないと笑
今回「技術トレンドとの向き合い方」というテーマで基調講演が行われました。
ここではJSフレームワーク等のトレンド技術についてお話がありました。
Vue.jsとか、名前は知ってるけど、jQueryすらやっとなのに…！！？
こういった新しい技術を積極的に習得するべきなのか？については…
現在や将来のキャリアアップのためとして、
フロントエンドエンジニアとして、バリバリコードを書けることで自分の価値を上げていきたい！という場合もあるでしょう。
現状で自分には必要なのかどうか、キャリアアップのために習得したいという目的があるか、という面から、新しい技術を学ぶか判断するのがいいと思います。というお話でした。
ちなみにわたしはCSSはidに対して1個1個書く昔からのやりかた（SASSは使ってます）で、設計思想は全然タッチしてなかったんですが、さわりは知っといた方がいいかなぁと思い始めました。最近。
コーダーとデザイナーの溝の話
ああ〜〜〜〜あるあるあるあるあるあるあ に溢れてましたね笑
わたしは結構、日頃からもらったデザインに対してツッコミ入れまくるタイプなので（嫌な意味じゃなくて、確認って意味ですよ）
コーディング前に「これ動きどういう想定ですか」とか「ここだけこうなってるのって意図ありますか」とか、すごい聞いちゃいます。
たまに、そんなに聞いたら、デザイナーの領域侵してると思われるかなぁ…と思うこともあるんですが、聞かないで自己解釈でやった後にそこはこういうつもりだったんだって言われて直すのってすごい手間だしイッラァ〜ってなるので、やっぱあらかじめクリアにしたいって思いますね…
それと同時に、デザインを渡す時点でコーダーに伝えてくださいね、って思います。
コーダーから聞かれてから、またはコーダーが組んだもの見てから言い出すよりも、あらかじめディレクターやデザイナーから伝えてくれればこの辺の溝ってそもそもあんまりないんじゃないかなぁと。
なんでも問題なのは、「聞かれるまで教えてくれない」「後から言い出す」だと思うので。
コーダーも「言われてないから適当にやっちゃえ」だと、確認不足で修正を言われたときの二度手間がめっちゃ無駄だと思うので、双方認識合わせてからコーディングに着手するっていうのがやっぱり大事ですねえ。
アクセシビリティ意識してますか
アクセシビリティというと、目が不自由なひとが音声読み上げでサイトを見るときに…のイメージがあって、あ〜その辺意識してないなぁと思ってたんですが…
もっともっと基本的に、無意識にやっていることがアクセシビリティ対応にもなっていたことがわかりました。
・HTMLコーディングの作法を守る
・role属性を指定する
・コンテンツの意味が通じる文書構造にする（見出しの後に付随する画像やテキスト、という順序を守る）
・画像の代替テキスト（alt）を適切に入れること
・navにaria-label属性を指定する
などなどが上げられてました。
すみません！role属性とaria-label属性はやってませんでした！！
でも今回学んだので、次からはしっかりとやっていこうと思います！
ようするに、きちんとサイトのコンテンツが「マシンリーダブル」つまりマシンに正しく構造を理解してもらえるように、マークアップをきちんとやろうね！というお話でした。
あとはリンクテキストはリンク先がわかる文言を入れるとかですね、ついクールなサイトにしようとして、リンクボタンのテキストを「more >」にしてるとか何がmoreやねんって話ですよね（過激）。きちんとリンクも「○○について >」とかにしたいですね。
マークアップの領域だとしても、ワイヤーフレームの段階から意識したいところですね、リンクテキスト。
解析のこと、もっと知りたいよ〜
やっぱり実案件でも、アナリティクスタグを入れることは多々ありますが、解析についてはわたし全然あかんかんじです…
ちゃんとデータを読めるようになりたいな〜とおもうし、どこをどう見れば改善を提案できるのかなぁ〜というのがさっぱりで。
コーダーとして必須、というものではないんですが、解析の知識は欲しいですよね。
ウェブ解析士を学んでみるか…とじわじわ考えてたところだったので、興味深く拝聴いたしました。
ちなみに最近わたしもこのサイトの計測タグをタグマネにしたところです😊
今見たら貼り付けてる位置が、説明されてたベスト位置じゃなかった…！！がーん
アナリティクスの見方も知りたいのもそうなんですが、
実際結構知りたいのってこれ→「ユーザーが起こしたアクションの解析」なんですよね。
お問い合わせが増えないから改善したい…という案件の、リニューアル後どのぐらい反応が増えたのか、というのはアクセス数を測るだけではわからないので、ちゃんと電話ボタン使われてるのかな？用意したPDFって読まれてるのかな？などなど、計測したいんですよね。
そういったイベントトラッキングに興味あります。
講演で紹介されていたように、電話ボタンを何回タップされたのか、どのページのものがタップされたのか、など計測できたらな！て思ってたので。
ちなみにどんなイベントを計測するか決め、そのためのタグマネ設定をするのはマーケターの領域だそうです。
コーダーの役目は、マーケターが設定して用意したコードを正しく設置すること。
とゆうことで、早速いっしょに仕事してるディレクターにウェブ解析勉強してみません…？と持ちかけてみました（学んでほしい）
サイトスピード改善の原因と対処法
バックエンド側とフロントエンド側で2セッション連続でお話がありました。
バックエンドとなるともう全然触れてこなかった分野なので、サイトスピードが遅い理由がバックエンドにあった場合、データベースやサーバー内部キャッシュなどについて専門知識があるエンジニアがいないとならないため、ここはコーダー的には手が出せないところですね。
フロントエンド側はコーダーでもすぐにできることが多いので、できれば意識的にやっていった方がいいですね。
画像の圧縮とか、cssやjsのminifyとか、ブラウザキャッシュなんかはよく取り入れられる基本の方法かなと。
わたしの場合WPでは「WP Fastest Cache」のプラグインを入れてます。
CSSとJavaScriptの非同期読み込みはやったことなかったので、これは試していきたいですね…
画像圧縮は基本的にやるんですが、画質とファイルサイズの天秤、ありますよねぇ。
JPGってよっぽど荒くならなかったらそんなに気にならないんですが、透過PNGの場合圧縮すると色数が減ってしまい、例えば口紅のピンクがベージュっぽくなってしまったりするので、でかい人物写真＋背景透過というド重いPNGファイルはいつもさじ加減が困ります…。
逆にギャラリーが命のサイト（写真やイラストそれ自体が主要なコンテンツの場合）は、無理に画質を下げた圧縮にしなくても…ということもありますね。
ただやっぱり画像自体が主要コンテンツ、ではないサイトでは、できるだけ圧縮はした方がいいです。
あとWPのメディアアップロードでアイキャッチ画像を入れたりする場合あるある、
画像を全くリサイズせず、素材サイトでダウンロードしっぱなしサイズ・デジカメで撮りっぱなしサイズでアップロードしてたり（驚異の2000pxとか笑）がものすごい負担になってる。
これってフロントで見たときに自動的に縮小されるおかげで一見見た目の問題がないせいで、「ちゃんと表示されてるから問題ないよね？」っていう、リサイズの仕方自体がわからないからそのまま使ってるっていうお客さんは結構いそうだと思いますね。
まとめ
CSSアニメーションなど、見てておもしろ〜いなセッションもあり、この辺は実装バリエーション増やしたいな〜て思いました。
上の方で書いた、「今やっていることにプラスアルファでいいんだ！」は、
・アクセシビリティでやってなかったことをきちんとやる
・サイトスピードアップのためフロントエンドでやってなかったことをやる
・デザイナーまたはディレクターとコーダー間のコミュニケーションはしっかりやる
こんな感じですね…
あとは解析やフレームワークに興味を持ってみようって感じかな。
なので、「置いてかれてる気がする」から「ちゃんとついてかないとコーダー失格！？」なのではなく、
今やっていることをさらに延長させ、必要に応じて新しいものに触れてく、という方向でいいんだなって思えたので、そういう意味で安心しました。
懇親会にも参加しました
名刺交換やご挨拶は控えめになってしまったんですが、以前のCSS Niteや別の交流会でお会いした方とまたお話させていただき、楽しかったです〜。前食べれなかったご飯とかも食べてきました笑
みなさまお疲れ様でした🙏
CSS Nite公式サイト
次は年末のShiftに申し込んであります！
懇親会も参加しますのでお会いできる方はどうぞよろしくです。
