〜ビルド環境を前提にしない理由〜
Web制作の現場では、「どんな技術を使うか」よりも、「納品後に誰が、どう触るか」のほうが重要になる場面が少なくありません。
今回は、私どもが制作会社との協業案件で意識している納品設計の考え方について書いてみます。
前提：すべての制作会社がビルド環境を使えるわけではない
制作会社と一口に言っても、体制はさまざまです。
- フロントエンド専任がいない
- デザイナーがHTMLも触る
- 急ぎの文言修正はディレクターが対応する
- ビルド環境は特定の人しか触れない
こうした状況は、決して珍しくありません。
にもかかわらず、
- 修正にはNode.jsが必要
- ビルドしないと反映できない
- 環境構築の手順が複雑
という構成で納品してしまうと、「触れる人が限られるサイト」になってしまいます。
パーツの共通化はPHPで行っている
私どもが担当する案件では、
- ヘッダー
- フッター
- 共通パーツ
といった部分の共通化は、
PHPで行うことがほとんどです。
テンプレートエンジンや独自フレームワークは使いません。
理由は単純で、
- PHPなら多くの制作会社で理解できる
- サーバー上で完結する
- 仕組みが分かりやすい
というメリットがあるからです。
テンプレートエンジンを使わない理由
テンプレートエンジン自体を否定しているわけではありません。
実際に、他の制作会社さまが関与しない直接のお客さまのサイトや、自社プロダクトでは使用することもあります。
ただ、協業案件では、
- 学習コストが増える
- 「これはどこを直せばいいのか」が分かりづらくなる
- 触れる人がさらに限定される
といったデメリットが目立つことがあります。
そのため、
誰が見ても、だいたい何をしているか分かる構成
を優先し、
あえて使わない選択をしています。
HTMLは「そのまま触れる」状態を保つ
納品後によく発生するのは、
- 文言の微修正
- 改行やリンクの調整
- マークアップの軽微な修正
こうした作業のたびに
ビルド環境が必要になるのは、正直かなり面倒です。
そのため、
- HTMLはそのまま編集できる
- 特別なツールがなくても修正できる
という状態を意識して設計しています。
SCSSとJavaScriptはビルド環境を使っている
一方で、
- SCSS
- JavaScript
については、
ビルド環境を使用しています。
ここは割り切っていて、
- 構造が複雑になりやすい
- 影響範囲が広い
- 無秩序に触ると壊れやすい
領域だからです。
つまり、
- 触ってほしいところ → HTML / テキスト
- 触らないほうがいいところ → SCSS / JS
という役割分担を、構成そのもので示しています。
触れる範囲を分けることで、事故を減らす
この設計の目的は、「自由に触れるようにすること」ではありません。
- 触っていい範囲を明確にする
- 触らないほうがいい範囲を分ける
ことで、
事故を減らすことが目的です。
結果として、
- 修正しやすい
- 壊れにくい
- 引き継ぎやすい
という状態を作りやすくなります。
要望があれば、開発環境の共有も行う
もちろん、
- より大きな改修をしたい
- フロント側も自社で管理したい
- ビルド環境を含めて引き継ぎたい
といった要望があれば、
開発環境や構成の共有にも対応可能です。
最初からすべてを固定するのではなく、制作体制や案件の性質に合わせて、柔軟に対応することを前提にしています。
まとめ：技術選定ではなく、運用設計の話
この話は、
- 最新技術を使うかどうか
- モダンかどうか
といった議論ではありません。
- 誰が
- いつ
- どこを
- どう触るのか
そこを先に考えた結果として、「ビルド環境を前提にしない納品設計」を選んでいる、というだけです。
制作会社との協業では、納品後の現場がスムーズに回ることが、何より重要だと考えています。