こんにちは、NRIネットコム新入社員・ツーシーム投げ代表の池部です。
高校時代から夢中になっていた微生物研究からWebへ転身し、現在はHTML/CSSのコーディングで奮闘中！
今日も元気に社会人という名のマウンドに立っています。
さて、コーディングをするにあたり、
- デザイン通りの見た目にならない
- 意図していない部分にスタイルが当たる
など、もやもやした経験はありませんか？
特に、私と同じように未経験でIT業界に飛び込んだ方は、このような壁にぶち当たることも多いのではないでしょうか？
本記事では、未経験から学んだリアルな失敗例をもとに、同じミスを避けるための具体的な対策とチェックリストをお届けします。
HTML
① HTMLのタグの役割を理解せず適切なタグを選べなかった話
突然ですが、下図のようなデザインのコーディングに取りかかる際、みなさんは何タグでマークアップしますか？
〈例〉タイトル、従業員の画像、名前や部署、電話番号のリストが記載されているデザイン
私は、このデザインを見たとき、「Name・department・TEL」 が同じ見た目で並んでいたため「同列の項目（箇条書き）」と判断し、全体を<ul>、各Staffの情報を<li>でまとめてしまいました。
しかし、実際には「Staff名（見出し）」に対する説明（「人物イラスト」と「Name・department・TEL」）が続く構造なので、情報の意味関係を正しく示すために、<dl>（<dt>/<dl>）を使う方が適切でした。
結果として、アクセシビリティ対応などで手戻りが発生しました。
原因
「各要素が同じ形で並んでいるから
<li>でいいか…！」と見た目重視でタグを選んでしまった。
見た目は正解。でも実際には、定義＋説明を表すリスト<dl>を用いたほうが適切だった。
〈<dl>/<dt>/<dd>、<ul>/<ol>/<li>の使い分け〉<dl>/<dt>/<dd>は「用語と説明」のセット（辞書・仕様書向き）<dl>：定義リスト<dt>：定義する言葉<dd>：定義の説明
<ul>/<ol>/<li>は「項目の列挙」（箇条書きが<ul>/・手順書向きが<ol>）<ul>：順序なしの箇条書き<ot>：順序ありの箇条書き<li>：リストの各項目(<ul>/<ot>のいずれかがないと使えない)
学び
まずコンテンツの意味を考える：「これは単なるリスト？用語と説明の組？それとも独立したセクション？」と自分に問いかける。
コンテンツの意味や役割を明確に示すHTMLタグを優先して使う。：1. で考えた内容に最も近いタグを選んで使う。
② タグの数が合わずレイアウトが崩れた話
HTMLは、テキストや段落、画像、リンクなどを「タグ」で囲んで構造を作るマークアップ言語です。
各タグは要素の始まりを示す「開始タグ」と終わりを示す「終了タグ」でペアになっています。
divの開始タグ(<div>)と終了タグ(</div>)の数が一致していないことでページ全体のレイアウトが崩れ、原因特定に時間がかかったことがありました。
原因
新しくdiv要素を追加する際、
<div>のみ書いて、</div>を書くことを忘れていた。余分なdivの削除をしようとした際、
<div>は消したが</div>を消し忘れていた。
学び
Google Chromeの拡張機能「HTMLエラーチェッカー」で、HTMLの開始・終了タグの過不足を見つけ、修正する。
→「「HTMLエラーチェッカー」は、拡張のアイコンをワンクリックするだけでHTMLを自動チェックしてくれるツールです。ブラウザは文法ミスをそのまま表示しがちなので、見た目では気づきにくいエラーやアクセシビリティ問題をサッと見つけて直せるのが便利で、結果的に作業が楽になります。VSCodeの拡張機能「Auto Close Tag」を使用することで、HTMLの閉じタグを自動的に補完する。
→開始タグの">"までを記載すると、自動的に終了タグが記載される仕組みです。ミスやコーディング時間の短縮にもなるので、ぜひダウンロードして使ってみてください！
CSS
① CSS命名の落とし穴…！？略語と汎用語が生む副作用
CSSは、HTMLで作った文書に「見た目」を与える言語です。色やフォント、余白、配置（レイアウト）を決めたり、画面サイズに応じて見た目を切り替えたり（レスポンシブ対応）できます。
簡単に言えば、HTMLが「何があるか（構造）」を表すのに対して、CSSは「どう見えるか（見た目）」を担当します。
その基本機能の一つがクラスセレクタです。クラスはHTML要素に付けるラベルで、同じクラス名を複数の要素につければ、まとめて同じスタイルを適用できます。これにより、デザインの再利用や統一が簡単になります。ただ、実務で気づいたのは「クラス名の付け方」が後の作業に大きく影響するという点です。
私は、自分でクラス名をつけるときに「list」や「menu」、「desc」のような曖昧な英単語を使ってしまい、レビュー時に「時間が経ってから何のためのクラスかが分かりづらくなるため、クラス名を変更してほしい」と指摘を受けたことがありました。
原因
どの場面でも使えそうな一般的な単語をそのままクラス名にしてしまっていた。そのため、後で「これは何のためのクラスなのか」が分かりにくくなってしまった。
〈例〉「list」は、項目の羅列という構造を示す語で、商品一覧や箇条書き、履歴など幅広い用途に使われるため、何のリストか不明瞭になりがち。
「menu」は、操作選択やナビゲーションを想起させる語で、機能的な意味合い（操作するための項目群）を持つため、表示目的や役割が違う要素に同じクラス名を使うと混乱を招く。
「desc」は、自分的には「description」の略の意味合いで使用したが、「降順」の意味で使われることが多いため、内容と結びつきづらい。
どこまでを1つのコンポーネント（部品）として扱うか決めていないと、どの要素にクラスを付けるべきか迷ってしまう。結果的に同じデザインのパーツに違う名前を付けたり、1つのクラスがあちこちで使われて意図しないスタイルが適用される原因になる。
学び
クラス名は、BEM命名規則に従って命名する。
要素を一つに特定できる英単語を選び、複数の意味を持つ単語は避ける。
② CSSの記述は合っているのに反映されない
原因
クラス名やタグ名にタイプミスがあったため、該当の要素に当たらなかった。
別のルールが優先されていて、自分の書いたスタイルが上書きされてしまっていた。
親要素のスタイルが子要素に影響していて、思った通りのスタイルにならなかった。
学び
下記の手順でCSSの記述を確認する。
ブラウザの DevTools を開いて、該当の要素をクリックして選択する。
「Styles（スタイル）」パネルを見て、自分が書いたルールが一覧にあるか確認する。
もし別のルールに取り消されている（打ち消されて線が引かれている）なら、そのルールのセレクタが優先されている可能性がある。セレクタ名や優先度（より具体的なセレクタ／!important の有無）をチェック。
セレクタ自体が存在しない（リストにない）場合は、HTML のクラス名やスペルが合っているかを確認する。
親要素の影響かもしれないと感じたら、親要素のスタイルも同じパネルで確認して、どこが効いているかをたどる。
チェックリスト
これまでの経験と学びをもとに、私は自分専用のチェックリストを作ってコーディングに取り組むようにしています。
よかったら参考にしてください！
- HTML
□ セマンティクス確認：要素は意味に合ったタグか？この要素の意味は何か説明できるか？
□ リポジトリ(プログラムやファイルをまとめて保存・管理する場所)に似た実装があるか検索したか？
□ 見た目よりも意味重視でタグを選んだか？
□ SEOフレンドリーな見出し構造：<h1>はページに1つ、見出しの階層が論理的か？
□ 不要なラッパーを排除：過剰な<div>タグや余計な親要素がないか？
□ HTMLバリデーション等で文法エラーがないか？
- CSS
□ 命名規則遵守：クラス名・変数がプロジェクト規約（BEM等）に従っているか？
□ クラス名の意味合い確認：曖昧な英単語を使っていないか（複数意味を避ける）
□ レスポンシブ確認：ブレイクポイント(レイアウトを切り替える画面幅の境目)で崩れがないか？
□ CSSの競合確認：意図したCSSとは別のCSSが適用されていないか？
□ 余白が重複した際、大きい値のみが適用される仕様（＝margin collapse）に注意
□ 余白のプロパティ（gap と margin） の使い分け：flex/grid 内では gapを優先し、それ以外ではmarginを使用するなど、方針に沿っているか？
□ スタイルの重複：同じCSSのスタイルを、異なるクラス名で重複して定義していないか？
終わりに
実務を通して分かったのは、HTML/CSSの奥深さは単なる見た目づくりにとどまらず、文書の構造や意味を整え、アクセシビリティや再利用性まで考えた「設計」にこそあるということです。
まずは見た目を作れるようになることを目標にして問題ありませんが、早いうちにセマンティクスや命名ルール、再利用性・保守性を意識する習慣を身につけると、チーム開発がずっとラクになり、レビューや手戻りも激減します。
小さなルールを自分で決めて守るだけで、品質は安定し、自信を持ってコードを出せるようになります。
まずは「意味を優先する実装」を習慣にしてみましょう！
