前回は三つの要素のうち「ワンデイリスト」を紹介しました。
・ワンデイリスト
・注意オブジェクトモデル
・フラットスタイル（ヒエラルキーレス）
今回は、「注意オブジェクトモデル」を紹介します。
注意オブジェクトモデルとは
「注意オブジェクトモデル」とは、生成するオブジェクトの粒度を、自分の注意の粒度に合わせて設定する手法のことです。私の造語です。
たとえば、前回紹介した「ワンデイリスト」ですが、これは私の注意が基本的に「今日」という単位にしか向いていないことに基づいて作られています。昨日より以前は漠然と「過去の塊」になっていますし、明日以降も「２〜３ヶ月先の塊」として捉えています。
6月24日とか6月15日といった、日ごとの区切りは、むしろ「カレンダー」という装置によって発生・固定化されているものであって、それがなければ注意の粒度としては存在していません。だから、デイリーリストは「その日」しか作らないのです。
プロジェクト or not
また、タスク管理における「プロジェクト」の扱いも同様です。私の管理システムにおいて、それがプロジェクトかどうかという自問はいっさい発生しません。そうではなく、「その対象に継続的に注意を向けたいか」が問われます。
もしその答えがYesなら、その項目はHome直下に置かれますし、そうでないならば、どこか別のリストに格納されるか、消されるかのどちらかです。
よって、プロジェクト・サブプロジェクト・サブサブプロジェクトみたいな概念はまったくありません。常に、一つの塊を作るか否かが問われます。
前々から、思っていたのです。たとえば、今電子雑誌「かーそる」の作業を進めているのですが、これをプロジェクト的に管理しようと思うと、まず「かーそる」運営というプロジェクトが立ち、そのサブプロジェクトとして「かーそる第四号の制作」が位置づけられます。
あるいは、「かーそる第四号の制作」というプロジェクトが立ち、その上に「かーそる」運営というスーパープロジェクトを位置づけるかもしれません。どちらの場合でも、そこに階層が持ち込まれるのですが、その階層は私の注意にはまったく合っていません。
私の注意にあるのは、「かーそる第四号の制作」なのです。これを捉えたい。だから、それをオブジェクト（項目）として扱う。それだけです。
ここで「動く」（Flowy）が関わってきます。
注意によって階層構造を変える
たとえば、つい最近まで、Evernote上でリストを自由自在に動かすためのスクリプトを書く「リストプロジェクト」を実施していました。
で、その一部として含まれていた「Evernoteの作業記録に書いたメモをテキストファイルに切り出して、Webブラウザで閲覧できるようにする」ためのツール作りが、「Mind Garden」として独立しました。よって、今は毎日「Mind Garden」の何かを行っています。
そのとき、WorkFlowyが動くのです。
もともと親項目であった「リストシステムの拡張」から、「Mind Gardenの作成」が独立し、今度はその子項目に「リストシステムの拡張」が移動します。注意の対象が切り替わったのです。
情報整理を厳密に（あるいは真面目に）考えれば、変更後の構造はおかしなものです。少なくとも「親→子」の関係が適切ではありません。しかし、私の注意は、まず「Mind Gardenの作成」に向けられていて、その「Mind Gardenの作成」は、「リストシステムの拡張」から派生したよね、という順番になっています。その形にアウトラインも沿わせているわけです。
同様に、「かーそる」の場合でも、一番最初は「かーそる」の運営がトップに立つでしょうが、一号目、二号目、三号目とそのときどきの制作号がトップに立ち替わり、その他の項目はその項目の下位要素に移動することになります。
アウトラインを、動かすのです。
さいごに
究極的に言えば、こうした情報整理は、「気になっていること」の管理だと言えます。
だから、「気になっていること/気にしたいこと」の粒度をベースに情報を整えていくのです。
常にボトムアップで作り、そして状況に合わせて作り替えること。
これを行えば、「頑張って作ってはみたものの、使いにくかった構造」は生まれません。私の感覚から言えば、「使いづらい構造」とは自分の注意モデルと合致していない情報構造のことだからです。あるいは、「情報はこのように分類しなければならない」という断定によって作成された構造だからです。
その意味で、私のWorkFlowyはまったく整理整頓されていません。にも関わらず、すごく使いやすいのです。もちろん、私以外の人にはまったく使いづらいでしょうが、それでもぜんぜん構わないのが、個人の情報整理システムの良いところです。
（つづく）