報告書の書き方と例文｜結論から書く構成とテンプレート5種

報告書とは、頼まれた調査や作業の結果を、読み手が次の判断や行動に移れる形で伝える文書です。書く順番は「結論→根拠→経緯→次の対応」で、事実と意見は別の見出しに分けます。 読み手が最初に知りたいのは「結局どうだったのか」と「自分は何をすればよいのか」で、経緯はそのあとに確かめる材料です。

この記事では、単発の調査や作業を終えたあとに書く報告書を扱います。調査報告書・作業報告書・検証結果報告書など5種を、架空の「図書貸出システム」の作業で埋めた記入例つきテンプレートとして載せました。毎日・毎週の定期的な報告や、プロジェクト全体の完了時・障害発生時の報告は対象にせず、「1回の調査・1回の作業の報告」 に絞っています。

確認環境（確認日 2026-10-06）：書き換え対比の文字数と行数は Python 3.11 で数え、テンプレートの表と見出しは Python-Markdown 3.10 で HTML に変換して崩れないことを確かめました。記入例の人名・部署名・数値はすべて架空です。

この記事の結論

• 順番は「結論→根拠→経緯→次の対応」。経緯から書き始めない
• 事実（確認できたこと）と意見（考察・提案）は別の見出しに分ける。1つの文に混ぜない
• 件名に「報告の種類・対象・結論」を入れ、冒頭3行で「結論・根拠・お願い」を言い切る
• 数値には単位・期間・母数を、日時には日付と曜日を、範囲には「対象外」も書く
• 報告書の種類ごとに、結論として書くものが違う（調査＝原因や答え、作業＝完了と結果、検証＝合否）

報告書の早見表（5種類の結論と構成）

タブ区切り版：

種類  書く場面    結論として書くこと   見出しの並び
調査報告書   原因や状況を調べるよう頼まれた 分かったこと（原因・答え）と確からしさ 結論→事実→考察→次の対応→経緯
作業報告書   依頼された作業を行った 完了したか、結果の件数、残ったこと   結論→作業結果→予定との差→残作業→経緯
検証結果報告書 変更や案が期待どおりかを確かめた    合否と、条件・残る心配 結論→検証結果→条件と範囲→考察→次の対応
比較検討報告書 複数の案を比べるよう頼まれた  推奨する案と理由    結論→比較表→各案の評価→選ばなかった理由→次の対応
問い合わせ対応報告書  利用者からの問い合わせを調べて回答した 回答の内容と、対応が済んだか  結論→問い合わせ内容→確認した事実→回答→今後の扱い

なぜ「結論→根拠→経緯→次の対応」の順なのか

読み手に判断や作業をお願いする場合は、4の「お願い」を冒頭3行にも1文で入れます。経緯は記録として大切ですが、判断に使うのは結論と根拠です。

件名と冒頭3行の型

件名の型

【報告の種類・相手にしてほしいこと】対象＋結論 の形にします。

冒頭3行の型

読み手にしてもらうことが無い場合も、3行目に 「ご対応は不要です」 と書くと、読み手が最後まで探さずに済みます。

時系列版と結論から書いた版の書き換え対比

同じ内容を、2通りに書いて比べます。題材は、架空の図書貸出システムで「月曜の朝に画面が遅い」と連絡を受けて調べた結果の報告です。

時系列で書いた版

件名：図書貸出システムの件

お疲れさまです。情報システム課の鈴木です。
9月28日（月）に、総務課から「月曜の朝に貸出画面の表示が遅い」と連絡がありました。
9月29日（火）にアプリケーションのログを確認しましたが、エラーは出ていませんでした。
9月30日（水）に画面の表示時間の記録を4週間分集計したところ、月曜の9:00〜9:40だけ平均8.5秒で、ほかの時間帯は平均1.2秒でした。
10月1日（木）にデータベースの処理の記録を調べたところ、月曜6:00開始の週次集計（延滞一覧の作成）が9:35ごろまで動いていました。
10月2日（金）に過去の所要時間を調べると、4月は平均95分、9月は平均215分で、蔵書データの増加にあわせて延びていました。
以上のことから、遅くなる原因は、週次集計が始業後の利用時間帯と重なったことだと考えています。
集計の開始時刻を日曜22:00に変更すれば、重ならなくなる見込みです。
変更してよいか、ご判断をお願いします。

結論から書いた版

件名：【調査報告・ご判断のお願い】月曜朝の貸出画面の遅さは週次集計との重なりが原因（開始時刻の変更案）

結論：月曜9:00〜9:40に貸出画面の表示が遅くなる原因は、週次集計が始業後の利用時間帯と重なったことです。
根拠：この時間帯だけ表示が平均8.5秒（ほかは平均1.2秒）で、週次集計が月曜6:00から9:35ごろまで動いていました。
お願い：集計の開始時刻を日曜22:00に変更してよいか、10月9日（金）までにご判断ください。

■ 事実（確認できたこと）
・表示時間（9月の4週間分）：月曜9:00〜9:40は平均8.5秒、その他の時間帯は平均1.2秒
・週次集計（延滞一覧の作成）：月曜6:00開始。所要時間は4月が平均95分、9月が平均215分
・アプリケーションのログ：期間中のエラーは0件

■ 考察（意見）
・蔵書データの増加で集計の時間が延び、所要時間が180分を超えた時点から始業（9:00）後に掛かるようになったと考えます。
・データは今後も増えるため、開始時刻を前倒ししない場合、重なる時間は長くなる見込みです。

■ 次の対応
・ご承認後、10月11日（日）の回から開始時刻を22:00に変更します（担当：鈴木）。
・10月12日（月）の表示時間を測り、10月13日（火）に結果を報告します。

■ 経緯
・9/28 総務課から連絡 → 9/29 ログ確認 → 9/30 表示時間を集計 → 10/1 処理の記録を確認 → 10/2 過去の所要時間を確認

2つの版を数えて比べる

結論とお願いが本文の何文字目・何行目に出てくるかを、Pythonで数えました（件名は除く）。

# 同じ内容の2つの報告文で、結論・お願いが何文字目・何行目に出てくるかを数える
def measure(path, keys):
    text = open(path, encoding="utf-8").read()
    body = text.split("\n", 2)[2]          # 件名と空行を除いた本文
    lines = [l for l in body.split("\n") if l.strip()]
    print(path, f"本文 {len(body.replace(chr(10), ''))}字 / {len(lines)}行")
    for label, key in keys:
        pos = body.replace("\n", "").index(key) + 1
        line = next(i for i, l in enumerate(lines, 1) if key in l)
        print(f"  {label}: {pos}字目 / {line}行目")

keys = [("原因（結論）", "重なったこと"), ("お願い", "変更してよいか")]
measure("v_time.txt", keys)
measure("v_concl.txt", keys)

実行結果（v_time.txt が時系列版、v_concl.txt が結論から書いた版）：

v_time.txt 本文 408字 / 9行
  原因（結論）: 340字目 / 7行目
  お願い: 390字目 / 9行目
v_concl.txt 本文 572字 / 15行
  原因（結論）: 47字目 / 1行目
  お願い: 137字目 / 3行目

書き換えの手順

事実と意見を分ける書き方

事実は「誰が確かめても同じになること」、意見は「そこから自分が考えたこと」 です。混ざっていると、読み手はどこまでが確かな話かを判断できません。

文末の使い分けも決めておくと、見出しが無い短い報告でも区別できます。

テンプレート1：調査報告書（記入例つき）

結論は「分かったこと」と「どの程度確かか」です。原因が1つに絞れていない場合は、その旨と次に調べることを結論に書きます。

# 調査報告書：月曜朝の貸出画面の表示が遅い件

- 報告日：2026年10月2日（金）
- 報告者：情報システム課 鈴木 一郎
- 宛先：情報システム課 田中課長
- 依頼内容：総務課から連絡のあった「月曜の朝に貸出画面が遅い」件の原因調査（9月28日依頼）

## 1. 結論

- 原因は、週次集計（延滞一覧の作成）が始業後の利用時間帯と重なったことです。
- 対策として、集計の開始時刻を月曜6:00から日曜22:00へ変更することを提案します。
- 変更してよいか、10月9日（金）までにご判断ください。

## 2. 調査の範囲

| 項目 | 内容 |
|---|---|
| 対象 | 図書貸出システムの貸出画面（本社） |
| 期間 | 2026年9月1日（火）〜9月28日（月）の4週間 |
| 調べたもの | 画面の表示時間の記録、アプリケーションログ、データベースの処理の記録 |
| 対象外 | 利用者のパソコンと社内ネットワークの状態 |

## 3. 事実（確認できたこと）

| No. | 確認したこと | 結果 |
|---|---|---|
| 1 | 画面の表示時間（月曜9:00〜9:40） | 平均8.5秒 |
| 2 | 画面の表示時間（その他の時間帯） | 平均1.2秒 |
| 3 | 週次集計の実行時間帯 | 月曜6:00開始、9:35ごろ終了 |
| 4 | 週次集計の所要時間 | 4月は平均95分、9月は平均215分 |
| 5 | アプリケーションログのエラー | 0件 |

## 4. 考察（意見）

- 蔵書データの増加で集計の時間が延び、所要時間が180分を超えた時点から
  始業（9:00）後に掛かるようになったと考えます。
- 月曜以外の表示時間は平均1.2秒で安定しているため、画面側の変更は不要と考えます。

## 5. 次の対応

| 対応 | 担当 | 期限 |
|---|---|---|
| 開始時刻の変更可否の判断 | 田中課長 | 10月9日（金） |
| 承認後、10月11日（日）の回から開始時刻を変更し、翌朝の表示時間を測定 | 鈴木 | 10月12日（月） |
| 総務課への回答 | 鈴木 | 判断の翌営業日 |

## 6. 経緯

| 日付 | 行ったこと |
|---|---|
| 9月28日（月） | 総務課から連絡を受ける |
| 9月29日（火） | アプリケーションログを確認 |
| 9月30日（水） | 表示時間の記録を4週間分集計 |
| 10月1日（木） | データベースの処理の記録を確認 |
| 10月2日（金） | 週次集計の過去の所要時間を確認、報告書を作成 |

## 7. 添付

- 表示時間の集計表（時間帯別）
- 週次集計の所要時間の一覧（4月〜9月）

テンプレート2：作業報告書（記入例つき）

結論は「完了したか」「何件できて、何件残ったか」です。予定と違った点は、理由と影響をセットで書きます。

# 作業報告書：蔵書データの分類コード一括更新

- 報告日：2026年10月7日（水）
- 報告者：情報システム課 鈴木 一郎
- 宛先：総務課 高橋様、情報システム課 田中課長
- 依頼内容：分類コードの見直しに伴う蔵書データの一括更新（依頼書 No.2026-031）

## 1. 結論

- 作業は完了しました。対象12,480件のうち12,474件を更新しました。
- 残り6件は貸出中のため更新を見送り、10月16日（金）に更新します。
- 利用者への影響はありません。ご対応は不要です。

## 2. 作業結果

| 項目 | 予定 | 結果 |
|---|---|---|
| 作業日時 | 10月6日（火）20:00〜21:00 | 10月6日（火）20:00〜21:25 |
| 対象件数 | 12,480件 | 12,480件 |
| 更新件数 | 12,480件 | 12,474件 |
| 見送り件数 | 0件 | 6件（貸出中） |
| システムの停止 | 20:00〜21:00 | 20:00〜21:25 |

## 3. 予定と違った点

| 違い | 理由 | 影響 | 対応 |
|---|---|---|---|
| 終了が25分遅れた | 作業前のバックアップ取得に予定より時間が掛かった | 停止時間が25分延びた。延長中の利用は0件 | 次回はバックアップの所要時間を40分で見込む |
| 6件を見送った | 貸出中のデータは更新しない手順のため | 6件は従来の分類コードで表示される | 返却予定日後の10月16日（金）に更新する |

## 4. 作業後の確認

| 確認項目 | 結果 |
|---|---|
| 更新後の件数が更新前と一致する | 一致（12,480件） |
| 従来の分類コードが残っている件数 | 6件（見送り分と一致） |
| 貸出画面で分類コードの検索ができる | 確認済み（3種類のコードで検索） |

## 5. 残作業

| 作業 | 担当 | 期限 |
|---|---|---|
| 見送った6件の更新 | 鈴木 | 10月16日（金） |
| 更新完了の連絡 | 鈴木 | 10月16日（金） |

## 6. 添付

- 作業手順書（確認印つき）
- 更新前後の件数の記録
- 見送った6件の一覧

テンプレート3：検証結果報告書（記入例つき）

結論は「合格か、条件つきか、見直しが必要か」です。検証した条件（環境・データ量・回数）を書くと、結果の当てはまる範囲が伝わります。

# 検証結果報告書：週次集計の開始時刻変更

- 報告日：2026年10月13日（火）
- 報告者：情報システム課 鈴木 一郎
- 宛先：情報システム課 田中課長
- 目的：開始時刻を日曜22:00に変更すれば、月曜朝の表示の遅さが解消するかを確かめる

## 1. 結論

- 合格です。検証項目6件のうち5件が合格、1件が条件つき合格でした。
- 月曜9:00〜9:40の表示時間は平均1.3秒になりました（変更前は平均8.5秒）。
- 条件つきの1件（日曜夜の夜間バックアップとの重なり）は、運用で確認を続けます。

## 2. 検証の条件

| 項目 | 内容 |
|---|---|
| 環境 | 本番環境（10月11日の回から変更を適用） |
| データ量 | 蔵書データ 12,480件、貸出履歴は9月末時点の全件 |
| 測定した日時 | 10月11日（日）22:00〜10月12日（月）10:00 |
| 回数 | 1回（1週分） |
| 対象外 | 月末・年度末の利用が多い週 |

## 3. 検証結果

| No. | 検証項目 | 合格の基準 | 結果 | 判定 |
|---|---|---|---|---|
| 1 | 集計が始業前に終わる | 月曜8:00までに終了 | 月曜1:35に終了 | 合格 |
| 2 | 月曜朝の表示時間 | 平均2.0秒以下 | 平均1.3秒 | 合格 |
| 3 | 延滞一覧の件数 | 変更前の手順で作った一覧と一致 | 一致 | 合格 |
| 4 | 延滞一覧の配信時刻 | 月曜8:30に配信 | 月曜8:30に配信 | 合格 |
| 5 | エラーの有無 | 0件 | 0件 | 合格 |
| 6 | ほかの夜間処理との重なり | 重ならない | 夜間バックアップ（日曜23:00〜23:20）と重なった。双方とも正常に終了 | 条件つき合格 |

## 4. 考察（意見）

- 集計の所要時間は215分で変更前と変わらず、時間帯を移した効果で朝の重なりが無くなったと考えます。
- バックアップとの重なりは今回は影響がありませんでしたが、データが増えた場合に備えて所要時間の記録を続けるのがよいと考えます。

## 5. 次の対応

| 対応 | 担当 | 期限 |
|---|---|---|
| 開始時刻の変更を正式な設定とする | 鈴木 | 10月14日（水） |
| 集計とバックアップの所要時間を4週間記録する | 鈴木 | 11月9日（月） |
| 総務課への結果の連絡 | 鈴木 | 10月13日（火） |

テンプレート4：比較検討報告書（記入例つき）

結論は「推奨する案と、その理由」です。選ばなかった案の理由も1行ずつ書くと、あとから同じ議論を繰り返さずに済みます。

# 比較検討報告書：蔵書検索の改善方式

- 報告日：2026年10月20日（火）
- 報告者：情報システム課 鈴木 一郎
- 宛先：情報システム課 田中課長
- 依頼内容：蔵書検索の待ち時間を短くする方式を3案で比べる

## 1. 結論

- A案（現行の検索に索引を追加）を推奨します。合計点は84点で3案中の最高です。
- 理由は、導入の手間と運用のしやすさが最も良く、検索の速さも目標を満たすためです。
- A案で進めてよいか、10月27日（火）までにご承認ください。

## 2. 比較表

点数は各項目5点満点、合計は重みを掛けて100点満点に換算しています。

| 評価項目 | 重み | A案 索引を追加 | B案 全文検索の機能を利用 | C案 外部の検索サービスを利用 |
|---|---|---|---|---|
| 検索の速さ | 40 | 3 | 5 | 5 |
| 導入の手間 | 30 | 5 | 3 | 2 |
| 運用のしやすさ | 30 | 5 | 4 | 3 |
| 合計（100点換算） |  | 84 | 82 | 70 |

## 3. 各案の評価（事実）

| 案 | 確かめたこと |
|---|---|
| A案 | 検証環境で索引を追加し、検索の待ち時間が目標（2秒以内）に収まることを確認した |
| B案 | 検索は最も速い。検索用のデータを別に作り直す作業が週1回必要になる |
| C案 | 検索は速い。蔵書データを外部へ送る設定と、社内の情報管理の確認が必要になる |

## 4. 選ばなかった理由

- B案：A案との差は2点。検索用データの作り直しという新しい運用が増えるため。
- C案：導入の手間が最も大きく、今回の目的（待ち時間の短縮）に対して範囲が広いため。

## 5. 考察（意見）

- 蔵書が現在の2倍を超える時期には、B案を再検討する価値があると考えます。

## 6. 次の対応

| 対応 | 担当 | 期限 |
|---|---|---|
| A案の承認 | 田中課長 | 10月27日（火） |
| 本番環境への索引の追加 | 鈴木 | 11月4日（水） |

テンプレート5：問い合わせ対応報告書（記入例つき）

結論は「回答の内容」と「対応が済んだかどうか」です。同じ問い合わせが再び来たときに使えるよう、確認した事実と回答文を残します。

# 問い合わせ対応報告書：返却済みの本が延滞一覧に載っている件

- 報告日：2026年10月22日（木）
- 報告者：情報システム課 鈴木 一郎
- 宛先：情報システム課 田中課長
- 問い合わせ元：総務課 高橋様（10月21日（水）10:15、メール）

## 1. 結論

- システムは設計どおりに動いており、修正は不要です。総務課へ回答済みです。
- 延滞一覧は作成した時刻のデータで作られるため、作成後に返却された本は次の一覧まで残ります。
- 一覧に作成日時を表示する改善を提案します。ご判断をお願いします（期限は設けません）。

## 2. 問い合わせ内容

- 「10月19日（月）に返却した本が、同じ日に届いた延滞一覧に載っている」

## 3. 確認した事実

| No. | 確認したこと | 結果 |
|---|---|---|
| 1 | 対象の本の返却日時 | 10月19日（月）10:42 |
| 2 | 延滞一覧の作成日時 | 10月19日（月）1:35（配信は8:30） |
| 3 | 10月21日時点の貸出状態 | 返却済み |
| 4 | 同じ条件の本 | 10月19日の一覧62件のうち4件 |

## 4. 回答（10月21日（水）15:30 にメールで送付）

- 延滞一覧は月曜の未明に作成しており、その後に返却された本は一覧に残ります。
- 対象の本は返却済みとして記録されています。追加の手続きは不要です。

## 5. 今後の扱い

| 対応 | 担当 | 期限 |
|---|---|---|
| 一覧に「作成日時」を表示する改善の可否の判断 | 田中課長 | 未定 |
| よくある問い合わせの一覧に追記 | 鈴木 | 10月23日（金） |

共通の骨組み（空欄テンプレート）

5種のどれにも当てはまらない報告は、次の骨組みから始めます。

# [報告の種類]：[対象と結論を短く]

- 報告日：
- 報告者：
- 宛先：
- 依頼内容：

## 1. 結論
- [分かったこと／終わったこと／合否]
- [根拠となる数字を1〜2個]
- [読み手にお願いしたいことと期限。無ければ「ご対応は不要です」]

## 2. 範囲
| 項目 | 内容 |
|---|---|
| 対象 |  |
| 期間 |  |
| 対象外 |  |

## 3. 事実（確認できたこと）
| No. | 確認したこと | 結果 |
|---|---|---|
| 1 |  |  |

## 4. 考察（意見）
-

## 5. 次の対応
| 対応 | 担当 | 期限 |
|---|---|---|
|  |  |  |

## 6. 経緯
| 日付 | 行ったこと |
|---|---|
|  |  |

項目だけを表計算ソフトで管理する場合のタブ区切り版：

見出し 書くこと    記入例
件名  種類・対象・結論    【調査報告・ご判断のお願い】月曜朝の貸出画面の遅さは週次集計との重なりが原因
結論  分かったこと、終わったこと、合否    原因は週次集計が始業後の利用時間帯と重なったこと
根拠  結論を支える数字    月曜9:00〜9:40だけ平均8.5秒、その他は平均1.2秒
お願い 読み手にしてほしいことと期限  開始時刻の変更可否を10月9日（金）までに判断
範囲  対象、期間、対象外   本社の貸出画面、9月1日〜28日、利用者のパソコンは対象外
事実  確認できたこと 週次集計の所要時間は4月が平均95分、9月が平均215分
考察  自分の考え   蔵書データの増加で集計が延びたと考える
次の対応    担当と期限   承認後、10月11日の回から変更して翌朝に測定（鈴木、10月12日）
経緯  日付順の記録  9/28連絡、9/29ログ確認、9/30集計、10/1処理記録、10/2所要時間

数値・日時・対象範囲の書き方チェック表

タブ区切り版：

区分  確認すること  直す前 直した後
数値  単位が付いている    表示が8.5  表示が平均8.5秒
数値  平均・最大・合計の区別がある  表示時間は8.5秒   表示時間は平均8.5秒（最大は別に記載）
数値  母数がある   6件を見送った 12,480件のうち6件を見送った
数値  比べる相手がある    215分掛かった    4月の平均95分に対し、9月は平均215分
数値  「多い」「かなり」を数字にした かなり遅い   平均1.2秒に対して平均8.5秒
日時  日付と曜日がある    先週の月曜   9月28日（月）
日時  開始と終了がある    夜に作業した  10月6日（火）20:00〜21:25
日時  期限が日付で書いてある 早めにご判断ください  10月9日（金）までにご判断ください
日時  24時間表記でそろえた 朝6時、21:25   6:00、21:25
範囲  対象が書いてある    システムを調べた    本社の貸出画面を調べた
範囲  期間が書いてある    最近の記録   9月1日（火）〜9月28日（月）の4週間
範囲  対象外が書いてある   （記載なし）  利用者のパソコンと社内ネットワークは対象外
範囲  回数・条件が書いてある 検証して問題なかった  本番環境で1回（1週分）検証し、6件中5件が合格

PREP・SDS・時系列の違いと選び方

この記事の「結論→根拠→経緯→次の対応」は、PREPの形を報告書向けに並べ直したものです。理由と具体例を「根拠（事実）」にまとめ、最後の結論を「次の対応」に置き換えています。

どの型で書くかの判断基準

似た報告との書き分け

確かめて分かったこと

• 結論から書いた版は、文字数では長くなった：時系列版408字に対して572字でした。短くすることが目的ではなく、結論が出る位置を340字目から47字目へ、お願いを最後の行から3行目へ動かすことが効果の中身です。
• 時系列版には期限が入りにくい：流れのまま書くと最後が「ご判断をお願いします」で終わり、いつまでにが抜けました。冒頭3行の型にすると、3行目に期限を書く場所ができます。
• 時系列版では、事実と意見が同じ文の流れに並ぶ：「以上のことから〜と考えています」の1文だけが意見で、前後は事実でした。見出しを分けると、意見が2項目あること（原因の見立てと、今後の見込み）がはっきりしました。
• Markdownの表は、区切り行が無いと表にならない：Python-Markdown で変換したところ、見出し行の次に |---| の行がある表だけが表として出力されました。テンプレートを書き換えるときは、区切り行を消さないようにします。
• 「-」だけの行は箇条書きにならず、ハイフンの文字として出力される：空欄テンプレートの「-」だけの行は、変換すると記号1文字の段落になりました。提出前に、記入していない行が残っていないかを見直します。

よくある質問

Q. 報告書とは何ですか？ A. 頼まれた調査や作業の結果を、読み手が判断や次の行動に使える形で伝える文書です。記録として残す役割もあるため、結論だけでなく根拠と範囲を書きます。

Q. 報告書とレポートの違いは？ A. 仕事の場面ではほぼ同じ意味で使われ、どちらも結果を伝える文書です。社内で使い分けの決まりがあればそれに従い、無ければ結論・根拠・次の対応がそろっているかで内容を整えます。

Q. PREP法とは何ですか？ A. 結論（Point）→理由（Reason）→具体例（Example）→結論（Point）の順で伝える型です。報告書では、最後の結論を「次の対応・お願い」に置き換えると使いやすくなります。

Q. 結論から書くと冷たい印象になりませんか？ A. 結論を先に書くことと、ていねいな言葉づかいは両立します。冒頭に宛名とひとことのあいさつを置き、その次の行から結論・根拠・お願いを書けば、読み手の時間を大切にした文面になります。

Q. 結論がまだ出ていないときは、どう書けばよいですか？ A. 「分かったこと」「分かっていないこと」「次に調べることと期限」の3点を結論として書きます。途中経過でも、この3点があれば読み手は待つか動くかを判断できます。

Q. 調査報告書と作業報告書の違いは？ A. 調査報告書は「調べて分かったこと」を、作業報告書は「行った作業の結果」を伝えます。調査報告書は事実と考察の区別が中心になり、作業報告書は予定と結果の差と残作業が中心になります。

まとめ

• 報告書は「結論→根拠→経緯→次の対応」の順で書く
• 事実と意見は別の見出しに分け、文末も使い分ける
• 件名は「種類・対象・結論」、冒頭3行は「結論・根拠・お願い（期限つき）」
• 種類ごとに結論が違う。調査は原因、作業は完了と件数、検証は合否、比較は推奨案、問い合わせ対応は回答
• 数値には単位と母数、日時には日付と曜日、範囲には対象外を書く
• 判断をお願いする報告はPREP、知らせるだけの報告はSDS、経緯を問われたら冒頭に結論を足した時系列
• 時系列で書いた下書きは、「以上のことから」に続く文を先頭へ移すところから直す

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。