本ガイドラインについて

ガイドラインの目的

本ガイドラインは、ハリマニックス株式会社が行う Web サイト制作全般においての品質を保持するために定めたものであり、当社が本ガイドラインに基づいた Web サイト制作を行うことで、クライアントに対して常に安定した品質の納品物を提供するために策定されている。

本ガイドラインはプロジェクトの開始から納品までの各段階について、プロジェクトメンバーが考慮すべき、または守るべき指標をまとめたものであり、クライアントに対して当社の制作ガイドラインを示す際にも使用される。各プロジェクトメンバーは本ガイドラインに基づいた制作を行い、クライアントに対する一連のサービス提供、及び納品物の品質にばらつきが生じないよう努める必要がある。

なお、本ガイドラインによって策定された内容も、クライアントとの協議の結果、もしくはプロジェクトの円滑な進行、クライアントのビジネスゴール達成のためにより最適な方法がある場合は必ずしも順守する必要はない。ただし、その決断に至った経緯や結果に関しては必ず社内にて情報共有し、必要に応じてガイドラインの改善に役立てるものとする。

本ガイドラインで扱わない内容

就業規則やビジネスマナーに関するガイドライン、パートナー企業・フリーランスに関する規定、及びより細かな情報管理ルール等は別途定めているため、本ガイドラインの対象外としている。

また、コーディングにおいて、HTML や CSS をはじめとした Web 標準技術は W3C の各仕様に基づいて正しく使用することを前提としており、本ガイドライン内のコーディング規則ではその詳細について取り扱わない。

ガイドラインの改定

必要に応じて本ガイドラインは適時更新、改訂される。

バージョン ナンバリングのルール

本ガイドラインのバージョン番号は、

  • [メジャーバージョン番号].[マイナーバージョン番号].[リビジョン番号]

という 3つの番号の組み合わせで構成される。運用版の最初のバージョン番号は、1.0.0 である。

本ガイドラインは、下記のルールに則って、更新、改訂ごとにバージョン番号が変更される。

  1. メジャーバージョン番号は、大幅な構成の変更など、前バージョンと別のドキュメントとして扱うのが妥当なほどの変更が行われた場合に 1 ずつ増加する。
  2. マイナーバージョン番号は、項目、項目内のセクションの追加が行われた場合に 1 ずつ増加する。
  3. リビジョン番号は誤字脱字の修正や文章の軽微な修正などが行われた場合に 1 ずつ増加する。メジャーバージョン番号、またはマイナーバージョン番号が変更された際は、0 にリセットされる。

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

基本

ディレクターはクライアントから指定の Web サイト要件を満たし、Web サイトのビジネスゴールを達成するため、適切な情報提供、提案を行う。また、Web サイトの情報設計からプロジェクトの進行管理、プロジェクトメンバーの業務管理、納品物の品質管理を適切に行うものとする。

ディレクターはクライアントを含めプロジェクトメンバー間でのコミュニケーションを積極的に取ることで円滑なプロジェクト進行を心がける。また、クライアントに対しては進捗の報告、情報共有を適時、および明確に行い、信頼関係の構築に努める。

プロジェクトキックオフ

新規 Web サイト制作案件立ち上げに際して行われるキックオフミーティングについては、下記の要領を基本として開催する。特に社内キックオフは必ず行うこと。

クライアントと行うキックオフ

クライアントとの間では現状の把握、ゴールイメージの共有、プロジェクト進行におけるスケジュールを含めた認識の共有を主な目的とする。

  • プロジェクトの要件確認
    • 求められる動作環境や検収条件などの確認
    • 納品物の内容や納品形態についての確認
    • 開発言語、環境の指定やその他要件の確認
  • プロジェクトの対象となる Web サイト等のユーザー層、ターゲット層の理解(必要に応じて下記を実施)
    • ユーザーのセグメンテーションペルソナ
    • ユーザーインタビュー
    • カスタマージャーニーマップ
    • 既存 Web サイトが存在する場合はその分析
      • アクセスデータ解析
      • ヒューリスティック評価
      • ユーザビリティテスト
  • クライアントビジネスの理解
  • スケジュールの共有
  • 議事録の作成 (決定事項等は「ヒアリングシート」にまとめ、社内のプロジェクトメンバーと共有する)

社内キックオフ

また、社内のプロジェクトメンバー間においては、次の項目を目的とする。

  • 現状の把握
  • ゴールイメージの共有
  • スケジュールの共有
  • 要件の確認に伴い、事前の意見交換
    • これは例えば
      ・「事前に実装担当者、デザイナー、プログラマが知っていればもっと効率よくやる方法があった
      ・「こうしておいてくれればもっと作業がしやすかった
      といった無駄をなくすことで、生産性を高め、納期の短縮や品質の向上でクライアントに還元する。
  • プロジェクトの要件確認
    • 求められる動作環境や検収条件などの確認
    • 納品物の内容や納品形態についての確認
    • 開発言語、環境の指定やその他要件の確認
  • プロジェクトの対象となる Web サイト等のユーザー層、ターゲット層の理解
  • 既存 Web サイトが存在する場合はその分析結果の共有
  • クライアントビジネスの理解
  • スケジュールの共有
  • 議事録の作成

社内プロジェクトメンバーのアサイン

社内におけるプロジェクトメンバーのアサインはディレクター(設置している場合はプロマネ)権限で行う。ただしリソース管理の観点から、Web 制作事業の責任者への報告を怠らないこと。またWeb サイト制作事業の責任者が独自判断でメンバーをアサインしたりすることは禁止する。

守秘義務契約、及び業務委託契約を結んでいない外部の個人事業主、及び企業へのプロジェクト情報の開示や作業の依頼は当然ながら一切禁止する。

ドキュメント

制作過程でディレクターが作成する標準的なドキュメントは下記の通りとする。フォーマットは問わないが、クライアント環境で問題なく閲覧ができること。当然、プロジェクトに応じて必要なドキュメントは変化する。

  • ヒアリングシート (キックオフミーティング時に確定した内容などをまとめたもの)
  • スケジュール案
  • サイト構成図
  • ワイヤーフレーム
  • wordpress など導入プロダクトの操作マニュアル(状況に応じて)

wordpress など導入プロダクトのマニュアルに関しては通常作成不要。開発元の公式ドキュメントがある場合はそれで代用できる。

例えば wordpress の場合、カスタムフィールドを用いた特殊な入力画面をクライアントに提供するなど、開発元が提供する公式ドキュメントでは対応できない場合などに、簡易なものを作成する前提とする。

プロジェクト進行における連絡手段

プロジェクト進行中のクライアントを含むプロジェクトメンバーとの連絡・情報共有の手段は、基本的にチャットワーク(https://chatwork.com)を利用する。プロジェクトのキックオフがされた後、ディレクターによってチャットワークグループの開設が行われ、プロジェクトメンバーが招待される。

クライアントの要望や、プロジェクトの特性、要件に応じて、連絡・情報共有用のツールは最適なものを選択できる。ただし、情報管理の観点から、使用ツールの選定はクライアント、および当社の情報管理ポリシーに基づき行う他、連絡の内容がすべて、ログとして長期にわたり保存され、後から検索可能なツールを選択すること。

アクセシビリティ

設計段階からアクセシビリティに配慮する。詳細な準拠レベルや内容については、デザイン関連 > アクセシビリティに記載する。

以下に記述する内容は準拠レベルに関わらず、Web制作において一般的に配慮すべきと考えるポイント。

例えばカルーセルパネル(数秒ごとに画像や要素がスライド等で差し替わる UI )は数秒間で要素内に記述されたテキストを把握できない可能性や要素が切り替わるまでの間に正しく操作できない可能性もあり、重要なナビゲーション機能をカルーセルに持たせるべきではないと考える。

あるいはナビゲーション機能を持たせるのであればカルーセルパネルの動作を一時停止できる仕組みを持たせるなど配慮が必要である。

また、色に依存したナビゲーション、文章の使用は禁止する。例えば「下記の赤い方のボタンを押してください」「文章内の赤い文字は重要項目です」などの表記、あるいは色を選択させるような際にカラーパレットのみで色名のラベルがない等の UI は、一部の色覚障がい者にとっては認識できない可能性がある。UI や文章作成時には配慮するものとする。

基本

  • 各ページにはページの内容を推測しやすい適切なタイトルを必ず付けること。ページ分割等を行う場合も、(1/2ページ)などとページ数表記を入れるなどして、ページタイトルは Web サイト内で重複しないようにすること
  • <meta name="description" /> に関しては、主要なページでは設定しておく事。その際、重複が発生しないように注意。主要でないページで description が重複するくらいであれば最初から記述しない事。
  • <meta name="keywords" /> に関しては特にクライアントからの指定がない限り省略しても構わない。あるいはトップページのみ記述するなどでよい。
  • 画像には適切な代替テキストを付与する。代替テキストは、画像の内容を具体的に示すものとする(下記サンプル 1)
  •     <!-- サンプル 1 -->
        <img
            src="photo.jpg"
            alt="熱海に行ったときに撮影した写真。海をバックに白壁の民家とペットの黒猫が写っています。"
         />
        
  • JavaScript が無効な環境を常に配慮すること。アコーディオンメニューなど、JavaScript によって開閉するような UI については、JavaScript が無効だった場合には開いた状態になるなど、重要な操作が JavaScript の無効によって不可能になるような実装は行わない。
  • リンクアンカーとなるテキストは適切に選択すること。アンカーテキストに制約がある場合は、title 属性を併用すること (下記サンプル 3)。
  •     <!-- サンプル 3 非推奨 -->
        資料のダウンロードは<a href="/dl/">こちら</a>から
        
        <!-- サンプル 3 推奨 -->
        <a href="/dl/">資料のダウンロードはこちらから</a>
        
  • PDF ファイルなど、HTML 以外のフォーマットへのリンクを提供する場合は、そのリンク先のフォーマットやファイルサイズがわかるようにしておくことが望ましい。

また、ある要素 (例えばナビゲーションなど) の位置固定表示 (e.g. position: fixed;) を行う場合は、特にスマホ画面等サイズが小さいときなどに画面外に要素がはみ出して閲覧できなくなるなどの可能性を十分に配慮する。

操作性

特別、スマートフォン等、画面サイズの小さいデバイスへの対応を行わない場合でも、マルチデバイスで操作しやすい UI を意識して設計する。「スマートフォンサイトではないのでスマートフォンでの操作が困難でも仕方ない」ということはない。

文字サイズの変更ボタン

Web ページ内の文字サイズ変更を Web サイト側で提供する所謂「文字サイズ変更ボタン」の提供は原則として行わない。文字サイズの変更はブラウザ UI に任せるべきで、必要であれば操作方法をヘルプページ等に表記するものとする。

ページタイトルやURL

各ページにはページの内容を推測しやすい適切なタイトルを必ず付けること。
ページ分割等を行う場合も、(1/2ページ)などとページ数表記を入れるなどして、ページタイトルは Web サイト内で重複しないようにすること

各ページのタイトル、およびディレクトリ名やファイル名はディレクターが実装担当に指示すること。実装担当者が勝手に決めたりはしない。

ページ一覧(各ページタイトルや URL を記載した)をワイヤーフレームと同一ファイル内などに作成し、実装担当者はそれを基準に各ページを作成する。

必要に応じて、ページ内に記述する <meta name="description" /> の値なども決められる場合は記述しておく。

なお、この一覧に CSS や JavaScript 等、ページで読み込まれる各リソースのパス指定などは不要(これらに関しては別途 コーディング関連のセクション で定める)。

文言の統一

案件の状況やクライアントの要望により異なるものの、コーディングにおいて原則的に下記のように Web サイト内で使用する文言を統一する。表記のブレによる品質の低下を防ぐ。

特にクライアントからの明確な指定がなく、迷ったときは、例えば下記を参考に統一する。

  • Webサイトのトップページに移動するリンクのラベル: ホームHOME (×トップページ、×ホームページ、×トップ)
  • ページ上部に移動するページ内リンクのラベル: このページの上部へPage Top (×ページトップ、×トップ)
  • お問い合わせContact (×お問合せ、×お問い合せ)
  • メールアドレスE-mail (×Mailアドレス、×アドレス、×email)
  • 英数字は原則半角とし、URLや数値・英単語を全角で記述しない
  • 文章内の全角スペースは半角に統一

その他、サイト内で複数の文言が混在しないように注意すること。

  • 例)弊社|当社、貴社|御社、お客様|クライアント、~します|~いたします ...etc

表記の統一ルールについては、別途策定予定の「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 で収集したアクセスログに関するプライバシーポリシーについては、下記をご確認ください(外部サイト)。

上記サンプル文章は、下記ページの内容を参考にしたもの。

サーバや外部サービスの契約

クライアントから新規のサーバ契約やその他外部サービス(ドメイン取得等)の利用を求められた場合は、当社にてその選定や申し込みを行うなど、最大限協力するものとする。 レンタルサーバは当社契約のエックスサーバービジネス エンタープライズプランのマルチドメインを割り当て、ドメイン取得にはお名前.comの利用を原則とする。ただし要件を満たさない場合には都度適切な手段を選択する。

デザイン関連

基本

  • 背景色と文字色には適切なコントラスト比を持たせる。
  • ブラウザによる文字サイズの変更が可能なように実装すること。また、10px 以下のサイズの文字は重要でない注釈等を除いて原則として使用しないことが望ましい。
  • リンク領域、ボタンのサイズ等は適切なサイズを考慮すること。また、各リンクのマージンは適切にとり、誤クリックを誘発するような実装は行わないこと。
  • PDF ファイルなど、HTML 以外のフォーマットへのリンクを提供する場合は、そのリンク先のフォーマットやファイルサイズがわかるようにしておくことが望ましい。
  •     <!-- サンプル 3 非推奨 -->
        資料のダウンロードは<a href="/dl/">こちら</a>から
        
        <!-- サンプル 3 推奨 -->
        <a href="/dl/">資料のダウンロードはこちらから</a>
        

また、ある要素 (例えばナビゲーションなど) の位置固定表示 (e.g. position: fixed;) を行う場合は、特にスマホ画面等サイズが小さいときなどに画面外に要素がはみ出して閲覧できなくなるなどの可能性を十分に配慮する。

  • アニメーションを採用する際には、必ずディレクター及び実装担当者と相談する。

アクセシビリティ

デザイン時にもアクセシビリティに配慮すること。

配色について

背景色とテキストのコントラスト、色覚障がい者向けの配色等に考慮する。JIS X 8341-3:2010 における該当箇所は下記引用の通り。

7.1.4.3 最低限のコントラストに関する達成基準

テキスト及び画像化された文字の視覚的な表現には、少なくとも4.5:1 のコントラスト比がなければならない。ただし、次の場合は除く。

a) 大きな文字
サイズの大きなテキスト及びサイズの大きな画像化された文字には、少なくとも3:1のコントラスト比がある。

注記 サイズの大きなテキストとは、半角の英数字の場合,少なくとも18 ポイント又は14 ポイントの太字であり、日本語、中国語及び韓国語のフォントでは、それと同等の文字サイズである。日本語を含む場合、少なくとも 22 ポイント又は 18 ポイントの太字と考えるとよい。

b) 附随的
テキスト又は画像化された文字において、次の場合はコントラストの要件は該当しない。アクティブではないユーザインタフェースコンポーネントの一部である、装飾だけを目的にしている、だれ(誰)も視覚的に確認できない,又は重要な他の視覚的なコンテンツを含む写真の一部分である。

c) ロゴタイプ
ロゴ又はブランド名の一部である文字には、コントラストの要件はない。

JIS X 8341-3:2010「7. ウェブコンテンツに関する要件」から引用

コントラストのチェックに関しては、下記のツール等を推奨。

フォントサイズやボタンサイズ

フォントサイズは、ベースサイズを 14px、最小サイズを 12px 相当とする。ただし、重要でない注釈等に関しては 10px 相当まで許容する。現在のディスプレイサイズ等を考慮すれば、標準的なフォントサイズは本文で 14px 相当~ 16px 相当が妥当と考える。その他、ボタンサイズ等については タッチデバイスのセクション を参照。

デザインデータ

基本的には Adobe 社の XD を使用して作成するものとする。利用バージョンは Adobe CC を推奨するが、必須ではない。ただし、できる限り最新バージョンのソフトウェアを使用し、プロジェクトメンバー間でのデータ互換性による作業遅滞を避けるよう努めること。

デザインデータは、XDの機能(文字スタイル、カラー、コンポーネント等)を設定し、実装担当者が迷わないよう配慮する。

ディレクター、およびデザイナーはデザインの進行、確定にあたり、実装面からの意見を必ず実装担当者に聞くこと。それにより実装時になってデザインの不具合により手戻りが発生するなどの無駄を省き、実装面の負荷を低減する。

また、図版等によっては、SVG での書き出しを考慮し、Illustrator や XD による作成を推奨する。

デザインデータはクライアントに納品されることを想定して作成するものとし、レイヤーの分け方や名前の付け方など、他の人が見てもわかりやすいように配慮すること。これは実装担当者の作業効率も向上させる。

基準とするスタイル

当社のWEB制作においての基準値を下記とする。ただし案件ごとデザインごとに適切な設定を怠らない。

テキスト font-size: 14px;
letter-spacing: 0em;
line-height: 1.6;
フォント(ゴシック) font-family: "Lucida Grande", "Hiragino Kaku Gothic ProN",
"メイリオ", Meiryo, sans-serif;
フォント(明朝) font-family: "游明朝", YuMincho, "Times New Roman",
"ヒラギノ明朝 ProN W3", "Hiragino Mincho ProN", "HG明朝E",
"MS P明朝",
"MS PMincho", "MS 明朝", serif;
リンクテキスト
:hover
:visited
:active

画像素材のライセンス

画像の著作権には十分配慮し、著作権、モデルリリース等の権利関係がクリアされていない、あるいは明確にされていない画像素材の使用は一切禁止する。また、画像の使用にあたり、提供元サイトへのリンクが必須の素材 (所謂リンクツール)、およびサービスの利用も禁止とする。

素材として使用する画像のライセンスは、原則として「ロイヤリティフリー」のものとする。ただし、クライアントの許可を得た上で、画像素材を購入することは問題ない。ライセンスの種別、用途、期間、その他制限については十分に確認し検証の上、使用すること。

SVG

アイコン、簡単な図版などに関しては、SVG の使用を推奨する。Illustrator や XD でデータを作成し、SVG での書き出しは実装担当者が行う。実際のデザイン上での表示サイズなどはデザインデータ内で明確に指定すること。

長いテキストの可読性など

行間や行長

Web ページ内に表示するテキストの行間は 150〜190% (line-height: 1.5;line-height: 1.9;)の値となるように調整する。

1行あたりの文字数 (行長) は、最長で 30~40 文字程度になるよう調整することが読みやすさの点から望ましい。

上記はデザインの要件や文字サイズ等によって変動、もしくは Web ページを閲覧する環境に依存するため、あくまで基準とするが、1行あたりの文字数が極端に多すぎる場合、逆に少なすぎて改行が多すぎる場合などは可読性を低下させるため注意が必要。

デバイスフォントの利用

Web サイトのパフォーマンス、メンテナンス性や CMS の利用も考慮し、テキストの不要な画像化は避ける。

画像処理が適当である箇所を除いては、なるべくデバイスフォントを使用する前提でデザインすること。また、デザインデータ内では、画像処理すべきテキストとそうでないものが実装担当者にわかるよう、指示レイヤーに記述する。

Favicon

新規構築の Web サイトに関して、デザインには Favicon のデータも含めること。既存のデータがある場合はそれを使用する。サイズは最低限、下記を実装担当者が生成する前提でデザインを用意すること。基本的にはすべて同じデザインとするため、最小サイズでも認識しやすいようにデザインする。

  • favicon.ico (16x16px, 32x32px, 48x48px)
  • favicon.png (64x64px)
  • apple-touch-icon-152x152.png (152x152px)

実装担当者は上記サイズの画像をデザイナーのデータを基に生成する。例えばビルドツールを使用する場合、下記などがある。

スマートフォン関連

基本

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

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

タッチデバイス

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

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

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

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

ブレイクポイント

要件説明時に特別な指定がないレスポンシブ Web デザイン対応案件では、以下を基準にブレイクポイントを設定する。

  • スマートフォン: ~767px
  • タブレット: 768px~1199px
  • PC: 1200px~

スマートフォンの最小画面サイズは横幅 375px とし、767px までの間は横サイズの可変で対応する。
この間の画面サイズによってレイアウトが変わるような指定は禁止。

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

高精細ディスプレイ対応

所謂 Retina 対応。

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

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

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

Retina 対応はマストで行う。ただし、画像のファイルサイズ増加に十分注意すること。

コーディング全般

基本

納品は、HTML、CSS、JavaScript 等ファイル、及び画像を含む、Web サイトを構成するリソース一式を、クライアントサーバにアップロードした状態とする。

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

ファイル名の基本ルール

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

  • 区切り文字はアンダースコア (_) を使用する。
  • 大文字小文字を混ぜず、すべて小文字で付ける。
  • 同じ種別のファイルは頭に同じ接頭辞を付ける。例えば、バナー関連なら bnr_ など。
  • 接頭辞リスト
    • アイコン:icon_
    • テキスト:text_
    • 背景画像:bgimg_
    • バナー:bnr_
    • その他の画像:img_
  • スマホ用画像がある場合には、スマホ版の末尾にアンダースコア・アイ (_i) を付ける (例: bgimg_header_001_i.png)。
  • 同じカテゴリ・役割などグルーピングされるべき画像群には、末尾をアンダースコアで区切り、2ケタ以上の連番を付ける (例: bnr_footer_01.png)。
  • 同じ内容の画像でサイズが異なる場合はサイズを入れたり (例: example_200x50.png)、デバイスピクセル比を入れたりしてわかりやすくする (例: example_x2.png)。
  • ファイル名には画像そのものの説明ではなく、サイト内での役割を付けると運用しやすいと考える (例: bgimg_header.png)。
  • ※CSSスプライトは非推奨とする。
  • ※画像ファイル名が長くなり過ぎないように注意すること。

ディレクトリ構成のルールとあわせて、第三者が見てもわかりやすいファイル名を心がけること。

動作検証ブラウザ

当社が標準で保証する動作環境ブラウザは下記の通りとする。このセクションは 毎年4月・10月に見直される

パソコン(Windows 11)

  • Microsoft Edge 最新版
  • Mozilla Firefox 最新版
  • Google Chrome 最新版

パソコン(Mac OS 13.0)

  • Mozilla Firefox 最新版
  • Google Chrome 最新版
  • Safari 最新版

スマートフォン

  • iOS Safari 最新版 (iOS 15 以降)
  • iOS Chrome 最新版 (iOS 15 以降)
  • Android 11 標準ブラウザ(Chrome)

なお、Android OSのバージョンは、グローバルなシェアデータ及び当社規定に基づいて選定している。

その他

ヘルプページ等に対応ブラウザ(推奨環境)を記載する場合は、上記動作検証ブラウザを踏まえ、下記の記述を基本とする。

JavaScript、スタイルシート、画像表示が有効になっている下記のブラウザソフト

  • Microsoft Edge 最新版
  • Mozilla Firefox 最新版
  • Google Chrome 最新版
  • Safari 最新版(Mac OS X)

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

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

HTML コーディング -> アクセシビリティのセクション や、JavaScruipt -> 基本・バリデーションのセクション 等もあわせて参照のこと。

文字コード

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

インデントルール

インデントを行う場合、タブ文字は使用しないこと。エディタの設定等で 1タブ = 4半角スペース に設定し、1階層の字下げは 4半角スペースを基準とする。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 の要素名・属性名は、原則として小文字で統一すること。ただし、IDEの機能により出力されるコードを書き直す必要はない。また、画像をはじめとしたファイル名などでも大文字小文字を混在させたりしないこと。

    <!-- 非推奨 -->
    <A HREF="/sample/"><IMG SRC="sampleImage.png" ALT="Sample" /></A>
    
    <!-- 推奨 -->
    <a href="/sample/"><img src="sample-image.png" alt="Sample" /></a>
    

クラス名 及び 変数名は以下のルールに則り、指定すること。

  • CSS用のHTML クラス名:ケバブケース(ハイフンによる単語の接続)
  • JS用のHTML クラス名:ローワーキャメルケース(頭文字小文字 かつ 単語の接続は大文字)
  • JS内の変数名:ローワーキャメルケース(頭文字小文字 かつ 単語の接続は大文字)
  • JS内のオブジェクトクラス名:アッパーキャメルケース(頭文字大文字 かつ 単語の接続は大文字)
    <!-- CSS用のHTML クラス名 -->
    <h2 class="main-title"></h2>;

    <!-- JS用のHTML クラス名 -->
    <span class="trigViewMap"></span>;
    
    // JS内の変数名
    const firstName = 'taro';

    // JS内のオブジェクトクラス名
    class AdminUser {}
    

コメント

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

HTML のコメントには <!-- の後と --> の前に半角スペースを入れること。

HTML において、要素の閉じタグを認識するためにコメントを入れる場合は、下記のように「/」に続けて該当する要素の class 名、id 名を記述するルールに従う。

    <div class="example" id="example">
        <p>...</p>
    <!-- /.example #example --></div>
    

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

viewport

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" />
    

などと数値を指定して記述する。

スキームの記述

外部 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 ライブラリやフレームワーク・API の利用はプロジェクトの要件に応じて選択可能。ただし、使用するライブラリやフレームワーク・API に関してはメンテナンスが継続されていること、バグフィックスや脆弱性への対応等が、過去きちんと行われていることを重視して選択すること。

HTMLコーディング

基本・バリデーション

基本的な考え方

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

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

基本的に class で CSS を書くようにし、 id 属性は適切に使用すること。セレクタとしての利用も特に制限しないが、多用しすぎてメンテナンス性や再利用性が妨げられてはならない。

バリデーション

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

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

アクセシビリティ

最低限、下記の事柄についてはクリアすること。

  • 各ページにはページの内容を推測しやすい適切なタイトルを必ず付けること。ページ分割等を行う場合も、(1/2ページ)などとページ数表記を入れるなどして、ページタイトルは Web サイト内で重複しないようにすること
  • 画像には適切な代替テキストを付与する。代替テキストは、画像の内容を具体的に示すものとする(下記サンプル 1)
  •     <!-- サンプル 1 -->
        <img
            src="photo.jpg"
            alt="熱海に行ったときに撮影した写真。海をバックに白壁の民家とペットの黒猫が写っています。"
         />
        
  • 文字間隔の調整を空白文字を用いて行ってはならない
  • 背景色と文字色には適切なコントラスト比を持たせる。
  • ブラウザによる文字サイズの変更が可能なように実装すること。また、10px 以下のサイズの文字は重要でない注釈等を除いて原則として使用しないことが望ましい。
  • 文字サイズ変更ボタンを Web ページ側で独自に提供しないこと(ブラウザの UI に任せる)。
  • リンクアンカーとなるテキストは適切に選択すること。アンカーテキストに制約がある場合は、title 属性を併用すること (下記サンプル 3)。
  • リンク領域、ボタンのサイズ等は適切なサイズを考慮すること。また、各リンクのマージンは適切にとり、誤クリックを誘発するような実装は行わないこと。
  • PDF ファイルなど、HTML 以外のフォーマットへのリンクを提供する場合は、そのリンク先のフォーマットやファイルサイズがわかるようにしておくことが望ましい。
  • フォームコントロールは、label 要素を適切に用いてラベルとの関連づけを行うこと。
  • キーボードによる操作を考慮した実装を行うこと。
  •     <!-- サンプル 3 非推奨 -->
        資料のダウンロードは<a href="/dl/">こちら</a>から
        
        <!-- サンプル 3 推奨 -->
        <a href="/dl/">資料のダウンロードはこちらから</a>
        

また、ある要素 (例えばナビゲーションなど) の位置固定表示 (e.g. position: fixed;) を行う場合は、特にスマホ画面等サイズが小さいときなどに画面外に要素がはみ出して閲覧できなくなるなどの可能性を十分に配慮する。

文書型宣言

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

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

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

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

要素や終了タグの省略

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>
    

セマンティクス(役割 / 意味)

要素の意味と異なる動作を与えたりしないこと。例えば 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 や JavaScript ファイルの読み込み

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

一時的なお知らせなどいずれ削除される要素は、要素の削除時に不要なCSSの消し忘れを防ぐため、インラインスタイルの記述を推奨する。

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 属性はスクリプトの依存関係等によって正常に動作しなくなる場合があるため、スクリプトの動作を優先してよい。

パフォーマンスのセクション もあわせて参照のこと。

type 属性

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/1.11.1/jquery.min.js"
     type="text/javascript"></script>
    
<!-- 推奨 -->
    <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
    

メタデータや OGP

メタデータ

<meta name="description" /> に関しては、主要なページでは設定しておく事。その際、重複が発生しないように注意。主要でないページで description が重複するくらいであれば最初から記述しない事。

<meta name="keywords" /> に関しては特にクライアントからの指定がない限り省略しても構わない。あるいはトップページのみ記述するなどでよい。

OGP

トップページに関しては原則として 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 を指定しないこと。HTML5 においては、#top を指定することで自動的にページ上部へのリンクとして機能する。
※スムーススクロールを採用の場合で #top を指定した場合、アニメーションは行われない。

    /* 非推奨 */
    <a href="#top">このページの上部へ</a>
    

SVG

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

CSSコーディング

基本・バリデーション

基本的な考え方

セレクタは必ず class で指定し、 id は使わない。また、class名は必ず小文字でケバブケース【"-"(ハイフン)による連結】とする。不可逆な省略は行わないこと。

    /* 非推奨 */
    .mi {...}
    .main_image {...}
    
    /* 推奨 */
    .main-image {...}
    

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

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

以上の理由より、CSS コーディングには BEM(Block Element Modifier) 規則を採用する。

    /* 非推奨 */
    .block-header ul.block-main-nav li a {...}
    
    /* 推奨 */
    .header__navi__link {...}
    

ベンダプレフィックスは、コーディング時に最新となる各ブラウザのバージョンから、2 世代前を基準に、有無を判断する。また、仮にサポートするブラウザが存在しない場合でも、必ず標準仕様に基づいた記述も併記すること。

記述は以下を基準とする。

-webkit-*****: #####;
-moz-*****: #####;
-ms-*****: #####;
-o-*****: #####;
*****: #####;

フォーマット

  • CSSは宣言ブロック部分に必ずインデントを入れること。
  • セレクタと "{" の間には半角スペースを1つ入れる。さらに、プロパティと ":" は続けて記述し、その後ろに半角スペースを1つ入れた上で、値を記述する。
  • すべての宣言ブロック末尾には ";" を付与すること。
  • 規則集合ごとに1行改行を入れて記述する。
  • 複数のセレクタをカンマ区切りで記述する場合は、セレクタごとに改行する。
  • プリプロセッサやビルドツールによる最終納品物からの改行やインデント等の自動削除は問題ない。
    /* 非推奨 */
    .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 検証サービスによるバリデーションを行うこと。特にスペルミスや記述ミスは確実にチェックし、排除すること。プリプロセッサやビルドツールを用いたバリデーションでも構わない。

スタイルシートのリセット

デフォルトスタイルシートのリセットには _reset.scss を @include して使用する。
ただしこれは随時改変されていく。

デフォルトスタイルシート

デフォルトスタイルシートのノーマライズは _default.scss を @include して使用する。
ただしこれは随時改変されていく。

BEM命名規則

セレクタとなる class 属性名は、BEM 命名規則を用いること。単語の連結にキャメルケースは用いず、"-"(ハイフン)による連結を原則とする。

BEM とはBlock、Element、Modifier の略でWebサイトのコンポーネント化のためのフロントエンド設計方法のひとつで、厳格なclass名の命名ルールが特徴的な手法。

  • 親子関係が変わる場合には "__"(アンダーバー2つ) で連結する
  • 親子関係が変わらないバージョン違いなどには "--"(ハイフン2つ) で連結する
  • 単純な単語の連結には "-"(ハイフン1つ) を用いる。

本来の BEM では親子関係には必ず "__" を追加するが、構造ルールを設定することでその煩雑さを回避する。構造ルールは以下を基準とする。

  • 例 1)
  • .aaa
  • .aaa__block
  • .aaa__boxes
  • .aaa__box
  • 例 2)
  • .aaa__box__lists
  • .aaa__box__list  .aaa__box__list--title
  • .aaa__box__list  .aaa__box__list--body
  • .aaa__box__list__info
  • .aaa__box__list__info  .aaa__box__list__info--tel

※BEM 自体が過渡期の規則なので、デザインによりブロック名を加えるまたは減らして最適なソースコードを目指すことを怠ってはいけない。

    /* 非推奨 */
    .blockHeader {...}
    .mainNavigation {...}

    .red {...}
    .h1 {...}
    
    /* 推奨 */
    .header {...}
    .header__navi {...}

    .navi {...}
    .navi__box {...}

    .navi__box__btn {...}
    .navi__box__btn--01 {...}
    .navi__box__btn--02 {...}
    .navi__box__btn--03 {...}

    .navi__lists {...}
    .navi__list {...}

    .header__logo {...}
    .header__logo__img {...}
    

ショートハンド

ショートハンドプロパティは無理に使用しないが、可能な場合には積極的に使用する。

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

@media 規則

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

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

単位などの省略

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

    margin: 0;
    padding: 0;
    

リンクの文字色は、: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 の指定

ゴシック体を基本とする通常の font-familyプロパティの指定は下記を標準とする。

    body {
        "Lucida Grande", "ヒラギノ角ゴ ProN W3", "Hiragino Kaku Gothic ProN", "メイリオ", Meiryo, sans-serif;
    }
    

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

    .font-family-min {
        font-family: "ヒラギノ明朝 ProN W6", "HiraMinProN-W6", "HG明朝E", "MS P明朝", "MS PMincho", "MS 明朝", serif;
    }
    

z-index の値

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

  • 使用可能な数値の範囲: 0~5000 まで、100 刻み を基本とする。
    • 100 刻みとする理由はメンテナンス等でどうしても既存要素の中間となる値(10刻み推奨)を指定しないといけなくなった場合に備えて。
  • スタート数値はある要素群の役割ごとに変えてもよい。例えばロールオーバーする要素は 1000 番台から始めるなど。
  • オーバーレイなど、確実に他の要素より上部に表示されないと困る要素群に対しては 4000 以上の値を指定する。
  • 大規模サイトで上記ルールでは数値が足りなそうなことが想定される場合はこの限りではない。

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

Web フォントやアイコンフォントの利用は可能。特にアイコンフォントに関しては、Font Awesome を推奨し、2021年12月現在の Font Awesome の推奨バージョンは「 5 」とする。

現行バージョンに注意し、必ず確認してから使用すること。新しいバージョンを使用する場合は個人だけで判断せず、Webチームで話し合うこと。

1つのサイト内で異なるバージョンを混在させることは禁止とする。

その他、第三者が提供するフォントを使用する場合は、ライセンスのセクション も確認すること。

CSS3 プロパティやセレクタ

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

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

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

CSSハック

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';
    

イベント発火ポイントとなるクラス・IDの命名規則

ホバー要素やクリック要素など、アクションの起点となる要素にはそれとわかる専用のクラス・ID を付ける。クラス・ID 名は CSS スタイルシートに影響しないように気を付けること。

命名規則には lowerCamelCase を用い、特に直接発火ポイントとなるものは trig で始めること。

例えばマップを表示するなどの機能の場合、以下のセットをイメージとする。

#trigViewMap または .trigViewMap
イベントのトリガーとなる要素
#bulletViewMap または .bulletViewMap
イベントの結果が反映される要素
#paramViewMap または .paramViewMap
イベントの判定要素となるパラメーター値を内包する要素
    <div class="map__box" id="map-box">
        hogehoge
    </div>
    
    <div class="map__box" id="trigMapBox">
        hogehoge
    </div>
    
    <div class="map__box trigMapBox">
        hogehoge
    </div>
    

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

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

    if (x) {
        function foo() {}
    }
    

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

    if (x) {
        var foo = function() {}
    }
    

jQuery

jQuery を使用する場合は原則として 3系の最新版を使用すること。jQuery は jQuery より入手し他のソースファイルと同様に読み込む。

    <script src="/js/jquery-3.6.0.js"></script>
    

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

プラグイン

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

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

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

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

jquery-latest.js

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

PHPコーディング

基本

基本的な考え方

操作、および情報の取得に影響する部分については、常にサーバー環境を考慮すること。

Web サーバーのパフォーマンスを重視し、本質的でない不要な処理を入れないこと。

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

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

    $name = $company_name . " " . $user_name . '様';
    
    $name = $company_name . ' ' . $user_name . '様';
    

動作基準サーバー要件

セキュリティの観点より、使用するWeb サーバーの PHP バージョンは、PHP 7.* 以上とする。PHP 5.* 以下の利用及び、その他に選択肢のないサーバーの利用を禁ずる。クライアントの要望がある場合でも、必ず考えうるリスクや工数アップを説明し、リスク管理及びコスト管理を行うこと。

メールサーバーが引っ越せない場合等でも、Webサーバーだけを引っ越すことは可能なため、工夫と提案を怠らない。

ファイル名の基本ルール

ファイル名は原則として、Classファイルには UpperCamelCase を、その他のファイルにはスネークケースを使用する。

特にClassファイルには拡張子の前に ".class" を追加するなどしても良い。

CMS やフレームワークを使用するケースでは、そのお作法に準拠すること。

変数 / 関数の命名規則

変数

通常の変数名は原則として、スネークケースを使用する。

    $name = 'Taro';
    

クラス、インスタンス

クラス名、インスタンス名は原則として、UpperCamelCase を使用する。

    class CustomPost {
     ...
    }
    

関数

関数名は原則として、lowerCamelCase を使用する。

    $MyPost = new CustomPost;
    
    function getListElement() {
     ...
    }
    

定数

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

    define('API_KEY', 'b6lC50HCr4mA');
    

パッケージ管理システム

Composer

Composer を使用する場合は原則としてバージョンを 2.* とすること。

Composer のインストール手順については制約はない。仮想コンテナを使用する場合は、本番環境との整合を考慮することを怠らないこと。

ライブラリ

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

ライブラリの動作を理由に Composer のバージョンを下げることは禁止する。Composer 2.* で動作しないライブラリは利用不可。

CMS

プロダクトの選定

使用するプロダクトはサポート体制、および開発元が定めるプロダクトライフサイクルポリシー(主に旧製品のメンテナンス継続期間や後方互換性の確保に関するポリシー)を考慮する。

オープンソースプロダクトは、クライアントが保守対応可能な部署、人材を自社で持つ場合は問題ないが、そうでない場合はサポートの提供方法について事前に十分配慮する。

「無料」であることを理由にオープンソースプロダクトを選択するようなことはしない。クライアントに対してはプロダクトのサポート体制やプロダクトライフサイクルポリシーについて説明を怠らない。

上記を踏まえ、当社では原則として wordpress を選択肢の第一候補とするが、プロダクト選定はクライアントの要件、ビジネスゴールの達成に対してそのプロダクトが最適であるかが前提となる。

プラグイン

WordPress など CMS のプラグイン利用に特に制限はないが、メンテナンスが継続されていること、脆弱性など、不具合への対応が過去きちんと行われていることを重視して選択すること。

プラグインの動作を理由に CMS のバージョンを下げること、あるいは CMS 本体のプログラムの改変を行うことは禁止する。最新のバージョンで動作しないプラグインは利用不可。

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

Wordpress

インストール

Wordpress のインストールは原則当社が担当する。管理者のメールアドレスは統一していくことが望ましい。(例えば wordpress@harimanics.co.jp )

インストール手順

インストール手順には特に制限はないが、ホスティング独自のサービスや機能がある場合は、その利用を推奨する。

バージョン

Wordpress のバージョンは、原則として使用可能な中で最新のものとする。

サーバー要件を理由に Wordpress のバージョンを下げることは禁止する。

自動更新

Wordpress の自動更新は、解決不可能な事情がある場合を除き、有効にしておくこと。テーマを購入して使用する場合、自動更新による不具合を防ぐ目的で、必ず子テーマで運用すること。

プラグインの自動更新は、基本的には無効とする。メンテナンスが頻繁に行われているなど、ポジティブな条件が揃っていれば、有効としたい。

プラグイン

「セキュリティ」セクションでも触れるが、セキュリティ観点より、「SITE GUARD PLUGIN」に使用を原則必須とする。ただしクライアントから別途要求があった場合はその限りではない。

プラグインのバージョン選択に特に制限はないが、メンテナンスが継続されていること、脆弱性など、不具合への対応が過去きちんと行われていることを重視して選択すること。

Laravel

基本

バージョン

migration

デバッグ

基本

種類と内容

開発者チェック

  • HTML CSS W3C準拠
  • OGP favicon apple-touch-icon
  • title description
  • sitemap.xml
  • 404 存在とリダイレクト
  • Lighthouse
  • Retina対応

ユーザーチェック

  • ひどいレイアウトずれ
  • コンテンツ抜け漏れ
  • リンクチェック
  • テキスト
  • お問い合わせ各ページの存在 入力 確認 ありがとう
  • 意図した挙動(CSS/JS)
  • ブラウザは要件を満たすもの全てでお願い

デバッグ仕様書

  • ディレクター指定の仕様書を使用すること
  • 開発者チェックは外注さんにも依頼する

セキュリティ

強固なパスワード

新規でアカウントを設定する際は推測されにくいアカウント名、および強固なパスワードを設定すること。ただし、外部データ転送サービスを利用する場合などに発行する一時的なパスワードについては、この限りではない。

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

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

乱数の発行には、下記のツールが便利。(※ハリマニックス社員のみ利用可能)
「乱数パスワード生成」https://www.harimanics.co.jp/tools/random_strings/

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

  • admin
  • root
改善案
  • example-admin("example" 部分はクライアントに応じて変えるなど)

不適切なパスワードの例

  • 12345(数字のみ/桁数も不足)
  • companyname(社名そのままなど)
  • 0312345678(電話番号など外部からわかりやすいもの)

強固なパスワードの例

  • oGZ2BL0ZLjl@

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

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

管理画面を持つプログラムへのログインページは、簡単にアクセスできないようにする。方法として、以下の2点を実施する。
・URLに「/wp/wp-admin/」を使用しない。
・プラグイン等を導入する。

SSL の利用

問い合わせフォームなど、個人情報を伴うデータをブラウザ・サーバ間で受け渡すプログラムに関してはその通信を SSL(TLS) で保護する。サーバへの 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 ファイルの読み込みのセクション を参照のこと。

パフォーマンスチェック

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

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

パフォーマンス向上のヒント

以下のセクションで説明する。

画像の最適化

画像は基本的に 透過の必要がなければパフォーマンス向上のため、JPEG形式を使用する。画像の最適化はGulpを用いて行うことを推奨する。必ずファイルサイズの最適化を行う。

Retina対応はマストで行う。ただし、画像のファイルサイズ増加に十分注意すること。

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

CSS の最適化

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

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

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

JavaScript の最適化

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

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

Google タグマネージャ

Google タグマネージャを必ず利用する。Google Analytics のトラッキングコードも Google タグマネージャから配信すれば個別にコードをページに入れる必要はない。(参考記事

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: ヘッダによる指定でもよい。

詳細は下記を参照。

rel=prefetch

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

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

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

詳細は下記を参照。

情報管理体制

基本

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

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

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

外出先での電話

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

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

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

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

SNS やブログ

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

パソコンのセキュリティ

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

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

パスワード等の管理

業務で使用する Google Apps、Dropbox など Web サービスは 2 段階認証を推奨する。また、使用するパスワードは最低でも 10 桁、できれば 13 桁以上の強固なものを設定する。他サービス間での同じパスワードの使い回しは可能な限り避けること。

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

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

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

機密情報の管理

クライアントから提供された機密情報は、制作担当者の責任において厳重に管理し、用件が済み次第すみやかに削除または返却する。

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

クラウドサービスの利用

Dropbox をはじめとした、データを外部サーバに預けるサービスの利用に関しては、10桁以上のパスワードを設定するなど、セキュリティの要件を満たしていれば特に制約はしないが、クライアントとの業務委託契約、あるいは機密保持契約の内容が優先される。

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

Google ドライブ

Google ドライブでの権限設定で、URLを知る全ての人にアクセスを許可することは原則禁止とし、可能な限り特定のユーザーを招待して共有すること。フォルダ単位で共有設定を行うと管理しやすい。

制作フェーズ終了後は必ず速やかに、適切な共有範囲に設定を変更するか、クラウドに残らないようにすること。

その他

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

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

ライセンス

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

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

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

ブランドロゴ等の利用

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

ビルドツール等

開発環境については各担当者の裁量で選択することができるが、複数人でのメンテナンス等を考慮し、下記のツールを強く推奨する。

CSS プリプロセッサ

Sass

AltJS

TypeScript

ビルドツール

gulp

バージョン管理

Git / リポジトリサービスは BitBucket + Source Tree を使用を推奨するが、クライアント案件のソースコードをパブリックなリポジトリには保存しないこと。

変更履歴

Ver1.1.12(2018-07-02) By Akito Kageyama
・プロジェクトメンバーアサインについての規定を変更しました。(
・プロジェクトメンバー進行における連絡手段を Chatwork に規定しました。(
・動作環境確認ブラウザについて見直しました。(
・Javascript における命名規則を追加しました。(
・Grunt の項目を削除しました。(
・ビルドツール(タスクランナー)についての表記を変更しました。(
・変更履歴を追加しました。(

デザイン

画像の最適化

ブランドロゴについて

コーディング

  • スマートフォン OSのバージョン
  • Web Content Accessibility Guidelines (WCAG) 2.0 の、Level A に準拠することを社内基準とする。ただし、Web サイトの特性や要件によっては、Level A 対象となる全項目にわたる準拠を必須とするものではなく、また逆に Level AA、Level AAA 項目を無視してよいということではない。WCAG 2.0 の全項目に関して適切な知識を持って制作にあたる。
  • 8.1.2.4 Optional tags - HTML5
  • Modernizr Download Builder から SVG 判別ライブラリをダウンロード
  • Font Awesome Web フォントやアイコンフォント。特に推奨する。
  • jQuery を使用する場合は原則として 1系の最新版を使用すること。jQuery は jQuery より入手し他のソースファイルと同様に読み込む。
  • jquery-latest.js の使用は禁止する。必ずバージョンを明示して呼び出すこと。(参考記事

テストツール

  • また、納品前の HTML ファイルは、必ず The W3C Markup Validation Service によるチェックを行うこと。特に HTML タグの閉じ忘れといったミスは避ける。なお、バリデーションはビルドツール等によって行っても構わない。
  • W3C CSS 検証サービスによるバリデーションを行うこと。特にスペルミスや記述ミスは確実にチェックし、排除すること。プリプロセッサやビルドツールを用いたバリデーションでも構わない。
  • PageSpeed Insights によるパフォーマンスチェックを必須とする。目安は PC で 85 点以上、モバイルで 80 点以上。
  • Google Developers / モバイルフレンドリーテスト

参考記事

その他