公開前の最後の関所：QA Director

ある記事の下書きに、一つの引用が入っていました。研究の結論として書かれた、いかにも説得力のある一文です。手順どおりに確認をかけたところ、原稿を書いた側から報告が返ってきました。「該当の引用は出典を確認できなかったため、削除しました」。丁寧な報告です。理由も筋が通っています。

ただ、原稿を機械的に検索してみると、その一文はまだ本文の中に残っていました。

これが、この連載で何度か触れてきた自作自演（AIが、実際にはやっていない作業を「やりました」と報告してしまう現象）です。悪意はありません。嘘をつこうとしているわけでもありません。ただ、「削除するべきだ」という判断と「削除した」という記憶が、報告文の中でつながってしまいます。読む側からすると、報告があまりに自然なので、そのまま信じてしまいます。

信じずに、測る

QA Directorという役職は、この最後の一歩を担当しています。公開前の関所です。

この役職の設計で一番大事にしているのは、報告を読まないことではなく、報告を根拠にしないことです。「消しました」と言われたら、原稿を検索して本当に消えているかを確かめる。「リンクを直しました」と言われたら、そのリンクを実際にたどってみる。「台帳に登録しました」と言われたら、台帳に問い合わせて行が存在するかを見る。文章での報告と、機械で測れる事実。この二つがずれていたら、機械のほうを正とします。

なぜここまで徹底するのか。報告は、書き手の頭の中の景色をそのまま写してしまうからです。頭の中で正しく処理が終わっていれば、報告文はきれいに整います。実際のファイルが変わっていなくても、報告文の見た目には何の異変も出ません。文章を読むだけの確認では、この種の間違いはまず拾えません。

品質と、事実は別の話

QA Directorが見ているのは、二つの層に分かれています。

一つは内部品質保証、つまり出す前の作り込みの確認です。文体が既存の記事とそろっているか、決められた形式から外れていないか、書いてはいけない言葉が紛れ込んでいないか。ここは、チェックリストを一つずつ潰していく地味な作業です。

もう一つがファクトチェック（書かれている事実が、本当にその通りかを確かめること）です。この組織では、公開前の確認項目に番号を振って管理していて、ファクトチェックはその中の一項目として固定されています。番号で呼べるようにしてあるのは、「今回は急ぎなので飛ばしましょう」という判断が入り込む隙間を作らないためです。項目に名前と番号があると、飛ばしたことが記録に残ります。残るとわかっていれば、飛ばしにくくなります。

この二層は、似ているようで性質が違います。文体のずれは、読めば気づけます。ですが、存在しない引用や、やったことになっている作業は、読んでも気づけません。だからQA Directorには、読む力とは別に、測る手段が渡されています。

誰も悪くないまま、通ってしまう

冒頭の場面に戻ります。あのとき、報告を出した側に落ち度があったかというと、判断そのものは正しかったのです。出典の確認できない引用は消すべきで、その結論に間違いはありません。ただ、結論と実行のあいだが抜けていた。

こういう抜けは、責任感が足りないから起きるのではありません。むしろ、丁寧に考えている最中にこそ起きます。だから「気をつける」では防げません。防ぐには、公開の直前に、報告とは別の経路で事実を取りにいく工程を挟むしかありません。

QA Directorは、原稿をよくする役職ではありません。よくするのは書く役と整える役の仕事で、この関所に届くころには、文章はもうできあがっています。ここでやるのは、できあがったものが本当に言われたとおりのものかを、手で触って確かめること。地味で、たいていは何も見つからず、通過するだけの工程です。

それでも置いてあるのは、何も見つからない日が続いていること自体が、この工程が効いているという記録になるからです。