このサイトの記事は、私が指示を出してAIが書いています。
始めるとき、記事の形を先に決めました。どの記事も同じ構成にすれば、書くのも読むのも楽になると考えたからです。
1本目を作った時点で、合わなくなりました。
制服を先に発注した
今回は制服のたとえで通します。
新しく人を雇うことになって、制服を用意します。まだ誰が来るか決まっていないので、標準的な体型を想定して、まとめて発注しておく。
来た人に着せてみると、袖が余る人と、丈が足りない人がいます。
発注そのものが間違っていたわけではありません。ただ、着る人を見る前に寸法を決めていた、というだけです。
私が3回やったのは、これです。
失敗の枠を、失敗していない記事に当てはめた
最初に決めたのは、記事の冒頭に置く表でした。
このサイトは、AIに実務をやらせた記録を書くところです。うまくいかなかった話が中心になります。そこで、冒頭に「何が起きたか」「原因」「結果」を並べた表を置くことにしました。読者が最初に要点をつかめる形です。
1本目の記事に当てはめてみました。
その記事は、失敗の話ではありませんでした。結果の欄に良い話が入り、原因の欄に悪い話が入る。読むと、何が言いたいのか分からない形になっていました。
失敗を前提にした枠を、失敗していない記事にも当てはめようとしたからです。
いまは、この表は失敗を扱う記事にだけ使っています。すべての記事には、内容に縛られない形の枠を置くことにしました。
制服を一種類だけ作って、全員に着せようとしたようなものです。
自分のやり方を、世の中の決まりとして書いた
2つ目は、記事の中身のほうです。
書いた記事に、事実と違う断定が入っていました。ドメインを変えると検索の評価がすべて失われる、という趣旨のものです。実際には、転送を適切に設定すれば引き継げます。
さらに洗い直すと、似た形の言い切りが3か所ありました。契約の話や手順の話で、私のやり方をそのまま一般の決まりとして書いていたのです。
私は毎回そうしている。それは事実です。ただ、誰もがそうなるとは限りません。
厄介なのは、この形の誤りが点検を通ってしまうことでした。文字数も見た目も問題なく、日本語としても自然です。書かれている内容が事実かどうかを確かめる工程が、当時はありませんでした。
いまは、公開する前に言い切りの表現を一覧にして、1件ずつ判定しています。公式の情報で確かめられるか、自分の環境で起きたことか、広く知られている事実か、そのどれでもないか。
最後のものが1つでもあれば、公開しません。
数えずに書いた件数を出した
3つ目は、記事ではなく報告のほうです。
作業を統括する側へ出す書類に、手元の書類が何件あるかを書きました。34件と書いています。
実際は32件でした。数えずに、記憶で書いたのです。
指摘されて訂正しました。2件の差なので、大きく違ったわけではありません。ただ、その数字は判断の材料に使われるものでした。
制服の話に戻せば、実際に採寸せず、だいたいこれくらいだろうと見当をつけて発注したのと同じです。近い値ではあります。近いだけです。
いまは、報告に書く数字をすべて実測してから書かせています。実測できないものは、実測していないと明記する。
3つとも、先に決めて後から合わせようとした
共通しているのは、順番でした。
枠を先に決めて、記事を当てはめた。自分のやり方を先に一般化して、それを書いた。数字を先に書いて、確かめなかった。
どれも、決めるのが先で、確かめるのが後です。
いま、この順番を逆にしています。1本作ってから枠を決める。自分の環境で起きたことだけを書いて、一般化しない。数えてから書く。
制服なら、1人に試着してもらってから残りを発注する。それだけの話です。
それでも先に決めたくなる
とはいえ、先に決めたくなる気持ちも分かります。
枠が決まっていれば、記事を書くのが速くなります。一般化して書けば、文章が短く済みます。数字を記憶で書けば、数える手間が省けます。
どれも、決めた時点では正しい判断に見えます。実際、多くの場合はうまくいくのだと思います。
私の場合は、3回とも合いませんでした。速く進めようとして、直す作業が増えています。
いまも、新しい形を思いつくと先に決めたくなります。そのたびに、1本試してからにしています。
