テクニカルライター

一言でいうと

テクニカルライターは、製品の仕様書、APIリファレンス、利用者向けのマニュアルやヘルプを、読み手が目的を達成できる構成と表現で作成する職種です。

この職種の出自と登場時期

テクニカルライティングを専門とする職業団体は、1953年に米国で生まれました。英語版Wikipediaによると、この年にボストンでSociety of Technical Writersが、ニューヨークでAssociation of Technical Writers and Editorsが設立されました。両団体は1957年に合併し、1960年に別の団体と合流したのち、1971年にSociety for Technical Communication（STC）へ名称を改めています。

国内では、1989年6月に第1回TCシンポジウム「いま、日本のマニュアルを考える」が開かれ、1992年1月にテクニカルコミュニケーター協会（JTCA）が設立されました。協会は1998年にテクニカルライティングの検定試験を始め、2009年に一般財団法人になっています。国内のテクニカルライターは、機器の取扱説明書に加えて、ソフトウェアのヘルプやAPIの文書も担当しています。

国内のIT企業では、ドキュメントエンジニアの名称で募集する例もあります。開発者向けの製品を持つ企業では、文書をコードと同じリポジトリで管理し、レビューとテストを通して公開する運用が見られます。

ミッション

テクニカルライターは、利用者が文書を読んで製品を正しく使い、目的を達成できる状態に責任を負います。製品の機能をすべて説明することではなく、読み手が必要な情報に短い時間でたどり着けることが成果の基準です。

文書の不足による問い合わせや誤操作を減らすことも役割に含まれます。問い合わせの記録と文書の閲覧状況から、書き直すべき箇所を特定します。

主な業務範囲

• 読み手の想定と、文書全体の構成の設計
• 開発者・プロダクトマネージャーへの取材と、仕様の確認
• APIリファレンス、導入手順書、利用者向けマニュアルの執筆
• 用語の統一と、表記のルール（スタイルガイド）の整備
• 製品のリリースに合わせた文書の更新と公開
• 文書の翻訳・多言語化の管理

求められる能力

技術面では、担当する製品の仕組みを開発者と同じ水準で理解する力が求められます。APIの文書を担当する場合は、HTTP、データ形式、認証の方式を理解し、サンプルコードを自分で動かして確認できる必要があります。文書をリポジトリで管理する組織では、GitとMarkdownなどの記法、静的サイト生成の仕組みも使います。

非技術面では、読み手の知識と目的を想定して情報の順序を決める力と、曖昧さのない文を書く力が中心になります。開発者から必要な情報を引き出す取材の力も求められます。

この職種に就く人のキャリア経路

エンジニアから文書の担当へ移る経路、テクニカルサポートやカスタマーサクセスから移る経路、機器メーカーのマニュアル制作からIT企業へ移る経路があります。

その後は、ドキュメント全体の責任者、DevRel、プロダクトマネージャー、情報設計の専門職へ進む経路があります。

隣接職種との違い

採用担当の見極めポイント

• 候補者の書いた文書を実際に読み、想定読者と目的が文書の冒頭で分かるかを確認してください。読み手の設計ができている人は、構成の段階で差が出ます
• 仕様が固まっていない段階で、開発者からどのように情報を集めたかを聞いてください。取材の手順を具体的に話せる人は、開発の速い組織でも文書を遅れずに更新できます
• 求人票には、対象読者（開発者・一般利用者・社内）と、文書の管理方法（リポジトリかCMSか）を明記してください。この2点によって、求める技術の水準が大きく異なります

求人・市場の傾向

国内では専任のテクニカルライターを置くIT企業は多くなく、開発者向けの製品を持つ企業や、海外展開するSaaS企業で募集が見られます。エンジニアが文書を兼務している組織も多いため、母集団は薄く、エンジニアやサポート職から文書に強い人を探す採用も選択肢になります。