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