テクニカルライターの年収相場｜ドキュメントエンジニアの評価軸とスキル差145万円

テクニカルライター・ドキュメントエンジニア（製品マニュアル、APIリファレンス、社内の技術文書を担う職種）の年収は、文章の上手さではなく、製品の仕様をどこまで自力で取れるかで決まります。日本語を整えるだけの範囲で募集される求人は減っており、開発チームに入って曖昧な仕様を確定させ、公開までの流れを自分で回せる人に高い等級が付きます。

この記事が想定している読者は、エンジニアからドキュメント側へ移ることを検討している人と、すでに書く仕事をしていて自分の提示額が妥当か確かめたい人です。まず、条件を揃えたときに推定レンジがどう動くかを確認します。

同じ経験年数でもスキル差で145万円開く

実務6〜9年／上場・大手／東京勤務という条件を固定して、スキルの水準だけを動かすとこうなります。

• スキル下位（スコア30）：589〜691万円
• スキル中位（スコア50）：638〜748万円
• スキル上位（スコア85）：723〜848万円

中央値で比べると、下位と上位で 145万円 開きます。この職種でこの軸がとくに効く理由は、成果物の見た目が揃いやすいからです。公開されたドキュメントだけを並べると、どれも整った日本語になっていて差が見えません。差が出るのは、書き始める前の段階、つまり仕様が固まっていないものをどう扱うかです。

具体的には、新機能のリリース直前に「この設定を変えたとき既存の挙動がどうなるか」が誰にも確定していない、という状況が起きます。上の帯の人はコードと設定ファイルを読み、手元で動かして挙動を確かめ、必要なら実装者に論点を絞って質問します。下の帯の人は仕様が決まるのを待ち、決まった内容を日本語にします。前者は仕様の抜けを見つける側として扱われ、後者は工程の下流として扱われます。この違いが、同じ年数でも等級として積み上がります。

ただし、このレンジは当サイトの診断モデルによる推定で、テクニカルライターという職種名ごとの実測値ではありません。診断のスキルスコアはコードを読んで挙動を言い当てる力を測るもので、ドキュメント職では「仕様を自分で読み取れるか」に対応する目安として読んでください。

企業タイプで変わるのは募集の有無でもある

実務3〜5年／東京勤務／スキル中位で、企業タイプだけを変えるとこうなります。

この表は、同じ仕事をしたときに企業タイプでレンジがどう違うかを示すものですが、ドキュメント職ではもう一段の読み替えが必要です。専任のドキュメント担当を置けるのは、同じ製品を長く売り続ける組織に限られます。 受託開発が主な会社では、文書は案件ごとの納品物として開発側が書くため、独立した職務になりません。そのため募集の多い帯と少ない帯が企業タイプによってはっきり分かれます。

言い換えると、この職種を選ぶことは応募先の構造を選ぶことでもあります。自社製品を持ち、ドキュメントが問い合わせ件数や解約率に影響する会社では、ドキュメントは製品の一部として扱われます。逆に、文書が検収のために必要な成果物として扱われる現場では、品質を上げても評価の対象になりにくく、年収の伸び方も鈍くなります。企業タイプによる差が何から生まれているかは企業タイプ別のエンジニア年収相場で扱っています。

経験年数別のレンジと、この職種の入り口

同じ上場・大手／東京／スキル中位で、経験年数だけを動かすとこうなります。

ドキュメント職の求人は、この表の上から下まで均等に出るわけではありません。未経験可の募集は、既存の文書の更新や表記の統一から入る形が多く、入り口の等級は低く設定されます。一方で実務経験者向けの募集は、文書の構造を決める、公開の仕組みを作る、他部署と交渉するといった範囲まで含むため、開発職と同じ等級レンジで出てくることがあります。

注意したいのは、年数が長いほど自動的に上の行へ移るわけではない点です。同じ会社で同じ製品の文書を更新し続けた年数は、評価の材料としては弱く扱われます。問われるのは担当した年数ではなく、担当した範囲がどこまで広がったかです。更新だけを続けた年数は、次の等級の根拠になりません。

テクニカルライターとドキュメントエンジニアはどう違うか

結論として、責任の境界は「文書の中身」と「文書を届ける仕組み」で分かれます。テクニカルライターは内容と表現に、ドキュメントエンジニアはリポジトリ、ビルド、リンク切れの検証、多言語の配信といった基盤に責任を持ちます。

この違いは、同じ不具合が起きたときの対処に表れます。手順書の説明が古いままだったとき、前者は正しい手順に書き換えます。後者は「製品の変更に文書が追従しない状態が放置された」ことを問題として扱い、変更があったときに文書側へ通知が飛ぶ形へ作り替えます。どちらが上位ということではなく、見ている対象が違います。

ただし日本の求人では、この使い分けが統一されていません。ドキュメントエンジニアという名前で募集していても実態は執筆だけの場合があり、テクニカルライターという名前で基盤の整備まで含む場合もあります。職種名の定義に寄りかからず、募集の背景と、公開の判断を誰がしているかで読み分けてください。外向きの技術情報を扱う役割との境界はDevRel・技術広報の年収と評価軸でも扱っています。

評価軸1：仕様を一次情報から自分で取れるか

この職種で最初に問われるのは、仕様の出どころを自分で確かめられるかです。実装者への質問だけで書こうとすると、相手の記憶違いや説明の省略がそのまま文書に入ります。評価される人は、質問の前にコード、設定、ログ、実際の画面を見て、分からない点を特定した状態で聞きます。

分かりやすい差は、質問の粒度に出ます。「この機能はどう動きますか」と聞く人と、「この条件のときだけ既定値が効いていないように見えるが、意図した挙動か」と聞く人では、実装者の手間がまるで違います。後者の聞き方ができる人は、開発チームの時間を奪わずに書けるため、同じ本数の文書を出しても評価が高くなります。

注意点として、自分で確かめることと勝手に決めることは別です。手元の挙動が仕様なのか不具合なのかは、書き手が決めてよい範囲を超えます。確認した事実と、判断が必要な論点を分けて持ち込む姿勢が前提になります。

評価軸2：ドキュメント全体の構造を設計できるか

次に問われるのは、個々の文書ではなく全体の構造です。製品の機能が増えるほど、どこに何を書くかの判断が難しくなり、同じ内容が複数の場所に重複して置かれます。重複は、片方だけが更新されたときに読者を誤らせる原因になります。

評価される人は、新しい文書を足す前に、置き場所と参照の向きを決めます。概念の説明、手順、リファレンスのどれにあたるのかを分け、同じ説明を二度書かずに参照で済ませます。この整理ができていると、製品が変わったときに直す箇所が特定でき、更新の手間が機能数に比例して増える状態を避けられます。

一方で、構造を整えること自体が目的になると行き過ぎます。読者が実際にたどる経路から外れた分類は、整っていても使われません。検索から直接入ってくる読者が多い文書では、階層の美しさより、1ページで完結して読めるかどうかが優先されます。

評価軸3：公開までの仕組みを自分で回せるか

3つ目は、文書を公開するまでの流れを自分で動かせるかです。原稿をファイルで渡して誰かに公開してもらう形だと、製品の変更に追従する速度が他人の作業に縛られます。この状態が続くと、更新の遅れが書き手の評価として戻ってきます。

具体的には、文書をコードと同じリポジトリで管理し、変更をプルリクエストでレビューし、リンク切れや用語の不統一を自動で検出し、公開まで自動で流れる形が目標になります。ここまで整えられる人は、ドキュメントエンジニアとして募集される側に回れます。実装の変更と文書の変更が同じ単位で進むため、追従の遅れそのものが起きにくくなります。

ただし、仕組みを作れば品質が上がるわけではありません。検出できるのは機械的な不整合までで、説明が読者の状況に合っているかは人が読んで判断する領域に残ります。自動化の範囲と、人が読む工程を分けて説明できることが求められます。

評価軸4：公開した後の変化を測れるか

4つ目は、書いた後に何が変わったかを示せるかです。文書の仕事は成果が見えにくいと言われますが、測れる指標は社内にあります。同じ質問による問い合わせの件数、特定の手順でつまずいた報告の数、導入までにかかる日数などです。

これらを前後で比べられると、文書の改善が製品の数字につながった話として扱えます。評価面談や転職の選考で説明するときも、書いた本数より、どの問い合わせが減ったかのほうが強い材料になります。逆に、公開した本数と文字数だけを実績として並べると、作業量の報告として受け取られます。

注意点として、問い合わせ件数は文書以外の要因でも動きます。製品側の改修、価格の変更、利用者の増減が重なるため、因果を強く主張するのは避けるべきです。自分が担当した範囲と時期を限定して示すほうが、説明として信用されます。技術情報を外に出した実績の扱い方は技術記事・OSS活動は年収に効くのかでも触れています。

年収が伸びにくいパターン

伸びにくい状態には共通点があります。ひとつは、依頼された原稿を期限内に整えることだけで評価が完結している状態です。この範囲は成果の上限が依頼の量で決まるため、どれだけ速く書いても等級の根拠になりません。

もうひとつは、文書の品質基準を自分の中だけに持っている状態です。表記や構成の判断が個人の感覚に閉じていると、他の人が書いた文書を同じ水準に引き上げられず、担当範囲が増えません。基準を文書化し、レビューの観点として共有できると、1人で書く仕事から、全体の品質に責任を持つ仕事へ移れます。

3つ目は、製品知識が特定のバージョンに固定されている状態です。長く同じ製品を担当していると、過去の経緯には詳しくなりますが、新しい領域の文書を任せられるかの判断材料になりません。別の製品や、まだ文書がない機能を引き受けた経験が、評価の幅を広げます。

公的統計でこの職種を切り出せない点に注意

テクニカルライターの平均年収として出回っている数字を扱うときは、出どころに注意が必要です。公的統計には、この職種だけを切り出した区分がありません。参考になるのは、産業としての情報通信業の水準です。

比較の対象として、ITエンジニア全体の平均は 469万円（2025年） です。ドキュメント職の提示額は、同じ会社の開発職の等級テーブルに乗る場合と、別の職種区分で低く設定される場合に分かれるため、産業平均をそのまま自分の相場として使うことはできません。使えるのは、応募先の産業がどのあたりの水準にあるかという前提の確認までです。

求人の出やすさを見る目安としては、情報処理・通信技術者の有効求人倍率が 1.39倍（令和8年3月） です。ドキュメント職はこの区分の中でも募集数が少ないため、条件の良い募集を待つ期間は開発職より長くなりやすいと見ておくほうが安全です。

求人票と面談で確認する項目

提示額の妥当性は、職種名ではなく権限の範囲から判断できます。次の項目を確認してください。

• 文書の公開を最終的に決めるのは誰か（自分のチームか、別部署の承認が必要か）
• 開発チームの設計の議論に、仕様が固まる前の段階から入れるか
• ドキュメントの基盤（リポジトリ、ビルド、配信）を誰が持っているか
• 文書の成果をどの指標で見ているか。本数以外の指標があるか
• 必須要件に開発または運用の実務経験が含まれているか
• 等級テーブルが開発職と共通か、別の職種区分になっているか

このうち最初の2つで実態がほぼ分かります。公開の判断が別部署にあり、議論にも入れない場合、担当できる範囲は依頼された原稿の作成に限られます。求人票の文言から等級を逆算する手順は求人票の必須要件から応募先の等級を逆算するにまとめています。

年収を上げるときの手順

今の職場で等級を上げる場合も、転職で提示額を上げる場合も、進める順序は同じです。

1. 担当している文書のうち、仕様を自分で確定させたものを洗い出す
2. その文書の公開後に変わった数字（問い合わせ件数、導入までの日数など）を集める
3. 基準や観点を文書化し、他の人の原稿をレビューできる状態にする
4. まだ文書がない機能、または別の製品を1つ引き受ける
5. 公開までの流れのうち、人の手が必要な工程を1つ自動化する
6. 以上を担当範囲の広がりとして整理し、評価面談または選考で示す

順番を飛ばすと説明が弱くなります。先に自動化や基盤の話を持ち出しても、仕様を自分で取れた実績がなければ、文書の質に責任を持てる根拠にはなりません。

最後に確認すること

ここまでの内容を、判断の順序として並べ直します。

• 応募先は自社製品を長く売る組織か、案件ごとの納品物として文書を扱う組織か
• 等級テーブルは開発職と共通か、別区分か
• 自分の実績は、書いた本数ではなく確定させた仕様と変わった数字で説明できるか
• 公開までの流れのうち、自分で動かせる工程がいくつあるか

このうち2つ以上が埋まらない状態で提示額だけを比べると、入り口の等級が低い募集を選んでしまいます。自分のスキル水準がレンジのどのあたりに対応するかは、診断で目安を出せます。