「なぜ」を記録しないドキュメントは劣化する

何となくずっと感じてきたことなのですが、世の中のドキュメントは保守することを考えられていないな、と思うものが多いです。 秩序を守るために書かれたルールや規定、設計書、仕事のプロセスや手順書などがそうです。

「保守することを考えられていない」というのはドキュメントの「変更」のために必要な情報である

• このドキュメントが作成されることになった背景
• 最終稿として決定するまでの経緯
• このドキュメントの内容が決定した理由

が追跡困難であるからです。

仕事のきほん

仕事の基本はシンプルです。 まず「課題」があり、その課題に対する「解決策」を考え、 解決策を実現・実行するための「手順」や「プロセス」を定める——この三層構造で成り立っています。¹

たとえばこんな例を考えてみます。

• 課題： 本番デプロイ時にたびたびミスが発生し、障害につながっている
• 解決策： デプロイ前にチェックリストを導入する
• 手順： デプロイ担当者はリリース前にチェックリストを埋める

この流れ自体はよくありますし、正しいです。問題は時間が経ったあとに起きます。

「手順」だけが残る

チェックリストが導入されてしばらく経つと、「手順」だけが残ります。 なぜそのチェックリストが生まれたのか、どんな障害がきっかけだったのか、 そういった背景は課題管理システムの奥深くに埋もれるか、担当者の遠い記憶の中にしか残りません。

新しく入ったメンバーから見ると「なんかチェックリストを埋めるものらしい」という認識になります。 やがてチームにとっての目的が「デプロイミスをなくすこと」から「チェックリストを埋めること」にすり替わっていきます。

これは珍しいことではありません。 ISO や社内ルール、議事録の記入、日報の提出…… 多くの場所で同様の現象が静かに進行しています。

状況は必ず変わる

最初の解決策がそのまま機能し続けることはほとんどありません。 チームの規模・技術・体制——すべてが変化します。

先ほどの例で言えば、CI/CD パイプラインが整備されて自動テストが充実してきたとします。 手動チェックリストの大半は機械的に担保されるようになり、人間が毎回確認する必要性は薄れています。 しかし誰もチェックリストをやめようとしません。

なぜなら、その手順がなぜ存在するかを誰も説明できないからです。

改善が止まる二つの罠

ドキュメントの見直しを提案しようとすると、必ずといっていいほど二つの壁にぶつかります。

罠①：現状維持バイアス

「今までこうやってきたから問題ない」という主張が出てきます。 これは現状維持バイアス²の典型的な例です。

実際には「今まで問題が起きていない」のはドキュメントのおかげかもしれないし、関係ないかもしれない。 「なぜ」が共有されていないと、その判断が誰にもできません。結果として現状維持が最も安全な選択肢に見えてしまいます。

罠②：影響範囲がわからない

先ほどの例の続きで言うと、「このチェックリストを変えたら何かが壊れるかもしれない」という不安も生じます。

チェックリストに限らず、ドキュメントは往々にして他のドキュメントに暗黙的に依存しています。 背景が記録されていないと、その依存関係をたどる術がありません。

怖くて手が出せないというのは感情の話だけではなく、 「手を出すと何が起こるかわからないので悪い方向に転がる可能性がある」という合理的な思考の結果です。 上手く回っていないように見えるからドキュメントを廃止しようとしても、何のために作られたかを理解するまで手を出すことはできません。 これは 「チェスタトンのフェンス（Chesterton's Fence）」 として知られる原則であり、 「なぜ」がわからない以上、手を出さないという判断は合理的です。

「何のためにあるのかわからないなら、片づけさせるわけにはいかない。出直してくれ。しかしもし戻ってきて、そしてこれが何のためにあるのか説明できたなら、もう壊してしまったって構わないよ」

— G.K. Chesterton, The Thing (1929)（意訳）
※ Claude に意訳してもらいました。 https://www.chesterton.org/taking-a-fence-down/ で原文からの引用を確認できます。

改善が止まる

この二つが重なると、改善の提案は立ち消えになり、組織は静かに機能不全へと向かっていきます。 提案しても何も進まないので声を上げることもなくなり、ある日ふと「なんかうまく回ってないな」と気づく頃には、 手遅れの状態になっているでしょう。

「なぜ」を残すとはどういうことか

では具体的に何を記録すればいいのでしょうか。ドキュメントの冒頭に以下を書くだけで大きく変わります。

## このドキュメントの目的
- 解決したい課題：本番デプロイ時の手動ミスによる障害
- 導入の背景：2026年1月に発生した3件の障害（`#123`, `#145`, `#167`）を受けて導入
- このドキュメントが不要になる条件：デプロイの自動化が完了し、CI/CDでカバーされた場合

「このドキュメントが不要になる条件」が書いてあるのはなかなか見たことがありません。 が、不要になる条件が明確に示されていれば必要である理由も明確になるので記載しておくのがベストです。 特に一時的な対策である場合や、期限がある場合は記載しておくべきでしょう。

改善が期待できない場合の補助線

チームによっては、ドキュメントを能動的に見直す文化や知識がまだ育っていないこともあります。 そういった場合は、見直しのタイミングと代替案をドキュメントの中に組み込んでしまうのが現実的です。

たとえばこのような形です。

## 見直しトリガー
- [ ] デプロイ自動化が完了した場合 → チェックリストの各項目をCIで代替できるか確認する
- [ ] チームの規模が10名を超えた場合 → レビュープロセス全体を再設計する
- [ ] 四半期に一度 → 担当者が実態と合っているか確認し、形骸化していれば廃止を検討する

「いつ見直すか」「見直したら何をするか」までドキュメントに含めておくことで、改善のきっかけを外部の誰かの判断に依存せず、仕組みとして回せるようになります。

ソフトウェア開発の文脈では、この考え方を実践する手法として ADR（Architecture Decision Records） があります。設計判断の「背景・選択肢・採用理由・トレードオフ」をドキュメントに残す文化で、「なぜ」を組織の資産として蓄積していく具体的なアプローチのひとつです。

まとめ

「なぜ」を残すことは、単なる記録の話ではありません。改善が回り続けるための必須条件です。

「なぜ」のないドキュメントだけが残った組織では、課題は解決されないままドキュメントが増え続けます。 「なぜ」を残しておけば、状況が変わったときに「このドキュメントはもう役目を終えた」と正しく判断できます。 その判断が積み重なって、組織は少しずつ前に進めます。

積極的に「なぜのないムダなドキュメント」を廃止していくこと——それ自体が、組織の健全性を保つための重要な仕事のひとつです。