「構造化文書の作成術」と上段に構える

構造化文書」について考察を述べます。

といっても、ここで述べる「構造化」は論理思考のような高尚なものではありません。それは、よそで勉強してください。

その昔、「SGMLStandard Generalized Markup Language)」というキーワードがありました。文書の構造やデータの意味などを記述するマークアップであると定義されています。約束した構造ルールからはみ出ているかをチェックするために「DTDDocument Type Definition)」という記法の定義文が不可欠になります。

違う言い方をすると、このDTDという「」がなければ「SGML」文書とは言いません。

アメリカでSGMLが定着したのは、彼等はビジネス文書を構造的に書くことを前提にしていることを上げることができます。

同時に業界として「DTD」を共有すれば、どこの企業が作成した文書であっても、全く同等のデータ価値としてあつかうことができるわけです。

そこで「Frammaker」というDTPソフトが使われることとなります。この「Frammaker」では「EDDElement Definition Document)」というDTDで定義された構造に対して書式を定義しておくことでレイアウトとして展開することができるという仕掛けです。

例えば、自動車企業が部品を調達するとして自動車工業会が決めたSGMLとDTDで仕様を記述して納入業者を募集すると、その仕様に応じた部品の価格を提示することで、即座に納入業者を選定することができるわけです。

つまり、構造化文書とは、「データ」そのものであると言えるわけです。

データ」であるということは「デジタル」であるとも言え、「」であるとも言え、「客観」であるとも言えます。

翻って日本の一般的文書は「アナログ」であり、「」であるとも言え、「主観」であると言えることとなります。

世間では「DX」を盛んに標榜しますが、手書きであれwordやExcelであれPDFにすることが「DX」の主流を占めている感がありますが、ワードクラフトでは文書を構造的に作成することが「データ化」に直結していると考えています。

やっと本題

SGMLが定着しなかった日本の産業界ですが、それは産業界だけにとどまることではなく、大げさに言うなら「日本文化」が底流にあるような気がしています。

マニュアルの構造化記法として「DITA」というのがあるとのことで、ある大企業が社内のマニュアル類をシンガポールで億円使って「DITA」にしたという話を随分前に耳にしたことがありますが、産業界に浸透しているのかは不明です。

外資なら経営陣にそうした発想があるのでしょうけれど、日本の大企業の経営陣は「お年寄り」が多いようにも見受けられ社内文書の改善よりもご自分の健康への気遣いが忙しいのではないでしょうか。

以前に学習参考書の問題作成システムを作ったことがあります。そこではAdobeのInDesignの機能で書式付きテキストの「snippet」に分解して組み立てるという発想で作りました。

唯我独尊で「素晴らしい」と思っていましたが、世間的にはどうと言うこともありませんでした。

そこで、構造化文書を「MS-Word」で作ろうという話です。そこから構造化したテキストファイルにすることで、いちいち、Word文書やPDF文書を閲覧する必要が無くなるわけで、マニュアルや規定、手順書などでは絶大な効果があると言えます。

スタイルは「標準」を変更してフォントは「メイリオ」、文字級数は「11」。

他のスタイルとして「表題」「副題」と「日付(見出し4)」「宛名(見出し5)」「著者(見出し6)」。

および、本文中に使うスタイルは「章(見出し1)」「節(見出し2)」「項(見出し3)」ぐらいにしておきます。

階層は3階層(見出し1~3)に収まるような文書作成を心掛けます。

無意味なインデントはしない。インデントするならスタイルに定義する。

上記の例は本の要約ですが、仕様書にしろ、マニュアル(手順書)にしろ、3階層を心掛けスタイルを充てることが、ワードクラフトで言うところの文書作成の「構造化」になります。

文字級数やボールドはスタイルに定義して統一するようにします。

思考法だったり、因果関係だったりのような面倒な(根源的な)話は、ネットにたくさん出ていますので、それらを参照してください。

文書を作成するときに「章見出し」「節見出し」(まれに「項見出し」)に本文を書く。本文は「。(読点)」で改行する。1改行(段落:パラグラフ)には一つのことしか書かない。

これがワードクラフトの「構造化文書」になります。

なにをどのように書くかは、書いているうちに工夫すればいいように思います。

上記の表に類する表は、世の中に珍しくなく使われています。縦、横自在に接合したりしています。これをデータ化するとなると画像にするぐらいしか方策はありません。

表は本来、横1行が1レコードであって、それを集合としたものが「」になるはずのものです。よって、横1行になるように心掛けることが重要です。

さらに文字に色を付けたり、背景となるセルに色を付けたり、挙句には意味もなく文字級数を見た眼で変えたりすることは、およそ意味のないことだと思います。

オヤジらが初めて使うワープロレベルの「見た目」で作る文書や表をそろそろやめる時期に来ていると思いますが、いまのオヤジが一掃されるまではなかなか変革が起きそうもありませんし、若年世代はスマホ重用世代でしょうから、一足飛びにパラダイムがシフトしそうです。

組織文書はデータ資産であり、データ化できない文書は保存価値の少ない文書だと認識しなければ、ここから先の競争社会において厳しくなっていくのではないかと憂えています。

なんでもそうですが、まず、形から入るのが近道と思います。そのうち、見出しに応じた文書の書き方に変わってくるだろうと楽観しています。

組織文書の構造化とは、Wordで「見出し1」~「見出し3」までを階層をイメージして作るようにすることと思ってください。違う言葉で言い表すならば「」「」「」のような階層を意識して文書を作成するために、Wordの「見出し1」~「見出し3」までを階層にあてはめて文書作成に取り組むことから始めるのがいいと思います。

Word・ExcelからMarkdownにする意味

Wordから「見出し1~3」を使ってMarkdownを経由させてHTMLにすると「見出し1~3」が、それぞれ<h1>から<h3>のタグに展開します。

ここが構造化の第一歩となりますが、PDFのほうが便利と言う人には残念ながら伝わらない話でもあります。

構造」とは「意味」になります。

表現としては「約束」「ルール」と言うことです。

文字を赤や青にするには、意味が必要で、その意味に応じた書式のルールを作ることになります。

文字の大きさも同様で、思い付きで大きさを変えたりすることは禁じ手で、約束を離れて加工する際に「思いつき」「気分」「主観」にこだわる限りアナログで修正することになります。

そこにコストをかけるだけの意味があるのであれば、それに応じた約束をつくるのが正規の構造化になりますが、ルールが多くなると、いずれは守られなくなるので「デジアナ」は回避できないことと考え、SGMLのDTDやDITAのような小うるさい小姑のような文書作成術ではなくWordの「見出し1~3」で構造化文書を作るのが現実的と思います。

組織の集合知としては、属人化することは避けられませんが、暗黙知に依存しすぎることなく、可能な限り文書化して組織内の「」を蓄積し、共有することで、競争優位を着実に実現していく有効な手段になるはずです。そのためにはルールと体系が不可欠になるわけで、そこがちゃんとしているか、していないかが企業の発展に大きく関わってくるものと思われます。