図解の本質はここにあった ITエンジニアにも必要な国語力

図解の本質はここにあった
ITエンジニアにも必要な国語力

第10回 複雑な条件を文章で書くべからず

開米瑞浩(アイデアクラフト)
2006/7/20

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

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

 前回「メタ情報とサマリーで『伝わる』ビジネス文」に引き続き、典型的な失敗のパターンから実務的な国語力を身に付けよう。

 前回の記事で「こんな説明では分からない」10種類の失敗パターンを列挙した。以下のようなものである。

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

 今回はこの3番目、「複雑な条件の文章表現」を紹介しよう。といっても大した話ではない。

複雑な条件の説明を文章で書いてはいけない

というだけのことだ。「条件の説明」というのは通常、以下のような形式になる。

基本形:Bならば、Aができる(あるいは、できない)
具体例:(B)身長120cm以下のお子さまは(A)ご乗車になれません

 こんな単純な場合ならば別に問題はないのだが、実業務では条件を表すBが複雑になるケースがちょくちょくある。例えば

複雑な条件例:BかつCまたはDならば、Aができる

という例では条件部分を論理式で書くと「(B and C)or D」と「B and(C or D)」の2種類の可能性があり、どちらのことなのか特定できないというややこしい話になってしまう。

 なお、論理演算のルールとして「and」の方が「or」よりも優先順位が高いため、この場合は前者に特定できるという意見もあるだろう。しかし、このように文章で書かれた場合、書き手が論理演算のルールをわきまえて書いているとは限らない。また知識として知っていてもそれを正しく運用できないこともある。やはりどちらかに特定するのは危険である。

 つまり、この例のように複雑な条件の説明は、そもそも文章で書くには向いていないのだ。

文章を捨てよ、図解しよう

 文章で書くのがダメなら図解しようということになるが、図解といってもこの場合は個条書きにするだけでもよい。例えば、以下のように書くだけでもかなり分かりやすくなる。

<個条書き例1>
(1)BかつCである
(2)Dである
(3)(1)と(2)のどちらかを満たせばAができる

 これなら60点ぐらいつけてもよい。しかし60点というのは微妙なところで、予選は突破できたが決勝戦には残れない、というくらいの水準である。要するにまだまだ改良の余地があるということだ。どのように直せばよいだろうか?

個条書きの各項は同種の情報を示しているか?

 前述の個条書き例1のように

(1)******
(2)******
(3)******

と、見掛け上同じ形式で並んでいると、読み手は「個条書きの各項が同じ種類の情報を示しているのだろう」という先入観を持ってしまう。ところが、書かれている内容はそうではない。改良例を示すと下記のようになる。

<個条書き例2>
下記のどちらかを満たせばAができます
(1)BかつCである
(2)Dである

 このように書ければ90点ぐらいの採点になり、実用的にはほぼ問題ない。いや90点じゃまだ不満だという場合はさらに次のように直してみよう。

<個条書き例3>
Aができるための条件は、下記のどちらかを満たすことです
(1)BかつCである
(2)Dである

 ちょっとした改良だが、「Aができるため」という部分を先に持ってくる方がいい。なぜなら、一般的に人が「目的+そのための行動や条件」といった説明を聞く場合、先に目的をはっきりさせる方が理解しやすいことが多いからだ。

 上記は「(B and C)or D」の場合だが、同じやり方で「B and(C or D)」という論理式を表現すると以下のようになる。

<個条書き例4>
Aができるための条件は、下記の両方を満たすことです
(1)Bである
(2)CまたはDである

 こう書けば、論理式を読むのに慣れていない人にでも、ほぼ誤解の余地なく伝わる。

「複雑な条件」を見逃すな

 「Bならば、Aができる」という基本形の条件部分が複合化した例を紹介してきた。ご覧のとおり理屈としては別に難しいものではないので、まずは実践してほしい。身近にある仕様書、指示書など多くの文書にこの種の記述があるはずだ。

 とにかく、複雑な条件を文章で書いてはいけない。それはスプーンで風呂の水をかき出すようなものである。このことをはっきり認識しておかないと、何かの説明文を書いている途中で「複雑な条件」が出てきたときに、何げなくそのまま文章で書いてしまいがちだ。何度もいうがこれは高校レベルの国語教育でたたき込まれるべき基本習慣なのである。

 そのうえで、「複雑な条件」に該当するいい回しには「Bならば、Aができる」以外のものもあることに注意しよう。

 「〜ならば」という文言があれば、それが「条件」を意味していることが分かりやすい。しかしそれ以外にも「実は条件になっている」という場合がある。例えば、

変化形:Aをするためには、Bをしてください(Bが必要です)

というものが代表的だ。具体例としては以下のようなものが挙げられる。

Q:利用サービスを変更するために何か特別な手続きや料金が必要ですか?

A:ご希望のサービスに関する環境適合調査が必要になります。結果、サービスの提供が可能である場合、契約変更手数料が必要になります。サービス提供が不可とされた場合でも環境適合調査費は必要になります。

 ここには「Bならば、Aができる」といういい回しは出てこないが、やはり複雑な条件の説明になっている。これを単純に個条書きにしてみると以下のようになる。

<個条書き例5>
利用サービスの変更に必要な手続き・料金
(1)ご希望のサービスに関する環境適合調査
(2)サービス提供が可能な場合、契約変更手数料
(3)サービス提供不可能な場合でも環境適合調査費が必要

 個条書きにしたら必ず「各項が同種の情報を示しているか」をチェックする。すると、明らかに(1)は手続きについて、(2)は料金について、(3)も料金についてとそれぞれバラバラな情報であることが分かる。しかも(1)と(3)はいずれも「適合調査」の話だから、本来(2)の前にまとめて書いておくべきものだ。

 この例のように個条書きの各項で複数の情報(例えば手続きと料金)を語っていて、しかも各項に時間軸で依存関係があり前項の結果で次項が変わるような場合、単なる個条書きで書くのは無理がある。

 ここで図解の出番である。といってもこの例の場合は表組みにするだけでも用が足りる。例えば下記のようなものである。

利用サービス変更に必要な手続き・料金
サービス変更
申し込み
         
No
前提条件
手続き
費用
手続き内容
(1)
なし
環境適合
調査
環境適合
調査費
サービス提供
可否を判断
(2)
(1)がOKの
場合
契約変更
契約変更
手数料
提供サービスの
変更
変更完了
         
図1 複雑な条件の図解例

 もちろん違う問題の場合は違うパターンの図解になるので、上記のパターンそのものを覚えても意味はない。重要なのは、

これは「複雑な条件」だから、文章ではなく図解しよう

という部分を見逃さないことである。見逃さずに考えれば、適切な表現方法はいずれ思いつく。見逃してしまえばそれまでだ。

ちょっとした違和感を大事にしよう

 今回扱ったような「複雑な条件」の説明は、ITエンジニアが読み書きする文書には頻繁に出てくるものだ。何だかややこしいな、というちょっとした違和感をおろそかにせず、食らいつくように対応してほしい。実践の機会はそこらじゅうにあふれているのである。

自分戦略研究所、フォーラム化のお知らせ

@IT自分戦略研究所は2014年2月、@ITのフォーラムになりました。

現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。

これからも、@IT自分戦略研究所をよろしくお願いいたします。