事例からは、書けなかった——書けたのは、自分の中にあるものだけだった

前回までのあらすじ

導入事例をAIに読ませて、検討中の当事者になりきって質問を作らせる——そんな取り組みをしました。質問は1,527問まで膨らみ、読み込んで9割を捨てました。残ったのは、答えると決めた761問。販売・制作パートナー向けに移した139問。そして、その質問群に回答する、こちらから提示できるノウハウ集——ティップスの34記事を作ろう、という試みです。具体的には、当事者の振りをしたAIが作成した質問に対して、人間である私が回答することで完成できる、という目論見でした。

「書き始めは、ティップスからにします」。そう締めたのが前回でした。

書き始める前に、方針を変えた

宣言どおり、ティップスになりそうな質問に、回答を書き始めるつもりでした。ところが改めて質問を読むと、どれもとても生々しい、具体的な案件の話になっています。回答を書いても、ティップスとして公開できるものにはならなそうでした。

その中でも、一般的な質問として使えそうなものを精査していくと、writeWiredの開発方法についての質問でした。これをまとめて、プラクティスパターンのような一つのものにする、と方向を変えました。1パターン1ページ。目次を起こすと、51本になりました。

51本のうち、21本は形になった

このプラクティスパターンの内容で比較的まとめやすかったのは、データの持ち方の話と、テンプレートの作り方の話の分野の計21本で、とりあえずは形になったので、その日のうちに、いったんサイトコンテンツとして公開しました。

残りの30本が、全部だめだった

残りは、権限、移行、外部連携、運用、プロジェクトの進め方。この30本は、種と手元の実装を元にAIに書かせて、私が読んで直す形で進めました。当初の目論見——AIの質問に、人間の私が答える——からは、ここで離れています。事例からパターンに方向を変えたのだから、書く作業ごとAIに任せてよいだろう、と考えたのです。

書き上がった30本を読み返すと、何が言いたいのか分かりません。書かせた本人の私が読んでも、です。

だめだった理由は、三つです。

• 方法論を上から言っているだけで、参考にならない。読んだ本人の私が、そう感じました
• 当たり前の要望に、当たり前の答えを書いていた。読む価値のある差分がありません
• 困りごとの場面が書けない。手元に残っているのは解決した後の実装だけで、以前の失敗はどこにも残っていません。書こうとすると、創作になります

捨てる前に、直せないかと粘りました。製品ではこう動く、という答えの欄を足してみる。語り口を、体験談の形に変えてみる。「例えばこんな場合」と、具体的なケースから書き出してみる。実際の案件の実装から、具体例を掘り出して入れてみる。

どの手も、同じ壁に当たりました。具体的にすれば創作か、生々しくて出せない話になり、一般化すれば当たり前の話になる。書く材料が、そもそも手元にないのです。

それで、認めました。30本書いて、残ったのは0本です。粘った跡は、無駄にはなりませんでした。この途中で作った「writeWiredでは」の欄と「例えばこんな使い方」の欄は、後に残るページの型として生きています。

書けない理由は、事例の側にあった

書き始めに感じた生々しさの正体が、ここではっきりします。前回の実験で、事例から当事者の文脈は抽出できました。それは本当です。ただ、抽出できることと、コンテンツとして使えることは、別でした。

事例の中身は、生々しいのです。話は特定の会社に固有です。名詞を伏せても、たとえばフォームの構成の組み合わせだけで、どの会社の話か分かってしまいます。前回、パートナー向けの資産として選り分けた139問も、読み直すと、そのまま使えるものではありませんでした。

事例からノウハウを抽出する計画は、素材の時点で無理がありました。やるなら、事例そのものの書き方を先に決める必要があります。事実だけを、一定の粒度で書く。読み物ではなく、データとして設計された事例です。

質問させて、私が答えることにした

実は、残った21本にも問題がありました。形にはなっているのですが、読み直すと薄いのです。どう作るかは書いてあるけれど、なぜそう作るのかがありません。そして、その「なぜ」を足せるのは私だけだ、ということを、30本の失敗が教えてくれていました。

そこで、残った21本を、私の言葉で書き直すことにしました。書き直しの前に整理をして、2本は近いページへ統合、5本は取り下げました。残った14本を書き直し、その途中で、新たに1本を書き加えています。

AIに質問させて、私が答える。1本ずつ質問が来て、私は思ったまま喋る。整理と清書は、AIの仕事です。一日で一周できました。

一周まわって、当初の目論見の形——AIが質問して、私が答える——に戻ってきたわけです。変わったのは質問の元です。事例ではなく、書き直す14本そのものが、質問の元になりました。

一人で書くと、言いたいことを端的に言って終わります。質問が外から来ると、自分では自分に聞かない問いが来ます。その設計で、何を守っているのか。やらないと決めていることは、何か。答えているうちに、書いたことのない言葉が出てきました。

• writeWiredは、ページで情報を管理しません。データ設計が、一番重要です——集の序文になりました
• エディターに自由に書かれたテキストを除けば、writeWiredの情報は、すべてマスタとして管理されます
• パッケージの機能が、サイト構築の足かせになってはならぬ——既製のメニュー機能やバナー機能を作らない理由です。20年やってきて、初めて文章にしました

ついでに、ページの型も変えました。もともと「どんなとき」「困ること」「こう考える」と見出しで小分けにする形式は、AIが提案したものです。項目に分かれていると、AIには書きやすく、管理もしやすい。私もそれに乗って、内容を見出しに振り分けることにこだわっていました。

でも、読み手には一息で読めません。見出しの小分けは、書き手と管理の都合であって、読み物の形ではなかったのです。見出しをぜんぶ取って、一つの本文に書き直しました。

総括——残ったのは15本と、名前

51本の目次の行き先です。

これに、整理の中で新しく書いた1本を足して、公開は15本。集の名前は「設計リファレンス」に変えました。事例のリファレンスでは、なくなったからです。

これで、このサイトのリファレンスは三つになりました。FAQは問答、機能リファレンスは事実、設計リファレンスは考え方です。

作り方も、三つとも違います。機能リファレンスは、製品の実物を台帳に棚卸しして、AIで一気に書き出しました。FAQは、AIに質問を作らせて、答えには根拠になるコンテンツを張りました。そして設計リファレンスは、AIに質問させて、人間の私が答えました。事実は台帳から、問答は根拠から、考え方は人の口から、です。

今回、分かったことがあります。今の導入事例は、再利用を前提に書かれていません。だから、抽出しても使えるものにならなかったのです。事例を資産にするには、先に、再利用するためのルールの策定が要ります。

もう一つ。困りごとや、判断の背景のような経験は、文章としてはどこにも残っていません。書けるのは、経験した本人だけです。

振り返っての印象は、こうです。目次をAIの目線で作ることは、できました。ただ、ノウハウの中身は、やはり人が書く必要があります。総量を先に出して、インタビュー形式でAIと進めて、清書はAIに任せる。この分担で、いいものができたと思っています。

見送りにした30本は、消していません。実際の案件の話を、公開できる形で添えられるようになったら、そこから書き直します。

この先の進め方は、少し考えます。ひとまず、ここで一区切りです。