文章に向いてない構造をいかに文章に向いた構造に直列化するかが大事

Software Design 12月号の特集が「なぜエンジニアは文章が下手なのか？」というタイトルだったので、読んでみたら、ちょっと残念な内容だった。

「それは文章で書くべき情報なのか」という章があって、直列化した論理構造であれば文章には書きやすいけど、分岐やループがあるような構造だと書きにくいということが書いてあった。そこで文章化しにくい構造の例として地図があげてあって、暗にそういう構造は文章化をやめて図であらわせと言っているように読める。
けれども、図に書いたところで、書く側は文章化から逃げれて満足かもしれないけど、それを読み取る側は結局どこかから順番に解釈していく必要がある。図に逃げるのは、読み手に責任を押し付けているだけだと思う。

で、「ですから文章を書く前にまず論理構造を考える必要があります」と続いていて、では考えた論理構造が「文章に向かない論理構造」だったらどうするの？逃げるの？と思ったのだけど、よくみたらこれは「ですから文章を書く前にまず(文章化しにくい倫理構造から文章化しやすい)論理構造を考える必要があります」ということだった。

そして、実際には、あまりその方法は書かれていない。ここが一番大切だと思うのに。
エンジニアが文章化する対象がそもそも文章化しにくい構造をもっていて、そのためエンジニアが書いた文章が下手と思えることが多いだろうからだ。

結局、エンジニアが文章を書こうとする対象は、技術的概念であることが多いので、そうすると、その対象は往々にして文章化しにくい論理構造を持っている。そのため、ただ文章化しようとすれば論点がぼやけた支離滅裂とした文章になってしまう。
エンジニアではない人や、エンジニアであってもエンジニアの立場から離れた状態で書く文章は、行動の記録であることが多く、行動というのは直列化しているから、文章化しやすい。

例えば、Javaの文法を解説するとする。
そうすると、Javaの構造というのはこのように表せる。ただし、ここではJavaの構造の説明が論点ではないので、なんとなくこんな感じと言えるよねってことで勘弁してください。

ここで、矢印を書いていないのは、基本的に相互依存だからだ。そもそも相互依存しているものを説明するのは難しい。インスタンスの説明にはクラスの説明が必要だし、クラスの説明にはインスタンスのイメージは必要になる。
ほかにも、例えばメソッドの説明をすると戻り値など型の説明が必要になるし、型の説明をするにはクラスの説明が必要だし、クラスの説明にはメソッドの説明が必要になる。

そういった、分岐もループもあるような論理構造を持った対象は、そのままでは文章にできないので、これをどうにかして次のような筋道を決めて文章化しないといけない。

ここで、まず考えないといけないのは、これがどのような読み手を前提としたどのような目的の文章かということだ。
読み手と目的を決めることができれば指針がきまる。文章化できない構造を文章化できる構造にするときの基本は、各項目を完全に説明しないで次に行くということだ。そこで、なにを説明してなにを後回しにするかということを決めるためには、なんらかの指針が必要になる。その指針が読み手と目的ということになる。

文章化できない構造を文章化できる構造にするために、最初にやることは、循環構造の解消だ。循環構造を解消させれば、構造はツリー構造になる。
循環構造を解消するためのテクニックのひとつに、各項目を分解するということがあげられる。言語の入門書の場合は、だいたいの項目が、利用と作成にわけられる。メソッドの場合は、メソッドを呼び出すことと、メソッドと定義することにわけられるけど、最初のうちはすでに定義されたものを使うことにすれば、定義に関しては後回しにできる。クラスなども同様だ。
このようにして、閉路のある構造グラフを、閉路のない構造グラフ、つまりツリー構造に変換する。

循環構造を解消できれば、あとはツリー構造をたどる優先順位の問題になる。基本的には、このツリーを全探索するということになる。このとき、幅優先でいろんな項目をかいつまんで説明するよりは、深さ優先でひとつひとつを説明しきって行くほうがいい。
そして、深さ優先探索をするときに、優先順位を決めて、順番を決めていく。優先順位は、先ほども出た、読み手と目的による指針から決めていく。

順番が決まれば、最後の準備として記述量の配分をしていく。その過程で、記述を省くということになる項目もある。というか、ここまでで書きうることは列挙されているので、記述量の配分としては、どの項目を記述しないかということになっていく。

順番と記述量が決まれば、あとは文章を書いていくだけになる。ここでは、記述が事実に即しているか、論理構造を正しく反映しているかということを考える。
事実に即しているかどうかというのは、まあ記述者の本職での力量ということになるので、それは文章力以外のところで磨く必要がある。
論理構造としては、挙げた事実から結論が導出できるかという点と、量化が正しいかということに気をつける。たとえばJavaの場合は型は基本型と参照型があるので「Javaの型は参照型である」は間違いで「Javaの型には参照型がある」は正しい。こういった、てにをはや接続詞は、それらの選び方の間違いというよりは、量化の間違いであることが多い。

言い回しや単語の選び方も気をつけたほうがいいけど、文学作品でもなければ、結局のところ統一されていればいいということになる。
論文や入門書などは、それなりにその分野ならではの書きかたのノウハウがあるので、そこは調べておいたほうがいい。

結局のところ、概念の構造を見出すことや、実装可能なようにその構造を分解すること、論理学として正しい記述をすることというのは、エンジニアの本来の能力なことなので、文章力としてこだわるよりは、エンジニアリング力をこだわってその結果文章もうまくなるということのほうがいいんじゃないかと思う。
それと、もうひとつの考え方として、ブログの文章のようなものは、構造とか難しいことを考えずに、思いついたものを思いついた順に書いたほうが面白い文章になることも多い。この文章は、思いついた順に書いてるので、面白いかどうか別として、ちょっと論点ぼやけたよろしくない文章になってる。

最後に、いくつか参考文献。
文章に論理構造を反映させるというトレーニングならこの本。

新版 論理トレーニング (哲学教科書シリーズ)

あと、書く文章が教育的なものであれば、このあたりをちょっと目を通しておくといいかも。

インストラクショナルデザイン―教師のためのルールブック