株式会社ファストコーディングで営業を担当しています長谷川と申します。お客様とお話ししていて気づいたことや、フロントエンド開発・コーディング制作界隈で最近流行っていることを書いていこうと思っております。どうぞ宜しくお願いします。
「前任が辞めて、何もわからない」
先日、あるお客様から急ぎのご連絡をいただきました。
「サイトの更新担当だった社員が先月退職して、管理画面のログイン情報すらわからないのです。サーバーの契約情報も、ドメインの管理も、全部その人が一人でやっていたので……」
このご相談は特別なケースではありません。私が営業として長年この業界に携わってきた中で、同じ状況を何度も目にしています。特に中小企業では、Web関連業務が「詳しい人」に属人化しているケースが非常に多い。
今回は、この「担当者がいなくなってプロジェクトが止まる」問題について、フロントエンド制作会社の営業だからこそ見えている「技術的な引き継ぎの落とし穴」も含めてお話しします。
一般的な属人化と「フロントエンド特有の属人化」
担当者がいなくなったときに困る情報は、大きく2種類あります。一般的な管理情報と、フロントエンド特有の技術情報です。
一般的な管理情報（サーバー、ドメイン、CMS管理画面のログイン等）については多くの記事で語られていますので、ここでは簡単に触れるにとどめます。
| 領域 | 属人化しやすい情報 | 止まったときの影響 |
|---|---|---|
| アカウント管理 | CMS管理画面、サーバー、ドメイン管理、SSL証明書 | サイトの更新・保守が一切できなくなる |
| 外部サービス連携 | Google Analytics、広告アカウント、SNS連携 | 計測が止まる、広告運用が中断する |
| 予算・契約管理 | 保守契約の更新日、月額費用の内訳 | 契約が切れてサービス停止する |
パスワードの管理については、1PasswordやBitwarden等のパスワード管理ツールで共有し、台帳にはツール内の格納場所を記載する方法が安全です。
ここから先は、フロントエンド制作会社の営業として、もう少し踏み込んだ話をします。
「前任のコードが怖くて触れない」問題
弊社がお客様から引き継ぎ案件を受けるとき、最も時間がかかるのは「アカウント情報の復旧」ではありません。前任者が書いたコードの解読です。
あるお客様のサイトを引き継いだとき、弊社のコーダーが最初に言ったのはこうでした。「CSSに!importantが200箇所以上あります。どこを触っても別の場所が崩れる状態です」。
これは極端な例ではありません。フロントエンドの引き継ぎで起きる典型的な問題を整理すると、以下のようになります。
CSSの地雷パターン
| 状況 | 何が起きるか | 修正にかかる工数 |
|---|---|---|
!importantの連鎖 | 上書きするにはさらに!importantが必要。連鎖が止まらない | 影響範囲の調査だけで数時間 |
| マジックナンバーの散在 | margin-top: -37pxのような謎の数値。理由がわからない | 変更すると別の場所が崩れるリスク |
| 命名規則の不在 | .box1, .text-red, .style2のようなクラス名 | どこで使われているか検索しないとわからない |
| インラインスタイルの多用 | HTMLに直接style="..."が書かれている | CSSで管理できず、修正が全ページに及ぶ |
JavaScriptの地雷パターン
| 状況 | 何が起きるか | 修正にかかる工数 |
|---|---|---|
| 古いjQueryプラグインへの依存 | jQuery 1.xに依存したプラグインが動かなくなる | 代替プラグインの選定と入れ替え |
| グローバル変数の汚染 | varで宣言された変数が他のスクリプトと衝突 | 影響範囲の特定が困難 |
| ビルドツールの未使用 | 生のJSファイルが30本、読み込み順に依存 | ファイル1つ消すとサイト全体が動かなくなる |
| コメントなしの業務ロジック | フォームのバリデーションが500行あるがコメントゼロ | 仕様の推測から始める必要がある |
CMS（WordPress）特有の問題
| 状況 | 何が起きるか | 修正にかかる工数 |
|---|---|---|
| プラグインが2年以上更新されていない | セキュリティホールが放置されている | 更新するとサイトが崩れるリスク |
| 子テーマなしのテーマ直接編集 | テーマ更新でカスタマイズがすべて消える | 変更箇所の特定と子テーマへの移行 |
| functions.phpに全機能が詰め込まれている | 1ファイル2000行、機能の依存関係が不明 | 分解作業だけで丸1日 |
| テンプレートの独自構造 | 標準のWordPressテンプレート階層と異なる独自ルーティング | 理解するのに前任者の思考を追う作業が必要 |
お客様にお伝えしているのは、「サーバーやドメインの管理情報は復旧可能です。しかし、前任者の頭の中にあった”なぜこう書いたか”は復旧できません」ということです。
「技術的な引き継ぎ」で残すべき情報
一般的な引き継ぎチェックリスト（アカウント情報、契約情報）に加えて、フロントエンドの引き継ぎでは以下の情報が必要です。
開発環境の情報
| 項目 | 記録すべき内容 |
|---|---|
| Gitリポジトリ | ホスティング先（GitHub/GitLab/Backlog等）、リポジトリURL、アクセス権限 |
| ステージング環境 | URL、認証情報（Basic認証等）、本番との差分 |
| ビルド手順 | Node.jsバージョン、npm install → npm run buildの手順、環境変数 |
| デプロイ方法 | FTP/SSH/Git push/CI自動デプロイ、手順書またはCI設定ファイル |
コードの構造メモ
弊社のコーダーが「これだけあれば助かる」と言う情報は以下の3つです。
- CSSの設計方針：BEMで書いているのか、独自の命名規則があるのか、Tailwindなのか。「なんとなく書いた」でも、そう書いてあればそれがわかる
- JSの依存関係：どのプラグインが何に使われているか。「スライダーはSwiper」「フォームバリデーションは自作」のようなメモ
- 意図的な例外：「このページだけレイアウトが違うのはクライアントの強い要望」「この余白は隣接する広告枠との調整」のように、理由がないと触れない箇所
この3つが1ページのドキュメントにまとまっているだけで、引き継ぎの工数は体感で半分以下になると弊社のコーダーは言っています。
制作会社との窓口の引き継ぎ
一般的な引き継ぎ記事では「窓口を2人にしましょう」で終わりますが、フロントエンド制作会社との引き継ぎでは、もう一歩踏み込んだ情報が必要です。
| 引き継ぐべき情報 | 具体例 |
|---|---|
| 過去の制作経緯 | なぜこのCMSを選んだか、なぜこのサーバーなのか |
| 暗黙の品質基準 | 「IE対応は切った」「Core Web Vitalsを重視している」等 |
| 進行中の課題 | 「ヘッダーのスマホ表示に既知のバグがある」「次回リニューアルで直す予定」 |
| デザインの意思決定者 | 社長決裁なのか、マーケ部門決裁なのか |
特に「過去の制作経緯」は重要です。「なぜWordPressなのか」「なぜこのプラグインなのか」がわからないと、制作会社は提案のしようがありません。前任者が口頭で伝えていた背景情報ほど、文書化されていないものはないです。
まとめ
今回は、担当者の退職・異動でプロジェクトが止まる問題について、フロントエンド制作会社の営業視点からお話ししました。
一般的なアカウント情報の引き継ぎは当然として、フロントエンドの現場では「コードの意図」と「開発環境の情報」の引き継ぎが決定的に重要です。前任者のコードが読めないために、修正に本来の3倍の工数がかかるケースを何度も見てきました。
今日からできることを3つにまとめます。
- サイト管理台帳に加えて、Gitリポジトリとビルド手順を記録する
- CSSの設計方針・JSの依存関係・意図的な例外の3点を1ページにまとめる
- 制作会社に伝えている暗黙の品質基準と制作経緯を文書化する
株式会社ファストコーディングでは、他社から引き継いだサイトのコード整理やリファクタリングもお手伝いしています。「前任者のコードが怖くて触れない」「引き継ぎで困っている」という方は、お問い合わせフォームからお気軽にご連絡ください。
