文芸的文書作成検討ステーション
-.icon
0 はじまり
（だけどこの時点で「部品指向」という文芸関係ない要素入ってるなｗ（これが混乱の元か
ページには「本文」と「下書き」がある
文書作成ではなくプログラミングでたとえると、本文はcode:xxxブロック、下書きはそれ以外の部分
ページ一つ一つは文章部品になる
文書は文章部品からつくる
こんな感じなのが思い浮かんだsta.icon
つまり、
文書を部品単位でつくるという発想
部品は文芸的である（コンテキストを書いておくことができる）
-.icon
1
workspaceという単位（スクボでいうproject）を設ける路線で考えてみる
部品の（自グループ外への）共有方法などは今は考えない。いきなりここ考えると死んじゃう……
個人的には「〜〜で使われてます！」みたいな見せ方がしたくて、皆が部品を求めて彷徨う世界にしたいんだよ。SIをぶっ壊したいにも繋げられる。 単位と連携をどう設計するかがクソ難しい……
単位を細かくしすぎると連結がだるくなる
markdown見出しでいう###レベルを部品の単位にしたとする
##や#単位はどうやってつくる？
まあcompositeだよなぁsta.icon
次に出てくるのが
一つのアイデアは「埋め込まない」
たとえば文書とリンク集の二種類をサポートする
リンク集だけだときつい場合は連結表示もサポートすればいい Readonlyで展開したビューをつくる
で、編集したければ今見てるところから部品ページに飛んで、そっちで
いじって
反映したらまたビューに戻ってきて確認する
とか
連結表示の延長で文書出力も入れる
つまり連結表示には
ちょっと確認するためのビュー
HTML
PDF etc
A案件でつくった文書は、このやり方でつくったものであっても「PJ固有情報」が含まれる
そういうの含まれてる部品は共有できない
（上記ではいったん「考えない」にしてるけど）
一番愚直なのは「テンプレ」と「固有情報入ったもの」の二種類を用意すること
だが原始的なんだよなぁ
後者がサイロ化するに決まってる。テンプレが自然に整備されなくなるsta.icon*3
世の中は .gitignore 使ってリポジトリに機密データ入らないよう分離せい、という程度の分離リテラシーがない方がマジョリティでもあるsta.icon*2 別の案が「センシティブ部品」という扱いにして共有不可にする
……が、不吉な臭い。。。
Scrapboxで言えば「public projectに ”編集メンバーだけが見れるprivateなpage" もサポートしよう」みたいな話と同義！
案1: センシティブ部品共有時は「部品内のテンプレ部分」だけが抽出される
テンプレなるものをちゃんと定める必要性は出てくるけど……sta.icon
案2: センシティブマークがついてる行は抽出しない（特定文字列でマスキングするとか） 絵文字でもいいかもね。🔑とか🔒とか
部品名につけるのもアリ
---
いったんスキップ。センシティブという概念はないとみなすsta.icon
idリンクと部品名リンクはどっちがいい？
Scrapboxは名前リンク + 修正したら自動追従
今回は文書作成なので、スクボ側が正しいと盲信するのは危なそうsta.icon
いける気はするけどなー
というよりidリンクだとidを採番・管理する手間が生じるのが微妙（下手すれば足引っ張る）で、ここをクリアできる他の方法がないsta.icon*2
uuidみたいな採番を端折れる仕組みだと文字列くそ長くなるしな
部品があるとして、どう組み込んでいくか、で考えてみる（ボトムアップ思考実験）
ただの同期的埋め込み
タイトルを見出しとした同期的埋め込み
タイトルをテキストとしたリンクをはる
---
monolithic …… 1つの白紙にガンガン埋め込んでいくスタイル
箇条書き記法でリンク埋めるか、見出しつき同期的埋め込みで普通にモノリシックにしていくなどする
箇条書き特化+折りたたみも入れたのがいわゆるアウトライナー
composite tree …… 埋め込まれたページもまた部品として、別のページに埋め込んでいくスタイル
埋め込みがネストする。モノリシックではなくツリーになる
tree by indexer …… ある程度でかいページを「このように配置しますファイル」で配置するスタイル
本質的にはツリーだが、Compositeパターンではなくなっている
MkDocs（mkdocs.ymlでnav:を定義する）などドキュメンテーションツールは大体これ
別の言い方をすると、monolithicをn個用意したのを、配置しますファイルで配置指定する
ここから考えると？sta.icon
案1: 文芸的文書作成を「monolithicをつくる」と定める
つまり最終的な文書はindexerに任せるとして、そのindexerに与える部分までを文芸的にする
んー、最悪これだが、妥協したくねーなーsta.icon
composite treeみたいな階層ドキュメントは（もうこれでいいよねと強引に決めてしまわないかぎり）まず成立しない、Scrapboxはネットワークの可能性を教えてくれた
じゃあ文書自体も階層を超えた形で提供すればいいのではという路線
つくるのは「ツリー（目次）」ではなく「ネットワークグラフ（地図）」になるsta.icon
妄想だけど、編集者が目次見てうーんとか話すんじゃなくて、ネットワークグラフみて「ここにいくまでが遅いから、このワードを置いて2ホップで辿れるようにしたらいいじゃない？」みたいなこと喋るような世界になるんだよ？sta.icon*2
「体系化は傲慢の所業である」「人類はいつ気づくのであろうか」
この中に全部あるから。読んでいけば色々わかってくるから。含意や暗黙知もたぶん見えてくるから。
たぶんさ、縦スクロールのみの一次元モノリシックってのが固定観念じゃないの？
たとえば縦横に並べてもいいよね？
Kakauだっけ、二次元のアウトライナーみたいなの 同じ部品をn個並べてもいいよね？
案2か3のような脱Book的アプローチを推そうとしている（内心傾いている）俺氏sta.icon*2
俯瞰があるとして、どう埋め込んでいくか、で考えてみる（トップダウン思考実験）
どこからスタートするの？
白紙？
フリーライティングで列挙しつつ粒度整理して目次化するという、まあいつものシェイクになるよねsta.icon （わかりづらいけど、ここでいうシェイクは目次の大中小項目といった粒度を行き来するって話。本文まではまだ書いてない。いや書いてもいいけど目次決める段階でいったん捨てる）
で目次が決まったら、あとは（各見出しに対する）内容を埋め込んでいく
埋め込んでいく
紐づけていく
ありきたりだが「目次をつくる」「内容をつくる」に分離できる
トップレイヤーとボトムレイヤーと呼ぼうsta.icon
---
トップレイヤーアプローチ
シェイク …… 目次をアウトライナーでしこしこいじる
KJ法的 …… 付箋洗い出した後まとめていく（が、n人で、しかもアイデア以外も扱うのでなんちゃってになる）
QAAP …… Quesiton, Answer, PoolのうちQuestion洗い出す部分 ボトムレイヤーアプローチ（たとえば「第一章第二節」の中身を埋めるとした場合）
普通に書く(monolithic) …… 普通にガァァッと書く
部品化アプローチ …… たとえば項単位の部品n個をつくってこれを連結する
文芸的アプローチ …… 本文の他にメモも入っている（文書時に使われるのは本文だけ）
メシングアプローチ …… 乱雑に散らかったnの作業空間があってこれらから拝借する 文芸的文書作成を部品で捉える
文書
部品
部品
部品
部品
部品
部品
……
テンプレートの考え方
使いまわしの考え方
重複をつくらないという考え方
ただし重複しても良いなど最近は「別に重複してもええで」が主流（in sta.icon） インタフェース（ダックタイピングでもいい）の考え方
仲介者の考え方
factory
生成処理を追い出して独立させる → ？
adapter
使いにくいものを覆い隠して使いやすいインタフェースを用意する → ？
実力者が出してくれた下手な言語化をアダプトするとか？sta.icon
decorator
Aを扱う能力abilityAを持つBやCを用意し、AはBやC経由で使えるようにする → ？
decorator覚えてないので解説sta.icon
これにより事実上Aを拡張できる
～～をつけたいなぁと思ったら、～～をつけるBをつくればいい
facade
複雑な処理を覆い隠して「単一の」窓口を用意する → ？
CoR
処理Aを行うマンを数珠つなぎにしておいいてそいつらに渡す → ？
解説sta.icon
数珠つなぎされるマン一人は「次の奴に渡す」処理と「もし俺が処理できそうならする」処理を持ってる
こういうマンをn人つなぐ
こうすることで「俺は無理だわ、次」「俺も無理だわ、次」「あ、俺できるで」みたいな流れ作業的に処理を任せることができる
observer
更新されたら通知する → ？
---
んー、別に浮かばないな
文芸的文書作成時のプロセス（あるいは役割とその連携方法）をつくるのにはまあ役立つとは思うけど
つかさ、便利概念全部ぶっこんでまとめればいいんじゃない？ｗ
一般用語定義レイヤー、独自用語定義レイヤー、説明レイヤー、内容レイヤー etc
まあこれは「ふーん」でいいや
-.icon
2
1 ここまで出てきた概念をまとめる
文芸的に文書作成したい
部品を組み合わせる世界観で文書作成したい
wide monolithic
wook
リスト縛りの文書
QAAP
メシング
2 分類する
文芸的文書作成
文芸的に文書作成したい
wide monolithic
wook
QAAP
データ構造的縛りを加える
部品を組み合わせる世界観で文書作成したい
リスト縛りの文書
乱雑なデータソースという思想
メシング
-.icon
3
文芸的以外の文書作成も混ざってるからややこしくなる。
いったん文芸的つまりコンテキストの共存について考えるとしたら？
考えることは単純だよな
本来本文だけを書くわけだが、そうじゃなくて本文とコンテキストを一緒に書けるようにする
そのような概念と仕組みを考える
つってもなー、イメージ湧かねえ……
スクボprojectみたいなフリーフォーマットで「文書つくれる "本文とコンテキストが混ざった書き方"」のイメージが全く湧かない
かなーりルール定めに行かないと無理では？
上手い塩梅を探さねばならない
rashitaさんのは？
力技だった（普通の執筆のやり方をScrapboxでやっただけ）sta.icon
が、当時の時点でコンテキストも書けるよねみたいなこと言ってて先見感さすが
そうだった、アプローチは3つあるんだったね
writer based …… 文章作成ツールに「コンテキストを書く」能力を付与する
memo based …… コンテキストを書くツール（メモツール）に「文章をつくる」能力を付与する
double layer …… 文章作成ツールとコンテキスト書くツールを両方使い、各々のデータを紐づける
「文芸的」の定義、というか性質も定義した方がいい気がする
文芸的XXとは、XXを「"XX" と "コンテキストのメモ" が混ざった単位」だけでつくること？
この場合、「コンテキストのメモ」をベースにXXをつくれればいい、みたいなことは成立しない
コンテキストのメモ（の集合）Mがあるとして、sta.iconはMからXをつくり、アイラ.iconはMからYをつくるかもしれないが、こういうのは無し
Mからは常にX（Yでもいいが）がつくられねばならない、みたいな関数的性質
プログラミングでは「yes」にする（しかない）けど、文書だとどっちがいいんだろうなーsta.icon
文書なので自動化する必要性はないんだよ
文章は機微のあるものなので自動化前提にしていいわけでもないんだよ
だからこそ迷う。つか答えわかんね現時点では。何もsta.icon
これを冪等性と呼ぶことにする
---
冪等性を前提としない場合、以下のような半々的アプローチもできる
MからX'を生成する（ここは冪等）
X'から「人の手で」Xをつくる（ここは個性が出る
つまり「中間結合物をつくるところまでは自動化する」けど、その先は人の手を使うようにするsta.icon
本文SとそのコンテキストCがあるとする。両者の紐づけはどうあるべきか？
SからCへの関連が設定されている
CからSへの関連が設定されている
多重度は？
1つのSに対してCは何個？
1つのCに対してSは何個？
---
SとCが一緒の場所に書き込まれている、という方向性もある
シングルレイヤー案
ストーリー性はなくてもよい？テーマはなくても良い？メッセージは？
仮にグランドメッセージと呼ぶことにする
あるいは「明示的につくりにいかなくても宿るよ」というパターンもありそうsta.icon
---
3パターンあるね
グランドメッセージを明示的につくる
グランドメッセージは暗黙的につくられる
グランドメッセージなんていらねえよ
「文書」の定義も必要
いったんNoにしておこうsta.icon
うーん、結局「読み物性」を残すか、殺してもいいかとも言えようsta.icon*2
仕事だと「この仕事のこの文書はこういう形式であるべきだ！」という信念となって出現する
文書の目的は何か
書きたい人が楽をするのか
読みたい人が楽をするのか
読みたい人に「体験」を楽しんでもらうのか（ないしは体験がないと読めない雑魚を想定するのか）
本文にステルスな（メモレイヤーへの）出入口を埋め込む？
ダブルレイヤーのバリエーション
ダブルレイヤー案
直感だけど「それだ！」な組み合わせがある気がした……sta.icon
用語
普通のテキスト …… wordでもmarkdownでもなんでもいいが普通に文書を書くこと（見出しは使う（ゆえに目次ができる））
monolithic text …… 普通のテキストのうち「1ファイルに全部書く」タイプのもの（特にプレーンテキストで書く系）
アウトライナー …… ここではストイックな箇条書きフォーマットのこと
---
本文レイヤーは普通のテキストで、メモレイヤーはアウトライナー
で、本文レイヤーのキーワードやフレーズから、メモレイヤーのlevel1にリンクする
たとえばmarkdownというキーワードにリンクする
memolayer
markdown ★ここにリンク
……
……
他のlevel1にもリンクできる
memolayer
markdown
……
…… ★1 この辺から2にリンクしてもいい
ドキュメンテーションビルド ★2
……
要するに解説ページがアウトライナーで整理（というか情報が放り込まれている）されている
メリット
アウトライナーなので情報を放り込みやすい
主要なキーワードに情報を集める、という運用にしやすい
デメリット
何でも放り込まれるので混沌としがち or 何書けばいいかわからなくて尻込みして書き込まれないがち
結局階層的整理の限界や問題に突き当たる
上手く雑に放り込んで「とにかくこの中にあるよ！」できればいいんだが、たぶんできない（下手に整理したがるやつが出てくる）sta.icon
本文レイヤーは普通のテキストで、メモレイヤーはネットワーク系メモツール（≒Scrapbox）
で、本文レイヤーのキーワードやフレーズから、メモレイヤーのページにリンクする
メリット
メモレイヤー側の表現力が高いし、整理コストも小さい
デメリット
読み手にメモレイヤー（のネットワーク世界）を辿るリテラシーが要る
書き手にネットワーク世界に則って書くリテラシーが要る