ここから本文です

誠意を見せつつ相手に納得してもらう「謝罪報告書」の書き方

6/2(金) 6:10配信

@IT

 連載「エンジニアのためのビジネス文書作成術」、第1回は「議事録」の書き方を、第2回は「要件定義書」の書き方を、第3回は「提案依頼書(RFP)」の書き方を学びました。第4回は「謝罪報告書」をWordで作ります。

【「原因」「真因」「再発防止」を整理した例】

 謝罪報告書とは「やってはいけないミスをやってしまったときに提出する」大人の反省文です。できれば一生無縁でありたいものですが、バグとオペレーションミスに溢れるIT業界では避けては通れない文書です。

 謝罪には「真摯な態度」が求められます。

 謝罪内容が不十分だと相手とのネガティブな関係を後々まで引きずります。しかし誠実さが正しく伝われば、おとがめは小範囲で済むものです。

 これはIT業界に限った話ではありません。

 やってしまったことは取り消せません。重要なのは「これからの状況」をどのように改善するかです。真摯な対応を伴う謝罪は、これまでに築き上げた「信用」を土台にして、これからの状況を「建設的」に相談することを可能にします。

 次項から、「真摯な対応」と相手に感じてもらえる謝罪報告のアプローチと、謝罪報告書の内容を見ていきましょう。

●報告は速やかに

 謝罪報告書の内容がどんなに優れていても、ミス発生時の初動対応が悪ければ、相手の心証を悪くします。

 次のケースを考えてみましょう。

---
Xさんの会社はクライアントからヘルプデスク業務を受諾しています。Xさんはその業務チームのリーダーです。

ある日、外部から添付ファイル付きの不審メールが送られてきて、チームメンバーのAさんが誤ってファイルを開いてしまいました。

AさんはXさんへ速やかに報告しましたが、Xさんがそのことをクライアントの担当者へ伝えたのは、Aさんの報告から半日たってからでした。
---

 もしあなたがクライアントの担当者なら、Xさんに対してどんな印象を持つでしょう。少なくとも、「もっと早く報告に来るべきではないか!」と思うのではないでしょうか。

 では、Xさんに事情があったならどうでしょうか。

---
クライアントの担当者に電話をしたが、連絡がつかなかった。業務が立て込んでいたので、いったん業務に戻り、担当者を見かけたタイミングですぐに声を掛けた。
---

 多くの人は、「だったら別のクライアント社員に報告して指示を仰げよ!」と思ったはずです。事情はどうあれ、Xさんのところで情報が止まってしまったという事実は、報告を受ける側の不信や不満を助長します。

 ミスをしたら、できるだけ早く上級担当者へエスカレーションすることが重要です。

●「事象」と「経緯」を説明する

 素早く報告しても、要領を得ない内容では相手の怒りは収まりません。報告の分からなさに対する不満で、むしろ相手の怒りは激しく燃え上がります。

 こうした事象を招かぬため、まずは相手に冷静な判断をしてもらいましょう。そのために必要なのは、「事象」と「経緯」の説明です。事象は「ミスそのもの」、経緯は「ミス発生の前後における状況の説明」です。

 「図1」のように「表形式」「時系列」で内容を整理するとよいでしょう。

 文章を分かりやすくするテクニックとして有名なのは「5W1H(When/Where/Who/Why/How)(いつ/どこで/誰が/何を/どうして/どうやった)」で示す方法です。しかし謝罪報告書の場合は、事象と経緯に「Why」を含めてはいけません。

 ここで「ミスを犯した理由」を書くと、相手には言い訳がましく聞こえます。それが正当な弁明であってもです。

When 関東地区池袋営業店からの緊急問い合わせ対応中に
Where 自席で
Who 弊社要員Aが
What 新宿営業店の担当者が差出人の「【大至急】エンドユーザークレーム対応」という文言が含まれたメールを
How 開封して添付ファイルを開いた

 もし上記説明に次の「Why」が並んでいたら、どう感じるでしょうか。

日常的に不特定多数の営業員からメールを受信していたから、勘違いした
「至急対応」を促すメールが日常的に来ており、速やかな対応が求められる場面が多かった
他の営業店から複数の問い合わせを受けており、メール内容を吟味する余裕がなかった

 どう見ても「言い訳がましい」ですよね。これらは正しい理由かもしれませんが、謝罪内容の経緯説明で出すべきものではありません。

 謝罪報告では、起きたこと「だけ」を淡々と述べ、相手に事実を「理解」してもらうことが先です。それがあって初めて、冷静に弁明を聞いてもらえる環境が整います。

●「原因」「再発防止策」は「ルートコーズ分析」で整理する

 ミスには、引き起こした「直接原因」とは別に、その原因を招くに至った「真因」というものが存在します。

 先述のミス「ケーキの発注数を1桁間違えた」の直接原因は、「桁入力を間違えた」です。しかしその背景には、「発注数をチェックする人がいなかった」という事情があります。

 その場合、同じミスを繰り返さないために、「今後は必ず2人以上で発注数をチェックするという仕組みを設ける」必要があるでしょう。「誤発注した人は日ごろから業務ミスが多かった」のならば、「発注作業は別の人に担当させる」と良いかもしれません。

 目に見える原因だけでは、適切な「再発防止策」を示すことは難しいでしょう。ミス発生を防ぐための「原因分析」は少なくとも二段構えで整理すべきです。

 このアプローチは「ルートコーズ分析(真因分析)」と呼ばれる、「根本原因」を突き止めるオーソドックスな手段です。

 「図2」のように、表面上の「原因」、その裏に潜む「真因」、真因に対する「再発防止策」を整理すると、「二度と同じ過ちを繰り返さない」という「強い反省」を相手に示せます。

●「謝る」のは文書の冒頭

 謝罪報告書のコアコンテンツは「事象、経緯」と「原因、再発防止策」です。しかし、これだけではぶっきらぼうな印象を謝罪相手に与えます。

 最初に述べた「真摯な態度」は、謝罪の成功率を高める最大のポイントです。謝罪報告書の「冒頭」に、真摯な態度を「文章」で示しましょう。

 今までのポイントをまとめた謝罪文全文のサンプルを載せます。下の画像をクリックするとダウンロードできます。

 この文書に含まれるスタイルは、前回までに取り上げた設定方法に加えて、新たに「表スタイル」を用いています。

 標準的な表スタイルは見栄えが悪いため、外枠線を無くし、表内の仕切り線を灰色かつ点線にし、表の中身に注意が集まるようにアレンジしました。また、同じ内容が当てはまるセルを結合させて、セルの範囲から意味が読み取れるようにしました。「図4」は設定方法です。

●Wordから逃げるのではなく、Wordの良さを見つけよう

 連載第1回から4回まで、エンジニアが苦手とするWordを使って文章を作成する場面を取り上げました。これまでWordと悪戦苦闘してきた方も、存在自体から目を背けてきた方も、Wordの活用余地に気付いてもらえたのではないかと思います。

 システム開発に携わる方は要件定義書と提案依頼書の作り方を、それ以外の人も議事録と謝罪報告書の作り方を参考に、是非ビジネス文書作成にチャレンジしてください。

 連載「エンジニアのためのビジネス文書作成術」、今後はPowerPointやExcelでの文書作成法もお伝えします。お楽しみに!

●書籍
外資系コンサルのビジネス文書作成術
吉澤準特著 東洋経済新報社 1944円(税込み)
大手コンサルティングファームでドキュメンテーションスキルを指導する著者が、ロジックの組み立てと効果的な表現をWord上で思い通りに実現するテクニックを解説する。
※書籍では本記事の内容を図解しています。是非ご覧ください。

※連載「エンジニアのためのビジネス文書作成術」は、書籍「外資系コンサルのビジネス文書作成術」(吉澤準特著 東洋経済新報社)を基に、出版社の許可を得て、筆者自身が@IT読者向けに再構成したものです。画像はWindows 7 + Word 2013上のものです。機能はWord 2013、2016のいずれでも使用できます

○筆者
吉澤準特
ITコンサルタント
外資系コンサルティングファーム勤務。ビジネスからシステムまで幅広くコンサルティングを行う。専門分野はシステム運用改善をはじめとするインフラ領域だが、クライアントとの折衝経験も多く、ファシリテーションやコーチングにも造詣が深い。
著書『資料作成の基本』『フレームワーク使いこなしブック』(以上、日本能率協会マネジメントセンター)『外資系コンサルの仕事を片づける技術』(ダイヤモンド社)など。

最終更新:6/2(金) 6:10
@IT