結論から書きます。ドキュメントが実態とズレていく主な原因は、書き手のサボりではありません。同じ「今どうなっているか」を、複数の場所に現在形で書いてしまうこと——これに尽きます。書く場所が2つあれば更新も2回必要になり、片方を忘れた瞬間にズレが生まれます。
先日、副業で運営しているプロジェクトの進捗管理で、この構造にはっきり気づかされる出来事が2件、同じ日に重なって発覚しました。原因を潰すために4つの運用ルールを決めたので、その経緯と中身をまとめておきます。
ドキュメントがズレるのは、書き手のサボりではなく「多重記帳」のせい
私は個人の副業プロジェクトを、AIエージェントとの共同作業で運用しています。期日や待ち事項をまとめた「進捗台帳」を1つ持ち、毎朝これを読んで状況を報告させています。同時に、各プロジェクトの詳細は個別のドキュメントに、数値の実績は別の計測ファイルに、それぞれ記録してきました。つまり「今の状態」を書ける場所が、最初から複数ある構造になっていました。
一つの事実を1ヶ所にしか書かないなら、更新を忘れることはあっても、情報が食い違うことはありません。ところが同じ事実を台帳と個別ドキュメントの両方に現在形で書いてしまうと、話は変わります。どちらかを更新した瞬間に、もう片方は自動的に嘘になります。忘れているのではなく、コピーが存在する限りいずれ必ず起きる現象です。
同じ日に見つかった2つの更新漏れ
実際に気づいたきっかけは2件あり、同じ日にまとめて発覚しました。
1件目は、外部サービスへの申請状況です。販売しているNotionテンプレートの審査状況を、プロジェクト側の正本ドキュメントでは最新の状態に更新していたのに、毎朝読んでいる台帳側は古い記述のままでした。正本を直したときに、台帳側の同じ記述を直し忘れていた、というだけの単純なミスです。
2件目は、月次レビューの自動生成でした。生成された草稿は、その月のテンプレート販売実績を「不明」と書いてきました。しかし実際には、手動で計測しているファイルに「0本」ときちんと記録済みだったのです。生成処理に渡していた入力が週報だけだったため、実績の正本にしかない事実が処理側に届いていませんでした。「不明」は嘘ではなく、参照すべき場所を参照していなかっただけです。
2件とも原因は担当者の不注意ではなく、同じ事実を書ける場所が複数あったことでした。
4週間前に公開済みだった記事が、台帳では「判断待ち」のままだった
この2件をきっかけに台帳全体を見直してみると、もう一つ同じ構造の実例が見つかりました。台帳に「公開ボタンを押すかどうかの判断待ち」として残っていた記事が1本あり、確認すると、その記事はすでに4週間前に公開が完了していました。台帳にだけ状態を書き込み、実際の管理画面という正本と突き合わせる工程が抜けていたのです。
4週間、存在しない「判断待ち」を毎朝読み上げていたことになります。実害は小さなものでしたが、この手の食い違いは、気づかないままだと本当に判断待ちの案件を埋もれさせるリスクを持っています。
「最新の状態」と「その時点の記録」は別物
3件を並べて見えてきたのは、「最新の状態」と「その時点の記録」を同じ扱いにしていたという問題でした。
月次レビューやその時々のメモは、書いた瞬間から古くなっていくのが前提の記録です。これは古くなって当然で、悪いことではありません。問題があるとすれば、その記録をあとから「最新の状態」として読んでしまうことです。
逆に言えば、日付つきの記録は「これは何月何日時点のスナップショットです」と最初から言い切ってしまえば、古くなっても嘘にはなりません。困るのは、現在形で「今こうです」と主張する記述が、正本以外の場所にも存在してしまうケースだけです。
「台帳に全部書いてあった方が早い」への反論
正直に言うと、最初にこの構造を選んだのには理由がありました。毎朝の確認を、台帳を1つ開くだけで完結させたかったからです。個別のドキュメントまで見に行かせるより、台帳に詳細まで書いてあるほうが速い——そう考えて、正本にある内容の一部を台帳側にも書き写していました。
ですが、この「速さ」は更新のたびに複製先を思い出せる場合にしか成立しません。実際には、正本を更新する作業と台帳を更新する作業は別のタイミングで発生し、後者を忘れることは十分にあり得ます。速さを取ったつもりが、古い情報を毎朝読み上げるリスクを抱え込んでいただけでした。
状態ではなく、ポインタを持つ
この整理を踏まえて、4つのルールを決めました。
1つ目は、現在形の状態は正本1ヶ所にだけ書くことです。正本は原則、それぞれのプロジェクトの運用ファイルに置きます。プロジェクトをまたぐ横断的な事項だけは台帳自体を正本として扱い、他の場所にはコピーしません。
2つ目は、台帳側は状態の詳細を持たず、「項目・正本の場所・最終確認日」の3つだけを持つことです。経緯や数値、次にやることといった中身は、すべて正本側にしか書きません。台帳を開いて詳しく知りたければ、書いてある場所を見に行く、という導線に統一しました。
3つ目は、日付つきのメモは、その時点のスナップショットである旨を冒頭に明記し、以後は現在形で更新しないことです。
4つ目は、自動生成される月次レビューの入力に、必ず状態の正本を含めることです。週報だけを渡す構成をやめ、手動計測のファイルと台帳の両方を読み込ませるようにしました。
更新漏れは検知できないが、「古さ」なら検知できる
この中で一番効いているのは、2つ目のルールです。台帳が「状態」ではなく「ポインタ」しか持たなくなったことで、更新すべき場所が常に1つに絞られます。
もう一つ副産物があります。「更新を忘れた」ことそのものは、システム側からは検知しようがありません。存在しない更新を検知する方法はないからです。ですが「最後にいつ確認したか」という日付なら、記録して監視できます。毎朝の確認手順に、最終確認日が7日を超えている行を「要再確認」として拾い上げる工程を足しました。
鮮度は状態と違って、自分で更新しない限り必ず古くなっていきます。だから古いまま放置されていること自体が、そのまま異常のサインになります。更新漏れを直接検知することはあきらめて、鮮度が落ちていることを検知する方に切り替えた、という言い方もできます。
データベース設計の正規化と同じ発想
振り返ると、これはデータベース設計の正規化と同じ考え方でした。同じデータを複数のテーブルに重複して持つと、更新のたびに整合性を保つコストが発生します。だから1つの事実は1ヶ所に置き、他からは参照だけを持たせる。ドキュメント運用でも考え方は変わりません。
「複数箇所に同じ情報を書いておけば、どこかで見落としても他で拾える」という発想も一見あり得ますが、これは冗長化ではなく食い違いの温床になります。冗長化が機能するのは、複製元と複製先が自動的に同期される場合だけです。人が手で両方を更新する運用では、複製は保険ではなくリスクになります。
参照だけを複数の場所に置くのは、まったく別の話です。台帳のどの行からでも正本にたどり着ければ、経路は何本あってもかまいません。増やして困るのは「状態そのもの」の複製であって、「状態への行き方」の複製ではありません。
チームの進捗管理でも起きること
これは個人の副業運営に限った話ではありません。チームの進捗管理でも、まったく同じ構造が起きます。同じタスクの状態を、スプレッドシートとチケット管理ツールと会議の議事録の3ヶ所に書けば、どれか1つは必ず実態とズレます。
よくあるのは、チケット管理ツール上は「対応中」のままなのに、直近の会議では「先週対応済み」と報告されているパターンです。どちらの情報も、報告した瞬間には正しかったはずです。ズレているのは事実そのものではなく、同じ事実を書いた場所の数のほうです。
どれを正本にするかを決め、他の場所には正本へのリンクだけを置く。メンバーに「ちゃんと更新して」と頼むより先に、書く場所を1つに絞る設計そのものを見直したほうが早いというのが、私の実感です。同じ状態を2ヶ所に書かせている限り、更新は必ずどちらかで漏れます。
まとめ：状態は正本に1ヶ所、確認日はいつでも見える場所に
台帳の更新漏れと月次レビューの「不明」は、原因を辿ると同じ構造に行き着きました。同じ事実を複数の場所に現在形で書いていたことです。対策として、状態は正本1ヶ所にだけ書き、他の場所にはポインタと最終確認日だけを持たせるようにしました。更新漏れそのものは検知できませんが、確認日の古さなら検知できます。
ドキュメントが実態とズレて困っている方は、まず「同じ状態を何ヶ所に書いているか」を数えてみることから始めてみてください。書く場所を1つに絞れば、更新すべき箇所も1つに絞られます。
私は現役EMとして、1on1やチーム運営の仕組み化について書いています。1on1管理のNotionテンプレート(無料Lite版)を公開中です → 試してみる。X: @anikuma_tech
コメント