> For the complete documentation index, see [llms.txt](https://engineer.toggle.co.jp/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://engineer.toggle.co.jp/chapter-1-toggle-holdings-engineer-101/ji-chu-yan-xiu/dokyumentonoki.md).

# 技術ドキュメントの書き方

## 技術ドキュメントの重要性

### **ドキュメントの役割と意義**

技術ドキュメントは、エンジニアが日々の業務で行った作業や取った決定を明記するためのものです。それだけでなく、他のエンジニアや関連するステークホルダーに情報を伝える役割も果たします。

**具体例：**\
あるソフトウェア開発プロジェクトで、特定の機能の実装方法を独自に変更したとします。この変更理由や方法を技術ドキュメントに詳細に記載することで、後からプロジェクトに関与するエンジニアが同じ機能を修正やアップデートする際、なぜそのような実装が選ばれたのかを理解しやすくなります。これにより、無駄な時間をかけずに作業を進めることができるようになります。

### **エンジニアリングプロセスにおけるドキュメントの位置づけ**

エンジニアリングのプロセスは複雑で、多くのステップと決定点を持っています。技術ドキュメントは、このプロセスの中で発生する多くの情報や決定をキャッチし、後で参照や確認ができるように整理する役割を果たします。

**具体例：**\
新しいシステムの設計フェーズでは、多くの技術的な決定が行われます。これらの決定をドキュメントに記録することで、実装フェーズやテストフェーズ、さらには運用フェーズに入ったときに、設計時の意図や考え方を確認できます。また、新たにプロジェクトチームに参加するエンジニアが、システム全体の設計思想や、特定の技術的選択がなされた背景を速やかにキャッチアップするためのリファレンスとしても利用できます。

## 目的と対象読者の明確化

### **どのような読者を対象とするか？**

技術ドキュメントを作成する際、そのドキュメントが誰に向けられているのかを明確にすることは非常に重要です。

**具体例：**\
あなたが新しいAPIのドキュメントを作成する場面を想像してみましょう。このAPIドキュメントの主要な読者は、そのAPIを使用する予定の開発者です。したがって、彼らが必要とする詳細な技術情報や使用方法を提供する必要があります。

### **ドキュメントの目的の定義**

ドキュメントには様々な目的が考えられます。その目的を明確にすることで、どのような内容を含めるべきか、どのようなトーンやスタイルで書くべきかが明確になります。

**具体例：**\
同じAPIに関して、一つは開発者向けの技術ドキュメント、もう一つは経営層やマーケティング部門向けの概要説明書を作成する場合、それぞれのドキュメントの目的は異なります。前者はAPIの詳細な仕様や使い方を説明すること、後者はAPIのビジネス価値や市場でのポジショニングを説明することが目的となります。

## ドキュメントの基本構造

### **タイトル、目次、導入部、本文、結論、参考文献**

ドキュメントは、以下の基本的な構造を持つことが一般的です。

**具体例：**\
「新しいデータベースマイグレーションツールの導入」を題材にしたドキュメントを想像してみましょう。

* **タイトル:** 新しいデータベースマイグレーションツールの導入ガイド
* **目次:** 各セクションへのリンクやページ番号
* **導入部:** なぜこの新しいツールを導入するのか、その背景や目的を説明
* **本文:** ツールの具体的な使い方、注意点、ベストプラクティスなどを詳細に説明
* **結論:** このツールの導入で得られるメリットや、次のステップについての情報を提供
* **参考文献:** このドキュメント作成時に参照した文献や外部リンク

### **各セクションの役割とポイント**

* **タイトル:** ドキュメントの内容を一目で伝えるための短い文言
* **目次:** 長いドキュメントでは、読者が必要な情報をすぐに見つけるためのナビゲーションとして機能
* **導入部:** 読者に背景情報を提供し、ドキュメントの内容を理解するための文脈を設定
* **本文:** 主要な情報や詳細を提供する核心部分
* **結論:** 主要なポイントを再確認し、読者に次に取るべきアクションを示す
* **参考文献:** 信頼性の確保や、さらなる詳細情報を求める読者のためのリソース

## 明確で分かりやすい言語の使用

### **テクニカルタームの適切な使用**

技術的な用語は適切に使用することで、専門家同士のコミュニケーションを効果的に行うことができます。しかし、その用語を知らない読者には理解が難しい場合があります。

「**APIエンドポイントを使用してデータをフェッチします**」という文は、APIやエンドポイントに精通している人には理解しやすいですが、初心者には難解かもしれません。そのような場合は、用語の定義や簡単な説明を追加することで明確にします。

### **アクティブボイスとパッシブボイス**

アクティブボイスは主語が行動を行う形式で、パッシブボイスは主語が行動の受け手となる形式です。アクティブボイスは文章をダイレクトにし、通常はより明確に情報を伝えることができます。

**具体例：**\
アクティブボイス: 「私たちは新しいデータベースを導入しました。」\
パッシブボイス: 「新しいデータベースが私たちによって導入されました。」

### **文の構造と明瞭さ**

簡潔で明確な文章を心がけることで、読者の理解を助けます。

**具体例：**\
長く複雑な文: 「データが毎日正午にバックアップサーバーに自動的に保存されるように設定されているので、もし何か問題が発生しても安心してください。」\
簡潔な文: 「データは毎日正午にバックアップされます。問題発生時も安心です。」

## 視覚的要素の活用

### **図表、グラフ、スクリーンショットの活用方法**

視覚的要素は、テキストだけでは伝えきれない情報や、複雑な情報を分かりやすくするのに役立ちます。

**具体例：**\
テキスト: 「今年の第2四半期の売上が前年同期比で20%増加しました。」\
グラフ: 前年と今年の第2四半期の売上を比較する棒グラフ。

### **デザインとレイアウトのヒント**

* 重要な情報は太字や色で強調します。
* 同じ種類の情報はリストや箇条書きを使用して整理します。
* グラフや図表はキャプションを付けて、その内容を簡潔に説明します。

**具体例：**\
エラーメッセージや注意点を記載する際に、赤色やアイコンを使用して目立たせる。また、手順を説明する際は番号付きのリストを使用して、手順の順番を明確にします。

## コードやプログラムのドキュメント化

### **コメントの書き方**

コメントはコードの理解を助け、将来的なメンテナンスを容易にします。

**具体例：**\
以下は、配列の各要素を2倍にする関数を示すTypeScriptのコードです。

```typescript
/**
 * 与えられた配列の各要素を2倍にする関数。
 * 
 * @param inputArray - 入力となる数値の配列
 * @returns 要素が2倍にされた配列
 */
function doubleElements(inputArray: number[]): number[] {
    return inputArray.map(element => element * 2);
}
```

### **APIドキュメントの基本**

APIの使用方法や仕様を明確に伝えるためのドキュメントです。

**具体例：**\
以下は、特定のユーザーIDを使用してユーザー情報を取得するAPIエンドポイントのドキュメントです。

```
GET /users/{id}

説明:
特定のユーザーの情報を取得します。

パラメータ:
- id: 取得したいユーザーのID (Type: number)

レスポンス:
200 OK
{
    "id": number,
    "name": string,
    "email": string
}
```

## APIを外部提供する場合のドキュメンテーション

APIを外部提供する際には、一般的にOpenAPI形式が良く使われます。OpenAPIは、RESTful APIの定義、説明、そしてビジュアル化を目的とした仕様です。OpenAPIの仕様書は、通常YAMLまたはJSON形式で記述されます。この仕様書をもとに、インタラクティブなドキュメントやクライアントSDKの生成など、多岐にわたるツールやサービスを活用することができます。

最も一般的なツールは、Swagger UIで、これを使うことでOpenAPI仕様から直接、ブラウザ上で操作可能なAPIドキュメントを生成できます。

#### 具体例

以下は、シンプルなOpenAPIの例です。この例では、`GET` メソッドを使用して`/users/{userId}` エンドポイントからユーザー情報を取得するAPIを定義しています。

<pre class="language-yaml"><code class="lang-yaml"><strong>openapi: 3.0.0
</strong>info:
  version: 1.0.0
  title: Simple User API
  description: A simple API to retrieve user data
paths:
  /users/{userId}:
    get:
      summary: Get user by ID
      description: Returns a single user
      parameters:
        - name: userId
          in: path
          description: ID of user to fetch
          required: true
          schema:
            type: integer
      responses:
        '200':
          description: A single user object
          content:
            application/json:
              schema:
                type: object
                properties:
                  id:
                    type: integer
                  name:
                    type: string
                  email:
                    type: string
        '404':
          description: User not found
</code></pre>

このYAMLファイルは、以下の情報を表現しています：

* APIの基本情報（タイトル、説明、バージョン）
* `GET /users/{userId}` エンドポイントの詳細
  * パラメータ`userId`はパス内で必須
  * 成功時のレスポンス（HTTPステータスコード200）は、ユーザーオブジェクトをJSON形式で返す
  * ユーザーが見つからない場合のレスポンス（HTTPステータスコード404）

Swagger UIやRedocなどのツールを使用すると、このYAMLから直感的なインタラクティブドキュメントを生成することができます。

## バージョン管理と更新

### **ドキュメントの変更履歴の記録**

変更内容や理由を明確にするために、変更履歴をドキュメントに記載することが重要です。

**具体例：**

```
変更履歴:

- 2023/09/01: ユーザーAPIのレスポンスに「email」フィールドを追加。
- 2023/08/25: エラーレスポンスのフォーマットを更新。
```

### **古い情報の見直しと更新のプロセス**

古い情報や非推奨の内容を定期的に見直し、必要に応じて更新します。

**具体例：**\
APIがバージョンアップされ、一部のエンドポイントが非推奨になった場合、その旨をドキュメントに明記し、代替のエンドポイントや方法を案内します。

## フィードバックとレビューの取り込み

### **ピアレビューの重要性**

同僚や他の開発者からのレビューは、ドキュメントの質を高めるのに役立ちます。

**具体例：**\
ある関数の挙動をドキュメント化した後、同僚がその関数の例外ケースについての情報が不足していることを指摘。それを受けて、ドキュメントを修正・補完します。

### **改善のためのフィードバックの収集と活用**

ユーザーや他の開発者からのフィードバックを収集し、それを基にドキュメントを更新・改善します。

**具体例：**\
APIのエンドユーザーから、あるエンドポイントの使用方法が分かりにくいとのフィードバックを受け取った。それを受けて、該当部分の説明を詳細にし、サンプルコードを追加します。