社内フロントエンド勉強会で「HTML解体新書」輪読会をしてみた

はじめに

こんにちは！
KINTO開発部 KINTOシステム開発G マスターメンテナンスツール開発チーム、技術広報部兼務、Osaka Tech Lab 所属の high-g（@high_g_engineer）です。フロントエンドエンジニアをやっています。

以前、社内で開催しているフロントエンド勉強会について紹介しました。

https://blog.kinto-technologies.com/posts/2025-06-30-frontend-study-group/

あれから勉強会は続き、2026年10月で第91回を迎えました。
今回はその中で、2026年8月〜9月に全5回で実施した 『HTML解体新書』の輪読会 について紹介します。

正直なところ、書籍の輪読会はフロントエンド勉強会では前例がなく、とりわけ、分厚い技術書の輪読会となると、「途中で失速しがち」「ただ読み上げるだけの会になりがち」という印象があり、少しハードルを高く感じていました。
実際、私自身も前職で同じ本の輪読会を経験したとき、内容を理解しないまま読み進めるだけの会になってしまった苦い思い出があります。
ですが、今回は最後まで走り切れたうえに、参加者全員が前のめりに議論する場になりました。
この記事では、その経緯と進め方、うまくいった理由などをまとめます。

題材にした書籍

https://www.borndigital.co.jp/book/25999/

『HTML解体新書 ―仕様から紐解く本格入門』は、HTMLの仕様（HTML Standard）をベースに、各要素の意味や使い方、アクセシビリティとの関係を丁寧に解説した書籍です。

なぜHTMLの輪読会をすることになったのか

「次に何をやるか」をみんなで話し合った

輪読会を始める直前、勉強会ではTSKaigi 2026のセッション動画をみんなで視聴していました。ただ、最近のフロントエンド勉強会はTypeScriptの型の話に寄りがちな内容になっていて、動画を見るだけの会が続いていたこともあり、「もう少し現場に寄り添った勉強会にしたい」と考えていました。

そこで7月に2回ほど時間を取り、参加者が所属する各チームで実際に起きているフロントエンドの課題をヒアリングしました。
すると、チームは違っても次のような悩みが共通して挙がりました。

• デザイナーとの協業の進め方に課題がある
• UI / UXに関する知識をもっと伸ばしたい
• アクセシビリティを最終的にコードへどう落とし込むか、どう周囲を巻き込むか

キーワードは「情報設計」

議論を重ねるうちに見えてきたのが、「情報設計」というキーワードでした。
勉強会で立てた仮説はこうです。

正しく情報設計されているUI ≒ 正しくマークアップされている ≒ Webアクセシビリティを満たしている

デザイナーと協業するうえでも、アクセシビリティを満たしたコンテンツを作るうえでも、土台になるのはHTMLの正しい理解です。
「HTMLの知識を強化することが、情報設計の理解につながり、ひいてはフロントエンドの全チームに共通する課題の解決につながるかもしれない」と考え、まずは h1〜h6 を正しい順序で使うという基礎的なレベルから理解し直そう、という結論になりました。その教材としてうってつけだったのが『HTML解体新書』です。

いきなり始めず「本を紹介する会」を挟んだ

とはいえ、この本は全352ページというなかなかの厚さです。いきなり「来週から輪読会をやります」と言うと、参加のハードルが一気に上がってしまいます。
一方で「みんなの準備が整ったらやろう」では、いつまでも始まらない可能性が高いです。

そこで、まずは すでに本を持っている人に持参してもらい、どんな本なのかを紹介する会 を一度挟みました。
この会で中身をパラパラと眺めたことで「とりあえず買って一読してみます」「今Kindleで買いました」という声が出て、その場で進め方のルールも決めることができました。

また、マネージャーの承認をもらい、東京（室町）と大阪のオフィスに1冊ずつ会社で書籍を購入できました。
ただ、ふたを開けてみると多くの参加者が自分で購入していて、「会社で買わなくても、みんな持っていたかもしれない」というくらいでした。

輪読会の進め方

ルール

ルールはシンプルにしました。

• 参加者はできる限り事前に読んでくる（もちろん、読めなくても大丈夫）
• 説明担当は担当箇所を事前に精読し、当日に説明する（説明方法はおまかせ）
• 書籍は会社購入分を貸し出し可（個人での用意もOK）

「読めなくても大丈夫」と明言しておくことで、担当以外の人も気軽に参加できるようにしています。

1回（約1時間）のタイムテーブル

次回の担当は、Claude Artifactsで作ったルーレットで決めました。ちょっとしたゲーム感覚があり、「誰になるかな」と盛り上がるポイントでもありました。

範囲は「主要な節だけ」に絞った

全章を読むと長期戦になってしまうため、CHAPTER 3の要素解説から、特に業務に関わりが深い5つの節に絞りました。

お盆や私の休暇で何度かスキップを挟みましたが、当初の見込みどおり5回で完走できました。

アクセシビリティの有識者が参加してくれた

今回の輪読会で大きかったのが、社内のアクセシビリティの有識者である辻さん、守谷さんが参加してくれたことです。
本に書かれている内容に対して「実際のスクリーンリーダーではこう読み上げられる」「昔はこう使われていた」といった、本の一歩先の知見 をその場で補足してもらえたことで、議論の質が大きく上がりました。

各回の様子

各回とも、担当者が本の内容をなぞるだけでなく、独自の切り口でテキストベースのまとめを作ってきてくれました。ここでは各回で印象に残ったトピックをいくつか紹介します。

第1回：セクション

section / article / aside / nav といったセクショニングコンテンツや、header / footer がランドマークになる条件などを扱いました。

印象的だったのは、書籍の刊行と同じ2022年に アウトラインアルゴリズムがHTML Standardから削除されている ことです。

https://github.com/whatwg/html/pull/7829

現在は、section で囲んでも見出しレベルは上がらず、h1〜h6 の数字で決まります。
また、「Reactアプリケーションでは、最終的にレンダリングされたHTML全体を目にする機会がほとんどありません。セクション構造が正しいことを日々の開発でどう検証すればよいか？」という、コンポーネント開発ならではの悩みも話題になりました。

第2回：グルーピングコンテンツ

p、ul、ol、dl、figure、main など「毎日書いている要素」がテーマでしたが、担当の三上さんは意味の深い説明よりも、個人的に「そうなんだ」と感じた部分を中心にまとめてくれました。

たとえば、p の中に ul を書くとエラーにはならず、パーサーが黙って p を閉じてしまいます。

<!-- 書いたつもりのHTML -->
<p>
  <ul>
    <li>項目</li>
  </ul>
</p>

<!-- パース後のDOM -->
<p></p>
<ul>
  <li>項目</li>
</ul>
<p></p>

その結果、p > ul を前提にしたCSSが効かなくなったり、末尾に生える空の p で余白が増えたりします。SSR環境ではサーバーで生成したHTMLとクライアントのDOMが食い違い、hydrationエラーの原因にもなります。

ほかにも、次のような話題で盛り上がりました。

• ol の番号はDOMに存在しないため、コピー＆ペーストすると消える
• main は hidden 属性を付けたものを含めれば、1ページに複数置ける
• hr は「線」ではなく、段落レベルのテーマの区切り。スクリーンリーダーでは「区切り」と読み上げられる
• dl の読み上げはブラウザとスクリーンリーダーの組み合わせによって差があるが、セマンティクスとして正しいなら使う価値がある

この回で特に印象に残ったのが、「セマンティクス＝スクリーンリーダーのため」というチャットの発言に対する、辻さんのひと言です。

「スクリーンリーダーのため」ってのはたぶんちょっと違うな。スクリーンリーダーはHTMLの仕様に合わせて解釈する側なので。

スクリーンリーダーで思いどおりに読ませるためにコンテンツを曲げるのではなく、仕様に沿って正しくマークアップし、スクリーンリーダー側がそれを正しく解釈する。アクセシビリティを考えるうえでの順序を、改めて確認できました。

第3回：テキストレベルセマンティクス

em と strong、small、s、time、ruby、bdi、br、wbr などを扱いました。
担当の齋藤さんからは「普段はフレームワーク上でコンポーネント単位でしかHTMLを書かないので、要素そのものを意識したことがなかった」という率直な感想があり、まさにこの輪読会の狙いどおりの気づきが共有されました。

書籍の刊行後に仕様側で変わった点も話題になりました。たとえば、書籍の時点では対応するARIAロールがなかった要素にも、WAI-ARIA 1.2ではロールが割り当てられています。

ほかにも、<p>H<sub>2</sub>O</p> をVoiceOverで読ませると「エイチ・ツー・オー」ではなく「エイチニオー」と読まれた、日本語にはイタリック体の文化がないので i 要素はマークアップと見た目が一致しにくい、といった実際に試してみたからこその話も出ました。

チャットでは、昔使っていたHTMLエディタの話や、ガラケーでHTMLを書いていた思い出話で世代を超えて盛り上がる一幕もありました。

第4回：フォーム その1

私の担当回です。form、label、各種 input の type、バリデーション属性、autocomplete などを扱いました。

特に強調したのは、label の for 属性の落とし穴です。存在しない id を指定するとHTMLチェッカーでエラーとして検出できますが、別の要素の id を指定してしまった場合はHTMLチェッカーでは検出できません。 ラベルをコピー＆ペーストして for を直し忘れると、コピーしたラベルまで最初の入力欄に紐づいてしまう、といった事故が起こり得ます。
これは目で見ても気づきにくい一方、スクリーンリーダーで読み上げるとすぐに分かる、という話が辻さんからありました。

そのほかにも、次のような話題が出ました。

• type="hidden" は「秘密」にはならない（値は改ざんできる）
• pattern 属性はセキュリティのためのものではない
• placeholder はラベルの代わりにならない
• 電話番号を「ハイフンなし」と注釈して type="number" で受け取るのは避けたい

KINTOのサービスには申込フォームが多いので、そのまま業務に生かせる内容だったと思います。

第5回：フォーム その2

最終回は溝口さんの担当で、button、select、datalist、progress / meter、fieldset / legend などを扱いました。

溝口さんの切り口がとても面白く、「今はゼロからフォーム部品を手書きすることは少なく、UIライブラリを使うことがほとんど」という前提に立って、MUI・Ant Design・Radix UIがそれぞれの要素をどう実装しているか を、書籍の内容と突き合わせてくれました。

たとえばスイッチ（Switch）コンポーネントひとつとっても、実装方針はライブラリごとに異なります。

select も同様で、ネイティブの select を使わずに role="combobox" と role="listbox" を組み合わせて再現していたり、フォーム互換のために見えない select を置いていたりと、各ライブラリの工夫が見えてきました。
「アクセシブルな複数選択UIを自前で実装するのはかなり大変なので、ライブラリを使うのがおすすめ」という結論にも説得力がありました。

また、スイッチは「押した瞬間に反映されるもの」なので、「保存」ボタンと組み合わせたり、月額／年額のような二択に使ったりするのは本来の用途とずれる、というSwitchとトグルボタンの使い分けの話も盛り上がりました。

ふりかえり

全5回を終えたあと、勉強会の1回分を使ってふりかえりを行いました。
フレームワークには、KPTではなく Fun / Done / Learn を採用しています。KPTだと特に問題がなくてもProblemを挙げる必要があり、ネガティブな空気になりやすいと考えたためです。

Fun：楽しかったこと

• 輪読会は負荷の高いフォーマットなのに、担当者が理解したことを積極的にシェアしてくれた
• ただ読んでくるだけでなく、担当者が独自の解釈を織り交ぜて、より高度な内容に仕上げてくれた（UIライブラリの対応状況など）
• 発表者ごとに本のどこに着目しているかが資料に表れていて、他の人がどう技術書を読んでいるのかを知ることができた
• 有識者のアクセシビリティの知見を踏まえて本を読み進める体験ができた
• 発表後のディスカッションで、全員が前のめりに建設的な意見を出す場になった

辻さんからは、こんなコメントももらいました。

昔のWeb制作者は、HTML解体新書に書いてあるくらいのことは普段使いしていた。今の時代は、そうした知識がなくてもプロダクトが作れてしまう。だからこそ、この輪読会を通してみなさんが知ろうとしてくれていることがうれしかった。

さらに、「世の中の登壇には、画面を見ていないと置いていかれるものが意外と多いけれど、今回のみなさんの発表は、画面を見ていなくても話として理解できた」という、うれしい言葉もいただきました。辻さんがこの点について書いた記事も紹介されていたので、発表をする方にはぜひ読んでほしいです。

https://note.com/debugon/n/nae7f164bf8a7

Done：やり遂げたこと

• フロントエンド勉強会で書籍を輪読するスタイルは初めてだったが、無事に完走できた
• 社内に『HTML解体新書』の存在を広められた
• 複数回にわたって1冊の技術書を読む、というスタイルを勉強会として1つ確立できた

一人で読むのがつらい本でも、勉強会に持ち込んでみんなで読む、という選択肢ができたのは大きな収穫です。

Learn：学んだこと

• HTMLの現行仕様は常に更新され続けるHTML Standardなので、書籍の内容はすでに古くなっている部分もある。だからこそ 書籍は取っかかりとして使い、怪しいと思ったら仕様を引く
• セクショニングコンテンツ、グルーピングコンテンツ、テキストレベルセマンティクスといったHTMLの原点を改めて思い出せた
• a 要素の内容モデルはTransparent（透過的）で、親がフローコンテンツなら a の中に div などを置くこともできる
• セマンティックなHTMLを書けばアクセシビリティを網羅できるわけではない。 結局、見出しやラベルを適切に付けることが、アクセシビリティ的に一番重要
• 見た目に頼っていたマークアップを、要素の意味から考え直すきっかけになった
• 担当になった人は誰も発表を避けず、1週間で1時間分の議論ができる資料を作ってきてくれた。1回あたりの適切なボリューム感 もつかめた

うまくいった理由をふりかえってみる

ふりかえりの内容も踏まえて、今回の輪読会がうまくいった理由を整理すると、次の4つだと思います。

1. 現場の課題から題材を選んだ
   「なんとなく良さそうな本」ではなく、各チームへのヒアリングで見えた共通課題（情報設計・アクセシビリティ）から逆算して本を選びました。そのため、参加者にとって「自分ごと」になりやすかったのだと思います。
2. 始めるハードルを徹底的に下げた
   紹介する会を挟む、「読めなくても大丈夫」と明言する、範囲を主要な節に絞る、書籍を会社で用意する、といった工夫で、参加の心理的なハードルを下げました。
3. 説明方法を担当者に任せた
   本の内容をなぞるのではなく、「そうなんだ」と感じた点に絞る、UIライブラリと突き合わせる、など担当者ごとの切り口が生まれ、毎回違った面白さがありました。
4. 有識者が一緒に読んでくれた
   書籍の内容を、現在の仕様や実際のスクリーンリーダーの挙動と照らし合わせて補足してもらえたことで、「読むだけの会」から「理解して議論する会」になりました。

おわりに

今回の輪読会を通して、HTMLの知識そのものはもちろん、「勉強会で1冊の本を読み切る」という新しい型を手に入れることができました。

ふりかえりでは、次の題材としてReactの公式ドキュメントのような無料で読めるリファレンスを読むのも良さそう、という声や、書籍の内容を起点に、現在のHTMLの仕様やAI時代のマークアップについてさらに議論を深める場をつくれないか、というアイデアも出ています。

少人数のふりかえりではありましたが、この輪読会を乗り越えたことで、新しいことができそうな可能性を感じています。
社内で輪読会を企画しようとしている方の参考になればうれしいです。