技術文書の書き方をプロのテクニカルライターに聞いてみた

今日はよろしくお願いします。世間ではテクニカルライターという職業に馴染みがない人も多いかもしれません。まずお仕事の内容と、テクニカルライターになったいきさつについて教えてください。

仲田です。テクニカルライターというのは、Webサービスやアプリの画面に書かれているテキストを考えたり、ヘルプサイト（製品やサービスの使い方を説明するウェブサイト）を作ったりするのが主な仕事です。

私自身は、新卒でサイボウズに入社して、初めはお客様の会社にシステムを構築する部署に配属されました。うちはメーカーなので、パートナー企業に技術支援をする機会も多かったのですが、当時はエンタープライズ（大規模企業向けのIT製品）対応を始めたばかりだったので、ノウハウがあまりなく、大規模な案件のためにドキュメントを書いたり、講師としてパートナー企業の担当者向けに話をさせてもらっていました。それが最初ですかね。技術的な文書を書ける人があまりいなかったのと、当時はまだトラブルがあれば朝までになんとかしてくれとか、そういう時代で（笑） 自分はいわゆる昔の強いエンジニアではなかったので、自然と書くほうにモチベーションが移っていったところがあります。そういう経験を経て、本格的にドキュメントを書く部署に異動しました。それからはひととおり製品のマニュアルを担当しましたね。

全社会人が学ぶべき研修資料

仲田さんといえば、新人研修用の資料がずいぶん話題になりましたよね。あれはどういう経緯で公開したものですか？

あれは毎年やっている新人研修の資料で、別に自分が公開したかったわけではなくて、どの部署も特に拒否しなければ公開されるんです。たまたまそれがバズったっていう。最初からテクニカルライターを目指して入社する人というのは少なくて、サイボウズではキャリアが柔軟に選べるので、エンジニアや営業からなる人もいますし、カスタマーサポートの部署から希望する人もいます。経理からテクニカルライターになる人もいます。新卒だと特にテクニカルライターとは何かみたいなところから、一から説明しないといけなくて。そういう背景があるので、私自身、マネージャとしていろんな研修コンテンツを持っていたんです。

当時ずいぶん注目されたと思いますが、バズったのはなぜだと思いますか？

ありがたいことに、そうですね。それで需要があるんだろうなとは思いました。自分だけじゃなくて、その頃他社のテクニカルライターの方が書いた記事なんかも注目されたりして。私もそうなんですが、文章を書くことを学ぶ機会って実はあまりないじゃないですか。あの資料がバズったので、デブサミ（注：日本最大のソフトウェア開発者のためのカンファレンス）にスピーカーとして出てもらえないかという話がきて、出たんですけどそこでもベストスピーカー賞をもらって、すごく評価してもらいました。やっぱりエンジニアって、ブログを書いたり、ドキュメントを書いたり、書くニーズはあるので、興味を持っている人は多いのではないかと。あと、デブサミはエンジニアが対象なんですが、エンジニアに限った話ではなくて、当時はコロナ禍だったので、テキストでのコミュニケーションの重要性が注目されたこともあって、全社会人が学ぶべき資料みたいなツイートもありました（笑）

文章のテクニックより情報の整理が大事

あらためて資料読ませてもらって、非常にわかりやすく誰にでも役に立つ内容だと思いました。しいていうなら、特にテクニカルな文書を書くうえで意識してほしいことはありますか？

「読み手のことを考える」がすべてだとは思うんですけど、けっこう、こういう書く系の話題って、わかりやすい文章とはみたいな話に行きがちだと思うんですけど、個人的に重要なのはそっちじゃないと思っていて。細かい技術でいうと文章の一文を短くとか係り受けとかいろいろあるんですけど、それをやったからといってわかりやすくなるかっていうと。読みやすくはなるけど、読みやすいとわかりやすいはまた別の話なんです。それよりも情報を整理することのほうが大事です。情報の階層や順番などを整理してきちんと話せば、多少文章が長くてもちゃんと伝わるので、個人的にはそちらに重点を置くようにしています。情報の整理のしかたについては、オライリーが出している「情報アーキテクチャ」などが参考になると思います。

ヘルプサイトに関していうと、SEOを意識することも必要になります。流入の50%は検索からなので。そうするとナビゲーションをわかりやすくすることよりも、いかに検索で見つけてもらいやすいように情報が整理されているかのほうが重要だったりします。記事のタイトルも例えば「アクセス権の設定」ではだめで、「掲示板にアクセス権を設定する」みたいに、それを探しているユーザーに最適な情報のまとまりを考える必要があります。そういう意味でも、細かい文章のテクニックを磨くよりも、いかに情報を整理するかを意識してもらったほうがいいかと。

テクニカルライティングの基本 2023年版より

プロダクトの価値を高めるのもテクニカルライターの仕事

今はソフトウェアの開発サイクルが以前に比べ短くなっていますが、テクニカルライティングにも影響はありますか？

昔はきちんと構成して、間違いがないことを確認して出していたのが、今は、ドキュメントも早く出して間違っていたらすぐ直すみたいなやり方に変わってきていますね。（現在ソフトウェア開発の手法で主流である）アジャイル開発っていつリリースされるかもわからないし、リリースされないこともありますからね。テクニカルライターとしては開発に追従するために、要件や開発の状況を常にキャッチアップしなければなりません。画面のスクリーンショットも多言語化の兼ね合いもあって、ほとんど使わない流れになっていますね。使う側にとっては不便かもしれないですけど（笑）。 最近はテクニカルライター界隈でDocs as Codeっていう考えがあって、ドキュメントもソースコードの一部として管理されるようになってきています。開発のリリースごとにソースコードが切り分けられるように、ドキュメントもリリースごとに切り分けられて、プロダクトのリリースとともにドキュメントもリリースされるわけです。そういう意味では、テクニカルライティングは開発に寄ってきているといえます。

開発寄りになるデメリットはないのでしょうか。例えばカスタマーサポート部門と連携しにくくなるとか。

おっしゃるとおり、カスタマーサポートへのお問い合わせを減らすのはヘルプサイトの大きな目的のひとつですから、カスタマーサポート部門との連携が必要になります。お客様からの要望をすべてドキュメントに反映するのは不可能ですし、声の大きい意見だけを取り入れるのも違うので、ある程度、ある機能についてのお問い合わせが何件あったとか、定量化してもらうことで、こちらも対応がしやすくなります。そういう形で定期的にコミュニケーションをとるようにしています。コストを減らすことももちろん大事なのですが、プロダクトの価値を高めることも重要なテクニカルライターの仕事だと思っていて、お問い合わせが何件減ったという指標と同様に、この機能の使用率が何%上がったという数字も、私たちの指標になります。

最後に、これからテクニカルライターを目指す方に向けてメッセージをお願いします。

一般的にテクニカルライターは書く仕事みたいに思われがちですが、書くテクニックよりも、エンジニアだったら技術をよくわかっているとか、カスタマーサポート出身の人だったらお客様が何に困っているとか、営業だとこういうことを意識して書けばもっと売れるとか、その人の強みを加えられると、よりよいライターになれるんじゃないかなと思います。

ありがとうございました。

今回インタビューした方
仲田 尚央（なかた なおひろ）さん
サイボウズ株式会社でテクニカルライター、UXライターとして活動するほか、株式会社SmartHRで多言語化技術顧問、東京都立産業技術高等専門学校でテクニカルライティングの講師も務める。
note: http://note.com/naoh_nak
『ヘルプサイトの作り方（技術評論社）』http://amzn.to/2lNsRfH