クラウドソーシングで操作マニュアルの執筆から始める
向いている人: 対象を触って理解し、手順に落とすのが苦にならない人（分野の実務経験があると受注しやすい）
今日やる1タスク
進捗 0 / 7（0%）・残り約 20時間
- 準備 0/3
- 登録 0/1
- 応募 0/1
- 受注 0/1
- 継続 0/1
チェックはこの端末のブラウザにのみ保存されます。別の端末へは進捗ページから書き出せます。
準備
操作マニュアルは書き方がある程度決まっている。目的・前提・手順・確認・困ったときの並びを、自分の型として用意する。
開始条件: 特になし。今日そのまま始められる
完了の目安: 目的・前提・手順・確認方法・つまずいたときの5要素が並んだ雛形ができている／成果物: 手順文書の構成テンプレート
つまずきやすいポイント
- 説明を先に長く書き、手順が埋もれる
- 前提（必要な権限・環境）を書かず、読者が途中で止まる
止まったら: 型が決まらないときは、自分が一番読みやすかった公式マニュアルの構成をそのまま借りる。
サンプルがないと受注しにくい。権利上問題のない題材（自分が使っているソフトの機能など）で、実際に手順書を1本仕上げる。
開始条件: tw-01 の構成テンプレートがあること
完了の目安: 読者が同じ操作を再現できる手順書が1本完成している／成果物: サンプル手順書 1 本
つまずきやすいポイント
- 自分が分かっている前提で手順を飛ばす
- スクリーンショットに個人情報や社内情報が写り込む
止まったら: 書きながら操作が分からなくなったら、その箇所こそ読者もつまずく。分からなかった経緯をそのまま「つまずいたとき」の節に書く。
技術文書では用語のぶれが致命的になる。案件ごとの指定に従えるよう、自分の基準と切り替え方を決めておく。
開始条件: tw-02 のサンプルがあること
完了の目安: 用語の統一ルールと、案件指定があった場合の切り替え手順が書けている／成果物: 用語・表記ルールのメモ
つまずきやすいポイント
- 同じ機能を複数の呼び方で書く
- 製品の正式名称と通称を混ぜる
止まったら: 決めきれない項目は「案件の指定に従う」と書いておく。技術文書では案件側の用語集があることが多い。
登録
登録と提案の費用、システム手数料、支払いの流れを公式ヘルプで確認したうえで登録し、プロフィールに書ける実務経験を整理する。
開始条件: tw-03 までの準備物がそろっていること
完了の目安: 登録が完了し、手数料の計算方法と支払いの流れをメモに書けている／成果物: 登録済みアカウントと、手数料・支払いの流れのメモ
つまずきやすいポイント
- 手数料を引く前の金額で受取額を考えてしまう
- 書ける分野を絞らず、対応できない技術領域の依頼を受けてしまう
止まったら: 手数料の記載が見つからない場合は推測せず「未確認」とメモし、契約前に見積もりで確認する。
応募
技術文書は「実物を触れるか」で作業量が変わる。触れない場合は誰に質問できるかを、応募前に確認する。
開始条件: tw-04 の登録が完了していること
完了の目安: 応募が完了し、対象への access と質問先の確認結果が記録に残っている／成果物: 応募文と、確認事項の記録
つまずきやすいポイント
- 実物を触れない前提を確認せず、仕様書だけで書くことになる
- 質問できる相手が決まっておらず、不明点で作業が止まる
止まったら: 対象を触れず質問先も決まっていない案件は、作業量が読めない。条件が確認できるまで応募しない。
受注
受注から納品まで通す。技術文書はレビューでの指摘が多いのが普通で、指摘の種類を記録すると次から減らせる。
開始条件: tw-05 の応募が採用されていること
完了の目安: 1件の納品が完了し、受けた指摘の種類が記録に残っている／成果物: 納品文書と指摘の記録
つまずきやすいポイント
- 確認できていない仕様を推測で書く
- レビューの往復回数を決めずに受注し、修正が終わらない
止まったら: 仕様が確認できない箇所は書かずに質問として残す。推測で書いた手順は、読者を誤った操作に導く。
継続
数件こなしたら、分量あたりの所要時間と指摘の傾向を見返し、次に受ける分野を絞る。
開始条件: tw-06 の記録が複数件たまっていること
完了の目安: 分量あたりの所要時間が並んでいて、次に応募する分野が決まっている／成果物: 見直しメモ（所要時間・得意分野・テンプレートの更新点）
つまずきやすいポイント
- 指摘の原因を「自分の理解不足」で片付け、構成テンプレートを直さない
- 分野を絞らず、毎回ゼロから対象を学び直す
止まったら: 判断できるほど件数がたまっていなければ、分野は絞らずにもう数件こなしてから見直す。