考えるフェーズ
コーディング設計 実装を、将来も運用できる構造へ変換する。
コーディング設計とは何か
コーディングというと、
- HTMLを書く
- CSSを書く
- JavaScriptを書く
という作業をイメージされることが多いと思います。
しかし私たちは、コーディングを単なる実装作業とは考えていません。
Webサイトは公開して終わりではなく、
- 情報が増える
- ページが増える
- 担当者が変わる
- CMS化される
- 機能が追加される
といった変化を繰り返します。
そのため、「今表示できるか」だけではなく、「将来も運用できるか」を考えながら設計する必要があります。
Flying High Works（FHW）におけるコーディング設計とは、どう書くかではなく、どのような前提で実装するかを整理する工程だと考えています。
コーディング設計の考え方
FHWのコーディング設計は、言語仕様やフレームワークの話だけではありません。
例えば、
- どこまで共通化するか
- どこを個別対応にするか
- 将来何が増えそうか
- 誰が保守するのか
といった判断を先に整理します。
実装前に考え方を揃えておくことで、
- 実装時の迷い
- メンバー間の認識差
- 後からの手戻り
を減らすことができます。
コーディング設計とは、実装そのものよりも、実装前の整理に近い作業です。
テンプレート化したVite環境
FHWでは、Viteをベースとした開発環境をテンプレート化しています。
案件ごとに毎回ゼロから構築するのではなく、
- 基本構成
- SCSS構成
- JavaScript構成
- SVG管理
- 画像管理
などを一定のルールで整理しています。
これにより、
- 初期構築のばらつきを防ぐ
- メンバー間の理解差を減らす
- 引き継ぎコストを下げる
といった効果が得られます。
私たちは、毎回同じことを考えるのではなく、本当に考えるべき部分へ時間を使いたいと考えています。
共通パーツを定期的に見直す
Webサイト制作を続けていると、
- このボタンの方が使いやすい
- この表組の方が崩れにくい
- この見出し構造の方が伝わりやすい
といった知見が少しずつ蓄積されていきます。
私たちは、それらを個人の経験として終わらせず、共通パーツとして整理し、次の案件へ活かせる状態にしています。
そのためFHWでは、半年から1年に一度程度、ディレクター・デザイナー・エンジニアによる分科会を行っています。
そこで、
- 見出し
- ボタン
- 表組
- リスト
- 画像パーツ
- ページャー
などの共通パーツを見直します。
Webサイト制作では、案件ごとに少しずつルールが変わっていくと、品質のばらつきや保守性の低下につながります。
そのため私たちは、共通化できるものは共通化し、改善が必要なものは定期的に見直しています。
コーディング設計とは、個別案件のためだけではなく、会社全体として品質を維持するための活動でもあります。
Git管理を前提とした実装
コーディングは、「今動いている」だけでは十分ではありません。
例えば、
- 誰が
- いつ
- 何を
- なぜ変更したのか
が分からなくなると、保守は非常に困難になります。
そのためFHWでは、Gitによるソース管理を前提として実装を行っています。
変更履歴を共有できる状態にすることで、将来的な改修や引き継ぎにも対応しやすくなります。
モバイル・PCのワンソース設計
現在でも、PC用HTMLとスマホ用HTMLを別々に管理しているサイトに出会うことがあります。
しかし私たちは、同じ情報を二重管理することは、品質や保守性の観点からリスクが高いと考えています。
そのため、HTMLは可能な限りワンソース化し、
- レイアウト
- 余白
- 表示順
などをCSS側で調整する設計を基本としています。
構造を一つに保つことで、修正漏れや管理負荷を減らすことができます。
将来の更新を前提に考える
コーディング時に見落とされやすいのが、将来の更新です。
例えば、
- タイトルが長くなったらどうなるか
- 画像サイズが違ったらどうなるか
- 記事が100件になったらどうなるか
- CMSで更新されたらどうなるか
といった視点です。
公開時だけ綺麗であっても、運用開始後に崩れてしまっては意味がありません。
私たちは、現在の状態だけではなく、将来の運用も想定しながらコーディング設計を行います。
ブレークポイントについて
FHWでは、基本的に下記のブレークポイントを利用しています。
- 768px以下
- 1024px以下
- 1025px以上
ただし、これはルールではありません。
プロジェクトによって、
- ターゲット層
- デザイン
- コンテンツ量
は異なります。
そのため、必要に応じて調整を行います。
重要なのは数値ではなく、どのデバイスでも情報が理解しやすいことです。
JavaScriptは目的がある場合に使う
JavaScriptは非常に便利な技術です。
しかし、動きを増やすことが目的ではありません。
例えば、
- スライダー
- フォーム制御
- 非同期通信
- UI補助
など、必要な場面で利用します。
私たちは、「動くから実装する」のではなく、「必要だから実装する」という考え方を重視しています。
設計があることで起きる変化
コーディング設計を整理しておくことで、
- 実装判断が揃う
- 人が変わっても読み解ける
- 改修時の負荷が下がる
- 品質を維持しやすくなる
といった効果が生まれます。
つまり、コーディング設計とは、将来のトラブルを減らすための準備でもあります。