動じないために。
パソコンを使う、アプリケーションを使うということを自分仕様にする生活。
Office日誌：思想を自分の手に取り戻そう
別に洗脳されていたとか乗っ取られていたとかいう話ではないが、未熟だった自分が解決できなかったことを解決してくれる誰かの何かに焦がれるあまり、自分自身の感性や美意識、認識の形態のようなものを二の次三の次にして忘れていたような感じがするのである。最初の最初は自分自身の物の見方というのは当たり前の前提としていたのに、人の思想を渡り歩くうちにいつの間にか、「情報とはこう整理したほうがいい」というような、主語が自分以外の抽象的な何かに設定された思考に偏っていった。そのことに気づいてもいなかった。
（略）
人の思想に幾度も染まり直したことは私に多くの学びをもたらし、それは今の私を作る大切な蓄積になった。そこに、十年前に置き去りにした私の素朴な思いと望みを重ねて、今こそ自分らしいコンピューターライフを送ろうと思うのである。
Backlinks
他の「生き方・心がけ」カテゴリの語句
全ての情報をひとつのツールで扱えたらいいのにという思いは絶えずある。
記事を書き始めた最初の頃にも、アウトライナーをうまく使えないことについて書いた中でその話をした。
何かのツールで完全にオールインワンを実現している人というのはいるのかどうか、いるとしてどのくらいいるのかは全然わからないのだが、たぶん、実現できていない人（あるいはそうする気がそもそもない人）が多数なのではないかと思う。
個人的な見解としては、現状のツールだとどれを選んでも私はオールインワンを実現できない。それぞれの機能の特徴が一長一短ということもあるし、「ツールを切り替える」ということが自分の中で必要になっている面もある。
それは作業を並行して進めたいから複数同時に開いておきたいという意味でもあるし、違うツールを使うということがスイッチになって自分のモードが切り替わるという意味もある。○○用のツールはこれと決めれば、それを開いた時に○○のモードになるということだ。前者はマルチウインドウ式ならひとつのツールで達成できるが、後者はツールが違っていないと成り立たない。
それならそもそもオールインワンなんか目指さなくてよくない？ という疑問が生まれる。それはその通り。
しかしそれでも複数のツールを使うことに多少の不本意さを感じてきたのは、つまるところ、データがバラバラになっている感じがしていたからだ。それぞれのアプリケーションでデータの規格は違っているし、何かを探すとなればツールごとに検索する必要がある。自分が持っているデータを総合して扱うということができない。
このことはもうどうしようもないと長い間思っていた。インポートとエクスポートの機能が各ツールに備わっていてかつその形式が一致しなければデータを移すこともできないし、という感じで。
しかしながらここ最近は、このことについて悩まなくなった。
同時に使っているツールは過去最多のような気がする。メインのものというのはあるが、限定された用途のみのツールを含めれば、Capacities、Dynalist、Obsidian、Cosense、Notionを全部並行して使っていることになる。それでも混乱はないし不本意さもない。
というのは、「データを一箇所に集めようと思えば集められる」と思えるようになったからだ。
複数のツールを使っているが、ツール選択には条件がある。それは完全なデータをエクスポートできるか（あるいはローカルにあるか）、APIで直接取り出せるかということだ。よりよいのはAPIでデータの編集までできることだが、それは全てが備えていなくともとりあえず構わない。
更に重要なのは、そうして取り出したデータを特定の規格に揃えられること。自力でやるにはプログラミングのスキルが必要だが、別に高度なことはない。ちょっと勉強すればできるようになる。
ここまで来れば、自分があちこちで扱っている全てのデータがたった数個のコマンドで繋がることになる。アプリケーションとアプリケーションが直接連携しているわけではないが、「バラバラ」感はかなり薄れる。
実際、ツール間のデータの引っ越しを結構やっている。CosenseのデータをDynalistに移したり、DynalistのデータをmdファイルにしてObsidianに移したり、やろうと思えば大体どうにかなる。
情報が複数のツールに分かれることによってバラバラになることが気になるのは、「この先ずっとバラバラであり続ける」からというのが大きい。アプリケーションがデータを出力する機能を備えていなかったり、データを加工する手段を自分が持っていなかったりすればデータはアプリケーションの数だけ分かれてそのままになってしまう。
データを出力できるアプリケーションを選び、データを加工する手立てを得ておけば、オールインワンを理想としながらも複数のツールを使う生活をしてモヤモヤとすることはない――と言い切っていいかわからないが、とりあえず私はモヤモヤしなくなった。
今気をつけていることは、出力したデータを他の規格に揃えやすいように書き方に注意しておくことだ。あんまり囚われても良くないのでカチッと決めるということではないが、あまりにも無秩序でめちゃくちゃになると加工しにくいのである程度は形式に意識を向ける。特にDynalistやCosenseのような自由度の高いツールは自分なりのフォーマットを作っておくかどうかで活用しやすさが大きく変わってくるだろう。
また、そういう軽いルールは必ずしも自分を縛るものではなく、どこにどの情報を書くか決めておいた方がその都度判断せずに済んでむしろ助かる場合もある。自由すぎて場当たり的な使い方を続けているようなツールは、後々の加工しやすさを基準にフレームを作ってみるとツールの使用感がよくなる可能性もある。
とはいえ、データは出力さえできればどうにでもしようがあるので、「気をつけておくと後でちょっと楽」という程度に考えておく。そのうち自分にとっての定番のフォーマットというのが定まるだろうし、そうなれば形式の維持に認知資源コストを費やすこともなくなるだろう。
Dynalistはアウトライナーだが、私にとってはデータベースである。アウトライナーとして使えるデータベース、くらいの言い方をしてもいいかもしれない。
もちろん普通にWebブラウザやスマホアプリで操作する分にはただの（と言うのもおかしいが）アウトライナーである。Dynalistがデータベースであるというのは、アウトラインの形をトップダウンできちっと整備してデータベースとして使うというような意味ではない。発想としてはむしろ全く逆である。
DynalistはAPIを提供しており、プログラムを通じて自分のデータを参照したり編集したりすることができる。あるファイルのノード情報を取得する場合、そのファイルに含まれるノードがフラットな配列として取り出される。以下の型のオブジェクトがひとつの容れ物にわっと入っている状態である。
{
id: string,
content: string, // 本文
note: string, // ノート欄
checked?: boolean,
checkbox?: boolean,
color?: number, // 0~6
heading?: number, // 0~3
created: number,
modified: number,
collapsed?: boolean,
children: string[], // idの配列
}
アウトライン構造はchildrenプロパティに子ノードのidが列挙されることで表現されている。なのでこのidに一致するデータを探せばそれが子ノードだと分かる。しかしデータ自体はアウトライン構造にはなっていないわけである。ルート直下のノードも10層インデントしているノードもデータ上は隣に並ぶ。
つまり、そのノードがどこにあろうが関係なく扱えるということになる。例えば色を赤に設定したものに何らかの意味付けをするとしたら、それぞれてんでばらばらな深さに存在していてもcolorプロパティによって同じ種類のデータとしてまとめて取り出せる。色なり見出しなりノート欄なりを使ってそのノードの種類を自分で定義すれば、ノードの種類を示すためにアウトライン構造を使う必要はなくなる。
アプリケーション上のビューでは全てのノードがアウトライン構造のどこかに位置づけられる必要があっても、それぞれのノードのデータはアウトライン構造とは無関係に活用することが可能なわけである。
このことにより私の中でDynalistの使用感は大きく変化した。APIが使えなかった頃は分類的な視点でアウトライン構造を用いていたが、そのように形式的なアウトラインを作る必要がないとなれば、完全に「気分」で自由にノードを配置できる。これとこれが近い方が便利だ、その方が気分が良い、そういう理由で配置することに違和感を覚えなくなった。
もちろんカオスな方が良いということではない。自分が納得する基準で適切に配置させられるのがアウトライナーを使う理由なのだから、自分なりに整えていくことにはなる。そこに自分の気持ちとは無関係な形式的構造を混入させずに済むというのがAPI活用のポイントである。
ここまでの話だと「データベース」感は薄い気がするので、データベースとしての活用の話をもう少し具体的にする必要があるだろう。単に特定の条件で一度にピックアップできるというだけなら検索機能を使えば済んでしまう。
このサイトの記事はDynalistに書いてAPIを通じてサイト用のデータを生成している、という話は既に何度か書いている。それはつまり、Dynalistのひとつのファイルが記事のデータベースになっているということだ。
特定の書式（例えば色が赤でノート欄に日時が書いてあるなど）に従って書いているノードをタイトル行、その子項目を本文と解釈することで、それをひとまとまりの記事データとみなす。
インターネットを使っていると、日々数多のページにアクセスすることになる。有用なものがあればリンクを保存しておきたいと思う。便利なツールのURL、興味深い記事のURL、誰かのサイトのURL、後でチェックしたいもののURL、等々、さまざまな種類や状態の情報を保存しておくことになる。
全てをブラウザのブックマークに入れるとごちゃつきに耐えられなくなるのだが、これらを如何にもなデータベースで管理するとなると、保存の気軽さや頻度の多さとデータベースというものの仰々しさが大抵見合わない。とても手入れはしていられないし、テーブル形式のぴしっとした感じの割にそれほど見やすいわけでもなかったりする。
とりあえずDynalistにファイルをひとつ作り、そこに全部突っ込んでしまうことにした。最初は「検索すればいい」というつもりでDynalistを選んだのだが、ある時「ほかにビューワを作ってDynalistをデータベースとして使えばいいのではないか」と思いついた。作ったブックマークのビューワがこれ。（画像の内容はもちろんごく一部。）
ここまではDynalist上で書き込んだ情報を取得・解釈して活用することについて記してきた。しかしDynalist APIでできることは情報の取得だけではない。データの編集も可能である。
不可逆的な操作になるのであまり軽率に試していいものではないが、APIを使えばファイルやフォルダ、ノードの作成・編集・削除ができる。Dynalistを開いていなくてもDynalistのデータにアクセスして弄れるのだ。
例えば、あるファイルの中のノードについて一括で置換したい何かがあるという時に、普通はひとつひとつ手作業でやるしかない気がするが、APIを使えばプログラムで処理できる。ルールを前もってきっちり決めなくても後で軌道修正できることになり、大規模な何かをやるにしてもあまり構えずにやれるようになる。
あるいは、何かのページを見ていてリンクを保存したいとなった時に、自作のChrome拡張機能にDynalist APIを使った処理を実装しておけば右クリックメニューから直接Dynalistの特定の場所に送信するみたいなこともできる。私はブックマーク、記事の本文、Twitter（X）のポスト、YouTubeの情報などをそれぞれ然るべき場所に送れるようにしている。
こうするといよいよDynalistがデータベースらしくなってくる。Dynalist上での操作より外から操作する方が多いファイルというのもあり得るし、アウトラインの形で見たい時だけDynalistを開くという使い方も考えられる。アウトラインの表示を自分で作るのは割と面倒くさいので、データのアウトライン化を簡単に実現してくれる手段としてDynalistを利用するわけである。
このようにしばしばアウトライナーとしての在り方から逸脱した使い方をしているが、もちろんDynalistのファイルおよびノードを全てデータベースとみなして使っているというわけではない。普通のアウトライナーとしてアウトラインを考えることにも使っているし、その方が当たり前に多い。しかしそれらはいつでもデータベースとして解釈して活用することが可能である。
Dynalistの見出し、色、ノート欄は最初の頃はさっぱり上手く使えなかった。検索での絞り込みにそれらを使うことはできるが、結局のところ当時の自分にとっては見た目の問題でしかなかったからだ。何色をどういう意味で使うかに必然性はないし、6色もあるが6色しかないということも活用を難しくしている。
しかしながら、プログラムでの判定にそれらを活用できるとなると、急にそれらが便利なものに変身した。全てをノードの本文部分に書かなくてはならないとなれば、私自身には必要のない機械用のデータが場所を取って見ていて嫌になってくる。なのでメタデータを付与できる手段がほかに色々あるのはとてもありがたいことなのだ。
今となっては色設定とノート欄は必要不可欠である。色付けに必然性が生まれたことによって使うタイミングに迷うことはなくなり、また「使いこなせてない」という気分もなくなった。
アウトライナーは全ての情報をアウトライン上に位置づける。その特徴は私たちの理解を助けてくれる一方で、情報が位置に縛られるという欠点にもなる。しかしDynalistには別の切り口で情報を扱う手立てがあり、工夫次第でデータを如何ようにも活用することができる。
その意味で、私はDynalistを単なるアウトライナーではなく「アウトライン型データベース」だなと思って使っている。
プログラミングを始めた頃はアウトラインの位置を基準にしたブックマークビューワを作っていたが、手入れが面倒になってしまった。 ↩︎
先週末から新しいツールを作り始め、昨日の時点でほぼ完成した。
（※まだ公開はしていません。）
デジタルツールなので、ページの入れ替えはもちろん可能だし、ページ間リンクも設定できる。大学ノート風の見た目だがルーズリーフのように差し替えられ、かつ、ルーズリーフと違って裏表の縛りはない。単位は1枚でも見開きでもなく1ページである。
上のスクリーンショットだと左に1ページ目、右に2ページ目が表示されている。この状態で「次のページ」に移動すると、1ページずれて左に2ページ目、右に3ページ目が表示される。つまり、表示は見開きだが見開き単位でめくるのではない。紙のノート及びルーズリーフで微妙に困っていたのが「ページと見開き」の関係だったのだが、このツールではそこに困ることはない[1]。
なお、連結されたページの塊をノートブックと見なしている。連結は自由に組み替えられ、ノートブックはいくらでも作ることができる。連結を切ればそこでノートブックは二冊になる。
紙面の制約もない。基本的には普通に表示される範囲で収まるように書くが、別に大幅にオーバーしても構わない。ページ内でスクロールできるようになっている。
Markdown記法を使えるようにしているので、書き方の幅も結構広い。ちょっとした表とか画像が使えるようになっているとやはり便利だ。（あんまり凝ると手間ばかりかかるので、手で書いた方が早いなら手元の紙のノートに書くけども。）
いつでもすぐ開きたいページは、pin設定すれば左端にインデックス付箋風にリンクが作られる。先頭の1文字しか表示していないが、マウスオーバーで本文を確認できるので迷うことはない。
右端のインデックス付箋で色々な機能にアクセスできる。検索とかページ一覧とか。付箋風のメニューにすることで「ボタンやアイコンがごちゃごちゃあって煩わしい」という気分を回避している。それらの機能は右ページの領域に表示され、見た目としては大学ノートの裏表紙裏のような感じになる。
今のところ、順番に並ぶことに全く意味がない情報は他のツール（例えばScrapboxやObsidian）でやるべきだが、前後関係を踏まえたい情報はこれで良さそうという感じがしている。
紙のノートの使い方が各々独特なように、このツールも私に最適化しているので、見た目の素朴なアナログ感とは裏腹に万人向けツールにはならない（UIを万人向けに設計しづらい）。なのでサンプル公開はどうするか考え中。
それにしても爆速で作れたなと思う。コーディングもCSSも随分自由になった。その前に作った「TextManager」と比べるとかなりの違いがある。
紙のノートは見開きが単位になるが、ルーズリーフは1枚が単位なので、見開き単位では扱いにくい。そのどうにもしようがない違いがいつも気になっていた。 ↩︎
Denoを使って、指定したディレクトリ内に存在するプレーンテキストのファイル（txt,md,js,css,html,...）とMicrosoftWordのファイル（docx）を自作ツールにまとめて取り込むスクリプトを作った。
ここ最近、Denoを使い始めた。
（※プログラミングについて色々書いていますが非プログラマーの素人が頑張って喋っているだけなので表現の正確さは全く保証しません。）
Denoとはなんぞやというのはお調べいただければと思うが、簡単に言うとNode.jsの製作者であるRyan Dahl氏がNode.jsの設計ミスを解決すべく開発したJavaScript実行環境ということになろうかと思う。「Node.jsを洗練させたもの」という感じである。
要はサーバーサイド（素人的に言うとWebブラウザ上ではなくパソコン上ということ）でJavaScriptを使うためのもので、例えばローカルファイルを読み込んで操作したりサーバーを立てたりできる。できることは無限にあると思うが、今のところ私の中で理解と実践が可能なのはローカルファイルの操作である。私が作っている自作ツールというのは、WebブラウザをGUIとして利用しているが、Node.jsでローカルサーバーを立ててローカルファイルの読み書きを可能にしている。
Node.jsはnode_modulesフォルダにライブラリがガンガン追加されていくわけだが、この形式のせいでコードを置く場所が縛られている感じがするし、自分で直接触ることのないファイルが作業ディレクトリ内に大量に発生するのにも違和感があった。Denoはnode_modulesを生成しないのでとても身軽である。別にどこに書いてもいいし、どこで実行してもいい。触りもしないよくわからないファイルが視界の中に溜まっていくこともない。
また、DenoはTypeScriptで書いたコードをそのまま実行できる。jsファイルを生成しなくて良いのである。そうするとソースマップのmapファイルも生まれないし、フォルダの中はスッキリサッパリ。
require形式からimport形式に変更されているのも良い。私は新参者なのでES2015の仕様が自分にとって普通で、CommonJSは混乱の元になっている。書き方を機械的に覚えてはいるが、同じ意味のものに別の書き方があるみたいなのはもやもやと気になってしまう（歴史的にやむを得なかった分岐なのはわかっているのだが）。なので全部importで済むのは非常にありがたい。
Node.jsにあった問題点が如何なるものでそれが実際にどう解消されているのかというのは話が高度過ぎて私にはよくわからないのだが、普通に使おうとしてすぐ出くわすような部分のデザインの変更だけでも快適さが段違いである。
こんな感じでなんだか気分がたいへん軽やかになったので、ローカルファイルの操作に関して色々と思いつき、あれこれコードを書いた。
具体的には、或るディレクトリ内に存在するプレーンテキストとdocxファイルを全部まとめてTextManager用のjsonに変換するとか、階層付きテキストをjsonに変換するとかである。パソコンの中に散らばっているテキスト情報を掃除機のようにガーッと吸い取って良い感じに整えるということができるようになった。
CLIコマンドにも急に親しみ（？）を感じ始め、コマンドへの苦手意識がすっと消えた。Denoの仕様を知ることで、そもそもコマンドとは何なのかというのがちょっとわかったような気がする。
Denoにすることで自分に可能なことが増えた、というわけではない。Denoでできること、少なくとも今の私がやれることはNode.jsでもやろうと思いさえすればできることである。しかし、潜在的に可能なことについて「できそう」と思うに至れるかどうか、という点で私の中ではNode.jsとDenoの間に大きな違いがあるのだと思う。
理解しなくても支障がないものだとしても、それがあると「理解できそう」という希望が生まれない、みたいなことというのがある。Node.jsのデザインは私にとって希望を生まれにくくする暗幕のようなものだったので、Denoの採用は大変に高い効果があった。
もっと早くから使っていれば……という思いはなくもないが、Node.jsとTypeScriptとCLIにある程度以上慣れていないと多分全然理解できないことだったので、このタイミングでの導入はまあ妥当なところなのだろうと思う。Deno自体、何年か前の時点では新しすぎて不安定な部分が多かっただろうし、仕様変更にすいすいついていけるスキルも私にはないわけなので、2023年の今というのは挑戦にはちょうどよかったのかもしれない。
参考リンク
自分用ツール開発に於いての自分自身の変化について、二つ目は感覚の変化の話。前回の記事はこちら。
プログラミングの経験と直接関係しているかどうかは定かでないが、ツールに求めるものというのが結構変わってきたと感じている。変化を一番感じるのは「平面に並べる」ということに関してで、次にアウトライナー機能についてである。
ツール作りを始めた頃というのは、Scrapboxのページ一覧画面に甚くハマっていた時期で、ツール内に存在しているデータを決まった大きさの小さいカード状にして均等に並べることが自分の感性にぴたりと合致しているような感じがしていた。Notionで言えばギャラリー表示である。
ブラウザのブックマークがリスト状なのは嫌だという話を前に書いたが（NTA-DIY：1ヶ月目⑨～ブックマーク管理ツールを作ってみる～）、タイル状に並べたら非常に見やすくなったと感じたので、バカの一つ覚えのごとくタイル状のビューのツールを作った。
その後、マンダラートの話を聞いたことをきっかけにしてマンダラート風のアウトライナー的なものも作った（Plane Outliner）。アウトライナーのリニアな表示に個人的に不自由さを感じていたので、この「面のアウトライナー」は自分としてはかなり画期的だったし、しばらくは実際に使っていた。ツールとしては今でも面白いと思っている。
ただ最近は、「平面に並べる」ということについて重視する点がちょっと変わってきたと感じる。メモ群の俯瞰にギャラリービューを使うみたいなことではなく、ダッシュボードのように、限られた画面上に計器を適切にレイアウトする、ということをより重要視するようになった。メモを開いたらメモに関する情報――つまり他のメモからのバックリンクや本文の文字数等――がパッと表示される、というようなことだ。
要らない情報はあると邪魔だし、表示する情報の見た目もなんでもいいわけではない。「何が同時に表示されている、どういう見た目の画面を欲しているのか」を自分に問い、厳密に自分に合った形を模索して作ることが重要で、最近は一覧ビューの如何よりもそちらに意識を向けている。
アウトライナー機能についても感覚が変わってきた。
一時期は自作ツールでアウトライナーを再現することに非常にこだわっていた。上述の「面のアウトライナー」も含めて○○型アウトライナーと名付けられそうなものを頑張って作っていたし、それらは実際にある程度活躍した。
しかしながら、最近はそうではない。この頃作っているツールでは、テキストエリアにプレーンなテキストを書いて、それをMarkedというライブラリでMarkdownとして解釈してHTMLに出力している。つまり専らMarkdownで書いているので、所謂アウトライナーを使った書き物はほぼしていない。
といっても、Markdownには箇条書き書式があるし、それを折り畳みできるように機能を加えているし、textarea要素にショートカットを自分で色々搭載して行の入替えやアウトラインのインデント/アンインデントなどはできるようにしているので、アウトライン操作は可能である。Markdownで書く中にアウトライナーの要素を一部吸収したような形だ。
自分の好きなようにデザインしたツールをあれこれ作っていく中で気づいたが、プロセス型にしろプロダクト型にしろ、アウトライナーというものが一番の大枠にあるツールではなく、色々な機能の中にアウトライナーの発想が包含されているような形式の方が自分に合っているのだと思う。つまり「○○型アウトライナー」よりも「××の中のアウトライナー的機能」という考え方だ。アウトライナーが大枠にあるもので何かをするならその全てがアウトライナーの仕組みに従わなければならないが（如何にその自由度が高くとも）、アウトライナーが主ではなく従ならば、アウトライナーとは異なる仕組みを使いつつ必要に応じてアウトライナーを召喚するということができる。
当初アウトライナーの再現にこだわっていたのは、前回（作るためのツール作りから使うためのツール作りへ①目的の変化）書いたように、可能性の開拓に関心を向けていたからである。自分でもアウトライナーを作れるのか、ということがとても重要なことだった。というのも、デジタルノートツールに於いてアウトライン操作は絶対的に必要なものと感じていて、それが実装できないなら結局何を作っても肝心なところを既存のサービスに頼らざるを得ない気がしたからだ。
その後色々なことを試していくうちに、自分にとって必須なアウトライン操作というのは既存のアウトライナーが持つ形態に沿っていなくてよい、ということがわかったわけである。
これらのことによって、初めの頃に想像していた「こんなツールが欲しい」と、今考えている「こういうツールを作りたい」とは、かなり大きな違いが生じている。
次回は力量の変化について。
他の記事を書こうとしていて脱線が膨らんでしまったので、その部分だけ先に切り出しておくことにしようと思う。自分用のツール開発に於いての自分自身の変化について。
この記事で何かを言いたいというよりは、他の話をする時にその場で経緯を説明するのは大変なので、部品を予め用意するために書いておく。
そして切り出すか～と思って書き始めたら結局6000字ほどになってしまい、一度に投稿するにはちょっと重くなってしまったので三本立てにすることにした。本流より支流の方が太い感がある。
さて、自分でコードを書いてツールを作るようになってしばらく経つ。
最近はワーッと爆走するようにコーディングするみたいなことは減り、必要なものを必要な分だけ作るという形に落ち着きつつある。プログラミングに割く時間は随分少なくなった。前まではほとんど毎日何かしら書いていたが、ここのところはそうでもない。
まだ「慣れた」という程プログラミングに慣れたわけでもないし、ましてや「わかった」とはとても言えないし、やはり初心者であると思うけれども、その中でも変化したことというのはある。以下の三点にまとめられるだろう。
今回はこのうちの「目的の変化」について。
最初の頃というのは、「JavaScriptで一体何をどこまでできるのか」「初心者の私は何をどこまでやれるのか」ということの追求を主目的にしていた。だから思いついたことを再現することが最大の関心事で、作れたという結果を得るために作っていた。「自分でも○○ができるかもしれない！」というワクワク感に突き動かされていたのである。
その熱意によって、例えばアウトライナー、付箋ツール、Scrapbox風のシステム、テトリス、ぷよぷよ、ドット絵エディタ、といったものを作っていった。（ぷよぷよは公式の教材「ぷよぷよプログラミング」があるが、それを利用したのではなく自分でゼロから考えた。）
最初のうちは、何かを思いついた時というのは具体的なコードを最初から最後まで細かく想像できるわけではないので、「本当にできるのか」というのはやってみないとわからない。実際、想像できなかった問題にぶち当たることもあるし、最終的に実現に至っても当初の予想とは結構違うコードになっていることもあった。その一連の「ある程度は予想できるけど実態については未知の領域」を探検する試みは、本当に楽しいし、次々思いついてしまうのでやめられない。
しかしある程度慣れてくると、「何ができるか」ということについては「まあ何でもできんだろ」というような感覚になっていった。具体的なコードが想像できるようになって、その通りに書けば再現できることがわかってくるからだ。もちろん実際に取り組めば気づいていなかった落とし穴に嵌ったりするだろうが、それでも未知への挑戦という気分はだいぶ薄れている。何か思いついても、本当に必要なものでないなら「やろうと思えばこんなこともできるな」と考えるだけで済ませるようになった。
可能性の開拓に全振りしていた状況が落ち着くと、じゃあ自分は何が欲しいのか、ということに関心が移っていった。自分にとって実用的なツールとはなんであるかということだ。それはもちろん最初から考えていたことではあったが、スキルが何もない状態では想像したところでそれを実現できる見込みがないので、本気で考えるには手持ちのカードを増やしておく必要があった。
関心が移り変わり始めてもしばらくは「可能性の開拓」と「実用性の吟味」の間をふらふらしている状態が続いて、「○○型アウトライナー」のようなツールをたくさん作ったし、「これがあれば便利かも」と思えばそれを片っ端から再現した。自分にとって何が実用的かということ自体がはっきりしていなかった。
しかしまあ、「便利かも」と思って作ったものは、だいたいコードが複雑でバグの温床になる割に結局「なくてもいいかも」なものであったりする。そこそこよくても面白くても、別になくて構わないもの。「なくてもよかった」は実際作ってみたからこそ出せる結論だが、それが繰り返されると迷走しているようで少し辛い。でも多分近道はないので、耐えて格闘を続けることになった。
最近は、コードが複雑だとデータの保存処理などを信頼しにくくなってくることも踏まえて、「便利かも」程度では実装しないようになった。
重要なのは「自分に必要な機能を最も使いやすい形で実装する」ということであり、シンプルで安心できて必要かつ十分な機能を作ることを心がけている。そうなってやっと、自分のツールを重用するということができるようになったと感じる。
次回は感覚の変化について。
この記事はこちらの記事へのレスポンスです。
ブログ記事にご感想をくださりありがとうございます。はじめの方では身に余る賛辞をいただき、大変恐縮しております。
自分なら違うデザインにする、とお書きになっている二点についてお返事を書こうと思い、コメントではなく記事の形で書くことにしました。
Goさんと私の感覚の分岐点になっているであろう点として挙げてくださっているのが、次の二点でした。（勝手に換言して書きますがお許しいただきたく）
実のところ、「私もそう思う！」という気持ちです。というか、私もそうなので、これまで使ってきた全てのツールが続いていなかったりします。似た複雑性のツールは数多ありますが、それらはその複雑性ゆえ継続は悉く挫折しました。なぜなら、ツールの複雑性がそのまま私にとって複雑だからです。
ところで、「違う考え」を提示していただいたことに対する返答の形なので、変に緊張を呼びそうだなと心配していますが、全然反論や弁明などではなく、Goさんのご意見を元に私自身の解像度を上げることを試みようと思っています。お返事と書きましたが、ほとんどただ自分語りをすることになりそうです。
突然ですが、私は極度の飽き性です。だいたい三週間または三ヶ月サイクルで「形式」に対して飽きてしまい、種々のデータがばらばらの形式であっちこっちにあります。
飽きる理由は多分いくつかあって、「理想の格好良さに沿うべく無理している」ということもありますし「傾けられるエネルギーに波がある」ということもあり、そもそも「ただ飽きて続けられない」ということもあります。経験上、「ただ飽きる」のは「自分以外の人間が作った事物」に対してより高確率で発生します。というか必ず発生しています。偏屈過ぎて、自分以外の存在の感性に合わせ続けていられないのです。
あとは、「より良いものを思いついてしまった」ということも大きな原因になります。そうなると現行のやり方は全く気に入らなくなってしまうからです。「モノ」には愛着もわきますが、私の場合「やり方」には全然そういう愛着・執着を抱くことができないのです。
あまりにも飽きっぽくて生活にある種の支障が出ているので、自分の「飽き」について随分詳しくなってしまいました。すぐ飽きる自分に悩まされているのが嫌で、「じゃあどうしたら飽きないんだよ」と問い続けている状態です。
飽き性である自分に対してできることを考えた時、「飽きないようにする」と「飽きても良いようにする」の二通りのアプローチがあるでしょう。
「飽きないようにする」にはどうしたらいいか？ 具体的な方策は人それぞれの性質次第ですが、私の場合は上述したような理由があるので、
の三点が対策になります。
一つ目を言い換えると、「無理をしないと格好良くならない仕組みは駄目」ということでもあります。これは特に汎用的なツールを使う時に発生します。紙のノートでもそうです。私は情報のレイアウトを超が付くほど重要視していますが、自分が望む見た目を作らんとして、記入するたび認知資源を使う必要があるのがまずいのです。なので、JavaScriptの力で自動で整えてもらうことにしました。
二つ目の達成には、やる気に満ち満ちている時でなくても維持できるような簡単さであることが必要です。私の記事を読んでくださった方は、多分ツールの見た目が複雑そうなのでここがネックになるとお感じになったのではないかと思いますが、むしろここを確実に解消するためのあの複雑さ（仮）なのでした。
あんまり具体的に書くとさすがに冗長なので割愛しますが、例えば「作成画面を開いてから必要項目をチェック」だと面倒くさくて絶対飽きるので「この項目をチェックした状態で作成画面を開く」というボタンを設置する、というようなことをしています。普通のタスク管理ツールは「作成画面を開いてから情報を編集」にならざるを得ないと思いますが、それだと私の場合100%飽きることを知っています。
なので、裏で動いている処理の複雑さや見た目の「なんか選択肢と記入欄が多い」という印象とは裏腹に、「私の動線」からすると逆にシンプルになっています。これは私が作って私が使っているからのことであり、それぞれがそれぞれの設計をしないと意味がないところだと思います。
ここまでは「飽きないようにする」ための対処法ですが、「飽きても良いようにする」ことも必要になります。自分以外の人が作ったツールには必ず飽きますが、じゃあ自分が作ったツールには飽きないかというとそうとは限りません。最初の方で書きましたが、「より良いものを思いついてしまった」が発生したらもうおしまいです。そしてそれはしばしば発生します。（思いつくこと自体は喜ばしいことです。）
何かのシステムでやっていて飽きた時に困るのは、そこまでの形式で作ったデータが他のツールにそのまま持ち越せないことです。しょうがないので新たに始めることになり、まあ結局はそんなに生活に支障はないのですが、気持ちとしてはかなりの不満を抱える羽目になっています。ツールを替えてしまえばそれまでのデータは参照しづらくなり、バックアップデータを残したとしても、それらはもはや「記録」ではなく「残骸」になっています。
やりようは技術次第で色々あるかと思いますが、私の場合は、JavaScriptで処理をしているのでJSONファイルが救世主になりました。今後も自分でツールを作ることが前提になってしまいますが（それは私の中では先述した通りもう前提なのですが）、見た目や編集の方法に飽きるとしても、必要なデータの種類はあまり変わらないことから、JSONファイルを使い回せばツールを替えてもデータを持ち越すことが可能です。
実際、（タスク管理ではないツールですが、）データはそのままにツールの設計を大きく変えて作り変えたものがあります。新旧ツールの間に一応互換性があるということです。やがて改良の末に旧ツールには戻せない形になることはありますが、大事なのは旧→新の移行なので、逆向きの可否は重要ではありません。（それも旧ツールを弄ればどうにでもなります。）
長くなりましたが、「飽き」についてはこのくらいで、次はログの話です。
一応ずっと何かしらの形でログを取っています。飽き性ゆえにログの形式はバラバラです。というか、どこにいつのログがあるのかももはや定かではありません。どこかにはあるはずですが、取り出してくるのは容易ではない状態です。とても不本意です。
そもそもログが必要かというと、正直なところ、情報としてはあんまり必要性は感じていません。よく自分の傾向を振り返るために記録を見返すというような話を聞きますが、私はそういうことはほとんどしません。あまりにもフォーマットというものに飽きるので飽きる周期はどのくらいかを知るために見返したことはありますが、多分、それだけです。そしてタスクの実行記録に至っては、全く役に立った記憶はありません。記録を活用していないのです。
でも、私はこれからもログを取ります。データがどこにいったのかさえもはや判らないにもかかわらず、これまでログを取っていたことは私には大きな意味があります。
以前、私は精神の健康を損なってほとんど何もできなくなったことがありました。虚無感、無力感、無能感に襲われてまあ大変だったのですが、それ以来、頭の中を「私は何もできていない」という認識が埋め尽くすようになりました。今もそうです。多分一生残る後遺症だと思っています。（回復する人もいると思いますが、私には恐らく死ぬまで残ります。）
仕事をする、何かを書く、というようなことをすれば、もちろん私がした何かが世界や誰かの中には残るのですが、それを自分自身が認識していられないと「私は何もできていない」ということが私の中では真実になってしまうので、「私はこの日これをした」という証明書を自分に発行するために毎日ログを残すのです。私の脳は私自身がしたポジティブなことを忘れたがっているようで、一目で把握できる形で書き留めないと容易く「なかったこと」になってしまいます。そのくせネガティブなことは絶対忘れてくれない残念な脳です。
証明書を発行してしまえばあとは安心してその証明書は放置です。ちゃんと生きている感を実感したい時だけ眺めています。
盛大な自分語りになってしまいました。個人的なこと過ぎて自分のブログにすら書く機会を見出だせていなかったことですが、えいやと書いてみました。
もしかすると他の人の目には私が如何にもシステマティックなものが好きそうに映っているのではという可能性を感じなくもないのですが、実情としては、多分全然そうじゃないのだと思います。システマティックに生きなくて済むシステムを作ろうとしているような気もしています。
ここ一週間くらいで、ローカルファイルのディレクトリ構成を大きく変更してファイルを整理した。ついこの間まで（唐突に）各所に記事を連投していたのに十日ほど前にあっさり途絶えたのはこの作業をやっていたからなのであった。
ここで言うローカルファイルというのは、PCやスマホを使う中で作成したりダウンロードしたりで発生するファイル群のことを指している。自分が使っている端末の中にあり、かつコンピュータが読むものではなく、自分自身が開いて利用するタイプのファイルである。（普通ローカルファイルと言ったらプログラムが読むためのファイルも当然含むけれども、今言いたいのは人間用のファイルの話ということです。）
フォルダとして括るべきプロジェクトがあればそれに関連ファイルをまとめれば良い、とシンプルに思いはするものの、普段PCやスマホを使っていて作成したり集めたりしたファイルはそううまく然るべきフォルダにまとめられない。困っているという話をそれほど聞かないけれど、みんな当たり前にうまくやっているのだろうか。自分は知らない常識がどこかにあったりするのだろうか？ あるいは、Evernoteが綺麗に解決してくれたということか。
もしかすると自分の混乱は私個人の独特な事情が災いしているということもあるのかもしれない。個人的な用途でOfficeファイルを作るということが結構あって（Office日誌：思想を自分の手に取り戻そうに以前書いた）、ローカルファイルがとにかくごちゃごちゃしやすい状態にあるのである。あとはデジタルノート系のフリーウェアやスマホアプリを試すことが多々あって、それぞれで生成したファイルも様々ある。更に諸々の趣味で作ったり集めたりする画像やファイルもなんだかんだ多岐に亘り、いつも悩みを抱えている。なるべくローカルファイルとして置いておきたいという願望がそれに拍車をかけている（例えばGyazoという便利なサービスを知っていつつも）。
そしてDropbox、Googleドライブ、OneDriveといった各クラウドのフォルダにもそれぞれファイルが置いてあり、使い分けとしてはおおよそ整理がついているものの、ディレクトリ構成の規格が整っていないせいで雑然としている感じが否めずにいた。
長年迷走に迷走を重ねており、とはいえさすがにそう頻繁に変えてはよろしくないと思って前回の整理からは年単位で経過していたが、常に「なんか違うんだよなあ」と思って過ごしていた。
今回の整理前は、昔Evernoteの使い方で見たような「連番+名称（だいたい英単語）」で順番をはっきりさせて十個くらいのフォルダを並べていた。「こういう感じのファイル群が上の方」みたいなニュアンスとしてはまずまず納得していたが、そもそも連番というのが私は気に食わないらしい。数字だけでなくアルファベットでも日本語でも同じことだが、順番をコントロールするための事務的な文字列が「名前」の欄にあるのが嫌なのである。Evernoteも自分が勝手にやり始めたこの手法の気に入らなさでフェードアウトへの一歩を踏み出したのに、また同じことをやっている。
とりあえずこの時点では、設定っぽいファイルは上の方で、バックアップ類がそれに続き、日頃使っているファイルは対象ごとに分けて真ん中あたりで、集めたファイル類は下の方にあってほしいな～みたいなイメージを抱いていた。私にとっては位置のイメージが重要なようである。
ところで近頃はHTMLやJavaScriptをいじっていることが多いので、htmlファイルを開いてぼけっとしていたことがあった。メインの内容はbodyタグ内に記述され、その上のheadタグにメタ情報の類が入っている。bodyタグ内にはheader、main、footerタグがある。navやarticle、section、asideについて調べたばかりでもあり、HTMLというのはうまく整理されているなあとかぼんやり考えていた。
そこでハッと閃いた。設定っぽいファイルはHeadで、「使う」タイプのファイルはBodyと捉えればなんかスッキリする気がする。じゃあバックアップとかバッファー的位置づけのフォルダはFootということにしてみるか。「集める」タイプのファイル、HTMLで言えばインポートするcssファイルやjsファイル、表示する画像といったものの位置づけにあたる類のファイルは、また別にまとめた方が良さそうだ。
「集める」ファイル群をまとめる言葉はHTMLのイメージからはうまく見つけられなかったが、とりあえずHead、Body、Footに合わせて四文字が良いかなと思い、安直にItemとすることにした。（英単語としてはちょっとずれているかもしれないが、ゲームに出てくる「アイテム」のニュアンスで採用した。）
そしてそういう分類用のフォルダであることを示すために全部大文字にしてフォルダ名とした。
こんな感じ。これをローカルのユーザーフォルダと各クラウドに基本の形式として設置した。
この時点で「使う」タイプのファイル以外のものにうまい名前がついてだいぶスッキリした。特にこれまでバックアップ類がなんとも微妙に漂っていたのが、もしもの時に支えてくれる縁の下的イメージに落ち着いたのは大きい。名前順に並べればBODY→FOOT→HEAD→ITEMの順になって上下の位置のイメージは崩れるが、名前にそのイメージが含まれているし、BODYが一番上に来るのはむしろありがたい。名前でイメージがわかるなら更新順にしても困らない。
ちなみに、PCやスマホ内で自分自身が扱う種類のファイルを入れたフォルダの名前にも長らく納得がいっていなかったのだが、「」にすることで決着した。半角のアンダーバー1文字である。どう名前を付けても変にレトロニム的になって気持ちが悪く、何の意味も示さない且つ名前順で先頭に来る名前が良いと思って「これでいいじゃん」となった。何か支障が生じやしないかと心配しないわけではないが、もし何かあったらその時は改めることにする。（つまり、PCでは「C:\Users\ユーザー名\\_」、スマートフォンではルート直下の「」の中にBODYその他が入っている状態になる。）
さて、使うファイルはBODYフォルダということにしたが、この中身は「明らかに他と混ざらない括り」によってそれぞれフォルダを作っている。要するにプロジェクト単位と言ってもいいかもしれないが、例えばGitのリポジトリごとのフォルダとか、小説を書くなら小説とか、絵を描くなら絵とか、そんな感じの括りである。
ちなみについ数日前に閃いたばかりのフォルダ名に「Noting」がある。「ノーティング」は倉下忠憲氏が著書『すべてはノートからはじまる』で提示されていた概念で、そこから拝借した。例えばLogseqとかObsidianのルートディレクトリや、ノートとして作成したOfficeファイル類を、どういう括りでどこに置いたらいいのか心情として解決していなかったのだが、「要はノートである」ということでまとめてしまえばいいんじゃないかと気がついたのである。ひとつのフォルダにまとめられただけでなく、そこに相応しい名前を与えられたことに大きな意味がある。
BODY内の各フォルダは、更に「COLLECT」「MAKING」「PROCESS」「RECORD」の四要素で区分することを基本とした。こちらは「これで統一する」というほど徹底しているわけではなく、経験的にこんな感じになっていることが多いなというところから必要に応じて作っている（特に創造的なものについて）。
それぞれ一応以下の意味合いである。名前は六～七文字のアルファベットにしようと思ってこうしているが、特にこだわりはない。
こちらは先述の大きな四分類と比べると必然性が薄く、まだ括りや名称を変える可能性がある。そんなに「良いこと思いついた」感があるわけではないが、記録としてついでに書いておくかと思って書いた。
今までの整理の試みと比べると自分の中で納得感があるが、果たしてどうなるか。
（なお、この整理をするにあたり「DiskInfo3」で解析結果を保存したほか、そのスクリーンショットをログとしてScrapboxに貼っておいたりした。こういう時はやはりScrapboxが便利である。）
のらてつ Noratetsu