この記事は、Feedforce Group Advent Calendar 2023の1日目です。初日から縁起でもない題材を選んでしまった感はありますが、どうかお付き合いください。
フィードフォースでは、サービス運営上のトラブルがあったときに、「障害レポート」と題して報告書を作成します。きっと他社でもインシデントレポートとか事故報告書とか、名前を変えて同じような取り組みがあるかと思いますが、今日はその障害レポートを作成する上で、わたしが気をつけていることをご紹介します。
この記事で特に伝えたいポイントは、次の3つです。
- 読者の視点で情報を再構成する
- パラグラフ・ライティングで書く
- 事実と意見を書き分ける
障害レポートの目的
フィードフォースにおける障害レポートの作成と活用の目的は、障害に関する情報を整理し、正しい意思決定をすることです。障害レポートの作成が始められるのは、障害発生を把握したあと、まだ対策や応急処置も行わないうちであることが多いです。事態の収拾を待っていたのでは、レポートにまとめるべき情報が散逸してしまったり、時系列に関する情報を追いきれなくなったりして、記録が困難になってしまいます。そのため、状況に進展があったらその都度障害レポートを更新するようにしています。
障害レポートがまとまった文書として存在することを目的とするのではなく、リアルタイム性をもって更新されていくものとすることで、状況に応じて次の打ち手を考える材料を関係者に提供する役割を果たしています。
ちなみにフィードフォースでは、障害レポートのテンプレートとして、こんな章立てのものが用意されています。事態の起き始めには「影響範囲」や「タイムライン」から更新され、状況がある程度見えてくると「概要」「原因」が更新される、というように書き換えていきます。
* 概要 * 対応記録 * 原因 * 影響範囲 * タイムライン * 解決方法 * 今後の対策
読者の視点で情報を再構成する
障害レポートの目的は、インシデントの関係者に整理された情報を提供し、正しい意思決定を導く材料を提供することでした。というわけで、まずはレポートに記載される情報が整理されていることが重要になります。
情報を整理して伝えるための文章にはいくつか型がありますが、わたしはよく「事件記事の文体で書くとよい」というアドバイスをしてきました。事件記事の初めの一文はだいたい、「いつ、どこで、何が起き、その結果どうなったか」という作りになっています。続いて発生時の状況に触れ、原因と思われる事柄も述べることが多いです。
この文体は、新聞読者に簡潔に情報を伝えるために磨かれてきたフォーマットです。障害レポートも「インシデントのあらましを伝える」という点においては事件記事と通じるので、これを利用しない手はありません。さて、「フォーマットに落とし込めばいいんだな」ということで、あなたが時系列で集めた情報を眺めると、重要度やスケールの点でさまざまであることに気づくと思います。一つの文でインシデントの全体像をまとめるには、集めた情報の多くを切り捨てなければなりません。
この、事件記事の文体に合わせるための情報の取捨選択こそが「読者視点での情報の再構成」です。
ここで、読者についても考えてみる必要があります。障害レポートを書くわれわれは、大抵組織の中で働いていますから、障害レポートの内容は組織の上や外のレイヤーにも伝わっていきます。上層や外部の人たちが、障害を知ったうえで何に関心を持つかを考えてみると、民間企業においてはやはりお金、まずは直接的な被害額、というところになるのではないでしょうか。
したがって、先に述べた事件記事の文体における、「その結果どうなったか」には、お金、もしくはそれに連なるパラメータ（影響が及んだユーザー・リクエストの数、スケジュールが飛んだバッチの数、データが消えた商品の数 etc.）の変化を置くといいんじゃないかと思います。「その結果どうなったか」が決まれば、集めた情報の中から影響があるものを選んで「いつ、どこで、何が起き」たかを当てはめていくことができます。
パラグラフ・ライティングで書く
障害レポートには、パラグラフ・ライティングのテクニックが役立ちます。パラグラフ・ライティングは、「主張や論理展開をわかりやすく伝えるのに有利」という特徴があります。障害レポートは、インシデントの状況を観察し原因を記載する、事実を述べる側面のほか、そこから導かれる再発防止策という、事実の評価と主張を述べる側面もあります。パラグラフ・ライティングは、後者の目的において特に力を発揮するように思います。
パラグラフ・ライティングは、読み手にとってもメリットを生みます。パラグラフ・ライティングで書かれた文書は、拾い読みでも構造が伝わるようになっています。というのも、パラグラフ・ライティングの基本単位であるパラグラフは、主題を簡潔に述べる要約文と、主題を補強する補足説明で構成されています。パラグラフどうしのつながりも、まず初めに文書全体の主張と展開を要約するパラグラフが置かれ、続くパラグラフで詳細な議論を展開する、というふうに構成されるので、各パラグラフの先頭を読んでいけば、文書の主張が読み取れるようになっているのです。
先に「インシデントの関係者に整理された情報を提供し、正しい意思決定を導く材料を提供する」ために、事件記事の文体を活用する考え方を紹介しましたが、これは一つひとつの文におけるテクニックでした。パラグラフ・ライティングは、文章全体の構成で情報を整理するテクニックと言えるでしょう。
パラグラフ・ライティングについては、 倉島保美「論理が伝わる 世界標準の『書く技術』」 がおおいに参考になります。
事実と意見を書き分ける
さて、障害レポートには、事実の評価と主張を述べる側面もある、と述べましたが、ここにも大事なポイントがあります。それが「事実と意見を書き分ける」です。
事実と意見の書き分けは、論理的に主張を伝えるうえで重要だと思っています。ふつう、報告書を通じて主張するような内容は、いくつかの事実を並べて、それぞれについての価値判断や、事象同士の関係を評価したうえで導かれます。事実と意見の書き分けがあいまいだと、読者に「見てきたように言うけど本当か？」という疑念を抱かせ、主張の根拠が揺らいでしまいます。
何が事実で何が意見かの見分けは難しいものの、一定の指針は見いだせるように思います。例えばこんな感じです。
- 事実: 定量的な観察結果や、他の文献を参照するなどで裏付けが取れるもの
- 意見: 推論や価値判断、およびそれらを元にした考え
ちょっとここは具体的な例を出して説明します。数年前にレビューした障害レポートの中に、こういう文章がありました。あるサービスのディレクターが、うっかりAmazon S3の設定を変えてしまい、自動で消えるはずのオブジェクトが消えなくなってお金が余分にかかってしまった、という事例での話です。
本件事象（筆者注：誤操作によるS3の設定変更）のきっかけは、ディレクターに本来の業務以上の権限を与えていたことだった。 全ての S3 のバケットのプロパティやパーミッションを操作できる強力な権限ではなく、業務で必要な操作のみに絞る必要があった。
「ディレクターに本来の業務以上の権限を与えていた」のは事実ですが、後段の「業務で必要な操作のみに絞る必要があった」というのは、再発防止策であり、主張です。主張なので、「事実を踏まえてこう考えました」という根拠を示すことができれば、より説得力が増します。このレビューでは、主張の根拠を添えた方がいい、と指摘をした上で、根拠の一つとして「一般的に、誤操作を人間の注意力に頼って防ぐのは限界がある」を挙げ、そこに「誤操作が発生したとしても、それが受け入れられなければいい」という見解を付け加えて、「権限を絞った方がいい」という主張に繋がるようにしました。
障害レポートの書き手は、すでに原因と対策の間のコンテキストを持ってレポートを書き始めていることがほとんどです。レポートの書き手は障害対応にあたるメンバーが兼ねることも多く、現状分析・問題・提言または主張などを経験から導くものとして持っていますし、障害対応で綿密なコミュニケーションを取るうちに、事実と対策の関係が当然のように思われてくるのも仕方ないところはあります。
しかし、障害レポートとして記録する際には、そのようなコンテキストを共有しない人にも読まれることを意識しておくと、事実と意見の区別がしやすくなるかもしれません。事実と意見の区別は、 木下是雄「理科系の作文技術」 に学びました。この本は、技術文書を書くためのテクニックがまとまっていて、学生でなくなってしばらく時間が経っても役立ちます。
おわりに
以上、障害レポートを書くときに気をつけているポイントを、3つに絞ってお伝えしました。他にもいろいろ意識しているポイントはあるのですが、「名詞の取り扱いを一貫させる」とか「時制を一致させる」とかは、 日本語スタイルガイド（第3版） に学びました。この本も、初歩的な文法から文書構成まで網羅的にまとまっているので、手元にあると心強いです。
長々と書いてきましたが、これから年末年始、ホリデーシーズンに向かってまいります。こんな季節に障害レポートなんて書かない方がいいに決まってます。この記事が皆様のお役に立たないことを、師走の空に願ってやみません。
明日は人事の nekoyanagi が、フィードフォースグループ青山オフィスへのおすすめルートを紹介してくださるそうです。お楽しみに！
