コーダー日誌
公開日：2019/11/07
派遣の「顔合わせ」に行くと「sass（scss）かlessできますか？」と確認されることが多くなってきました。
自分の質問力の無さを棚に上げると、「どの程度をできるって言ってるんだろうなー」と毎度思います。
ストレートに確認したいところですが、言葉の選定を誤るとめんどくさい人認定されかねないし、遠回しに訊いてもこちらの考えが伝わらないどころか斜め上方向に墓穴を掘りかねないので、考えあぐねているうちに時間が過ぎてしまうというね・・・。
sassに限らずなんですけど、派遣であちこち行ってるとマジで超人なの？？っていうわけのわからんレベルの人に遭遇することがあるので、自分の中ではそれが「できる」レベルになっちゃって、簡単に「できますか？」って訊かれても「できる」と断言するのがはばかられるわけです。
だいたい、派遣先は本当はそれほど高いレベルは求めてなくても、あとで必要になるかもしれないしってな感じで高いレベルや不急のスキルがあるか訊いてくることがあります。
そいういう仕事ができると思って契約しても、そんな仕事はなく、期待した実務経験をつめないどころか忙しすぎて自前で勉強したスキルが劣化することも・・・。
不要になれば契約打ち切りできる方は気楽でしょうけど、こっちは次に繋げないといけないからねぇ・・・。
必要とされていることは何なのか、自分のやりたい仕事・できる技能とマッチしてるのか、訊き出す質問力を身につけないとなぁ・・・。
それはさておき。
sassは慣れてしまえば、そんなに難しいものではありません。
めったに使わないものは都度調べないといけなかったりするかもしれませんが、よく使うものは憶えてしまうし、ネット上にはいろいろと使い方やチートシートを提供してくださっている方々もいらっしゃいます。
導入・設定云々も環境によりますが、簡単に使えるようになるエディタや、コンパイルまでしてくれるオンラインエディタもありますし、環境ごとのhowtoもネットにたくさん落ちているので、ちょっと前よりずっと簡単に導入できるはずです。
とりあえず、面倒な設定はうっちゃって、使ってみましょう。
左に最初の画面にsassを書いていくと、コンパイルして右側にくれるので、画面上の方の[css]タブで切り替えるとcssを表示してくれます。
viewとかOptionsとかメニューをいろいろ変えるとhtmlも書けてプレビューできたり、sassのバージョンを変えたりできます（リロードが必要かも）。
逆にcssをsassに変換してくれるものもあります。sass（scss）でどう書いたらいいかわからなくなったときにも使えそうですね。
まずは、すぐ実務でも使えそうな入れ子とか変数とかを試してみるとよいかと思います。
慣れてきたらmixinとかextendとかも使ってみましょう。
実際、業務で使用となると、オンラインエディタよりもPCにインストールされたエディタで使えた方が助かると思います。たまに、謎の社内規定やCMSが対応してないとかで、sass導入できない企業に遭遇しますが・・・。
ワタクシの自前環境はVS Code＋gulpでsassを使えるようにしていますが、gulpなどを入れなくても拡張機能を追加すれば使えるようになるので、試してみてください。
ちょっと前まではRubyがどうのCompassがどうのって、やや面倒くさい感があったのですが、楽になったなぁ・・・。
この他にもあると思うので、ご自身が使い慣れたエディタでsassのコンパイルができるかgoogle先生たちに訊いてみてください。
sassを勉強するに当たり、『Sassの教科書』といった書籍もあります。ワタクシの体感では、制作会社やwebサイトを自社制作している会社で置いていある率が結構高いので、実務に耐えられるくらい信頼性高いのかなぁと思います。
sassを学ぶのに役立ちそうな記事やチートシートもご紹介しておきます。
古い記事も混ざってます。最新の情報はgoogle先生たちに訊いてください。
sassを勉強していると、SusyとかBourbonとか何かがでてきます。導入している企業に出会ったことがないのですが、知識としてはあったほうがいいかも？
数ページで収まるようなwebページや数種のテンプレートで収まるブログなどでは、あまり気にしなくても良いと思いますが、大規模なwebサイトになってくると開発に関わる人数も増えるので、名付けルールなどが重要になってきます。
webに限らずプロジェクトの規模が大きくなれば、いろいろなものの管理が煩雑になります。
cssもしかりで、読み込むcssファイルが多すぎてそのページに本当に必要なのか、class名が謎すぎて（あるいは汎用的すぎて）どんな役割で何に影響しているのかわからなかったり、カオス状態になることがあります。
そういうわけで、なるべく早い段階（できれば仕様を作る段階）でcss設計をしておくことが大事なのですが、そこで登場するのがcss設計手法というものです。
css設計手法のなかで、最近の主流なのかな？というものがflocssです（注：個人の体感です）。
css（に限らず）設計手法や思想は、世界中でいろいろ提案され、実際に導入・運用しているwebサイト（プロジェクト）があります。
それぞれにメリット・デメリットやプロジェクトとの相性などといったものがあると思いますが、そのポテンシャルを最大限に引き出すには、プロジェクトに関わる人たちが導入する手法を理解し実行していけるように認識を合わせておくこと、定期的にメンテナンスすること、正しく運用されているかチェック体制を整えることなどがあります。
また、設計手法やルールにこだわるあまり柔軟性をなくし、かえって管理が煩雑になることもあるので、実際の運用状況を客観的に分析し、運用メンバーの意見も確認しつつ、そのプロジェクトに最適な方法を模索していく必要はあると思います。
想定より学習コストや運用コストが人的コストとして現れてくる可能性があります。
プロジェクトの規模や目的（性質）、開発・運用環境や使用するツール、運用期間、関わるメンバー（メンバーの入れ替えの可能性も含め）によっては、あえてcss設計はせずにゆるーいルール設定だけするのもありかもしれません。
ページ数も関わる人数もそれほどではなく、運用期間も限定的なサイトで、あんまりガチガチな設計・ルールを設定すると、かえって工数が増えるパターンもあります。コーダーの立場からすると正直class名などが煩雑でも、webブラウザの開発ツールで簡単に確認できたりするので、それほど負荷がかからない状況もあります。
某企業ではSMACSSを導入して、新規ページなどのデザインコストをさげる（デザイナーはイラストなどのパーツ作りだけしてページはSMACSSで設計されたcssを使ってコーダーがコーディングする）ことを試みましたが、ページごとの印象があまりにも面白みに欠けてユーザーに肝心なことが伝わっていたのかどうか謎状態になっていました。
そもそものコンテンツの目的（テーマ）・内容もさることながら、それをユーザーに伝える技術を持つライターさん・デザイナーさんのチカラも偉大です。そしてそれを実現する技術屋さんのチカラも大事！
それらのチカラをそれぞれ発揮して、ユーザーに思いを伝えるには自由度と愛（思いやり）も必要ってことをそれぞれが忘れないようにしたいですね。
うーんと偉い人はもちろん、マーケターさんも営業さんもプロデューサーさんやディレクターさんだって、愛あるお仕事、おねがいしまーす！
go to homeindex