※記事二本分まとめてみました
スプレッド
ノートという場に広げる 断片の時間
ひとつひとつをまさぐる だけでなく ひとつひとつをひとつに 編み上げる 時間を空間に移しかえて 展開させる 最適化効率化有用化して 時間に返す
ケルト十字 スプレッド
人は時間に生きるに非ず 空間に在る ノートという広場でこそ 人は自在だ
(読解)
形式の諸問題(バレットジャーナル考)
こだわったとたん、その形式に縛られたことになるからだ。縛られてはいけない。さまざまな形式を、例えば音符のように使いこなさなければいけない。音符のように、自在に組み合わせることが出来なければ、形式の意味はない。(後藤明生 『この人を見よ』p.184 幻戯書房 2012年8月12日 初版)
1.PoIC(Pile of Index Card)
GTD(Getting Things Done)という方法が日本の情報カードと出会って生まれた方式。詳しくはこちらを
PoIC : 情報カードの積み重ね(2007年9月7日 Hawkexpress) http://gihyo.jp/lifestyle/serial/01/poic/0001
もともと、GTDは、日々のタスクをいかに効率的に処理していくかを追求した方法論でした。従って「何かを蓄積していく」というタイプのものではなかったのです。
一方、日本に根付いていた「情報カード」術は、日々の気づきを蓄積しておいて、必要に応じてそれらを取り出し、並べ替え、新たな気付きを見出そう、というものであり、効率的なタスク処理のためには、別の方式の導入が必要でした。
タスクは、時系列順に並べられるべきであり、未処理のタスクは次々と相応の未来へ送っていかねばなりません。また同時に、締め切りを厳守しなければならないものについては、リマインダー機能が必要不可欠です。
2.デジタルとアナログ
PoICをEBT light for zaurus上で運用するためのスタディ(2013年8月)
ノートとペンによる方法と、電子端末でソフトウェアによって運用する方法との、最も大きな差は、「一覧性」であり、これは「検索性」と「リマインダー機能」に現れると思います。
GTDでは、カレンダーという(紙的)フォルダがあり、締め切りがあるタスクについてはそこで一括管理します。これは、卓上カレンダーなどへ「転記」することによって、一覧性(リマインダー機能)を補完します。
PoICにおいては、このカレンダー機能が実装されていなかったため(原則として全てはカード作成の時系列順)、なんらかの、カレンダー的ドックを導入することになります。
参考1 Re:PoIC~ライフハッカーのためのPoIC入門 第4回 GTDとPoIC~相補完する思考第4回(2008年3月13日 野ざらし亭)http://gihyo.jp/lifestyle/serial/01/re-poic/0004?page=2
参考2 Poic マニュアル v3.5 http://pileofindexcards.org/wiki/index.php?title=%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8 より「43TABの実装について」
これらをデジタルで行う場合には、以下のソフトが有用でした。
PoIC+43Tab風運用→EBT light for zaurus http://seesaawiki.jp/irrational/
GTD(リマインダー機能)+PoIC→howm for linux https://howm.osdn.jp/index-j.html
しかし、現在はほとんど活用できていません。やはり、ノートとペンという方法には、汎用性と安心感があるのです。(バッテリー問題や、端末への依存度に不自由を感じてしまいます)
3.マーク(バレット)と転記による補完
では、アナログ派は「検索性」「一覧性」「リマインダー機能」をどのように補完すればよいでしょうか?
参考 100円ノートの「超メモ術」 http://www.kirari.com/amz/note/
バレットジャーナル
最近バレットジャーナルがシェアを広げているようです。これは、タスク特化型の方式として、カード運用されていたGTDをノート上で運用する方法論の一つだと思います。
『「ラピッドロギング」では、バレットを用いて箇条書きしていきます。箇条書きの各項目は全て、客観的な短文で描いて下さい。』
(バレットジャーナル公式サイト「入門ガイド」日本語訳 2017年07月28日 2017年08月22日)http://bujo-seikatsu.com/2017/07/28/getting-started/
GTDでは、気になることを書き出したら、それらひとつひとつを、実現可能な小さいタスクに分解してから「整理」する(各処理へ振り分ける)ことになっています。
参考:はじめてのGTD 田口元 ITmedia http://www.itmedia.co.jp/bizid/articles/0606/27/news003.html
GTDが定める厳格なフローチャートのスタディ(2013年8月)
GTDではこれらのタスクをいくつかのフォルダに分類し、処理した後、定期的に「収集」という方法によって進捗状況を更新します。
一方、ノート上で完結させるバレットジャーナルでは、各バレットに付加する・×(完了タスク)、・>(移動タスク)、・<追加タスク、などの記号と、これらの「見返し」による「転記」によって、この処理を実現します。
カード式とデジタル式には不要で、ノート式の場合に必要となるのが、この「転記」作業です(「インデックスページ」の準備も、ここに含まれます)。
これを手間ととるか、「一覧性(銘記性)」と「リマインダー機能」の強化作業ととるかで、好みが分かれるのだと思います。
4.「タスクの書き出し」こそが最大のポイント
GTDにおいて、もっとも重要なものは、「収集」で、今頭の中にあることを、週に一回、1時間以上かけて100個位は書き出すことが推奨されています。そのための「トリガー」も用意されており、とにかく、頭の中のもやもやを空っぽにすることが第一の目的なのです。
タスクの効率的実行を目的とするバレットジャーナルの「基本マニュアル」では、この工程が弱い気がしました。タスクとなる以前の塊を広げる場が、用意されていないからです。
イベントは、例えば「チャーリーの誕生日」や「リースの契約日」など、日付が重要となる項目で「○」で表します。イベントは、ラピッドロギングが可能になるように客観的&手短かに書かなくてはいけません。それがどんなに主観的・感情的で厄介なことでもです。もしそのイベントについて詳しく書きたいのなら、別ページに好きなだけ書いてください。ここではあくまでも「ラピッドロギング」方式でシンプルに書きます。(同上 バレットジャーナル公式サイト「入門ガイド」日本語訳)
GTDでは、「収集」した項目を、「整理」する過程で、「タスクの細分化」と「タスクの性質の判断」を同時に行わなければならない点がネックとされています。
その点、バレットジャーナルは、いきなり「整理」から始まっているように思われ、その根本となる「箇条書きすべき内容」を確定すること自体に、困難を感じるように思います。
もちろん、バレットジャーナルでは、無数のモジュールが可能なので、GTDにおける「収集」的モジュールを、別の場に設けることで、解消できるでしょう。
5.アイデアの収集と蒐集
PoICは、「収集内容を情報カードとしての蓄積」します。日々の気づきも重要ですが、集中的に行いたい場合に強力な「トリガー」となるのは、ブレインストーミングの諸方法、「マインドマップ」や「マンダラート」といった、発想法などです。
情報は蓄積され、相互に関連付けられた時に「知識」となります。
前述したEBT lightの、「無階層の双方向リンク機能」や、howmの往復リンク+wikiタイプリンク機能は、作者さんの「知識」に関する深い洞察によって組込まれたものです。
ブックタイプのインターフェイスでこの機能を担うのはさしずめ「索引」でしょうか。しかし、この機能をアナログノートで実装するのはひじょうに困難です。
日付、ページ数、行番号などの記載を徹底化し、>>や、<<や、==などの記号欄をもうけ、その内容を「索引ページ」に記していく。それはまさに、「私家版ビブリオマシーン」の制作といえるでしょう。
書いたことを覚えておけばいい、というのでは、頭を空っぽにした意味がありません。
一覧機能やリマイド機能や索引機能。これらはみな、「検索」にかかわるテーマです。ノートの検索性の向上する形式とは何か?これは今後も課題でありつづけるのではないかと思います。
参考 MIDORI検索ノート http://文房具大図鑑.com/note/midori-kensaku-note/
(前略)こだわらないための形式。縛られないための形式。その矛盾こそ自由だからである。その自己矛盾こそ、そもそも形式というものだからである。(同前書 p.195)
おまけ(2013年のトラベラーズノート)
1)今回掲載した2013年のトラベラーズノートの図版では、ジェットストリーム0.7をメインに使っていた。時間がたつと、ページ全体が油紙のようになり、裏抜けは致命的となる。
2)当時の利用状況としては、余白もおおく、横書きメインで使用していた。PoICを導入しようとしていて、タイムスタンプと、PoIcマークを義務付けていた。この後から、「リンク記号」を赤のuni signo 0.28で書き込んだりしている。
3)ノートの読み返しは、頻繁に行っており、EBT light や、howmへの入力(転記)も積極的に行って、全文検索などによる検証を繰り返していた。