テクニカルライター・ドキュメント担当 · 業務ごと

リファレンスを起草する

これはこのサイトで最も晒された「書く業務」である。真実の出どころが機械可読で、出力の形式が決まっているからである。関数の宣言から引数の表をつくることは、モデルよりずっと前から文書生成の道具によって部分的に自動化されていた。モデルが足したのは、人が書いたように読める文章であり、それが、人に書かせる最後の理由を取り除いた。

生成されたリファレンスとは、公開の前に誰も読まなかったリファレンスである。そして失敗の形は、間違っていることではなく、もっともらしいことである——コードが実際に何をするかではなく、コードが何を宣言しているかを述べた文書である。その隔たりは、それを実際に使う人にしか見つからない——それが下の業務である。だからここを自動化することは、この職を取り除くのではなく、そちらの価値を上げる。

自分が書いているものを実際に使ってみる

この業務の入力は、どのリポジトリにも存在しない——特定の場所で戸惑うという経験である。そのコードベースで学習したモデルは、エンジニアの知識を受け継ぐ。そしてそれこそ、この試験が働くために欠けていなければならない知識である——ここでの価値は、知らないことから来ている。

この業務は、この職業にとって最も強い論拠であり、予算の会議では最も弱い論拠である。その成果が「ないこと」——起きなかった問い合わせ——だからである。文書のチームが削られた場所で真っ先に消えたのはこの業務であり、そのために技術は何一つ要らなかった。

何を書かないかを決める

生成が安くなったことは、これを最も価値の低い業務ではなく最も価値の高い業務にする。制約が移ったからである——すべてを書くことが可能になった瞬間、選ぶことが仕事のすべてになった。何を落とすかを決めることは、どんな利用者がいて、その人たちが何をしようとしているかを知っていることに依っており、それはコードのなかにない。

価値が上がることと、認められることは別である——文書はたいてい網羅率で測られ、そして網羅率こそ、安い生成が無意味にする指標である。公開したページ数で判断されるチームは、この業務が重要になったまさにその瞬間に、それを手放すことで報われる。

エンジニアから答えを引き出す

必要な情報は、定義からして文書化されていない——書かれていたなら、この業務は存在しない。それを引き出すことは、誰かの予定表に対して行われる社会的な行為であり、そして技能は、建前の答えではなく本当の答えを引き出す問いがどれかを知っていることである。

この業務こそ、この職を、遠隔で、短時間で、外部の請負の席からやりにくくしているものである——そしてそれはまさに、費用の圧力が押していく方向である。ここでの脅威は自動化ではない。この職が、この業務を含められない形に組み替えられることであり、そのあと文書は劣化する——そして誰もその原因を正しく帰属しない。