まず、Dropbox直下に保存されているのは、いわゆるプロジェクトを扱うフォルダだけではない。むしろ、自分の中でWorkingなものはだいたいここにフォルダが作られている。シゴタノ！やメルマガなどの連載ものを扱うフォルダもあるし、日々の作業記録やプログラミングの作業フォルダもある。非常に雑多な状態だ。
で、コメントにあったように、そうしたものまでわざわざ走査するのはムダである。はっきり「プロジェクト」だとわかるものを集めた、「プロジェクト」というフォルダを作り、その配下に置いておけば走査の範囲は大幅に限定される。
私も最初は同様に考えた。そうするのがナチュラルであるようにも思えた。しかし、DoMAモデルを考案してからの私はどうにも反逆的になっている。
その「プロジェクト」フォルダって、本当に必要だろうか。
こうした疑問が頭をちらつくのだ。
いわゆる「プロジェクト」としか呼べないもの
一番ひっかかりを感じるのは、その「プロジェクト」というフォルダが整理のためだけにしか機能しない点だ。実質的には「フォルダをまとめるためのフォルダ」でしかない。そういうピンハネ的というか中間管理職的な存在を無批判に受け入れるのはあまりよろしくない。
たとえば、「かーそる」というフォルダを作り、その下に各号用のフォルダを作るのは問題ない。たしかにその「かーそる」フォルダはフォルダをまとめる役割を中心的に担っているが、しかし「かーそる」のレベルでも扱う情報は存在している。たとえば、すべての号で共通に使う画像データはその階層に置かれている。つまり、その階層にも実質的に意味がある。
しかし、「プロジェクト」フォルダは違う。それは純粋にフォルダをまとめるだけのフォルダである。
これは、機械的な階層の話をしているように見えるだろうが、実際はそうではない。私が、そうした行動の情報を扱うときに「プロジェクト」という概念/単位がそもそも先駆的に存在していないのである。
たしかに、執筆企画という対象は「プロジェクト」と言えるだろう。電子書籍を自分で制作する場合でも同じだ。しかしそれは、結果として見いだされる共通性でしかない。かーそるの場合は、「かーそる」という電子雑誌を運営するという背景的な目標があって、そこから「005号を作る」といったより具体的な目標が算出される。親と子の関係になっているかどうかはさておき、たしかにそこには矢印で結べるような認識的な関係がある。
一方で、「プロジェクト」と執筆企画にはそのような関係はない。「よし、何かプロジェクトをしよう→書籍の企画だ」という認識にはなっていないのである。実際は、複数の具体的な目標があり、それらのうち共通的な性質を持つものが、「プロジェクト」と呼称されているだけだ。いわばタグなのである。あるいは、（Javaにおける）インターフェース的なものが近いかもしれない。「プロジェクト」というくくりを用いれば、それらに共通的な操作が可能になる。そんな感覚だ。
ウィトゲンシュタインの言葉を借りれば、それらの「プロジェクト」は、家族的類似性をもつに過ぎないと言える。それを「プロジェクト」というフォルダにまとめるのはカテゴリー的越権であろう。
簡単に言えば、私は「プロジェクト」→「個々の企画案」という認識を持っていない。むしろ、もっとフラットに個々の企画をとらえている。だから、フォルダの構造もそれに合わせる。そういうノリなのである。
もちろん、そうした思想的な話だけでなく、もっと実用的な意味もある。簡単に言えば、「それが正しくプロジェクトであるか」をいちいち考えるのが面倒なのである。フォルダを新しく一つ作るたびに、「これはプロジェクトであるかどうか」を考えていては、フォルダを作る手が止まるだろう。それに、プロジェクトと呼べないにしろ、todoが発生することも十分ありえる。そのたびに、フォルダの位置を変えるのだろうか。
そんな運用ベースで帳尻を合わせるくらいならば、はじめからすべてのフォルダを走査してしまえばいい。そうすれば、使うときの自分は何も気にせずにフォルダを作り、その中にtodo.mdを作ったり、作らなかったりしていればいい。簡単である。
ツールに従順な私たち
ここまでの話で考えるのだ。私たちは実に「従順」になってしまったな、と。
「プロジェクト」フォルダを作るというのは、いわばツール開発者側の発想である。そうしたほうがプログラムはスムーズに（≒無駄なく）動いてくれる。一方で、区別なくフラットに並べるのは使用者の発想である。だって、自分の認識がそうなっているのだから、そうしておいた方が使いやすいじゃん。
私が自分自身について驚いたのは、まず最初に「ツール開発者側の発想」が出てきたことである。ユーザー側はわがままをいわず、処理しやすいようにデータ構造を整えておくことが「自然である」とすら感じた。実に従順な態度だ。
たとえばこれは、Evernoteではノートブックの順番が並び替えられないから、接頭辞をつけて制御する、というのにずいぶんと似ている。「あちら側」は変えられないから、「こちら側」で融通を利かそう、というわけだ。こういう話は、ほかのツールでもたくさんあるだろうし、それがいわゆる「ライフハック」の一部を形成していたりもする。
でも、それしか発想がなくなってしまうのは、あまりにも従順すぎはしないだろうか。
なにせ私は、自作のツール≒自分自身しか使わないツールを作っているときでも、まずその発想が出てきたのだ。もう身に染みついてしまっている状態がうかがえる。
でも、プログラムが無駄多く動いていても困るのは私だけなのだ。それも１秒未満で終わる処理が、２秒くらいかかる、という話でしかない。私よりも所有ファイルが多い人ならばもっとたくさん時間がかかるだろうが、しかしその人は「私」ではない。だからぜんぜん関係ないのである。
私が自分のツールをこういう仕様にしていても、カスタマセンターに不満の声が届くわけではないし、SNSで「改悪だ」と糾弾されるわけでもない。自分がその機能を納得して使っているならば、どんな仕様になっていても問題ないはずだ。その地平では、「一般性」はほとんど冗談みたいにどうでもいい話である。そんなことよりも、まず「自分がどう使いたいか」がプライオリティーになるはずだ。
その意味で、今回のような実装は一つの「反逆」だとも言える。従順なユーザーが起こす反逆だ。
もちろん、その矛先はツール開発会社に向けられるものではない。そんなものを”打倒”したところで何の益もない。そうでなく、自分で自分の国をつくるのである。システムを整備し、ルールを制定し、そのコストを自分で引き受けるのである。言い換えれば、「自分のやりたいこと」という欲望を肯定し、それを実現するために自分の手を動かしていくのである（そしてプログラムにはたくさん無駄なことをしてもらう）。
自分の道具を自分で作る
考えてみると、そうした在り方こそが「デジタルツールが見た夢」ではなかっただろうか。
アナログツールでは一度「プリントアウト」されてしまえば、ユーザーがそれをどうこうするのは難しくなる。可能であるにせよ、その範囲は限られている。
一方で、デジタルツールはいくらでも改変が可能で、もっと言えば自分でゼロから作ることすらも容易である（工場で金型から起こすことと比較してほしい）。
「自分のやりたいこと」に合わせて「道具」を作り上げること。
それを低コストで実現できるのがデジタルツールの真骨頂であろう。しかし、いつからか私たち一般ユーザーは、ツールを「与えられる」ものとしてとらえるようになってはいなかっただろうか。まるで「お上と町民」のような関係だ。愚痴はいくらでも言うけれども、自分で何かをなすつもりはない。反抗的な態度をとり続けるという従順さがそこにはある。
いったいそれをいつまで続けるのだろうか。
もちろん、自作ツール以外を使うな、とかそういうしょーもない主張をしたいわけではない。そうではなく「自分のやりたいこと」に目を向けて、それに足りないものがあるなら「いっちょ自分で作ったるか」という気概を持つことの重要性を確認しているだけである。むしろ、そうした気概を持ち、実際に自分で小さなツールを作りはじめてみれば、既存のツールがどれほどすごいものなのかが実感されるだろう。
永田希さんが『書物と貨幣の五千年史』書かれているように、テクノロジーとはブラックボックスである。何かを見なくても目標が達成できるようにしてくれる。言い換えれば、それは私たちに目隠しを施す。それがどれくらいにすごいことなのかを隠ぺいするとともに、自分でそれがなせるであろうという可能性も隠してしまう。
だからそのヴェールをぱらっとはがそうではないか。
コンピュータ/ツールにおいて「主体性を発揮する」とは、つまりはそうことなのだろうと思う。あるいは、それはコンピュータ/ツールに限らない話なのかもしれない。
