Noratetsu Lab

　タスク管理は何のためにやるのか、というお話がうちあわせCastであった。

• 第百六十八回：Tak.さんと何のためのタスク管理か - 知的生産の技術

　少し考えてみたが、個人的には「養うため」というのが一番収まりがよいかもしれない。（今自分で考えて書いているけれど、他に誰かは言ってそう。）
　「養う」にも色々あるが例えばこういうこと。

• 自分および家族のいのち
• 人生の納得感、コントロール感
• 自身の有能感、自己肯定感
• 自分の能力

　まず第一に、自分や家族が生きられるように養っていかなくてはならない。仕事がうまくできないということは、昇進できないかもしれないしクビになるかもしれないし仕事が取れないかもしれないし会社が潰れるかもしれないということだ。そうすると文化的な暮らしはできなくなっていくし、いのちすら危うくなる。収入が減らないようにするために仕事をうまくやらねばならない、というのがタスク管理の大前提だろう。
　働き続けるためには働けるような精神状態を保っておかなくてはならないので、その意味では「怒られないようにする」といったことも重要な要素である。（怒られたくなさで倫理を無視してはまずいけれども。）
　切羽詰まっているとか生存以外の欲がないとかであれば、自分や家族を養えれば達成ということになり、それ以外の意味合いはタスク管理に伴わないかもしれない。そして別に管理しなくても養えるなら（あるいは自分が養わなくてもいいのなら）そもそもタスク管理は不要だろうと思う。

　生き物としていのちが続くことを確実にできたなら、次は精神面の健康を養う必要がある。
　不満があったり不幸を感じていたりすれば、寿命まで生きるには生きたが生きた甲斐がなかった、ということになりかねない。それを回避するためには、自分の生活に納得すること、社会を構成する一個体として十分な存在であると思えることが必要だろう。
　つまり、自分の生活がどういうものであり、自分は何を選択しているのか、そして実際に何を成してそれが社会でどういう意味を持っているのか、ということを把握し管理することで不満から脱出するよう試みるわけである。この意味では、誰かを養う身分でなくともタスク管理というものは有用ということになる。
　ただしこれらは、例えば「どう生きたって人はどうせ死ぬのだ」的な考えに納得しているならば必要ない要素であろうと思う。幸福感の欠如に悩まされていないのならわざわざ自分の選択や存在意義に思い巡らさなくても構わないだろう。

　更に、生存を確かにするためにしろ幸福感を確かにするためにしろ、ただ現状をどうにかしているだけでは足りなそうならば、環境を変えるためにまだ自分にない能力を新たに養う努力をしなくてはならない。そのためにはその努力をするのに必要な時間や資金を捻出する必要がある。（ここでの「能力」というのは、いわゆる「スキル」だけでなく「思考回路」も含む。新たな考え方も新たな能力ということである。）
　となると、既にあるタスクと開拓のためのタスクを合わせて管理して日々を設計することになる。これは頭の中だけでやるのはかなり難しいので、実際的なタスク管理の必要に迫られる。必要な行動は何で、それをいつまでにどのようにどの順番でやっていかなくてはならないのか、そういったことをどこかに書き出して検討して決めていく工程は必須だろう。

　まずいのちを養う。現状で頑張っても駄目そうなら新たな能力を養う。いのちが安泰なら精神を養う。現状でやっていっても幸福感が足らなそうなら新たな能力を養う。それを着実に実行していくために、自分の頭の中だけでは足りないようならタスク管理ということをする。
　いずれの意味でも養う必要がない、または養うにあたり改めて把握と管理をする必要に迫られていない、という状態ならタスク管理は多分要らない。

　タスク管理は、タスクの実行を最適化する手段であると同時に、それらのタスクを検討・実行している自分自身の姿が可視化されるという副産物をもたらすものである。
　タスクの選択や可視化された自己の解釈には、タスク管理そのものとは別の営為が必要であり、それが例えばミッション・ステートメントやTak.さんのライフ・アウトラインの「LIFE-BE」「LIFE-AS」といったものということになるだろう。どう実践していけば本当に自分に有用かというのはよくよく勉強と検討を重ねていく必要がある。
　ということを考えた。

先日の問いかけに早速お答えいただきありがとうございます。重要な気づきを得られたと思います。
苦手なことはどこに整理したらいい？
このこと、つまり自分のネガティブ要素（≒欠点）とその対応の検討場所について二つのことを考えました。

　こちらを拝聴した。

• 第百五十七回:Tak.さんと『思考のエンジン』読了について - 知的生産の技術
• 第百五十七回:Tak.さんと『思考のエンジン』読了について - うちあわせCast - LISTEN

　その中でタイプライターやワープロといった書くための専用機の話があった。（なお『思考のエンジン』については私はまだ冒頭をちょっと読んだところで止まってしまっている。）
　同年代の中ではもしかしたら珍しいかもしれないが、私はタイプライターもワープロも触ったことがある。タイプライターは母親が持っていて、ワープロは電子レンジみたいなサイズのごついものを父親が持っていた。小さい頃だったのでそれで何か文章を綴るということをしたわけではないけれども、どういうものかくらいは一応理解している。
　特に何が言いたいということもないけれど、この機会に記憶を辿ってみようかと思う。

　タイプライターの愉快なところは、ボタンを押すとガチャンと文字の判子が捺されて即座に印字されるところだ。アナログだが機械的で、もはや道具としてそれを使う必要性を失った今の時代からすると、シンプルに「面白い」感じがする。
　今はアナログイコール手書き、デジタルイコール印刷（もしくはデータのまま）、というふうな住み分けになっているから、電気を使わずに「ボタンを押すと、印字される」という機構とは縁遠くなっている。
　日本語が打てないことを考えるとタイプライターは後のワープロやパソコンほど手書きの代替になったわけではないのだろうし、母語のタイプライターがない人間にとっては単純に「手書きとワープロの間」と言えるものではないが、もしも自由自在に日本語が打てるタイプライターがあったとしたら、「間」のものとして働いて情報管理における紙の扱いはかなり違ったものになるのだろうなと思う。今でもただ綺麗な統一された字体で表現したいという理由だけで印刷をしたくなることは普通にあり、それを叶えてくれる簡単な道具があったらアナログのテクニックはもっと豊かに育っただろう。
　タイプライターについて母親が繰り返し話していたのが、「打つのが速すぎるとキーのアームが噛んじゃうんだよ」ということだ。それを防ぐために今パソコンのキーボードでもお馴染みのQWERTY配列が生まれたという説があるが、打鍵速度に気を使わなくてはならないというのは今のキーボード入力とはだいぶ異なった感覚だなと思う。打鍵速度が指を動かせる速さの限界まで高められるということもデジタルの利点なのだ。
　タイプライターに初めて触った時、私はピアノのようだなと思った。無個性に並んだボタンを押すと、「文字を打つ」という範囲内でそれぞれ違った結果が現れる。ピアノの鍵盤が「ひとつの音を出す」という範囲内でそれぞれ違った結果を生じるのと同じように感じたのだ。今パソコンのキーボードに対してそういうある種詩的な感慨というのは全然抱かないのだが、それは「操作」という動詞に寄り過ぎているからかもしれない。パソコンのキーボードはパソコンの処理を操作するためのものだが、タイプライターのキーやピアノの鍵盤には何かを「操作する」ためのものという印象は持たない。あくまで「書く」「弾く」ためのものである。

　父親が持っていたワープロは、今見たらまた違う印象になるのかもしれないが、幼少の私からするととにかくでっかい塊という感じだった。前面のカバーが手前に開くようになっており、その内側の部分がキーボードになっている。
　今なら大抵キーボードが本体側で開く蓋の方がディスプレイであり、まあどっちを動かすかの違いに過ぎないが、手前に倒したカバーがそのままキーボードになるというのは今考えてもちょっと面白く感じる。箱に画面がついている、というのはブラウン管テレビと似たような見た目だし、その時は画面というのは本体と一体という印象が強かったなと思う。その後登場した薄型ディスプレイには「画面って薄くなるの！？」という驚きがあったのを覚えている。
　ワープロの黒い画面の右側にはフロッピーディスクの挿入口が二つついていたと思う。そしてその隣にはフロッピーディスクを数枚収納するための空間があった。「置き場」があるというのは小型化が徹底される今となってはあり得ない工夫かもしれない。でも便利だったと思う。
　ワープロは印刷機を兼ねていたから、上面に紙を差し込んで横のツマミをくるくる回してセットして、インクリボンなるもので文書を印刷できた。当時はリボンというのはアクセサリーや包装に使う平たい紐のイメージしかなかったから、ワープロという無機質な機械とリボンという華やかな装飾品が言葉として結びつかずに混乱したことを覚えている。
　父親がそのワープロを使って具体的にどのような仕事をしていたのかは全然わからないのだが、私が触っても良かったフロッピーディスクの中には父親の書きかけの物語が三つほど入っていた。いや、書きかけともちょっと言い難いようなごく短い冒頭部分だけだったのだが、父親が物語を書くことを試みていたということはそれで私は知ったわけである。内容も文体も子ども向けという感じだったから私のために書こうとしていたのかもしれないけれど、完成させる時間か気力かその両方かが足りないままに私は育ってしまった。もしかしたらそれらについて何らかのやり取りを父親としたかもしれないが、とりあえず覚えていない。
　それらが結局どういう話になるはずだったのかはわからないが、当時の私はお話を作るということをまるっきりの無から有を生み出すことのように感じていたから、書き出しだけでも創造したことには素朴にすごいなと思っていた。
　ちなみに私は後に言うアスキーアートのようなものを描いて遊んでいた。幼すぎて文章は書けなかったから、記号でお絵描きしていたのだ。その分だけどんどん巧みに……ということは特になく、いつまでもいくつかの決まった記号を並べるだけだった気がするが、楽しんで遊んでいたということは覚えている。

　そういえば、当時のワープロは黒い画面に白い文字だったから、今で言うダークモードが当たり前だった。私にとってはそれは如何にもデジタルな、しかも初期のデジタルという印象が強い。ドラゴンクエストのコマンドも黒い背景に白文字だ。子どもの頃に見たデジタルっぽいものの印象と「黒い背景に白の文字」ということが私の中で強く結びついている。ワープロでは文字列の選択部分が白背景に黒文字になっていたが、その状態はあまり綺麗には見えなかった。
　今私はなんでも極力ライトモードに設定しているのだが、かつて家にやってきたWindowsの画面で白い背景に黒い文字が美しく映ったことに感動したのをずっと引きずっているのかもしれない。

　うちあわせCastのこの回を聴きました（結構前に聴いていました）。

• 第百六十回：Tak.さんと生活におけるプロジェクト管理について - うちあわせCast - LISTEN

　この中でCapacitiesでプロジェクトを扱うことについて語られていましたが、自分の感覚とかなり違う気がしたので、どこが違ってそれがどこから生まれる違いなのか考えてみたいと思います。（批判や正解探しということではなく単純に「何が異なっているのか」の分析を試みるということです。）

オブジェクトを全て「～についてのノート」と思っている

　倉下さんのお話の中で「プロジェクトについて書いたノートオブジェクトがある」という話がありました。ここにまず捉え方の違いがあるようです。
　Capacitiesのオブジェクトタイプは、TagやWeblink、PDFなどのベーシックなオブジェクトを除いて全て「Pageオブジェクトの派生」と解釈しているので、私の中で「○○オブジェクト」は「○○についてのPageオブジェクト」ということになります。
　ベーシックオブジェクトは、例えばPDFオブジェクトがPDFそのものを扱うもの、imageオブジェクトが画像そのものを扱うものであるように、オブジェクトが実物です。そこにノートを添えることもできる、という形です。しかしカスタムオブジェクトでは実物を扱うということは基本的にあり得ません。Bookオブジェクトはあくまで本についてのノートであって、Capacitiesの中に本そのものは存在しないわけです。
　プロジェクトももちろんそうです。本そのものや人物そのものがCapacitiesの中に収まっているわけではないように、プロジェクトそのものがCapacitiesの中に存在するということはあり得ません。常に「それについてのノート」の形になります。
　個人的にはそのように認識しているので、「ノート用のオブジェクト」というものは生まれず、Projectオブジェクトは「プロジェクトについてのノートというオブジェクト」ということになります。

プロジェクトを単に「ノートが必要な『やること』」と思っている

　プロジェクトという言葉をどう定義するかというのは、生活・仕事の前提によって大きく変わってしまうところだと思うのでなんとも言えませんが、私がCapacitiesでProjectオブジェクトを使う時というのは、単純に「ノート部分を必要としている『やること』」を扱う時と言えます。
　そして基本的には「完了できるもの」です。ただし断続的にやるものについても、場所を分けることにメリットがないという意味でProjectオブジェクトで扱っています。しかし「完了がないもの」の取り扱いは割合としてごく一部です。なお、例えば「本を読む」「掃除する」「語学を習得する」のような基本的な動詞で表される習慣的なもの、スキルアップを目指すものはProjectオブジェクトではなくDoingオブジェクトというものを作って扱っています（Capacitiesのマイオブジェクト⑥ セルフマネジメント系）。
　また、ルーティン以外のほぼ全ての「やること」が、Projectオブジェクトになっているか、またはいずれかのProjectオブジェクトの中に含まれる要素かになっています。よってデイリーノートのToDoリストにはProjectオブジェクトのリンクが並んでいるということになります。ToDoリストはアウトラインになっていますが、①リンクのノードそのものにチェックボックスがついているパターン、②リンクノードの子項目にチェックボックス付きの小タスクが並んでいるパターン、③リンクノードを子項目としたチェックボックス付き親項目があるパターンがあります。

　Capacitiesは現状全文検索が役に立たないという実用上の問題もあって^[1]、情報をオブジェクトから辿れるようにしておく必要を感じており、基本的に全ての「やること」がProjectオブジェクトのタイトル、本文、バックリンクのいずれかで把握できるようになっています。
　あるProjectオブジェクトが、他のProjectオブジェクトのサブタスクになっていることも偶にあります。プロジェクトは入れ子になり得るというのは前にも考えたことがありました（タスクとプロジェクトを考える）。ただ、今のところは「偶に」で、基本的にはフラットになっています。タスク群を一通り完了することで意味をなす、その「一通り」を粒度としてProjectオブジェクトのページを作っている形です。なのでページ本文の文量はプロジェクトごとにかなり幅があります。本文が一行で終わることもあれば、トグルを多用して長文を畳んだり規模の大きいアウトラインを作っていたりのこともあります。

サブジェクト基準でプロジェクトにしていない

　ここまで考えて思ったのは、多分ですが私はCapacitiesに於いてはサブジェクトをProjectオブジェクトとして扱ってはいないのだろうということです。（「サブジェクト」の理解に自信がありませんが、多分。）
　何をどうしていきたいか、ということはライフ・アウトラインの中に含まれるものと見なしています。実際にライフ・アウトラインの場に書いていることもあれば「本来あるべきはライフ・アウトラインの中なんだよな」と思いながらデイリーノートやフリーライティングの場に書いたきりになっていることもありますが、ともかく思いやテーマについては「最終的に存在すべき場所はライフ・アウトライン」ということを前提とし、そこから生まれた具体的な「やること」がProjectオブジェクトになります。何をもって完了とするのかが見えた時点でProjectオブジェクトとして形を持ちます。

　認識の個性の違いが明瞭になったかどうかはわかりませんが、そんな感じで私はCapacitiesのProjectオブジェクトでプロジェクト（と私が認識している塊）を扱っています。

---

1. その後だいたい解消しました。
   Capacitiesで日本語での全文検索が機能するようになりました（多分） ↩︎

情報整理のいろいろ - by 倉下忠憲@rashita2 - トンネルChannel
言及いただきありがとうございます。私の元記事の当該部分は少し自分の言いたいことに引き寄せすぎた書き方をしていてあまり適切ではなかった気がします。

　以下の記事を読んでいて、私は結局どういうシステムを働かせて動いているのだろうか、と考えた。（※記事の内容自体の感想ではありません）

• ノウハウコンテナ宣言 | R-style
• 私的なノウハウの名づけ | R-style
• ブラッドによるTimeline system - by 倉下忠憲@rashita2
• タスクとメモの統合ツールとしてのアウトライナー（あるいは現代的な「手帳」）｜Tak.

　このツールでこうやっている、ということをその都度描写しても「つまるところどういうシステムか」が自分でもはっきりしてこない。もう一段抽象の階段を昇らないといけないのだろう。

　そういうことを考える時に、まずどこにどう書いて考えるのか、それもはっきりしない。というのは、考えようとしている領域を指し示す呼称がないからだ。もちろん、単に考える場を作るという意味ではどのツールでもいいから「私は結局どういうシステムを働かせて動いているのだろうか」という項目なりページなりを作ってその中に書けばいいのだが、名前がないと考えた結果を取り扱いづらいし多分継続的に考え続けられない。
　そしてシステムの様子を反映した適切な名前をつけるには全体像がわからなくてはならないので、事前には特徴を示した名前はつけられないということになる。メソッド風の名付けを目指す前に、結局何をどうするシステムの話なのか、ということで一般的な名称を用意する必要がある。ブレストしてみよう。
何を：情報、メモ、ノート、タスク、生活
どうする：管理する、取り扱う、回す、流れさせる
　やっていることは情報の管理ではあるけれども、情報管理という表現は実際の雰囲気から離れているような感じがする。情報を管理する目的は生活および頭の中をうまく回していくことで、語感に生活感が足りない。また情報の範囲についても、この場合自分の生活のための情報ということなので、単に情報とかインフォメーションとかいう表現だと大仰過ぎる感がある。
　資料庫の管理人をやっているのではないので、自分が取り扱いたいものというのは自分の手で作ったか集めたかした情報であり、『すべてはノートからはじまる』を踏まえるとそれらは全て広義のノートであると言える。とはいえ自分が生成または収集したものなのだから、広義と言ってもより一般的意味合いの「ノート」に近いものだ。例えば会社の書類を「ノート」とは言いづらいし、「ノート」という表現をするだけで、個人的なもの、属人的なものという印象が生まれるように思う。
　ということで、自分が考えようとしていることを「ノートの流れ」、つまり「ノートフロー（note flow）」と表現することにした。ChatGPTに「これこれこういうことを指してノートフローと言い表そうと思うがどうか」ということを尋ねたら「英語的にも自然だし良いと思うよ！」という旨が返ってきたのでこれでよしとする。
　これまではこの種のことを「ノートツール環境」と表現していて、このサイトでもノートツール環境スナップショットというタグを付けていたが、ツールがどうというより「書かれたものの流れ」が重要なので「ノートフロー」の方が良いだろう。

　早速Capacitiesに「私のノートフロー」というページを作る。オブジェクトタイプはMapオブジェクトにしておこう。これで私の中でこの領域を「あれ」と指させるようになった。（MapオブジェクトなるものについてはCapacitiesのマイオブジェクト⑥ セルフマネジメント系で書いた。）

　ノートフローの姿は頻繁に変化するのでバージョン管理したいところだ。しかしver.1とかver.2とかやると、どこを1にするのか、それ以前のものはどうナンバリングするのか、という問題が発生するので、年ごとに「2024年のver.1」といった風に捉えるのが無難だろう。
　今現在がバージョンいくつになるのかわからないので、とりあえず「2024-xx」としよう。例えば3段階目だなと判明したら「2024-03」という感じにする。そしていつの話なのかわかった方がいいので、日付をリンクしておく。

　何月何日版というふうに表記する方法もあるが、そうすると前後に書かれているものが繋がっているのかそうでないのか曖昧になるので、通し番号を打てたほうが良いと感じる。
　2025年のver.1は、元日に改めない限りは2024年の最終バージョンと同じものになるだろう。なので「＝2024-xx」とか書いておく。

　こんな感じで書いていけばノートフローのフローが明快になる。だがしかしこれだけでは足りないのだった。抽象化・一般化を試みる場が必要だ。上の方に場所を作ろう。

　今考え始めたことなので内容はまだ適当。そのうちまとまってくるはずだ。
　以後は定点観測的な内容や一般化したものを「のらてつのノートフロー」と称して記事にしたら良いだろう。
　

　こちらの記事を読みました。

• 目次(TOC)と索引(Index)の違い - by 倉下忠憲@rashita2

　本をイメージすると目次と索引の違いは明らかなのに、デジタルツールのリンクの仕方で考えるとびっくりするほど曖昧な感じがします。曖昧であることにこの記事を読んで気がつきました。

　目次の役目を果たすものについてのこの一文に膝を打ちました。

たとえばそれはEvernoteで言えばノートブック（or スタック）であり、Obsidianで言えばvaultの中にあるフォルダです。すべての情報は、必ずこの中に入っているのですから、網羅的と呼んで差し支えないでしょう。
　言われてみれば半ば当たり前の話です。しかし「これは実質目次だよね」という意識を持ったことがなかったので、確かにそうだという感動がありました。
　ネットワーク型の情報管理が流行る中、階層構造での管理は欠点が目立ってどこに行っても批判されているような状態ですが、しかし完全に階層構造をなくすことに私は不安感がありました。それはつまり、「目次がない」あるいは「地図がない」という心許なさだったのでしょう。

　目次の役割は「順番と網羅性」、索引の役割は「重要な情報へのアクセス」。その根本的な違いゆえに、ひとつのやり方で両方を兼ねようとするとうまくいかない。その通りだなと思います。

本に目次と索引があるように、デジタルノートでもその二つは別にあっていいのです（なんなら目次はなくても構いません。Cosenseはそうなっています）。
　リンク、タグ、フォルダ……そういった情報の結びつけの手段はそれぞれどういう意味を持ち、自分がそれぞれにどういう役目を持たせたいのか。そのことを考える上で、目次と索引という二つのイメージは大きな手がかりになるように思います。

　記事が言わんとしていることからは離れますが、多分、「目次はなくても構いません」と思える人と、そう思えない人がこの世に存在しているように思います。私は思えない側の人間です。
　ゆえに、目次となりうるものがない、そして自分で作りにくいツールとは相性が悪いのでしょう。自分が扱いたい情報の中でも「これは目次は要らない」と積極的に思える種の情報しかそういったツールでは納得できないということになります。そういう情報も一定量ありますが、全体からすると一部に過ぎません。（あくまで個人の感覚の問題です。）
　で、更に混乱を招くことになるのが「分類」と「目次」の境界の曖昧さです。こうして適切な言葉を与えて並べれば明らかに異なるものですが、「なんかこう、括って並べたいんだよ」みたいな気分でフォルダ分けをしたりするとこの境界はあやふやになります。「分類」は明らかに「索引」とは異なりますが、しかし「順番と網羅性」が必須とは言い切れないことから「目次」とも違うものです。「目次」に近い「分類」も、然程近くない「分類」もあり得るでしょう。

　さて、ここで最近私が重用しているCapacitiesについて考えてみます。
　Capacitiesでは全ての情報がいずれかのひとつのオブジェクトタイプに属します。そのオブジェクトタイプは縦に一列に並びます。各オブジェクトタイプには更にコレクションという括りがあり、これもオブジェクトタイプの下位に順番に並びます。その状態について「目次」という言葉は想像しませんが、しかし「順番と網羅性」が示されているわけなので、倉下さんの言う「目次」の役割はこのオブジェクトタイプのリストが担っていることになります。
　そしてオブジェクトタイプのリストの上にはピン留め欄があります。これはつまり特定の情報にピンポイントにアクセスするもので、「索引」の役割を果たしています。本の巻末のように大量に並べると使いづらいかもしれませんが、性質としては「索引」に類するものということになるでしょう。また、Capacitiesではタグやコレクションをピン留めすることもできるので、本の索引が一つの項目について複数の参照先を表示するのと同じような機能を持つこともできます。
　ピン留めだけでなく、特定のページにリンクを貼って並べることでも「索引」を作ることはもちろん可能です。実際にそのようにしているページもあります。

　このようにCapacitiesは自然と「目次」と「索引」をそれぞれ扱えるようになっているわけですが、それで万事解決というわけではありません。というのも、「目次」として並べたい括りというのは「オブジェクト」とは限らないからです。よって、オブジェクト的ではない情報で、かつ「目次」にする必要のあるものは別の適切なツールが必要ということになります。
　そこで私は先日紹介したSoulLinkMapに行き着いたということになるわけですが（SoulLinkMapとの出合い）、CapacitiesにしろSoulLinkMapにしろ、未だ嘗てない納得感があるその背景にはこの「目次」と「索引」の必要性およびそれぞれの使い分けの問題があったのだなということに、この記事を読んだことで気がつくことができました。
　

　うちあわせCastを拝聴していて、B6サイズがちょうどいいのに汎用的なバインダーがないんだよね、というようなお話があった。

• 第百六十三回:Tak.さんとカード法について - 知的生産の技術

　私もB6は絶妙なサイズだと思う。普段A5を使っているけれど本当に手に馴染むのはB6だし、今使っているバイブルサイズのシステム手帳は外側のサイズがちょうどB6なのでなんとなく触っていて好ましい。（以前にも書いたことがある→「システム手帳×A6紙」というプチ革命）
　中身がB6紙のバインダーとなると、外側はA5紙くらいのサイズになるだろうか。A5バインダーの横幅の広さと比べればそれでもかなり細身に感じられる気はする。

　B6のリフィルとかバインダーって確かに見たことないよなあ……と考えていてふと思いついた。A5バインダーを切っちゃえばいいのではないか？
　あまり立派なのは勿体ないし加工も難しいのでやめておくとして、百均に売っているようなややペラっとしたバインダーならカットしようと思えばできる。というか、かなり前の話だが『「超」整理法』に感化されて「超」整理手帳の真似事をしようとして、Z式バインダーを切って使っていたことがある。A4を四つ折りにしたのがちょうどぴったりになるように上も横も切り落としてしまったのだ（留め具で挟むための幅があるので実際の幅は三つ折りに近い）。その試み自体はまあお遊びのようなもので実用的というわけではなかったが、面白いことをやってみた感はあった。
　話を戻そう。A5バインダーを流用してみるとして、B6紙に自分で穴を開ける場合、上下の端は微妙なことになる。まず中央揃えで穴を開けた場合（綴じ具側の方に注目）。

　端の穴が半端に空いてしまう。雑さが気になる人はもうこの時点で「無理！」ということになるだろう。次にキリの良いところで穴を開けた場合。

　紙の方は綺麗だが、綴じると位置が片側に寄るわけなのでちょっと気持ち悪いかもしれない。もしバインダーの幅を少しでも細くしたいなら、片側の空間を付箋などのスペースにあてて横幅をギリギリでカットするという手もある。
　なおB6紙用にカットする場合、バインダーの幅としてはやはりほぼA5になるだろう。A5紙と並べるとこうなる。左端はバインダーの背を立てた状態に合わせてある。

　更に強硬手段に出るなら、A5リフィルを裁断機でB6の幅にカットして使うという手もある。この場合は別にB6にこだわらなくてもいいし、そうして自分の好きな幅のリフィルを強引に生み出すという選択肢はなくもない。裁ち落とした部分が勿体ないので余程強いこだわりがないとやりづらいが、いざとなったら安価に自分仕様のものを作れるには作れるということになる。
　毎日使うものであればちゃんとしたメーカー品を購入できるということはとても大事なことだし、なんでも自前で済ませればいいという話ではない。なによりこういう力技は他の人には薦められない。けれども頭の体操としてこういうことを考えてみるのも面白いし、実際にはやらないとしても考える中で得るものはあると思う。

　個人的には今現在用途が見つからないのと、リフィルの類の扱いには慎重になっていることもあって実践の予定はないけれども、いざとなればやれなくもないなという気づきは少し頭を柔軟にしてくれた気がする。

　前回の記事（デジタル手帳会議）から話を膨らませていただいたこちらの記事を読みました。

• デジタル手帳術 | R-style
• デジタル三術法 | R-style

　これは、デジタル手帳術、デジタルノート術、デジタルファイル術の三つの視点で「デジタルツールを扱う」ということを説明しようとする試みと言えるだろうと思う。つまり、デジタルツールそのものにデジタル手帳とかデジタルノートとかデジタルファイルといった呼称を与えるのではなく、デジタルツールを使うという行為の方にいくつかの切り口によって名称を与える試みである。
　そうして考え出された三つの名称を見ると、一周回って普通のことに見えてしまうのだが、一方でこれがなかなか当たり前ではないとも感じる。

　ところで、この区分けは前に自分もやったような気がしないでもないと思って記事を探したら、以下の二つを見つけた。

• タイムライン型・カード型・デスクトップ型①～タイムライン型とカード型を使い分ける～
• タイムライン型・カード型・デスクトップ型②～デスクトップ型～
• 内容をまとめた用語集ページ→タイムライン型・カード型・デスクトップ型

　名前は違うが、指し示したい領域としてはだいぶ重なるところがあると思う。問題意識が別のところにあるので話の内容としてはドンピシャではないけども。
　なおこの分類については当時倉下さんに別の観点で整理し直していただいた。

• 情報ツールの時間性 | R-style

　時間軸に沿う・沿わない、終わりがある・ないの二軸でマトリクスができ、そのうちの三つの領域が私の出した「タイムライン型・カード型・デスクトップ型」、倉下さんの表現では「タイムライン（ジャーナル型）・非時間/恒久（カード型）・期間（プロジェクト型）」ということになる。

　さて、表まで作って可視化したけれどもこれについては置いておいて、デジタル三術法のほうに話を戻すことにする。今のところ私もこの三分類に「確かにその通りだな」と納得している。
　倉下さんは以下のように仰っている。

よく言われる言い方を拝借すれば、デジタル手帳術がセルフマネジメントであり、デジタルノート術がナレッジマネジメントになる。
そうファイルだ。資料などを束ねておくためのもの。「ナレッジ」そのものというよりは、それを表したもの。そうしたものの扱いも、ビジネスワーカーには必要だろう。とすれば、「デジタルファイル術」が三つ目の術法としてあがってくる。
　前者二つと後者に性格の違いを感じ取ったのだが、何かと考えてみると、「捕捉」と「把握」の違いではないか。情報が失われてしまわないために必要なものと、情報を使えるようにするために必要なものである。そしてそれぞれ姿が違い、取り扱い方が変わってくるということになるだろう。
　手帳術は元々両方に跨っているが、手帳術をその二つの性格で分割することには意味はなく、自分の生活を司るものとしてまとめて扱ったほうが現実的であろう。
　ナレッジについては倉下さんがお書きになっているように、「ナレッジそのもの」と「ナレッジを表したもの」の二つのものを扱う手法がそれぞれ必要だ。これは結構難しい問題である。
　例えばEvernoteは全部をまとめて扱えることが売りだったが、実際には「ナレッジを表したもの」の収集・保管、つまりデジタルファイル術のツールとして使うことに落ち着いた人が多いのではないかと思う。今でもその点に於いてはEvernoteは他の追随を許していない気がしている。一方でデジタルノート術のツールとしては挫折して他のアプリケーションに移っていったユーザーが少なくないと推測する。そして当のEvernoteはデジタル手帳術をカバーしようと進化（？）してきたように見えるが、それが功を奏しているのかは微妙なところだ。
　Notionも全部を扱えるようになっている。手帳的運用もノート的運用もEvernoteより自然にでき、全ての問題がNotionで解決したという人はかなりいるのではないか。
　私自身はNotionに全てを解決してもらえはしていないのだが、それはおそらく、デジタル手帳術・デジタルノート術・デジタルファイル術をそれぞれ別の場所かつ別の見た目で実践したいということが前提にあるからだと思う。Notionの場合は「処理がちょっと遅い」というストレスも感じてはいるが、仮に爆速処理になったとしても多分「Notionひとつで万事解決！」とはならない。LogseqでもObsidianでも同じである。
　このことは自分でツールを作る時にも非常に厄介である。自分で自由に作れるとなれば、ぼくのかんがえたさいきょうの情報ツールを作ってしまいたくなる。頑張って考えて頑張ってコードを書いて、すごいものが爆誕したような気持ちになる。しかし最強に思われたそのツールは、どうにも上手く働かない。プログラミングが下手だからか。欠けている要素が何かあるのか。いや、全てを兼ねようということ自体が自分に合っていないのだ。その「全て」とは具体的に何なのかと言えば、それがきっと手帳術とノート術とファイル術だったのだ。
　また、メタ認知によって生まれる自己についての情報の位置づけに混乱しがちなのだが、それも領域の越境に起因しているかもしれない。自分のことなのだからセルフマネジメントの領域として「手帳術」の範疇で扱いたくなるが、しかし自分を分析対象とした研究と思えばナレッジとして「ノート術」の範疇で扱った方が自然に思える。分析結果が自分の今日明日の行動に直結するのでいずれにせよ切り離して考えることは不可能だが、二種類の領域に跨っているものではないかと思っておくとやりようはまた違ってくる気がする。跨っているから併せてシームレスに扱った方がいいのか、跨っているから線を引いて二段階で扱った方がいいのか、正解は各々違っていると思う。

　これまで、「手帳とデジタルツール」「ノートとデジタルツール」「書棚とデジタルツール」といった対比は当たり前になされてきたと思う。しかし、それらを三本柱として総合的に考えることは意外にもなかったのかもしれない。汎用的なデジタルツールはいずれも広く兼ねてしまえるので、アプリケーションの名前を主語にして話をしてしまうと曖昧にならざるを得なかった感もある。
　この見方で「デジタルツールを使う」という行為を捉え直すことは、キーワードの普通っぽさとは裏腹に、とても面白い展開を導くのではないかと感じている。

　以前「生活の技術」というテーマ的なものが話題になっていたことをふと思い出したので、その肝になるのはなんなのかを自分なりに考えてみることにした。