「できません」が言えなかった私が、品質の守り方を変えるまで
営業に言われるまま見積もりを出していた頃
正直に言うと、以前の私は「できません」が言えないタイプでした。営業から「この仕様と納期でいけますよね？」と聞かれると、技術的に厳しいと感じても、とりあえず見積もりを出して進めてしまう。結果、実装フェーズで工数が膨らみ、社内もクライアントも疲弊する炎上案件が続きました。
そこでようやく、「技術的な視点でブレーキをかけるのは自分の役割だ」と痛感しました。以降は感覚ではなく、WordPressやサーバー運用の知見をもとに根拠を整理し、「その納期では品質が担保できないので、こういう進め方はどうでしょう」と代案を出すようにしています。意外なことに、その方がクライアントからの信頼は上がりました。
当時の私は、公開前のチェックさえ頑張れば品質は守れると思っていました。でも本当に効いたのは、もっと手前の工程でした。
要件定義で「できる・できない」を言語化する
炎上を防ぐ一番のポイントは、要件定義の段階でどれだけ“ほつれ”を見つけられるかです。ジェイ・ラインでは、サイトの用途に応じて次の観点で擦り合わせます。
- WordPressで構築すべき部分と、静的でよい部分の切り分け
- 更新フロー・運用体制と、管理画面の設計が合っているか
- サーバー／ドメイン、SSL、メールなどインフラ要件の抜け漏れ
- 納期と品質のバランスが現実的か
ここで「難しい理由」と「代替案」をセットで示すのが、かつての自分に一番足りなかったことです。「できません」で終わらせないから、相手も納得してくれます。
実装チームへの指示は「迷わせない」が基本
TDの仕事は、実装を丸投げすることではなく、迷いなく作れる土台を用意することだと考えています。そのために、自分用のチェックリストを運用しています。
- ディレクトリ構成や命名規則を事前に共有しているか
- UIパーツごとの仕様（ホバー、ブレイクポイント、フォームの挙動）を定義したか
- 外部スクリプトやプラグインの制約・バージョンを明記したか
以前は指示の曖昧さが原因の手戻りがよくありました。テンプレート化してからは、複数案件を並行していても抜け漏れが目に見えて減りました。
公開・納品は“最後の砦”
上流で手を打っても、公開前のチェックはやはり最後の砦です。特に重点的に見るのは次の点です。
- ステージングと本番の環境差分（ドメイン、パス、キャッシュ設定など）
- フォーム、検索、会員機能など重要動線の実機テスト
- OGPや構造化データなど、最低限のマーケティング要件
- 管理画面からの更新テストと、運用担当者へのレクチャー内容
基準は「表示されていればOK」ではなく、「運用してもらっても壊れないか」です。
運用保守で知った「本当に必要な品質」
運用保守に関わるようになって、作った瞬間のきれいさより、変化に耐えられる設計の方が大事だと実感しました。
テーマ／プラグイン更新による不具合リスク
担当者が替わっても迷わない管理画面の構成
小さな改修の積み重ねでコードが肥大化していないか
ジェイ・ラインは自社でWordPress保守サービスも運営しているため、「運用する側のしんどさ」を前提に設計する考え方がチーム全体に共有されています。保守で得た気づきは、次の案件の要件定義にそのまま返っていきます。
クライアントと「完成の基準」を揃える
品質トラブルの多くは、「何をもって完成とするか」の認識ズレから生まれます。そこで意識しているのは次の3つです。
- 見積もり時に、含まれる範囲・含まれない範囲を言葉にしておく
- サンプルやプロトタイプで「この仕上がりになります」と見せて共有する
- 懸念点は早めに伝え、「こうすれば実現できます」という代案を同時に出す
リスクを並べるだけでなく、どうすれば実現できるかを一緒に考える。それが結局、品質への信頼につながります。
最後に
「できません」が言えなかった頃の私は、品質を守る方法を知らなかっただけでした。根拠を持って代案を出し、上流から手を打つ。ジェイ・ラインのTDは、そういう形でクオリティに責任を持つ仕事です。技術がわかるからこそ言える「NO」を武器にしたい方と、一緒に働けたら嬉しいです。
あわせて読みたい
