aptpod Advent Calendar 2021の20日目を担当する、製品開発グループDocumentsチームの篠崎です。
この記事では、「70人規模の会社で、ドキュメント専門の担当者はどんなことをするのか」を紹介したいと思います。
最近、いくつかのオンライン上のミートアップで、テクニカルコミュニケーションチームの素晴らしい情報が公開されていて*1、かっこいいなあ、すごいなあと思いながら日々見ています。
これらミートアップを拝見しながら、弊社のような「もっと小さな会社のドキュメント担当の仕事」についてもご紹介したいと思いました。
私自身以前から、同規模の他社ではどのようにされているのか知りたいと考えており、「まずは自分が書いてみよう」と思ったのでした。同様の仕事をしている方の参考になるところがあれば幸いです。
職種名と所属
弊社内でのドキュメント担当の職種名は「テクニカルコンテンツディレクター」です。 テクニカルコンテンツディレクターは、「製品開発グループ」（15人ほどのエンジニアにより構成）に所属し、製品・サービスの使い方・価値を、分かりやすく統一性のある形で社外に伝えることを目標に、ドキュメントを作っています。
ただ、自己紹介するときに「テクニカルコンテンツディレクターです」と言っても実際の仕事をイメージしてもらうことが難しいので、「ドキュメント担当です」「テクニカルライターです」「マニュアルを作っています」などのように言っています*2。
実務を振り返ってみると、私としては、「ドキュメント担当」というのがいちばんしっくりくるかなと思っています。以下のような理由からです：
- 実際にドキュメントを書いていますが、書く以外の仕事も多いので、「ライター」という言葉ではカバーしきれない
- マニュアルというと一般にはPDFや冊子の形式になったものを想像することが多いと思いますが、開発者向けAPIリファレンスも扱うので「マニュアルを作っている」だけでもない
- 翻訳の進行もする（ただし、翻訳者ではありません）し、ドキュメント作成のためのツールの整備をしたりもする
ドキュメント担当の仕事
弊社の「ドキュメント担当」の仕事は、4つの分野に整理できます。
- (A) ライティング／リライト関連
- (B) 翻訳関連
- (C) UI文言関連
- (D) A～Cにかかわるツールや仕組みの整備
現在、弊社は全体で70人ぐらいですが、社内に「テクニカルコンテンツディレクター」は1人しかいません*3。そのため、上記のように幅広く担当しています*4。
小さな組織で、情報システム関連のあらゆる業務を受け持つ人を「ひとり情シス」と呼ぶことがありますが、それになぞらえると、私は「ひとりドキュメント担当」です。
1年半前に入社したとき、社内にこの職種の人はいませんでした。一方、私は以前ドキュメント制作チームで働いた経験はありましたが、「ひとりドキュメント担当」として働いたことはありませんでした。
そのため、社内の既存メンバーも私も、ドキュメント担当の業務分担はどうあるべきかを手探りで確かめながら、現在のような形を作ってきました。
その「手探り」は、いまも続いています。製品のラインナップ、サービスの提供形態、組織の成長フェーズが移っていくにつれて、常に調整していかなければならないことだと思っています。
では、4つの分野について、もうすこし詳細をご紹介します。
(A) ライティング／リライト関連
弊社コーポレートサイトのDocsで公開されているマニュアル、ドキュメント類を、日本語で作成しています。
量が多く、また内容も幅広いため、すべてを一人で書いているわけではありません。 制作工程は製品や内容によってさまざまです。いくつかの代表的なパターンは以下のようになります：
- ドキュメント担当が、企画、構成検討から始め、ゼロからライティングをする
- 決まった構成に沿ってエンジニアが原案を書いて、それをドキュメント担当が整理・リライトして仕上げていく（ハードウェアマニュアルなど）
- エンジニアが書いて、ドキュメント担当は表現のブラッシュアップのみを行う（デベロッパーガイド、APIリファレンス）
どのパターンで作成するかは、内容、スケジュールによって臨機応変に変えています。 「前回はエンジニアさんの原案をもとにして作りましたが、今回の改版部分はドキュメント担当が直接書きますね、エンジニアさんはレビューをしてくださいね」ということもよくあります。
作成に使用するツールは主にSphinxです（APIリファレンスを除く）。
ドキュメントのデータは、社内GitLabで管理しています。ドキュメント担当がすべてのドキュメントリポジトリのオーナーになっており、修正作業は修正用ブランチで行って（対象製品の開発担当エンジニア、ドキュメント担当がともにコミット可能）、ドキュメント担当が最終的に本流にマージして完成させるというフローが定着しました。
一般的には、ドキュメントの作成（特に「マニュアル」と呼ばれる種類のもの）を、専門の制作会社に外注するケースも多いと思いますが、ドキュメント担当が社内で作成する（内製する）ことは、継続的にドキュメントを整備していくにあたって大きな利点になると考えています。
社内の人間であれば、常に社内の製品開発エンジニアと共に、製品を深く理解しながら作業を進めることができます。存分に社内の資料を見られますし、エンジニアに気軽に質問することができます。その気になれば、製品のソースコードを読むことも可能です。
ライティング中は、開発担当エンジニアに製品仕様や新機能の目的などを質問することがあるのですが、事前に十分に情報収集ができるおかげで、あらかじめ「きっとこういうことだな」と理解したうえで、エンジニアに「こういうことですよね？」と確認し、「そのとおり」という返事をもらって、短時間で情報収集を行うことができます。これは大きなアドバンテージです（もちろん、「そのとおり」でないこともありますが）。
また、ドキュメント担当としては、同じ製品を継続して担当することで、製品の知識を蓄積することができます。弊社の場合、ハードウェアからソフトウェア開発用SDKまで、非常に製品の幅が広く、それらが1つの目的のためにシステムとして動くので、幅広く、しかし自社製品に集中して知識を蓄積できる環境は非常に重要と考えています。
この分野で思い出深い今年の仕事（年末なので振り返ります）：
ハードウェア製品EDGEPLANTシリーズの取扱説明書
(B) 翻訳関連
一部のドキュメントは英語に翻訳する必要があります。私自身は技術翻訳はできませんが、翻訳前の処理、翻訳会社への発注（一部は社内で機械翻訳を使用）、翻訳後の処理、訳文のチェックを行っています。
翻訳会社で翻訳支援ツール（CAT）を使った処理をしやすいように、また、自分でもチェックしやすいように、原文ファイル、用語集、翻訳メモリなどの材料を整えたり、工程を考えたりします。
このあたりは、リンギストと呼ばれる仕事に近いと思います。
原文である日本語のライティングと、この翻訳関連業務を一人で担当していると、「翻訳結果をチェックすると原文の日本語のマズいところが分かり、すぐに日本語版を直すことができる」という、特有の利点もあります。
今後、本格的に英語ドキュメントを用意していくためには、クラウド型の翻訳支援ツールを導入しないと処理しきれなくなるだろうなと思っているところです。
この分野で思い出深い今年の仕事：
- Automotive Proクイックスタートガイド英語版（近日公開）
(C) UI文言関連
弊社製品のうち、UIを持つウェブアプリケーションについて、ボタンやメッセージの文言を考えています。
これは、最近「UXライター」と呼ばれている仕事にあたると思います。
このあたり、私は業界の動向に十分に追い付けているとは言い難いですが、それでも、画面を設計する段階から議論に加わり、エンジニア、デザイナーとともにUI文言を作っています。 UI検討のフェーズから開発に加わることで、早い時期から製品の仕様を理解し、そこで得た情報をドキュメントのライティング工程にも活かすことができます。
たった1行の文言を書くのに、調査・議論など、かなりの時間がかかる難しい仕事です。
この分野で思い出深い今年の仕事：
- Visual M2M Data Visualizerのバージョンアップに合わせて文言を検討（ユーザーが複雑な設定をする画面があり、もっとマニュアルで補足説明したいと思っていたのですが、エンジニア、デザイナーとともに画面そのものを分かりやすくすることで、複雑さの原因の部分で改善ができました）
(D) A～Cにかかわるツールや仕組みの整備
ここまで挙げてきたような仕事をしていると、もっと効果的なものを効率よく作れるようになりたいと感じてきます。 そこで、そのためのツールを整えたり、ドキュメントを公開するための仕組みを作ったりするのも仕事です。
前述のように、マニュアルは主にSphinxで作っていますが、その設定やスタイルファイルは継続的に改善しています（SphinxでのPDF生成については以前のテックブログの記事にも書きました）。
また、PDF/HTMLを自動でビルド・デプロイするための仕組みを整えたり、Sphinxから出力される翻訳用ファイル（Gettext PO）を使ったワークフローを考えたり、といったことも含まれます。 このあたり、ドキュメント関連のエンジニアリング的な作業が好きな人には、とっても楽しい仕事です。
また、ドキュメント内で使う用語をできるだけ統一できるように、製品に関連する概念や機能名を集めた用語集も整備しています。
この分野で思い出深い今年の仕事：
- SphinxでPDFを出力するための社内スタイルファイルの統一
- intdash FAQの外部公開（これは、ドキュメント担当だけでなく部署横断チームにて、ナレッジベースサービスの選定からコンテンツ公開までを行いました。今後も内容を充実させていきます。）
まとめ
以上が、弊社の「ひとりドキュメント担当」の概要です。
すべてをこなすのは大変で、十分にできていないところもありますが*5、現在の弊社の場合のように1人（または少人数）で、「製品横断的に、また、工程縦断的に、多方面にかかわることができる」というのは面白いところだと思っています。今後も日々勉強・実践していきます。
*1:例えば、LINEの開発者向けドキュメントを支える「テクニカルライティング」の専門チーム、Cybozu × SmartHR プロダクトに関わるライターのリアル、LINE Technical Writing Meetup vol. 8 など
*2:「自分の仕事を何と呼べばよいのか迷う」というのはテクニカルコミュニケーション業界の「あるある」だと思います。業界外では最もよく知られている「テクニカルライター」という職種名でさえ、職業図鑑にはなかなか載っていないですので。
*3:弊社内の職種別の構成については今年のアドベントカレンダーで人事担当が紹介しています。
*4:マーケティング関連のドキュメント（コーポレートウェブサイト、パンフレット、プレスリリースなど）は、別途マーケティング部門が担当しています。
*5:課題もたくさんあります。
- まだ説明しきれていない機能がある
- 情報が見つけにくい場合がある
- このままドキュメントが増えると今のやり方ではメンテナンスが追い付かなくなる
- 必要とされている情報を作るだけでなくて、情報の再利用性、メンテナンス性、製品としての方向性、読者にとっての必要性、潜在的なユーザー層のありかなどを考えて、作るものの優先順位をもっと考えないといけない（コンテンツストラテジー）
これらについては、今後も考え、対処していかないといけません。
