オーバードキュメンテーション
かつて私は、ドキュメント is 説明の自動化というエントリを書きました。
同じ説明を何度も口頭で繰り返すコストをなくし、自分が不在でも現場が回るようにするドキュメント化こそが正義である、と。
自分の頭の中に情報を囲い込み、都度「分からないことは何でも聞いてね」と確認を強いてボトルネックを生むのに対し、情報をオープンな場所に書き出して誰でも非同期に参照できるようにするほうが圧倒的に効率的であるはずでした。
もちろん、単に文字として書き出すだけでなく、不要な情報を削ぎ落としたり適切に管理したりすることがなければ質の高いドキュメントにならないことは理解していました。
それでも、不正確さは他人の仕事を増やすのだから、暗黙知を言語化してドキュメントとして残す行為そのものは、善であると信じていたのです。
しかし先日、とあるプロジェクトで数十万文字にも及ぶ、極めて緻密に書き込まれた仕様書群を目の当たりにしたとき、私の頭の中にまったく逆の疑問が湧いてきました。
「これ、ドキュメントが丁寧すぎて、逆に何も伝わらなくなっていないか？」
そこに広がっていたのは、要件定義から概念設計、用語の定義、パッケージ構成、例外ケースの網羅に至るまで、隙なく書き込まれているように見える文字列の大海原でした。
いくら文章を読み進めていってもブラウザのスクロールバーは這うようにしか動きません。
書いた側からすれば、仕事としてのアウトプット量は十分なのかもしれません。
しかし、いざそれを前にして自分が手を動かそうとしたり、新しく参画した人が全体像を掴もうとしたりすると、途方もない疲労感に襲われます。
読むだけで数日を要し、仕様を一つ確認するために無数のページを行き来させられ、コードを一行書くたびに「仕様書のどの制約に引っかかるか」を照合しなければなりません。
情報の抜け漏れを防ぎ、誰が見ても誤解のないようにと正確さを突き詰めた結果、かえって人間には読まれなくなります。
「10分で読む名著」みたいなダイジェストは読まれますが、その原典はほとんどの人が読まないのと同じように。
なぜ、理解を助けるために書かれたはずのドキュメントが、かえって人間の理解を拒むものになってしまうのでしょうか。
その理由を掘り下げていくと、「言葉」という仕組みそのものが抱えるトレードオフに行き当たります。
言葉の正確性と伝達性は、トレードオフになっているのです。
言葉とは本来、グラデーションに満ちた現実を、限られた記号に丸め込む「非可逆圧縮」のツールです。
「これ、いい感じにしといて」「ヤバいバグが出た」といった言葉は、情報量として十数文字しかありません。
それでも一瞬で相手に通じるのは、お互いが現場の文脈(コンテキスト)や暗黙の了解という「復号キー」を共有しているからです。
あえて言葉の解像度や正確性を落とす代わりに、圧倒的な伝達スピードを手に入れているわけです。
そもそも、100パーセント正確で厳密な答えは、聞き手が話し手と同じくらいすべての詳細に精通していない限り、激しい認知の摩擦を引き起こします。
一方で、大まかに芯を捉えた比喩やメタファーは、少しのフィクションを導入するリスクと引き換えに、その摩擦を取り除いてくれます。
たとえば、おじいちゃんおばあちゃんに「インターネットって何？」と聞かれたとき、TCP/IPやパケット、ルーターやDNSの仕組みから説明し始めたら、相手はまず聞く気をなくします。
それよりも「世界中のコンピュータをつなぐ道路みたいなもので、そこを手紙や写真が小包になって運ばれていく」と言ったほうが、はるかに伝わります。
厳密には道路も小包も存在しませんし、データは細切れにされてバラバラの道を通ったりもしますが、聞き手が知りたいのはそこではないのです。
そうした適度な嘘や曖昧さというクッションを挟むことで、私たちは辛うじて他人とのやり取りを成立させているのです。
では逆に、そうした曖昧さを一切許さず、「誰が読んでも絶対に誤解が生じないようにしよう」とするとどうなるでしょうか。
相手が復号キーを持っている前提に頼れないので、復号キーそのものまで文字に起こして同梱しようとすることになります。
しかし、文字に起こしたその復号キーもまた「言葉」で書かれている以上、それを誤解なく読むための別の復号キーが必要になるという無限後退から逃れられません。
先ほどのインターネットの例でいえば、その仕組みを本気で正確に説明しようとすると、技術仕様をまとめたRFCという文書群だけでも9000を超える文書が存在し、途方もない文字数になります。
しかもRFCには、文中の「MUST」や「SHOULD」といった単語をどういう意味で使うのかを定義するためだけのRFC(RFC 2119)まで存在します。
そして当然、そのRFC 2119自体も英語という「言葉」で書かれているわけです。
そもそも「定義する(define)」という英単語が「終わらせる(finish)」と同じ語源(終わり・境界)を持っている通り、定義とは完全にはならない言葉を、とりあえずこのあたりで打ち止めにして仮決めしておく程度の意味しかありません。
だとすれば、流動的な文脈を一時的に凍結させるオントロジーは道具としては有用でも、それで実務を言葉で定義し尽くせると考えた時点で、発想が最初から破綻しているのだと思います。
たとえば業務の知識を整理しようとして、「手順」と「決まり」という二つのカテゴリに分けて定義したとしましょう。
一見すると綺麗に分類できているようですが、普通に考えれば「手順」は「決まり」の中の一つです。
現実はそうしたグラデーションと重なりの塊なのに、それを無理やり別々の箱に切り分けようとするから、「どこまでが手順で、どこからが決まりなのか」という不毛な境界線の定義や例外規定が雪だるま式に増え、文章は何十倍、何百倍にも膨れ上がります。
その極致が、六法全書の条文や、誰も読まないソフトウェアの利用規約です。
法的なトラブルを防ぐために正確性を突き詰めた結果、専門家ですら読むのが嫌になる長大な文章が出来上がります。
スッと頭に入ってくる伝達性は、そこにはほとんど残っていません。
しかも、書き尽くした側は「抜け漏れなく言語化した」という安心と免責を得られる一方で、膨大な記述を読み解いて照合する手間は、すべて読み手に回ってきます。
正確さの追求は、書き手の安心のために読み手の時間を差し出させる行為にもなり得るのです。
さらに皮肉なのは、そこまでして伝達性を犠牲にしたところで、肝心の「正確性」すら手に入らないということです。
ドキュメントの量が増えれば増えるほど、あちらのページで定義した前提とこちらのページで定めた制約が食い違ったり、細かく規定しようとしたせいでかえって「じゃあこの場合はどうなるのか」という未決事項が次々に噴出したりするようになります。
言葉で境界線を引くたびに、その境界線同士がどこかで重なり、矛盾が生まれます。
ルールAとルールBを両方守ろうとすると、両方は守れない場面が必ず出てきます。
六法全書ですら、条文だけで現実を矛盾なく定義し切ることはできないからこそ、裁判官や弁護士という「人間による解釈」が不可欠になっているわけです。
実際の裁判でも、条文だけでは白黒つけられない場面ばかりだからこそ、過去の具体的な判断の積み重ねである「判例」に頼ることになります。
しかも、そうして例外を埋めるために蓄積された判例もまた膨大な山となり、個別の状況や時代によって判例同士が食い違ったり、後から覆ったりするのです。
どれほど言葉を尽くしてルールや前例を書き足したところで、書き足すほど正確になるのではなく、矛盾の発生源が増えていくだけです。
正確性を求めて伝達性を差し出したのに、その正確性すら手に入っていない。
この構図は、前回書いた慣習法と成文法の話にもそのままつながります。
社会の日常(正常系)を動かしているのは、法律の条文ではなく、人々の間にある暗黙の了解や良識(慣習法)です。
成文法は、その阿吽の呼吸が破綻したときのための「例外処理」に過ぎません。
それなのに「ルールで縛らなければ信用できない」と例外処理を増設し続けた結果、社会は手続きの摩擦で身動きが取れなくなっていきます。
オーバードキュメンテーションは、システム開発における「過剰な成文法化」そのものです。
「誤解されたら困る」「例外が起きたら困る」と恐れるあまり、あらゆる前提やエッジケースをドキュメントという名のcatch節で埋め尽くしてしまう。
その結果、現場の常識や阿吽の呼吸で回っていたはずの正常系の開発が、例外規定の山に埋もれて人間には扱えないものになってしまうのです。
ドキュメントを書くのをやめて、すべてを口頭や個人の勘に頼ればいいのかというと、もちろんそうではありません。
言語化とは、現実のすべてを白黒はっきり塗り分けるのではなく、どこまでを言葉にして、どこからをグレーゾーンとして残すか、その境界線を引く作業なのだと思います。
では、その境界線をどこに引けばいいのか。
結局のところ、それは書き手のバランス感覚に委ねるしかありません。
そして、そのバランス感覚の正体は、「書き手が最初の読み手であり続けること」なのではないでしょうか。
自分で読み返す気にもならない量を、他人に読ませようとするのは無理があります。
レシピに「塩少々」と書いてあるのは手抜きではなく、料理人の舌と素材の状態に委ねるための余白です。
「塩化ナトリウムを0.85グラム投入せよ」と書かれたレシピは、一見正確でも、素材の個体差には対応できません。
もちろん、パンやお菓子作りならグラム単位で量ったほうがうまくいきます。
ただそれは、小麦粉や砂糖、ベーキングパウダーといった、規格化された化学物質に近い材料を扱っているからです。
個体差のある野菜や肉を相手にする料理では、その正確さは通用しません。
システム開発でも、実装する人の野生の思考が入り込む余地を残しておかないと、変化に弱いものになってしまいます。
ただ、AIの登場によって、そうした余白はますます残りにくくなっています。
AIに「この機能の仕様書を詳しく書いて」と頼めば、本来グレーゾーンとして残すべきところまで律儀に埋め尽くした、人間なら何日もかかる量のドキュメントが数分で大量に出てきます。
かつては「書くこと」自体に相応の労力が必要だったため、書き手の理解を超える量のドキュメントは物理的に生まれにくいというブレーキがありました。
しかし今は、自分自身の理解が追いついていなくても、AIを使えばもっともらしいアウトプットを一瞬で生み出せてしまいます。
出力のハードルが極端に下がった一方で、それを読み解く人間の脳の処理速度は昔から何も変わっていません。
その結果、人間が誰も全体を把握できないまま、AIが書いたものをAIだけが読み、AIだけが実装し、開発だけが進んでいってしまいます。
「人間が読めないならAIに読ませればいい」という声も聞こえてきそうです。
しかし、AIに読ませたところで、人間が最後に受け取るのは結局AIによる要約、つまり「10分で読む名著」のほうです。
正確さを突き詰めて書いたはずの原典は、誰にも読まれないまま非可逆圧縮されて人間に届くことになります。
さらにたちの悪いことに、仕事の成果というものは基本的に「目に見えるアウトプット」でしか測られないようになっています。
100ページのプレゼン資料や分厚い仕様書を作る作業には分かりやすく得点が入りますが、誰かが作ったその100ページを必死に読み込んで理解する作業には1点も入りません。
どれだけ時間をかけてインプットしたところで、そこからまた別の資料や指摘事項といった「何かしらのアウトプット」をひねり出さない限り、仕事をしたとは見なされないのです。
真面目に読んで理解しようとすればするほど評価から取り残され、認知を置き去りにしてでもAIでアウトプットを量産したほうが仕事をしたことになる。
そんな環境に置かれれば、誰もが「読む側」のババを引くのを避け、「出す側」に回ろうとするのは当然の帰結です。
こうして、お互いの理解を犠牲にしたまま成果物だけをぶつけ合う「アウトプットバトル」が繰り広げられ、誰にも読まれないドキュメントばかりがさらに積み上がっていくことになります。
かく言う私も、このブログでAIを使い始めてから1記事あたりの文字数が明らかに増えています。
そして、そうやって膨れ上がったこの文章自体が、すでにオーバードキュメンテーションになってしまっている気もします。