長文が読み書きできないのは致命的

経営トップやマネージャは忙しい、なので報告は短くといわれて久しい。
本当なのだろうか。

短くまとめる能力も必要だが、長文でしっかり説明できないと困る。また、長文も読めないと困る。と思う。

逆に、何文字以上で書けというのもクレージである。よく国家プロジェクトの報告書とか、金額いくらあたり何ページがメドだといわれて、みな真に受けている。結果、何百ページを越える報告書を作る。が、そのような報告書は読むのにムダに時間がかかる。おそらくは誰も読んではいないであろう。まさに作業が形骸化していて、時間の無駄である。

以下、その理由をはじめに紹介し、後半　http://bit.ly/JpqxvI 　で長文短縮化の間違いを2つの実例で実験してみたい。http://bit.ly/K6t5VM だけでも、短縮化への取り組み勘違いを実感できると思う。 リンクをクリックするとジャンプできる。
最後　http://bit.ly/K6KNbC　に本blogの長さなど、統計量を書いておく。

理由を簡潔に書くと以下の通り)

1. イノベーションの時代であり、知らない技術がどんどん生まれてくる。
2. 経営者は、これら経営判断しないとならない。マネージャはマネージメントしないとならない。
3. 技術理解なしに、数行で進捗を説明されても何が何だかわからない。
4. 口頭で説明せよとなる。
5. 紙の資料なら10分も掛からないが、同じものを口頭で説明すると30分はかかる。
6. また、忙しいと直ぐに忘れる、一度読んだ文書なら1分で思い出せれるが、また報告にいくとなると、する方もされる方も時間がかかる。結局、一旦忘れたら、技術内容がよく分からないまま報告書を読むことになる。
7. 技術内容を知らずに、事業判断ができるか。。私はNoだと思う。

技術内容を知らずに、事業判断ができるか)

2012年5月28日月曜日: HowよりWhatの勘違い。

に書いた沢山のHowの部分は、ざっとでも良いので、技術の中身を知らないと簡単には判断できない。

 単にお客様視点で、製品をみただけでは、ほとんど違いは分からない。その製品に関する知識とか、十分に使い込んでいないとならない。

試作品ができた状態で、ぱっとみてその価値がわかる経営者は、やはりその道の技術に長けているといえよう。(Steve Jobsは、そうだったらしい）

一つの技術がイノベートしないで改良で続くのなら、適用可能かも知れないが、破壊技術がでてきたり、大きなイノベーションが起きていたら、おそらくは、革新性を見誤るだろう。この事例は沢山聞いている。

似たような話)
よく技術者の間で言われる話。ガラケーを使っている女子高生にスマホが発想できるか。Noである。ガラケーの世界しか知らないからである。新しい技術を作るには、技術を知った上で、女子校生の気持になれる技術者こそ必要である。

素人では技術開発はできないということである。同様に、やはり全く技術をわからないのでは、事業判断はできないと思う。

米国の技術者はどうか）
仕様書を書かない技術者が多い。ハードウェア設計仕様も、ソフトウェアの設計仕様もどんどん変わるからである。よく使われるのは、簡単なコンパイルと走らせ方のDocumentだけを用意して、自分で実行してみてね。あとは、ソースコードにコメントが書いてあるから読んでね。分からなかったら質問してね。というものである。

ソースコードを読んで、ちりぢりのコメントで理解するのは、長文読解よりも遙かに手間がかかる。長文が読める根性のある人でなければ、やれないように思う。

文字の資料の意味)

A4一枚 80 x 40行として、3,200文字。サマリーだと、40字 x 5行 = 200文字。表現できる内容が、16倍も違う。サマリーで技術の本質を理解することは不可能である。図表や写真をいれても、説明がないと全くわからない。

昨今はA4一枚の資料が読めないというが、ちゃんとした技術説明をするとA4 が3から5枚にはなる。5枚として考えると、1万6千文字である。

文字の資料と、口頭での説明の差）

文字の資料だと中学受験をした小学生なら1,200文字/分で読める。(速読に関連して、小学生2人と大人1人を実測してみた。）音読するとせいぜい450文字/分が限度。口頭で説明したら、おそらく平均120文字/分もいかない。計ってみると分かるが、普通にしゃべると3音/秒程度である。速読練習をすると、数日で 3,000文字/分に達し、誰でも6,000文字/分(しゃべる速度の50倍) に至るようである。（速読の勧めを、以下に書いた）

2011年12月31日土曜日: 速読の勧め - Super Reading

先のA4　5枚と仮定した完全版の資料を、1,200文字/分で読むと13分である。これでは、興味の無い人には時間が掛かりすぎるので、1) 目次  2)概要  3)詳細という構成にして、冒頭部を600字ぐらいでまとめればよい。それなら2)までを30秒で読める。

実際に会社でも、パワーポイントなどの中途半端な資料はやめて、wordで完結した報告書を書けとか、資料はフリーフォーマットでよい。とか変えつつあるところがある。

長文が書けない読めない人は..)

長い文がロジカルに書けない人は、短文でもロジカルには書けないと思う。
また、長い文が読めない人は、そもそも、文章を書く資格すらないことが多い。

長文が読み書きできる、辛抱強さがなければ、到底、長い会議にも耐えられない。
出ているだけで、ときどき、ちらほらと話を聞くことになってしまい。
有意義な議論ができない。

長文だからといって読むのに時間がかかるか)
おそらくはNoである。まず、文を短くするのに何をやるかを考える。

1. 内容を絞り込む。-- これはある意味有効。無駄な論理を省く
2. 余計な、言葉を省く。「なるほど」「たしかに」とかである。これは、有効だが、文体が変わってくる。
3. 「ですます」調を「である」調にする。多少短くなるが、文の堅さが変わる。
4. 体言止めにする。「可能である」を「可能」にする。など。
5. 段落を一つにして、詰めて書く。

1は有効であるが、内容が根本から変わることが多い。2は有効だが、文としてつまらなくなることが多い。3は、若干だが有効。4も有効な場合があるが、内容すら変わってくる。

読んでみると、所詮大した違いにはならない。人間、末尾の部分には力を入れて読んでいないからである。5は却って読みにくくなる。

一方、行数は増えるが読みやすくするテクニックは以下がある。圧倒的に分かりやすくなが、報告書の行数を制限されると、これが使えないケースがでてきて、逆効果になる。

1. 段落毎に、行間をあけて、ばらばらと書く。（上記5の反対である）
2. 適宜、章にわけて、適切な見出しをつける
3. 箇条書きにして、まとめる。
4. 必要な内容は、適宜繰り返して、文の前の方に戻らなくても読めるようにする。
5. 目次、概要、詳細の3部構成にする。

問題なのは以下の、文のロジック（すなわち論理展開）がめちゃくちゃな文であり、これは、いかに短くても、読むのに時間がかかる。また、聞いたことも無い専門用語やら、曖昧な表現をつかわれると、途端分からなくなる。本稿の後半で例を示したい。

短縮する効果の例）
内容を維持して短縮しても、あまり読む時間には影響がでないと私が考える例である。

Ａ)　原文

総アクセス総数が多い理由は記事が沢山あるためですが、先の日食の記事は5/6の投稿で393アクセスになっています。 

同じ記事に、何度も手をいれているので、面白いといって読んでくれている方もいます。それに記事全体は長いのですが、セクションはなるべく短く簡潔にしてあり、話が展開していって、面白く読めるように、毎度工夫をするようにしています。

B) 　ですます調。余計な言葉を省く。

総アクセス総数が多いのは記事が沢山あるためですが、先の日食の記事は5/6に投稿して、現在393アクセスです。記事を頻繁に推敲するからか、面白いと読んでくれる方もいます。また記事全体は長いのですが、セクションは極力簡潔にし、話が展開して、面白く読めるように、毎度工夫をしています。

C)　である調。

総アクセス総数が多いのは記事が沢山あるためだが、先の日食の記事は5/6に投稿して、現在393アクセスである。記事を頻繁に推敲するからか、面白いと読んでくれる方もいる。また、記事全体は長いのだが、セクションは極力簡潔にし、話が展開して、面白く読めるように、毎度工夫をしている。

意味が良く通じない翻訳文)
別な例で、以下を実験した。

1. 原文) 日本語として形を成してない文が読みにくいこと
2. 書き直し文）長さを変えなくても、文を直せば読みやすいこと
3. 超短縮文）内容を理解していれば、目的にあわせて極めて短文化できること
4. インチキ短縮文）会社の報告書でやる、間違った短文化が、中途半端なこと

Softbank Creative社　2009年7月7日初版　「はじめてのiPhoneプログラミング」　デイブマーク・ジェフラーチ著 某日本の有名大学卒の方の訳　http://amzn.to/K6v6Bj　参照。
から、 p.134 「第6章　マルチビューアプリケーション」の一部を引用する。
以下が書籍にある通りの文である。

原文)

はじめの一歩からマルチビューアプリケーションを作成するにあたって、より手強いことの一つは、相互接続したオブジェクトを作成しなければならないということです。Interface Builderでなにかをする前に、またソースコードの１つも書きはじめる前に、われわれのアプリケーションファイルを形成するすべてのファイルを作成しなければならないわけです。最初にすべてのファイルを作成しておくことで、Xcode Code Senseを使ってわれわれのソースコードをより早く書けるようになります。

この調子で、一冊の本が続いている。自動翻訳にほとんど加筆していないのではとも思える。問題点は以下の通り。

• 意味不明な用語が突然出てくる
• 本来の説明に関係ない修飾語が多い
• 日本語としてよじれている。

以下のように書き直せばぐっと分かりやすくなる。読みにくいのが、文の長さのせいではないことが、おわかりになると思う。

書き直し文）

ビューという画面の構成要素が複数あるアプリケーションを、何もないところから作成することにします。オブジェクトを複数作って相互接続しないとならないので手強いです。ツール(Interface builder) を使ったり、ソースコードを書き始めたりする前に、まず空のファイルでよいので、アプリケーションを構成する全てのファイルを用意することをお勧めします。それによって、Xcode Code Senseというツールを用いて、ソースコードを簡単に記述できるようになります。

ここでは、たいして重要なことは言っていない。もっと短くして、以下のようにしても十分である。

超短縮文）

 空のファイルでよいから、全部のファイルを作っておくのが、コツです。

結局、文に内容がほとんどないので短くなったが、内容をかなり落とした結果である。つまり、

1. どういう場合(どう言うアプリケーションで、どう言う状況で)、このコツが適用されるのか。
2. それがどう言う理由で嬉しいのか。

などが落ちている。また、文の主張点を理解していなければ、このようにスッキリと内容を詰めることはできない。これが長文が書けなければ、短い文も書けないと主張する理由である。

内容を理解しないで短縮すると)
また、内容を理解しないで「書き直し文」を、短くしようとするとどうなるか。見やすいように、上下に並べて書く。文の長さは、表面上長くなるが、再引用を読んで時間がかかると文句をいう人はいない。並べたほうが、比べやすく、親切だとは思わないだろうか。

書き直し文）

ビューという画面の構成要素が複数あるアプリケーションを、何もないところから作成することにします。オブジェクトを複数作って相互接続しないとならないので手強いです。ツール(Interface builder) を使ったり、ソースコードを書き始めたりする前に、まず空のファイルでよいので、アプリケーションを構成する全てのファイルを用意することをお勧めします。それによって、Xcode Code Senseというツールを用いて、ソースコードを簡単に記述できるようになります。

インチキ短縮文）

ﾋﾞｭｰが複数あるｱﾌﾟﾘでは複数ｵﾌﾞｼﾞｪｸﾄを相互接続する。新規作成では、ﾂｰﾙの有効活用のため、ｱﾌﾟﾘの全ﾌｧｲﾙを空で用意。Xcode Code Senseで、ｿｰｽの簡単記述が可。

確かに短くなる。以下の手法を使っている。

1. 全角カタカナを半角にして一見短くしている。
2. 新規出現した用語の説明を省く。
3. アプリ、など、短縮形、いわゆるジャーゴン(　http://bit.ly/K6CMDy　）を使う。
4. である調にし、極力体言止めにする。箇条書きを文章にしたものとも言える。
5. 主語を省く

これで、文字数は確かに減り、見かけ上文の長さは短くなった。多少読む時間が、はしょれたかもしれない。が、「書き直し文」の内容を理解して書いた「超短縮文」で十分なのに、それほどまでにも読む時間が短縮されない。むしろ「書き直し文」に比べ、内容や文の連結が曖昧になった。半角カナで読みにくくなった。つまり、中途半端な文になっただけに思う。

ちなみに、もともとの「書き直し文」は、長文だと騒ぐほどの長さでもない。

英語メイルでは）
補足だが、英語では、決してこういう短縮化はしない。文章は、あくまで文章であり、主語や動詞は省かないし、適切な単語は決して変えたりしない。むしろ、「超短縮文」のように、内容を精査し短縮して、選んだ内容については、丁寧に説明するのである。

英語に関しては、例を別途あげることとするが、一つだけ引用しておく。「そのやり方は、複雑だし関係ない部分にも影響を及ぼして良くない。」ということを言うのに、これだけの文を掛けているのである。丁寧で婉曲な表現も使っている。専門家同士の会話なので、専門用語があるのはご容赦いただきたい。

This seems more complicated than is necessary and introduces the max version number logic into yet another part of the system.
I'd argue for doing whatever is simplest and most central. What's wrong with just ensuring that the max version number entry is written atomically with the header and log digest?

長文読解、長文作成能力がないと、短文も書けないと主張する理由である。

日本のIT業界は大丈夫なのか）
翻訳本では、この程度の日本語のソフトウエア解説書は多い。英語力もないので、原文に引きずられ逐語訳になるうえに、日本語の作文力が足らないのが露呈している。

また、言語解説書とかは翻訳本ばかりである。それでは、日本のソフトウエア技術者が勉強するのも大変である。
また、こんな文ばかり読んでいて論理的な思考力がつくのか、不安になってしまう。

英語力をつけて、原著で読む人が増えてきているのだろうと期待したい。

業務文書での注意点）
業務文書は作文とは違う。以下の注意が必要である。感情を書く作文よりも、報告文の練習を積むべきであるし、米国では、小学生から、そういう作文教育がされている。

そもそも、小説が書ける才能がある人は、自分で小説を沢山読むので、小説を書く能力など、教えなくても、知っているはずであろう。

1. 起承転結ではない。転はいらない。むしろ、起結、ないしは、結でも良いぐらいである。http://bit.ly/K6wDXP　にも主張がある。
2. 自分や専門家にしかわからない用語は使わない。
3. 表現の揺れをなくす。用語は同じ意味ならば一つに統一する。
4. 主張点を明確にして、それに対して説明をつけていく。
5. 一時には、複数のことは言わない
6. 文と文は論理関係でつながっている。前の文を読んで、次の文が予想できるぐらいがよい。意外な展開（小説のような）は、悪い文である。これはスライドについてもいえる。Stanford大では、そのように学生を指導している。以下に書いた。
   

   2011年12月31日土曜日: 本当の教育者、本当のプロとは

7. かならず、自分で読み直す。納得するまで書き直す。本当に国語力のある人は、これは要らないようであるが、私は不十分なので、なんどでも書き直している。そうすることで、少しは国語力もついてくると思う。

米国には、Editorという職種がある。論文や報告書、記事などを校閲する仕事である。この方による、英文writingの講座を受講しているが。2, 3については、これでもかと、訂正する。2つの単語、たとえば、storageとdata storeという単語を2つ使ったら、どう意味が違うのか、確認される。同じ意味なら、一つにまとめろということである。単語の使いわけについても非常に厳密である。referenceとindexという単語を変えると意味が通らなくなる。

英語に関しては、こういう英語教育をしていないと、英語社会で通用するような、まともな英文は書けない。なんとなく意味が通じるというのは、旅行者レベルの英語であり、そのレベルでは、知識階層には、相手にもされないのを、定例会議にでていて強く感じる。すこし話題がそれたので、別途記載したい。

長文が読めない弊害）
長文が読めない人は、マニュアルも読めない。いろいろな製品を真に使いこなせない。
すこし、こんがらがった文も読めない。

人の主張も読み下せない。そういうくせに、自分は、文の構造がこんがらがった長文を書いたりして平気だったりする。つまりコミュニケーション能力が低下する。

長文読解力の低下は理解力の低下につながり、がそれでは、有効な技術開発も、有効な事業判断もできない。

本blogの長さ）
ちなみに、この記事は、本節の前までで、A4 9ページ。310行。6,736文字である。
これぐらいの長さがないと、主張が書けないと同時に、これぐらいの長さがあれば、主張は十分かける。1分1,200文字の読書速度の人なら、5分で読める。

書くのには、5-6回の推敲をいれて、都合2時間ぐらいであろうか。
もちろん自分では、何度も読み直しているが、全文を読んでも1分も掛からない。
ただし、慌てて読むと誤字（変換ミス）に気がつかないのであるが。

本blogは、いろいろ書き足していって、当初の2倍以上の長さになり、文がよじれてきている。複数の論旨があると文が不明瞭になる。そろそろ、分割も考えたい。。