Noratetsu Lab

動じないために。

タグの定義・詳細

Capacities

情報を「オブジェクト」として扱うモダンなノートテイキングアプリケーション。
https://capacities.io/
UIはNotion風で、ページ間リンクやそのグラフはObsidianと似ている。
Logseqのようにデイリーページを重視したつくりになっている。

注意点

  • [日本語・中国語・韓国語等は全文検索に対応していない(タイトル検索は可)]
    • 2025/01/22時点で解決した模様
  • フォントの問題で括弧類が謎の挙動をする時がある(CSS上書きで解決可)
  • Androidアプリでは入力の決定時にブロックの内容を上書きしてしまう(加筆ができない)致命的なバグあり
    • iOS版は試していないので不明

Backlinks

他の「Application」カテゴリの語句

「Capacities」タグの記事一覧

2025/05/19

【Capacities】「今日以降やること」の扱いに用途を絞って使ってみる

2025/05/17

Capacitiesのマイオブジェクト定点観測(2025/05) 今日以降のやることに関わるものに限る

 Capacitiesに自分で定義しているオブジェクトタイプの話。今回は3月Capacitiesのマイオブジェクト定点観測(2025/03) 生活に関わるもの以外のオブジェクトの除去までの定義から変更した点について書きます。

2025/04/21

【Capacities】Daily Noteのテンプレートに「今ホットなものまとめ」を組み込む

2025/03/25

Capacitiesのマイオブジェクト⑦ Container

 ナンバリングの数字が巻き戻っていますが、過去記事のタイトルを一部変更したことによるものです。
 さて、今回は前の記事Capacitiesのマイオブジェクト定点観測(2025/03) 生活に関わるもの以外のオブジェクトの除去で触れたContainerオブジェクトについてです。


 情報の扱いを考える上では、情報を置く場所、あるいは容れ物について考えることが不可避でしょう。仮に全ての情報をひとつのツールで扱ったとしても、そのツールの中にフォルダ的なものや内容ごとのトップページにあたるようなものがおそらくあり、それぞれが容れ物の役目を果たしていると思います。
 この情報はあれに入れようと考える時、その容れ物に名前がついていると考えやすいです。意識しなくとも大抵識別のために何らかの名前はつけるものと思います。
 そういった容れ物は、新たに作ったり解体したり統合したり意味合いを変えたり、様々な操作をして在り方がしばしば変化していきます。こうしようと思いつくとすぐ着手して変更を加えがちですが、その場その場でやっていると後から変遷を追えなくなります。そうすると前にやった失敗を数年後に繰り返すようなことも起こり得ます。
 なので、容れ物自体の検討や記録をする場所があると便利です。少し前からContainerオブジェクトとしてCapacitiesに用意することにしました。現在作っているコレクションは以下の通りです。

画像

 ちなみにアイコンは弁当箱です。このうちCapacitiesオブジェクトのコレクションはこうなっています。
画像

 頭に「❌️」がついているのは既に削除したオブジェクトです。他のアプリケーションについても、活用をやめたり解体したりした領域は❌️をつけています。今あるものだけ表示したい場合はFilterで「タイトルに❌️を含まないもの」を抽出します。
 中身のページの記述量は様々です。どのように運用するか、今感じている問題点は何かなどを細かく書いていることもあれば、ページを作っただけで中にはほとんど書いていないものもあります。
 このオブジェクトの存在意義はページを用意してそこに書き込むことだけではなく、Daily Noteなどからリンクを貼れることにもあります。例えばタスク欄に「Mapオブジェクトの○○をTime(Dynalist)に移動」と書いて「Mapオブジェクト」と「Time(Dynalist)」というページにリンクしておけば、それぞれのバックリンクに履歴が並びます。いつどういう意図で何をしたかが蓄積されていくわけです。情報がどの容れ物からどの容れ物に渡っていったかも追跡することができます。

 結局今どこにどんな場所を作っているのかというのがこのオブジェクトの一覧を見れば一目瞭然です。色々なところに情報が分散していたとしても、リストによって把握できるならばそれほど混乱しません。Containerオブジェクトを見ればいいわけなので、情報の所在を思い出すために認知資源を消費するということがなくなります。
 また、「こうした方がいいんじゃないか」と思った時に、本当にそれが妥当かを検討することが簡単になります。検討の場がページとして用意されていること、今運用している全ての場を把握できること、リンクによって過去の記述の参照が可能になること、これらによって検討をスムーズに進められます。
 このようにContainerオブジェクトを用意したことで、情報の整理方法を考えるのが随分楽になりました。

2025/03/23

Capacitiesのマイオブジェクト定点観測(2025/03) 生活に関わるもの以外のオブジェクトの除去

 Capacitiesに自分で定義しているオブジェクトタイプの話。今回は去年12月Capacitiesのマイオブジェクト定点観測(2024/12)までの定義から変更した点について書きます。

2025/01/23

Capacitiesで日本語での全文検索が機能するようになりました(多分)

 直近のCapacitiesのアップデートで全文検索機能の改良が行われ、おそらくですが日本語での全文検索の問題が解消しました。なお私の環境ではアップデートの案内が昨日アプリ上に表示されました。


 Capacities公式サイトのWhat's new?ページには今月のリリースの記事が公開されています。

 この中で、「Better full-text search experience」という見出しで以下のように書かれています。

We transitioned the search engine used for the command palette, extended search, and search queries to a more powerful one. This should improve matching and ranking of your search results.
 技術的なことは詳しくないのでわかりませんが、おそらくこの変更により結果として日本語の検索も有効になったということではないかと思われます。積極的に日本語その他(logographic languages)に対応しようとしたものではないような気がしますが、何にせよ思いのほか早く解決されたのはありがたいことです。

 検索結果が本当に完全に反映されているかというのは確かめるのが難しいので、絶対漏れがないと断言はできません。
 しかしながら、私はアップデートの度に特定のワードで検索を試みて「拾えてなさ」を確認しており、それが今回明確に改善したので、多分直ったのではないかと思っています。
 ただ、検索してみると「本当にヒットしているのか?」と思われるかもしれません。というのは、全文検索の結果がそもそも20件しか表示されないからです。検索ワードを含むページが20件以上あれば何らかの基準でそのうちの20件が表示され、20件に満たない場合は検索ワードの一部を含んだページが追加で表示されるようです。それ以上の件数を表示する方法があるのかどうか、パッと見たところではわかりませんでした。
 検索の際はいくつかのフィルターの手段があります。多くのページで使用しているワードで検索する場合には、それらの仕組みを駆使するなどして絞り込むことが必要になるでしょう。

 検索のシステム自体にはまだ改良の余地がありそうです。しかし、日本語であるという理由でのハンデは解決したように思うので、日本人には勧めにくいという状況からはおそらく脱することができました。
 残る問題はAndroidアプリで日本語での編集が実質的に不可能である点です。こちらの方は欧米目線の改良で副次的に直る見込みは薄く、そう簡単には解決しないような気がしています。スマートフォンでも使いたいという人にはまだCapacitiesを勧められない状態が続きますが、しかし全文検索の改良を機に日本人ユーザーが明確に増えれば、もしかしたら状況は変わるかもしれません(全然わかりません)

2025/01/12

DoMA式とCapacities

 以前、倉下忠憲さんがDoMA式というWorkflowy運用術を提案なさっていた。

 DoMAとは「Depend On My Attention.」の略であり、使う人の注意の構造に合わせて情報を扱うことがこのメソッドの核になっている。


 DoMA式は以下の三つのポイントによって成り立っている。

  • ワンデイリスト
  • 注意オブジェクトモデル
  • フラットスタイル(ヒエラルキーレス)

 私はDoMA式についての一連の記事を拝読した時にリアルタイムでいたく感銘を受けたのだが、今Capacitiesを使いながらこのことを思い返した時、まさにDoMA的に運用しているのだということに気がついた。

 Capacitiesはデイリーノート機能を提供しており、毎日そのデイリーの欄を拠点としている。つまりワンデイリストである。
 私は「やること」についてはProjectオブジェクトとしてページを作っている。Capacitiesでのプロジェクトの扱いを考えるで詳しく書いたけれども、これは所謂「プロジェクト」とはちょっと違った粒度だと思う。私が一塊として扱いたいと思ったそのまとまりであって、自分のイメージする「あれ」の感覚である。それは倉下さんが書かれているのと同様に、基本的に階層を作らない[1]
 「注意オブジェクトモデル」は「プロジェクト」や「やること」より広い概念を指していると思う。他のあらゆる「自分が注意を向けているもの」が含まれるが、そういうものを扱うのがCapacitiesなので、Projectオブジェクト以外にも色々なものがある。ただし「もやもや考えていること」はオブジェクトとしては扱いにくいので、Workflowyのノードほどの柔軟性はないかもしれない。一応「~について考える」とすればProjectオブジェクトとして違和感はなくなる。
 Capacitiesは階層管理にはなっていないので、必然的にフラットスタイルになる。オブジェクトタイプとそのコレクションは階層構造のような見た目をしてはいるが、それは単にフィルターで絞り込んでいるだけであって、オブジェクト自体は階層を持たずに存在している。
 よって、今注意を向けているオブジェクトのページをピン留めしたりどこかのページにリンクを並べたりすれば、それはフラットスタイルの注意オブジェクトモデルということになる。また、ページにリンクを並べる形式を取るならば、Capacitiesのページの粒度とは合わないような注意対象もそこに一緒に書き込むことで扱うことができる。

 倉下さんのDoMA式はWorkflowyを使う上での具体的な手法なので、そもそも形の違っているCapacitiesとイコールで結ばれるわけではないけれども、DoMA式の肝になっている部分はCapacitiesと相性が良いということは言えると思う。DoMA式とCapacitiesのリンクというのは昨日得た閃きだが、今思うに私がCapacitiesを使い始めた時に得た感動はDoMA式を見た時の感動と同じ種類のものという感じがする。
 プロセス型アウトライナーでは自分の中で「オブジェクト感」が足りずにDoMA式を十分に実践できなかった。Capacitiesと出合って、ようやく「あの感じを自分もちゃんとやれるようになった」という思いでいる。


  1. 倉下式WorkFlowy運用術 その2:注意オブジェクトモデル | R-style ↩︎

2025/01/07

忘却に伴う恐怖/私が欲しい第二の脳

 「記憶は薄れてしまう」ということを私はかなり恐ろしく思っている。


 それは「全てのものを全て覚えておきたい」ということとはちょっと違っている。自分が例えば砂粒の集合のようにできていたとして、自分でも気づかぬ間にさらさらと砂粒が流れ出し、いつの間にか自分の一部が欠けている――そういうことに恐怖を感じているのだ。

 その感覚には少なくとも二つのことが関係している。
 まず「忘却への備えが下手」ということがある。恐れている割に、この半生のかなりの部分でうまく記録をつけられなかった。若い頃はそもそも記録をつけていなかったし、大人になってからは飽きとか際限のない「よりよい形式探し」によって記録が分散して、結局振り返りができないということになっていた。
 今起きたこと、今感じたことを、今大切にする。その習慣がなかなか身につかなかった。見たり聞いたり、そしてそれに何かを感じたりしただけで恒久的に自分の一部になった気がして、それをちょっと立ち止まって愛でるということをしないで次に行ってしまうから、気づいた時にはせっかく自分の一部になったものが失われているということになる。
 あるいは、記録をつけ始めても、将来振り返りやすい形式みたいなことを小賢しく考えてしまって、結局今今それを大切にするための記録にはなっていないということが続いていた。だから平気で形式を二転三転させ、「より劣った形式」でつけた記録は蔑ろにしてしまう。
 そうなると、記録をつけてはいても結局自分の頭頼みになり、忘却が恐ろしいという状態を全然解決できない。

 忘却への備えの問題の他にもうひとつ、「何かを感じたということが自分にとってものすごく重要である」ということがある。
 何かを感じて、それによって自分が出来ていると思っているから、後から忘却に気づいた時に巨大な喪失感に襲われることになる。「感じ直す」ことはもうできないわけだから、二度と取り戻せないのは確実であり、その取り返しのつかなさに絶望的な気分になるのである。
 で、その「感じた」というのは言葉にするのが難しい。記録の時点で正確に書き表すことは到底できないことが明らかだ。あまりにも大変な感じがしてしまうので記録を諦めてしまうということが子どもの頃に起きていたのだが、そうして何も残さないと綺麗さっぱり丸ごとなくなってしまうおそれがある。100%再現できる記録はできなくとも、1%でも書いておけばそこまでの喪失にはならなかったはずだが、そういうことは若い頃にはわからなかった。
 なにしろ、「何かを感じる」ということはひっきりなしに起こるのだ。ひとつひとつはそこまで特別なものには感じない。立ち止まって格闘している暇があったら次の「感じる」に移った方がいい。そもそも上述したように「感じたものはちゃんと自分に刻まれる」と思い込んでいた。そうやってパックマンのごとく動き回って「感じる」を続け、そうしてそれらがさらさらと呆気なく零れ落ちていることに後から気づいて困ったことになっているのである。

 もちろん、忘却によって失われたものがあるとしても、過去に発生した「感じる」は確実に今に繋がっている。具体的に何を感じたのかは忘れても、何かを感じるということを重要なものに位置づけ続けてきたということは確かに自分を形作っていて、だから今こうして「自分が感じたこと」を仔細に書き表すことで文章をつくることができている。
 とはいえ、やはり忘れるに任せていては不安だし、自分の一部が失われていくのはあまりにももったいない。
 今世の中には忘却に備えるためのツールやメソッドというのがたくさんある。「第二の脳」というフレーズもしばしば聞く。その場合の「脳」にどういう「脳らしさ」を期待するかというのは自明ではないと思うけれども、今私が欲しているのは「忘却によって自分が欠けていくことを防ぐもの」なので、忘却する自分の脳をサポートして一緒に記憶してくれるものとしての「第二の脳」を考えたいと思う。
 情報を無限に入れられて、そしてそれが勝手に消えないというツールはたくさん生まれている。紙のノートも、捨てたり焼失したりしない限りはずっと残しておけるものだし、日記をつけるのがうまい人はもうそれで私が抱えているような問題はほとんど解決していると思う。
 昨今は言うまでもなくデジタルノートツールの隆盛が目立つ。紙のノートは「記録」に特化しているが、デジタルツールだと「ある括りによってまとめて取り出す」というようなことが可能になる。より「脳」的であると言える。何かを思い出す時、脳は関連したものを一緒にイメージすることができるわけで、それとある程度似たことを再現してくれることになる。もちろんキーワードによって捜索するということ自体、紙のノートにはない「脳」っぽさがある。

 一口にデジタルノートツールと言っても、情報をどう保管しそれぞれにどういうフックを付けるかというのはそれぞれ異なっている。どれかの場所に必ず属すフォルダ(あるいはツリー)形式、キーワードを好きなだけくっつけて串刺し検索を可能にするタグ形式、情報と情報をリンクで繋ぐネットワーク形式、平面上の位置に意味を持たせる付箋・マインドマップ・カンバン系の形式。他にもあるかもしれないし、ひとつのツールがそれらの形式を複数カバーしていることも多い。
 これらの形式というのは、後から情報にアクセスする時の辿りやすさを左右する。
 種別が明らかで混在の可能性がないものならば、フォルダ形式が直感的かつ「必ず辿り着ける」ものだろう。どこかには属しているわけだから、フォルダを開けていけばどこかでは見つかるはずである。一発で見つけられないとしても入っている候補のフォルダというのはある程度絞られるのだし、フォルダの粒度が大きすぎない限りは力技でどうにかできるという利点がある。この形式は「脳」らしくはない。いや、脳内でも情報をカテゴライズして認識している部分はあるので全く違うわけではないが、少なくとも脳内では「必ずここらへんに入っているから、探せば出てくる」ということにはならない。
 何かに属しているとは限らない形、つまりネットワーク型ツールの多くは、情報の在り方がより実際の脳に近いように思える。キーワードが含まれさえすれば絶対取り出せるという意味では脳より強力だが、情報が大量になってくるとキーワードがわからなくなった時に取り出せる可能性がかなり薄くなる。タグ機能があるとしても、タグ付けが必須でない場合には自分の几帳面さにかかっていて、「ここさえ探せばいい」という安心感はやや得にくい。探すとなればフォルダ形式と違って捜索範囲が全体になってしまい、虱潰しに探すことは現実的でなくなる。脳のようにすっかり失われるということはないが、実質的に辿り着きにくくなるので忘却と似たことが起こる。実際の脳と似たライフサイクルになるわけで、それはとても自然な感じがすると同時に、脳と同じ欠点を一部引き継いでしまうということでもある。
 こう書くとフォルダ形式の方が良いと言いたいのか、と思われそうだが、もしそうなら今ネットワーク形式がこんなに流行ってはいない。今話しているのはあくまで「忘却によって自分が欠けていく」という事態を防げるかどうかの観点で、日々の情報の取り扱いでのフォルダ形式の欠点とネットワーク形式の利点はよく指摘されている通りである。

 さて抽象的に「情報」と言っているけれども、そもそもどんな情報を忘れたくないという話だったか。それは「何かを感じたということ」だ。それは自分の記憶が薄れて失われたらもう二度と取り戻せず、そして私にとってはそれが失われることが自分自身の一部を失うことと同じように思われるので、なんとか失わないようにしたいのだという話を前半でした。
 そういう情報は、「まあなくなったらなくなったでいいや」式の管理とは相性が悪いであろうということがわかった。ガラクタ箱のように、何が入っているか忘れてしまっても箱を開けて漁れば「こんなのあったなあ」と言って全てを確認できる、そういう保管方法が良い。しかしモノではなく情報を扱い始めると、ガラクタ箱に溜めていたのとは比べ物にならない規模の内容量になってしまって、情報同士が埋もれさせあって振り返りが難しいということになりかねない。大きい箱ひとつではなく、何かしらの基準で分別した箱をいくつも用意した方がいい。そのような用途なら、フォルダ形式またはツリー形式のイメージの方がネットワーク形式より合っている。
 自分以外のことはわからないので想像だが、多分「何かを感じたということ」を普通そんなには重要視しないのだと思う。今日明日の仕事には全然関係しないのだから当たり前のことだろう。「情報管理」の四文字で思い描く対象にそういうものは普通含まれない気がする。日記の話ではよく出てくる話であっても、それについて「情報」という言い方はしない。
 しかしながら、私はそういったものを「自分の人生上に生じたもの」としてある種「モノ」的に扱いたいという思いがあり、そうなると情報管理の手法を使って記録・保管したい。そういう発想で情報管理を考えると、それはタスク管理とも個人情報管理とも知識管理ともアイデア管理とも違った領域の話になるような気がする。
 ここ数ヶ月ずっとCapacitiesの話をしているが、私の中にある「オブジェクト感」というのは、こういった前提があってのものだ(ということにここまで書いてきて気がついた)。この感覚にぴたりと填まるツールがそれ以前になかった。Capacitiesと出合ったことで、Capacitiesになぜ納得できるのか、他のツールのどこが引っ掛かっていたのかを考えられるようになった。
 自分の脳だけでは情報を扱いきれないというのは現代人共通の悩みで、それに対処するために「第二の脳」となってくれるツールを皆欲している。しかしその理想の形というのは各々でおそらく驚くほどバラバラなのだと思う。TPO次第でその時必要な形が違ってくるということもあるだろう。私自身Capacitiesで全てをカバーしているわけではない。
 だから、「第二の脳」として相応しいツールは何か、というより、「私が欲しい第二の脳」とはどういう形をしているのか、ということを真剣に考えることが情報管理に於いては重要だろうと思う。

2025/01/05

Capacitiesでのプロジェクトの扱いを考える

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


 この中で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で日本語での全文検索が機能するようになりました(多分) ↩︎

2024/12/27

『ライフハックの道具箱2024』にてCapacities紹介記事を書きました

 毎年の年末に倉下忠憲さんが発行なさっている『ライフハックの道具箱』の2024年版が発売されました。

 私も参加しております。「ネットワークファーミングツール」セクションのCapacitiesの項です。コンパクトにまとめるのに骨が折れましたが、気合を入れて書いたのでCapacitiesのことが気になっている方はお読みいただけたら嬉しいです。Kindle Unlimitedで読めます。
 私も他の方の記事はこれから読むところなので楽しみです。

 さて、告知だけというのも当サイトの記事としては寂しいかなと思ったので、Capacitiesの使用風景の紹介を兼ねてこの原稿を書く際に使ったツールの話でも書いておこうかと思います。
 原稿を書くとなってまず最初にしたことは、CapacitiesでProjectオブジェクトを用意することです。タイトルは「ライフハックの道具箱2024にCapacitiesの記事を寄稿する」でした。そのままですね。(厳密には「寄稿」ではないのですがそれはさておき。)

画像

 やるぞ~という気持ちを表すものとしてアイコンに炎を設定しました。そしてこのページをピン留めしておきます。
 このページには、締切等の決まり事や字数の目安などのメモ、どういう工程で何をするかの検討、やり取りのログといったことを書き込んでいきました。内容そのもの以外の情報を全部ここで扱うという形です。
 作業を進める時はデイリーノートにトグル項目としてこのページへのリンクを貼り、下位項目に個別のToDoやログを記述します。するとこのページのバックリンク欄に作業ログが並びます。
画像

 次に、Dynalistに専用のファイルを作りました。ファイル名は「ライフハックの道具箱2024」です。ここでは内容に関わることを扱います。

画像

 公式の情報、他の方が書かれた記事のリンク、自分が思うツールの特徴、文章の構成などを全部ここに集約しました。本文もここで書きます。
 自作のChrome拡張機能によってDynalistで文字数カウントできるようにしてあり、普段からごく普通のテキストエディタのようにしてDynalistを使っています。あちこちに情報を分散させずに済むので取り扱いが楽です。Chrome拡張機能を自分で作って活用する(Dynalist)
 また、今回書くにあたって公式ドキュメントとブログはほぼ全部に目を通しました。といっても私は英語をすらすらとは読めないので、ChatGPTの力を借りました。元の英文を全部Dynalist内にコピーし、ChatGPTによる訳をノート欄にペーストし、英文と和訳を照らして誤訳や省略などがないか気をつけながら読んでいきます。ChatGPTのおかげでドキュメントを読むだけなら英語が不自由でもほとんど困らなくなりました。ありがたいことです。
 本文はMarkdown書式で書いていて、書いたものはGitHub Gistで確認しました(もちろんSecret設定です)。バージョン管理ができること、コメントをつけられることから、原稿を扱う形式として便利だと思ったからです。

 原稿提出後はその後のやり取りのログをCapacitiesに記録し、全部終わってからCapacitiesとDynalistの内容を整理して、後で見て一目瞭然な形に整えてこの件については完了ということになりました。
 書くにあたっていつもの数倍神経を使いはしましたが、短い記事を一本提出するだけなので、そんなにきっちりしなくてもできたことではあります。しかし敢えて雑にやる意味もないので、意識的に情報をきちんと整理しながらやりました。元々几帳面な質ではなく油断するとすぐ雑然とするので「どうせなら綺麗にやっていこう」と意識しています。
 Capacitiesはその「どうせなら綺麗に」という気持ちを惹起してくれるので、ズボラ人間でも恰も几帳面な人かのように情報を整えられます(個人の感想かつ当社比の話です)

管理人

アイコン画像

のらてつ Noratetsu

キーワード

このブログを検索

検索

ブログ アーカイブ

2025
2024
2023
2022
2021