ドキュメントツールを導入したのに誰も書かない——失敗する本質的な理由
2026.06.08執筆者：DigKnow株式会社 CTO 桑原 脩
「今度こそちゃんと書こう」と言って、ドキュメントツールを導入します。最初の一ヶ月は活気があり、テンプレートが整備され、初期ページが立ち上がり、「ここに書いていきましょう」とアナウンスが流れます。ところが半年後、そのスペースを開くと、更新日が半年前で止まったページが並んでいます。私自身、何度か立ち会ってきた光景です。ツールを入れたはずなのに、なぜこうなるのでしょうか。
ツールを入れた直後だけドキュメントが増える、という現象
多くの開発組織で、一度は同じ経験があるはずです。Confluence、Notion、Kibela、Backlog Wiki、esa、GitHub Wiki——使うツールは違っても、たどる軌跡はよく似ています。
導入初月は、ページ数のグラフがきれいに右肩上がりになります。「やっと情報が一箇所に集まる」という高揚感のなかで、主要メンバーが手を動かします。
問題は三ヶ月目あたりから始まります。新規ページの増加速度が鈍り、半年経つ頃には数週間に一度誰かが思い出したように更新するだけになり、一年後にはほとんどのページが「これ、今も正しいのだろうか」と疑いながら読むしかない状態になっています。
ツール自体に機能的な欠陥があるわけではありません。検索も権限管理もテンプレートも揃っています。それでも書かれなくなる。ツールの問題ではなく、ツールが乗っかっている前提の問題だと言ったほうが実態に近いのです。
その前提とは、「誰かが書く」という意思です。ところが実際の現場では、その「書く意思」そのものが構造的に細い。実装・レビュー・障害対応はいずれも「今日中」という圧力がかかります。それらに比べて、ドキュメントは「今日書かなくても、今日は誰も困らない」という性質を持っています。この力学はツールを入れても変わりません。
書いても「読まれない」ことが、次の書き手を静かに止める
書く意思が細いとしても、最初の数ヶ月は何人かが頑張って書きます。ここで起きる次の問題が、書かれたものが読まれないことによる書き手の学習です。
私が観察してきた範囲では、初期に熱心に書くのは一部のメンバー——感覚値で1〜2割——に限られます。彼らは使命感で書きますが、数ヶ月後、質問対応をしていて気づきます。「この話、ドキュメントに書いてあるんですけど」と答える場面が減っていない。チームメンバーはそもそもドキュメントを検索していないのです。詳しい人に直接聞くほうが速いからです。
ここで書き手の内部に小さな諦めが生まれます。「あれだけ時間をかけて書いたのに、読まれないのか」と。一度この学習が起きると、次のページを書き始めるハードルが静かに上がります。書いても読まれない経験の累積が、書くモチベーションを底から掘り崩しているのです。
ツールはこの問題を検知できません。ページ数や閲覧数は記録されますが、「熱心な書き手が疲弊している」という内側の変化は、ダッシュボードに現れません。
古いドキュメントはないより悪い——信頼が一度消えると戻らない
腐ったドキュメントが並び始めると、ドキュメントツール全体への信頼が単調減少する局面に入ります。ここが一番厄介な段階です。
あるページを開いて、最終更新が八ヶ月前だとわかる。書かれた内容は、今のコードと整合しているでしょうか。「たぶん、ところどころずれている」——この不確実性を抱えたまま情報を信用するのは、エンジニアにとっては相当コストが高い。次第に、開発者はドキュメントツールを開く前に、まずコードとSlackの過去ログを見るようになります。
一度この回路ができると、元には戻りません。こうなると、ドキュメントツールは書かれていないから読まれないのではなく、信用されていないから読まれない状態へ移行します。
多くの組織で繰り返し起きている「ConfluenceからNotionへ乗り換える」ような判断も、この構造を理解していないと同じ結末をたどります。ツールを変えても、書く意思が細く、書いても読まれず、古くなったら信用されなくなる、という三段階のサイクルは変わらないのです。乗り換え直後の初月だけ元気なグラフが描かれて、半年後に同じ静寂が訪れます。
AIコーディング時代に、このサイクルはもう一段速く回る
ここまでの構造はAI以前からありました。ただ、AIコーディングが日常になった現在、同じサイクルがより速く、より深刻に回るようになっています。
理由は二つあります。
①コードの変化速度が上がったこと。Claude CodeやGitHub Copilotによって実装スピードが上がると、書き換えられるコードの量が増えます。その分、既存ドキュメントが実態と乖離する速度も上がります。「古くなる前に書き直せばいい」は理屈としては正しいのですが、書き直す速度が実装速度に追いつくかというと、追いつきません。ドキュメントが腐る半減期が、構造的に短くなっています。
②書くべき「なぜ」そのものが、書き手の中に残っていないケースが増えたこと。AIとの対話で生まれたコードについて、書いた本人が三週間後に細部の理由を即答できない——という現象は、AIコーディングを日常的に使っているエンジニアなら思い当たるはずです。
書くコストは変わらないまま、書く対象の量が増え、書くべき内容の言語化難易度が上がっている。ツール側の基本的な編集体験は数年前と大きく変わっておらず、AI時代の開発速度に、AI以前の設計思想のドキュメントツールで追いつこうとしている——というのが、今多くの現場で起きていることの正体だと、私は捉えています。
ツールを入れる前に、問うべきだったこと
ここまでの構造を踏まえると、ツール導入を検討する組織が導入前に問うべきだった問いがはっきりしてきます。それは「どのツールを選ぶか」ではありません。「書く行為を、誰が、どのインセンティブで、どのタイミングで、どのくらいのコストで担うのか」という問いです。この問いに具体的に答えられないまま導入すると、どれだけ評判のいいツールを選んでもほぼ確実に空洞化します。
そしてもう一つ踏み込むなら、「そもそも人間が書かなくても、ドキュメント相当のものが残る設計はできないか」という問いがあります。コミット履歴、PRの議論、テストコード、AIとの対話ログ——開発過程で自然に発生する情報は、すでにかなり豊富です。それらを素材として「なぜこのコードがこうなっているか」を復元できる仕組みがあれば、書く意思の細さや読まれない諦めといった人間側の構造問題を、ある程度迂回できる可能性があります。この方向性については、今後の記事で順を追って掘り下げていきます。
ツールを導入したのに誰も書かないという現象が教えてくれるのは、ツールが乗っかっている前提——「誰かが、継続的に、書く意思を持って書き続ける」——そのものが現場では成立していない、というシンプルな事実です。この事実に向き合うところから、次のやり方が見え始めるのではないかと、私は思っています。
まとめ
ドキュメントツールを導入しても誰も書かない現象の本質は、ツールが乗っかっている前提の問題です。書く意思の細さ・読まれない諦め・信頼の消失——この三段階のサイクルで空洞化が進みます。AI時代にはコードの変化速度が上がり、書き手の中の「なぜ」が曖昧になることで、このサイクルはより速く回ります。問うべきだったのは「どのツールを選ぶか」ではなく、「書く行為を誰がどのインセンティブで担うのか」という構造の側です。
あなたのチームのドキュメントツール、一番新しいページの更新日はいつですか。そしてその更新日を見たとき、その内容をどれくらい信用していますか。次回は、この問題のもう一つの定番アプローチ——「ドキュメントを書く文化を作ろう」という号令が、なぜ毎回同じように失敗するのかを、文化という言葉に逃げずに解剖していきます。