第9回　メタ情報とサマリーで「伝わる」ビジネス文

開米瑞浩（アイデアクラフト）
2006/6/23

コミュニケーションスキルの土台となる図解言語。だが筆者によると、実はその裏に隠れた読解力、国語力こそがITエンジニアにとって重要なのだという。ITエンジニアに必須の国語力とはどのようなものだろうか。それを身に付けるにはどうしたらいいのか。毎回、ITエンジニアに身近な例を挙げて解説する。

　ビジネスやエンジニアリングの世界では、実務的な国語力＝「情報を整理整頓して分かりやすく他人に伝える能力」が不可欠である。しかし困ったことにその実務的な国語力を学校ではなぜか教えてくれない。典型的な失敗を学び、そこから実務的な国語力を養おう。

■実務的な国語力が必要とされている

　20年前、高校生だった私が最も嫌いな教科は国語だった。

　その私がいまでは国語教育の改革の必要性を訴えて旗を振っているというのも妙なものだが、私の理屈は首尾一貫している。要するに「無駄な教育はやっても無駄、まともに意味のある教育をしよう」ということである。

　私が現役高校生だった時代、国語という教科は無駄なものだった。受験の役に立たないという意味ではなく、授業を受けても国語力が付かないという意味で「無駄」だったのだ。

　もしこの評価に異議があるとすれば、おそらく「国語力」に何を求めるかの考えが違うのだろう。「文章に書かれている情報を正しく読み取り、整理整頓して分かりやすく他人に伝える能力」という意味の国語力、現在のビジネスやエンジニアリングの世界で必要とされる国語力は、例えば下記のような目次で構成された教科書では身に付かない。

小説を読む（1） 詩を味わう 言葉と生活 小説を読む（2） 創作の楽しみ 自己を考える 小説を読む（3） 生への思索 短歌と俳句

　これは3年ほど前の、とある高校現代文の教科書の目次から一部を引用したものである。一目で「小説」「詩」「創作」「思索」といった文学や哲学に関するテーマのオンパレードであることが分かる。要するに20年前から変わっていないのだ。

　別に文学や哲学を否定したいわけではないが、それを高校の授業で何十時間もかけてやる必要はないだろう。ちなみに私自身は自分で小説や舞台脚本を書いていたこともあり、文学芸術への愛にかけてはそこらの国語教師に負けるものではない。だが、だからこそ文学教育は国語教育とは別にするべきだと考えている。普通の学生に必要なのは国語教育であって文学教育ではないのだ。

　仕様を表現したり事実関係を報告したりといったビジネス文書には、詩も小説も思索も通用しない。それをやるぐらいだったら実務的な国語の技術を学んだ方がよっぽど役に立つ。現にその実務的な国語力がないために、大学でも論文が書けないし、会社に入ってからも仕事ができずに困ってしまうケースが後を絶たないのである。採用する会社の方でもこのことが深刻な問題になっている。

　では、どんな教科書であれば「実務的な国語力の養成」という目的に適しているのだろうか。今回はその一例として、私が先日行った「仕様を伝えるコトバの力」というセミナーの一部を紹介しよう。

■「こんな説明では分からない」10種類の失敗パターン

　このセミナーの狙いは、主にITエンジニアの実務で使われる仕様書や説明書、議事録などの文書における表現技術のポイントを身に付けることである。例として、よくありがちな10種類の失敗パターンを取り上げた。セミナーの目次から引用すると以下のようになる。

（1）メタ情報の欠落 （2）要点の分からない見出し （3）複雑な条件の文章表現 （4）分類を表さない名前 （5）過剰な言い換え （6）対称性のない表現 （7）指示代名詞の多用 （8）相互関連の分からない個条書き （9）時系列の乱れ （10）語感と実感のミスマッチ

　先ほどの国語教科書と比べると、1つ1つの項目の具体性が非常に高くなっていることがお分かりだろうか。国語教科書の方は「詩を味わう」「生への思索」といった、何をするのかはっきり分からないもので、下手をしたらタイトルと本文が違っていても気が付かないだろう。

　それに対して上記「10種類の失敗パターン」は各項目がそれぞれ特定の問題を扱っていることが明らかであり、タイトルと本文が違っていれば必ず気が付く。

　ちなみにこの現象は実はよくある話で、慣れない人が作ったプレゼンテーション資料はページのタイトルと中身が違っていることが珍しくない。そんなばかなと思うかもしれないが、冗談抜きにそれが実態である。それを防ぐためには明解なタイトルを付けることを習慣づけておくしかない。それを考えると、実は国語教科書はそれ自体がビジネス文書としては「出来の悪いシロモノ」であって、教科書の役割を果たしていないのだ。

　この10項目の中には本連載ですでに扱ったものもあるが、それも含めてひととおり簡単に解説していこう。

■メタ情報の欠落

　「メタ情報」などと聞き慣れない名前が出てきたが、要するに「見出しを付けろ」というだけの話である。例えば次のような報告がメールで届いたとしよう。

○○運輸の配送トラックが多重事故に巻き込まれて炎上しました。 積み荷に当社からの出荷商品が3個含まれていて、すべて焼失しました。 至急、再配送の手配が必要です。

　わずか3行のテキストで内容も単純明快だ。これを見て「分からない」と思う人はまずいないだろう。しかし、実務的な国語力の観点から考えると、この文は出来が悪い。「メタ情報の欠落」という失敗パターンにはまっている典型である。

　どうするべきだったかというと、例えば下記のように書けばよかったのだ。

【事故】○○運輸の配送トラックが多重事故に巻き込まれて炎上しました。 【損害】積み荷に当社からの出荷商品が3個含まれていて、すべて焼失しました。 【対応（todo）】至急、再配送の手配が必要です。

　要するに、「事故、損害、対応（todo）」という見出しを付けるべきだったということである。

　ここで付けた見出しのことを「メタ情報」と呼んでいる。メタ情報というのは抽象的にいうと「情報の意味を規定する情報」のことである。例えば、「出発地：東京」と「到着地：東京」とあった場合、同じ「東京」でもその意味は違う。「東京」という情報が持つ意味を「出発地」または「到着地」というメタ情報が規定するという関係にある。

　実はITエンジニアはオブジェクト指向プログラミングやHTMLの<META> タグ、XMLなどを通じてこの概念をすでに知っていることが多い。メタ情報というのはデータベースでいえばスキーマであり、プログラミングでいえば構造体やクラス定義に当たるものである。

　そのメタ情報を、報告書や説明書などを書くときも必ず付けるべきなのだ。「それだけ？」と思うかもしれないが、ただそれだけのことさえほとんど実践されていないのが現実である。

• 電子メールで数行の報告を送った。短いので見出しを付けなかった
• 社内規定の報告書フォーマットを何も考えずに使ってしまい、「そのほか」の欄にズラズラと長文を書き連ねてしまった

　このような例の1つや2つは、誰でも心当たりがあるだろう。報告書や説明書という自然言語でのコミュニケーションでは、いちいち書かなくても内容を読めば通じてしまうため、メタ情報を省略してしまうことが多い。

　しかし、それではいけないのだとあらためて肝に銘じておこう。一見簡単そうに見えても、メタ情報を付けるのは意外に難しいものだ。

　例えば今回の例題にしても、「損害」のところを「影響」や「結果」としてもよさそうに見えるかもしれない。しかし、「影響」や「結果」というのは中立的な表現なので、「ちょっとこれはヤバイ事態でっせ」という意味を伝えることができない。ここはやはり「損害」でなければいけないのである。

　このようにいくつかの候補の中から最も適切な言葉をメタ情報として選び出すためには、単に情報の表面的な内容だけでなく、ビジネスにおいて意味するニュアンスも含めて完全に理解していなければならない。そのため、メタ情報を考えるのは単に読み手にとって便利なだけでなく、書き手である自分の頭を整理するうえでも効果的なのである。

■要点を表さない見出し

　ところが、実はメタ情報が役に立たない場合もある。例えば次のテキストを見てみよう。

＜概要＞ Javaサーブレットは、Javaアプリケーションをサーバ側で動作させる仕組みです。 ＜機能＞ CGIと同様の機能を、Javaで実現しています。 ＜メリット＞ CGIでは、HTTPリクエストを受けるたびに、新しいプロセスが生成されます。Javaサーブレットでは、1つのプロセスが何度もリクエストを処理するため、負荷が少なく、高速に実行できます。

　赤字の部分がメタ情報になっているが、これは読み手にとって役に立つだろうか。

　このテキストの赤字部分を削って本文のみを提示し、「これに見出しを付けろ」と出題したとき、一番多い解答が上記の「概要、機能、メリット」の3点セットなのである。しかし一番多いからといって、それが役に立つものだとは限らない。この問題の場合、下記のように見出しを付ける方がはるかに役に立つだろう。

＜サーバ側のJavaアプリ＞ Javaサーブレットは、Javaアプリケーションをサーバ側で動作させる仕組みです。 ＜CGIを代替可能＞ CGIと同様の機能を、Javaで実現しています。 ＜高速・低負荷＞ CGIでは、HTTPリクエストを受けるたびに、新しいプロセスが生成されます。Javaサーブレットでは、1つのプロセスが何度もリクエストを処理するため、負荷が少なく、高速に実行できます。

　「メリット」と書かれたのでは本文まで読まなければ内容が分からないが、「高速・低負荷」ならばそれ以上読まなくても大体の意味を読み取れる。これなら見出し部分のみを拾い読みするだけで済むので、膨大な報告を受けなければならないマネージャにとってはこの方がありがたいのである。

　要は、見出しを付けるときには、情報の項目名＝メタ情報と、情報の要約＝サマリーという2種類の選択があるということだ。

■メタ・サマリー・ディテールの3点セット

　実はこの例題に限らず、あらゆる情報について「メタ・サマリー・ディテール」の3点セットを考えることができるのである。

メタ情報：メリット
サマリー：高速・低負荷
ディテール：CGIでは〜（中略）〜高速に実行できます

　書く側が自分の思いつくまま書いてしまうと、とかくディテールだけの文章になりがちなのだが、それでは読み手が苦労する。書き手はメタ情報とサマリーを加えて3点セットで情報を管理し、適宜その中から必要な範囲の情報を出すようにしなければいけないのである。

　これは間違いなく高校までの国語教育で履修すべき課題である。大学入学後や就職後に初めて学ぶのでは遅過ぎる。なぜなら「メタ・サマリー・ディテール3点セット」を考えることは、自分の頭を整理するために有効な手段なので、これができるのとできないのとでは専門分野を勉強するスピードにも大きな差が出てくるためだ。

　このような実務的に有効な国語力を身に付けさせず、ひたすら文学や哲学の世界に没頭している国語教育には、30年前ならいざ知らず現代ではもはや存在意義はない。

■残る課題は次回に継続

　今回取り上げたメタ情報とサマリーの問題は、10種類の失敗パターンのうちの（1）と（2）に該当する。次回以降で残りのパターンを扱うので、引き続きこの連載を楽しみにしていただければ幸いである。