コーポレートサイト運用の属人化を解消する5ステップ

「あの人が辞めたら、このサイト誰も触れなくなりますよね」

以前、あるクライアントの情報システム担当者からそう言われたことがある。WordPressで運用しているコーポレートサイトで、プラグインの更新もデプロイも、特定の1人だけが把握していた。その人が退職を検討しているという話が聞こえてきて、初めて問題が顕在化した。

正直なところ、あの状況は珍しいケースではないと思っている。Web担当者が1人という体制は中小企業では当たり前だし、引き継ぐ機会がなければ属人化は静かに進んでいく。問題は、「誰かが辞める」という事態になって初めて可視化されることだ。

私がこれまで関わってきた複数の現場で、属人化の解消に取り組んできた。うまくいったケースもあれば、最初のアプローチを間違えて遠回りしたこともある。その経験をもとに、5つのステップとして整理してみた。

ステップ1：今ある手順を「黙って書き起こす」ことから始める

最初にやってしまいがちな間違いがある。「ドキュメントをちゃんと作ろう」という気合いで、Notionやらスプレッドシートやらに大きなテンプレートを用意してしまうことだ。

試したことがある。担当者に「普段やっていることを全部書き出してください」とお願いした。1週間後に出てきたのは、半分埋まったスプレッドシートだった。担当者いわく「どこまで書けばいいか分からなくて、手が止まった」と。

それ以来、最初のステップは**「黙って書き起こす」**にしている。担当者に実際に作業してもらいながら、隣で私がメモを取る。スクリーンを録画することもある。担当者は何も特別なことをしなくていい。いつも通りにやってもらうだけでいい。

1週間もあれば、定例作業のほぼ全量が把握できる。書き起こした内容は後で清書するが、最初から「清書を作る」という目標を立てるのが間違いだったと気づいた。

ステップ2：「触れない領域」を切り離して可視化する

書き起こしの中には、かなり深いレイヤーの作業が混在していることに気づく。たとえば「ドメインの更新」「Aレコードの変更」「SSL証明書の対応」。これらは担当者が1人でやっていたとしても、他のメンバーに引き継ぐのが難しいか、引き継ぐべきかどうか迷う領域だ。

ここで運用を考えると、大きく2種類に分けて考えることが重要だと思っている。

インフラ・ドメイン系を「コンテンツ更新と同列に解消する」ことを目指すと、必要以上に難易度が上がる。運用を考えると、この領域は「触れる人を1人から2人に増やす」ではなく、「何をどこで管理しているか一覧化して、緊急時に連絡できる体制を作る」ことのほうが現実的だ。

具体的には、以下のような管理台帳をドキュメントとして残すことにしている。

# インフラ管理台帳

## ドメイン
- 登録業者: お名前.com
- 更新時期: 毎年 MM 月
- 管理者: 〇〇（社内）/ 担当代理店: △△

## DNS / SSL
- DNSプロバイダ: AWS Route 53
- SSL: ACM（CloudFront経由で自動更新）
- 手動対応が必要なケース: なし（ACM自動）

## ホスティング
- S3バケット名: xecin-site-prod
- CloudFrontディストリビューションID: XXXXXXXXXX
- アクセス権限: IAMロール xxxx（GitHub Actionsのみ）

この台帳は「使いやすさ」より「緊急時に見て30秒で状況が分かること」を優先して作っている。

ステップ3：更新作業をPRレビューに乗せる

コンテンツ更新系の属人化を解消するうえで、私が最も効果的だと感じた手段がPRベースのワークフローへの移行だ。

WordPressでの直接編集だと、「誰がいつ何を変えたか」が分かりにくい。FTPで上書きした場合はさらに追跡が難しい。それに対してGit + PRレビューの仕組みを使うと、変更の内容・理由・確認者が履歴として残る。

実際に使っているGitHub Actionsのデプロイワークフローを一部示す（改善の余地があるため、本番向けには追加のセキュリティレビューを推奨する）。

# .github/workflows/deploy.yml
# ⚠️ 改善の余地あり: 環境別のシークレット管理と、
#    PRプレビュー環境のクリーンアップが未実装
name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: npm ci && npm run build
      - name: Deploy to S3
        run: aws s3 sync dist/ s3://${{ secrets.S3_BUCKET }} --delete
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

このワークフローが動いている状態であれば、コンテンツを変更するためにFTPやWP管理画面にアクセスする必要がなくなる。PRを作成してレビューを受けてからマージする、というステップが一つ挟まることで、「前任者に聞かないといけない作業」が減る。

実際に効果が出た数字を挙げると、あるクライアントでは月次の更新作業において「担当者本人しかできない作業」の割合が、導入前の約80%から導入後3か月で約30%まで下がった。残りの30%がインフラ系の作業で、こちらは台帳整備で対応した。

ステップ4：AIエージェントを「2人目の担当者」として組み込む

ここは好みが分かれるところですが、私が最近取り組んでいる実験的な話として。

「2人目の担当者がいない」という属人化の根本原因に対して、AIエージェントを組み込む方法がある。すべての作業をAIに任せるわけではなく、定型的なコンテンツ更新作業（記事作成・フォーマット変換・PR作成）をAIが自律的にこなし、人間はレビューだけするという分担だ。

現実的な落とし所は、以下のような役割分担だと考えている。

この仕組みが成立するには、AIへの作業規約（CLAUDE.mdなど）を明示的に定義しておくことが前提になる。AIに「このファイルだけ触ってよい」「このブランチに直接pushするな」というルールを設計しておくことで、人間が安心してレビューだけに集中できる。

AIエージェントを「ツール」ではなく「社員」として設計するという考え方だが、このアプローチはまだ発展途上で、すべての現場で同じように機能するとは言い切れない。ただ、「2人目が育つまでの橋渡し」として使うには十分だと感じている。

ステップ5：3か月後・6か月後に振り返る

属人化の解消は、一度やれば終わりではない。

ステップ1〜4を実施した後、3か月後に「この作業、担当者以外の人でも対応できるか？」を確認する機会を設けることを強く勧めている。理由は単純で、手順書は書いた直後は正確でも、3か月後には変更されている部分が必ず出てくるからだ。

確認する観点はシンプルにしている。

## 属人化チェック（四半期レビュー）

### 確認項目
- [ ] 担当者が1週間不在でも、コンテンツ更新ができる体制か
- [ ] インフラ台帳は最新の状態か（ドメイン更新日・証明書期限）
- [ ] PRレビューができる人が2人以上いるか
- [ ] AIエージェントへのアクセス権限が適切に管理されているか

### 残存属人領域の記録
| 作業 | 担当者 | 代替できる人 | 優先度 |
|---|---|---|---|
|  |  |  |  |

6か月後のレビューでは「残存属人領域の記録」の変化を見る。減っていれば改善が続いている証拠だし、同じ項目が残っていれば何か構造的な障壁があると判断して掘り下げる。

今思えば、最初から「属人化をゼロにする」という目標を立てていたのが無理だった。インフラ変更や緊急対応は、特定のスキルと経験が必要で、誰でも対応できるようにするより「対応できる人を明確にしておく」ほうが現実的だ。

振り返って

5つのステップをまとめると、大きな流れはこうなる。

全部一度に実施しなくていいと思っている。ステップ1と2だけでも、担当者への負荷は目に見えて下がる。

今後取り組みたいのは、ステップ4のAIエージェント活用をより汎用的にすることだ。現状はコンテンツ更新に特化しているが、インフラ台帳の更新確認や証明書の期限チェックなど、定型的な確認作業をAIがこなせる範囲を少しずつ広げていきたいと考えている。

「運用を考えると」、属人化は組織の脆弱性だ。誰かが辞めるまで気づかない、というサイクルから抜け出すために、できることから始めていくしかない。