報告書の書き方について

　ある日、私は報告書を書いていた。

　そして私はその報告書を添削してもらったのだが、その際に面白いことが発覚した。

　その報告書は、私と取引先との打ち合わせをまとめて、取引先と仲介業者に提出するものであった。

　その報告書は取引先へ送付し、仲介業者は業務に立ち入らず、メールのＣＣに入れて報告するものである。

　私の報告書は、簡素であった。私の考え方は、この報告書を読む人間は、内容を把握しているため、詳細に書く必要がないというものであった。

　詳細な内容は別途の用紙に正式な印鑑を押して記入してあるので、詳しく知りたいなら別文書を読めというスタイルだった。

　私が添削をお願いした人物（Ａと呼ぶ）は、私の報告書を見てこう述べた。

Ａ：この報告書は何が書いてあるかわからない所がある。引用で説明されているが、この打ち合わせに至るまでの問題点が記入されていない。引用ではなく、記入すべきだ。（引用された文書も私が書いたものである）

私：私が引用した文書を読めば、詳細な理由から原因まで、問題の奥深くを知ることができる。この報告書に、その詳細さは求められていないし、報告書が嵩張ってしまう。取引先はこれらについて既に把握している。

Ａ：これは報告書であり、だれでも理解できなければならない。どうして報告を読んでいる人が、他の報告書を引っ張ってきて、理解するまで読み込む。そんな面倒なことをしなければならないのか？

私：取引先はこの文章で理解できるし、CC送付する仲介業者は、業務に興味がない。第三者が見た場合は面倒なのはそうかもしれないが……。報告書の意義である、将来的に見返しが必要になった際は、その引用を引けば、詳細かつ正確に理解が可能で問題解決に役立つだろうし良いと思うんだが。

A：報告書にはプロセスがある。原因・対応・レビューだ。君の報告書には原因が書かれていない。原因は省かれ、詳細は引用先だ。第三者は、報告書に記載された引用される報告書を見て初めて理解できる。逆に言うと、他の文書を読まなければいけない君の文書はダメだ。

私：なるほどね。なら書き直そう。

　Aの指摘は正しい。要するにAは、「報告書はそれ自身で完結すべき」であると主張していて、私の報告書は、それを満たしていないのだ。

　私はこの話はとても面白く感じた。これはプログラミングが関わることに気づいた。私はプログラミングの技術に興味があり、勉強していたからだ。

　ここで私の報告書は「オブジェクト指向」の体系が適用されていて、Ａのいう報告書は「手続き型」が適用されていることに気が付いた。

　プログラミングをご存じない方のために補足する。

　ボールと壁を例にしてみよう。ボールが壁に当たると跳ね返るプログラミングでは、それを表現する手法が無数に存在する。下記例は正確ではないがイメージの手助けになると思う。

オブジェクト指向：ボールと壁にはそれぞれ役割が決まっている。ボールが壁に当たったと判断してどうするか決める。

手続き型：ボールがどういう動きをするか、あらかじめ指定している。ボールは壁に向かって投げられて跳ね返るように見えるが、すべての軌道はいちいち記述されて決められている。

　この二種類の手法の結果は、両方とも「壁に当たって跳ね返る」になる。表現方法の問題だ。

　この二種類の手法にはメリットとデメリットが存在してる。

【メリット】

手続き型：コードが追いやすく学習難易度が低い。簡単なシステムに向いている。

オブジェクト指向型：再利用がしやすく、保守性が高い。複雑なシステムに向いている。

【デメリット】

手続き型：再利用ができない。

オブジェクト指向型：コードが追いかけづらく学習難易度が高い。

　報告書はだれでも簡単に読める必要があり、その方法として記述方法は手続き型のような形式になるらしいということである。

　私が今回書いた報告書をオブジェクト指向型報告書で、Ａがいう全て記入された報告書を手続き型報告書と考えてみよう。

　オブジェクト指向より手続き型の方が、読みやすいことに気づく。見た目は私の方がスマートだが、親切なのはAの報告書だろう。

　ボールの例だと、私の報告書は、「ボールが壁に向かって投げられた」とだけ書いてある。Aの報告書は「ボールが壁に向かって放物線上に飛んで跳ね返った」と書いてあるわけだ。

　報告書はそれ自身で完結すべき。なるほど。

　表現するものは同じだし、結果も同じだ。しかし、書き方の秘訣というものを言語化でき、私は気分が良い。

　報告書の書き方というものについて、プログラミングの考え方が結びついて面白かったのでノートに纏めた。