【顛末書の書き方まとめ】社外・社内用の例文や書き方のコツを解説

「顛末書を書くよう言われたけど、何を書けばいいかわからない」
「始末書や報告書とは、何が違うのだろう？」
「もしものために、顛末書の書き方や書くときのコツを教えて！」

普段の仕事をしている時に、どうしてもミスによるトラブルが発生することがあります。

そして「顛末書を書くようなミスは二度と起こしたくない」と思うのは、社会人として当然であり避けたいでしょう。

そこで本記事では、顛末書の書き方や例文、始末書・報告書との違いについて解説。書かないための再発防止策や失敗例なども紹介するので、ぜひ参考にしてみてください。

顛末書（てんまつしょ）とは？

そもそも「顛末書（てんまつしょ）」とは何か分からないという人もいるでしょう。

顛末書とは、事件や事故、失敗に係る一部始終を報告するための書類のこと。

それこそ、いつ、どこでどの様なトラブルが発生し、それにどう対処したのか。これは「社内に当てた報告書」という位置付けで書かれることが多い書類です。

ですので、謝罪文ではなく、事態の再発防止のために書く書類だと考えて良いでしょう。

顛末書は経緯書と呼ばれる場合もあります。

顛末書を書く時は公平で客観的な目線が大切

再発防止のためには顛末がしっかりと把握でき、どこに問題発生の原因があったのかを特定しなければなりません。

そのため、顛末書は私情を挟まず、客観的に事実を書くことが重要です。

特定の個人を非難したり、誰か特定の個人からという偏った視点ではなく、平等になるよう、当事者以外の人間が書く事もあります。

社内文書ですから、宛先は代表取締役社長です。大企業の場合は、全てを代表取締役にあげるのは無理があるので、管轄している事業部長や、工場長宛てになることも。

 顛末書の提出には上長の確認が必要

顛末書の提出には、上司などの確認が必要です。

誰もチェックしないままに提出すると、内容が間違っていたとしても、顛末書という正規の書類として流れてしまうのです。

ですので、必ず第三者のチェックを受けてから提出する必要があります。

そして社内文書ですから、提出の際に封筒に入れる必要はありません。

ただし公的機関に提出する場合は別です。免許証やパスポートなどを紛失した際の「紛失顛末書」などは会社の規定に従い、必要に応じて封筒に入れて提出するなどしてください。

「顛末」の意味

顛末（てんまつ）は「ある出来事の最初から最後までのこと、一部始終」という意味。「顛」の字には、「いただき」や「はじまり」といった意味があります。

「はじまり」から「すえ」まで、という漢字の意味と合わせて覚えましょう。

顛末書と始末書・報告書との違い

会社では「顛末書」以外に「始末書」が用意されている場合も。

そこで本章では、顛末書・始末書・報告書の違いについて解説します。

始末書との違い

「始末書」は社内だけではなく社外、特に顧客に対しても提出されることがある書類です。

これは、社内はもちろん、不祥事に社外の人間も関与していた場合、クライアントを含む、社外でも共有される事があるのです。

ですので、失敗や不祥事などの一部始終、つまり顛末とともに、謝罪の内容も記載した反省文という位置付けになります。そういう点で、顛末書とは意味が違うのです。

とはいえ、顛末書と始末書では謝罪が入っているかいないか程度の違いである場合が多いため、この両者を区別なく使っている企業も。

もちろん、謝罪部分についてはミスによってトラブルを発生させたチームのリーダーや、影響が小さい場合にはミスをしてしまった本人が書きます。

また、始末書は責任が重大なミスを犯した時に必要となる書類です。

そのため、始末書も顛末書と同様に基本は会社の代表取締役社長あてになる事が多め。ただ、顛末書と異なり、提出時には封筒が必要となります。

報告書との違い

「顛末だったらいつも書いてるけどなぁ」と思った方もいらっしゃるかも知れません。

例えば普段から、セミナーなどへ参加したり際に内容を報告したり、社内での開発進捗などを報告書として書いている場合です。ただしこれは「顛末書」とは異なります。

普段書いている「報告書」は良い事も悪い事も含めて、事実を報告する書類という位置付けですが、顛末書は悪い事が起こった時にしか書きません。

ですので、セミナーの内容など、一部始終を「顛末」として書いたとしても、これを「顛末書」とは呼ばないのです。

また「始末書」は、何らかのペナルティが発生する場合、つまりものすごく悪いことが起こった時に書くというイメージ。

そこが「報告書」との大きな違いなのです。

顛末書の書き方のポイント

顛末書を書く際、どのような点に注意して書けば良いのでしょう。

顛末書を書くときは以下のポイントに気をつけましょう。

• 5W1Hを明確にする
• 誰が読んでもわかりやすいように心がける

5W1Hを明確にする

まず、5Ｗ1Ｈをはっきりさせることです。

5Ｗ1Ｈの5Ｗとは、以下を表しています。

• いつ（When）
• どこで（Where）
• 何が（What）
• 誰によって（Who）
• どうして（Why）

5Wを用いて、ミスやトラブルがどの様に発生したのかを書きます。そして同じ事案が二度と起こらないようどうすべきかを、1Ｈである（HOW）として書くのです。

経緯を細かく書くことはもちろん、読みやすさを考えて結論から記述しましょう。

先に結論または大まかな経緯を書き、そのあとで5Ｗ1Ｈを含めて詳細を書くのが良い顛末書のポイントです。

この5Ｗ1Ｈをベースに原因を分析し再発防止策を書くため、分析が出来る程度にまで詳細に書く必要があることを、念頭に置いてください。

顛末書に書くべき内容は以下の通りです。

• 問題が発生した日時と場所
• 当事者
• 何が起きたのか、被害や損害の規模について
• 問題が発生した原因
• 対応した内容
• 今後同じ問題を発生させないための対策
• 担当者の問題に対する意見

誰が読んでもわかりやすいように心がける

顛末書は社内で共有される文書でもありますので、誰が読んでもわかる様に書きましょう。

時々、そのチームでしか共有しないと思っているのか、チーム内でしかわからない言葉が書かれていたり、一部の経緯が省かれていたりすることがあります。

この場合、社内共有しようにも「これってどういうこと？」という疑問が湧いてしまい、何度もヒアリングを重ねる結果となってしまいます。

事情を知らない人が読んでもわかるように、簡潔かつ具体的に記述するようにしましょう。

顛末書の例文

顛末書の例文を以下の項目に分けて掲載しますので、参考にしてみてください。

• 社内用
• 社外用

【社内用】顛末書の例文

では、社内用の顛末書についての例文を挙げておきます。

【社外用】顛末書の例文

一方、社外とも共有する顛末書のフォーマットは下記の様になります。

社内用の顛末書と異なるのは、社外の関係者が絡む場合ですので、社内でしか通用しないような内容についても省かずに、しっかりと書き起こす必要があります。

もしさらに始末書にするのであれば、謝罪に関する文章を冒頭と最後に追記しましょう。

顛末書に書くべき内容チェックリスト

顛末書には以下の項目を書き漏らさないように注意しましょう。

• 日付：書類を作成した日付です。
• 宛名：社長宛てに書くことが多いです。
• 作成者名：顛末書を書く人の名前です。
• 顛末書：「顛末書」という記載が必要。左右の中央に書きます。
• 概要：いつ発生したどのようなトラブルの顛末書なのかを記載します。しっかりと詳細まで書くようにしましょう。
• 記：本題に入る前に「記」と書く場合があります。フォーマットによっては不要なこともあります。
• 顛末書本文：トラブルの概要、対応、対策などを記載します。５Ｗ１Ｈがしっかりわかるようにしましょう。
• 以上：最後は「以上」でまとめます。

上記の内容を書くことで、同じフォーマットで顛末の情報を全社共有できます。

顛末書を提出する際の注意点

顛末書を提出する際の注意点は、以下の3つです。

• 事態が収束したら速やかに提出する
• 手書きでいいのか問題について
• 今後の取り組みに活かすことが重要

それぞれ解説します。

事態が収束したら速やかに提出する

顛末書はトラブルが収束したらできるだけ早く提出します。顛末の意味の通り、初めから終わりまでがわからなければならないので、対応途中で出すことはありません。

ただし、問題が発生した旨はすぐに報告する必要があることは覚えておきましょう。

手書きでいいのか問題について

顛末書の書き方は会社のフォーマットに沿って書きます。手書きか、パソコンで作成するかは基本的には社内規定に従いましょう。

もしも、指定がない場合にはどちらにするべきか悩む場合もあるでしょう。

手書きは人間味が感じられるので、謝罪や反省の気持ちが伝えやすいことがメリット。

ただし、顛末書はトラブルの内容の報告や今後の対策について簡潔にわかりやすく述べる必要があります。その観点から考えると、見やすく修正が行いやすいパソコンの方が適しています。

迷った場合には、素直に上司にどちらがよいのか相談するとよいでしょう。

今後の取り組みに活かすことが重要

顛末書は提出して終わりではなく、これからの再発防止や改善に活かすことが重要。

また、「きちんと対策が行われているか「状況は改善されているか」といったデータを取得し、経過を報告すると顛末書としての精度も高まります。

顛末書を書く機会を減らす5つの再発防止策

顛末書を書く機会を減らすなら、以下の5つの対策を行いましょう。

• 確認する習慣をつける
• 作業を分担する
• 休みを取って調子を整える
• スキルに磨きをかける
• 仕事や職場が合っていないのなら転職を考える

不当に顛末書を書かされていると感じるのであれば、こちらの「クビ（懲戒解雇）になる場合でも顛末書を書かなければならないのか」も参照してください。

確認する習慣をつける

まずは何かを行った場合にはしっかりと確認するようにしましょう。できていない、もしくは以前はやっていたのに、最近はできていなかった場合には、再度習慣づけることが重要です。

具体例を挙げると、もしあなたがエンジニアであるならば、必ずコードレビューを受けるようにしましょう。

上司や同僚にお願いし、ダブルチェックをすればミスの発生確率を抑えられるはずです。

その際、GitHubを使ってソースコードを共有化し、コードレビューがしやすい体制を作るのも一つの手です。

また、デバック作業も必ず細かく行います。これはテストもそうなのですが、できる限り考え得るテスト項目を洗い出し、リスト化すると良いでしょう。

このチェックリストもダブルチェックすれば、漏れ抜けを防げます。

作業を分担する

2つ目の対応は、一人で多くの作業を抱え込まないことです。

仕事を抱え込みすぎると、そんなつもりはなくても、どうしても一つ一つの作業が雑になってしまう可能性がでてきます。

当然、期日までにたくさんの仕事を一人で処理しようと思うと雑になってしまうところは出てしまいますし、その結果ミスが増えることになります。

特にエンジニアは単独で作業を行うことが多い上、優秀な人ほど多くの仕事が割り当てられる傾向にあります。一人で大量のコードを書くなど、仕事量が増えやすいです。

これは結果として、会社にとっても本人にとっても良いことではありません。ですから同じチームや部署の人たちと作業を分担して、抱え込みすぎないようにしましょう。

プロジェクトというのは、会社という組織として行っているわけです。

本来ならば、組織としてどういう体制でプロジェクトの目的を達成するのか、という点をしっかりと考え、体制を整える必要があります。

ですので、このような場合、自分からチームメンバーの、マネジメントを担当している上司に相談し、仕事の割り振りを見直してもらうようにしてもらうと良いでしょう。

休みを取って調子を整える

3つ目の対応は、調子を整えることです。

常に仕事に追われていることによって、肉体的にも精神的にも疲れていませんか？疲れは集中力を低下させ、ミスを誘発する原因となります。

もし日常業務の疲労から、仕事のミスが増えている可能性があるのであれば、一度しっかりと休みをとって、心身ともにリフレッシュするようにしましょう。

仕事が忙しいと、スケジュールとにらめっこした結果、なかなか休めないと考えがち。

しかし実際には、パフォーマンスが落ちた状態で仕事を続けるよりも、1〜2日休んでリフレッシュした方が集中力も上がります。

わずかな遅れならば、すぐには取り戻せてしまうもの。調子を整えるのも仕事のうちですので、上司に相談したうえで、休めるときには休むようにしましょう。

スキルに磨きをかける

4つ目の対応は、自身のスキルアップによって仕事の処理速度を上げ、デバッグなどに割くことのできる時間を増やすという方法です。

それ以外にも、スキル不足が原因によるミスが増え、顛末書を書く機会が増えている可能性もあります。

特にエンジニアの場合、技術は日々進化しているため、自分の持っているプログラミングスキルがいつまでも通用するとは限りません。

そのため、新しいシステムを開発する際に、技術の進化に対応するための時間がかかってしまい、開発速度がどうしても落ちてしまう事も起こりえます。

ですので、技術の進化に対応するための時間を常に確保したり、もし通常の業務時間内での確保が難しい場合は、改めてスキルを磨くためにスクールに通うのも一つの方法です。

いずれにせよ、何らかの形でプログラミングスキルが上がれば、時間に余裕を持つ事ができますので、ミスを防ぎ、顛末書や始末書を書く事態を避けられるかもしれません。

仕事や職場が合っていないのなら転職を考える

根本的な問題として、今の仕事や職場環境が自分に合っていない場合も。

例えばサーバー側の開発が得意なのに、実際の仕事はフロント側の開発ばかりである場合、保有しているスキルと与えられている仕事の内容がマッチしていません。

その場合、どうしても不慣れによるミスが増えやすいです。

仕事の内容を変える、それこそ転職によって職場を変えるなどの手を打ち、自分に合った仕事に就くことで、ミスが減らせるかもしれません。

ただし、本当に仕事や職場が自分のスキルと合っていないのかについては、慎重に判断する必要があるでしょう。

顛末書を書くエンジニアに多い失敗例

エンジニアが顛末書や始末書を書く原因となる失敗例には、どのようなものがあるのか。

本章では、エンジニアにありがちな失敗例を4つ紹介します。

• コードのミスに気がつかず、サービスのリリース後に修正
• 上司への報連相をせずに作業を進めた結果エラーが発生
• 製作物のデバッグをしなかったことでエラーが発生
• コードの修正をしたが、実機で確認しなかった結果バグが発生

コードのミスに気がつかず、サービスのリリース後に修正

最初の事例として、ソースコードのミスに気がつかないまま、サービスをリリースしてしまった場合があります。

これは、テストを行う際のチェック項目の洗い出しが上手く行っていなかった場合や、設計書を読む時に勘違いをしてしまった場合などに多いです。

この場合、リリース後に想定と動作が異なるなどのエラーが発生することになります。

もちろん想定と異なる動作をするわけですから、そのシステムを使用しているユーザーからのクレームが次から次へと発生するかもしれません。

少しのエラーであれば動かしたまま修正することも可能ですし、場合によっては一時的にサービスを止める必要が出たにしても、短時間で修正、再リリースできる場合もあるでしょう。

しかし、過去には銀行のATMが長期間使えなくなったなどの長期に渡るサービス停止が発生した事例などもあり、この場合は大損失を出すと同時に、信用も大きく毀損してしまいました。

上司への報連相をせずに作業を進めた結果エラーが発生

2つ目としては、ついつい報連相を怠ってしまうことで起こってしまう場合です。

特にエンジニアの作業は一人で行うことが多いので、本来であれば適度なタイミングで行うべき報連相を怠ってしまうことがあります。

怠らないまでも、「もうちょっとまとめてからでも良いか」と後回しにしてしまったことで、報告のタイミングを逃してしまい、発生することがあります。

このように報連相を怠って自分一人で作業を進め、エラーが発生させてしまうと、上司や顧客からひどく叱られてしまうでしょう。

作業に詰まった時に報連相が重要であるのは、このような理由からです。

製作物のデバッグをしなかったことでエラーが発生

3つ目はデバッグ不足によるものです。

もちろん全くデバッグをしないということはないでしょう。

しかし、クライアントから制作依頼をされてサービスを作ったものの、マルチタスクで忙しく、デバッグが甘くてエラーが多かった例などが挙げられます。

当然ながら納品後にエラーが発生し、クライアントからのクレームが入った場合、クレームへの対応次第でその後の展開は変わるでしょう。

誠意を持って対応しなければ、結果的にクライアントの信用は当然下がります。すると次回以降、仕事の依頼が来なくなるリスクも。

コードの修正をしたが、実機で確認しなかった結果バグが発生

4つ目は、実機や本番環境でのチェックを怠ったためにバグが発生してしまった例です。

リリース前にテストをしていると、当然の事ながら、事前にコードのミスに気がつき修正することがあるでしょう。

これは大変重要ですし、この対応自体は誉められるべきものです。しかし実機ではその修正部分の動作を確認せず、ソースコード上でのみ確認したとしたらどうでしょう。

特にデータベースに拡張などの修正を入れてしまった場合は、ソースコードの修正アップロードだけでは済みません。やはり実機での確認は重要なのです。

また、修正したはずが、システムの実装後にエラーが複数箇所で発生してしまったということもあります。

この場合、設計書での事前検討をしっかりしていれば良いのですが、それを怠った場合、1カ所コードを書き直したことで、別の箇所に新たなエラーの原因が発生してしまうこともあります。

もしもに備えて顛末書の書き方をおさえておこう

顛末書の書き方、始末書・報告書との違い、再発防止策や失敗例などを紹介しました。

人間誰しも、大なり小なり仕事でのミスはつきもの。もし顛末書の提出を求められた場合は、本記事で紹介した例文や書き方のポイントを参考に、速やかに記入し提出してください。

また顛末書を書いた後は、同じミスをしないための再発防止策も重要。「失敗は成功の元」とポジティブに捉えて、次に活かしましょう。

↑目次へ戻る