マルチチャネル・テキスト処理

ワープロの古典的な時代、テキストは MS Word とプリンターのあいだで生まれていました。いまやテキストは複数のデバイスやアプリで書かれ、編集され、メールされ、印刷され、コピーされ、貼り付けられ、注釈を付けられ、公開され、RSS で流され、共有され、再共有されます。あらゆるツールやプラットフォームを使う、このせわしない新しい環境では、頑固な独自ファイル形式はうまくいきません。プレーンテキストのほうがましですが、リッチテキストの書式機能はありません。Markdown は私たちの金の銃になれるかもしれません。もっとピカピカに見えさえすれば！

では、リッチテキスト、プレーンテキスト、Markdown¹ は、この多様な執筆環境でどんな強みと弱みを持つのでしょうか？

1. リッチテキスト

MS Word や .rtf のようなリッチテキストは、WYSIWYG（見たままが得られる）の約束で有名です。太字、斜体、別のフォントや書式を使えるし、その結果が画面にそのまま見えます。登場当時、それは「Reveal codes」ベースの面倒な書式設定や、そもそも書式がない世界に比べて革命でした。ですが欠点もあります。

プレーンテキストでは、テキストそのものがソースです。リッチテキストでは、私たちはシミュレーションを見ています。目に見えるものは心地よいかもしれませんが、その下でワープロはもっと複雑なテキストをコードとして密かに組み立てています。Pages や Word で文書を作り、「Hello World」と入力して保存し、拡張子を .zip に変えて解凍してみれば、この隠れた世界をのぞけます。ようこそ 1979 年へ！²

できあがったフォルダをのぞく勇気があるなら、自分が入力したのは “Hello World” だったのか、それとも “Hello Hell” だったのか、考え始めるかもしれません。

独自形式はプレーンテキスト形式より重いのです。独自形式の最大の問題は、ソースコードとテキスト、つまり見えるものと見えないものの関係が気まぐれだということです。2016 年にこれらの形式を使うと、実際にはこうなります。

バグと UX のトラブル

リストから抜けるには？ インデントを消すには？ 単語のリンクを外すには？ 太字や行間やタイトルサイズを消すには？ そもそも、どうやって写真を 2 枚横に並べるのか？ ときには、バグなのか UX の悪さなのかすらわかりません。

コピーパスタチュッタ

マルチチャネル公開環境における独自形式の大きな難題は、コピー＆ペーストを壊してしまうことです。PDF から 1 段落をコピーしてメールに貼り付けると、英語の文章がイタリアのスパゲッティ・ウエスタンに変わり、大げさなスペースや改行だらけになります。しかも PDF だけの話ではありません。書式付きテキストでは、貼り付けたときに何が出てくるかわかりません。

互換性

.rtf はかなり定着していますし、多くのワープロは .docx を読めますが、アプリによってこれらの形式の解釈は異なります。RTF や Docx のテキストを CMS に確実に入れることはできません。CMS と Word 文書を行ったり来たりすることなんて、もう忘れてください。

分岐

書き出しは「ワンクリック」かもしれませんが、テキストが複数の版に分岐するとワークフローは複雑になります。フィードバックや別案の編集を、ひとつのマスターファイルに簡単に戻すことはできません。版管理はあっという間に悪夢になります。

アクセシビリティ

リッチテキストでは、文書のソースそのものには触れません。テキストはファイルのふりをしたフォルダの中にあるのかもしれないし、「ユーザーから安全な場所」と称するどこかに隠され、スパゲッティコードの入れ子フォルダの奥深くに埋もれているのか、秘密のデータベースというフォートノックスに暗号化されているのかもしれません。

もちろん、bizdev の立場なら独自形式の金の手錠が大好きでしょう。ですが、2016 年にさまざまなアプリ、デバイス、プラットフォーム、形式を使って文章を書く普通の人にとっては違います。.docx を 10 年後にどう感じるか、30 年後にどう感じるかなんて、誰にもわかりません。

いまのワープロは、グラフや表や画像を追加したり、高度な書式設定を適用したりと素晴らしいことができますが、ひとつだけできないことがあります。今日私が書いた言葉が、10 年後にも読めると保証することです。それが、私がプレーンテキストで作業するのを好む理由のひとつです。時代を超えるからです。私が今日作るテキストファイルは、.dotx ファイルが何なのか誰も思い出せなくなったずっと後でも、孫たちが読むことができるでしょう。³

今日のマルチチャネルなテキスト環境では、リッチテキストのファイル形式は、昔よりもさらに多くの壁を作ります。ファイルを開くのに、ある OS の特定バージョンで、あるアプリの特定バージョンを入れなければならない、という考えは冗談のように聞こえます。アプリやプラットフォームをまたいで共有できるようにするには、テキストそのものがアプリ、プラットフォーム、デバイスの束縛から自由でなければなりません。

2. プレーンテキスト

どこでも期待どおりに動く唯一のファイル形式は、ファイル形式がないこと、つまりプレーンテキストです。そして、最初の下書きを書くにはそれで十分です。

プレーンテキストとは、単語がスペースで区切られ、文がピリオドで区切られ、段落がたいてい 1 行の空行で区切られたものを意味します。執筆の仕事に携わる人なら、出版でも脚本でも、それだけで足りることが多いのです。⁴

プレーンテキストはわかりやすい。言いたいことに集中させてくれます。

プレーンテキストは無料です。TextPad、TextEdit、Vim、携帯電話、1997 年の AOL メールアプリでもいい。ジャケットは要りません。

プレーンテキストは軽い。

プレーンテキストは水のように流れます。でも水と違って、どんな喉の渇きも癒すわけではありません。印刷物でも、ブログ記事でも、PDF でも、メールでも、あるいはファクスでさえ、最終的には、そのテキストは読めるように媒体に合った形を取らなければなりません。言葉が媒体の中で形を取るにつれて、視覚的な構造が必要になります。ビジネス資料にはヘッダー、フッター、表紙が必要です。文章の中には、画像や動画、表で豊かにしないと生きてこないものもあります。オンラインで書くならリンクが欲しい。ホワイトペーパーには脚注が必要です。

プレーンテキストから書式付きテキストへの移行は、これまで一般に急激で、元に戻れないものでした。TextEdit や Notepad で書いても、RTF、Docx、HTML に移ったらもう後戻りはできません。けれど、テキストは自然に、ただの言葉から書式付きの散文へと少しずつ変わりたがります。そこで Markdown の出番です。

3. Markdown

Markdown、MediaWiki、LaTeX のようなマークアップ言語は、プレーンテキストの下に見えない王国を作らずに、言葉を構造化できます。残念ながら……。

3.1 Markdown はひどい！

Markdown で書いたり Wikipedia の項目を編集したりして、嫌になった ことがあるかもしれません。「ボタンひとつで書式設定できて、結果もそのまま見えるのに、なんで新しい『構文』なんか覚えなきゃいけないんだ？」と思ったからです。⁵ そして、その通りです。

• マークアップで書けばコピペの問題はある程度回避できますが、素の Markdown はどうしても散らかって見えます
• Markdown は HTML より簡単ですが、それでも構文を覚える必要があり、リンクの追加方法を毎回調べるのは流れを途切れさせます
• マークアップ、Markdown、MultiWhatever…… これらの形式にも独自の互換性問題があります

Markdown は、すべての書き手や、書くあらゆる形態・段階に対する完璧な解決策ではありません。でも、メモ取りから公開まで全部自分でやるなら、いまのところ最も効率的な解決策です。出版社が使う道具を指定するなら、Markdown の出番は少なくなります。とはいえ、従来のファイル形式より共有しやすいという点は、共同作業をかなり滑らかにしてくれるかもしれません。

3.2 Markdown へのお願い

見た目の好みはさておき、太字 と 斜体 だけなら Markdown は無敵です。見出しごとに # や ## や ### を打つのは不格好に見えるかもしれません。でも、一度覚えてしまえば、ハッシュ記号を打つほうが、キーボードから手を離してマウスポインターを探し、テキストを選び、Headline の WYSIWYG ドロップダウンをクリックして、適切な見出しレベルを選ぶより速くて簡単です。しかも、あの気難しいスタイル形式と違って、ハッシュ記号はいつもきちんと振る舞います。

この 3 つ、*、**、# を知っていれば、Markdown を始めるには十分です。そして Markdown がうまくなるほど、執筆全体の摩擦は減ります。もう少し難しい課題を見てみましょう。

リンク

Markdown のリンクは、文章の見た目を台無しにすることがあります。リンクが文章の中にそのまま見えて、右クリックやポップアップをいじらなくていいのは助かりますが、文章中にリンクを多用するとひどいことになります。回避策のひとつは参照スタイルのリンクを使うことです。もうひとつはエディタ内でリンクを折りたたむことですが、そうするとリッチテキストの欠点がまた戻ってきます。

マルチメディア

文章の中で画像をもっと自由に扱えるのは気持ちいいものです。画像のレイアウトをうまくやってくれるプログラムが欲しいなら、InDesign を使うか、CMS でやってください。Word に頼らないでくださいし、Markdown エディタに文章を書き出す以上のことまで期待しないでください。もちろん、InDesign で Markdown を使うこともできます。⁶

表

プレーンテキストの表には悪評があります。複雑なら確かに見苦しい。でも、少数の行と列ならうまく使えます。Word と違って、何が起きているかがそのまま見えるからです。（高度な表を扱うなら Word はそもそも敵です。Excel か Numbers を使いましょう。）作るのは面倒ですが、少しの魔法があれば……。

自動化

MultiMarkdown⁷（Markdown の強化版）を使えば目次を自動生成でき、メタデータ変数を使えば差出人テンプレートさえ組めます。かなり本格的に聞こえますし、実際に本格的です。でも、ぜひ 試してみてください。基本を理解するのに ninja rockstar hacker である必要はありません。しかも基本を理解してしまえば、MS Word よりも MultiMarkdown で目次を作る ほうが簡単になります。

脚注

MultiMarkdown には脚注もあります。構文はリンク同様ややわかりにくいですが、リッチテキストエディタでも同じように厄介です。ただ、プレビュー付きの Markdown エディタ なら、クリックしながら構文を学べます。

Markdown をよりよく使えるようになるほど、プレーンテキストと書式付きテキストを行き来するのは速く簡単になります。そこが Markdown の強みです。プレーンとリッチテキストの 橋渡し をし、最初のランダムなメモからマルチチャネル公開まで、テキストを継続的に形にできます。

ライブレンダリング

Markdown の表示をよくする方法として折りたたみなどがありますが、もしその場で WYSIWYG っぽくレンダリングしてしまうと、リッチテキストエディタを時代遅れにしている問題をすべて再導入するうえ、さらにいくつか新しい問題まで加わります。Word が WYSIWYG のない言語の上でやっていることを Markdown で全部やろうとすると、結局 WYSIWYG 向けではない言語の上に Word を作り始めることになります。だから iA Writer は Markdown の記号を隠さないのです。

4. 現代的なワークフロー

執筆プロセスのさまざまな段階を、制御可能な別々のフェーズとして、時間順に並べられるものだと想像しがちです。実際には、私たちは書く前にメモを取り、それでも公開直前まで素材を集め続けます。編集は初稿から始まり、デジタルメディアに限らず、公開後まで続きます。⁸

創作プロセスの段階を分けることは必要ですが、柔軟なワークフローは滝ではありません。段階は重なり、相互作用し、相互に影響し合います。私たちの執筆・公開ツールは、好きなように前後できるようにすべきです。⁹ 書くことは、もともと少しやんちゃなのです。

集中して書くとは、目隠しをして書くことではありません。プロセス全体のうち、ある一面に主な注意を向けることです。隣り合う 2 つの段階を意識的に行き来するのも有益です。Markdown があれば、境界を気にしなくてよくなります。

4.1 書いてプレビューする

工程のあいだを行き来するのは必要で、しかも気分を新たにしてくれます。WYSIWYG エディタで作業するのが好きな人、時々テキストを印刷する人、公開前にブログで定期的にプレビューする人なら、もう知っているはずです。明確な書式は、読者の視点で文章を見る助けになります。印刷された文章を見ると、私たちの受け取り方は変わります。Markdown から離れて HTML プレビューのレンダリング結果を見ると、同じような効果が得られます。

その効果は画面から印刷物へ飛ぶほど劇的ではないかもしれませんが、これから形になる文章の輪郭を垣間見せてくれます。読者がどう見るかを感じたうえで、あらためて自分の文章に向き合うことができます。手書きの修正を打ち直す面倒な時間のかかる作業を省けるので、こちらのほうがずっと速いのです。

プレーンテキストと書式付きテキストを意識的に切り替えることで、外から見たとき文章がどう読まれるかを想像できるようになります。

プレーンテキストと書式付きテキストを意図的に切り替えることで、外から見たとき文章がどう読まれるかが見えてきます。

4.2 編集して公開する

同じ視点の切り替えは、文章をフロントエンドとバックエンドの表示で行き来するときにも起こります。つまり、コンテンツを CMS に移したときです。

すでに Markdown で書いているなら、公開ツールが書式を失わずにプレーンテキストを編集できるようにしておきましょう。Markdown ベースの CMS に全面移行する必要はありません。WordPress を使っているなら、エディタに Markdown プラグインを入れればいいのです。最初から複数のプラットフォームへの投稿を支援する執筆アプリを使っていると助かります。だからこそ iA Writer は WordPress と Medium に直接公開できるのです。

執筆アプリから直接公開できるのは気持ちいいことです。ただ大事なのは、作業を失わずにテキストを前後にコピー＆ペーストできることです。コピー＆ペーストは、たくさんのボタンを押すより速いことがよくあります。ワークフローの達人でない限り、InDesign、WordPress、.Pages で最後の仕上げを加えることは避けられません。ワープロではできないことをさせてくれない公開ツールに、何の価値があるでしょう？

結論

私たちは、ノートを取るために異なるデバイスを使い、下書きや編集には別のアプリを使い、テキストを他人に送り、言葉の形を整えて公開するために別のプラットフォームを使います。制作プロセスと、テキストの最終形は、以前よりも計算しづらくなりました。今日の複雑な書式設定と公開の現実に対処するには、定まった形式／アプリ／プラットフォーム／デバイスの枠に閉じ込める従来のテキスト形式以上のものが必要です。

普遍性と単純さのおかげで、プレーンテキストはどんなファイル形式よりも先へ連れていってくれます。それでも、プレーンテキストエディタは、テキストを視覚的に構造化したり、複雑なレイアウトを最適化したり、詳細なタイポグラフィをいじったり、テキスト本体を相互リンクしたりするようには作られていません。適切な言葉を見つけるには最適ですが、テキストが長くなるほど弱くなります。現代的な執筆プロセスには、プレーンな言葉と書式付きテキストを、じっくりしたワークフローやコピー＆ペーストを通じて自由に行き来できることが必要です。

いまのところ、それを可能にするのは Markdown のような軽量マークアップ言語だけです。Markdown は少し散らかって見えるかもしれませんし、もちろん、改善の余地も必要もたくさんあります。欠点はあるものの、従来の「プレーンな言葉」と「書式付きテキスト」の分離がうまくいかない複雑な方法論的問題を解決してくれます。デバイス、プラットフォーム、アプリに依存せず、テキストとその中に埋め込まれたファイルをどこでも使えるようにしてくれるのです。テキストとスタイル、パッケージと内容、本体テキストとレイアウトのあいだを移る瞬間は、二度と戻れない一点であってはなりません。自由に行き来できる段階であるべきです。Markdown はそれを可能にします。

リンク、画像、脚注、TOC のようなより複雑な書式が欲しいなら、UI かショートカットを使ってください。より高度な構文で Markdown の腕を上げたいなら、ライブプレビュー付きのテキストエディタに助けてもらいましょう。そうすれば、書式がどう見えるかを早い段階で垣間見られ、すぐにミスを見つけられるので、より複雑なマークアップも使いやすくなります。

クラウドサービス、メモアプリ、テキストエディタ、公開環境のあいだの自動化は便利ですが、必須ではありません。本当に 必要なのは、書式や情報を失わずにテキストを行き来できることです。それを保証するのはプレーンテキスト形式だけです。公開プラットフォームが Markdown を解釈するように設定して、Writing、Editing、Publishing のあいだを自由に移動できるようにしましょう。その方法やアプリはいくつもあります。そして、それこそがポイントです。プレーンテキストは軽く、無料で、そうあり続けるべきなのです。プレーンテキストを手枷にはめようとするアプリは避けましょう。