CSS Nite LP39「Coder’s High 2015: コーディングスタイルの理想と現実」に参加してきました。
開演前はちょっとだけ、受付のお手伝いもしていました 😀
前に「Coder’s High」を観てから、早くも五年が経ちました。
フレームワークやビルドツールがスタンダードになった、今のコーディング事情を勉強しようと、上京したのでした。
少し日が開きましたが、セッション全体を通して感じたことをまとめます。
フォローアップ参加はまだまだ受付中ですよ!
これからのコーダーに必要なスキルとは?
テーマが「コーディング」ですから、技術面の情報が多くなります。タスクランナーの「Gulp」や、今どきのスタティック・サイト・ジェネレータのことはまったく知らなかったので、今回も勉強不足を痛感することになりました。
ですが、五年前と比べると、技術の話は「幹」ではなく「枝葉」になっていました。
ツールはあくまで手段として捉え、目的を見据えた設計を施したり、デザイナーやクライアントとの交渉術を鍛えることが、これからのコーダーに求められるようです。
壊れない完璧な設計を求めるのではなく、壊れたときに勇気を持って修復できる設計を
– Yuya Saito
さっさと、ぬかりなく、高品質に
– Takeshi Takatsudo
基調講演で紹介された、CSS Radarの斉藤祐也さんの言葉と、最後のセッションのピクセルグリッド高津戸さんの言葉が、印象に残りました。
若手Web制作者の感覚
二本目のセッションに登壇したアップルップルの森田さんは、1993年生まれ。
Web制作をはじめてまだ二年ですが、最新の技術を集中して身に付け、a-blog cmsの開発にも携わっています。ブラウザ戦争どころか、フレームワークという概念が登場する前の実務制作を経験していません。
彼女の話は、フレームワークの使い方や魅力、デザイン面の話が中心だったので、バリバリのコーダーには物足りないという声もあったようです。
が、逆に私には興味深かったです。
若手Web制作者は、クロスブラウザのテクニックや、CSSの構成や文法を、すでに意識しなくなっているということです。
フレームワークがほとんどやってくれるから、デザインなり先述のマネジメントなり、個々の得意分野の方が優先度が高くなるのでしょう。
私自身も、最近のコーディングはほとんど、bootstrap3を利用します。
私が受注する案件の大半は、コーディングの次にCMSの構築が控えています。デザインはすでに引退していますが、CMSを専門にしている私にとっては、コーディングに割く労力も極力減らしたいのです。
デザイナーとコーダーの新たな戦い
個人的には「music.jpのリファクタリング before / after」が面白かったです。
専門の制作担当者がいなかったため、CSSがカオス化していた「music.jp」を根本から整理した、という話でした。
きっちりとしたスタイルガイドを作成し、「ここにある以外のデザインは認めない」としたため、デザイナーと衝突したそうです。もちろん最終的には和解して、更新や改修にかかる作業時間も劇的に改善したそうですが。
スタイルガイドが完璧であるほど、微妙な余白取り、色味の変更を受け容れにくくなります。
ですが、デザイナーは文字の太さやコンテンツボリューム、写真素材の配色によって微妙に調整することもあるため、すべて同じ規格に揃えるというのは、逆にデザイナーにとっての美意識の妥協でもあります。
かつては、デザイナーとコーダーの衝突というのは「デザイナーさんがカンプをピクセルに合わせてくれない」とか、「コーダーさんがデザインをちゃんと再現してくれない」といった次元の話でした。
今のWeb制作ならではの、高次元の戦いが勃発しているのでした。
まとめ:そして、現実
イベント中、私は他の参加者とTwitterでこんな会話をしていました。
タスクランナーの話で一番聞きたいのは、リテラシーの高くないお客さんに納品する場合はどうしたらいいのか?ということ。 #cssnite_lp39
— Akoarum-K (@Akoarum_K) 2015, 2月 7
@Akoarum_K 私は仮納品後にクライアントさんが調整することがわかっている場合は、その段階でSass、Compass、Gruntは切り離します。
— WebbingStudio (@webbingstudio) 2015, 2月 7
@webbingstudio ありがとうございます!やはりそうなりますよね…。 私もそうするのですが、後でまたスポット的に弊社で対応する場合、またタスクランナーを使いたいということもあるので、良い方法があればいいのにな、と思ってます。。
— Akoarum-K (@Akoarum_K) 2015, 2月 7
.@Akoarum_K 折衷案ではありますが、仮納品後も修正が多そうだったときに、ビルドツールの管理下にないCSSとJSをひとつずつ追加して「ここに追記してください。あとでマージするので」というお願いをしたことがあります #cssnite_lp39
— WebbingStudio (@webbingstudio) 2015, 2月 7
高津戸さんはセッションの冒頭で、「理想と現実というテーマで話してほしいと言われましたが、現実というとなんだかネガティブな印象になります」と言いました。
しかし、残念ながら先の会話が現実だったりします。
第一線の制作者は、バージョン管理もビルドツールを自分の裁量で駆使でき、その後も管理し続けられる環境にあります。
ですが、子請け・孫請けの制作者は、採用できるかは上司や同僚のリテラシー次第、納品後はデータ一式を「クライアントが修正できる状態で」引渡さなければならないのです。
※余談ですが、この折衷案はGitが使えない案件で、ディレクターさんがこのような形で仮納品後の調整をしていたのを、うまい方法だなあと思って参考にさせてもらってます
現実とも向き合おうと考えると、ますますこの記事の最初に書いた「ツールはあくまで手段として捉え、目的を見据えた設計を施したり、デザイナーやクライアントとの交渉術を鍛える」ことが、重みを増してくるように思います。
今回は、全国のコーダーの知り合いにまとめて会うことができ、とても楽しかったです。
同業の皆さん、現実はなかなかしんどいですが「さっさと、ぬかりなく、高品質に」を合言葉に、Web制作の変化の波を乗り切っていきましょう。