Web制作ガイドライン（2021年11月19日版）

 

本ガイドラインは、株式会社トモガラ（以下、当社という）が行うWebサイト制作全般においての品質を保持するために定めたものである。当社は本ガイドラインに基づいたWebサイト制作を行うこととし、お客様に対し常に安定した品質のサービス及び納品物の提供をすることに努める。

サイト設計、ディレクション

基本指針

Webディレクターは、クライアントからの要求仕様を満たすことはもちろん、Webサイト制作の本来の目的を達成するため、適切な情報提供、提案を行う。またWebサイトの情報設計からプロジェクトの進行管理、プロジェクトメンバーの業務管理、納品物の品質管理を適切に行う。

ディレクターは、お客様を含めプロジェクトに関係するメンバー間でのコミュニケーションを積極的に取ることで、円満かつ円滑なプロジェクト進行を心がけるべきであり、お客様に対しての進捗報告、情報共有を定期的かつ明瞭に行い、信頼関係の構築に努める。

プロジェクト進行中の連絡手段

プロジェクト進行中の、お客様を含むプロジェクトメンバーとの連絡及び情報共有の手段は、原則としてChatWork及びBacklogを用いる。

お客様のご要望やプロジェクトの要件及び特性に鑑みて、別途、適するものを選択しても問題ない。

但し、情報管理及び履歴管理の観点から、使用するツールは連絡の内容が全てログとして長期に渡り保存されるとともに、後に検索可能なツールを選択すること。

文字サイズ変更ボタン

Webページ内の文字サイズ変更をWebサイト側で制御する、「文字サイズ変更ボタン」は原則として提供しない。

何故なら、文字サイズの変更はブラウザインターフェイスに任せるべきものであるからである。必要であれば、その方法をヘルプページ等に記載することが望ましい。

ページタイトルやURL

各ページのタイトル及びディレクトリ名やファイル名は、要件に応じてWebディレクターが実装担当者に指示するか、実装担当者がガイドラインに従って命名する。

実装担当者が、ガイドラインから外れた命名をすることは慎むこと。

また、原則として主要ページのメタディスクリプションについては、Webディレクターが実装担当者に記載内容を指示することとする。主要でないページについては、検索エンジンによる自動生成でも構わない。

文言の統一

原則として、下記の通りWebサイト内で使用する文言を統一することで、表記ブレによる品質の低下を防ぐ。

但し、案件の状況やお客様のご要望により、柔軟に対応してよい。

例）

・Webサイトのトップページに遷移するリンクのラベル：トップページ（×ホームページ、×トップ）

・お問い合わせ（×お問合せ、×お問い合せ）

・メールアドレス（×Email、×E-mail、×メイルアドレス、×Mailアドレス、×アドレス）

・英数字は原則半角文字とし、URLや数値、英単語を全角文字で記載しない

・文章内の1文字スペースは半角に統一する

 

その他、同一サイト内で複数の記述・文言が混在しないように注意する。

 

例）

・御社、貴社

・弊社、当社

・クライアント、お客様

・頂きます、いただきます

・いたします、致します、します

アクセス解析

当社が制作するWebサイトについて、アクセス解析ツールの導入は必須とし、お客様からの特別な指定がない限りは、Google Analytics及びSearch Consoleを導入する。

ディレクターは、Webサイト公開前に必ずWebサイトへのGoogle Analyticsトラッキングコードの設置及び設定並びにSearch Consoleの設定が行われていることを確認すること。

デザイン

フォントのサイズ

フォントサイズは最小サイズを12px相当とする。但し、重要でないテキスト（注釈等）については10px相当まで使用してもよい。

現在（2021年）のディスプレイサイズを考慮した場合、標準とするフォントサイズは、本文用で14～16px相当が妥当である。

デザインデータ

原則として、Adobe社のXDを使用して作成するものとする。経過措置として、Photoshopの使用も可とする。共に、利用するバージョンはAdobe CCの最新版を基本とする。

デザインデータには、必ず「説明」レイヤーを設け、リンク色（通常時、hover、active、visited）の指定等、実装担当者向けの指示を記載する。

 

また、作成するものの性質によっては、SVGでの書き出しを想定し、Illustratorでの作成を検討すること。

レイヤーの分け方や命名法等、他人が見ても理解しやすいよう努めること。

スタイルガイド

投稿型ページがある場合、納品後もページの追加が発生する場合には、ワイヤーフレームに指示がなくても、スタイルガイドを作成すること。

スタイルガイドとは、各見出しレベルのデザイン（h1～h6）、リスト（ul, ol, dl）、表組（table）、引用（blockquote）等、頻繁に使用されるHTML要素のデザインをまとめたものをいう。

また、各要素が配置されたときの、他要素とのマージン等もスタイルガイドに記載するのが望ましい。このとき、例えば同じレベルの見出しでも配置される場所によってマージンが異なる等、1つの要素に複数のスタイルが混在するような設定は避けること。

更に、デザイン内で使用している基本カラーの一覧及び使用フォントの一覧もスタイルガイドに記載することとする。

画像素材のライセンス

使用する素材の著作権には十分に配慮し、各種権利関係（著作権、肖像権等）がクリアになっていない、または明確にされていない素材の使用は一切禁止するものとする。

また、素材として使用する画像のライセンスは「ロイヤリティフリー」のものとする。但し、お客様の許可を得た上で「ライツマネージドライセンス」の素材を購入することは妨げない。その際の契約は、素材提供者とお客様間で行うものとし当社が代理で契約することはしない。

SVG

アイコン、簡易な図版等については、SVGの使用を検討する。

その際、データはIllustratorで作成し、SVGでの書き出しは実装担当者が行う。

実際の表示サイズ等は、デザインデータ内の「説明レイヤー」で明確に指示すること。

長いテキストの可読性等

Webページ内に表示するテキストの行間は140%～200%の値となるよう調整する。1行あたりの文字数（行長）は、最長で30～40文字程度になるよう調整することが望ましい。

但し、デザイン要件や文字サイズ及び閲覧環境に依存するため、求める本質は「読みやすさ」であることを忘れないこと。

デバイスフォントの利用

画像での表示が適切である場合を除いては、出来る限りデバイスフォントでの表示を前提にデザインすること。その際、デザインデータ内では、画像で表示すべきテキストとそうでないものが実装担当者に分かるよう、Instructionレイヤーに記載すること。

Webサイトのパフォーマンス、メンテナンス性やCMSの利用を考慮し、テキストの安易な画像化は避けるとともに、Webフォントの使用についても必要最小限に留めること。

Webフォントについては、サブセット化も考慮する。

ファビコン（Favicon）

新規構築のWebサイトのデザインについては、Faviconデータも含めること。既存のデータがある場合は、それを使用してよい。（お客様から特別な指示がある場合を除く）

レスポンシブ（スマートフォン、タブレット）

基本

明確にスマートフォン対応が要件に含まれていない案件においても、スマートフォンやタブレットによる操作を想定したデザインや実装を考慮すること。特にタッチデバイスの特性に関しては十分配慮する。

画面サイズが小さいデバイスでは、モーダルウィンドウ形式の UI は操作性を著しく低下させる可能性があるため極力避けること。または、画面サイズが小さい場合は無効にするなどの配慮を必要とする。

タッチデバイス

タッチ操作を考慮したデザインや実装を行うこと。マウスオーバーに依存した UI は避けるほか、タッチ操作により表示・非表示を切り替える所謂アコーディオン形式の UI は、数が多くなると操作が煩わしくなるため、はじめからすべて開いた状態にするなど配慮する。

画面の縦サイズが長くなることよりもタッチ操作が多くなりすぎないことを重視すること。

また、タップ可能な要素（ボタンやリンク）には、最低でも 40px × 40px 以上のサイズを持たせること。視覚的にそのサイズを持たせることが難しい場合は、タップ可能領域を広げるなどして対応する。また、タップ可能な要素同士の間には十分な余白をもたせること。（但し、十分にサイズが大きいタップ可能要素同士であれば不要）

タップ可能な要素は視覚的に分かりやすいように配慮すること。

ブレイクポイント

要件説明時に特別な指定がないレスポンシブ Web デザイン対応案件では、ブレイクポイントを 1つ、768px （初期 iPad / 縦表示を基準）に設定 することを基準とする。スマートフォンの最小画面サイズは横幅 320px とし、768px までの間は横サイズの可変で対応する。

ディスプレイの横サイズ 768px 以上のデバイスに関しては PC 向けレイアウトを表示する。

ただし、上記についてはプロジェクトの要件によって変動する場合がある。

高精細ディスプレイ（Retina）対応

前提として、スマートフォン向けページのデザインに際しては、レイアウトの基準は、最小横幅を 320px での表示とし、そのサイズで文字サイズやレイアウトを最適化する。

複数のブレイクポイントを指定しない案件におけるスマートフォン向けデザインの最大サイズは横幅 768px での表示となるため、320px ～ 768px までの間でデザインの整合性がとれるように配慮する事（この間の画面サイズによってレイアウトが変わるような指定は禁止。要素のサイズ可変で対応する）。

よって、Retina対応が必要なスマートフォンサイトのデザインデータの作成は、ブレイクポイントとなる 768pxの2倍の横サイズ（1,536px）で行うこととなる。その際、アイコンフォントやCSSを利用し、極力画像の使用を避けるデザインを心がけることで実装時の負担を低減する。また、Webサイトの表示速度についても配慮すること。

PC向けWebページに関しては、Retina対応は不要とする。対応する場合は画像のファイルサイズ増加に十分注意すること。

コーディング全般

基本

納品は、HTML、CSS、JavaScript等ファイル、及び画像を含む、Webサイトを構成するリソース一式を、クライアントサーバにアップロードした状態とする。別途、CD-ROMやDVD等のメディアによる納品を求められる場合はそれに従う。

上記以外に、使用した各種ライブラリ、jQueryやWordPress・Movable Type等といったCMS のプラグインを 1つのドキュメントにまとめてディレクターに提出すること。

また、Sass ファイルや、プリプロセスされた中間制作物一式は、特に要望がない限りはクライアントへは納品しない。メンテナンス作業に備え、プロジェクトごとに社内規定に基づき管理する。

ディレクトリ構成

既存の Web サイトを踏襲する場合やクライアントからの指定がある場合等を除き、基本的なディレクトリ構成は下記の通りとする。

  • htdocs
    • index.html
    • css
      • style.css
    • img
      • common
        • logo.png
      • service(example)
        • image.png
    • inc
      • header.php
    • js
      • function.js

スタイルシートは css ディレクトリへ、同様に、画像、インクルード用ファイル、JavaScript ファイルをそれぞれのディレクトリに格納する。画像は全ページ共通で使用するものを share ディレクトリへ、その他は使用するページのディレクトリ構成に合わせて格納する。

ファイル名の基本ルール

画像などのファイル名は下記の基本ルールに則って付ける。

  • 区切り文字はハイフン （-） を使用する。
  • 大文字小文字を混ぜず、すべて小文字で付ける。
  • 同じ種別のファイルは頭に同じ接頭辞を付ける。例えば、バナー関連ならbnr-、ボタン関連ならbtn-など。
  • 背景画像は頭に bg- という接頭辞を付ける。
  • 同じ内容の画像でサイズが異なる場合はサイズを入れたり （例：example-200×50.png）、デバイスピクセル比を入れたりしてわかりやすくする。（例：example-x2.png）
  • あるclass名に対応する画像は、class名と同じファイル名を付けるなどわかりやすくするとよい 。（例：bg-module-section-header.png）

目指すべき本質は、ディレクトリ構成のルールと合わせ、第三者が見てもわかりやすいファイル名とすることである。

動作検証ブラウザ

当社が標準で保証する動作環境ブラウザは下記の通りとする。この項目は半年ごとに見直される。

パソコン

Google Chrome 最新版

Safari 最新版（Macのみ）

Microsoft Edge 最新版（Windowsのみ）

※Internet Explorer 11以降及びMozilla Firefoxは、要件となっている場合のみ対応・検証する。

スマートフォン

iOS Safari 15.x 以降 （iOS 15.0 以降）

Android 8.0 以降 Chrome

※Android 標準ブラウザは、要件となっている場合のみ対応・検証する。

プログレッシブ・エンハンスメント

上記、動作検証ブラウザに含まれない旧式ブラウザに関しても、最低限必要な操作、情報の取得ができるようスタイルシートの調整は行うこと。多少のレイアウト崩れや装飾目的の画像の表示がされないといった問題に関しては気にする必要はない。

旧式ブラウザとは主に IE9 ～ IE10 や Android 5.x や Android 6.x 系の標準ブラウザを指す。

文字コード

Web サイトの文字コードは、特別な指定がない限り UTF-8 (no BOM) を使用すること。HTML 文書においては、<meta charset=”utf-8″> を head 要素内の可能な限り上部 に（基本的には最初の子要素として）記述すること。

インデントルール

インデントを行う場合、タブ文字は使用しない。

エディタの設定等で 1タブ = 2半角スペースに設定し、1階層の字下げは2半角スペースを基準とする。HTMLのインデントは任意。CSS は宣言ブロック部分に必ずインデントを入れること。

ただし、プリプロセッサやビルドツールを使用する場合においては、最終的な納品物からインデントや改行が削除されていてもよい。元のコーディングファイル、あるいは中間制作物はこのフォーマットに従うこと。

大文字・小文字

HTML の要素名、属性名、および CSS 内のカラーコード等はすべて小文字で統一すること。また、画像をはじめとしたファイル名などでも大文字小文字を混在させたりしないこと。

コメント

HTML、CSS、JavaScript、いずれも分かりやすくコメントを付けること。

但し、プリプロセッサやビルドツールを使用する場合においては、最終的な納品物にコメントが含まれなくてもよい。元のコーディングファイル、あるいは中間制作物にコメントが残るようにすること。

HTML 文書内で不要になった要素ブロックや、CSS ファイル内の不要なスタイル宣言等を、一時的な場合を除いてコメントアウトで長い期間運用することはしない。

viewport

viewportに関しては、原則として下記の記述を標準とする。

<meta name="viewport" content="width=device-width,initial-scale=1.0">

なお、ページ幅が固定されている Web ページの場合、viewport metaを記述しないか、

<meta name="viewport" content="width=640px">

等、数値を指定して記述する。

一方で画面サイズが固定されていない Webページの場合（リキッドレイアウトやレスポンシブ Web デザイン）、initial-scaleのみの記述で問題ないが、Windows PhoneのIEなど、一部のinitial-scaleに対応しないブラウザに配慮して、上記推奨コードの通り、両方の指定を行う。

スキームの記述

外部 CDN からの JavaScript ライブラリ読み込み等を行う場合、URI のスキーム（http: / https:）はすべて https:// から記述すること。

ただし、読み込むファイルが HTTPS で提供されていない等、状況によってはこの限りではないが、原則として HTTPS で提供されない第三者サーバからのライブラリの読み込みは禁止する。また配信先ドメイン所有者の信頼性については事前に確認すること。

HTMLコーディング

基本、バリデーション

基本的な考え方

HTML はメンテナンス性を考慮すること。各ブロックのモジュール化を意識し、CSS の記述と合わせて、あるブロックを他のページにそのまま移動したり、同一ブロック内で要素が多少変更されたとしても（ul 要素 → ol 要素や段落の追加など）、レイアウトや見た目が変化しないように考慮し、モジュールの使い回しを容易にすること。

HTML5 で追加された新要素は適切に使用すること。ただし、旧ブラウザに配慮し、HTML5 要素をセレクタとしては原則として使用しないこと。また、input 要素の type 属性値などについても HTML5 から追加された属性値を用途に応じて適切に使い分けること（type=”mail”、type=”number”、type=”tel”、type=”search” など）。

id 属性は適切に使用すること。セレクタとしての利用も特に制限しないが、多用しすぎてメンテナンス性や再利用性が妨げられてはならない。

HTML5 が廃止され、WHATWG による HTML Living Standard が標準となったことに鑑み、今後は HTML Living Standard に沿った記述を心がけること。

バリデーション

各要素は、HTML のコンテンツモデルや使用できる文脈に基づき適切に記述すること。またアウトラインが適切かについて必ず確認すること。

また、納品前の HTML ファイルは、必ず HTML Conformance Checkers — WHATWG によるチェックを行うこと。特に HTML タグの閉じ忘れといったミスは避ける。なお、バリデーションはビルドツール等によって行っても構わない。

文書型宣言

新規に作成する HTML 文書は、特別な指定がある場合を除いて HTML Living Standard を使用すること。文書型宣言は <!DOCTYPE html> と記述。大文字小文字も左記の通りとする。

MIME Type は text/html を指定すること。特別な指定がある場合を除いて、XHTML （application/xhtml+xml） は使用しないこと。

ただし、HTML は記述統一の観点や、Movable Type から出力される XHTML との整合性等を考慮し、下記のルールに則って記述すること。

 

  • 閉じタグは省略しないこと
  • 属性値は必ず ” ” で囲むこと
  • 論理属性は必ず 属性名=”属性値” という記述にすること。<input type=”check” checked> → <input type=”check” checked=”checked”>
  • URL内やテキストノード内の & は &amp; と文字参照で記述すること

要素や終了タグの省略

HTML における省略可能な要素、あるいは終了タグの省略は原則として行わないこと。

本セクションにおける 「省略可能な要素」 とは、ある要素のコンテンツモデル上は必須だが、条件を満たすことで記述を省略することができるとされている要素 （html 要素、head 要素、body 要素） がその対象となる （詳しくは下記参考リンクを参照）。記述が任意の要素、例えば table 要素内における thead 要素、tbody 要素などはこの限りではない。

なお、要素に関わらず、終了タグの省略は禁止する。

セマンティクス

要素の意味と異なる動作を与えたりしないこと。例えば div 要素や p 要素をクリックすることでリンクとして機能させたりといったことは行わない。リンクを設定したい場合は a 要素を使用すること。

また、class 名や id 名を要素に付与する際も命名規則にはセマンティクスを意識すること。

CSSやJavascriptファイルの読み込み

CSS を外部ファイルとして読み込む場合、パフォーマンスを考慮して 1ファイルにまとめること。また、link 要素に対する media 属性の使用は原則として行わず、CSS ファイル内に @media規則を用いて記述すること。また、原則として CSS ファイル内での @import 規則の使用、および HTML 文書内でのインライン・スタイルの記述は禁止する。

 

JacaScript の読み込みは、script 要素を body 要素の終了タグ直前に記述する。また、可能な場合は async 属性や defer 属性を付与してレンダリングブロックを避ける。なお、「Google タグマネージャ」が使用できる場合は、導入することが望ましい。

ただし、async 属性、defer 属性はスクリプトの依存関係等によって正常に動作しなくなる場合があるため、スクリプトの動作を優先してよい。

type属性

link 要素による CSS の読み込み時や、script 要素に対して type 属性は付与せず省略する。

構造化データ

HTML 文書に対する構造化データの付与は、JSON-LD、もしくは RDFa Lite を用い、語彙は schema.org を原則として使用すること。

構造化データのテストツールとしては、Google の 構造化データテストツール を推奨する。

メタデータやOGP

メタデータ

メタディスクリプション に関しては、主要なページでは設定しておくこと。その際、重複が発生しないように注意する。主要でないページで description が重複するくらいであれば最初から記述しない方が良い。

メタキーワードに関しては、特にクライアントからの指定がない限り省略してよい。

OGP

トップページに関しては原則として OGP の記述を入れておく事。その他、商品ページなど重要なページに関してはクライアントとの取り決め、もしくはディレクター、実装担当者の判断で記述する。

条件付きコメント

条件付きコメントの使用は原則として禁止する。

ただし、要件上どうしても旧式のブラウザ向けにポリフィルを読み込まなければならない場合など、やむを得ない場合は使用可能とする。

ページ上部へのアンカーリンク

ページ上部に移動するためのページ内リンク （所謂アンカーリンク） として使用する a 要素の href 属性値には #top を指定すること。HTML5 においては、#top を指定することで自動的にページ上部へのリンクとして機能するからである。

SVG

スクリプトを伴わない SVG データに関しては img 要素での埋め込みを推奨する。スクリプトを伴う場合は、iframe、もしくは object 要素による埋め込みを推奨。文書内への svg 要素による直接記述は、メンテナンス性の面から推奨しない。

ただし、IE9 以降、および Android 4.0 以降しか SVG の表示に対応していないため、旧 Android が動作検証対象に入る場合はフォールバックを用意する。ただし、完全に装飾目的で使用された SVG であればこの限りではない。

フォールバックの手法

当社の標準的なフォールバックの方法として、下記の方法を用いる。

  • フォールバック用の画像を SVG と同ファイル名の .png 形式で用意し、SVG と同階層に設置する
  • Modernizr Download Builder から SVG 判別ライブラリをダウンロード
  • 上記を modernizr-svg.js として保存し、ページに読み込み
  • 下記のソースコードを modernizr-svg.js の後ろで読み込み （jQuery を使用している場合）

CSSコーディング

基本・バリデーション

基本的な考え方

CSS はメンテナンス性と再利用性を考慮すること。各ブロックのモジュール化を意識し、HTML の記述と合わせて、あるブロックを他のページにそのまま移動したり、同一ブロック内で要素が多少変更されたとしても（ul 要素 → ol 要素や段落の追加など）、レイアウトや見た目が変化しないように考慮し、モジュールの使い回しを容易にすること。

 

セレクタによる詳細度を極力高くしないように心がけ、単一セレクタによる記述を基本とする。また、要素セレクタの使用はなるべく避け、HTML 側の変更によって CSS の変更まで行わなければならなくなる事態を極力避けるよう配慮すること。

 

ベンダープレフィックスは、コーディング時に最新となる各ブラウザのバージョンから、2 世代前を基準に、有無を判断する。また、仮にサポートするブラウザが存在しない場合でも、必ず標準仕様に基づいた記述も併記すること。 ####フォーマット – CSSは宣言ブロック部分に必ずインデントを入れること。 – セレクタと “{” の間には半角スペースを1つ入れる。さらに、プロパティと “:” は続けて記述し、その後ろに半角スペースを1つ入れた上で、値を記述する。 – すべての宣言ブロック末尾には “;” を付与すること。 – 規則集合ごとに1行改行を入れて記述する。 – 複数のセレクタをカンマ区切りで記述する場合は、セレクタごとに改行する。 – プリプロセッサやビルドツールによる最終納品物からの改行やインデント等の自動削除は問題ない。

バリデーション

W3C CSS 検証サービスによるバリデーションを行うこと。特にスペルミスや記述ミスは確実にチェックし、排除すること。プリプロセッサやビルドツールを用いたバリデーションでも構わない。

デフォルトスタイルシートのノーマライズ

デフォルトスタイルシートのノーマライズには Destyle.css を使用する。また、リセット CSS の使用は非推奨とする。

セレクタの命名規則

セレクタとなる class 属性名、id 属性名は、セマンティクスを意識した命名規則を用いること。また、キャメルケースは用いず、”-“（ハイフン）による連結を原則とする。

 

また、レイアウト、モジュール、テキストへの意味づけ等、用途別に先頭文字列を分類するなど、class 名や id 名からセレクタの用途がある程度推測できるなどが望ましい。セレクタの命名規則に関しては、下記を基準とする。

layout-

Web ページ内のレイアウトに用いられる要素には layout- から始まる class 名を使用する。

block-

各ページに共通の要素ブロックなどは block- から始まる class 名を使用する。原則として layout- の子要素のみに使用する。

module-

block- 内でそのまま他の場所に抜き出しても意味が通じる程度のまとまりとなった要素ブロックに付ける。原則として block- の子要素のみに使用する。

elm-

module- 内で単一の要素にスタイルを当てるために使用する class 名は elm- から始める。原則として module- の子要素のみに使用する。

状態の変化

block- や module-、elm- がスクリプトなどによって変化した状態を示すマークアップは、WAI-ARIA / state を利用することが望ましい。ただし、WAI-ARIA / state では語彙が足りない場合 （active など） に関しては state- から始まる class 名を使用する

ショートハンド

極力ショートハンドプロパティを使用する。

ただし、font 関連プロパティのショートハンドに関しては、記述順などが煩雑なことや、スタイルの継承が複雑になる場合もあるため、メンテナンス性や記述ミスのリスクを考慮して、無理に使用する必要はない。body 要素に対しての指定のみにとどめるなど、実装時に判断する。

@media 規則

HTML ガイドラインにて、link 要素に対する media 属性の使用は原則として禁止しているため、メディアクエリに関しては CSS ファイル内での @media 規則のみ許可する。

 

ただし、プリント用 CSS を記述する場合は、CSS ファイルの末尾に記述すること。また、原則として CSS ファイル内での @import 規則の使用は禁止する。

単位などの省略

値が 0 となるプロパティに関しては、単位を省略して記述すること。

また、line-height プロパティの値も原則として単位を省略して記述すること。

値が 0 以下の数値となる場合、0 は省略して記述すること。

リンクの文字色

リンクの文字色は、:link、:visited、:hover それぞれに必ず異なる文字色を設定すること。

リンクの下線はデザイン要件により非表示にしてもよいが、文字色などで通常のテキストとの差異を明確にし、リンクがわかりやすいように配慮すること。

font-family の指定

font-familyプロパティの指定は下記を標準とする。

font-family: '游ゴシック', YuGothic, 'ヒラギノ角ゴ Pro', 'Hiragino Kaku Gothic Pro', 'メイリオ', Meiryo, sans-serif;

明朝体の場合は以下の順序で記述する。

font-family: '游明朝', YuMincho, 'ヒラギノ明朝 ProN W3', 'Hiragino Mincho ProN', 'HG明朝E', 'ＭＳ Ｐ明朝', serif;

z-index の値

z-index プロパティの値は下記の範囲、及びルールに従い指定する。

使用可能な数値の範囲： 0～5000 まで、10 刻み を基本とする。

10 刻みとする理由はメンテナンス等でどうしても既存要素の中間となる値を指定しないといけなくなった場合に備えて。

スタート数値はある要素群の役割ごとに変えてもよい。例えばロールオーバーする要素は 1000 番台から始めるなど。

オーバーレイなど、確実に他の要素より上部に表示されないと困る要素群に対しては 4000 以上の値を指定する。

大規模サイトで上記ルールでは数値が足りなそうなことが想定される場合はこの限りではない。

Web フォントやアイコンフォントの利用

Web フォントやアイコンフォントの利用は、原則として可能とする。但し、ページスピードを重要視するサイト等もあるので、要件に注意すること。

アイコンフォントに関しては、FontAwesome を推奨する。

CSS3 プロパティやセレクタ

CSS3 で追加された新しいプロパティなどは積極的に利用して構わないが、多くのブラウザにおいてベンダプレフィックス付きで先行実装されている機能については仕様の変更などの事態に配慮し、慎重に判断すること。

例えば、border-radius、text-shadow、box-shadow、linear-gradient などについては、ブラウザのサポートも一般的になっているため、特に問題なく使用可能。

なお、サポート対象ブラウザよりも古いバージョンのブラウザに関しては、未対応のプロパティやセレクタを使用することで、閲覧に支障が出るほどレイアウトが大きく崩れたり、アクセシビリティを損ねるような状態になることが予想される場合には、フォールバックを用意すること。

CSSハック

CSS ハックは原則として使用しないこと。やむを得ない場合のみ使用できるが、CSS ファイル内の末尾などにまとめて記述し、標準的なスタイルの記述と混ぜないこと。

中間制作物

ビルドツールやプリプロセッサを使用する場合、最終納品物（Web サイトで読み込まれる CSS ファイル）と、実際に編集している Sass ファイル等の間に、改行、コメントを残し、1ファイルにまとめた CSS ファイルを中間制作物として必ず出力するようにすること。CSS によるコードレビューが必要な場合などに配慮して。

通常は、中間制作物となる CSS ファイルからコメント、改行等を取り除いた（Minify した）ものが最終納品物となる。

JavaScript

基本・バリデーション

基本的な考え方

操作、および情報の取得に影響する部分については、常に JavaScript が無効な環境を考慮すること。それらに影響のない、装飾的な部分に関してはその限りではない。

Web サイトのパフォーマンスを重視し、本質的でない不要な処理を入れないこと。例えば古いブラウザ向けに box-shadow を適用させたいからと言って JavaScript で処理するようなことは無駄と考える。

また、jQuery の場合、セレクタの記述でパフォーマンスに影響が出るケースがある。文書内で唯一の要素を操作するのであれば id セレクタを使った方が高速な可能性が高い、またセレクタはシンプルに記述すること。

$('div.sample ul li#item');

$('#item');

####バリデーション JSHint による構文チェックを推奨する。 #####.jshintrcの設定例

{

  "camelcase": true,

  "curly": true,

  "eqeqeq": true,

  "forin": true,

  "immed": true,

  "indent": 2,

  "latedef": true,

  "newcap": true,

  "noarg": true,

  "noempty": true,

  "nonew": true,

  "plusplus": true,

  "quotmark": true,

  "regexp": true,

  "undef": true,

  "unused": true,

  "strict": true,

  "trailing": true,

  "browser" : true,

  "devel" : true,

  "globals": {

    "jQuery": false

  }

}

シングルクォーテーションとダブルクォーテーション

統一感の問題から、シングルクォーテーションを基本とする。

$('div').add('p').css('background-color', 'red');

$('div').add('<p id="sample">new paragraph</p>').css('background-color', 'red');

セミコロン

セミコロンの省略は行わないこと。JavaScript ではセミコロンの省略が許されるが、セミコロンの挿入を処理系に任せた結果、自動補完が意図せず行われたり、または行われないことでエラーが発生し、デバッグが困難になる等の問題が想定されるため。

変数 / 関数の命名規則

変数名 / 関数名は原則として、キャメルケースを使用する。変数名 / 関数名における「$」は使用禁止。

var firstName = 'taro';

function getListElement() {

 ...

}

####コンストラクタ関数 コンストラクタ関数の名前の先頭は大文字とする。

var Person = function(name){

  this.name = name;

  this.age = age;

};


var taro = new Person('taro', 32);

var jiro = new Person('jiro', 29);

####定数 定数はすべて大文字で記述し、単語間をアンダースコア（_）で接続する。

var API_KEY = 'b6lC50HCr4mA';

ブロックの中での関数宣言

ECMAScript（ECMA-262）では、if や while などのブロック内における関数宣言を認めていない。将来的な互換性を確保するため、この仕様に準じる。

if (x) {

  function foo() {}

}

ブロック内で関数を定義したい場合は、関数式を使用する。

if (x) {

  var foo = function() {}

}

jQuery

jQuery を使用する場合は原則として最新版を使用すること。jQuery の読み込みは Google Hosted Libraries より行う。

<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js"></script>

開発中 bower 等を用いてローカルに必要なライブラリをインストールするといった手法に制約はない。リリース時に上記のルールに基づいてソースコードを修正すること。

プラグイン

jQuery プラグインの利用に特に制限はないが、メンテナンスが継続されていること、軽量であることを重視して選択すること。また動作検証ブラウザにおいてプラグインを使用しなくても実装可能な方法があればそちらを優先すること。

また、アクセシビリティやユーザビリティに影響のない範囲での表示誤差 （角丸やグラデーションの有無） のためだけにプラグインを使用するようなことは避ける他、例えばフォームのプレースホルダは placeholder 属性を使用するなど、HTML で実現可能な機能にプラグインを使用したりしない。

プラグインの動作を理由に読み込む jQuery のバージョンを下げることは禁止する。最新の jQuery で動作しないプラグインは利用不可。

また、使用したライブラリは一覧できるように別途ドキュメントに記載すること。

jquery-latest.js

jquery-latest.js の使用は禁止する。必ずバージョンを明示して呼び出すこと。

セキュリティ

基本

Webサイト、及び Webアプリケーションの実装にあたって参考とすべき外部のガイドラインとしては、IPA 独立行政法人 情報処理推進機構が公開する、「安全なウェブサイトの作り方（改訂第7版）」を参考とすること。

また、納品物として Webアプリケーションのセキュリティ実装の実施状況を確認する必要がある場合は、同ガイドライン付属の「セキュリティ実装 チェックリスト」を利用、あるいは参考の上、クライアントの要望に応じたチェックリストを作成する。

強固なパスワード

CMS インストール時のアカウント設定など、新規でアカウントを設定する際は推測されにくいアカウント名、および強固なパスワードを設定すること。

パスワードは 12 桁以上が望ましいが、状況に応じて 8 桁以上であれば許容する。必ず英数字を混在させ、数字だけのパスワードや英単語によるパスワードは禁止する。また、同一のパスワードを複数のサービスやアカウントで使い回すことも禁止。

上記は、クライアントの要望によらず厳守すること。

推測されやすいアカウント名の例

admin

root

 

改善案

example-admin（”example” 部分はクライアントに応じて変えるなど）

 

不適切なパスワードの例

12345（数字のみ/桁数も不足）

companyname（社名そのままなど）

0312345678（電話番号など外部からわかりやすいもの）

 

強固なパスワードの例

oGZ2BL0ZLjl@

管理画面のパスワード保護

サーバに設置した管理画面をもつプログラムへのログインページは、可能な限りパスワードによって保護する。認証方法はベーシック認証でよい。状況に応じて IP アドレスでのアクセス制限なども検討、実施する。

SSL の利用

問い合わせフォームなど、個人情報を伴うデータをブラウザ・サーバ間で受け渡すプログラムに関してはその通信を SSL（TLS） で保護する。サーバへの SSL 導入をクライアントに提案し、暗号化されていない状態でのデータ送信は原則として行わないこと。

 

SSL を使用する場合、レンタルサーバ業者が提供するような所謂共有 SSL の利用は原則として不可。

SSL サーバ証明書を発行する際に申請する証明書の公開鍵暗号は 2048bit RSA、ハッシュ関数は SHA-2 を選択する。また暗号化強度は 128bit 以上の信頼できる認証局発行 SSL 証明書を利用する。推奨する認証局は下記の通り。

 

シマンテック（旧ベリサイン）

セコムトラストシステムズ（セコムパスポート）

GMO グローバルサイン

ジオトラスト

FTP

サーバへのファイル転送に関して、FTP の使用は禁止する。SFTP（SSH File Transfer Protocol）、もしくは FTPS （File Transfer Protocol over SSL/TLS） を利用し、FTP クライアントに関しては、これらに対応していないものの使用は禁止。

SFTP/FTPS 対応クライアントとして、Windows 環境であれば、WinSCP、NextFTP の利用を推奨。

パフォーマンス

基本

Web ページの表示速度、反応速度に関して、フロントエンド側で対応できる部分に関しては可能な限り配慮すること。

HTML 側での配慮

HTML での配慮については、CSS や JavaScript ファイルの読み込みのセクション を参照のこと。

パフォーマンスチェック

PageSpeed Insights または Lighthouse によるパフォーマンスチェックを必須とする。目安は PC で 85 点以上、モバイルで 80 点以上。

ただしこれを下回った場合でも、すでにやるべきことができているのであれば問題はない。特にスマートフォン向けに最適化されていないサイトのモバイル項目の数値は低く出るので、実機テストにおいて著しく操作性が低いといった問題がない場合は不問とする。

画像の最適化

画像は基本的に PNG 形式（8ビットカラー / アルファチャンネル可）の画像を使用すること。ただし、写真に関してはJPEG形式を使用。画像は、下記の最適化ツールを用いて、必ずファイルサイズの最適化を行う。

PNG：TinyPNG

JPEG：JPEGmini

JPEG 画像は、retina 対応（表示サイズの 2 倍サイズで画像を用意）した上で、画像の圧縮率を高くするという方法が、見た目とファイルサイズのバランスで最もよい場合がある。（[参考](jpeg-retina-sample/)）

CSS の最適化

CSS は必ず1ファイルにまとめ、CSS ファイル内での @import 規則は使用しないこと。また、セレクタは簡略に記述し、スタイルの上書きが頻繁に行われないように配慮することでパフォーマンスは向上する。

Sass 等を使用する場合は、ネストが深くなりすぎないように注意。またはメディアクエリが複数の場所に分散したりしないように配慮すること。また、実際にページで読み込まれる CSS は必ず Minify すること。

また、メンテナンス等により、使われていないスタイル宣言が大量に残ったままになるなど、ファイルサイズを無駄に肥大化させる記述は、ツールなどを用いてなるべく早期に排除するよう心がける。

JavaScript の最適化

jQuery プラグインを複数使用する場合は、なるべく 1 ファイルにまとめること。実際に読み込まれる JavaScript は必ず Minify し、ファイルサイズを最適化すること。

Google Analysis のトラッキングコード、各 SNS のシェアボタン系コードなどは、必ず最新のコードを使用すること。また、CSS や JavaScript ファイルの読み込みのセクション を参照し、async / defer 属性を可能な限り使用する。

Google タグマネージャ

可能な限り、Google タグマネージャの利用を推奨する。Google Analysis のトラッキングコードも Google タグマネージャから配信すれば個別にコードをページに入れる必要はない。

サーバサイドでの設定

下記の設定がサーバ側で可能な場合はできる限り行うこと。

圧縮転送

gzip によるファイル圧縮は、Web サーバ側で mod_deflate が有効であれば .htaccess に下記の記述で有効にできる。

<ifModule mod_deflate.c>

  SetOutputFilter DEFLATE

  BrowserMatch ^Mozilla/4 gzip-only-text/html

  BrowserMatch ^Mozilla/4\.0[678] no-gzip

  BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

  SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|ico)$ no-gzip dont-vary

  SetEnvIfNoCase Request_URI _\.utxt$ no-gzip

</ifModule>

####キャッシュ設定 Web サーバ側で mod_expires が有効であれば .htaccess に下記の記述で有効にできる。画像など、一度公開されれば変更される可能性が低いファイルはキャッシュを長めに設定する。

<ifModule mod_expires.c>

  ExpiresActive On

<Files ~ “¥.(gif|jpg|png|ico)$”>

  ExpiresDefault “access 1 months”

</Files>

  ExpiresByType text/css “access 10 days”

  ExpiresByType text/javascript “access 10 days”

  ExpiresByType application/javascript “access 10 days”

  ExpiresByType image/svg+xml “access 1 months”

  ExpiresByType font/ttf “access 1 months”

  ExpiresByType font/x-woff “access 1 months”

</ifModule>

HTTP/2

サーバ側で HTTP/2 の利用が可能であれば利用する。SPDY の利用も効果があるが、HTTP/2 が利用できる Web サーバであれば、そちらを優先すること。サーバプッシュの設定なども含めて、クライアントサーバ管理担当者と協議する。

rel=subresource

CSS ファイルやページのレンダリングに影響のある JavaScript ファイル に rel=”subresource” を付与することで、Chrome では該当リソースを優先的にダウンロードしキャッシュするため、レンダリング速度が向上する可能性がある。

<script src=”plugin.js” rel=”subresource”></script>

<link rel=”stylesheet subresource” href=”style.css” />

<!– ただし、この指定 （rel=”stylesheet subresource”） は IE7 以前など旧ブラウザでスタイルが読み込まれない場合がある –>

HTTP の Link: ヘッダによる指定でもよい。

詳細は下記を参照。

 

LINK rel=subresource ： The Chromium Projects

rel=prefetch

チュートリアルなど、連続して次のページを読んでいくようなコンテンツの場合、あるいは、ほぼ次に移動する静的なページが決まっているような場合は、Link prefetching の利用が効果的な場合がある。IE11 を含む主要ブラウザで利用可能。

 

<link rel=”next prefetch” href=”step-2.html” />

HTTP の Link: ヘッダによる指定でもよい。

情報管理体制

基本

情報管理の意識を常に持ち、適切な管理を行うことで情報漏洩を防止する。

事例としての紹介許可を得ているかいないかに関わらず、クライアント名やプロジェクトの内容、その他、プロジェクトに関連する情報を、公共の場所など、不特定多数が集まる場で話題にしたりすることを一切禁止する。

例えば、食事の最中、電車などでの移動中の会話などでクライアント名や案件の内容を出したりしない。これは家族や友人、知人などに対しても同様とする。クライアントの情報やプロジェクトの内容を不用意に第三者に話したりしないこと。これは機密情報とされるもの以外も含めすべての情報が該当する。

外出先での電話

やむを得ず、外出先などで携帯電話でクライアント、もしくは社内スタッフとプロジェクトの内容などについての会話をしなければならない場合、会話の内容が第三者に聞こえていないか十分に注意すること。

駅の構内や人通りの多い路上など、不特定多数が往来する場所での通話は禁止する。

パソコンや携帯電話の管理

業務で使用するパソコンや携帯電話 （スマートフォン） の管理は厳重に行い、必ずパスワード等にてロックすること。また、画面ロックを解除したまま席を外したり、他人にそれらを貸したり、使わせたりはしないこと。（パソコンのセキュリティセクション も参照）

メールアドレス

クライアント情報やプロジェクト関連のファイルを、@gmail.com など、フリーのアドレス （不特定多数が @ 以降を共用しているアドレス） 宛に送信することを禁止する。仮にクライアントからそのような要望があったとしても不可。メールアドレス間違いによる外部への情報漏洩を防止するため。

SNS やブログ

個人としての SNS の利用やブログの開設、運営は原則として禁止しないが、クライアントやプロジェクトの内容に関してそれらに投稿することは一切禁止する。これはアカウントが非公開になっている場合も含む。

パソコンのセキュリティ

デスクトップ、モバイルを問わず、使用するパソコンには必ずパスワードによるロックをかけること。また、画面ロックをしないまま PC の前を離れたり、第三者にパソコンを貸したりはしないこと （どうしても一時的に貸さなければならない場合はゲストアカウントを使用し、目の届く範囲で使用させること）。

カフェなど、複数の人間が周囲にいる状況で会社やクライアントの重要な情報が記載されたファイルを開くことを禁止する。また、公衆無線 LAN など、安全でないネットワーク上において、さらに通信が暗号化されていない状況で重要なファイルをメール送信したり、受け取ったりしないこと。

パスワード等の管理

業務で使用する Google Apps、Dropbox など Web サービスは 2 段階認証を必ず有効にすること。また、使用するパスワードは最低でも 8 桁、できれば 12 桁以上の強固なものを設定し、他サービス間での同じパスワードの使い回しは堅く禁じる。

また、パスワードを平文でメール送信することは禁止。どうしてもメールで伝える必要がある場合は、パスワードロックした圧縮ファイルや PDF ファイルに記載して送信した上で、解凍パスワードを別メールで送信するなど最低限の配慮をすること。その際の送信先はメーリングリストなど、複数の人が受信する可能性のあるアドレス宛は避け、必ずクライアント担当者個別に送信する。

社内での連絡であればパスワードのみチャットツール等で送信する方法でも良い。この場合でも、ログイン URL、ID、パスワードといったログインに必要な情報をひとまとめにして送ることは避けること。

パスワード情報などを誰でも閲覧可能な場所に保存したりはしないこと。各自の手元でパスワードを管理する場合は、パスワード管理ソフトを使用し、適切に管理すること。

機密情報の管理

クライアントから提供された機密情報は、担当者の責任において厳重に管理する。

また、紙で提供された情報は、不用意に書類ケースに放置したり、シュレッダーにかけずに廃棄したりするようなことがないように注意すること。

クラウドサービスの利用

Dropbox をはじめとした、データを外部サーバに預けるサービスの利用に関しては、2段階認証を行うなど、セキュリティの要件を満たしていれば特に制約はしないが、クライアントとの業務委託契約、あるいは機密保持契約の内容が優先される。

使用する場合でも、クライアント関連のデータは暗号化して保存するなど、データの取り扱いには注意すること。なお、機密情報と文書または口頭にて明示されたデータのクラウドサービスへのアップロードは原則として禁止する。

その他

他者の著作権

映像、写真、音楽など、他者が創作したものを Web サイトで使用する場合は著作権の侵害を行わないよう十分に注意すること。映像や音楽等、他者が創作したものを公の場で利用する場合は、原則として創作者に対する利用許諾が必要なため、クライアントから提供された素材だとしても、必ず著作権の問題がクリアされているかを確認の上、使用する。

その他、フレームワークやライブラリをはじめとしたプログラムのソースコード等、ライセンスに則った適切な利用を行うこと。詳しくは ライセンスのセクション を参照。

ライセンス

案件で使用する JavaScript （jQueryプラグイン等）、CSS （Destyle.css等）、アイコンライブラリのライセンスは必ず確認し、ライセンスの元に正しく使用すること。また、ソースコードに記載されたライセンス表記は削除しないように注意すること。

ビルドツールなどを使用する場合にコメントの自動削除が適用されてしまう場合があるので /*! … */ 形式のコメントになっていることを確認する。

なお、リンクツール （利用にあたり、作者ページへのリンクが必須のライブラリ等） は使用不可とする。

ブランドロゴ等の利用

Web サービスなど、ブランドロゴをバナーやボタンに使用する際は、各ブランドロゴの利用規約、ガイドラインを必ず確認し、それに従って利用する事。下記に代表的なブランドロゴの利用規約を挙げる（一部は素材画像やロゴデータのダウンロード時に規約が表示される）。