概要
技術メディアの編集は、エンジニアが書いた原稿を、企業の技術ブログやインタビュー記事などの技術メディアで公開する前に、正確で読みやすく、表記の揃った状態に整える作業です。 このページでは、編集が担う役割、技術用語のチェック、原稿を編集する手順を扱います。技術メディアの編集とは
3つの役割
技術メディアの編集には3つの役割があります。それぞれが守る対象は異なるため、原稿が1つの役割を満たしていても、別の役割を満たしていないことがあります。
正確性を最初に置くのは、技術記事の誤りが、ぎこちない文よりも大きな損失を生むためです。誤った手順に従った読者は時間を失い、誤りに気づいた読者は記事の残りの部分も信用しなくなります。
読みやすさは、編集者ではなく想定読者を基準に判断します。テーマをすでに知っている編集者は、説明の抜けを無意識に補って読んでしまいます。そのため、テーマを知らない読者にとって読める文章かどうかを確認します。
表記の統一が問われるのは、1本の記事ではなくメディア全体の単位です。記事ごとに同じ製品名や概念の書き方が違うと、読者はそのメディアが内容を確認しているのかを疑い始めます。
技術用語のチェック
確認すること
用語のチェックで見つかるのは、一般的な校正では見落とされる誤りです。製品名の誤記や古いバージョン番号は、文章としては自然に読めてしまうためです。
最も注意が必要なのは、バージョンと時点への依存です。「このオプションがデフォルトです」という記述は、執筆時には正しくても1年後には誤りになりえます。そのため、どのバージョンで確認したかを記事に書きます。
避ける表記と推奨する表記
用語辞書を持つ
記憶に頼った用語のチェックは安定しません。編集者ごとに覚えているルールが違うためです。用語辞書はルールを1か所に固定し、チェックを照合の作業に変えます。 実用的な用語辞書は、正しい表記・誤った表記の例・備考の3列で構成します。備考には、そのルールの理由や根拠を書きます。備考があると、次の編集者が迷う事例に出会ったとき、推測ではなく根拠に基づいて判断できます。編集の手順
原稿は、大きな単位から小さな単位の順に編集します。後で削る段落の言い回しを直しても作業が無駄になるため、文より先に構成を確認します。1
構成を確認する
想定読者を確認します。見出しが記事の中身と一致しているか、各節が読者の追える順序で並んでいるかを確認します。
2
事実を確認する
誤りうる記述を1つずつ確認します。定義・分類・数値・バージョンに依存する挙動・比較が対象です。根拠として認めるのは、公式ドキュメントや仕様書などの一次情報だけです。確認できない記述は書き換えず、書き手に根拠を尋ねます。
3
用語をチェックする
原稿の用語を用語辞書と照合します。表記ゆれを統一し、略語は初出で正式名称を示し、固有名詞とバージョンの記述が正しいかを確認します。
4
表現を調整する
長い文を短くし、冗長な言い回しを削り、想定読者が知らない可能性のある専門用語を言い換えます。修正は1つひとつを小さく保ち、理由を説明できる範囲にとどめます。
5
書き手に確認する
実質的な修正には理由を添えて、編集した原稿を書き手に戻します。公開する最終版は書き手が承認します。
注意点
書き手の意図を尊重する
記事は書き手のものです。編集者の修正が正当化されるのは、正確性・読みやすさ・表記の統一のいずれかに役立つ場合です。編集者なら別の書き方をするという理由だけの修正は、これに当たりません。 意味の取りにくい箇所は、書き換える前に書き手の意図を確認します。誤った推測に基づく書き換えは、文章は整って見えても、技術的な意味が変わってしまうことがあり、元の文章よりも悪い結果になります。過剰な修正を避ける
過剰な修正は書き手の語り口を消し、メディアのすべての記事を同じような文章にしてしまいます。また、書き手が本来は不要だった修正まで確認することになり、進行も遅くなります。 1つの修正は、それが解決する問題の範囲にとどめます。誤りを見つけたらその箇所だけを直し、周辺の文章や書き手の文体には手を入れません。原稿を戻すときは、必須の修正と提案を分けて示します。必須の修正は事実・用語・メディアの基準に関する誤りであり、提案は書き手が採否を決められる改善案です。この区別を示すことで、提案を採用するかどうかを書き手自身が判断できます。
関連ページ
DevRelの役割
企業がエンジニアコミュニティと関わる方法の中で、技術メディアがどこに位置づくかを確認できます。