編集可能
2011年10月20日

わかりにくい文書を如何に改善するか~課題文書から得られた教訓10箇条

説明のコツ:「問題」が発生する「場所」と「対策」の関係を明示する - 読解力図解力と教える技術の謎解きブログ http://blogs.bizmakoto.jp/kaimai_mizuhiro/entry/3560.html
5
開米瑞浩 @kmic67

「わかりにくいと感じた文書を持ち寄って改善案を考える研修」というのをある電機メーカーさんで継続してやっているんだけれど、昨日の講座でその課題文書から得られた教訓を書いてみることにしよう。

2011-10-20 22:43:48
開米瑞浩 @kmic67

教訓1:「 状況 」を伝えて「 選択肢 」を示し「 判断 」を求めるパターン →解説:そのまんまですね。「○○な状況ですのでここで可能な選択肢はAとBがあります。どちらになさいますか?」 というパターン。 これはビジネス文書でよく出てくる。

2011-10-20 22:47:58
開米瑞浩 @kmic67

このパターンでのポイントは、「状況」と「選択肢」を分けて書くこと。 昨日見た文書では、これが分離されておらず、その結果「選択肢2つのうち1つしか明記されてない」状態になっていた。分けてあるとこういうミスは少なくなる。

2011-10-20 22:50:31
開米瑞浩 @kmic67

また、「選択」をするためには選択のための手がかりが示されなければならない。「選択肢がある」という場合は、その選択にともなう長所短所があるはずで、それを整理して示すことも重要。これも昨日の事例では出来ていなかった。

2011-10-20 22:51:56
開米瑞浩 @kmic67

教訓2:1対Nの関係が見えるように書く →解説:たとえば1台のコンピュータには複数のHDが搭載されていることがある。こういう場合、「1対N」の関係が見えるように書いたほうがよいケースが多々ある。文章だけだとその違いがわかりにくいので図解したほうがいい。

2011-10-20 22:54:50
開米瑞浩 @kmic67

昨日の事例では、複数の対象デバイスに対してある処理をする際、「同時並行で行うか」「1つずつ順番に行うか」の選択が可能だった。どちらの選択をするかによって、それぞれ処理時間や必要なリソースが変わってくる。それを直感的に理解するためには「1対Nが見える」図のほうがよかった。

2011-10-20 22:56:44
開米瑞浩 @kmic67

僕の経験上、「1対Nの関係」にあまり注意を払わずに書かれている文書が実は少なくないのでした。

2011-10-20 22:58:00
開米瑞浩 @kmic67

教訓7:「長い名前」を使う回数を極力減らす →解説:技術文書でよくありがちなんだけれど、たとえば次の例文を見てみよう「ハイパーエクストラライトサーミスタは小型高性能です。ハイパーエクストライトサーミスタは長寿命です」 ・・・さて、どこか変じゃない?

2011-10-20 23:02:38
開米瑞浩 @kmic67

何が変か、というと、ハイパーエクストラライトサーミスタ と ハイパーエクストライトサーミスタ 、よく見ると「ラ」の字が1個減ってます。 こういう微妙な違いには人はなかなか気がつかない。ところが技術文書にはこういう「紛らわしい長い名前」がよく出てくる。

2011-10-20 23:04:31
開米瑞浩 @kmic67

単なる誤植、タイプミスではなく、どちらも正しい名前で紛らわしいというケースがよく出てくるので、長い名前が何度も出てくると、「それが同じものか違うものか」を確かめるために読者は非常な負担を強いられるのです。だから、「長い名前を何度も使う」のはしないほうがいい。

2011-10-20 23:06:22
開米瑞浩 @kmic67

具体的な方法としては、「文中に登場する長い名前の数を減らす」のが一番ですが、それができない場合は次善の策として、「名前に記号を付加して書く」という手を私はよくやります。たとえばさっきのエクストラなんとかが実は違うものを示している場合に、

2011-10-20 23:10:34
開米瑞浩 @kmic67

(1)ハイパーエクストラライトサーミスタ (2)ハイパーエクストライトサーミスタ のように、(1)(2)と短い記号をつけて必ずその記号と一緒に名前を使う。そうすれば、記号が違うので「あ、これは(2)だからさっき出てきた(1)とは違うほうだな」という判断を読者が短時間でできる

2011-10-20 23:12:16
開米瑞浩 @kmic67

以上、教訓7でした。ちなみになぜ教訓2から7に飛んだかというと、twitterでは説明しにくい教訓も結構あるから(^^ゞ

2011-10-20 23:14:16
maria/安倍 茉里/sabrina/ @marianna_ave

うわー、TLの取得漏れか?と、悩んでいました(笑 RT @kaimai_mizuhiro: 以上、教訓7でした。ちなみになぜ教訓2から7に飛んだかというと、twitterでは説明しにくい教訓も結構あるから(^^ゞ

2011-10-20 23:16:10
開米瑞浩 @kmic67

この際教訓11までとりあえず列挙しときます(^^ゞ RT @marianna_ave: うわー、TLの取得漏れか?と、悩んでいました(笑 RT 以上、教訓7でした。ちなみになぜ教訓2から7に飛んだかというと、twitterでは説明しにくい教訓も結構あるから(^^ゞ

2011-10-20 23:17:30
開米瑞浩 @kmic67

教訓3:似通ったパターンに注目する →解説:20行ほどのある文書を箇条書きに分解すると15か条ほどになった。そのうち3~5条と6~8条が非常によく似たパターンだった。こういう「似たパターン」に注目してそこを構造化すると、全体の手がかりになる基本構造図が書けることが多い

2011-10-20 23:19:55
開米瑞浩 @kmic67

「似たパターン」というのは全体の中の一部なので、先にそこに注意を向けて考えると、1度に意識しなきゃいけない情報量が減って考えやすくなります。

2011-10-20 23:20:53
開米瑞浩 @kmic67

教訓4:時間軸を明示する →解説:そのまんまです。時間軸があるものはそれを明示しましょう。書く方はわかっていても、読者には通じてないケースが多々あります。 (1)(2)(3)・・・のようにナンバリングをするのが手頃。

2011-10-20 23:23:40
開米瑞浩 @kmic67

だいたい複雑な工程になると、 工程(8): (2)で作った○○と(3)で作った××を合わせて焼きます ・・・のように過去のどの作業に関連づくか指定しなきゃいけない場面がよくある。ここで指示代名詞を使うのは混乱のもとで、ナンバリングしておくほうが簡単。

2011-10-20 23:26:07
開米瑞浩 @kmic67

教訓5:全体の手がかりになる「基本構造」を見つける →解説:略

2011-10-20 23:28:04
開米瑞浩 @kmic67

教訓6:「問題」が発生する「部分」と「対策」の対応関係を明示する →解説:うーんこれは文字では説明難しい あらためて図解つきで書くか(後日)

2011-10-20 23:29:42
開米瑞浩 @kmic67

教訓8:「誰が」 「何をする」 かを考える →解説: よく「5W1Hを押さえるのが客観的記録の基本」 と言いますが、その話です。「誰が」「何のために」「何をする/した」という情報はまず切り分けておくこと。これが不十分な書き方をしてる文書も意外に多い。

2011-10-20 23:32:01
開米瑞浩 @kmic67

教訓9:「目的」を達成する「方法」の「利点と欠点」 →解説:おっとこれは教訓1に通じる話であった。何かの目的を達成するための方法が2つ以上ある、という場合、たいていそれぞれに利点欠点があるので、それを切り分けて書いておくほうがいいですよ、ということ。

2011-10-20 23:34:13
開米瑞浩 @kmic67

教訓10:「組み合わせ判断」には「デシジョンテーブル」 →解説:これは情報処理技術者試験の定番の問題である「デシジョンテーブル」の話。複数の項目の組み合わせによって何をするかを決める、という組み合わせが複雑になる場合はデシジョンテーブルを書け、というそれだけのこと。

2011-10-20 23:36:24
開米瑞浩 @kmic67

しかし意外だったのは、昨日その講座をやっているとき、「デシジョンテーブルって聞いたことありますか?」という質問にほとんど手が上がらなかったことだ。IT技術者でも意外に名前を知らずに使っている人も多いのかもしれない。まあ単なる表だから教えられなくても使うしね。

2011-10-20 23:38:52
残りを読む(7)

コメント

コメントがまだありません。感想を最初に伝えてみませんか?