読みやすい文章のコツ

ストーリー

「報告書の内容は合ってるんだけど、ちょっと読みにくいかな」

「えっ、どこがですか？」

「文章が長いのと、何が一番言いたいのか分かりにくい。 読みやすく書くコツがあるんだよ」

コツ1: 結論ファースト

最も重要な情報を最初に書きます。

技術文書は小説ではありません。読む人は忙しいので、結論から先に知りたいのです。

悪い例

今週はユーザー登録機能の実装に取り組みました。
最初にデータベースの設計を行い、次にAPIの実装をしました。
テストも書いたのですが、いくつかバグが見つかりました。
バグの修正に時間がかかり、予定より2日遅れています。

良い例

**ユーザー登録機能の実装が予定より2日遅延しています。**

原因はテストで発見したバグの修正に想定以上の時間がかかったためです。

### 詳細
- DB設計: 完了
- API実装: 完了
- テスト: バグ3件を発見し、うち2件を修正済み。残り1件を対応中

ポイント: まず「遅れている」という最重要情報を先に伝え、詳細は後から書く。

コツ2: 一文一意

1つの文に1つの意味だけを入れます。

悪い例

今週はログイン機能の実装を進めていて、認証ロジックの部分は完了したのですが、
画面のデザインがまだ確定していないため、フロントエンドの実装は着手できておらず、
来週の月曜日にデザイナーと打ち合わせをして、その後に着手する予定です。

良い例

- 認証ロジックの実装を完了した
- フロントエンド実装は未着手（画面デザインが未確定のため）
- 来週月曜日にデザイナーと打ち合わせ予定
- 打ち合わせ後にフロントエンド実装に着手する

ポイント: 長い一文を短い複数の文（箇条書き）に分解する。

コツ3: 箇条書きを活用する

並列する情報は箇条書きにします。

悪い例

今週の成果としては、APIの実装とテストの作成とドキュメントの更新があります。

良い例

今週の成果:
- APIの実装
- テストの作成（20件）
- ドキュメントの更新

箇条書きを使うべき場面

コツ4: 図表を活用する

文章で説明しにくい情報は、表や図で表現します。

悪い例

田中さんの進捗は80%で来週完了予定です。佐藤さんは50%で
予定通りです。鈴木さんは30%ですが、課題があり遅延リスクがあります。

良い例

| 担当 | タスク | 進捗 | 状況 |
|------|-------|------|------|
| 田中 | バックエンド実装 | 80% | 来週完了予定 |
| 佐藤 | フロントエンド実装 | 50% | 予定通り |
| 鈴木 | インフラ構築 | 30% | 遅延リスクあり |

コツ5: 曖昧な表現を避ける

具体的な数値や日付を使います。

コツ6: 主語を明確にする

誰が、何を、するのかを明確にします。

悪い例

確認した結果、問題ないことが分かった。
対応する予定。

良い例

田中が動作確認を実施し、問題ないことを確認した。
佐藤が来週月曜日にリリース対応を実施する予定。

読みやすさチェックリスト

文章を書いたら、以下をチェックしましょう。

• 結論が最初に書かれているか
• 1つの文が2行以上になっていないか
• 3つ以上の項目を列挙するとき箇条書きになっているか
• 表で表現できる情報は表にしているか
• 「いくつか」「近いうちに」などの曖昧表現がないか
• 主語が明確か

まとめ

• 読みやすい文章の6つのコツを学んだ
• 悪い例と良い例の違いを理解した
• チェックリストで自分の文章を確認できる

次のステップへ

読みやすい文章のコツは掴めましたか？

次のセクションでは、実際に報告書を作成する演習に取り組みます。 週報と障害報告書を書いてみましょう。

推定読了時間: 30分