Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
HTMLの品質ってなんだっけ? “HTMLクライテリア”の設計と実践
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
una
September 06, 2025
Programming
4.4k
5
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
HTMLの品質ってなんだっけ? “HTMLクライテリア”の設計と実践
2025/09/06 フロントエンドカンファレンス北海道2025の登壇資料です
una
September 06, 2025
More Decks by una
See All by una
入社したばかりでもできる、 アクセシビリティ改善の第一歩
unachang113
3
550
リッチエディターを安全に開発・運用するために
unachang113
1
540
Other Decks in Programming
See All in Programming
PHPだって関数型したい 〜できること、できないこと〜 / fp-in-php
jsoizo
0
230
【やさしく解説 設計編・中級 #4】ルールの寿命と、システムの年輪
panda728
PRO
2
150
PHP Application における Kubernetes 内 gRPC 通信
ganchiku
0
500
継続モナドとリアクティブプログラミング
yukikurage
3
610
ローカルLLMでどこまでコードが書けるか -縮小版 / How much code can be written on a local LLM Shortened
kishida
2
190
共通化で考えるべきは、実装より公開する型だった
codeegg
0
250
フィードバックで育てるAI開発
kotaminato
1
120
コーディングルールの鮮度を保ちたい for SRE NEXT 2026 / keep-fresh-go-internal-conventions-sre-next-2026
handlename
0
140
5分で問診!Composer セキュリティ健康診断
codmoninc
0
380
AI駆動開発を妨げる技術的負債の解消アプローチ / ai-refactoring-approach
minodriven
17
9.1k
信頼性について考えてみる(SRE NEXT 2026 miniLT)
hayama17
0
200
PHP に部分適用が来るぞ!……ところで何それ?おいしいの? #phpcon / phpcon-2026
shogogg
0
270
Featured
See All Featured
Dominate Local Search Results - an insider guide to GBP, reviews, and Local SEO
greggifford
PRO
0
210
VelocityConf: Rendering Performance Case Studies
addyosmani
333
25k
Leveraging LLMs for student feedback in introductory data science courses - posit::conf(2025)
minecr
1
320
WCS-LA-2024
lcolladotor
0
720
Statistics for Hackers
jakevdp
799
230k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
Learning to Love Humans: Emotional Interface Design
aarron
275
41k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.8k
GraphQLとの向き合い方2022年版
quramy
50
15k
GraphQLの誤解/rethinking-graphql
sonatard
75
12k
Git: the NoSQL Database
bkeepers
PRO
432
67k
Embracing the Ebb and Flow
colly
88
5.1k
Transcript
HTMLの品質ってなんだっけ? “HTMLクライテリア”の設計と実践 フロントエンドカンファレンス北海道2025 うな(@unachang113)
株式会社LayerX バクラク事業部 CREグループ X:@unachang113 しろたんと野球観戦が好きです うな(夛田 小百合/Tada Sayuri) 自己紹介 自己紹介
前職PR TIMESで行った活動の 内容を話します 快諾してくださった前職、現職の方々、 本当にありがとうございます...! 発表について
目次 01. 01. 02. 02. 03. 03. 04. 04. HTMLクライテリア作成の
きっかけ HTMLクライテリア設計の 進め方 結果を元に行った活動 活動の効果 05. 05. まとめ
01. 01. HTMLクライテリア作成のきっかけ HTMLの品質に対するエンジニア間の共通の指標がなかったの で、何を満たせば品質を担保していると言えるのかの指標がな かった HTMLの品質について考えるきっかけや継続的に改善点を探す ためにクライテリアを作りたいと思った
01. 01. HTMLクライテリア作成のきっかけ HTMLの品質に対するエンジニア間の共通の指標がなかったの で、何を満たせば品質を担保していると言えるのかの指標がな かった HTMLの品質について考えるきっかけや継続的に改善点を探す ためにクライテリアを作りたいと思った → これは建前
本音 アクセシビリティ対応のための 土台を作りたい!!!! 01. 01. HTMLクライテリア作成のきっかけ アクセシビリティ対応を行うことにより、様々な環境のユーザ ーを誰一人取り残すことなく情報の発信、閲覧ができるように したい 対応を進めるにはHTMLをセマンティックにすることが不可
欠!!!!!!!まずはその土台を整えたい!!!
HTMLの品質を担保するための基準を作成する 1 品質の基準を達成するためのカテゴリを策定する 2 各カテゴリを満たすための判断基準を策定する 3 アセスメントシートの作成する 4 クライテリアのチェックを実施する 5
02. 02. HTMLクライテリア設計の進め方
クライテリアって何? 判断や評価を行う際の基準や尺度のこと フロントエンドだと日本CTO協会が提供している Webフロントエンド版DX Criteriaが有名 https://dxcriteria.cto-a.org/frontend PR TIMESではWebフロントエンド版DX Criteriaを元に HTMLの品質をチェックするためのツールとして
HTMLクライテリアを作成した
対象に本来備わっている特性の集まりが、 要求事項を満たす程度 ISO 9000:2015 / JIS Q 9000:2015 品質って何?
対象に本来備わっている特性の集まりが、 要求事項を満たす程度 ISO 9000:2015 / JIS Q 9000:2015 品質って何? →そのモノが持っている特徴・機能が、
期待や基準とどれくらい合っているか
対象に本来備わっている特性の集まりが、 要求事項を満たす程度 ISO 9000:2015 / JIS Q 9000:2015 品質って何?
→ 品質は国際標準で定義されている! 対象に本来備わっている特性の集まりが、 要求事項を満たす程度 品質って何? ISO 9000:2015 / JIS Q
9000:2015
ソフトウェアの品質に対する定義もある ソフトウェアの品質には8つの特性がある 1 2 3 4 5 6 機能適合性 性能効率性
互換性 信頼性 使用性 セキュリティ 7 保守性 8 移植性 品質って何?
ソフトウェア品質の8つの特性にHTMLの品質を 担保するための要素をあてはめて定義していく 1 機能適合性 ユーザーが操作を行う際に迷わないように適切なHTML要素 を使用していること 2 性能効率性 パフォーマンスを意識したHTMLが書けていること 3
互換性 さまざまなデバイスからアクセスした際に 同じ機能が提供できること 1. HTMLの品質を担保するための基準を作成する
4 使用性 ユーザーが操作を行う際に迷わないマークアップに なっていること 5 信頼性 動作を保証しているブラウザで表示崩れが起きないこと 6 セキュリティ HTML要素を適切に設定していないことによる
セキュリティインシデントがないこと 7 保守性 表示の不具合が生じた場合に原因箇所が 容易に特定できること 8 移植性 他のプロジェクトをまたいで共通の HTMLコンポーネントが利用できること 1. HTMLの品質を担保するための基準を作成する
HTMLの品質を担保するための基準を元に 大カテゴリと小カテゴリを策定 2. 品質の基準を達成するためのカテゴリを策定する → 突然の迷走 HTMLだけだとフォーカスが狭すぎない・・・? CSSも品質の定義上必要だよね・・・? React使ってるしReactの話も書く・・・?
軌道修正 アドバイザーの1000chさんと壁打ちした セマンティックなHTMLが大目標であることを再確認 コーディングルールではなく、クライテリアとして実装時の試 行錯誤を促したい 2. 品質の基準を達成するためのカテゴリを策定する
2つの大カテゴリと3つの小カテゴリを策定 ユーザー体験を支える品質 UIコンポーネント アクセシビリティ ライブラリの選定 成長できるチーム HTMLの仕様理解 セマンティックスなHTMLを書くことの意義の理解 より良い仕様に落とす努力 2.
品質の基準を達成するためのカテゴリを策定する
Webフロントエンド版DX Criteriaを参考に 判断基準を策定 3. 各カテゴリを満たすための判断基準を策定する メトリクスの計測 指標を定量的に計測/管理しているか 学習と改善 組織内での学習を健全に回すための サイクルが存在しているか
プラクティス よい慣習や実践方法が文化レベルで 浸透できているか アンチパターン 逆指標として、よくない慣習が行われ ていないか
例: UIコンポーネント メトリクスの計測 Markuplint等のリンターでUIコンポーネントのマークアップが問題ないかの点検を日常的 (日ごと〜週ごと)に実施している 学習と改善 UIのマークアップに関する議論をチーム内で行い逐次共有している プラクティス 開発プロセスの中でHTMLの利用やアウトラインが妥当かをレビューの際に判断している アンチパターン
同じ様な用途のUIをいくつも作成してしまう。 (共通化されていない) HTMLの意味付けが正しくないコンポーネントが汎用的に利用されている 3. 各カテゴリを満たすための判断基準を策定する その他の判断基準はこちら → https://developers.prtimes.jp/2025/02/05/prtimes_html_criteria/
4. アセスメントシートの作成する Webフロントエンド版DX Criteriaのアセスメント シートをカスタマイズしてシートを作成 様々な便利な機能が搭載されていたのでカスタマイズして利用 チェックに応じた自動集計 集計結果のグラフ化機能 結果に応じたスコアリング
4. アセスメントシートの作成する
4. アセスメントシートの作成する
5. クライテリアのチェックを実施する 過去2回、クライテリアのチェックを実施 1回目の集計方法: Google Meetで挙手してリアクションをチェック 集計で数えるのが大変 回答が人にひっぱられてしまう感じがした 2回目の集計方法: Google
Formでアンケート実施 集計が楽になった 回答の集計を集めた後に振り返りが実施できたので、本当にや りたいこと(次の改善活動)に集中できるようになった
1回目のクライテリアのチェック結果 5. クライテリアのチェックを実施する
1回目のチェック時に出た内容 UIコンポーネントの整備やアクセシビリティの対応が進んでい ない HTMLの仕様理解が人によって差がある より良い仕様に落とし込むために他のチームと協業する部分が 弱い 03. 03. 結果を元に行った活動
HTMLの品質を保つためのガードレールを設置 MarkuplintでHTMLの要素の使い方が正しいか、必要な attributeが指定されているか等のチェックを実施 エンジニアで分担し、lintエラーになっていた箇所を修正してい くことで導入を進めた UIコンポーネントが正しいHTML構造になり、 知識量に左右されずHTMLが書けるように → Markuplintの導入
HTMLをみんなで学び、知識の底上げを図る 週に1回Slackのハドルで集まってオンラインで輪読会を実施 FigJamを使って輪読会を通して得た知識を共有 HTMLの仕様理解やアクセシビリティについて 知るきっかけに → HTML解体新書の輪読会を実施
輪読会のFigJamの様子 HTML解体新書の輪読会を実施
2回目のチェック時に一部数値が改善 🎉 04. 04. 活動の効果
点数が向上した部分と下がった部分を話し合った Markuplintの導入でUIコンポーネントの点数が向上した HTMLの仕様理解で点数が下がった項目は「WHATWGを見て仕 様理解しているか?」という内容だったが、メンバーはMDNを 普段見ているからチェックを入れていなかったという声が多か ったので、クライテリアを実情に即したものに変更した アクセシビリティの点数が上がらなかったのでアクセシビリテ ィ改善を次に実施することにした 2回目のチェック時の振り返り
05. 05. まとめ クライテリアを作って自分たちの現在の立ち位置を理解すると 改善の種が見つかる! クライテリアの定期的なチェックでチーム内で品質について考 える機会が生まれる! チェック結果を元にした改善活動でHTMLの品質の向上につなが る!!