こんにちは。画像は高知の仁淀川です。すごいきれい。
すでに本業ではテクニカルライティングはほとんどやっていない状況ですが、ありがたいことに副業ではライティングの機会を持っています。
もちろんAIをバンバン使って書きます。が、モデルが進歩しても、生成物に対して「イマイチだなー」と思う部分はけっこうある。
コーディングと比べると、ドキュメント、特にヘルプページのライティング領域は明らかにAIの進歩が遅いように感じます。
なぜ最新のモデルでも、生成したヘルプページがバシッと決まらないのかを考えてみます。
言い換えが難しい
プロダクトの仕様をコードベースから自然言語に起こす能力に関しては、AIは人間を完全に凌駕していると感じます。
ここで人間が張り合うのはほぼ無理に近い時代になりました。
ただ、AIが得意とするのは、あくまで「プロダクトの仕様」を「そのまま」自然言語に起こすことです。
そして、ヘルプページの表現というのは、得てして「プロダクトの仕様」そのままではないことが、けっこうあります。
例えば、複数の処理を一括で実行する機能があったとします。
ユーザー向けヘルプページであれば「一括処理」や「まとめて処理」などのワードチョイスをしたいところですが、コードベースで batch_process などと書いてある場合、AIは「バッチ処理」と平気で書いてきます。
仕様ドキュメントであれば「バッチ処理」でも構いませんが、ユーザー向けのドキュメントであれば、もう少し平易な言葉で書いたほうがいい場面もあります。
このように、コードベースの言葉遣いをそのまま出力してしまうケースは多く、イマイチだなと感じる部分になっています。
とはいえ、言い換えの部分は、モデルの進化や渡すコンテキスト、あとはユビキタス言語などが整備されていれば、一定緩和できるのも事実かなと思います。
工夫次第でなんとかなる部分ではありそう。
どこまで書くかの判断が難しい
ヘルプページは「仕様ドキュメント」とは異なる部分がある、という上述の話につながりますが、ヘルプページにはたとえ仕様であっても「あえて書かない」内容もあります。
例えば、かなりエッジケースのエラーがあったとします。
プロダクトの仕様としてエッジケースのエラーが存在するのは事実ですが、ユーザーに情報として伝えるか?は判断が入ります。
あまりにエッジケースであれば、ヘルプページには記載せず、ユーザーがドキュメントを読む際のノイズを減らすという判断をする場合もあります。
AIは、この判断が苦手かな〜と感じます。何がエッジケースで、何がクリティカルか。
書かんでもええやろというような細かい仕様やエラーまで記載してしまうこともあれば、これは書かんとアカンという内容が抜け落ちることも。
実際、この判断は意外と複雑で、考えることがいろいろあります。
- メインターゲットとする読み手は誰か。内容によってはターゲットを絞れず、包括的に書く必要もある
- 事象が発生する割合。どれくらいのユーザーが該当しそうか
- エラーに遭遇した場合の影響の大きさ。ユーザーの作業が止まってしまうか
- 既存の記載内容とのバランス。追記内容だけ極端に詳細に書いてしまっていないか
上記のようなことをあれこれ考え、最終的にステークホルダーの合意を得ながら書く・書かないの判断を下すことになります。
ここをAIが判断しきれないことがイマイチさにつながっているのかも。
テストができない
コーディングと比べて明らかに違う点はこれで、ヘルプページはテストができません。
コードについては、そもそもの仕様の正しさとは、という話はありますが、特定の処理が想定通りに動作するかを担保するためにテストを書けます。
テストは処理の正しさを論理的に示せるので、AIとしてはとにかくテストを満たすコードを生成すればよく、仕事がしやすい。
対してヘルプページというのは、テストが書けません。
最終的には「ユーザーが理解できること」がゴールなわけですが、そのゴールを論理的なテストに落とし込むのはかなり困難に思います。
つまり、ヘルプページは「絶対的な正しさ」を定義できません。
ゴールを定義できないので、成果物もブレやすい性質があるように思います。
もちろんAIをレビュアーとして使って「hogeでも理解できるようにドキュメントを書いて」とお願いすることはできますが、本質的な正しさの担保にはならなさそう。
textlintなどのlinterはありますが、文法の正しさなどをチェックしてくれるだけで、内容の正しさは担保できません。
書いていて思いましたが、これはAIの問題というよりも、テクニカルライティングが持つあいまいさが問題な気もします。
視点を選べない
現時点では、AIを使ったライティングを行うとしても、その起点は人間が持っているケースが多いと思います。
「hogeができるようになったのでドキュメントを書いて」という「依頼」は発生するかなと。ほぼフルオートでドキュメントを整備する環境でも、起点となるなんらかの情報は渡すはず。
この起点となる情報、つまりヘルプページを書く際の「与える情報の視点」が、人間に依存するのがイマイチなヘルプページにつながる要因のひとつとも考えています。
例えば、複数の機能に対して横断的にサブ機能を追加する場合。
開発チーム的には「サブ機能をリリースした」という認知でも、ユーザーからは「異なるいろいろな機能で新しいことができるようになった」という見え方をすることがあります。
ここで、AIに「サブ機能をリリースしたのでヘルプページを書いて」という情報を渡してヘルプページを書くと、サブ機能に関するペライチの新規ページが生成されがちです。
もちろんそれが望ましい場合もあるのですが、複数の機能ページにそれぞれサブ機能に関する情報を追記したほうがいいケースもあります。
書く視点を決めるのが人間に依存しがちなので、生成されるヘルプページの構成が、人間の認知やスキルによってブレるところが課題としてあるのかなと思っています。
このような話は、哲学の問題として知られる「フレーム問題」にも関連するのかな、という気はしています。
フレーム問題は、人工知能は「ある事象の関連性や重要性を完全に論理的には選び出せない」というような問題で、けっこう有名です。
AIはまだ視点を柔軟に選べない気がします。視点が選べないので、「誰にとって」「どんな事柄が」「どれくらい関連するか」という判断も、完全にはできないのかなと思っています。
もちろん既存のドキュメントからある程度察してもらうことは可能ですが、新機能のドキュメントを起こす場合などはそれも難しい。
まとめ
書いていてふと思いましたが、「ある専門性における、アウトプットそのものの作成が占める割合」が多いほうが、相対的にAIが得意に見える、というのはあるのかもしれません。
例えば「プログラミング」のスキルは、もちろん設計フェーズも重要ですが、言語の文法など、アウトプット生成自体に関するスキルも多くを占めていたと思います。
対してライティングは、アウトプット生成が専門性に占める割合は、正直かなり少ないです。コードと違って日本語は多くの人が書けます。
AIが書くヘルプページがイマイチに見えるのは、モデルが文章を書けないからではなく、ライティングの専門性が「何を・どこまで・誰の視点で書くか」に偏っているからなのかもしれません。
いろいろ書きましたが、半年後・1年後はどうなっているかわかりませんし、すでに完璧なヘルプページをラクラク書ける方法があって、自分が知らないだけかもしれません。
研究は続けていきたいですね。