「きちんと感」のあるトラブル報告書の書き方

30代OLを読者層とする女性向けファッション誌に、「きちんと感」という言葉がよく出てくる。ヒラヒラフリフリがいっぱい付いたエビちゃん風の服ではなく、かちっとしたスーツと白いブラウスにタイトスカートといった、ビジネスシーンにふさわしい「きちんと」した服装のことらしい。

社外向け文書も、「きちんと感」をしっかり出したいものひとつだ。しかし、最近見かける社外文書は、「これで大丈夫か？」と首をかしげるものが結構あってビックリする。

私が社会人になったときは、世の中にまだまだ余裕があったので、約3ヶ月の研修期間が設けられていた。最初の2週間が導入教育で、ビジネスマンとしての基本をたたき込まれる。名刺の受け渡し方、電話の取り方、そしてビジネスライティングだ。最近はこんなに悠長なことをいってられないので、入社してすぐ現場に配属され、OJT中心で育てられていると聞く。怪しげな社外文書を見かけるようになったのは、こういった研修環境の変化が影響しているのだろうか。

特にトラブル報告書は、「きちんと感」がきわめて重要だ。ただでさえ頭に来ているお客様に出す文書だ。火に油を注がないように細心の注意を払う必要がある。

「きちんと感」のある報告書にはポイントがいくつかある。どれもごく当たり前のことなのだが、それが当たり前でなくなっている世の中だから、ここに書いておく価値が十分あるだろう。

（1）フォントは明朝体

Don McMillanのプレゼン（持ちネタ）で出てきたように、数多くのフォントの中からどれを選ぶかは、その人の性格や人となりを表す。トラブル報告書の場合は、絶対に明朝体を使うべきだ。まかり間違っても丸ゴシックなど使ってはいけない。ビジネス文書ではゴシック体が一般的だが、「きちんと感」を出すには明朝体が最適である。私はWindowsで社外文書を作るので、MS P明朝を使うようにしている。

英文フォントは日本語と同じフォントにしておく。Times New Romanなどの英文フォントを選ぶと、英数字の部分が浮き上がって見えて、見た目の統一感を欠く。

（2）「拝啓・敬具」より「謹啓・謹白」

社外文書というと、判で押したように「拝啓・敬具」を使う人が多い。トラブル報告書は、会議を開催しますとか新しい製品が出ましたとかいう連絡文書と一緒にしてはいけない。かしこまった雰囲気、すなわち「きちんと感」を出すために、トラブル報告書では「謹啓・謹白」を使った方がよい。

「冒頭の挨拶文なんか誰も読んでないよ」という人もいるだろう。それは正しい。しかし、そういったところに気を配るかどうかが、「きちんと感」を出せるかどうか、きちんとしたビジネスマンと見られるかどうかの分かれ目だ。

（3）とにかくしっかり謝る

このまえレビューした報告書は、こんな書き出しで始まっていた。

拝啓 貴社ますますご清栄のこととお慶び申し上げます。平素は格別のご高配を賜り、厚く御礼申し上げます。表記の件につき、下記の通りご報告申し上げます。ご査収の程、よろしくお願い申し上げます。

これでトラブル報告書といえるだろうか。トラブル報告書は単なる事実の報告書ではない。自社の製品やサービスの問題なのか他社に非があるのかがはっきりしていない段階で出す報告書でも、「このたびの○○の障害について、貴社に多大なるご迷惑をおかけしておりますこと、心からお詫び申し上げます」とまずはしっかりと謝るべきだ。

謝ることは自分の非を認めることと思いがちだが、迷惑をかけていることについては頭を下げる必要がある。そうでなければ、その先の話を読んでもらえないかもしれない。ここはアメリカではないので、謝ることでその後の話が不利になるとは考えなくてよいだろう（少なくとも今のところは）。

（4）誤字・脱字・変換ミスは厳禁

こんなことは改めて書くまでもないのだが、実際に誤字・脱字・変換ミスだらけのドラフトが回ってくるのだから、書いておく必要がある。先日レビューした報告書は、いきなり「背景 貴社ますますご清栄のこととお慶び申し上げます」で始まっていて、開いた口がふさがらなかった。

ひととおり書いたら、しばらく時間をおいて何度も読み返そう。時間をおくことで、第三者の視点で客観的にレビューできる。他の人が見つけてくれるなどと期待しないこと。ドラフトのレビューは、内容や構成をチェックするもので、誤字・脱字・変換ミスはそれまでに撲滅しておくべきだ。ちょうど、単体テストとシステムテストの関係に似ている。

Wordのスペルチェックや校正機能も活用し、波線が付いているところは目をこらしてじっくり見ること。思わぬ間違いをしているはずだ。

（5）宛名には「殿」ではなく「御中」「様」を使う

文書の左上の宛名書きで、「○○社 △△事業部 殿」のように「殿」を使っている例が多い。実は、私が受けた導入教育でも「殿」を使うように指導された。しかし、いまなら「御中」や「様」を使うべきだ。広辞苑を見ると、こんなことが書いてある。

他人の氏名・官名の下に添えて敬意を表す語。「様」よりも敬意が軽く、また現在ではより公的な用語。

トラブル報告書に敬意の軽い言葉を使ってはまずい。会社名には「御中」だ。個人名宛で発信するのであれば「様」がよい。会社名に「様」を付けた例も見かけるが、書き言葉にはふさわしくない。話し言葉だけにとどめておくのが無難だ。

（6）レターヘッドの自社ロゴは右上に配置

自社ロゴ付きの用紙やテンプレートを使うことがある。それ自体は問題ないが、ロゴの場所は用紙の右上でなければまずい。

左上にロゴを置いたテンプレートを社外文書で使うと、相手の名前の上に自社ロゴが乗っかることになる。トラブル報告書に限らず、これは実に失礼だ。どんな場合でも、相手の頭の上に乗ってはいけない。

（7）構成は「概要」「調査状況／原因」「対策」の3本立て

まず「概要」でトラブル内容を簡単にまとめ、「調査状況」でこれまでわかっていることを説明する。原因が判明しているのであれば、それを説明する。そして最後に「対策」を書く。この構成がトラブル報告書の原則で、状況に応じて必要な情報を追加する。

あまり情報を詰め込みすぎると、かえってわかりにくく訳のわからない文書になってしまう。報告書本文はできるだけ簡潔にまとめ、詳細情報をどんどん添付資料に追い出すとよい。時系列の詳細な対応履歴や、障害に至ったロジック、対策のための操作手順などは当然添付資料行きだ。目安としては、本文はA4で1枚から2枚に抑える。添付資料は、必要なら10枚以上付けても構わない。

報告書は、渡した相手だけが読むものではない。報告の場に出ていなかった人にも回覧される。一般的にいって、管理職や幹部社員は本文だけ読んで状況を判断するから、そこだけを読んでもトラブルの経緯や対策がよくわかるようにしておきたい。添付資料は、主にシステム部門の担当者など現場の人向けだ。