WEB制作現場で通用するレベルのコーダーになるために知っておきたい16のこと。

2020年2月29日 18:31

こんにちは。@CoComina_okiです
今日も絶賛コーディング中です。最近はReact x Typescriptを勉強してます。Web歴ももう7年近くになりました。

今回はProgateやドットインストールなどで基礎を終えて、次のレベルを目指すWebデザイナーやコーダーのために、僕が経験した「これは知っておいた方がいいよ」という手法・知識をまとめてみました。

確実にどの現場でも役に立つ！とまでは言い切れませんがほとんどのWeb制作の現場で役に立つと思います。よろしければご参考ください。

# 1. Markup編

1-1. セマンティック要素で文書構造を意識したマークアップができる

セマンティックの意味については「Weblio辞書」が簡潔にまとまっていると思いますので引用します。

セマンティックとは、一般的には「意味」や「意味論」に関することを指す語である。IT用語としては、コンピュータに文書や情報の持つ意味を正確に解釈させ、文書の関連付けや情報収集などの処理を自動的に行わせる技術について用られる語である。
https://www.weblio.jp/content/%E3%82%BB%E3%83%9E%E3%83%B3%E3%83%86%E3%82%A3%E3%83%83%E3%82%AF

これらセマンティック要素を使ってマークアップすることで検索エンジンにこのページは何について書かれたページなのかを適切に伝えられます。

下記にセマンティック要素をありとなしの2つのマークアップを用意してみました。

# セマンティック要素なし

<div class="header">
  <h1><a href="#">HTML5のセマンティック要素について</a></h1>
</div>

<div>
  <h2>セマンティック要素とは？</h2>
  <div>
    <p>・・・本文・・・</p>
  </div>
</div>

<div>
  <h2>セマンティック要素の使い方</h2>
  <div>
    <p>・・・本文・・・</p>
  </div>
</div>

<div>
  <h2>セマンティック要素の一覧</h2>
  <div>
    <p>・・・本文・・・</p>
  </div>
</div>

# セマンティック要素あり

 <header class="header">
   <h1><a href="#">HTML5のセマンティック要素について</a></h1>
 </header>

 <section>
   <h2>セマンティック要素とは？</h2>
   <div>
     <p>・・・本文・・・</p>
   </div>
 </section>

 <section>
   <h2>セマンティック要素の使い方</h2>
   <div>
     <p>・・・本文・・・</p>
   </div>
 </section>

 <section>
   <h2>セマンティック要素の一覧</h2>
   <div>
     <p>・・・本文・・・</p>
   </div>
 </section>

どちら日本語は同じ内容ですがマークアップが違います。
前者は<div>ばかり使用されていますが、後者は<header>や<section>を使用しています。

さらにわかりやすくするためにリストにしてみます。

●セマンティック要素なし
div：HTML5のセマンティック要素について
div：セマンティック要素とは？
div：セマンティック要素の使い方
div：セマンティック要素の一覧

●セマンティック要素あり
header：HTML5のセマンティック要素について
section：セマンティック要素とは？
section：セマンティック要素の使い方
section：セマンティック要素の一覧

ここでピンとくる方もいると思います。

どちらも「HTML5のセマンティック要素について」について解説する内容が書いてあることが想像できます。

ですが、後者のセマンティック要素ありの方がどれが本題（<header>）で、どこからどこまでが全体文章のうちの一章（<section>）なのかが、
明白ですので文書構造としては後者の方が適切です。

※ クラス名にheaderなどついていますがクラスはCSSの装飾のためのもので文書構造とは関係ありません。

このように文書構造を意識することで検索エンジンなどにも「何について書いてあるページなのか？」が伝わりやすくなります。
参考までに下記によく使うセマンティック要素をあげておきます。

「 header、section、article、aside、footer、nav、main 」
※セマンティック要素には必ず見出し（h1〜h6）が必要です。見出しが不要な場合はセマンティック要素を使用するべきではありません。

1-2. クラス名に命名規則を活用している

HTMLにクラス名をつける時に適当につけてはいけません。
一定のルール（命名規則）を用いてクラス名つけることはとても大切です。
下記にダメな例のパターンをあげてみました。

① クラス名の汎用性が高すぎて後々こわい。
　クラス名が汎用的なので他の場所でも使用する可能性がある。
　複数人での作業や他の人からの作業引継ぎ時に影響を受けやすい

<div class="profile">
 <h3 class="name">CoComina</h3>
 <p class="age">38</p>
 <p class="birthplace">沖縄</p>
</div>

② 単語の区切り方に規則性がない。
　キャメルケース、ハイフン、スペースでの区切りが混ざってる

<div class="profile">
 <h3 class="profileName">CoComina</h3>
 <p class="profile-age">38</p>
 <p class="profile birthplace">沖縄</p>
</div>

③ ハイフンやアンダーバーの使い方に規則性がない。

<div class="profile">
 <h3 class="profile-name">CoComina</h3>
 <p class="profile__age">38</p>
 <p class="profile--birthplace">沖縄</p>
</div>

上記のようにクラス名に命名規則がないとクラス名を決める時に悩んでしまい作業スピードが落ちたり、外部の人がみた場合に「ソースコードが汚くて見辛い」などと言われたりします。

成果物に一定の品質も保つためにも、クラス名には命名規則を必ず用いましょう。

# どうやって命名規則を決めたらいいの？
マークアップに慣れるまでは自分で命名ルールを決めるのは難しいです。
そんな時はいくつか有名な設計手法がありますのでそれらのルールにしたがってクラス名をつけていきましょう。

ここでは、僕も使っている設計手法の一つであるBEMを紹介します。

# BEM（ベム）
Block、Element、Modifierの頭文字をとった設計手法。
最近ではよく見る設計手法です。ルールが単純かつ覚えやすく拡張性もあるのでおすすめです。

Block：主に枠組みとなる要素。
Element：Blockの中に存在する子要素。
Modifier：BlockやElementを修飾するもの（状態を表す場合にも用いる）

例：.block__element--modifier
Blockの後ろに「 __ 」（アンダースコア）を2つ。続いてElement、BlockやElementにModifierを付ける場合は「--」（ハイフン）を2つはさみます。
「main title」など2単語で1つのクラス名の場合はハイフン1つで、区切ります。（main title → main-title）

# BEMを使ったサンプル

// Block
<div class="profile">

 // Element
 <h3 class="profile__name">CoComina</h3> 

 // Element + Modifier ( --hidden )
 <p class="profile__age--hidden">38<span　class="profile__sex">男</span></p>
 
 // Element + Modifier ( --red )
 <p class="profile__birthplace--red">沖縄</p>

</div>

--hiddenで年齢（38）と性別（男）を非表示にする「状態」も書いてみました。クラス名に規則性があって分かりやすいですね。
Block（.profile）内に新たにElementを追加するときもクラス名は「.profile__XXX」とBlockの名前を一部引き継いで追加すればいいので更新もしやすいです。

BEMの他にも「OOCSS」や「SMACSS」などの設計手法があります。
※解説サイトがいっぱいありますのでここでは細かい説明は割愛します。

ちなみにこれらの設計手法をベースにして独自カスタマイズしてもOKです。（原型がわからなくなるほどのやり過ぎ厳禁）

命名規則は最初はわずらわしいと感じるかもしれません。
ですが、理解するとマークアップも綺麗になり、作業スピードも上がりますのでどんどん活用していきましょう。

1-3. コメント（コメントアウト）を適度に残している

最近では「コメントは書かないほうがいい。ソースコードを読んでも意味が分からないのであればそれはその人のスキル不足だ！」などの風潮がみられますがそんなことはありません。

# コメントは書いてください。
スキル不足だ！とかどうこういう前に単純にその方が把握しやすいです。HTMLに限らずPHPやJSなどでもそうですが、コメントなしのソースコードを読んでも動作や構造を把握はできます。

ですが、コメントがあった方が把握するまでのスピードが違うんです。コメントあった方が早いんです。

特に全て自分で作った場合はふるまいを断片的に覚えてるのでいいですが、他者が作った場合はコメントが無いと解読が面倒です。

# コメントの書き方には規則性を保つ。
コメントも適当に書いてはいけません。コメントを書く目的をしっかりもちましょう。

HTMLのマークアップは時に階層が深くなるため、閉じタグ迷子になることがあります。その予防として閉じタグの箇所に  で目印としてコメントを残すことはよくありますよね。

この時コメント適当に書くのではなく「どこにをどのように書くかということは大切」です。一定の規則性を用いてコメントを書いておきましょう。

下記にダメな例と良い例のサンプルをあげてみました。

# ダメなコメントの書き方の例

// コメントの書き方に規則性がない、記述場所もチグハグ

<div id="foo" class="bar">
 <ul class="list">
   <li>・・・</li>
   <li>・・・</li>
 </ul>
 <!-- ul.list --> // ① ここでは閉じタグの下にある。要素名も含まれている
</div><!-- #foo.bar --> // ② ここでは閉じタグの右にある。要素名も含まれていない

<div id="hoo" class="dar">
 <ul class="list">
   <li>・・・</li>
   <li>・・・</li>
 </ul><!-- .list --> // ① ここでは閉じタグの右にある。要素名が含まれていない
</div>
<!-- div#hoo.bar --> // ② ここでは閉じタグの下にある。要素名が含まれていない

コメントの位置やテキストに規則性がなくて分かりづらいですね。
下記はどうでしょう？

# ダメなコメントの書き方の例

// 要素名は書かずに閉じタグを表す （ / ）とid（ # ）とクラス（ . ）だけをコメントアウト内に書く。
// 記述場所は閉じタグの下に統一した。

<div id="foo" class="bar">
 <ul class="list">
   <li>・・・</li>
   <li>・・・</li>
 </ul>
 <!-- /.list -->
</div>
<!-- /#foo.bar -->

<div id="hoo" class="dar">
 <ul class="list">
   <li>・・・</li>
   <li>・・・</li>
 </ul>
 <!-- /.list -->
</div><!-- /#hoo.bar -->

こちらの方が統一性があってみやすいと思いませんか？
僕はいつもこの方法でコメントを残しています。

これらは閉じタグ迷子防止のためのコメントですが、他にも「HTMLをPHPに組み込む際のメッセージの意味を持つコメント」、「変更した箇所を知らせる」などのコメントを僕は下記のように書いてます（参考までに）

// PHPでループして出力することがわかっている場合
<div>
 <!-- Loop Start ( 10件表示 )-->
 <section>
   <h2 class="title"><a href="#">タイトル</a></h2><!-- 文字数最大：10文字（それ以降は...で表示） -->
   <p>・・・本文・・・</p><!-- 文字数最大：88文字（それ以降は...で表示） -->
 </section>
 <!-- Loop End -->
</div>

// 更新した場合（クラス名を変更）
<div>
 <section>
   <!-- クラス名.titleだと他の場所と被る可能性がありますので、.article-titleに変更 -->
   <h2 class="article-title"><a href="#">タイトル</a></h2>
   <p>・・・本文・・・</p>
 </section>
</div>

先ほどのコメントの用途は閉じタグ迷子帽子の目印になればよかっただけなので最低限のことしか書いてませんでした。

ですが、これはちょっと違います。メッセージ性が高いコメントです。
こうすることで「どこからどこまでをループで出力すればいいのか？」「今回変更された箇所はここだけだな。」など把握が早くなるので、複数人での作業の時にやりやすくなります。

こうすることで電話嫌いな人ににいちいちチャットで「どこが変更されたの？えーっとですねー」なんて無駄なやりとりもせずに済みますよ！

なんのためにコメントを書くのか？誰のためにコメントを書くのか？など、意味も考えつつ規則性も守ってコメントは書きましょう。

※ただし、書きすぎると余計に混乱しますので注意しましょう。

1-4. 空タグを乱用しない

基本的にdivやspanなどタグの中身を空にしてはいけません。
絶対使っちゃだめ！とゆうわけではありませんが、多用は避けるべきです。

元々、HTMLはマークアップ言語（文書を構造化する言語）です。
そのためタグの中身が空なのは良しとは言えません。

装飾目的のために少しなら問題ありませんができるだけ多用は避けておいた方が無難です。

タグの中に入れるテキストが思いつかない場合は擬似要素でどうにかできないか？などをまず検討しましょう。
Makeup編はここまでです。
続いては、# 2.CSS編です。

# 2. CSS編

2-1. 文字サイズは最小10pxまでを使用する

Chromeではデフォルトで最小文字サイズは10pxに設定されています。
8pxや9pxを使用しても10pxにされます。

もしも、デザイナーから上がってきたデザインファイルに10px未満の文字サイズが指定されていたら10pxに修正できないか相談してみましょう。

いざ、コーディングを始めてみたら「8pxや9pxに設定したが強制的に10pxされてしまい、デザインが崩れてしまった・・・」などのトラブルを未然に防ぐことができます。

2-2. CSSの指定に要素名は含めない

CSSでHTML要素にスタイルを当てる時にどのように指定していますか？
下記のように要素を含めて指定していませんか？

// HTML
<div class="wrapper">
 <div class="section">
   <h2 class="section__title">セクションタイトル</h2>
   <div class="section__content">
     ・・・本文・・・
   </div>
 </div>
</div>


// CSS
div.wrapper {
}
div.section {
}
div.section h2 {
}
div.section div {
}

上記のCSSの指定でも間違いではありませんのでスタイルは適用されます。
ですが、この指定方法だとHTML側のマークアップが変更された時にCSSも調整しなければいけませんので、賢いやり方だとは言えません。

・<div class="section"> が<section class="section">に変更されたら？
　→ HTML側を修正後に、CSSの「div.sectionをsection.section」に変更

・<h2> が<h3>に変更されたら？
　→ HTML側を修正後に、CSSの「div.section h2をsection.section h2」に
　　変更

・<h2> が<div class="wrapper">直下に位置を変更されたら？
　→ HTML側を修正後に、CSSのdiv.section h2をdiv.wrapper h2に変更、
　　さらにsection内にh2がくる場合も含めてsection.section h2を追記

上記のようにHTML側が変更されると同時にCSS側の修正範囲も大きくなってしまい工数が増えてしまいます。

では、CSSの指定方法を下記のように変更してみます（HTMLは変更なし）

// HTML
<div class="wrapper">
 <div class="section">
   <h2 class="section__title">セクションタイトル</h2>
   <div class="section__content">
     ・・・本文・・・
   </div>
 </div>
</div>


// CSS
.wrapper {
}
.section {
}
.section__title {
}
.section__content {
}

どうでしょう？
CSSは全てクラス名で指定しています。
これならHTMLが多少変更されてもCSSを調整する範囲は少なくて済みます。HTMLの変更内容によってはCSSを調整する必要さえ無いかもしれません。

・<div class="section"> が<section class="section">に変更されたら？
　→ .sectionのみでCSSを指定しているので影響なし

・<h2> が<h3>に変更されたら？
　→ .section__titleのみでCSSを指定しているので影響なし

・<h2> が<div class="wrapper">直下に位置を変更されたら？
　→ 入れ子関係に依存せずに.section__titleのみでCSSを指定しているので
　　影響なし

このように、CSSの指定にはなるべく要素名を使用しないことで影響範囲を限定的にすることが大切です。

ここまでを理解すると次の疑問が浮かぶと思います。
# HTML要素の全てにクラス名をつける必要があるの？
答えは "ノー" です。
マークアップした全てのHTMLにクラスをつける必要はありません。

実際の現場では<li>を50個書いたり、<table>の中に<th>や<td>が膨大にあるなど、そんなケースがちょくちょくあります。
なのでHTML要素全てにクラス名をつけるのは労力が大きすぎます。
現実的ではありません。

<ul>や<dl>や<table>など内包される子要素がある程度決まっている場合は、親要素にクラス名をつけ、そこからスタイルを指定するやり方にしましょう。
もちろん、必要であれば子要素にクラス名を追加してもかまいません。

// HTML
<ul class="breadcrumb">
 <li><a href="#">ホーム</a></li>
 <li><a href="#">カテゴリー</a></li>
 <li><span class="breadcrumb__current">記事のタイトル</span></li>
</ul>

// CSS
.breadcrumb {
 〜〜
}
.breadcrumb li {
 〜〜
}
.breadcrumb a {
 〜〜
}
// spanからaに変わっても問題ないようにクラス名で指定しておく。
.breadcrumb .breadcrumb__current {
 〜〜
}

考え方としては、「HTML要素自身にCSSとの依存関係を持たせる」のではなく「HTML要素に付与しているクラスにCSSとの依存関係を持たせる」という考えをベースに構築していくとやりやすいかと思います。

Webサイト公開後も「コンテンツの更新」や「SEO対策のテスト」など細かい修正はよく入ります。その時に修正箇所が少なくて済むようにしておくことで自分が楽になります。

2-3. モバイルファーストでコーディングする

モバイルファースト（モバイルデバイス優先）はデザインでも使われる言葉ですが、ここではCSSの書き方に限定してお話します。

ご存知でしょうか？
ほとんどのサイトで閲覧デバイスの割合は、下記のようになっています。

1位：スマートフォン
2位：PC
3位：タブレット

スマートフォンでの閲覧が一番多いです。
よって、CSSの書き方もスマートフォンでの閲覧時にストレスを少なくする書き方（モバイルファースト）になるのは必然です。

言葉で説明するより下記の「非モバイルファースト」と「モバイルファースト」のCSSの書き方を見比べていただいた方が分かりやすいかと思います。
※それぞれメディアクエリ（@media）の箇所にご注目ください。

① 非モバイルファーストのCSSの書き方 （ PC用のスタイルから始まる ）

.section {
}
.section__title {
}
.section__content {
}

@media screen and (max-width:768px) {
 〜〜ここはタブレット用のスタイル〜〜
}

@media screen and (max-width:414px) {
 〜〜ここはスマートフォン用のスタイル〜〜
}

② モバイルファーストのCSSの書き方 （ スマートフォン用のスタイルから始まる ）

.section {
}
.section__title {
}
.section__content {
}

@media screen and (min-width:768px) {
 〜〜ここはタブレット用のスタイル〜〜
}

@media screen and (min-width:1024px) {
 〜〜ここはPC用のスタイル〜〜
}

① 非モバイルファーストのCSSの書き方について
この書き方はデバイスサイズが「 PC → タブレット → スマートフォン」の順で書かれているため、スマートフォンでもPCとタブレット用のスタイルを読み込んでしまいスマートフォンへのストレスが大きいです。

② モバイルファーストのCSSの書き方について
こちらの書き方は「スマートフォン → タブレット → PC 」の順で書かれているため、スマートフォン（768px未満）では「@media screen and (min-width:768px) 」以降はデバイスサイズが該当しないので読み込まれることはありません。こちらの方がスマートフォンにストレスなく優しいですね。

正直、モバイルファーストでCSSを書けない人もたまにいます。
この書き方ができるようになるまでは多少の経験が必要だなっとは僕も思います。

ですが、諦めずにぜひチャレンジしてください。
PCファーストでずっとやっていると、サイト完成後にスマフォでの読込速度が思ったより遅いからどうにかして！など、せっかく書いたCSSをモバイルファーストでほぼ0から書き直さなければいけない時もあったりします。
（体験談）

そんな時にモバイルファーストに慣れていないと、とてもしんどいです。
失敗よりチャレンジが大事です。
チャレンジしないことには経験もつめません。がんばりましょ！

続いてはSassについてです。

2-4. Sassを使う時の注意点

Sass（サース、サス）と読みます。拡張子は.scssです。
CSSを拡張させて効率よくかけるようにしたCSSのメタ言語です。

みなさん使われているでしょうか？最近のWeb業界ではSassを使うのが主流になっています。
ここではSassの使い方を説明するのではなく、あくまでSassを使う上での注意点のみに限定して書いています。

① ネスト（入れ子）しすぎない

// ネストが深いのでクラス名を 「 command + F 」で検索できない
.section {
 &__title {
 }
 &__content {
 }
 &__list {
   li {
   }
 }
}

// ネストが浅いのでクラス名を 「 command + F 」で検索できる
.section {
}
.section__title {
}
.section__content {
}
.section__list {
   li {
   }
 }

現在制作真っ最中の場合の時はネストが深くても構造が頭の中に入っているので大した弊害になりませんが、納品後にある程度時間が経過し、久しぶりの更新作業の際などにちょっと困ります。

なぜなら「command + F」で検索してもヒットせず、修正箇所を把握するのに時間がかかってしまうためです。あまりネストを深くしないように注意しましょう。

他のメリットとしてプロジェクトに途中参戦した人でもすぐに内容を把握できるので、余計な説明が省けるので結果的に自分が助かります。

② &を多用しない
&を使う場合は、下記のような兄弟要素や状態変化の時などに、できるだけ限定的に使うようにするのがおすすめです。
&を多用しすぎて行が長くなり画面に入りきらず「この&ってなんだっけ？」っていちいち上にちょっとスクロールして確認するのが手間です。

  .section__table {
    tr {
     & + tr {
       〜〜 tr + tr の時のみ 〜〜
     }
    }
  }

  .section__list {
   li {
     & + li {
       〜〜 li + li の時のみ 〜〜
     }
   }

   a {
     &.active {
       〜〜 アクティブ時のみ 〜〜
     }
     &.disabled {
       〜〜 非アクティブ時のみ 〜〜
     }
   }
 }

③ カラーやブレイクポイントなど変数にまとめてそこから利用する。
サイト上で使用されているカラーやブレイクポイントなど共通の設定は、
変数にまとめておくことで管理・変更がしやすくなります。

変数に使用する命名規則やカラーコードの書き方にも注意して統一性をもたせるようにしましょう。

※** 変数名は必ずキャメルケースで書く事 ***

// ブレイクポイント （ 必ず小中大の順番で書く ）
$mobileMedium: 375px:
$mobileLarge: 414px:
$tabletSmall: 600px:
$tabletMedium: 768px:
$tabletLarge: 1024px:
$pcSmall: 1080px:


// カラー （ 省略できる場合は3桁にする。大文字は使用しない ）
$mainColor: #724c8f;
$red: #ff0000;
$blue: #0000ff;
$gray: #ddd;
$lightGray: #f0f0f0;

④ CSS（.css）を圧縮して出力している
改行やタブなどを削除して1行にすることを " 圧縮・Minfy ”と言います。

WebPackやGulpなどのツールでは、Sassで作ったソースコードを出力する際に圧縮するか否かを設定できますので必ず圧縮しましょう。

CSSを圧縮し読込速度を軽減できるのも、Sassを使うメリットの一つです。使わない手はありません。

④ マップファイル（.map）も用意している
ブラウザはSassを読み込むことはできません。
あくまでSassで作成し出力されたCSSを読み込み、スタイルを適用していきます。

ですが、このままだとSassとCSSのスタイルの記述場所がどのように一致しているのかすぐに把握できないのでデベロッパーツールなどで修正箇所を探す時に修正箇所がわかりづらくなってしまいます。

そんな時に役に立つのがマップファイル（.map）です。

マップファイルはSassとCSSのそれぞれのスタイルの記述場所をマッピングしてくれます。これにより「このCSSファイルのこのスタイルは、このSassファイルのここに書かれている」という事がすぐに分かるようになりますのでデベロッパーツールで修正箇所をすぐに把握できます。

下記にマップファイル（.map）ありとなしの場合のChrome Developer Toolsのキャプチャを用意しました（CSSは圧縮されている前提です）

# マップファイルなし

# マップファイルあり

右側の赤枠のところですが、下記のように書かれています。

マップファイルなし：index.css: 1
マップファイルあり：index.scss: 13

マップファイルありの方にはSass（.scss）ファイルの該当箇所の行が書かれているのでどのSassファイルのどこを修正したらいいのか一目瞭然です。

一方、CSS（.css）の方は1行目に書かれているとの情報しかありません。
ちなみにこのCSSの1行目は下記のようになっています。
※横にスクロールできます。

@-webkit-keyframes fadeIn{0%{opacity:0}100%{opacity:1}}@keyframes fadeIn{0%{opacity:0}100%{opacity:1}}.container{padding-top:1.4rem}.mainvisual{margin-top:5.4rem;background:#c3deff}.mainvisual__inner{width:100%;max-width:128rem;margin-right:auto;margin-left:auto}.swiper-slide{overflow:hidden;padding:0 1.4rem}.swiper-image{position:relative;padding-top:14%}.swiper-image dt{text-align:center;opacity:0;-webkit-transform-origin:center bottom;transform-origin:center bottom;-webkit-transform:scale(0.5);transform:scale(0.5);-webkit-transition:all .4s .2s ease-in-out;transition:all .4s .2s ease-in-out}.swiper-image dt img{height:50vw}.swiper-image dd{position:absolute;opacity:0;-webkit-transform-origin:center bottom;transform-origin:center bottom;-webkit-transform:scale(0.5);transform:scale(0.5)}.swiper-image dd a{display:block;width:100%}.swiper-image dd img{width:100%}.swiper-image.-first dt{padding-left:6%}.swiper-image.-first dd.comment01{width:32%;top:18%;left:8%;-webkit-transition:all .4s 0s ease-in-out;transition:all .4s 0s ease-in-out}.swiper-image.-first dd.comment02{width:42%;top:61%;left:4%;-webkit-transition:all .4s .2s ease-in-out;transition:all .4s .2s ease-in-out}.swiper-image.-first dd.comment03{width:28%;top:8%;left:58%;-webkit-transition:all .4s .4s ease-in-out;transition:all .4s .4s ease-in-out}.swiper-image.-first dd.comment04{width:23%;top:46%;left:70%;-webkit-transition:all .4s .6s ease-in-out;transition:all .4s .6s ease-in-out}.swiper-image.-second dd.comment01{width:32%;top:16%;left:10%;-webkit-transition:all .4s 0s ease-in-out;transition:all .4s 0s ease-in-out}.swiper-image.-second dd.comment02{width:45%;top:60%;left:0;-webkit-transition:all .4s .2s ease-in-out;transition:all .4s .2s ease-in-out}.swiper-image.-second dd.comment03{width:32%;top:6%;left:60%;-webkit-transition:all .4s .4s ease-in-out;transition:all .4s .4s ease-in-out}.swiper-image.-second dd.comment04{width:34%;top:50%;left:67%;-webkit-transition:all .4s .6s ease-in-out;transition:all .4s .6s ease-in-out}.swiper-slide-active dt{opacity:1;-webkit-transform:scale(1);transform:scale(1)}.swiper-slide-active dd{opacity:1;-webkit-transform:scale(1);transform:scale(1)}.notice{width:100%;background:#c33;color:#ffff45;padding:1.4rem;border-radius:.3rem;margin-bottom:1.4rem}@media screen and (min-width: 768px){.notice{margin-bottom:2.8rem}div.swiper-slide{display:-webkit-box;display:-ms-flexbox;display:flex;width:50%}dl.swiper-image{width:100%;padding-top:14%}dl.swiper-image dt{-webkit-transition:all .4s 0 ease-in-out;transition:all .4s 0 ease-in-out}dl.swiper-image dt img{height:28vw}dl.swiper-image.-first dd.comment01{width:32%;top:26%;left:6%;-webkit-transition:all .4s .6s ease-in-out;transition:all .4s .6s ease-in-out}dl.swiper-image.-first dd.comment02{width:48%;top:65%;left:0;-webkit-transition:all .4s .4s ease-in-out;transition:all .4s .4s ease-in-out}dl.swiper-image.-first dd.comment03{width:32%;top:14%;left:62%;-webkit-transition:all .4s .2s ease-in-out;transition:all .4s .2s ease-in-out}dl.swiper-image.-first dd.comment04{width:28%;top:50%;left:74%;-webkit-transition:all .4s .8s ease-in-out;transition:all .4s .8s ease-in-out}dl.swiper-image.-second dd.comment01{width:32%;top:20%;left:8%;-webkit-transition:all .4s .8s ease-in-out;transition:all .4s .8s ease-in-out}dl.swiper-image.-second dd.comment02{width:48%;top:60%;left:-1%;-webkit-transition:all .4s .6s ease-in-out;transition:all .4s .6s ease-in-out}dl.swiper-image.-second dd.comment03{width:32%;top:12%;left:64%;-webkit-transition:all .4s .4s ease-in-out;transition:all .4s .4s ease-in-out}dl.swiper-image.-second dd.comment04{width:34%;top:50%;left:67%;-webkit-transition:all .4s .2s ease-in-out;transition:all .4s .2s ease-in-out}.container{padding-top:2.8rem}.is-loaded dl.swiper-image dt{opacity:1;-webkit-transform:scale(1);transform:scale(1)}.is-loaded dl.swiper-image dd{opacity:1;-webkit-transform:scale(1);transform:scale(1)}}@media screen and (min-width: 1024px){.mainvisual{margin-top:0}.main{width:calc(100% - 48rem);padding-right:1.4rem}}@media screen and (min-width: 1280px){dl.swiper-image{padding-top:10%}dl.swiper-image dt img{height:26vw}dl.swiper-image.-first dd.comment01{width:18.4rem;top:9rem;left:4rem}dl.swiper-image.-first dd.comment02{width:30rem;top:26rem;left:-1.4rem}dl.swiper-image.-first dd.comment03{width:19.6rem;top:6rem;left:38rem}dl.swiper-image.-first dd.comment04{width:16rem;top:22rem;left:45rem}dl.swiper-image.-second dd.comment01{width:19.6rem;top:9rem;left:4rem}dl.swiper-image.-second dd.comment02{width:29.4rem;top:24rem;left:0}dl.swiper-image.-second dd.comment03{width:19.4rem;top:4rem;left:40rem}dl.swiper-image.-second dd.comment04{width:20.8rem;top:20rem;left:40rem}.main{width:calc(100% - 55rem);padding-left:2.8rem;padding-right:2.8rem}}

/*# sourceMappingURL=maps/index.css.map */

圧縮されて1行になっているのでめちゃくちゃ横に長いです。
これでは修正箇所を目視で探すのは困難ですし、修正範囲を見落としがちになってしまいます。

このようなことにならないためにもSassを使うなら必ずマップファイルも出力するようにしましょう。

WebPackやGulpなどでSassからCSSを出力する際にマップファイルも同時に出力できますので設定しておきましょう。

Sassはできることが多いため、コードのばらつきが大きくなり過ぎないようにチーム内で使用してはいけない機能や書き方に決まり事などがあったりしますので、その際はリーダーやディレクターに確認してみましょう。

# 3. SEO編

3-1. SEOでマイナス効果にならないマークアップをする

僕は見た目を整えるだけがコーダーの仕事とは思っておらず少しはSEO面も気にする必要があると思っています。

まず、Webサイトは見られてナンボです。作ったからはい終わり！というのは少し無責任かなと思います。

多数の人にみてもらうには検索結果に表示される必要があります。
そのため、SEOでマイナス評価を受けないようにマークアップし、少しでも検索結果に表示されやすくするのはコーダーとしての仕事の範疇ではないかと考えます。（LPなどの最初からSEO度外視の場合はそうではありません）

ここではキーワードの選定や見出しのつけ方などの、本格的なSEO対策の話は置いといてコーダーという立場からのSEOでマイナス評価にならない方法をいくつかご紹介たいと思います。

① セマンティックマークアップを取り入れる
これは本記事の最初のテーマ【Markup編：セマンティック要素で文書構造を意識したマークアップができる】に書かれている内容と同じです。
セマンティック要素を使ってできたWebページは検索エンジンに意図が伝わりやすくなり、検索結果に表示されやすくなります。

② alt属性を空にしない、または重複させない。
imgタグに使うalt属性ですがこれは空にしてはいけません。
または1ページに使用されいているaltのテキストが重複してはいけません。

単なる装飾目的のための画像（意味のないアイコンなど）であればaltは無くてもいいのですが、最初の頃は判断がつきづらいかと思いますので全てのimgタグにaltは必ずつけるようにしておいたほうがいいでしょう。

② titleとdescriptionは重複させてはいけない。
SEOの基本としてページコンテンツはもちろんですが「一つのURLに対して一つのユニーク（一意）なtitleとdescription」である事が基本です。

特にECサイトやWordPressなどで作ったカテゴリーごとの記事一覧ページにように、同じテーマで複数のページを跨ぐ作りになっている場合は下記のように一部でも変更して重複させないように気をつけましょう。
※ページコンテンツは必然的に重複しないはずなので割愛します。

■1ページ目
title：プラダのバッグ一覧
description：このページはプラダのバッグを紹介しています。

■2ページ目
title：プラダのバッグ一覧（ページ 2）
description：このページはプラダのバッグを紹介しています（2）

③ canonicalを設定する。
上記と関連してきますが、複数のページを跨ぐ作りになっている場合は、
1ページ目と2ページ目の内容が似通ってしまい、Googleにコンテンツが重複していると見られマイナス評価につながる可能性があります。

これは、ECサイトなどで、バリエーション違いの商品が多くて、どうしても掲載する内容（サイズや素材など）が被ってしまう場合に起こりがちです。

canonicalを設定する事で重複コンテンツを1つのURLにまとめる（正規化すると言います）ことで、オリジナルページをGoogleに教える事ができます。
これによりマイナス評価を避ける事ができます。

// 2ページ目以降にcanonicalを追加する （ 1ページ目には不要 ）
<meta canonical="https://example.com/prada-bag-list/">

④ URLはハイフン区切りで英語が使用されているか？
マークアップとは話が少し逸れてしまいますが、URL（ドメインより後ろ）も適当につけてはいけません。できるだけ意味を持たせてください。

「http://example.com/prada-bag-list/」のようにをハイフン区切りの英単語でつなげページの内容を簡潔にまとめた意味をもつようにしましょう。
この例ですと「prada-bag-list = プラダのバッグ一覧」と連想しやすいので検索エンジンが解釈しやすくなります。

同時に次の点も気をつけましょう。

# URLに日本語は使用しない。
URLに日本語を使用するとエンコードされてしまい、　　%E9%AC%BC%E6%BB%85%E3%81%AE%E5%88%83のようになります。これでは意味がわかりませんよね。さらにSNSでシェアされた時などもURLが長くて読みづらいのでURLは英語を使用しましょう。

# URLにアンダーバー（ _ ）は使用しない。
本来アンダーバーはURLに使用していけない文字です。そのためアンダーバーは使用せずにハイフン（-）を使用して下さい。

⑤ display: none;はできるだけ使用しない
これは単純に、どのデバイスでも表示しないのなら初めから書く必要ないよね？ならdisplay: noneじゃなくてHTML要素自体を削除してください。
ってことです。

ただし、レスポンシブなどのレイアウト保持のためや、クリックして表示を切り替えたりするような時はOKのようです。

と言われましても判断が難しいのでできるだけ使わないようにしたほうが無難です。

SEO対策は他にも気をつけることは多々ありますが、今回はコーダーからの立場でみたSEO対策に限定させていただきました。
（ちょっと逸れましたが・・・）

もしも、SEOについてもっと詳しく知りたいという方がいましたら下記のツイートをご参考ください。こちらの方は太っ腹にも網羅的なSEOチェックシートを無償で公開しております。

弊社がWeb制作をやってた時の「SEOチェックシート」が優秀だったので制作者さん向けにシェアします！

構造化データ周りはないですが、小規模サイトならこれで十分かと思います！

ちなみに作ったの僕じゃないですw
当時いたメンバーが作ってくれたんですが、まじ優秀だわ。https://t.co/HqPYVsfvo4
— 岩田真（ユーティル代表） (@Shin_Iwa_Utill) February 6, 2020

3-2. 読み込み速度を意識する

Webサイトの読み込み速度はとても重要です。
Googleもページの読み込み速度を検索ランキングの評価基準の一つとして、採用しています。

また、読込速度が遅いとユーザーの離脱率は高くなってしまい、コンバージョンにもつながりにくくなってしまうのでいいことありません。

そうならないためにも、読み込み速度を意識し、できるだけ読み込み速度が早くなるように「HTML、CSS、JSの圧縮」「画像のファイルサイズの軽量化」「画像ではなくCSSで再現できるところはCSSでやる」などの読み込み速度向上のための対策をしておく必要があります。

下記のようなツールを使うと読み込み速度を客観的に計測できますので、レイアウトに問題がないことを確認できたら、今度は読み込み速度を早くするためにブラッシュアップすることをお勧めします。

・Page Speed Insights
・lighthouse（Google Chrome アドオン）

lighthouseは、Page Speed Insightsの中でも使用されています。
こちらは読込速度だけでなく全体のSEO対策の結果を評価してくれますので一緒に

3-3. 301リダイレクト設定している

これはよくディレクターも見落としがちな気がします。
サイトを新規に作成する時には関係ありませんが、サイトリニューアル案件の時などに301リダイレクト設定は必要になってきます。

301リダイレクトとは？
301リダイレクトとはページを恒久的に転送するという意味で、主にページやサイトのリニューアルや引っ越し時に使用します。
この設定を行うことでページやサイトの評価を受け継ぐ事ができます。

特にコーダーとして仕事を始めたばかりだと、301リダイレクトのことまでまで気が回らない時もありますので、下手をすると「サイトをリニューアルしたら検索結果が以前より下がった・・・」などの、悲惨な結果になってしまうかもしれません。

そんな時は301リダイレクトが設定されておらず以前の評価を引き継げてない可能性が高いです。
一度、.htaccessなどで301リダイレクトがちゃんと設定されているか確認してみてください。

上記のようなトラブルを起こさないように「サイトの引越し・リニューアル時には301リダイレクトも設定する」ことを覚えておきましょう。

ここで便利なツールを一つご紹介します。
httpstatus：https://httpstatus.io/

このツールを使うと「リダイレクト処理がちゃんと301で行われているか？」「無駄に複数回リダイレクトしてないか？」など複数のページのステータスコードを一気にチェックできますのでかなり便利です。

SEO編については以上となります。
続いては画像などの # 4. Media編です。

# 4. Media編

今やデバイスや高解像度ディスプレイ（Retina）などシーンに応じて適切な画像を扱うことが当たり前です。

「1枚のものすごく大きい画像を使用すればどののデバイスでも、どの高解像度のディスプレイでもきれいに表示されるからオールOK！」なんて乱暴なやり方はやめましょう。
ファイル容量が大きすぎて読み込み速度が低下し、ユーザーのストレスになり得ます。

ここでもモバイルファーストの考え方を意識する。
スマートフォンユーザーは「移動中の電車の中」や「恋人を待っている間」など、いわゆるスキマ時間にもサイトを閲覧します。
そんな時でも近くに安定した高速Wi-Fiがあればストレスは感じませんが、
そう都合良くはいきませんよね。

なので、次のことを意識しておきましょう。

・画像によって最適な種類（.pngや.jpgなど）を使い分けてファイル容量を
　軽量化する
・デバイスやディスプレイ解像度に応じて適切なサイズの画像を切り替える
・SVG画像の特性を理解して使う

4-1. PNGやJPGの使い分け

テキストもきれいに見えるし透明部分もサポートしてるからといって、なんでもかんでもPNGにすれば問題ないというわけではありません。
PNGやJPGにはそれぞれ特性があります。この特性を理解して最適な画像の種類を選択しましょう。

PNG：透明部分をサポートしているが、ファイル容量が重くなりがち
JPG：透明部分をサポートしていないが、ファイル容量を調節できる

最初の頃は「透明部分があるならばPNG、透明部分がないならJPG」ぐらいの認識で問題ないと思います。

PNGとJPGのファイル容量の差は微々たるものかもしれませんが、Webサイトには複数の画像が使われることがほとんどですので、チリも積もればなんとやらです。

4-2. 様々なデバイスサイズに適した画像を切り替える

スマートフォンやタブレットなどデバイスのサイズに応じて画像を切り替えるにはsrcsetを使用します。

<picture>

 // 大きめのスマートフォン用 （ iPhone 6 Plusとか ）
 <source media="(min-width: 414px)" srcset="medium.jpg">

 // タブレット用
 <source media="(min-width: 768px)" srcset="large.jpg">

 // PC用
 <source media="(min-width: 1024px)" srcset="large-x.jpg">

 // デフォルトの画像 ( この場合は414px以下の時に適用される )
 <img src="small.jpg" alt="〇〇">
</picture>

モバイルファーストの考え方を意識すると、ここでも「スマートフォン（小）→タブレット（中）→PC（大）」の順で書いておくと頭が混乱せずに済みます。

4-3. 高解像度ディスプレイに対応した画像に切り替える

高解像度ディスプレイと通常のディスプレイで画像を切り替える方法です。
ここでもsrcsetを使いますが少し書き方が変わります。

<img
  src="example.jpg"
  srcset="example.jpg 1x, example@2x.jpg 2x"
  alt="〇〇"
>

先ほどと違ってシンプルになりました。
「srcset="example.jpg 1x, example@2x.jpg 2x"」の部分が高解像度ディスプレイと通常のディスプレイの画像を切り替える部分になります。
1x, 2xと記載がありますがこれは下記の意味を持っています。

1x : 通常のディスプレイ（解像度 1倍）の時に読み込まれる
2x : 高解像度ディスプレイ（解像度 2倍）の時に読み込まれる

2行目の「src="example.jpg"」はsrcsetに対応していないブラウザ用です。
画像ファイル名は管理しやすいように解像度に合わせて「@2x、@3x」などを末尾に追加しておきます。

4-4. SVG画像の特性を理解して使える

画像にはビットマップ画像とベクター画像があります。
PNGやJPGはビットマップ画像で、SVGはベクター画像となります。

ビットマップ画像（.png、.jpg、.gif）
・ピクセルデータで表される。点描画のようなもの。写真向き。

ベクター画像（.svg）
・点と線を数式で表し描画する。ロゴなどイラストに向いている。
・表示サイズをHTMLやCSSで指定できる。
・解像度に依存せず、高解像度のディスプレイでもきれいに表示される

ロゴやイラストにはSVG画像を使用し、風景や人物写真はPNGかJPGを使用する。などと、画像の種類（写真かイラスト）に合わせて使い分けることが大切です。

さらにマークアップも少しシンプルになる上に、画像ファイルも減るので管理しやすいメリットもあります。

ぜひとも「PNG、JPG、SVG」これらを使い分けていきましょう。

# 5. Framework編

5-1. Bootstrapなどのフレームワークを使用せずに0から作成できる

これは個人的に強く言いたい。

Progateなどの入門者向けの学習サイトではBootstrapなどのフレームワークがよく教材として使用されてるので、Bootstrapは様々な現場で使われてるイメージがありますが、それは違います。

どの現場でもフレームワークは必ず使われているわけではない！とゆうことを覚えておきましょう。

フレームワークとは？
簡潔にゆうと、よく使う機能などをまとめて簡単に使えるようにしたもの総称をフレームワークといいます。CSSのフレームワークではBootstrapが有名ですが、他にも「Foundation」や「Tailwind CSS」などがあります。

管理システムなどのコーディングや納期が極端に短いとかであれば別ですが、基本的に一般的なWebサイトのコーディングに関してはBootstrapに限らずフレームワーク自体使わないことの方が多いと思います。
（僕はフレームワーク使う現場に会ったことありません）

そんな時は、HTMLもCSSもJSも自分で全て書く必要があります。
普段からフレームワークに頼ってばかりだと基礎がおろそかになってしまい0から自分で構築するスキルが身に付かない恐れがあります。

なので、最初はフレームワークを使用せず学習することをオススメします。
その方が基礎力もあがりますし、言語への理解も深まります。
理解が深くなっていけば、様々な要望や自体に対応できる強いコーダーになれます。

# Bootstrapの機能にないことはできません。
なんてことを言っちゃう人は、正直、戦力としてカウントしづらいと思います。

もちろん、僕も職業訓練学校で0から学びましたからできるようになるまで大変なことは重々承知です。

ですが、努力は嘘をつきません。大変な思いをした分だけ必ず自分を成長させてくれます。しんどくてもふんばって頑張りましょう。

ここまでお読みいただきありがとうございます。
これより先ははおまけとメッセージです。
読み飛ばしていただいてもかまいません。

#6. おまけ

おまけです。
HTMLやCSSなどのリソースの管理はどうされてますか？
ローカルに日付ごとにフォルダ作って手動で分けてたりしませんか？

# 今すぐそれはやめてGitを使いましょう。

今やGitはスタンダートなリソース管理ツールです。
Gitを使うことで複数人での分業や編集した箇所を確認がすぐできます。

Gitの操作は主にコマンド入力で操作する方法と、アプリの「Source Tree」で操作する方法の2種類があります。

「Source Tree」を使えば入門ハードルはそれほど高くありません。
ご自身の学習記録をGitを使って管理してみるのをオススメします。

何よりGitのリソースを管理する仕組み（ブランチやマージなど）は、人から説明を受けてもなかなか頭に入ってきづらいので普段から慣れておいた方がいいです。
まずは、Gitの理解はおいといて使えることを優先しておきましょう。

#7. 最後に。

気がつけば、20,000字を超える長文になってしまいましたが最後までお読みいただけたら嬉しいです。中には辛辣な物言いになっている箇所もありましたが、誰もが当たり障りのない優しいことばかりを言っているのはその人のためにならずと思い、できるだけ正直な思いを書かせていただきました。

本文を読んで想像と違うので挫折しそう、諦めそうなどと思った人にも頑張って欲しいと思っています。
先ほども言いましたが、「努力は嘘をつきません。大変な思いをした分だけ必ず自分を成長させてくれます」ですので諦めず学習しつづけましょう。

いい記事だと思ったらスキとかツイートとかしてくれると嬉しいです。

見ていただきありがとうございます。フリーランスのWeb屋、CoCominaと言います。日本や海外を行ったり来たりしています（今は京都にいます）漫画が大好きです。お仕事のご依頼などはhttps://cocomina.comまでメッセージをください。