行政WebサイトのID,Class命名規則についてNotion AIと語る四方山話
この記事はGovTech東京アドベントカレンダー8日目の記事です。
はじめに
「四方山話(よもやまばなし)」 は、特に筋道を立てずに、いろいろな話題について気ままに語る雑談のことを指します。直訳すると「四方八方の山の話」という意味で、あちこちの様々な話題を取り上げて話すことを表現しています。
行政DXの世界に飛び込んで2年経過、GovTech東京で1年強のtoruishiiです。主にWebのUI/UX全般サポート活動をしています。行政サービスの開発支援のなかで、動かす機能先決でスタイル・アクセシビリティ・アクセス計測などが後付けになってしまい、より良いUXや再利用性の高いシステムとして作りこむのに手遅れな場面に遭遇しました。
そんな、いつか見てきた光景から、サービスにデザインを埋め込む過程について、Notion AIと対話をしてみました。
IDやClassの命名ルールの設計は、SPA(Single Page Application)のインタラクション、デザインシステム、SEO、アクセス解析などに密接に関連するものでしょうか?
はい、IDやClassの命名ルールの設計は、これらの要素と密接に関連しています。以下に具体的な関係性を説明します:
SPAのインタラクション
- 状態管理とコンポーネント操作の効率化
- スムーズな画面遷移制御
- 再利用性の最適化
デザインシステム
- 一貫したスタイリング
- 明確な階層構造
- 保守性の向上
SEO対策
- 検索エンジンの理解度向上
- 重要コンテンツの特定
- クローリング最適化
アクセス解析
- 行動追跡の容易さ
- 利用状況の分析
- 効率的なA/Bテスト
命名ルールの設計は開発効率だけでなく、プロジェクト全体の成功に大きく影響を与える重要な要素です。
アクセシビリティについてはいかがでしょうか?
アクセシビリティに関しても、適切なIDやClassの命名ルールは非常に重要な役割を果たします:
アクセシビリティ
- スクリーンリーダーとの連携を最適化
- WAI-ARIAとの効率的な統合
- キーボード操作の使いやすさを確保
- フォーカスと状態変更の適切な通知
- 代替テキストの一貫した管理
このように、適切な命名ルールは、すべてのユーザーにとって使いやすいウェブサイトを作る上で重要な基盤となります。特に、支援技術を利用するユーザーにとって、より良い体験を提供することができます。
IDやClassの命名ルールは、エンジニアとデザイナーどちらが作成すべきでしょうか?
IDやClassの命名ルールは、エンジニアとデザイナーの協働で作成することが理想的です。その理由は以下の通りです:
エンジニアの視点
- コードの保守性と再利用性
- 技術的な制約への対応
- パフォーマンスの最適化
デザイナーの視点
- デザインシステムとの整合性
- UXの最適化
- 視覚的階層構造の反映
協働の効果
- 専門知識の相互活用による完成度向上
- 一貫性のある開発の実現
- 将来の拡張に柔軟に対応
このように、命名ルールの設計は技術面とデザイン面の両方に影響を与えるため、両者が密接に連携しながら決定していくことが望ましいアプローチとなります。
IDやClassの命名ルールを作成するタイミングは、UXデザインプロセスのどのタイミングで行うべきでしょうか?
IDやClassの命名ルールは、UXデザインプロセスの各段階で段階的に定義します:
1. 情報設計フェーズ
- 基本構造の定義と階層関係の明確化
- コアとなる命名規則の策定
2. ワイヤーフレームフェーズ
- UI要素の配置と状態変化に応じた命名規則の設定
- 再利用可能なコンポーネントの命名規則確立
3. ビジュアルデザインフェーズ
- デザインシステムに基づく命名の最適化
- 視覚要素に関する命名規則の設定
4. プロトタイプフェーズ
- 技術要件に基づく調整と最適化
- 実装面での命名規則の確定
この段階的なアプローチにより、デザインと開発の両面で整合性のある実用的な命名規則を確立できます。各フェーズでの見直しにより、プロジェクトの進行に応じて柔軟に対応が可能です。
IDやClassの命名ルールは、プロジェクトを進めながら状況に応じて調整するため、デザイナーとエンジニアの密な連携が必要ということですね
はい、その通りです。命名ルールの効果的な運用には、継続的な連携が重要です:
継続的な連携のポイント
- 定期的なレビューでの規則の確認と更新
- 新規コンポーネント追加時の早期協議
- 実装時の課題フィードバックと解決
- デザインシステムの進化に応じた調整
効果的な連携方法
- 命名の一貫性を保つドキュメント管理
- 命名規則の実例共有
- 命名に関する議論の可視化
このような連携により、プロジェクトに応じて柔軟に命名ルールを発展させ、チーム全体で一貫した実装とメンテナンスが可能となります。
行政サービスのように、定型化や横展開をしやすい手続きシステムを構築する場合、フロントエンドでのIDやClassの命名ルール作成は重要なプロセスではありませんか?
はい、行政サービスの定型化された手続きシステムでは、IDやClassの命名ルールは極めて重要です:
横展開のしやすさ
- 複数自治体での共通フォーマット再利用
- 標準化による開発・保守コスト削減
アクセシビリティ
- 高いアクセシビリティ基準への対応
- 支援技術との互換性確保
保守・運用
- 法改正対応の容易さ
- 複数ベンダー間の共通理解促進
品質管理
- テスト自動化の実装
- セキュリティ対策の一貫性
このため、初期段階での綿密な命名ルール設計が、プロジェクトの成功と効率的な運用を支えます。
IDやClassの命名ルールは車輪の再発明を避けるためにも、だいじなことなのですね
はい、その通りです。適切な命名ルールは「車輪の再発明」を防ぎ、以下の利点があります:
開発効率の向上
- コンポーネントの再利用性向上
- チーム内の効率的な開発
品質の一貫性
- 検証済みコンポーネントの活用
- テストの効率化
リソースの活用
- コストとメンテナンスの最適化
- チーム間の知見共有
このように、命名ルールの標準化はプロジェクトの効率と品質を高める基盤となります。
ノーコード、ローコードのSaaSを利用してシステムを構築していく際にも、IDやClassの命名ルールは意識すべき重要項目になりますか?
はい、ノーコード・ローコードツールでも命名ルールは重要です。主な理由は以下の通りです:
カスタマイズ時の一貫性
- スタイルのカスタマイズ効率化
- 独自コード追加時の整合性
システム連携
- 外部システム統合の容易さ
- 分析・テストツールとの連携
将来への対応
- 他プラットフォームへの移行
- アップグレード時の互換性
このため、将来の拡張性と保守性を考慮した命名ルールの設計が推奨されます。
こうしたサービス開発では、デザイナーとエンジニアはどのようにチームビルドするのが望ましいでしょうか?
デザイナーとエンジニアのチーム編成において、次の組織構造が効果的です:
クロスファンクショナルチーム制
- デザイナー、エンジニア、プロダクトマネージャーによる三位一体の開発
- 迅速な意思決定と実装の実現
専門性の活用
- 各専門家の知見を活かす環境づくり
- デザインシステムチームとプロダクトチームの連携
効果的なコミュニケーション
- 定例レビューの実施
- 継続的なプロトタイピングとフィードバック
アジャイル開発
- 短サイクルでの実装と改善
- デザインとエンジニアリングの視点統合
この構造により、専門性を活かした効率的な開発とチーム間の相互理解が促進されます。
まとめ
ということで、Notion AIと語る四方山話はいかがでしたでしょうか?個人的には余計な褒めの一言を挟んでくれるClaudeさんの回答が好みではあったりしますが、過去経験を踏まえても、身に染みる回答もあったりして、概ねうなずけるものでした。
行政サービスDXにおけるフロントエンドの再利用性に着目してみると、デザイン&エンジニアリングの一層の充実が求められる状況は、流行りの言葉を使えば 「リジェネラティブ・エンジニアリング」 とでも言えましょうか。
そんなこんな、この分野に興味を持ち一緒に活動してみたいデザイナーやエンジニアの皆様からの気軽なお問い合わせなど、絶賛お待ちしております!!
東京都では2050年代の東京を見据え、長期戦略を検討する「シン東京2050」プロジェクトを実施しています。ご意見を大募集中ですので #シン東京2050 をつけてSNSに投稿してください。
Discussion