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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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

maria/安倍 茉里/sabrina/ @marianna_ave

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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

教訓３：似通ったパターンに注目する →解説：２０行ほどのある文書を箇条書きに分解すると１５か条ほどになった。そのうち３～５条と６～８条が非常によく似たパターンだった。こういう「似たパターン」に注目してそこを構造化すると、全体の手がかりになる基本構造図が書けることが多い

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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

開米瑞浩 @kmic67

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