納期と品質を両立させるテクニカルディレクターの案件コントロール術

# BEM設計# Web制作効率化# WordPress要件定義# コンポーネント設計# 採用サイト構築

品質を落とさないための設計の「型」

品質を担保する鍵は、着手前の「型化」です。
Figma等から共通パターンを洗い出し、ヘッダー・フッター・グローバルナビ・カード・ボタン・フォームなどをコンポーネントとして定義します。
「例外対応前提」で設計を始めると、低単価案件ほど赤字化するため、まずは8〜9割を共通化し、「残り1〜2割だけを個別対応する」という前提でサイト構造・CSS設計・テンプレート構成を決めるのが基本方針になります。

共通パーツ設計とBEM命名で「無駄コーディング」を削る

まず「どこからどこまでをひとつの共通パーツとするのか」を、デザイナーと丁寧にすり合わせるところから始めます。
共通パーツの範囲を最初にきちんと決めておくことで、後から余計なコーディングが増えるのを防ぎ、更新しやすいWebサイト構造にできます。
例えば、よくあるカード型の一覧パーツなら、次のような単位に分けて考えます。

カード全体を包むリスト部分：.card-list
1枚1枚のカード要素：.card-list__item
カードの中身（画像・タイトル・補足情報など）：.card / .card__thumb / .card__title / .card__meta

このように、BEM（Block・Element・Modifier）というルールに沿ってクラス名を設計しておくと、「どの部分がどの役割を持っているか」が誰にでも分かりやすくなります。
結果として、複数ページにまたがる大規模なWEBサイトでも、レイアウト変更やコンテンツ追加に柔軟に対応しやすくなります。

たとえば、同じカードでも横長レイアウトにしたいときは .card–wide、注目させたいカードには .card–highlight のようにmodifier（バリエーション用のクラス）を付けるだけで、デザインの違いを表現できます。
「新しいレイアウトだから1からCSSを書き足す」という事態を避けられるため、工数を抑えながらも、クライアントにとって更新しやすく、運用コストの低いWEBサイト制作・WEB運用管理につなげることができます。

WordPress案件での事前ヒアリング術

WordPressの「想定外対応」は赤字要因になってしまう可能性があるため、テクニカルディレクターは受注直後に以下を必ず確認します。

固定ページ／投稿／カスタム投稿の切り分け方
編集権限とGutenberg／クラシックエディタの方針
共通ブロック（よく使うセクション）の有無
お問い合わせフォームのバリデーション要件

WordPressのテンプレート設計では、「個別のpage-xxxx.phpをどこまで作り込むか」「共通のpage.phpとACF（Advanced Custom Fields）で柔軟に管理するか」を、制作初期のディレクション段階で明確にしておくことが重要です。
この方針を曖昧にしたまま進行すると、実装フェーズで構成を大きく見直す必要が生じ、スケジュールやコストに影響が出てしまいます。

そのためジェイ・ライン株式会社では、Webサイト制作や採用サイト構築の前に、お客様へのヒアリングを徹底的に行います。
「どのページで何を伝えたいのか」「更新頻度の高いコンテンツはどこか」「将来的にどのような追加・改修が発生しそうか」といった運用イメージまで深くお伺いし、テンプレート構成に落とし込んでいきます。
とくに採用サイトやコーポレートサイトでは、求人情報やニュース、インタビュー記事など、更新サイクルやボリュームが大きく異なるため、ヒアリングの段階で「専用テンプレートにするページ」「共通テンプレート＋ACFで再利用するパーツ」を一緒に整理していきます。

こうした事前の要件定義とヒアリングを丁寧に行うことで、「後からやっぱり構成を変えたい」といった手戻りを最小限に抑えられます。
結果として、Webディレクターやテクニカルディレクターにとっても見通しの良い進行ができ、クライアントにとっては運用しやすく、拡張性の高いWordPressサイト／採用サイトを、安定した品質で提供することが可能になります。

社内コーダーへの指示を明確にし工数を圧縮

まず最初に、プロジェクトのスタート段階で作成した要件定義書を担当コーダーに共有し、「どんなサイトを、どこまで、どのレベルでつくるのか」という前提条件を丁寧にすり合わせます。
そのうえで、デザインがFIXしたタイミングでも要件定義書をもう一度起点にしながら、「このUIはどの仕様で実装するか」「どこまでを今回のスコープとするか」などを細かく指示していきます。
要件とデザインを常にセットで確認することで、認識の食い違いや解釈のブレを事前に防ぎ、レビューの回数や手戻り対応に費やす時間を最小限に抑えられます。
結果として、コーダーは迷いなく実装に集中でき、ディレクターは品質チェックと価値の高い提案に時間を割けるため、プロジェクト全体のスピードとアウトプットの質を同時に高めることができます。

検証工数を削るテスト観点リストと自動化の使いどころ

ジェイ・ライン株式会社では、案件ごとに使い回せる検証チェックリスト（テンプレート）を標準化し、抜け漏れを防ぎながら検証工数をコントロールしています。
例えば、PageSpeed Insightsなどのパフォーマンス計測ツールで、スコア数値が一定基準を下回った場合、画像最適化やキャッシュ設定、コードの見直しといった詳細な原因調査・改善に進むなど、「深掘りする条件」を事前に決めておくことで、WEB運用管理における検証プロセスを安定して回せるようにしています。
こうしたチェックリストのテンプレート活用と、条件を絞った自動化・計測の組み合わせにより、クオリティを担保しながら、Web制作現場の検証工数を着実に削減しています。

コーディング改善提案と上流工程へのステップ

ジェイ・ライン／MARUTTOでは、単発のコーディング案件でも「運用を見据えた構造提案」を行うことで、保守・追加開発へ広げた事例が多くあります。例えば、

手書きHTMLの更新負荷を指摘し、WordPress化＋ブロック設計を提案
散在するCSSを整理し、コンポーネント設計にリファクタリング

といった改善を「次回リリース時に無理なく移行できる案」として提示することで、テクニカルディレクター自身が要件定義・情報設計まで関わるケースが増えています。
コーディング術を磨くことは、そのまま上流工程へのパスポートになり得ます。