本ガイドラインは、バーンワークス株式会社が行う Web サイト制作全般においての品質を保持するために定めたものである。当社は本ガイドラインに基づいた制作を行い、クライアントに対して常に安定した品質のサービス、及び納品物を提供する。
Last modified
ディレクターはクライアントから指定の Web サイト要件を満たし、Web サイトのビジネスゴールを達成するため、適切な情報提供、提案を行う、また Web サイトの情報設計からプロジェクトの進行管理、プロジェクトメンバーの業務管理、納品物の品質管理を適切に行うものとする。
ディレクターはクライアントを含めプロジェクトメンバー間でのコミュニケーションを積極的に取ることで円滑なプロジェクト進行を心がける。また、クライアントに対しては進捗の報告、情報共有を適時、および明確に行い、信頼関係の構築に努める。
新規 Web サイト制作案件が立ち上げに際して行われるキックオフミーティングについては、下記の要領を基本として開催する。クライアントとの間では現状の把握、ゴールイメージの共有、プロジェクト進行におけるスケジュールを含めた認識の共有を主な目的とする。
また、社内のプロジェクトメンバー間においては、現状の把握、ゴールイメージの共有、スケジュールの共有の他、要件の確認に伴い、事前の意見交換を目的とする。これは例えば「事前に実装担当者、デザイナー、プログラマが知っていればもっと効率よくやる方法があった」「こうしておいてくれればもっと作業がしやすかった」といった無駄をなくすことで、生産性を高め、納期の短縮や品質の向上でクライアントに還元する。
社内におけるプロジェクトメンバーのアサインは Web サイト制作事業の責任者権限で行う。リソース管理の観点から、ディレクターが現場の独自判断でメンバーをアサインしたりすることは禁止する。
守秘義務契約、及び業務委託契約を結んでいない外部の個人事業主、及び企業へのプロジェクト情報の開示や作業の依頼は当然ながら一切禁止する。
制作過程でディレクターが作成する標準的なドキュメントは下記の通りとする。フォーマットは問わないが、クライアント環境で問題なく閲覧ができること。当然、プロジェクトに応じて必要なドキュメントは変化する。
Movable Type など導入プロダクトのマニュアルに関しては通常作成不要。開発元の公式ドキュメントがある場合はそれで代用できる。
例えば Movable Type の場合、カスタムフィールドを用いた特殊な入力画面をクライアントに提供するなど、開発元が提供する公式ドキュメントでは対応できない場合などに、簡易なものを作成する前提とする。
プロジェクト進行中のクライアントを含むプロジェクトメンバーとの連絡・情報共有の手段は、クライアントと協議の上、Backlog、Slack、Chatwork をはじめとしたチャット・プロジェクト管理ツールを利用するが、原則として Backlog の利用を推奨する。ただし、クライアントがすでに Slack、もしくは Chatwork を利用している場合など、Backlog よりもそちらを利用した方が効率がよいと考えられる場合はこの限りではない。
プロジェクトのキックオフがされた後、ディレクターによってチャット・プロジェクト管理ツールに当該プロジェクト用のスペースが開設され、プロジェクトメンバーが招待される。
なお、クライアントの要望や、プロジェクトの特性、要件に応じて、連絡・情報共有用のツールは前述したサービス以外にも最適なものを選択できる。ただし、情報管理の観点から、使用ツールの選定はクライアント、および当社の情報管理ポリシーに基づき行う他、連絡の内容がすべて、ログとして長期にわたり保存され、後から検索可能なツールを選択すること。
設計段階からアクセシビリティに配慮する。
例えばカルーセルパネル（数秒ごとに画像や要素がスライド等で差し替わる UI ）は数秒間で要素内に記述されたテキストを把握できない可能性や要素が切り替わるまでの間に正しく操作できない可能性もあり、重要なナビゲーション機能をカルーセルに持たせるべきではないと考える。
あるいはナビゲーション機能を持たせるのであればカルーセルパネルの動作を一時停止できる仕組みを持たせるなど配慮が必要である。
また、色に依存したナビゲーション、文章の使用は禁止する。例えば「下記の赤い方のボタンを押してください」「文章内の赤い文字は重要項目です」などの表記、あるいは色を選択させるような際にカラーパレットのみで色名のラベルがない等の UI は、一部の色覚障がい者にとっては認識できない可能性がある。UI や文章作成時には配慮するものとする。
特別、スマートフォン等、画面サイズの小さいデバイスへの対応を行わない場合でも、マルチデバイスで操作しやすい UI を意識して設計する。「スマートフォンサイトではないのでスマートフォンでの操作が困難でも仕方ない」ということはない。
Web ページ内の文字サイズ変更を Web サイト側で提供する所謂「文字サイズ変更ボタン」の提供は原則として行わない。文字サイズの変更はブラウザ UI に任せるべきで、必要であれば操作方法をヘルプページ等に表記するものとする。
各ページのタイトル、およびディレクトリ名やファイル名はディレクターが実装担当に指示すること。実装担当者が勝手に決めたりはしない。
ページ一覧（各ページタイトルや URL を記載した）をワイヤーフレームと同一ファイル内などに作成し、実装担当者はそれを基準に各ページを作成する。
必要に応じて、ページ内に記述する <meta name="description" /> の値なども決められる場合は記述しておく。
なお、この一覧に CSS や JavaScript 等、ページで読み込まれる各リソースのパス指定などは不要（これらに関しては別途 コーディング関連のセクション で定める）。
案件の状況やクライアントの要望により異なるものの、原則的には下記のように Web サイト内で使用する文言を統一する。表記のブレによる品質の低下を防ぐ。
特にクライアントからの明確な指定がなく、迷ったときは、例えば下記を参考に統一する。
その他、サイト内で複数の文言が混在しないように注意すること。
制作する Web サイトに対して、アクセス解析ツールの導入は必須と考える。なお、クライアントからの特別な指定がない場合のアクセス解析ツールとしては、Google Analysis を導入する前提とする。
ディレクターは、Web サイト公開前に必ず Web サイトへの Google Analytics トラッキングコードの設置、及び設定 （主にゴール設定） が行われていることを確認する。
また、Web サイトには必ず個人情報保護方針 （プライバシーポリシー） を掲載し、その中で、Google Analysis の使用、およびクッキー （Cookie） を使用したアクセスログ収集に関する掲示を行うものとする。その際、Google 社のプライバシーポリシーページへのリンクもあわせて掲載すること。（詳しくは 個人情報保護方針のセクション を参照）
Web サイトには個人情報保護方針 （プライバシーポリシー） のページを必ず用意する。クライアントによってすでに個人情報保護方針が策定されている場合はそれに準じるが、アクセス解析に Google Analysis を用いる場合は、必ず Google Analysis の利用規約に則り、クッキー （Cookie） を使用したアクセスログ収集に関する掲示を追加で行うものとする。
その際、Google 社のプライバシーポリシーページへのリンクもあわせて掲載すること。下記の記述をサンプルとして利用できる。
アクセス解析について
当サイトにおけるアクセスログの収集、および解析には Google Analytics を使用しています。Google Analytics ではクッキー（Cookie） を使用してアクセスログを収集しますが、これは個人を特定する情報を含みません。
なお、収集されるアクセスログは Google 社のプライバシーポリシーに基づいて管理されます。
Google Analytics で収集したアクセスログに関するプライバシーポリシーについては、下記をご確認ください（外部サイト）。
上記サンプル文章は、下記ページの内容を参考にしたもの。
クライアントから新規のサーバ契約やその他外部サービス（ドメイン取得、ASP の利用等）の利用を求められた場合は、当社にてその選定や申し込みの代行を行うなど、最大限協力するものとする。しかし、実際の契約自体はクライアントとサービス提供元間での直接契約とし、当社が代理契約をすることは原則として行わない。
デザイン時にもアクセシビリティに配慮すること。
背景色とテキストのコントラスト、色覚障がい者向けの配色等に考慮する。JIS X 8341-3:2016 における該当箇所は下記引用の通り。
1.4.3 コントラスト（最低限レベル）の達成基準
テキスト及び文字画像の視覚的提示には，少なくとも 4.5:1 のコントラスト比がある。ただし，次の場合は除く（レベル AA）。
a) 大きな文字 サイズの大きなテキスト及びサイズの大きな文字画像には，少なくとも 3:1 のコントラスト比がある。
b) 附随的 テキスト又は文字画像において，次の場合はコントラストの要件はない。アクティブではないユーザインタフェース コンポーネントの一部である，純粋な装飾である，誰も視覚的に確認できない，又は重要な他の視覚的なコンテンツを含む写真の一部分である。
c) ロゴタイプ ロゴ又はブランド名の一部である文字には，最低限のコントラストの要件はない。JIS X 8341-3:2016「1.4 判別可能のガイドライン」から引用
コントラストのチェックに関しては、下記のツール等を推奨。
フォントサイズは、最小サイズを 12px 相当とする。ただし、重要でない注釈等に関しては 10px 相当まで許容する。現在のディスプレイサイズ等を考慮すれば、標準的なフォントサイズは本文で 14px 相当～ 18px 相当が妥当と考える。その他、ボタンサイズ等については タッチデバイスのセクション を参照。
基本的には Adobe 社の Xd もしくは Figma を使用して作成することを推奨する。インストール版ソフトウェアの場合は、できる限り最新バージョンのソフトウェアを使用し、プロジェクトメンバー間でのデータ互換性による作業遅滞を避けるよう努めること。
デザインデータには必ず「指示」レイヤーを追加し、リンクカラー（通常、ホバー時、訪問済み、アクティブ時）の指定をはじめ、実装担当者向けの指示を記載するのもとする。
ディレクター、およびデザイナーはデザインの進行、確定にあたり、実装面からの意見を必ず実装担当者に聞くこと。それにより実装時になってデザインの不具合により手戻りが発生するなどの無駄を省き、実装面の負荷を低減する。
原則としてデザインデータのクライアントへの提供は行わないが、あらかじめ業務委託契約内などでの取り決めがある場合、デザインデータはクライアントに納品される。レイヤーの分け方や名前の付け方など、他の人が見てもわかりやすいように配慮すること。これは実装担当者の作業効率も向上させる。
スタイルガイドの作成を行う。ワイヤーフレームに特に指示がなかった場合でも、各見出しレベルのデザイン（h1～h6）、リスト（ul, ol, dl）、表組み（table）、引用（blockquote）など、頻繁に使用される HTML 要素のデザインはスタイルガイドとして用意する。
また、各要素が配置された際の他要素とのマージンなどもスタイルガイド内に明記する。この際、例えば同じレベルの見出しにもかかわらず、配置される場所によってマージンが異なるなど、1つの要素に複数のスタイルが混在するような事態は避けること。
加えて、デザイン内で使用している基本カラーの一覧、および使用フォントの一覧もスタイルガイド内に記載すること。
画像の著作権には十分配慮し、著作権、モデルリリース等の権利関係がクリアされていない、あるいは明確にされていない画像素材の使用は一切禁止。また、画像の使用にあたり、提供元サイトへのリンクが必須の素材 （所謂リンクツール）、およびサービスの利用も禁止とする。
素材として使用する画像のライセンスは、原則として「ロイヤリティフリー」のものとする。ただし、クライアントの許可を得た上で、「ライツマネージドライセンス」 の画像素材を購入することは問題ない。その際の契約は素材提供業者とクライアント間で行い、当社が代理で契約することはしない。
アイコン、簡単な図版などに関しては、SVG の使用を推奨する。SVG での書き出しは実装担当者が行う。実際のデザイン上での表示サイズなどはデザインデータ内で明確に指定すること。
Web ページ内に表示するテキストの行間や各段落の間隔などは下記を基準とする。
line-height: 1.5;）* + * {margin-top: 2rem;}）letter-spacing: normal を推奨)word-spacing: normal; を推奨)なお、1行あたりの文字数 （行長） は、最長で 30 ～ 40 文字程度になるよう調整することが読みやすさの点から望ましい。
上記はデザインの要件や文字サイズ等によって変動、もしくは Web ページを閲覧する環境に依存するため、あくまで基準とするが、1行あたりの文字数が極端に多すぎる場合、逆に少なすぎて改行が多すぎる場合などは可読性を低下させるため注意が必要。
画像処理が適当である箇所を除いては、なるべくデバイスフォントを使用する前提でデザインすること。また、デザインデータ内では、画像処理すべきテキストとそうでないものが実装担当者にわかるよう、指示レイヤーに記述する。
Web サイトのパフォーマンス、メンテナンス性や CMS の利用も考慮し、バナーなど画像化が必然な場合を除き、テキストの画像化は原則として禁止する。
新規構築の Web サイトに関して、デザインには Favicon のデータも含めること。既存のデータがある場合はそれを使用する。サイズは最低限、下記を実装担当者が生成する前提でデザインを用意すること。基本的にはすべて同じデザインとするため、最小サイズでも認識しやすいようにデザインする。
favicon.png は 64×64 の画像を作成せず apple-touch-icon.png （152px×152px）のファイル名だけ変更して同じ画像を使用してもよい。
実装担当者は上記サイズの画像をデザイナーのデータを基に生成する。例えばビルドツールを使用する場合、下記などがある。
明確にスマートフォン対応が要件に含まれていない案件においても、スマートフォンやタブレットによる操作を想定したデザインや実装が求められる。特に後述するタッチデバイスの特性に関しては十分配慮すること。
画面サイズが小さいデバイスでは、モーダルウィンドウ形式の UI は操作性を著しく低下させる可能性があるため避ける。あるいは画面サイズが小さい場合は無効にするなどの配慮が必要。
タッチ操作を考慮したデザインや実装を行うこと。マウスオーバーに依存した UI は避ける他、タッチ操作により表示非表示を切り替える所謂アコーディオン形式の UI は、数が多くなると操作が煩わしくなるため、はじめからすべて開いた状態にするなど配慮する。
画面の縦サイズが長くなることよりもタッチ操作が多くなりすぎないことを重視すること。
また、タップ可能な要素（ボタンやリンク）には、最低でも 44px × 44px 以上のサイズを持たせること。もし視覚的にそのサイズを持たせることが難しい場合はタップ可能領域を広げるなどして対応する。また、タップ可能な要素同士の間には十分な余白をもたせること（ただし十分にサイズが大きいタップ可能要素同士であれば問題はない）。
タップ可能な要素は視覚的にわかりやすいよう配慮する。
要件説明時に特別な指定がないレスポンシブ Web デザイン対応案件では、ブレイクポイントを 1つ、768px に設定 （初期 iPad / 縦表示を基準） することを基準とする。スマートフォンの最小画面サイズは横幅 320px とし、768px までの間は横サイズの可変で対応する。
ディスプレイの横サイズ 768px 以上のデバイスに関しては PC 向けレイアウトを表示する。
ただし、上記はプロジェクトの要件によって変動する場合がある。
所謂 Retina 対応。
前提として、スマートフォン向けページのデザインに際しては、レイアウトの基準は、最小横幅を 320px での表示とし、そのサイズで文字サイズやレイアウトが最適化されていること。
ブレイクポイント のセクションで指定されているとおり、複数のブレイクポイントを指定しない案件におけるスマートフォン向けデザインの最大サイズは横幅 768px での表示となるため、320px ～ 768px までの間でデザインの整合性がとれるように配慮する事（この間の画面サイズによってレイアウトが変わるような指定は禁止。要素のサイズ可変で対応する）。
よって、Retina 対応が必要なスマートフォンサイトのデザインデータの作成は、ブレイクポイントとなる 768px の 2 倍の横サイズ（1,536px）で行うこととなる。その際、アイコンフォントや CSS を利用し、極力画像の使用を避けるデザインを心がけることで実装時の負担を低減する。また、Web サイトの表示速度面も配慮すること。
PC 向け Web ページに関しては、Retina 対応は不要とする。対応する場合は画像のファイルサイズ増加に十分注意すること。
納品は、クライアントが Git および GitHub の使用、操作に慣れている場合は、プロジェクトで使用しているリポジトリに、クライアント担当者を招待することで引き継ぎを行う。そのまま運用・更新を当該リポジトリで行う場合は、別途ブランチの作成ルール、コミットやプルリクエストのルールなどを事前にクライアントとの間で決めておくこと。
納品後に希望される場合は、リポジトリの移管も可能。その場合は移管先リポジトリをクライアントに用意して頂いた上で、手順に基づいて移管する。
上記以外で、クライアントが Git および GitHub を使用できない事情がある場合は、HTML、CSS、JavaScript 等ファイル、及び画像を含む、Web サイトを構成するリソース一式を、クライアントサーバにアップロードした状態で納品とする。
Git 管理外にある、例えば外部 CDN から直接読み込まれた JavaScript ライブラリ や Movable Type 等、CMS、および使用プラグインに関してはその情報を 1つのドキュメントにまとめてディレクターに提出すること。
また、クライアントサーバへのアップロードにて納品する場合、Sass ファイルや、プリプロセスされた中間制作物一式 （中間制作物のセクション を参照） は、特に要望がない限りはクライアントへは納品しない。元のファイル群が Git 管理されていることをクライアントに説明し、納品物への直接の編集は、差分や修正履歴の把握が難しくなることを前提として共有すること。
バージョン管理には Git、および GitHub を使用する。新規リポジトリの作成に当たっては別途定める社内ルールに基づいてディレクターが申請を行うこと。プロジェクトに使用されるリポジトリはすべてプライベートリポジトリとし、会社契約以外の個人リポジトリをプロジェクトに使用することなどは一切禁止する。
ただし、クライアントからの指定で、クライアントが管理するリポジトリでの作業を行う場合などは、クライアントからの指示、要望に従って対応すること。
なお、デザインデータに関しては、GitHub にはアップロードしないこと。
既存の Web サイトを踏襲する場合やクライアントからの指定がある場合等を除き、基本的なディレクトリ構成は下記の通りとする。
スタイルシートは css ディレクトリへ、同様に、画像、インクルード用ファイル、JavaScript ファイルをそれぞれのディレクトリに格納する。画像は全ページ共通で使用するものを share ディレクトリへ、その他は使用するページのディレクトリ構成に合わせて格納する。
画像などのファイル名は下記の基本ルールに則って付ける。
bnr- など。bg- という接頭辞を付ける。example-200x50.png）、デバイスピクセル比を入れたりしてわかりやすくする （例： example-x2.png）。bg-module-section-header.png）。ディレクトリ構成のルールとあわせて、第三者が見てもわかりやすいファイル名を心がけること。
当社が標準で保証する動作環境ブラウザは下記の通りとする。このセクションは 6ヶ月ごとに見直される。
Internet Explorer 11 （IE11） への対応は原則として行わない。クライアントの要望により行う場合は別途 IE11 対応費用を請求すること。
スマートフォンOSに関しては、原則としてプロジェクト開始時点における最新リリースから2バージョン前までを動作確認対象とする。
ヘルプページ等に対応ブラウザ（推奨環境）を記載する場合は、上記動作検証ブラウザを踏まえ、下記の記述を基本とする。
JavaScript、スタイルシート、画像表示が有効になっている下記のブラウザソフト
上記、動作検証ブラウザに含まれない旧式ブラウザに関しても、最低限必要な操作、情報の取得ができるよう、スタイルシートを無効にした場合の構造には配慮すること。例えばある CSS プロパティが解釈されなかったときに、重要な情報が表示されない、といったことが起こらないように最低限の配慮は必要。一方で多少のレイアウト崩れや装飾目的の画像の表示がされないといった問題に関しては気にする必要はない。旧式ブラウザとは主に IE11 や Android 4.1.x や Android 4.2.x 系の標準ブラウザを指す。
HTML コーディング -> アクセシビリティのセクション や、JavaScruipt -> 基本・バリデーションのセクション 等もあわせて参照のこと。
Web サイトの文字コードは、特別な指定がない限り UTF-8 (no BOM) を使用すること。HTML 文書においては、<meta charset="utf-8" /> を head 要素内の可能な限り上部 （基本的には最初の子要素として） に記述すること。
インデントを行う場合、タブ文字は使用しないこと。エディタの設定等で 1タブ = 2半角スペース に設定し、1階層の字下げは 2半角スペースを基準とする。HTML のインデントは任意。CSS は宣言ブロック部分に必ずインデントを入れること。
<!-- 推奨 --> <ul> <li>HTML</li> <li>CSS</li> </ul>
/* 推奨 */
.example {
color: red;
}
/* 非推奨 */
.example {color: red;}
.example{
color:blue;
}
CSS においては、@media 規則内に記述した規則集合を、すべて 1階層インデントすること。
/* 推奨 */
@media (min-width: 1200px) {
.block-container {
max-width: 970px;
}
}
ただし、プリプロセッサやビルドツールを使用する場合においては、最終的な納品物からインデントや改行が削除されていてもよい。元のコーディングファイル、あるいは中間制作物はこのフォーマットに従うこと。
HTML の要素名、属性名、および CSS 内のカラーコード等はすべて小文字で統一すること。また、画像をはじめとしたファイル名などでも大文字小文字を混在させたりしないこと。
<!-- 非推奨 --> <A HREF="/sample/"><IMG SRC="sampleImage.png" ALT="Sample" /></A>
<!-- 推奨 --> <a href="/sample/"><img src="sample-image.png" alt="Sample" /></a>
/* 非推奨 */
.example {
color: #E5E5E5;
}
/* 推奨 */
.example {
color: #e5e5e5;
}
HTML、CSS、JavaScript 共にわかりやすくコメントを付けること。ただし、プリプロセッサやビルドツールを使用する場合においては、最終的な納品物にコメントが含まれなくてもよい。元のコーディングファイル、あるいは中間制作物にコメントが残るようにすること。
HTML において、要素の閉じタグを認識するためにコメントを入れる場合は、下記のように「//」に続けて該当する要素の class 名、id 名を記述するルールに従う。
<div class="example"> <p>...</p> <!--//.example--></div>
<div id="example"> <p>...</p> <!--//#example--></div>
また、HTML 文書内で不要になった要素ブロックや、CSS ファイル内の不要なスタイル宣言等を、一時的な場合を除いてコメントアウトで長い期間運用することは推奨しない。
viewport に関しては、原則として下記の記述を標準とする。
<!-- 推奨 --> <meta name="viewport" content="width=device-width,initial-scale=1.0" />
ユーザーによる拡大縮小ができなくなるため、下記の記述は推奨されない。
<!-- 非推奨 --> <meta name="viewport" content="width=device-width,initial-scale=1.0,user-scalable=no" />
なお、ページ幅が固定されている Web ページの場合、viewport meta を記述しない、もしくは
<meta name="viewport" content="width=640px" />
などと数値を指定して記述する。
一方で画面サイズが固定されていない Web ページの場合（リキッドレイアウトやレスポンシブ Web デザイン）、本来は下記のように initial-scale のみの記述で問題ないが、Windows Phone の IE など、一部の initial-scale に対応しないブラウザに配慮して、上記推奨コードの通り、両方の指定を行う。
<meta name="viewport" content="initial-scale=1.0" />
外部 CDN からの JavaScript ライブラリ読み込み等を行う場合、URI のスキーム（http: / https:）はすべて https:// から記述すること。
ただし、読み込むファイルが HTTPS で提供されていない等、状況によってはこの限りではないが、原則として HTTPS で提供されない第三者サーバからのライブラリの読み込みは禁止する。また配信先ドメイン所有者の信頼性については事前に確認すること。
<!-- 非推奨 --> <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
<!-- 非推奨 --> <script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
<!-- 推奨 --> <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
<!-- 推奨 --> <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.3.11/angular.min.js"></script>
/* 非推奨 */
@font-face {
url(http://www.example.com/fonts/example) format('woff');
}
/* 非推奨 */
@font-face {
url(//www.example.com/fonts/example) format('woff');
}
/* 推奨 */
@font-face {
url(https://www.google.com/fonts/example) format('woff');
}
CSS / JavaScript ライブラリやフレームワークの利用はプロジェクトの要件に応じて選択可能。ただし、使用するライブラリやフレームワークに関してはメンテナンスが継続されていること、バグフィックスや脆弱性への対応等が、適切に行われていることを重視して選択すること。また、各ライブラリ、フレームワークの利用規約、ライセンスは必ず確認し、不明な点がある場合はディレクターに相談すること。
OSS については Fork した上で、クライアントの要望に合わせて利用することも可能だが、継続的なメンテナンスが可能、かつ会社としてメリットがある場合のみとする。
また、使用したライブラリ・フレームワークは一覧できるように別途ドキュメントに記載すること。
HTML はメンテナンス性を考慮すること。各ブロックのモジュール化を意識し、CSS の記述と合わせて、あるブロックを他のページにそのまま移動したり、同一ブロック内で要素が多少変更されたとしても（ul 要素 → ol 要素や段落の追加など）、レイアウトや見た目が変化しないように考慮し、モジュールの使い回しを容易にすること。
HTML Standard で追加された新要素は適切に使用すること。ただし、旧ブラウザに配慮し、HTML Standard 要素をセレクタとしては原則として使用しないこと。また、input 要素の type 属性値などについても HTML Standard から追加された属性値を用途に応じて適切に使い分けること（type="mail"、type="number"、type="tel"、type="search" など）。
id 属性は適切に使用すること。セレクタとしての利用も特に制限しないが、多用しすぎてメンテナンス性や再利用性が妨げられてはならない。
各要素は、HTML Standard のコンテンツモデルや使用できる文脈に基づき適切に記述すること。またアウトラインが適切かについて必ず確認すること。
また、納品前の HTML ファイルは、必ず The W3C Markup Validation Service によるチェックを行うこと。特に HTML タグの閉じ忘れといったミスは避ける。なお、バリデーションはビルドツール等によって行っても構わない。
JIS X 8341-3:2016 の、適合レベル A に準拠することを社内基準とする。ただし、Web サイトの特性や要件によっては、適合レベル A 対象となる全項目にわたる準拠を必須とするものではなく、また逆に 適合レベル AA、適合レベル AAA 項目を無視してよいということではない。JIS X 8341-3:2016 の全項目に関して適切な知識を持って制作にあたる。
最低限、下記の事柄についてはクリアすること。
text-transform: uppercase; などを適切に使用すること。<!-- サンプル 1 --> <img src="photo.jpg" alt="熱海に行ったときに撮影した写真。海をバックに白壁の民家とペットの黒猫が写っています。" />
<!-- サンプル 2 --> <p> <abbr title="World Wide Web Consortium">W3C</abbr> は World Wide Web で使用される各種技術の標準化を推進する為に設立された標準化団体です。 </p>
<!-- サンプル 3 非推奨 --> 資料のダウンロードは<a href="/dl/">こちら</a>から
<!-- サンプル 3 推奨 --> <a href="/dl/">資料のダウンロードはこちらから</a>
また、ある要素 （例えばナビゲーションなど） の位置固定表示 （e.g. position: fixed;） を行う場合は、画面サイズが小さいときなどに画面外に要素がはみ出して閲覧できなくなるなどの可能性を十分に配慮する。
新規に作成する HTML 文書は、特別な指定がある場合を除いて HTML Standard を使用すること。文書型宣言は <!DOCTYPE html> と記述。大文字小文字も左記の通りとする。
MIME Type は text/html を指定すること。特別な指定がある場合を除いて、XHTML （application/xhtml+xml） は使用しないこと。
HTML は記述統一の観点から下記のルールに則って記述すること。
<br> → <br />" " で囲むこと<input type="check" checked /> → <input type="check" checked="checked" />& と文字参照で記述することただし、静的サイトジェネレーターなど、フレームワークを使用した場合に空要素が閉じられなかったり、論理属性が属性名のみになるなど、フレームワーク側のデフォルト設定、あるいは仕様により避けられない場合は問題ない。一方でページによって記述方法にばらつきが出るようなことはないように注意すること。
HTML における省略可能な要素、あるいは終了タグの省略は原則として行わないこと。
<!-- 非推奨 --> <title>example page</title> <article> <h1>Example 1 <p>This is example page.
<!-- 推奨 -->
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>example page</title>
</head>
<body>
<article>
<h1>Example 1</h1>
<p>This is example page.</p>
</article>
</body>
</html>
本セクションにおける 「省略可能な要素」 とは、ある要素のコンテンツモデル上は必須だが、条件を満たすことで記述を省略することができるとされている要素 （html 要素、head 要素、body 要素） がその対象となる （詳しくは下記参考リンクを参照）。記述が任意の要素、例えば table 要素内における thead 要素、tbody 要素などはこの限りではない。
なお、要素に関わらず、終了タグの省略は禁止する。
要素の意味と異なる動作を与えたりしないこと。例えば div 要素や p 要素をクリックすることでリンクとして機能させたりといったことは行わない。リンクを設定したい場合は a 要素を使用すること。
<!-- 非推奨 --> <div onclick="allEntries();">すべての記事一覧へ</div>
<!-- 推奨 --> <a href="/all/">すべての記事一覧へ</a>
また、class 名や id 名を要素に付与する際も命名規則にはセマンティクスを意識すること。
<!-- 非推奨 --> <span class="red">注意してください</span>
<!-- 推奨 --> <span class="elm-coution">注意してください</span>
class 名や id 名の命名規則に関して詳しくは セレクタの命名規則セクション を参照。
CSS を外部ファイルとして読み込む場合、パフォーマンスを考慮して 1ファイルにまとめること。また、link 要素に対する media 属性の使用は原則として行わず、CSS ファイル内に @media規則を用いて記述すること。また、原則として CSS ファイル内での @import 規則の使用、および HTML 文書内でのインライン・スタイルの記述は禁止する。
JacaScript の読み込みは、script 要素を body 要素の終了タグ直前に記述する。また、可能な場合は async 属性や defer 属性を付与してレンダリングブロックを避ける。なお、「Google タグマネージャ」が使用できる場合は、導入することが望ましい。
<!-- 非推奨 --> <link rel="stylesheet" href="base.css" media="screen" /> <link rel="stylesheet" href="grid.css" media="screen" /> <link rel="stylesheet" href="print.css" media="print" />
<!-- 推奨 --> <link rel="stylesheet" href="style.css" />
<!-- 非推奨 --> <head> <script src="plugin.js"></script> <script src="function.js"></script> </head>
<!-- 推奨 --> <script src="plugin.js" async="async" defer="defer"></script> <script src="function.js" async="async" defer="defer"></script> </body>
ただし、async 属性、defer 属性はスクリプトの依存関係等によって正常に動作しなくなる場合があるため、スクリプトの動作を優先してよい。
パフォーマンスのセクション もあわせて参照のこと。
link 要素による CSS の読み込み時や、script 要素に対して type 属性は付与せず省略する。
<!-- 非推奨 --> <link rel="stylesheet" href="style.css" type="text/css" />
<!-- 推奨 --> <link rel="stylesheet" href="style.css" />
<!-- 非推奨 --> <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js" type="text/javascript"></script>
<!-- 推奨 --> <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>
HTML 文書に対する構造化データの付与は、Microdata、もしくは RDFa Lite を用い、語彙は schema.org を原則として使用すること。ただし、構造化データの付与自体は必須ではない。
構造化データのテストツールとしては、Google の 構造化データテストツール を推奨する。
<meta name="description" /> に関しては、主要なページでは設定しておく事。その際、重複が発生しないように注意。主要でないページで description が重複するくらいであれば最初から記述しない事。
<meta name="keywords" /> に関しては記述不要。クライアントから別予算をもって求められない限り原則として対応しない（IE11 対応と同様の扱いとする）。
トップページに関しては原則として OGP の記述を入れておく事。その他、商品ページなど重要なページに関してはクライアントとの取り決め、もしくはディレクター、実装担当者の判断で記述する。下記に標準的な OGP 設定のサンプルを示す。
<!-- トップページへの記述例（MT タグ使用例） --> <meta property="og:title" content="<$mt:BlogName$>" /> <meta property="og:url" content="<$mt:BlogURL$>" /> <meta property="og:description" content="<$mt:BlogDescription$>" /> <meta property="og:image" content="http://example.com/img/1200x630.png" /> <meta property="og:type" content="website" />
<!-- 個別ページ（商品ページやニュース記事）への記述例（MT タグ使用例） --> <meta property="og:title" content="<$mt:EntryTitle encode_html="1"$>" /> <meta property="og:url" content="<$mt:EntryPermalink$>" /> <meta property="og:site_name" content="<$mt:BlogName$>" /> <meta property="og:description" content="<$mt:EntryExcerpt encode_html="1"$>" /> <meta property="og:image" content="http://example.com/img/article/1200x630.png" /> <meta property="og:type" content="article" />
条件付きコメントの使用は原則として禁止する。
<!-- 非推奨 --> <!--[if IE 8]> ... <![endif]-->
ただし、要件上どうしても旧式のブラウザ向けにポリフィルを読み込まなければならない場合など、やむを得ない場合は使用可能。
ページ上部に移動するためのページ内リンク （所謂アンカーリンク） として使用する a 要素の href 属性値には #top を指定すること。HTML Standard においては、#top を指定することで自動的にページ上部へのリンクとして機能する。
<a href="#top">このページの上部へ</a>
スクリプトを伴わない SVG データに関しては img 要素での埋め込みを推奨する。スクリプトを伴う場合は、iframe、もしくは object 要素による埋め込みを推奨。文書内への svg 要素による直接記述は、メンテナンス性の面から積極的には推奨しないが、状況によって判断する。
CSS はメンテナンス性と再利用性を考慮すること。各ブロックのモジュール化を意識し、HTML の記述と合わせて、あるブロックを他のページにそのまま移動したり、同一ブロック内で要素が多少変更されたとしても（ul 要素 → ol 要素や段落の追加など）、レイアウトや見た目が変化しないように考慮し、モジュールの使い回しを容易にすること。
セレクタによる詳細度を極力高くしないように心がけ、単一セレクタによる記述を基本とする。また、要素セレクタの使用はなるべく避け、HTML 側の変更によって CSS の変更まで行わなければならなくなる事態を極力避けるよう配慮すること。
/* 非推奨 */
.block-header ul.block-main-nav li a {...}
/* 推奨 */
.block-main-nav a {...}
ベンダプレフィックスは、コーディング時に最新となる各ブラウザのバージョンから、2 世代前を基準に、有無を判断する。また、仮にサポートするブラウザが存在しない場合でも、必ず標準仕様に基づいた記述も併記すること。
/* 非推奨 */
.example {
color:red;
margin:0
}
.sample{color:red;margin:0}
/* 推奨 */
.example {
color: red;
}
.sample {
...
}
/* 非推奨 */
h1,h2,h3 {
font-weight: normal;
line-height: 1.2;
}
/* 推奨 */
h1,
h2,
h3 {
font-weight: normal;
line-height: 1.2;
}
W3C CSS 検証サービスによるバリデーションを行うこと。特にスペルミスや記述ミスは確実にチェックし、排除すること。なお、プリプロセッサやビルドツールを用いたバリデーション、あるいはエディタの機能として提供されている機能を利用したバリデーションでも構わない。
デフォルトスタイルシートのノーマライズには Normalize.css を使用する。また、リセット CSS の使用は非推奨とする。
セレクタとなる class 属性名、id 属性名は、セマンティクスを意識した命名規則を用いること。また、キャメルケースは用いず、"-"（ハイフン）による連結を原則とする。
/* 非推奨 */
.blockHeader {...}
.mainNavigation {...}
.red {...}
.h1 {...}
また、レイアウト、モジュール、テキストへの意味づけ等、用途別に先頭文字列を分類するなど、class 名や id 名からセレクタの用途がある程度推測できるなどが望ましい。セレクタの命名規則に関しては、下記を基準とする。
layout-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 名を使用する
/* 推奨 */
.layout-main-content {...}
.layout-sub-content {...}
.block-header {...}
.block-main-nav {...}
.block-section {...}
.module-section-header {...}
.module-page-title {...}
.elm-pub-time {...}
.elm-coution {...}
<!-- 推奨 --> <ul class="module-sub-menu" aria-expanded="true"> <li class="state-active"> ...略...
/* 推奨 */
.module-sub-menu[aria-expanded="true"] {...}
.state-active {...}
極力ショートハンドプロパティを使用する。
/* 非推奨 */ font-family: "Hiragino Kaku Gothic ProN", Sans-Serif; font-size: 100%; font-style: normal; font-weight: bold; line-height: 1.6; margin-bottom: 1em; margin-left: 1em; margin-right: 1em; margin-top: 1em; padding-bottom: 2em; padding-left: 1em; padding-right: 1em; padding-top: 0;
/* 推奨 */ font: normal bold 100%/1.6 "Hiragino Kaku Gothic ProN", Sans-Serif; margin: 1em; padding: 0 1em 2em;
ただし、font 関連プロパティのショートハンドに関しては、記述順などが煩雑なことや、スタイルの継承が複雑になる場合もあるため、メンテナンス性や記述ミスのリスクを考慮して、無理に使用する必要はない。body 要素に対しての指定のみにとどめるなど、実装時に判断する。
HTML ガイドラインにて、link 要素に対する media 属性の使用は原則として禁止しているため、メディアクエリに関しては CSS ファイル内での @media 規則のみ許可する。
ただし、プリント用 CSS を記述する場合は、CSS ファイルの末尾に記述すること。また、原則として CSS ファイル内での @import 規則の使用は禁止する。
値が 0 となるプロパティに関しては、単位を省略して記述すること。
margin: 0; padding: 0;
また、line-height プロパティの値も原則として単位を省略して記述すること。
line-height: 1.5;
値が 0 以下の数値となる場合、0 は省略して記述すること。
opacity: .8; font-size: .875em;
リンクの文字色は、:link、:visited、:hover それぞれに必ず異なる文字色を設定すること。
a {
color: #52a437;
text-decoration: none;
}
a:visited {
color: #428bca;
}
a:hover {
color: #fc4f00;
text-decoration: underline;
}
a:active {
color: #fc4f00;
}
リンクの下線はデザイン要件により非表示にしてもよいが、本文内など、通常のテキストとリンクテキストが混在する部分では、下線やアイコンを付与するなどして通常のテキストとの差異を明確にし、リンクがわかりやすいように配慮すること。
font-family プロパティの指定は下記を標準とする。
body {
font-family: "Helvetica Neue", Arial, "Hiragino Kaku Gothic ProN",
"Hiragino Sans", "BIZ UDPGothic", Meiryo, sans-serif;
}
z-index プロパティの値は下記の範囲、及びルールに従い指定する。
Web フォントやアイコンフォントの利用は可能。特にアイコンフォントに関しては、Font Awesome を推奨する。
第三者が提供するフォントを使用する場合は、ライセンスのセクション も確認すること。
CSS3 で追加された新しいプロパティなどは積極的に利用して構わないが、多くのブラウザにおいてベンダプレフィックス付きで先行実装されている機能については仕様の変更などの事態に配慮し、慎重に判断すること。
例えば、border-radius、text-shadow、box-shadow、linear-gradient などについては、ブラウザのサポートも一般的になっているため、特に問題なく使用可能。
なお、サポート対象ブラウザよりも古いバージョンのブラウザに関しては、未対応のプロパティやセレクタを使用することで、閲覧に支障が出るほどレイアウトが大きく崩れたり、アクセシビリティを損ねるような状態になることが予想される場合には、フォールバックを用意すること。
CSS ハックは原則として使用しないこと。やむを得ない場合のみ使用できるが、CSS ファイル内の末尾などにまとめて記述し、標準的なスタイルの記述と混ぜないこと。
ビルドツールやプリプロセッサを使用する場合、最終納品物（Web サイトで読み込まれる CSS ファイル）と、実際に編集している Sass ファイル等の間に、改行、コメントを残し、1ファイルにまとめた CSS ファイルを中間制作物として必ず出力するようにすること。CSS によるコードレビューが必要な場合などに配慮して。
通常は、中間制作物となる CSS ファイルからコメント、改行等を取り除いた（Minify した）ものが最終納品物となる。
操作、および情報の取得に影響する部分については、常に JavaScript が無効な環境を考慮すること。それらに影響のない、装飾的な部分に関してはその限りではない。
Web サイトのパフォーマンスを重視し、本質的でない不要な処理を入れないこと。例えば古いブラウザ向けに box-shadow を適用させたいからと言って JavaScript で処理するようなことは無駄と考える。
また、jQuery の場合、セレクタの記述でパフォーマンスに影響が出るケースがある。文書内で唯一の要素を操作するのであれば id セレクタを使った方が高速な可能性が高い、またセレクタはシンプルに記述すること。
$('div.sample ul li#item');
$('#item');
JSHint による構文チェックを推奨する。
{
"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 ではセミコロンの省略が許されるが、セミコロンの挿入を処理系に任せた結果、自動補完が意図せず行われたり、または行われないことでエラーが発生し、デバッグが困難になる等の問題が想定されるため。
変数名 / 関数名は原則として、キャメルケースを使用する。変数名 / 関数名における「$」は使用禁止。
const firstName = 'taro';
function getListElement() {
...
}
コンストラクタ関数の名前の先頭は大文字とする。
const Person = function(name){
this.name = name;
this.age = age;
};
const taro = new Person('taro', 32);
const jiro = new Person('jiro', 29);
定数はすべて大文字で記述し、単語間をアンダースコア（_）で接続する。
const API_KEY = 'b6lC50HCr4mA';
ECMAScript（ECMA-262）では、if や while などのブロック内における関数宣言を認めていない。将来的な互換性を確保するため、この仕様に準じる。
if (x) {
function foo() {}
}
ブロック内で関数を定義したい場合は、関数式を使用する。
if (x) {
const foo = function() {}
}
jQuery は原則として推奨はしないが、要件により使用する場合は 3.x 系の最新版を使用すること。jQuery の読み込みは Google Hosted Libraries より行う。
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.6.1/jquery.min.js"></script>
開発中 bower 等を用いてローカルに必要なライブラリをインストールするといった手法に制約はない。リリース時に上記のルールに基づいてソースコードを修正すること。
jQuery プラグインの利用に特に制限はないが、メンテナンスが継続されていること、軽量であることを重視して選択すること。また動作検証ブラウザにおいてプラグインを使用しなくても実装可能な方法があればそちらを優先すること。
また、アクセシビリティやユーザビリティに影響のない範囲での表示誤差 （角丸やグラデーションの有無） のためだけにプラグインを使用するようなことは避ける他、例えばフォームのプレースホルダは placeholder 属性を使用するなど、HTML で実現可能な機能にプラグインを使用したりしない。
プラグインの動作を理由に読み込む jQuery のバージョンを下げることは禁止する。最新の jQuery で動作しないプラグインは利用不可。
また、使用したライブラリは一覧できるように別途ドキュメントに記載すること。
jquery-latest.js の使用は禁止する。必ずバージョンを明示して呼び出すこと。（参考記事）
使用するプロダクトはサポート体制、および開発元が定めるプロダクトライフサイクルポリシー（主に旧製品のメンテナンス継続期間や後方互換性の確保に関するポリシー）を考慮する。
オープンソースプロダクトは、クライアントが保守対応可能な部署、人材を自社で持つ場合は問題ないが、そうでない場合はサポートの提供方法について事前に十分配慮する。
「無料」であることを理由にオープンソースプロダクトを選択するようなことはしない。クライアントに対してはプロダクトのサポート体制やプロダクトライフサイクルポリシーについて説明を怠らない。
上記を踏まえ、当社では原則として SixApart 社の Movable Type、およびその関連プロダクトを選択肢の第一候補とするが、プロダクト選定はクライアントの要件、ビジネスゴールの達成に対してそのプロダクトが最適であるかが前提となる。
Movable Type、およびその関連製品として案件で利用を推奨するプロダクトは下記の通り。
Movable Type や WordPress など CMS のプラグイン利用に特に制限はないが、メンテナンスが継続されていること、脆弱性など、不具合への対応が適切に行われていることを重視して選択すること。
プラグインの動作を理由に CMS のバージョンを下げること、あるいは CMS 本体のプログラムの改変を行うことは禁止する。最新のバージョンで動作しないプラグインは利用不可。
また、使用したプラグインは一覧できるように別途ドキュメントに記載すること。
Webサイト、及び Webアプリケーションの実装にあたって参考とすべき外部のガイドラインとしては、IPA 独立行政法人 情報処理推進機構が公開する、「安全なウェブサイトの作り方（改訂第7版）」を参考とすること。
また、納品物として Webアプリケーションのセキュリティ実装の実施状況を確認する必要がある場合は、同ガイドライン付属の「セキュリティ実装 チェックリスト」を利用、あるいは参考の上、クライアントの要望に応じたチェックリストを作成する。
CMS インストール時のアカウント設定など、新規でアカウントを設定する際は推測されにくいアカウント名、および強固なパスワードを設定すること。
パスワードは 32 桁以上が望ましいが、状況に応じて 16 桁以上であれば許容する。必ず英数字を混在させ、数字だけのパスワードや英単語によるパスワードは禁止する。また、同一のパスワードを複数のサービスやアカウントで使い回すことも禁止。
上記は、クライアントの要望によらず厳守すること。
adminrootexample-admin（"example" 部分はクライアントに応じて変えるなど）12345（数字のみ/桁数も不足）companyname（社名そのままなど）0312345678（電話番号など外部からわかりやすいもの）yrQpjO9BI4gx84a@Movable Type をはじめ、サーバに設置した管理画面をもつプログラムへのログインページは、可能な限りパスワードによって保護する。認証方法はベーシック認証でよい。状況に応じて IP アドレスでのアクセス制限なども検討、実施する。
例として、Movable Type 管理画面にベーシック認証を設定する場合は、下記のような .htaccess の記述が考えられる。
<Files mt.cgi> AuthUserFile /var/www/html/.htpasswd AuthGroupFile /dev/null AuthName "Please enter your ID and password" AuthType Basic require valid-user order deny,allow </Files>
<Files mt.cgi> の部分は、主要な実行ファイルのリネームを行っている場合は適時変更する。
ディレクトリ単位で認証をかけても問題ない場合は、そのように対処する。Movable Type 等の場合、インストールディレクトリ全体に認証をかけてしまうと、コメントや検索用プログラム等を外部から利用できなくなるので注意が必要。
問い合わせフォームなど、個人情報を伴うデータをブラウザ・サーバ間で受け渡すプログラムに関してはその通信を SSL（TLS） で保護する。サーバへの SSL 導入をクライアントに提案し、暗号化されていない状態でのデータ送信は原則として行わないこと。
SSL を使用する場合、レンタルサーバ業者が提供するような所謂共有 SSL の利用は原則として不可。
SSL サーバ証明書を発行する際に申請する証明書の公開鍵暗号は 2048bit RSA、ハッシュ関数は SHA-2 を基準として選択する。また暗号化強度は 128bit 以上の信頼できる認証局発行 SSL 証明書を利用する。推奨する認証局は下記の通り。
サーバへのファイル転送に関して、FTP の使用は禁止する。SFTP（SSH File Transfer Protocol）、もしくは FTPS （File Transfer Protocol over SSL/TLS） を利用し、FTP クライアントに関しては、これらに対応していないものの使用は禁止。
SFTP/FTPS 対応クライアントとして、Windows 環境であれば、WinSCP、NextFTP の利用を推奨。
Movable Type プログラムは、下記の通り主要な実行ファイルのリネーム、および設定ファイルへの追記を行うこと。リネームのルールは別途定めているため下記は参考。
#mt-config.cgiに追記 AdminScript mt-example-example.cgi UpgradeScript mt-upgrade-example.cgi DataAPIScript mt-data-api-example.cgi CheckScript mt-check-example.cgi
また、Web サイトの構築に不要な機能に関しては .cgi ファイルの実行権限を削除してもよい。
Web ページの表示速度、反応速度に関して、フロントエンド側で対応できる部分に関しては可能な限り配慮すること。
HTML での配慮については、CSS や JavaScript ファイルの読み込みのセクション を参照のこと。
PageSpeed Insights によるパフォーマンスチェックを必須とする。目安は PC で 85 点以上、モバイルで 80 点以上。
ただしこれを下回った場合でも、すでにやるべきことができているのであれば問題はない。特にスマートフォン向けに最適化されていないサイトのモバイル項目の数値は低く出るので、実機テストにおいて著しく操作性が低いといった問題がない場合は不問。
以下のセクションで説明する。
画像は基本的に PNG 形式（8ビットカラー / アルファチャンネル可）の画像を使用すること。ただし、写真に関してはJPEG形式を使用。画像は、下記の最適化ツールを用いて、必ずファイルサイズの最適化を行う。
JPEG 画像は、retina 対応（表示サイズの 2 倍サイズで画像を用意）した上で、画像の圧縮率を高くするという方法が、見た目とファイルサイズのバランスで最もよい場合がある。（参考）
閲覧環境が許す場合は WebP 形式の画像を使用することも可能。
ビルドツールを使用する場合、例えば Grunt 向けなら下記のようなツールがある。
CSS は必ず1ファイルにまとめ、CSS ファイル内での @import 規則は使用しないこと。また、セレクタは簡略に記述し、スタイルの上書きが頻繁に行われないように配慮することでパフォーマンスは向上する。
Sass 等を使用する場合は、ネストが深くなりすぎないように注意。またはメディアクエリが複数の場所に分散したりしないように配慮すること。また、実際にページで読み込まれる CSS は必ず Minify すること。
また、メンテナンス等により、使われていないスタイル宣言が大量に残ったままになるなど、ファイルサイズを無駄に肥大化させる記述は、ツールなどを用いてなるべく早期に排除するよう心がける。
jQuery プラグインを複数使用する場合は、なるべく 1 ファイルにまとめること。実際に読み込まれる JavaScript は必ず Minify し、ファイルサイズを最適化すること。
Google Analysis のトラッキングコード、各 SNS のシェアボタン系コードなどは、必ず最新のコードを使用すること。また、CSS や JavaScript ファイルの読み込みのセクション を参照し、async / defer 属性を可能な限り使用する。
可能な限り、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 の利用が可能であれば利用する。SPDY の利用も効果があるが、HTTP/2 が利用できる Web サーバであれば、そちらを優先すること。サーバプッシュの設定なども含めて、クライアントサーバ管理担当者と協議。
その他、CDN （Content Delivery Network） の利用など、サードパーティのサービスを利用する場合はクライアントと協議の上決定すること。
CSS ファイルやページのレンダリングに影響のある JavaScript ファイル に rel="subresource" を付与することで、Chrome では該当リソースを優先的にダウンロードしキャッシュするため、レンダリング速度が向上する可能性がある。
<script src="plugin.js" rel="subresource"></script>
<link rel="stylesheet subresource" href="style.css" />
HTTP の Link: ヘッダによる指定でもよい。
詳細は下記を参照。
チュートリアルなど、連続して次のページを読んでいくようなコンテンツの場合、あるいは、ほぼ次に移動する静的なページが決まっているような場合は、Link prefetching の利用が効果的な場合がある。
<link rel="next prefetch" href="step-2.html" />
HTTP の Link: ヘッダによる指定でもよい。
詳細は下記を参照。
情報管理の意識を常に持ち、適切な管理を行うことで情報漏洩を防止する。
事例としての紹介許可を得ているかいないかに関わらず、クライアント名やプロジェクトの内容、その他、プロジェクトに関連する情報を、公共の場所など、不特定多数が集まる場で話題にしたりすることを一切禁止する。
例えば、食事の最中、電車などでの移動中の会話などでクライアント名や案件の内容を出したりしない。これは家族や友人、知人などに対しても同様とする。クライアントの情報やプロジェクトの内容を不用意に第三者に話したりしないこと。これは機密情報とされるもの以外も含めすべての情報が該当する。
やむを得ず、外出先などで携帯電話でクライアント、もしくは社内スタッフとプロジェクトの内容などについての会話をしなければならない場合、会話の内容が第三者に聞こえていないか十分に注意すること。
駅の構内や人通りの多い路上など、不特定多数が往来する場所での通話は禁止する。
業務で使用するパソコンや携帯電話 （スマートフォン） の管理は厳重に行い、必ずパスワード等にてロックすること。また、画面ロックを解除したまま席を外したり、他人にそれらを貸したり、使わせたりはしないこと。（パソコンのセキュリティセクション も参照）
クライアント情報やプロジェクト関連のファイルを、@gmail.com など、フリーのアドレス （不特定多数が @ 以降を共用しているアドレス） 宛に送信することを禁止する。仮にクライアントからそのような要望があったとしても不可。メールアドレス間違いによる外部への情報漏洩を防止するため。
個人としての SNS の利用やブログの開設、運営は原則として禁止しないが、クライアントやプロジェクトの内容に関してそれらに投稿することは一切禁止する。これはアカウントが非公開になっている場合も含む。
デスクトップ、モバイルを問わず、使用するパソコンには必ずパスワードによるロックをかけること。また、画面ロックをしないまま PC の前を離れたり、第三者にパソコンを貸したりはしないこと （どうしても一時的に貸さなければならない場合はゲストアカウントを使用し、目の届く範囲で使用させること）。
カフェなど、複数の人間が周囲にいる状況で会社やクライアントの重要な情報が記載されたファイルを開くことを禁止する。また、公衆無線 LAN など、安全でないネットワーク上において、さらに通信が暗号化されていない状況で重要なファイルをメール送信したり、受け取ったりしないこと。
業務で使用する Google Apps、Dropbox など Web サービスは 2 要素認証を必ず有効にすること。また、使用するパスワードは最低でも 16 桁、できれば 32 桁以上の強固なものを設定し、他サービス間での同じパスワードの使い回しは堅く禁じる。
また、パスワードを平文でメール送信することは禁止。リモートで送付する必要がある場合は、チャット・プロジェクト管理ツール上など、関係者以外がアクセスできない場所で投稿、あるいは送信すること。ファイルの閲覧に受取手のログインが必須な設定であれば、Google ドライブや、Dropbox などの共有ドライブサービスを利用することも可能。
また、「パスワードを伝達する」 という目的を果たしたら、なるべく早めにファイルや投稿を削除し、いつまでもパスワード情報が放置されたままにしないこと。
パスワード情報などを誰でも閲覧可能な場所に保存したりはしないこと。各自の手元でパスワードを管理する場合は、パスワード管理ソフトを使用し、適切に管理すること。
クライアントから提供された機密情報は、担当者の責任において厳重に管理する。
また、紙で提供された情報は、不用意に書類ケースに放置したり、シュレッダーにかけずに廃棄したりするようなことがないように注意すること。
Dropbox をはじめとした、データを外部サーバに預けるサービスの利用に関しては、2 要素認証を行うなど、セキュリティの要件を満たしていれば特に制約はしないが、クライアントとの業務委託契約、あるいは機密保持契約の内容が優先される。
使用する場合でも、クライアント関連のデータは暗号化して保存するなど、データの取り扱いには注意すること。なお、機密情報と文書または口頭にて明示されたデータのクラウドサービスへのアップロードは原則として禁止する。
映像、写真、音楽など、他者が創作したものを Web サイトで使用する場合は著作権の侵害を行わないよう十分に注意すること。映像や音楽等、他者が創作したものを公の場で利用する場合は、原則として創作者に対する利用許諾が必要なため、クライアントから提供された素材だとしても、必ず著作権の問題がクリアされているかを確認の上、使用する。
その他、フレームワークやライブラリをはじめとしたプログラムのソースコード等、ライセンスに則った適切な利用を行うこと。詳しくは ライセンスのセクション を参照。
案件で使用する JavaScript （jQueryプラグイン等）、CSS （Normalize.css等）、アイコンライブラリのライセンスは必ず確認し、ライセンスの元に正しく使用すること。また、ソースコードに記載されたライセンス表記は削除しないように注意すること。
ビルドツールなどを使用する場合にコメントの自動削除が適用されてしまう場合があるので /*! ... */ 形式のコメントになっていることを確認する。
なお、リンクツール （利用にあたり、作者ページへのリンクが必須のライブラリ等） は使用不可とする。
Web サービスなど、ブランドロゴをバナーやボタンに使用する際は、各ブランドロゴの利用規約、ガイドラインを必ず確認し、それに従って利用する事。下記に代表的なブランドロゴの利用規約を挙げる（一部は素材画像やロゴデータのダウンロード時に規約が表示される）。
開発環境については各担当者の裁量で選択することができるが、複数人でのメンテナンス等を考慮し、下記に推奨ツールを記載する。特定のOSに依存するようなツールは使用しないこと。
Sass、もしくは LESS を推奨する。
クライアントと協議の上、問題ない場合は、Tailwind CSS を使用してもよい。
npm-scripts の使用を推奨する。ただし、要件や開発の特性に応じてタスクランナーの使用も可能。その場合は Gulp を推奨。
Git を推奨。リポジトリサービスは GitHub を使用を推奨するが、クライアント案件のソースコードをパブリックなリポジトリには保存しないこと。
React、および Next.js、静的サイトジェネレーターについては Astro.js を推奨。原則として TypeScript を導入すること。
本ガイドラインは、バーンワークス株式会社が行う Web サイト制作全般においての品質を保持するために定めたものであり、当社が本ガイドラインに基づいた Web サイト制作を行うことで、クライアントに対して常に安定した品質の納品物を提供するために策定されている。
本ガイドラインはプロジェクトの開始から納品までの各段階について、プロジェクトメンバーが考慮すべき、または守るべき指標をまとめたものであり、クライアントに対して当社の制作ガイドラインを示す際にも使用される。各プロジェクトメンバーは本ガイドラインに基づいた制作を行い、クライアントに対する一連のサービス提供、及び納品物の品質にばらつきが生じないよう努める必要がある。
なお、本ガイドラインによって策定された内容も、クライアントとの協議の結果、もしくはプロジェクトの円滑な進行、クライアントのビジネスゴール達成のためにより最適な方法がある場合は必ずしも順守する必要はない。ただし、その決断に至った経緯や結果に関しては必ず社内にて情報共有し、必要に応じてガイドラインの改善に役立てるものとする。
就業規則やビジネスマナーに関するガイドライン、パートナー企業・フリーランスに関する規定、及びより細かな情報管理ルール等は別途定めているため、本ガイドラインの対象外としている。
また、コーディングにおいて、HTML や CSS をはじめとした Web 標準技術は W3C の各仕様に基づいて正しく使用することを前提としており、本ガイドライン内のコーディング規則ではその詳細について取り扱わない。
必要に応じて本ガイドラインは適時更新、改訂される。
本ガイドラインのバージョン番号は、
という 3つの番号の組み合わせで構成される。公開版の最初のバージョン番号は、1.0.0 である。
本ガイドラインは、下記のルールに則って、更新、改訂ごとにバージョン番号が変更される。
本ガイドラインの改訂履歴は下記、GitHub 上で確認できる。
本ガイドラインは、下記のライセンスで一般に公開される。
本ガイドラインの HTML ファイル一式は下記から取得可能。