手順書は書いた当日に3本が画面と合わなくなり、ロードマップは7日目に見直しになった。それでも文書は4か月間1バイトも変わらなかった話

先週、自社の広告運用プロジェクトの資料を別件で読み返す機会がありました。5月に作った計画書・手順書の一式です。読み始めてすぐ引っかかったのが、配信開始後のロードマップに「G2判定は6月1日」と書いてあること。私の記憶では、その判定は開始から7日目のレビューで見直しになり、予定どおりには行われていません。

つまり文書は、4か月前の「予定」を今日も現在形で語っている。

理屈はそうなんですが、「文書は更新しましょう」で片づけると同じことを繰り返します。なぜ更新されなかったのか、どの文書のどの部分が腐り、その腐りはどこに記録されたのか。今回はそれをリポジトリと課題管理の履歴から数えて、文書の置き場所を決め直しました。数字は全部、自社リポジトリの docs/510_広告運用/01_AI-WEB-PLATFORM/ 配下と、対応する Redmine チケットから取っています。広告の成果そのもの（費用や件数）は本題ではないので出しません。

何を数えたか

対象フォルダには Markdown が 36 本、合計 490,666 バイトあります。要件定義・基本設計・計測仕様・入稿物・配信開始までの手順書（親手順書）・既知問題・ロードマップの 7 本と、週ごとのタスク手順書（_week0 から _week2、T-0.1 から T-2.13）が 27 本、それに引き継ぎ用のプロンプト雛形などです。

これを私は 3 層に分けて見ました。

• 計画書: いつ何をするかを並べたもの（ロードマップ、親手順書の週割り）
• 手順書: 画面をどう操作するか（T-1.10 のような 1 タスク 1 本の文書）
• 決定記録: 実行した結果、何をやめて何を変えたか

層ごとに「書かれた時刻」「実行された時刻」「乖離が記録された時刻と場所」を git の履歴とチケットの履歴から拾います。最初のブロックは、そのタイムラインを取り出したコマンドです。

cd docs/510_広告運用
git log --date='format:%m-%d %H:%M' --format='%ad %h %s' -- . | tail -n 25

# 実行結果（抜粋。時刻は JST）:
# 05-13 03:02 40c0dda feat(ads): 広告配信運用ドキュメントセットを追加          # 12 files / +3,091
# 05-16 02:20 62fbd26 docs(ads): Week 0/1 タスク手順書を追加                  # 16 files / +4,346
# 05-16 03:07 7b92632 docs(ads): T-1.13 Week1通しテストのエビデンス画像を追加
# 05-16 07:13 9515a51 docs(ads): Week 1 完了記録と新UI仕様変更を反映          #  7 files / +376
# 05-16 08:12 ... 14:59  Week 2 の手順書・入稿物を 16 コミット（マージ含む）
# 05-18 09:20 8b6a310 docs(ads): 既知問題と配信開始後ロードマップを追加       #  2 files / +549
# 05-18 11:01 d20763c docs(ads): 入札戦略の新UI乖離（手動CPC廃止）を記録     #  3 files / +71 -3
# 06-11 21:33 387b953 docs(広告運用): キャンペーン別フォルダ構成へ再編        # パス移動のみ
# （以降、このフォルダへの内容変更コミットは無し）

このログだけで、話の半分は見えています。

手順書は、書いた当日に腐った

Week 0/1 の手順書 16 ファイルが入ったのが 5 月 16 日の 02:20。通しテストの証跡画像が 03:07。そして 07:13 に「Week 1 完了記録と新UI仕様変更を反映」というコミットが乗っています。手順書の追加から 4 時間 53 分で、3 本の手順書（T-1.10 拡張CV送信、T-1.11 GTM タグ設定、T-1.12 コンバージョン設定）の冒頭に「新UI仕様による実装方針変更」という節が追記されました。

中身は、手順書が前提にしていた Google 広告の管理画面の動線が、実行時点の画面に存在しなかった、というものです。「ツールと設定 → 測定 → コンバージョン」の動線が無い、「スキャン → 手動設定」の選択肢が無い、アカウント設定の「お客様データ活用」という項目自体が消えている。旧UIを前提に書いた手順が、新UIでは参考情報に格下げされ、実際にやった別の手順が上に書き足されています。

正直なところ、私は「手順書は数か月で古くなる」くらいの時間感覚でいました。5 時間は想定外でした。

しかもこれで終わりではなく、2 日後の配信開始当日にもう 1 件。T-2.10 入稿手順で「手動CPC（拡張CPC OFF）」と指定していた入札戦略が、新規キャンペーン作成画面の選択肢から消えていて選べない。この乖離は 05-18 11:01 のコミットで記録されました。ロードマップ v1.0 を 09:20 に置いてから 1 時間 41 分後、v1.1 への改訂です。

乖離した項目を数えると、T-1.10 で 2 か所、T-1.11 で 1 か所、T-1.12 で 4 か所、T-2.10 で 1 か所の 計 8 か所。4 本の手順書のうち、当日中に画面と合わなくなったものが 3 本、2 日後にもう 1 本です。

ここで気になったのは「乖離はどこに記録されたか」です。grep -l '新UI' でこのフォルダ内で当たるファイルは 6 本ありました。3 本の手順書の冒頭、親手順書の §4.4、ロードマップの §6.0、そして次のセッションに渡す引き継ぎプロンプト。さらにリポジトリ直下の CLAUDE.md にも同じ乖離表が入っていて、合わせて 7 か所。同じ事実が 7 か所に書かれている一方で、T-2.10 の手順書本体と T-2.13 のプリフライトチェックリストには、今も「手動CPC」の行が当時のまま残っています。乖離を知っている文書と知らない文書が、同じフォルダに同居しているわけです。

手順書の中身を数えたら、画面パスが 102 行、終了状態が 25 行だった

なぜ 5 時間で腐るのか。答えは手順書の書き方にあると踏んで、27 本の手順書の行を分類しました。箇条書きと番号付きの行を「手順行」とみなし、その中で「画面 A → 画面 B」のように操作の動線を書いている行と、「〜になっていること」「〜が表示される」のように終了状態を書いている行を数えます。

import re, glob

nav_pat = re.compile(r'(→.*(「|\*\*))|クリック|選択')
end_pat = re.compile(r'であること|になっていること|を確認|確認する|表示される')

total = nav = end = 0
for path in sorted(glob.glob('_week*/T-*.md')):
    for line in open(path, encoding='utf-8-sig'):
        if not re.match(r'\s*(\d+\.|-\s\[ \]|- )', line):
            continue
        total += 1
        nav += bool(nav_pat.search(line))
        end += bool(end_pat.search(line))
print(f'files={len(glob.glob("_week*/T-*.md"))} steps={total} nav={nav} end_state={end}')

# 実行結果:
# files=27 steps=1281 nav=102 end_state=25
# 当日に腐った 2 本だけ抜くと T-1.10: nav=15 end=3 / T-1.12: nav=13 end=1

この分類器は正直に言って粗いです。「選択」は「選択肢」にも当たるし、「確認」は「確認済み」にも当たる。改善の余地は大いにあります。ただ、4 倍の差が数え方のブレで消えるとは思えないので、傾向としては受け取っていいと判断しました。

手順書は「どこをクリックするか」を主に書き、「終わったときに何がどうなっていれば正しいか」をほとんど書いていない。動線は画面の持ち主（この場合は Google）が予告なく変えるものなので、動線中心の手順書は書いた瞬間から相手の都合で腐り始めます。終了状態のほうは、画面が変わっても変わりにくい。「拡張コンバージョンの設定が有効になっていること」という要件は、その設定画面がどこに移動しても生きています。

ドキュメントにはこう書いてあるけど、実際に手を動かす人が見ているのは画面であって手順書ではありません。手順書が役に立つのは、動線が分からなくなったときと、終わったかどうか判断がつかないときの 2 回だけで、前者は画面の変更で価値がゼロになる。残るのは後者です。

計画書は、7 日目に取り下げられた決定を知らない

次に計画書側です。配信開始後のロードマップ（v1.1）には、Day 0 の配信 ON から 7 月の Meta 投入まで 12 行のマイルストーン表があります。これは Redmine の親チケット 1 件と子チケット 10 件に起票されていました。作成時刻は 05-18 の 00:50 から 00:56、ロードマップのコミットの 8 時間半前です（起票の方が先でした）。

現場では、計画書の各行がチケットになった時点で「計画は管理されている」と感じます。私もそう思っていました。そこで、子チケットの終わり方を API で数えました。

# 親チケット配下の子チケットを、状態・終了時刻つきで一覧する（読み取りのみ）
PARENT=7394
curl -s -H "X-Redmine-API-Key: $REDMINE_API_KEY" \
  "https://redmine.example.jp/issues.json?parent_id=$PARENT&status_id=*&limit=50&sort=id" \
| jq -r '.issues[] | [.id, .status.name, .start_date, (.closed_on // "-"), .subject] | @tsv'

# 実行結果（件名は要約）:
# 7395  11.完了  2026-05-18  2026-05-25T02:17:38Z  Day 0 配信ON
# 7396  11.完了  2026-05-19  2026-05-25T02:17:39Z  Day 1-3 初動72時間モニタリング
# 7397  12.中止  2026-05-22  2026-05-25T02:07:15Z  観察期 Day 4-14 通常運用
# 7398  11.完了  2026-05-25  2026-05-25T02:06:14Z  Day 7 中間レビュー
# 7399  12.中止  2026-05-31  2026-05-25T02:17:46Z  Day 14 最終データ集計
# 7400  12.中止  2026-06-08  2026-05-25T02:17:46Z  拡張CV マッチ率評価
# 7401  12.中止  2026-06-15  2026-05-25T02:17:46Z  Phase 2: 稟議用PDF Apps Script 化
# 7402  12.中止  2026-06-29  2026-05-25T02:17:46Z  Phase 2: 週次オフラインCV CSV 自動化
# 7403  12.中止  2026-07-01  2026-05-25T02:17:46Z  Meta 投入
# 7404  12.中止  2026-06-01  2026-05-25T02:17:46Z  Day 15 G2 本格運用移行判定

完了が 3 件、中止が 7 件。全部の終了時刻が 05-25 の 02:06 から 02:17（UTC。JST では 11:06 から 11:17）の 11 分間に収まっています。Day 7 の中間レビューのチケットが完了になり、そのコメントに「初週のデータで前提が崩れたので方針を見直す。観察期は中止、G2 判定はプロダクト見直し後に再設定、Phase 2 は親側で方針再決定後に判断」という趣旨の判断が書かれ、直後に残りが一括で中止になっています。

ここが今回いちばん想定外だったところで、私は最初「決定の記録が無い」と読んでいました。リポジトリのロードマップは v1.1 のまま、G2 判定は 6 月 1 日のまま、中止の文字はどこにも無い。だから記録されていないのだと。実際には記録はありました。ただし計画書ではなくチケットに、それも 10 件中 1 件のコメント欄にだけ。決定は存在したのに、計画書がそれを知らされていなかった、というのが正確な描写です。

今思えば、これは置き場所の設計ミスです。計画書はリポジトリ、実行と決定は Redmine、乖離の記録は手順書の冒頭。3 つの層が 3 つの場所に分かれていて、下の層で起きたことを上の層へ書き戻す手順が、どこにも書かれていなかった。手順書は 27 本あったのに、「計画が変わったときに計画書をどう直すか」の手順書だけが無かった。

4 か月間、1 バイトも変わらなかった

念のため、「更新されなかった」を感覚ではなく比較で確かめます。05-18 11:01 のコミット時点のフォルダを取り出して、今日の同じフォルダと突き合わせました。6 月に一度フォルダの再編があるので、パスが変わっても内容が同じかを見る必要があります。

# 05-18 時点のスナップショットを展開し、現在のフォルダと内容比較する
git archive d20763c "docs/510_広告運用" | tar -x -C /tmp/snap
diff -rq "/tmp/snap/docs/510_広告運用" "docs/510_広告運用/01_AI-WEB-PLATFORM"; echo "rc=$?"

# 05-18 以降にこのフォルダの内容を変更したコミットを探す（リネーム追跡つき）
git log -M --diff-filter=M --format='%h %ad %s' --date=short \
  --after=2026-05-18T23:59:59 -- "docs/510_広告運用/01_AI-WEB-PLATFORM"

# 実行結果:
# rc=0            ← 差分ゼロ。画像や CSV を含む 44 ファイルすべて同一
# （2 つ目のコマンドの出力は空。内容変更コミットは 0 件）

差分ゼロ。6 月 11 日の再編はパスの移動だけで、内容には触れていません。05-18 から今日まで 124 日、計画書はロードマップ v1.1 を、手順書は「手動CPC」を、現在形で語り続けています。

「更新されなかった文書は 60% が半年で古くなる」といった話はよく聞きますが、今回のケースは半年どころか、手順書は当日、計画書は 7 日目に古くなり、そのまま 4 か月置かれました。古くなる速度と、古さが発覚する速度は別物です。手順書は実行した人がその場で気づいたので 5 時間で発覚した。計画書は誰も実行しないので、4 か月後に私が別件で読むまで誰も気づかなかった。

教科書どおりに 36 本書いて、重すぎた

失敗の話を正直に書いておきます。このプロジェクトの文書体系は、要件定義から入稿物詳細、週ごとのタスク手順書、プリフライトのチェックリストまで、PMBOK の「計画してから実行する」を素直に踏んだ形になっています。文書量は 490 KB、手順書だけで 30 万バイト。Week 1 と Week 2 の実作業は 5 月 16 日と 17 日の 2 日間で終わっているので、2 日間の作業のために 30 万バイトの手順を書いたことになります。

書いたこと自体は間違いではなかったと思います。初めて扱う広告管理画面で、設定漏れを出さずに 2 日で走り切れたのは、手順書とチェックリストがあったからです。問題は「書いた後」です。手順書は実行の瞬間に役目を終えて、その後は乖離の記録だけが価値を持つ。それなのに手順書の体裁を 4 か月維持していて、その維持のためのコスト（本文を読んで古い箇所を見つけ、7 か所を同期させる）を誰も払えなかった。

フレームワークは目的ではなく道具です。今回削るべきは「計画してから実行する」ではなく、「実行後も手順書を手順書のまま保つ」という、どのフレームワークにも書かれていない暗黙の前提でした。

3 層の役割を決め直す

数えた結果から、文書を「何のために存在するか」で 3 層に分け、それぞれの鮮度の守り方を決めました。テーラリングの判断理由も添えます。

具体的な型は次のとおりです。手順書の冒頭と、計画書のマイルストーン表の 2 つを変えるだけで、今回数えた 3 つの現象（当日の乖離、記録の分散、書き戻し漏れ）に対応します。

<!-- 手順書の冒頭に固定で置く枠。動線が変わったらここだけ直す -->
## 実施記録
| 実施日 | 実施者 | 結果 | 画面との乖離（あれば） | 正本 |
|---|---|---|---|---|
| 2026-05-16 | 担当A | 完了 | §2.1 の動線は現UIに無い。検索バー経由で到達 | 本表 |

## 終了状態（この手順が終わったと言える条件）
- [ ] コンバージョン一覧に `Lead - Form Submit` が 1 件だけ存在する
- [ ] 計測期間が 30 日になっている
- [ ] 旧イベントが削除されている

<!-- 計画書のマイルストーン表に 2 列足す。取り下げは理由を 1 行で書き戻す -->
| 日付 | マイルストーン | 記録先 | 結果 |
|---|---|---|---|
| 05-25 | Day 7 中間レビュー | #7398 | 完了。前提が崩れたため以降を見直し（詳細は #7398） |
| 06-01 | Day 15 G2 判定 | #7404 | 中止（#7398 の決定により。再設定は未定） |

「終了状態」の書き方は、動線を捨てるのではなく主従を入れ替えるのがポイントです。動線が生きているうちは補助として役に立つし、死んだ後も終了状態だけで作業は再現できる。動線の寿命は画面の持ち主が決めますが、終了状態の寿命は自分たちで決められます。

ここは好みが分かれるところですが、私は「実施記録」を手順書の末尾ではなく冒頭に置く派です。末尾だと読まれないままの本文を信じて作業が始まる。冒頭にあれば、本文を読む前に「この手順書は 5 月 16 日に一度腐っている」と分かります。

振り返って

計画書・手順書・決定記録の 3 層で、鮮度が落ちる速度と、それに気づく速度を数えました。手順書は 4 時間 53 分で乖離し、実行者がその場で気づいた。計画書は 7 日目に前提が崩れ、誰も気づかないまま 124 日。決定はチケットの 1 件に残り、計画書には戻らなかった。

やってみて分かったのは、文書の鮮度は「更新する意志」ではなく「置き場所と書き戻しの手順」で決まる、ということです。7 か所に同じ事実を書く運用でも、その日のうちに 2 つの文書が取り残されました。1 か所に書いて残りはリンクにする、書き戻しをチケットの完了条件に入れる、手順書は終了状態を主役にする。どれも小さな変更ですが、全部「人の善意に頼らない」方向に倒しています。

今後は、この 3 層の型を次に立てるプロジェクトの文書雛形に最初から入れて、4 か月後にもう一度同じ数え方で測るつもりです。数字が変わっていなければ、型のほうを疑います。