Textboxについて 構造編
Weekly R-style Magazine ～読む・書く・考えるの探求～ 2021/11/08 第578号
○「はじめに」
ポッドキャスト配信されております。
今回は、メモの扱いについてさまざまな話をしました。よろしければお聴きください。
〜〜〜広告費の謎〜〜〜
スマートフォンでゲームをしていると、よく動画の広告が流れます。途中に突然流れるものもあれば、何かしらのメリットと引き換えに動画の視聴が要求されることもあります。どちらにせよ、20秒程度の短い動画です。
しかしながら、「広告動画が表示される」と予測できると、それを表示させたままスマートフォンから目を離して別のことをするのはいつだって可能です。テレビを見たり、iPadでタイムラインをチェックしたりという「脱線」ができてしまうのです。
でもって、そういう風に動画広告とつき合っている人は多いのではないでしょうか。
そうすると、そうした広告動画はユーザーのパケットを消費している以外に何も成していないことになります。一方で、ここまで動画広告が飛び交っているのですから、そこには少なくない「広告費」がかかわっているのでしょう。
それって実に不思議なことです。
〜〜〜7wriner〜〜〜
4年前に自作した7wrinerというツールがあります。そのツールをカスタマイズしてくださった方がいらっしゃいました。
◇7wrinerを自分好みの見た目にしてみる - のらてつ研究所
ものすごくモダンな感じになっています。というか、もともとのバージョンが簡素すぎましたね。自分でも少し整えたくなりました。
そのついでに、JavaScriptのソースもちょっと「読んで」みてびっくりしました。なんというか、非常にダサいのです。混乱しているのがモロにうかがえる状態になっています。スマートな書き方ではなく、「こういう機能が欲しい、よし実装だ！」という思春期の男子高校生のような直接的な書き方をしていて、構造的整理がほとんど為されていません。
そうなると、既存の機能を「改修」したくなっても、どのように手を入れていいのかがさっぱりわからないのです。
すでに動いているコードの「整理」を行う行為はリファクタリングと呼ばれますが、そういう「直接的に何か生み出すわけではない」作業を行っていないと、そこからの大きな展開が不可能になる、というよく知っている知識を改めて実感しました。
でもって同じことは知的生産活動においても言えるだろうと予想します。
〜〜〜使途不明メモ〜〜〜
書き留めたメモの処理をしていたら、「ストア哲学とテクノロジー」というメモと遭遇しました。笑ってしまうくらいに大きなテーマのメモです。
で、こうしたメモは扱いが難しいものです。本のタイトルなのか、章題なのか、研究テーマなのか、何かのフレーズなのか、エッセイのタイトルなのか判然としません。というか、そのどれでもでありうる可能性が秘められています。
だからこそ、簡単に「位置づけて」終わりにはしない方が良いのでしょう。頭を使うとしたら、このタイミングです。
〜〜〜手抜きのタスク管理〜〜〜
社会生活を送る上で、何かしらのタスク管理を行っておくのは有効です。でなければ、さまざまな不義理が発生してしまいますし、タスク管理を行っていることで達成できる「生産性」もあるはずです。
一方で、最高の生産性を維持するために最大限のタスク管理を行う、というのはちょっと危うい感じがあります。なぜなら、ものすごく忙しくなったときに、「管理のための手間」がかけられなくなるからです。そうなると、すべてが機能不全となり、「ただやるだけ」という状況になりかねません。最低限必要であるはずのタスク管理がゼロになってしまうのです。
そのように考えると、「むちゃくちゃ忙しくなっても最低限これだけはできる」という手間で維持できるタスク管理の方が、タスク管理を中長期的に維持する上では役立つのかもしれません。あるいは、二階建てバスのように「最低限の一階」と「余裕があったらの二階」に分けておいて、めちゃくしゃ忙しくなったときは一階だけでも実行する、という二段構えならば対応力は広がるでしょう。
もちろん、「そんなにむちゃくちゃに忙しくなることを避けるのがタスク管理なんだ」という理念を持つことはできますが、そうはいっても忙しくなってしまうことはあります。そういう状況も踏まえておくことが、個人的には良いマネジメントだと思います。
〜〜〜最高の生産性〜〜〜
原稿を書いているときに別の何かを思いついたり、何か調べものをしているときにひらめいたことがあったりすると、そのままScrapboxにページ作ることがあります。
新規ページを作成し、タイトルをつけ、本文を書く。そうした「脱線」をしているときは、モチベーションアップの秘策など何一つ使わなくても、完全に集中できています。気が他に逸れることもなければ、疲れで書けなくなることもありません。たぶん、時間当りの文字数で言えば、最高の生産性を誇る時間でしょう。
これは実に面白い話です。「やりたいことをやっているときは、最高の生産性を出せる」というのは、逆に言えば、最高の生産性が出ていないならば「やりたいことではないことをやっている」と言えるからです。
しかしながら、毎日書籍原稿を書いているなら、ときどき「今書いている原稿について書きたい気分ではないのだけども」という日はあるでしょう。その「気分」を乗り越えて、毎日着手するからこそ生まれる進捗というのはたしかにあります。ここがバランスの難しいところです。
ちなみに、ニクラス・ルーマンは「気乗りしないことはやらない」というポリシーで研究を進めていたようで、ようは常に上の「脱線」状態を維持していた、ということでしょう。それはたしかに、高い生産性を誇れるはずです。
一方で、このやり方の場合、「締め切りに間に合わせるように原稿を書き上げる」ということはなかなかできません。これが現実的な問題になってくることがあるのが厄介です。
〜〜〜中根千枝さん〜〜〜
社会人類学者の中根千枝さんがお亡くなりになりました。
◇社会人類学者 中根千枝さん死去 94歳 | おくやみ | NHKニュース
代表的な著作である『タテ社会の人間関係』は、KBR（倉下・ブックス・ランキング）の上位に入るたいへん面白い本です。しばらく執筆が止まっている『僕らの生存戦略』（仮）においても重要な位置づけを占めています。
なかなか言葉にしづらい感覚ではありますが、『僕らの生存戦略』（仮）を書き上げよう、という思いが強まりました。これは来年の主要なテーマになるかと思います。
タイミング、というのは非常に重要な要素ですね。
〜〜〜Q〜〜〜
さて、今週のQ（キュー）です。正解のない単なる問いかけなので、頭のウォーミングアップ代わりにでも考えてみてください。
Q. 一番「生産性」が高いタイミングって、どんな状況でしょうか。
では、メルマガ本編をはじめましょう。今回はTextbox話の第二回をお送りします。
○「Textboxについて 構造編」
前回は、Textboxの基本となる機能を紹介しました。簡単に復習しておきます。
・実体は単なるindex.htmlで、Webブラウザから自分のローカルファイルを閲覧できる
・閲覧できるのは拡張子がmdのテキストファイル
・ファイル内のリンクから別のファイルの閲覧が可能
こうした特徴を持つツールが、思っている以上に便利なのだ、という話を今回はしてみましょう。
■もともとやりたかったこと
そもそもこの「Textbox」は、最初は別のプロジェクトの名前でした。今回のツール開発のスタートとなったのは、実は「読書手帳2021」というプロジェクトだったのです。
まず読書の情報を管理する「紙の手帳」が何か欲しいな〜という思いがあり、いろいろ検討していくうちに「そうはいっても、書誌情報の管理を考えるとデジタルでやった方がよくね？」と方向性がシフトし、だったらデジタルツールで自分で実装しようと考えていたところ、そういえば以前「自分用のWebページをローカルサーバー経由で表示させる」というプロジェクトがあったことを思い出したので、そのときのファイルをそのまま流用してはじめたのが、このプロジェクトです。
で、その以前のプロジェクトが「Textbox」でした。つまり、ツール「Textbox」を使って、自分なりの「読書手帳」を作る、というのが一番最初に私が目指していた地点でした。現状はかなり拡大して当初の目的からはズレていますが、少なくとも当初は読書周りの情報を管理するためにこのツールを実装していたわけです。
■多様なフォーマット
イメージしていたのが「手帳」だったので、いくつかのページの種類が必要だろうなと考えました。たとえばそれが「日記」ならば（つまり読書日記ならば）、フォーマットは限定的でしょう。しかし、「手帳」ならば違います。
たとえば、紙の読書日記帳は、日付ごとではなく、本ごとにページが作られていて、そこに書誌情報や感想を書き込んでいく形になっています。基本的にそのフォーマットがほとんどすべてのページを占めていて、おまけ程度にカレンダーがついているものがあるくらいです。たしかにそれは「日記」でしょう。
一方で、私がイメージしているのは「手帳」でした。ここで手帳の定義に細かく立ち入ることはしませんが、それが「管理/マネジメント」を目的とするものであり、そのために多様な種類のページを持つ、という感覚が私にはあります。私が作ろうとしていたのも、そうしたタイプのデジタルツールです。
よって、一種類のフォーマットしか扱えないものはダメだろうと判断しました。また、「テンプレートからフォーマットが選べる」というタイプも今一歩という感覚があります。これまでやまほどのデジタルノートツールを使ってきた経験から言って、結局そういうフォーマットはほとんど使われないか、使うにしても使い勝手が良くないものになりがちです。
そうしたもろもろの検討の結果、出てきた結論は"乱暴"なものでした。
それぞれのページ（ファイル）のフォーマットは、それぞれ違っていい。それぞれのファイルが独自にフォーマットを定義する。
以上です。
これがどれくらい乱暴な（あるいは単純な）方法なのかは、ブログなどのシステムをお使いであれば直観されるでしょう。そうしたシステムでは、各ページはコンテンツの中身だけを保持し、それ以外のデザイン的情報は一つ上の共通基盤によって管理されます。その基盤があるからこそ、どのページを開いても基本的なデザインは同じになるのです。
Textboxでは、そのような設計思想を破棄しました。それぞれのページは共通的なデザインになっていなくても構わない。むしろ、それぞれのページのデザインが異なっている方が好ましい、と考えたわけです。
もう一度アナログの手帳を思い出してみてください。年間インデックスがあり、月間カレンダーがあり、それぞれの週や日付のページがある。それらすべてのフォーマットが異なっています。記入されている情報だけでなく、その「枠組み」が違っているのです。ブログのように、どのページを開いても同じデザイン、というのとはまったく違っています。
で、なぜ手帳はそのようにフォーマットが異なるページが含まれるのかと言えば、それぞれのページの「役割」が違うからです。役割が違えば、適切なデザインも違う。あたり前の話です。その「あたり前」を、デジタルツールで実現しようとしたのです。
もちろん、手帳の「カレンダーページ」が何月のものであっても同種のフォーマットになっているように、共通的なフォーマットが使われることはあるでしょう。しかしそれは、結果として（ないしはボトムアップ的に）共通になるのであって、頭から先に決められているものではないはずです。
どういうことかと言えば、7月と8月のカレンダーページが同じフォーマット/デザインになっているのは、同種の役割を求めるからです。同種の役割を求めるから、同じフォーマットになる。だからもし、12月だけ特別な情報が欲しいのであれば、本来12月のカレンダーページは他と違ったデザインになっていいはずです。アナログ手帳の場合は、さまざまな制約があるのでそこまで奇抜（ないし個別的）なものは作れないでしょうが、デジタルツールであれば問題ありません。
それぞれの情報の適性や自分が欲している役割に応じて、フォーマットを個別に作っていけばいいのです。
■mdファイルの内実
ここでmdファイルを扱う、という機能が効いてきます。
mdファイルは、内容的にはテキストファイルですが、情報的にはHTML要素を扱います。そしてHTMLタグをそのまま書いても問題ありません。#を三つつなげる代わりにh3タグを書いてもマークダウンファイルが壊れることはないのです。
だから、tableタグを使うこともできますし、divタグを書いてそれにdisplay:flexを適用することもできます。つまり、ページを「デザイン」できるのです。
一般的にマークダウンというと、見出し記法が話題の中心になりますが、そもそもが「最終的にHTMLに変換する」ための記法であって、それはつまり簡易でHTMLファイルを作成している、ということです。だから、上記のようなデザインのためのタグだけでなく、styleタグをmdファイルに書くこともできます。cssなどを記述するためのタグです。
そのタグを使えば、個別にページをデザインしていけます。すべてのページに対して共通的なcssを当てるのではなく、個別のページが「自分のためのCSS」を持つようにするのです。そうすれば、上位の要素（index.html）は個別のページについて何も気にする必要がなくなります。「このページはカレンダーだな。ということはこのフォーマットを使用するぞ」というCMS的判断をしなくてもいいのです。必要な情報は、すべてそのページ/ファイルが持っているからです。
ここまでを読んで「それってちょっとオブジェクト指向的だな」と思われた方がいらっしゃるかもしれません。私も同じように感じました。それが何を意味するのかはまた回を改めて検討しますが、ここでやっていることはある種の「委任」であるとは言えるでしょう。
index.htmlというページを呼び出す側が、そのページの扱い方を決めるのではなく、それぞれのページに任せてしまう。index.htmlはただファイルを呼ぶだけ。必要なフォーマットはそのファイル自身が持っている。
こうした委任/役割分担を行ったおかげで、Textboxは「単なるビューア」になりました。なにせ、必要な情報はすべて呼び出すファイルが持っているのです。Textboxの本体であるindex.htmlは、それらのファイルの管理についてやきもきすることはありません。単に必要に応じてファイルを呼び出して、その内容を表示すればいいだけです。ファイルはきちんと「独立」しているので、それを信頼すればいいのです。index.htmlがやいやい言う必要はどこにもありません。
まるでできた上司のようではありませんか。
（下につづく）
ここから先は
¥ 180
この記事が気に入ったらサポートをしてみませんか？