テクニカルライターの探し方｜6職種マップと複数職種組成で失敗しない発注設計

「テクニカルライターを1名採用すれば、社内のドキュメント問題は解決するはずだ」— そう考えて探し始めたものの、実際には期待どおりのアウトプットが得られず、契約更新に至らなかった。この経験を持つ発注担当者は少なくありません。理由は単純で、ドキュメント制作は「情報設計 → ヒアリング → 執筆 → 図解 → レビュー → 更新運用」という複数工程で構成されており、これらすべてを高い水準で1人でこなせる人材は極めて稀だからです。

さらに近年は、テクニカルライター以外にも UX ライター・情報アーキテクト・DevRel エンジニア・ドキュメントエンジニアといった隣接職種が急速に細分化しています。「テクニカルライターを探す」という切り口だけで進めると、実は自社の課題により適した職種を見落としているケースが多くあります。

本記事では、テクニカルライターの探し方を単職種で捉えるのではなく、隣接するドキュメント専門人材 6 職種の職種マップとして整理します。その上で、自社のドキュメント課題タイプから逆引きで最適な職種組成を選ぶ設計論と、職種ごとに異なる探索ルート（クラウドソーシング / エージェント / 副業マッチング / コミュニティ経由）を提示します。

想定読者は、従業員 30〜200 名規模の SaaS 企業・開発会社で、プロダクトドキュメント・API リファレンス・ヘルプセンター・オンボーディング資料などの整備を継続的に外部委託したいと考えている CTO・プロダクトマネージャー・カスタマーサクセス責任者です。

なお、テクニカルライター1名を業務委託で確保する際の契約実務（NDA・単価相場・受入基準等）については、記事末尾で関連記事にご案内します。本記事は「どの職種をどう組み合わせて探すか」という上流工程の意思決定を支援するものとして位置づけています。

テクニカルライターの探し方で「1名採用」に絞ると失敗する理由

多くの発注担当者が最初にぶつかるのは「テクニカルライターを1名雇えば、ドキュメント整備は完結する」という前提の誤りです。ドキュメント制作は複数の専門スキルが絡む複合作業であり、1人にすべてを求めると期待とアウトプットが噛み合わなくなります。まずはこの前提を見直すところから始めましょう。

ドキュメント制作の 6 工程と、1 人でカバーできる範囲

ドキュメント制作は、大きく以下の 6 工程で構成されます。

1. 情報設計: ヘルプセンター全体の構造、ドキュメントサイトの IA（情報アーキテクチャ）、記事同士の関係性を設計する
2. ヒアリング: 開発者・PM・カスタマーサポートから仕様や運用実態を引き出す
3. 執筆: 読み手の理解度・タスクフローに合わせて文章を組み立てる
4. 図解: シーケンス図・UI キャプチャ・アーキテクチャ図を作成する
5. レビュー: 技術的な正確性・読みやすさ・用語統一を検証する
6. 更新運用: プロダクトの変更に追随してドキュメントを継続的に改訂する

この 6 工程のすべてを高い水準でこなせる人材は現実にはほぼ存在しません。多くのテクニカルライターが得意とするのは「執筆」と「一部の情報設計」までで、「ヒアリングを能動的にリードする」「図解を最初から自分で設計する」「更新運用フローを社内に埋め込む」までを1人で完結できるケースは稀です。

「1 人採用で失敗する」典型 3 パターン

実際に発注担当者から聞かれる失敗パターンは、次の 3 つに集約されます。

パターン1: ヒアリング品質不足で内容が浅くなる ライターが受け身のスタンスで、開発者から情報を引き出せない。発注側が仕様書や口頭説明を渡した範囲でしか記事が仕上がらず、読者が本当に知りたい「なぜこの仕様なのか」「よくあるエラーの回避方法」といった一次情報が抜け落ちる。

パターン2: 情報設計をスキップして読みにくい 個別記事は書けるが、ヘルプセンター全体の情報構造・記事間の関係性を設計する視点が弱く、記事は増えるが「どこに何があるか分からない」状態になる。ユーザーが探しているページに辿り着けず、結果としてカスタマーサポートへの問い合わせが減らない。

パターン3: 更新運用が回らない 初期の記事は納品されたものの、プロダクトのリリース後に更新が追いつかず、公開から半年で内容が古くなる。ライター1人に「執筆」だけを依頼しており、更新運用の仕組み（Docs as Code 基盤・レビューフロー・棚卸しサイクル）が社内に構築されていない。

これらのパターンに共通するのは、「執筆スキル」以外の領域（ヒアリング設計・情報アーキテクチャ・運用基盤）が抜けていることです。次の章で紹介する 6 職種マップは、この抜け漏れを埋めるための職種選択の地図として機能します。

テクニカルライターを含むドキュメント専門人材 6 職種マップ

ドキュメント制作に関わる専門人材は、テクニカルライターに限りません。ここでは発注者が把握しておきたい 6 職種を、役割・得意領域・単価感の観点で整理します。職種によって強みが明確に分かれているため、自社の課題に合わせて選び分ける、あるいは組み合わせて発注することが成果に直結します。

テクニカルライター

製品マニュアル・API リファレンス・運用手順書などの執筆を主担当する職種です。手順の分解、正確な用語の使い分け、読者のタスクフローに沿った構成が得意領域です。SaaS プロダクトの管理者向けマニュアル、業務システムの操作手順書、社内オペレーション文書などで採用されます。

大企業では専門チームを組成する事例もあります。たとえば LINE では、複数のプロダクトを横断してドキュメントを整備する「テクニカルライター」職を明確に定義しており、その職務内容と組織的な位置づけはLINE の Speaker Deck 資料で公開されています。単価目安は業務委託で時給 4,000〜8,000 円、月額換算では 40〜80 万円のレンジが中心です。

UX ライター

プロダクト UI 内のマイクロコピー（ボタンラベル・エラーメッセージ・空状態メッセージ・オンボーディング画面の文言）を設計する職種です。「機能を説明する文章」ではなく「ユーザーが迷わず操作できる短い言葉」を設計するのが得意領域で、デザイナーと密に連携します。

日本国内では専業の UX ライターがまだ少なく、副業マッチングサイト経由での確保が現実的です。たとえば副業マッチングプラットフォームの lotsful には UX ライターの募集案件が掲載されており、実務内容と単価感の参考になります。時給 5,000〜10,000 円程度、スポット案件が多い傾向にあります。

情報アーキテクト（IA）

ヘルプセンター・ドキュメントサイトの情報構造そのものを設計する職種です。カテゴリ分類、ナビゲーション設計、検索経路の最適化、記事間の関係性の定義といった上流工程を担います。「記事を書く」のではなく「記事群がどう並ぶべきか」を設計するのが仕事です。

大規模なヘルプセンターや複数プロダクトを抱えるドキュメントサイトのリニューアル時に必須になります。日本国内では独立した「情報アーキテクト」として活動している人材は限られており、UX デザイナーが兼任するケースも多く見られます。スポット案件で 50〜150 万円の設計フェーズ発注が一般的です。

DevRel エンジニア

開発者向けのチュートリアル記事、SDK のサンプルコード、API 活用ガイド、技術カンファレンスでの登壇資料などを担当する職種です。開発者コミュニティとの接点設計、開発者体験（DX）の改善までを含む広い役割を持ちます。

DevRel 領域内でも役割は細分化されており、Think IT の職種細分化に関する解説記事では Developer Advocate、DevRel Engineer、API Writer などの職責の違いが整理されています。純粋なテクニカルライターとは異なり、コードを書けることが前提になるため、業務委託の相場は月額 60〜120 万円と高めです。

ドキュメントエンジニア

ドキュメント制作の「基盤」を担当する職種です。Docs as Code（Markdown をリポジトリで管理し、Pull Request でレビューする運用）の導入、静的サイトジェネレータ（Docusaurus、VitePress、MkDocs など）のセットアップ、CI/CD への組み込み、レビュー自動化などを行います。

継続運用体制を構築する場面で必須になる職種で、初期構築フェーズにスポットで発注し、以降は執筆担当者に運用を引き継ぐ形が一般的です。エンジニア職としての単価が適用されるため、スポット構築で 80〜200 万円の予算感を見込むと現実的です。

副業エンジニア＋編集者ペア

「現場エンジニアが技術的に正確な下書きを書き、編集者が読み手目線で仕上げる」という組成パターンです。単一の職種ではなく発注設計上のパターンとして紹介しています。

テクニカルライター単独では踏み込みにくい「技術的に深いトピック」や「社内でしか把握していない仕様の背景」を扱う場合に有効です。副業エンジニアは技術ブログや GitHub の活動履歴、コミュニティ登壇歴から探索し、編集者はクラウドソーシングや編集プロダクションから確保するのが現実的です。単価は 2 名合計で月額 40〜80 万円のレンジが目安です。

6 職種の役割・単価・適合ケース一覧表

単価は 2026 年時点の業界相場を目安として整理したもので、経験年数・案件の難易度・稼働時間によって変動します。実案件では試験発注（スポット 1〜2 週間）を経て継続契約に移行するのが安全です。

自社のドキュメント課題タイプ別｜推奨職種組成パターン 4 選

先ほど紹介した 6 職種を、自社のドキュメント課題タイプから逆引きで組成するパターンを 4 つ紹介します。いずれも「テクニカルライター1名で足りるか、他職種も組み合わせるべきか」の判断材料になります。

課題タイプA: 新規プロダクトのオンボーディングドキュメント整備

新規 SaaS プロダクトのリリースに合わせて、管理者向けマニュアル・エンドユーザー向けヘルプ・UI 内オンボーディング文言までを一貫して整備したいケースです。

• 推奨組成: 情報アーキテクト（スポット）＋テクニカルライター（メイン）＋UX ライター（マイクロコピー）
• 想定期間: 3〜4 ヶ月
• 想定月額レンジ: 総額 150〜300 万円（IA スポット 50〜100 万円＋テクニカルライター月 60〜80 万円×3ヶ月＋UX ライタースポット 30〜60 万円）
• ポイント: 立ち上げ時に情報アーキテクトが情報構造を設計しておくと、その後の執筆・追加コンテンツが構造に沿って積み上がる。「後から情報整理し直す」コストを回避できる

課題タイプB: 既存 API 仕様書のリファクタと DevRel 強化

既に API を公開しているが、リファレンスが古く開発者からの問い合わせが多い、チュートリアルが不足しているといったケースです。

• 推奨組成: DevRel エンジニア（メイン）＋ドキュメントエンジニア（基盤整備）
• 想定期間: 4〜6 ヶ月
• 想定月額レンジ: 総額 200〜400 万円（DevRel 月 80〜120 万円×4〜6ヶ月＋ドキュメントエンジニアスポット 80〜150 万円）
• ポイント: コードを読み書きできる DevRel エンジニアがリファレンス改訂と活用サンプルをセットで提供し、ドキュメントエンジニアが OpenAPI 定義から自動生成する基盤を組む。純粋なテクニカルライター単独では踏み込めない領域

課題タイプC: ヘルプセンターの CV 改善

既存ヘルプセンターの記事は揃っているが、ユーザーが情報にたどり着けず問い合わせが減らない、または資料ダウンロードなどの CV につながらないケースです。

• 推奨組成: 情報アーキテクト（メイン）＋UX ライター＋テクニカルライター（既存記事の改稿）
• 想定期間: 2〜3 ヶ月
• 想定月額レンジ: 総額 120〜250 万円（IA スポット 60〜120 万円＋UX ライタースポット 30〜60 万円＋テクニカルライター月 40〜70 万円×2ヶ月）
• ポイント: 「執筆」ではなく「情報構造の再設計」が主課題であることを見誤らない。テクニカルライターだけを追加投入しても記事は増えるだけで CV は改善しないケースが多い

課題タイプD: 継続的にドキュメントを最新化する体制構築

初期のドキュメントは揃ったが、プロダクトのリリースに追随した継続的な更新が回らないケースです。

• 推奨組成: ドキュメントエンジニア（基盤）＋副業エンジニア＋編集者ペア（継続執筆）
• 想定期間: 初期構築 2〜3 ヶ月 → 継続運用
• 想定月額レンジ: 初期構築 80〜200 万円 → 継続運用月 40〜80 万円
• ポイント: Docs as Code の基盤を最初に組み、リポジトリ内の Pull Request として更新を管理する。現場エンジニアが仕様変更を PR で下書きし、編集者が読みやすく仕上げるフローに乗せることで、更新の遅延を構造的に防げる

いずれのパターンでも共通するのは、「1 職種の稼働時間を増やす」より「役割の異なる複数職種を組み合わせる」ほうがドキュメント全体の品質が上がるという点です。

テクニカルライターと他 5 職種の探し方｜職種 × 探索ルートのマトリクス

職種ごとに、主に見つかる探索ルートが異なります。「テクニカルライター 探し方」で辿り着いたクラウドソーシングだけで 6 職種すべてを賄うのは現実的ではありません。ここでは職種別に、代表的な探索ルートと使い分けを整理します。

テクニカルライターの主な探し方｜クラウドソーシングとフリーランスエージェント

テクニカルライターを探す主要ルートは 2 系統に分かれます。

クラウドソーシング（ランサーズ・クラウドワークス）: 単発〜スポット案件に強く、着手までのリードタイムが短いのが特長です。単価は低め（1 記事 1〜5 万円、時給 2,000〜4,000 円）で、まずは試験発注で品質を見極めたい場合に向きます。ただし応募者数が多い一方で、専門性の高いテクニカルライターは限られるため、スキルシートとポートフォリオでの絞り込みが必須です。

フリーランスエージェント（レバテック・ITプロパートナーズ・フリーランスHub等）: 継続契約前提のミドル〜ハイクラス人材が中心で、月額 60〜100 万円のレンジが多くなります。事前のスキルスクリーニングが入るため、面談通過後のミスマッチが少ないのが利点です。半年以上の継続発注を想定する場合に適しています。

フリーランスエージェントで見つかる職種

フリーランスエージェント経由では、テクニカルライターに加えて DevRel エンジニア、ドキュメントエンジニアも探せます。特にエンジニア専門エージェントは「開発経験＋ドキュメント作成」の複合スキル人材を保有しているケースがあり、DevRel 系の発注では有力な選択肢になります。単価は月 80〜120 万円のレンジが中心です。

副業マッチングプラットフォームで見つかる職種（UX ライター中心）

UX ライターは、クラウドソーシングよりも副業マッチングプラットフォームで見つかりやすい傾向があります。lotsful、Workship、Offers といった副業マッチングサイトには、事業会社の UX ライター・プロダクトデザイナー経験者が登録しています。

副業マッチングの特徴は「本業がある人が週数時間〜10時間程度で参画する」形態が主流な点です。フルタイム稼働は期待できないものの、専業では確保しにくい高品質な人材にリーチできます。UX ライターだけでなく、テクニカルライターも本業の傍らで副業として登録しているケースがあります。

コミュニティ・技術ブログ経由の直接契約が主流の職種

DevRel エンジニア・情報アーキテクト・ドキュメントエンジニアは、プラットフォーム経由では見つかりにくく、直接契約が主流です。具体的な探し方は次のとおりです。

• DevRel エンジニア: 技術カンファレンス（DevRelJP、Developer eXperience Day 等）の登壇者、Qiita・Zenn の技術記事執筆者、OSS コミッターから直接コンタクトを取る
• 情報アーキテクト: UX 系コミュニティ（HCD-Net、UX MILK 等）、Designship 等のカンファレンス登壇者から探す
• ドキュメントエンジニア: GitHub の Docusaurus / VitePress 等のリポジトリへのコントリビューター、技術書典・技術ブログ執筆者から探す

直接契約はスクリーニングコストが高い反面、専門性が高く継続的な関係を構築しやすいのが利点です。

職種 × 探索ルートのマトリクス表

（◎: 主要ルート、○: 選択肢あり、△: 少数、✗: ほぼ見つからない）

この表からわかるのは、「6 職種すべてを 1 つのプラットフォームで完結させることはできない」ということです。組成パターンを決めた段階で、職種ごとに使うプラットフォームを分ける前提で発注計画を立てる必要があります。

複数職種組成で発注する場合のプロジェクト管理設計

複数職種を組成すると管理コストが増えるのは事実です。ここでは、発注者側が最低限押さえておきたいプロジェクト管理設計を紹介します。

役割分担の定義と RACI 表の作り方

複数職種を発注する際、最初にやるべきは役割分担の明文化です。RACI 表（Responsible / Accountable / Consulted / Informed）を使うと、誰が実行し、誰が承認し、誰に相談し、誰に共有するかを一枚に整理できます。

たとえば「新規プロダクトのオンボーディング記事」を対象にした場合、次のような整理が可能です。

R（実行担当）を複数人にせず、A（承認者）は必ず発注側 PM に置くのがポイントです。外部人材同士でレビューを完結させる設計にすると、意思決定の責任が曖昧になりやすくなります。

コミュニケーション設計

複数職種の外部メンバーと同時に進める場合、コミュニケーションチャネルの設計が成否を分けます。実務的には次の 3 点を最初に決めておくと運用が安定します。

• Slack ワークスペースへの招待範囲: 全員を招待するのか、職種ごとにチャンネルを分けるのか。情報漏洩リスクとコミュニケーション効率のバランスを取る
• 週次ミーティング設計: 全員参加の 30 分ミーティングを週 1 回、職種別の個別ミーティングを隔週で設定するのが目安。全員参加ミーティングは進捗共有と論点の擦り合わせに絞り、詳細議論は個別ミーティングに寄せる
• 非同期レビューのフロー: GitHub の Pull Request、Notion のコメント機能、Figma のコメントなど、成果物ごとにレビュー場所を分けすぎない。可能な限り Pull Request ベースに統一すると、履歴が残り再現性が確保できる

成果物の受入責任者を発注側に置く

外部人材同士のレビューだけで成果物を確定させないことは、複数職種発注で最も重要な原則です。テクニカルライターと情報アーキテクトが相互レビューして「これで良いです」と言った成果物が、発注側の期待とズレていた、というケースは実際に頻発します。

受入責任者（Accountable）は必ず発注側の PM または CTO に置き、最終判断を委譲しないこと。外部メンバー間のレビューは「品質を上げるための工程」であり、「受入の代替」ではありません。

単価配分の考え方

複数職種を発注する際、総額をどう配分するかの目安を示します。プロジェクト全体の予算 100% を、役割の重要度に応じて配分するイメージです。

• メインライター（テクニカルライター等）: 55〜60%
• 情報設計者（情報アーキテクト等）: 15〜25%
• レビュアー（技術レビュー・編集レビュー）: 10〜15%
• 発注側 PM 補助（進行管理・議事録等をアウトソースする場合）: 5〜10%

この配分はプロジェクトのフェーズによっても変わります。立ち上げフェーズは情報設計者の比率を高め、運用フェーズはメインライターの比率を上げる、といった調整が必要です。

発注前の準備｜自社のドキュメント課題を言語化する 5 質問

どの職種を選び、どのルートで探すにしても、発注前に自社のドキュメント課題を言語化しておくことが最重要です。ここでは発注担当者が自答すべき 5 質問と、その回答が課題タイプの選択にどう接続するかを整理します。

5 質問チェックリストと回答テンプレート

1. 読み手は誰か: エンドユーザー / 管理者 / 開発者 / 社内オペレーター など、対象読者を明確にする
2. 現状の課題は何か: ドキュメントがない / あるが古い / 探しにくい / 難しくて読めない / 内容が浅い のうちどれか
3. 更新頻度はどれくらいか: 月次 / 四半期 / リリース都度 / 年次 のどのタイミングで更新が発生するか
4. 既存ドキュメントとの整合性はどう保つか: 既存の記事群と用語・トーンを揃える必要があるか、それとも新規に整備するか
5. 成功指標は何か: 記事数 / カスタマーサポート問い合わせ削減率 / CV 率 / 開発者オンボーディング時間短縮 など、達成したい定量指標を定義する

これら 5 質問に社内で回答を出しておくことで、外部人材との初回打ち合わせが実質的な議論から始められます。逆に、この 5 質問への回答があいまいなまま発注すると、外部人材側が仮説を立てるところから始めることになり、時間と単価の両面でロスが発生します。

回答結果から課題タイプへのマッピング

5 質問への回答は、先ほど紹介した課題タイプに次のようにマッピングできます。

もちろん現実の課題は複数タイプが混在することが多く、その場合は「まず最優先の課題タイプを 1 つ選んで着手し、他タイプは次フェーズで扱う」という段階的な進め方が現実的です。

まとめ｜テクニカルライターを含むドキュメント専門人材の確保を成功させる 3 つの原則

本記事の内容を、テクニカルライターを含むドキュメント専門人材の確保を成功させる 3 つの原則として整理します。

3 原則の要約

原則1: 1 人採用ではなく職種組成で考える ドキュメント制作は情報設計・執筆・図解・レビュー・更新運用の複数工程で成立します。1 人にすべてを求めるのではなく、テクニカルライターを含む 6 職種のなかから必要な役割を組み合わせて発注しましょう。

原則2: 自社課題タイプから逆引きで職種を選ぶ 「テクニカルライターを探す」から始めるのではなく、「自社のドキュメント課題は 4 タイプのどれか」を先に特定します。課題タイプが決まれば、必要な職種組成と想定予算レンジが自然と定まります。

原則3: 職種ごとに探索ルートを変える 6 職種は同一プラットフォームでは見つかりません。テクニカルライターはクラウドソーシングとフリーランスエージェント、UX ライターは副業マッチング、DevRel・情報アーキテクト・ドキュメントエンジニアはコミュニティ経由の直接契約が主要ルートです。組成パターンを決めた段階で、職種別のプラットフォーム選定まで計画に含めましょう。

次のアクション

次に取るべきステップは 3 段階です。

1. 社内ヒアリング: 5 質問チェックリストに沿って、プロダクト担当・カスタマーサポート・開発責任者にヒアリングし、ドキュメント課題を言語化する
2. 職種組成の仮組み: 特定した課題タイプに応じて、6 職種マップから組成パターンを仮組みし、想定予算・想定期間を試算する
3. 探索ルート選定: 組成に含まれる職種ごとに探索ルートを決め、それぞれのプラットフォームで候補者リストの作成に着手する

テクニカルライター1名の業務委託契約の実務詳細（NDA・単価相場・試験発注のスコープ設計・受入基準等）は、テクニカルライターを業務委託で確保する方法で個別に解説しています。本記事で職種組成が決まったあと、テクニカルライターを実際に発注する段階で参照してください。

ドキュメント整備は、プロダクトの成長と歩調を合わせて継続する必要のある投資領域です。単発の 1 名採用で完結させようとするのではなく、職種マップと組成パターンを踏まえた発注設計に取り組むことで、外部体制の再現性と継続性を高められます。