> ## Documentation Index
> Fetch the complete documentation index at: https://lib.findy.co.jp/llms.txt
> Use this file to discover all available pages before exploring further.

# 技術記事の編集とは — 役割と用語チェック

> 技術メディアの編集が担う3つの役割、用語辞書による技術用語のチェック、原稿を編集する手順を解説します。

## 概要

技術メディアの編集は、エンジニアが書いた原稿を、企業の技術ブログやインタビュー記事などの技術メディアで公開する前に、正確で読みやすく、表記の揃った状態に整える作業です。

このページでは、編集が担う役割、技術用語のチェック、原稿を編集する手順を扱います。

## 技術メディアの編集とは

### 3つの役割

技術メディアの編集には3つの役割があります。それぞれが守る対象は異なるため、原稿が1つの役割を満たしていても、別の役割を満たしていないことがあります。

| 役割 | 守るもの | 典型的な問い |
| - | - | - |
| 正確性 | 内容に対する読者の信頼 | この記述は、記事が前提とするバージョンと条件のもとで正しいか |
| 読みやすさ | 読者の時間 | 想定読者が読み返さずに論旨を追えるか |
| 表記の統一 | メディア全体の信用 | 同じ対象を、他の記事と同じ書き方で呼んでいるか |

正確性を最初に置くのは、技術記事の誤りが、ぎこちない文よりも大きな損失を生むためです。誤った手順に従った読者は時間を失い、誤りに気づいた読者は記事の残りの部分も信用しなくなります。

読みやすさは、編集者ではなく想定読者を基準に判断します。テーマをすでに知っている編集者は、説明の抜けを無意識に補って読んでしまいます。そのため、テーマを知らない読者にとって読める文章かどうかを確認します。

表記の統一が問われるのは、1本の記事ではなくメディア全体の単位です。記事ごとに同じ製品名や概念の書き方が違うと、読者はそのメディアが内容を確認しているのかを疑い始めます。

## 技術用語のチェック

### 確認すること

用語のチェックで見つかるのは、一般的な校正では見落とされる誤りです。製品名の誤記や古いバージョン番号は、文章としては自然に読めてしまうためです。

| 確認項目 | 起きる問題 | 対応 |
| - | - | - |
| 表記ゆれ | 1本の記事の中で、同じ対象が複数の書き方で書かれている | 1つの表記に決めて、記事全体で使う |
| 略語 | 読者が意味を知る前に略語が出てくる | 初出で正式名称を示す。想定読者が知らない可能性があれば略さない |
| 固有名詞 | 製品やプロジェクトの名前の大文字小文字・区切りが誤っている | 製品の公式ドキュメントにある表記を使う |
| バージョン・時点への依存 | 特定のバージョン、または執筆時点でのみ正しい記述になっている | 記述が当てはまるバージョンや日付を明記する |

最も注意が必要なのは、バージョンと時点への依存です。「このオプションがデフォルトです」という記述は、執筆時には正しくても1年後には誤りになりえます。そのため、どのバージョンで確認したかを記事に書きます。

### 避ける表記と推奨する表記

| 避ける | 推奨する | 理由 |
| - | - | - |
| 「サーバー」と「サーバ」が混在 | どちらか一方に統一（例:「サーバー」） | 長音符の有無による表記ゆれ |
| 「インターフェース」と「インタフェース」が混在 | どちらか一方に統一 | カタカナ表記のゆれ |
| 全角英字の「Ｇｉｔ」 | 半角英字の「Git」 | 全角と半角の混在 |
| Javascript、javascript | JavaScript | 公式の大文字小文字 |
| 初出から「K8s」 | 「Kubernetes」。略す場合も初出で正式名称を示してから | 定義前の略語 |
| 「最新版で対応しています」 | 「バージョン3.2で対応しています」 | 時点に依存する表現 |

### 用語辞書を持つ

記憶に頼った用語のチェックは安定しません。編集者ごとに覚えているルールが違うためです。用語辞書はルールを1か所に固定し、チェックを照合の作業に変えます。

実用的な用語辞書は、正しい表記・誤った表記の例・備考の3列で構成します。備考には、そのルールの理由や根拠を書きます。備考があると、次の編集者が迷う事例に出会ったとき、推測ではなく根拠に基づいて判断できます。

> [!TIP]
>
> 照合は辞書に載っている語に限ります。辞書にない語を直感で「修正」すると、見慣れない名前についての思い込みが新しい誤りを生みます。繰り返し表記ゆれが起きる語が見つかったら、根拠とあわせて辞書に追加します。

## 編集の手順

原稿は、大きな単位から小さな単位の順に編集します。後で削る段落の言い回しを直しても作業が無駄になるため、文より先に構成を確認します。

**1. 構成を確認する**

想定読者を確認します。見出しが記事の中身と一致しているか、各節が読者の追える順序で並んでいるかを確認します。

**2. 事実を確認する**

誤りうる記述を1つずつ確認します。定義・分類・数値・バージョンに依存する挙動・比較が対象です。根拠として認めるのは、公式ドキュメントや仕様書などの一次情報だけです。確認できない記述は書き換えず、書き手に根拠を尋ねます。

**3. 用語をチェックする**

原稿の用語を用語辞書と照合します。表記ゆれを統一し、略語は初出で正式名称を示し、固有名詞とバージョンの記述が正しいかを確認します。

**4. 表現を調整する**

長い文を短くし、冗長な言い回しを削り、想定読者が知らない可能性のある専門用語を言い換えます。修正は1つひとつを小さく保ち、理由を説明できる範囲にとどめます。

**5. 書き手に確認する**

実質的な修正には理由を添えて、編集した原稿を書き手に戻します。公開する最終版は書き手が承認します。

生成AIは、この手順に入る前の下ごしらえに使えます。たとえば、要件から最初の構成案を作らせたり、見出しの候補を挙げさせたりする使い方です。その出力は出発点であり、上の手順、特に事実の確認をすべて通します。

## 注意点

### 書き手の意図を尊重する

記事は書き手のものです。編集者の修正が正当化されるのは、正確性・読みやすさ・表記の統一のいずれかに役立つ場合です。編集者なら別の書き方をするという理由だけの修正は、これに当たりません。

意味の取りにくい箇所は、書き換える前に書き手の意図を確認します。誤った推測に基づく書き換えは、文章は整って見えても、技術的な意味が変わってしまうことがあり、元の文章よりも悪い結果になります。

### 過剰な修正を避ける

過剰な修正は書き手の語り口を消し、メディアのすべての記事を同じような文章にしてしまいます。また、書き手が本来は不要だった修正まで確認することになり、進行も遅くなります。

1つの修正は、それが解決する問題の範囲にとどめます。誤りを見つけたらその箇所だけを直し、周辺の文章や書き手の文体には手を入れません。

> [!NOTE]
>
> 原稿を戻すときは、必須の修正と提案を分けて示します。必須の修正は事実・用語・メディアの基準に関する誤りであり、提案は書き手が採否を決められる改善案です。この区別を示すことで、提案を採用するかどうかを書き手自身が判断できます。

## 関連ページ

> [card] [DevRelの役割](https://lib.findy.co.jp/ja/devrel/engineering-culture.md)
>
> 企業がエンジニアコミュニティと関わる方法の中で、技術メディアがどこに位置づくかを確認できます。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.