弊社のコーディングおよびデザインについて遵守するガイドラインを定義しております。
目的
・お客様の品質目標を達成するため。
・曖昧な箇所による不具合/速度の低下を未然に防ぐため。
留意事項
・本ガイドラインはお客様からのご指定がない場合に限り有効です。
・ガイドラインと品質指標にそぐわない場合、この限りではございません。
デザイン制作の流れ
認識確認
お客様の実現したい項目についてヒアリングを実施いたします。
お見積り
お客様の要件や用意可能な情報に応じて、お見積りをさせていただきます。
ワイヤーフレーム作成
弊社デザイナーがワイヤーフレームを作成し、大まかな構成についての成果物を提出いたします。
デザインカンプ作成
Adobe XDを使用したデザインの完成形を一度ご確認いただきます。
終了
ご納得いただいた場合、納品またはコーディングのフェーズに移行いたします。
1.認識確認
お客様の課題をヒアリングしてサイトの方向性を決定します。
アクセス数を増やしたい
サイトを見やすくしたい
求職者を増やしたい
LPサイト
Webシステム
ECサイト
コーポレートサイト
2.お見積り
お客様がご用意可能な情報に応じて、見積りの金額が変動いたします。
またコンテンツ数やデザイン制作の有無によっても、お見積り額が変動いたします。
| ライティング（ページに載せる文言など） | 形式は問いません（Excel、テキスト、Word等） |
|---|---|
| 画像 / 動画ファイル / アイコン | 企業ロゴや製品のシンボル、 採用ページ等で使用したい従業員の写真や作業に関連する画像等 |
| 現行のWebサイトやその他が分かる情報 | 使用してほしくない画像や文言などありましたらご教示ください |
| ワイヤーフレーム | CSSテーマやWordPressテーマなど |
Consistency
サイトに統一感があるほど費用が抑えられます
Contents
情報数に応じて価格帯が変動します
Design
ロゴなど、弊社側でオリジナルで制作する場合別途費用がかかります
Responsiveness
対応デバイスが増えると価格があがります ※お安くできる提案もあります
3.ワイヤーフレーム作成
お客様から頂いた情報を元にワイヤーフレームを制作いたします。
目的と定義
・コンテンツの情報を整理し、要件が踏襲できるかの確認をいたします。
・どんなターゲットに対し何を伝えるかを定義します。
・どのような結果を得たいかを定義します。
成果物の定義について
・お客様との認識を揃えることを目的としているため、フォーマット指定しない形を原則とします。
※お客様の指定がある場合はこの限りではございません
4.デザインカンプ作成
方向性が決まったら、デザインカンプを作成いたします。
目的と定義
・本情報を元にコーディングを実施していきます。
・レイアウトやテーマ、コンテンツなどをこちらで詳細に決定していきます。
留意事項
・最終的なレビューについてはコーディングにて決定しますが、レビューの方向性を先に決定させていただきます。
レビュー観点について
ボタンやリンクなどが押下不可
アクション領域が適切なサイズでない
フォーム入力時に入力項目が拡大される
不要な横スクロールが発生する
文字化け/誤字/脱字
目的が達成されているか
・サービスを訪れるユーザーの目的や実施したい項目にマッチしているか。
例：子供向けのサイトであるにも関わらずテキストの漢字使用率が高い等。
UI/UX
・デザイン時点で操作しづらい、見づらい等。
…年齢層やターゲットを加味しての観点となる。
例：「文字が背景色と同化して見づらい。」などは指摘対象となるので文字色を変更するか、影をつけて視認性を高くする等の対応を実施する。
可用性
・ デバイスが異なるケースでも正しくWebサイトが使用可能であるか。
例：動的サイズではない場合は閲覧可能であっても1文字ずつの改行されるケースなどはレビュー指摘対象内とする。
ブランディング
・ブランドイメージに沿っているか。
・ターゲットとデザインがマッチしているか。
実装面での懸念点
・テクニカルな実装についての見積り内での実装が可能なデザインかどうか。
※お客様の要望である場合は対応の判断を実施し、必要である場合は追加でお見積りを提示させていただきます。
コーディングについて
コーディングレビューの方向性について
納品物の定義を双方で揃えるため、方向性について決めさせていただきます。
レスポンシブデザインについて
・タブレットデザインが成果物の対象外の場合、コーディング側で適切に対応いたします。
・SPの横画面は原則として縦幅が短くなります。ボタンやアクションが必要な項目について視認性が悪くなる為、サイズによっては動作保証外とします。デバイスに依存しないもの以外でコンテンツの表示制御の対応はしません。
例：ハンバーガーメニューはSP/Tabletのみ表示→対応
例：SPのみXXXXとテキストと画像を表示する→非対応
ブラウザについて
下記以外のブラウザおよび、スマートフォンアプリを介した際に表示されるブラウザでの表示については動作保証はいたしません。
Google Chrome
Microsoft Edge
Safari(iOS)
Mozilla Firefox
コーディングの品質について
ソースコードの品質について、弊社側で担保すべき事項について明記いたします。
| セキュリティ上問題があるケース |
SQLインジェクションの可能性があるもの XSSの危険性を孕んでいるもの CSRFの危険性を孕んでいるもの その他システム側で脆弱性が高いもの ※仕様の段階で危険性が高い要件と判断した場合は仕様変更、または制作をお断りする可能性がございます。 |
|---|---|
| 著しくパフォーマンスが劣化するケース |
不要/冗長なループの見直し サイズが大きすぎる静的コンテンツの見直し 動作上影響がないシステムの並行・並列処理への修正 ※データの構造上、直列処理しか難しい場合は該当しません |
| 不適切なコーディング |
業務やロジックに関係しないコメント サーバー側の処理が理解できてしまうフロント側のコメント 不適切な変数名
消し忘れのログ出力
|
| HTML/CSS側のコーディングについて |
セマンティックを意識したコーディング BEMの命名規則に準拠 タグに直接装飾はせず、クラスを用いて再利用性を高める Reset.cssをスタイルの直前にインクルードする HTML/CSSのインデントは半角スペース2つ分とする Idをセレクタとしてスタイルを付与しない JSで操作するクラスに’js’などの接頭辞を付与しない Importantは使用せず、詳細度でスタイルを上書きする 指定がない場合、SCSSを使用し見通しのよいCSS設計を実施する |
| JavaScriptのコーディング |
原則camelケースを採用 即時関数は使用しない 変数宣言varは使用せず、const/再代入が必要な場合のみletを使用する jsDoc以外での複数行のコメントは使用しない。 データ構造以外でのスコープネストは3階層までとする インデントはタブを使用せず、半角スペース2つ分までとする |
テストについて
テスト工程における全体的な流れについてとなります。
ただしマスタースケジュールなどに依存するため、この場限りではありません。
弊社環境内でテスト
お客様環境にあげる前に事前に確認します。
お客様環境へデプロイ
お客様環境下でも同様に動作するかを確認します。
お客様にてご確認
要件が満たされているか、気になる点はないか等のご確認を念のためお願いします。
弊社にて修正
ご指摘いただいた点を修正し、再度アップロードいたします。
終了
ご納得いただいた場合、納品のフェーズに移行します。
コミュニケーション体制について
Communication
指定がない場合
Slackを利用
Slack
何に関する連絡か分かりやすい、
充実した検索機能が
メリットとなります
メールの場合は通信が遅い、
複数人への情報の展開などが
デメリットです
もし使い方や導入方法が不明の場合、弊社にて実施およびサポートします。
契約書などの取引に関連する重要なファイルについては、メールを採用しています。