Slide 1

Slide 1 text

HTMLの品質ってなんだっけ? “HTMLクライテリア”の設計と実践 フロントエンドカンファレンス北海道2025 うな(@unachang113)

Slide 2

Slide 2 text

株式会社LayerX バクラク事業部 CREグループ X:@unachang113 しろたんと野球観戦が好きです うな(夛田 小百合/Tada Sayuri) 自己紹介 自己紹介

Slide 3

Slide 3 text

前職PR TIMESで行った活動の 内容を話します 快諾してくださった前職、現職の方々、 本当にありがとうございます...! 発表について

Slide 4

Slide 4 text

目次 01. 01. 02. 02. 03. 03. 04. 04. HTMLクライテリア作成の きっかけ HTMLクライテリア設計の 進め方 結果を元に行った活動 活動の効果 05. 05. まとめ

Slide 5

Slide 5 text

01. 01. HTMLクライテリア作成のきっかけ HTMLの品質に対するエンジニア間の共通の指標がなかったの で、何を満たせば品質を担保していると言えるのかの指標がな かった HTMLの品質について考えるきっかけや継続的に改善点を探す ためにクライテリアを作りたいと思った

Slide 6

Slide 6 text

01. 01. HTMLクライテリア作成のきっかけ HTMLの品質に対するエンジニア間の共通の指標がなかったの で、何を満たせば品質を担保していると言えるのかの指標がな かった HTMLの品質について考えるきっかけや継続的に改善点を探す ためにクライテリアを作りたいと思った → これは建前

Slide 7

Slide 7 text

本音 アクセシビリティ対応のための 土台を作りたい!!!! 01. 01. HTMLクライテリア作成のきっかけ アクセシビリティ対応を行うことにより、様々な環境のユーザ ーを誰一人取り残すことなく情報の発信、閲覧ができるように したい 対応を進めるにはHTMLをセマンティックにすることが不可 欠!!!!!!!まずはその土台を整えたい!!!

Slide 8

Slide 8 text

HTMLの品質を担保するための基準を作成する 1 品質の基準を達成するためのカテゴリを策定する 2 各カテゴリを満たすための判断基準を策定する 3 アセスメントシートの作成する 4 クライテリアのチェックを実施する 5 02. 02. HTMLクライテリア設計の進め方

Slide 9

Slide 9 text

クライテリアって何? 判断や評価を行う際の基準や尺度のこと フロントエンドだと日本CTO協会が提供している Webフロントエンド版DX Criteriaが有名 https://dxcriteria.cto-a.org/frontend PR TIMESではWebフロントエンド版DX Criteriaを元に HTMLの品質をチェックするためのツールとして HTMLクライテリアを作成した

Slide 10

Slide 10 text

対象に本来備わっている特性の集まりが、 要求事項を満たす程度  ISO 9000:2015 / JIS Q 9000:2015 品質って何?

Slide 11

Slide 11 text

対象に本来備わっている特性の集まりが、 要求事項を満たす程度  ISO 9000:2015 / JIS Q 9000:2015 品質って何? →そのモノが持っている特徴・機能が、  期待や基準とどれくらい合っているか

Slide 12

Slide 12 text

対象に本来備わっている特性の集まりが、 要求事項を満たす程度  ISO 9000:2015 / JIS Q 9000:2015 品質って何?

Slide 13

Slide 13 text

→ 品質は国際標準で定義されている! 対象に本来備わっている特性の集まりが、 要求事項を満たす程度 品質って何?  ISO 9000:2015 / JIS Q 9000:2015

Slide 14

Slide 14 text

ソフトウェアの品質に対する定義もある ソフトウェアの品質には8つの特性がある 1 2 3 4 5 6 機能適合性 性能効率性 互換性 信頼性 使用性 セキュリティ 7 保守性 8 移植性 品質って何?

Slide 15

Slide 15 text

ソフトウェア品質の8つの特性にHTMLの品質を 担保するための要素をあてはめて定義していく 1 機能適合性 ユーザーが操作を行う際に迷わないように適切なHTML要素 を使用していること 2 性能効率性 パフォーマンスを意識したHTMLが書けていること 3 互換性 さまざまなデバイスからアクセスした際に 同じ機能が提供できること 1. HTMLの品質を担保するための基準を作成する

Slide 16

Slide 16 text

4 使用性 ユーザーが操作を行う際に迷わないマークアップに なっていること 5 信頼性 動作を保証しているブラウザで表示崩れが起きないこと 6 セキュリティ HTML要素を適切に設定していないことによる セキュリティインシデントがないこと 7 保守性 表示の不具合が生じた場合に原因箇所が 容易に特定できること 8 移植性 他のプロジェクトをまたいで共通の HTMLコンポーネントが利用できること 1. HTMLの品質を担保するための基準を作成する

Slide 17

Slide 17 text

HTMLの品質を担保するための基準を元に 大カテゴリと小カテゴリを策定 2. 品質の基準を達成するためのカテゴリを策定する → 突然の迷走 HTMLだけだとフォーカスが狭すぎない・・・? CSSも品質の定義上必要だよね・・・? React使ってるしReactの話も書く・・・?

Slide 18

Slide 18 text

軌道修正 アドバイザーの1000chさんと壁打ちした セマンティックなHTMLが大目標であることを再確認 コーディングルールではなく、クライテリアとして実装時の試 行錯誤を促したい 2. 品質の基準を達成するためのカテゴリを策定する

Slide 19

Slide 19 text

2つの大カテゴリと3つの小カテゴリを策定 ユーザー体験を支える品質 UIコンポーネント アクセシビリティ ライブラリの選定 成長できるチーム HTMLの仕様理解 セマンティックスなHTMLを書くことの意義の理解 より良い仕様に落とす努力 2. 品質の基準を達成するためのカテゴリを策定する

Slide 20

Slide 20 text

Webフロントエンド版DX Criteriaを参考に 判断基準を策定 3. 各カテゴリを満たすための判断基準を策定する メトリクスの計測 指標を定量的に計測/管理しているか 学習と改善 組織内での学習を健全に回すための サイクルが存在しているか プラクティス よい慣習や実践方法が文化レベルで 浸透できているか アンチパターン 逆指標として、よくない慣習が行われ ていないか

Slide 21

Slide 21 text

例: UIコンポーネント メトリクスの計測 Markuplint等のリンターでUIコンポーネントのマークアップが問題ないかの点検を日常的 (日ごと〜週ごと)に実施している 学習と改善 UIのマークアップに関する議論をチーム内で行い逐次共有している プラクティス 開発プロセスの中でHTMLの利用やアウトラインが妥当かをレビューの際に判断している アンチパターン 同じ様な用途のUIをいくつも作成してしまう。 (共通化されていない) HTMLの意味付けが正しくないコンポーネントが汎用的に利用されている 3. 各カテゴリを満たすための判断基準を策定する その他の判断基準はこちら → https://developers.prtimes.jp/2025/02/05/prtimes_html_criteria/

Slide 22

Slide 22 text

4. アセスメントシートの作成する Webフロントエンド版DX Criteriaのアセスメント シートをカスタマイズしてシートを作成 様々な便利な機能が搭載されていたのでカスタマイズして利用 チェックに応じた自動集計 集計結果のグラフ化機能 結果に応じたスコアリング

Slide 23

Slide 23 text

4. アセスメントシートの作成する

Slide 24

Slide 24 text

4. アセスメントシートの作成する

Slide 25

Slide 25 text

5. クライテリアのチェックを実施する 過去2回、クライテリアのチェックを実施 1回目の集計方法: Google Meetで挙手してリアクションをチェック 集計で数えるのが大変 回答が人にひっぱられてしまう感じがした 2回目の集計方法: Google Formでアンケート実施 集計が楽になった 回答の集計を集めた後に振り返りが実施できたので、本当にや りたいこと(次の改善活動)に集中できるようになった

Slide 26

Slide 26 text

1回目のクライテリアのチェック結果 5. クライテリアのチェックを実施する

Slide 27

Slide 27 text

1回目のチェック時に出た内容 UIコンポーネントの整備やアクセシビリティの対応が進んでい ない HTMLの仕様理解が人によって差がある より良い仕様に落とし込むために他のチームと協業する部分が 弱い 03. 03. 結果を元に行った活動

Slide 28

Slide 28 text

HTMLの品質を保つためのガードレールを設置 MarkuplintでHTMLの要素の使い方が正しいか、必要な attributeが指定されているか等のチェックを実施 エンジニアで分担し、lintエラーになっていた箇所を修正してい くことで導入を進めた UIコンポーネントが正しいHTML構造になり、 知識量に左右されずHTMLが書けるように → Markuplintの導入

Slide 29

Slide 29 text

HTMLをみんなで学び、知識の底上げを図る 週に1回Slackのハドルで集まってオンラインで輪読会を実施 FigJamを使って輪読会を通して得た知識を共有 HTMLの仕様理解やアクセシビリティについて 知るきっかけに → HTML解体新書の輪読会を実施

Slide 30

Slide 30 text

輪読会のFigJamの様子 HTML解体新書の輪読会を実施

Slide 31

Slide 31 text

2回目のチェック時に一部数値が改善 🎉 04. 04. 活動の効果

Slide 32

Slide 32 text

点数が向上した部分と下がった部分を話し合った Markuplintの導入でUIコンポーネントの点数が向上した HTMLの仕様理解で点数が下がった項目は「WHATWGを見て仕 様理解しているか?」という内容だったが、メンバーはMDNを 普段見ているからチェックを入れていなかったという声が多か ったので、クライテリアを実情に即したものに変更した アクセシビリティの点数が上がらなかったのでアクセシビリテ ィ改善を次に実施することにした 2回目のチェック時の振り返り

Slide 33

Slide 33 text

05. 05. まとめ クライテリアを作って自分たちの現在の立ち位置を理解すると 改善の種が見つかる! クライテリアの定期的なチェックでチーム内で品質について考 える機会が生まれる! チェック結果を元にした改善活動でHTMLの品質の向上につなが る!!