テックキャンプ無料カウンセリング テックキャンプ無料カウンセリング
資料請求はこちら

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

更新: 2021.07.27

>>No1エンジニア養成プログラム テックキャンプ

プログラミングを仕事にして収入を上げる方法

「顛末書を書くよう言われたけど、何を書けばいいかわからない」
「始末書とは何が違うのか」

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

そして「顛末書を書くようなミスは二度と起こしたくない」と思うのは社会人として当たり前の気持ちだと思います。

本記事では顛末書の書き方や例文、始末書との違いについて解説します。

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

顛末書を書かなければいけないことになった場合、どの様なことに注意して書けば良いのでしょう。

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

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

5W1Hを明確にする

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

5W1Hの5Wとは、

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

を表し、ミスやトラブルがどの様に発生したのかを書きます。

そして同じような事が二度と起こらないようどうするのかを、1Hである(HOW)として書くのです。

重要なのは経緯が細かく書かれていることですが、読みやすさを考えて結論から記述しましょう。

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

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

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

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

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

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

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

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

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

10年後も食べていける職業

エンジニアは、今もっとも注目を集めている職業の1つ。市場価値の高いエンジニアにキャリアチェンジできれば、あなたの人生の選択肢は飛躍的に増えることでしょう。 3,200名以上のIT転職を支援したテックキャンプが、未経験からエンジニアになる方法を解説! 資料はこちらから無料ダウンロードが可能。※2016年9月1日〜2021年5月14日の累計実績。

顛末書の例文

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

  • 社内用
  • 社外用

【社内用】顛末書の例文

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

平成〇〇年×月△日

〇〇部長殿
〇〇部××課 〇〇〇〇 印

〇〇のエラー発生顛末書

平成〇〇年×月□日、株式会社〇〇様へ納品いたしました〇〇というWebサービスについてソースコードの誤入力があり、リリース後にユーザーがサービスをご利用できなくなる事態が発生しました。
今回のミスについて原因および再発防止のための対策を下記に記載いたします。

1.原因
平成〇〇年×月△日、弊社システムエンジニアの〇〇〇〇がソースコードを入力していた際、誤入力に気づかずに納品。
ミス発生の原因は、納品前のソースコードの確認とデバッグの不足によるものです。

2. 発見の経緯
株式会社〇〇〇〇当てに、〇〇のサービスを利用しようとしたユーザーよりクレームがありました。
その後、株式会社〇〇〇〇の担当者△△△△様より弊社にご連絡をいただきました。

3.損害
エラー修正にかかった1日分の〇〇の想定売り上げ〇〇万円となります。

4.今後の対策
・ソースコードの確認は2人以上で行う
・製品の完成後はデバッグを必須とする。修正を加えたときもデバッグを必ず行う。

この度は、確認不足によってこのような事態を引き起こしてしまいました。
今後二度と同様の事態が起きぬよう、担当者始め、部署全体で体制を見直します。
以上

【社外用】顛末書の例文

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

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

平成○○年△月×日
株式会社〇〇
〇〇部長 〇〇〇〇殿
〇〇部××課〇〇〇〇

顛末書

この度弊社が納品いたしました〇〇というサービスにつきまして、コードの誤入力によるエラーが発生してしまいましたこと、深くお詫び申し上げます。
今回の件につきまして、エラーが発生してしまった原因が判明いたしましたので、ご報告申し上げます。

1. 平成〇〇年△月□日、弊社システムエンジニアの××がサイトのフロントエンドの開発を行っていました。〇〇が他業務に追われる中で、入力したコードの確認を怠っていました。

2. 平成〇〇年△月○日、〇〇のサービスのデバッグを行ったところエラーを確認。××が修正を行いました。
しかし、この修正の結果、別の部分のコードにエラーが発生していた模様です。コード修正後の確認をせず、納品を行いました。

3. 納品後、サービスは問題なく起動。しかし、ユーザー様がアクセスしようとしても、サイトが表示されないエラーが発生。貴社へユーザー様からのクレームがあったとの旨を、ご担当の△△様より弊社へご連絡いただき、事態が発覚しました。

4.××によるソースコードのエラー部分の確認を行い、約1営業日のサイト停止の後、再開しております。

今回の事態の発生原因は、確認不足にありました。
今後は、製品完成後2名以上による確認を行い、修正を行った際はデバッグ(動作確認作業)を必須で行うよう徹底いたします。
また、修正を行った際は、随時部署内のメンバーにも共有し、現在各自が対応している作業を複数名で相互に監視し合える体制をとります。
以上

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

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

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

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

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

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

顛末書を提出する際の注意点について、以下で解説します。

顛末書は事態が収束したらすぐに提出

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

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

顛末書は手書きでいいのか問題

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

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

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

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

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

顛末書は今後の取り組みに生かすことが重要

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

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

顛末書・始末書を書く機会を減らすための5つのポイント

もちろん皆さんもしっかりと確認をしながら仕事をされていることと思います。それでも、どうしてもミスや失敗が続くこともあります。

もし顛末書や始末書を書く機会を減らしたいのであれば、次の5つのポイントに注意しましょう。

不当に顛末書を書かされていると感じるのであれば、以下の記事も参照してください。

クビ(懲戒解雇)になった場合に顛末書を書く必要はあるのか、顛末書を過剰に書かせるはパワハラにならないのかなどを解説しています。

確認する習慣をつける

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

では具体的にはどの様にすれば良いのでしょう。もしあなたがエンジニアであるならば、必ずコードレビューを受ける様にしましょう。

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

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

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

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

作業を分担する

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

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

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

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

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

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

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

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

もしかしたら常に仕事に追われていることによって、肉体的にも精神的にも疲れていませんか?

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

仕事が忙しいと、スケジュールとにらめっこした結果、なかなか休めないと考えがちです。しかし実際にはパフォーマンスが落ちた状態で仕事を続けるよりも1〜2日休んでリフレッシュした方が集中力も上がります。

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

スキルに磨きをかける

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

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

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

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

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

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

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

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

例えばエンジニアとして働くにしても、サーバー側のプログラミングが得意なのに、実際の仕事はフロント側の開発ばかりである場合、保有しているスキルと与えられている仕事の内容がマッチしていないことになります。

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

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

ですので、スキルを身につけると同時に、根本的な方法として、転職を考えてみるのも一つの手です。

エンジニアに多い失敗例

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

失敗をしないためにも、良くある例を紹介したいと思います。

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

最初の事例として、ソースコードのミスに気がつかないまま、サービスをリリースしてしまった場合があります。
もちろんわざとミスをするわけではないのですが、テストを行う際のチェック項目の洗い出しが上手く行っていなかった場合や、設計書を読む時に勘違いをしてしまった場合などが挙げられます。

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

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

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

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

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

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

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

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

このように自分一人で作業を進めた結果、エラーが発生させてしまうことで、しかも報連相を行わなかったがために上司が把握してない部分のエラーだったりすると、ひどく叱られてしまう結果となります。

作業に詰まった時はもちろんですが、定期的な報連相が重要であるのはそういう理由です。

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

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

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

しかし、クライアントから制作依頼をされてサービスを作ったものの、他の作業と一緒にやっていたなどの理由で忙しく、目視でコードのミスがなさそうなところはきちんとデバッグしなかった例などが挙げられます。

当然のことながら納品後にエラーが発生し、クライアントからのクレームが入ってしまうなどした場合、どれだけしっかりとその後の対応をするのかに依って、その後の展開は変わってきます。

もしきちんと誠意を持って対応しなければ結果的にクライアントの使用を失ってしまい、次回以降、仕事の依頼が来なくなってしまう、つまりクライアントを失ってしまうことにもなりかねません。

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

最後の事例は、実機や本番環境でのチェックを怠ったためにバグが発生してしまった例です。
リリース前にテストをしていると、当然の事ながら、事前にコードのミスに気がつき修正することがあるでしょう。

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

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

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

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

顛末とは?

そもそも顛末書の「顛末」というのはどういう意味でしょうか。

まずはこの顛末という言葉の意味を理解しましょう。

顛末はある出来事の最初から最後まで

顛末という言葉で辞書を引くと、「ある出来事の最初から最後までのこと、一部始終」などと書いてあります。

顛末の読み方は「てんまつ」。「顛」の字には、「いただき」や「はじまり」といった意味があります。

「はじまり」から「すえ」まで、という漢字の意味と合わせて覚えておくと間違えづらいです。

会社では顛末書と始末書がある場合が多い

聞きなれない言葉かもしれませんが、会社では「顛末書」以外に「始末書」という書類のフォーマットが用意されている場合があります。

例えば、システム開発会社の場合は、何かシステムでトラブルが発生した際に、いつ誰が、どういった経緯でそのトラブルに気がつき、それに対してどの様な対処を行ったのか。それによってどの様にトラブルが収まったのか。

同時に、トラブルによる被害範囲や大きさはどのようなものだったのか、が、顛末として記載されるべきものです。

顛末書と始末書の違いは以下で詳しく解説します。

顛末書と始末書の違い

顛末として記載されるべき内容を聞くと、「それって始末書と同じでは?」と思う方もいるでしょう。

しかし、始末書と顛末書では大きな違いがあるのです。それを紹介していきましょう。

顛末書とは?

まずは「顛末書」についてです。

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

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

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

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

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

再発防止のためには顛末がしっかりと把握でき、どこに問題発生の原因があったのかを特定する必要があります。

そのため、顛末書は私情を挟まず、客観的に事実を書く必要があります。特定の個人を非難したり、誰か特定の個人からという偏った視点ではなく、平等になるよう、当事者以外の人間が書く事もあります。

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

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

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

誰もチェックしないままに提出されてしまいますと、内容が間違っていたとしても、顛末書という正規の書類として流れてしまうのです。ですので、必ず第三者のチェックを受けてから提出する必要があります。

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

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

始末書とは?

一方、「始末書」は社内だけではなく、社外、特にクライアントに対しても提出されることがある書類です。
これは、社内はもちろん、不祥事に社外の人間も関与していた場合、クライアントを含む、社外でも共有される事があるのです。

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

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

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

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

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

報告書との違いは?

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

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

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

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

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

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

↑目次へ戻る

何でも相談できる無料カウンセリング【テックキャンプは給付金活用で受講料最大70%オフ※1

こんな不安や疑問はありませんか?
・自分のキャリアでエンジニア転職できるか
・自分はエンジニアに向いているのか
・どうしたら効率良くプログラミングを習得できるか


カウンセリングでは、IT転職・プログラミング学習に特化したプロのカウンセラーが、中立な立場であなたの悩み解決をサポートします。満足度93%※2、累計利用者数は40,000人以上!※3

無理な勧誘は一切致しませんので、気軽にご参加ください。
※1.テックキャンプ エンジニア転職は経済産業省の第四次産業革命スキル習得講座の認定も受けており、条件を満たすことで支払った受講料の最大70%が給付金として支給されます 2.2018年10月24日〜11月16日(N=106) 3.2016年9月1日から2020年12月31日の累計実績

無料カウンセリングの詳細はこちら

この記事を書いた人

Tatsuya T. Yamada
天文学・宇宙物理学の研究を行い、一般向けの講演会や解説書も書いていた。現在は、1991年から行っている「パソコンを使った教育」を本業とし、eラーニングソフト・コンテンツを開発している。教育ビッグデータ、教育へのAI活用の専門家。日本天文学会、教育システム情報学会、宇宙作家クラブ会員。

あなたの理想のキャリアに合わせた、テックキャンプの3つのサービス

Advertisement