情報の管理・整備のトレーニングとして自分自身の情報をどう処理してきたのかを一度整理して今後に活かすべく、今日まで利用してきたPKM(パーソナル・ナレッジ・マネジメント)ツールの変遷をまとめました。

2010年 - Evernote 時代

ちょうどこの頃はEvernoteが爆発的に普及していたと思います。Evernoteとモレスキンのコラボの方眼紙が新宿のデパートで売られていたことが強く印象に残っています。今は見る影もないですが、一時代を築いたのは間違いないです。

私のPKMもここから始まりました。GTDを知ってEvernote上でGTDサイクルを回すようにノートブックの運用ルールを決めたり、Web Clipperでいいと思ったものは何でもかんでもクリップしたり（これがのちのち問題となる）まさにAll-in-Oneでした。

スマホとデスクトップでシームレスに使えるというのも重要な要素でした。長らくEvernoteから離れられなかったのも、結局この要素が大きかったです。それくらい生活に根ざしたツールでした。

2017年 - Evernote + VSCode(git) 時代

Evernoteから技術系のスクラップを掘り出すのが面倒になってきたため、技術系のクリップはリポジトリを作ってそこにmarkdown形式で集約することにしました。

YYYY/MM.md 形式でファイル・フォルダを作っていき、以下のようなフォーマットで大まかなカテゴリごとにTipsや作業ログなどをまとめていきました。

メモの例；

Docker | Security | コンテナスキャン系ツールについてまとめ
-----------------------

* <urlなど>

メモを書いたり、marmaid/plantuml/asciiflowで図を描いたり。

{カテゴリ名}.md 形式でまとめてもよかったのですが時系列のほうが記憶から引っ張り出しやすいのと検索クエリとして {カテゴリ名} | で検索するといい感じにヒットするのと、静的ファイルなので当然全文検索も速いということでこの形式に落ち着きました。

Evernoteの検索がポンコツだったということが大きいのですが、gitというかテキストファイルのほうがcliで操作しやすく検索も速い、vimmerなのでターミナル上で扱えるほうがアプリケーションスイッチのコストも少ないという点も要因のひとつでした。

この頃からコンテキストに合わせた保存先・保存ルールというものを意識し始めます。

2019年 - Evernote + VSCode(git) + 方眼紙 時代

この時期あたりから日記をEvernoteではなく方眼紙に書きはじめました。

考え事をするときは特に紙とペンがよいということはずっと前から思っていたことで実際仕事でも常に手元に紙とペンはありましたが、日記についてはなんとなくEvernoteで続けていました。日記というよりはライフログ的な使い方に近く、チェックボックスを並べて習慣づけの確認をしたりテンプレのコピペをしたりがやりやすかったのが要因でした。が、なんとなくサボって書かないことがあったりして少し課題感を感じていました。

この少し前に職場で同僚だった方からバレットジャーナルフォーマットを教えていただいたことを思い出し、ペンやノートの紙質に少しこだわったりして、なんとなくバレットジャーナルを始めたことが方眼紙を取り入れはじめたきっかけでした。バレットジャーナルは発達障害の方が編み出した技術で、やってみると日々の細々したことでも意識できるようになったり書き留めたことを忘れにくくなったりして、ライフログのサボりも無くなりました。フォーマットは自分流にすぐに改変してしまいましたが。

ライフログを振り返って読むことは殆ど無いものの、朝と夜に書く時間を持つように習慣化できたのもよかったです。

2020年 - Evernote + Notion + VSCode(git) 時代

Notionが無料でも使いやすくなった頃からライフログをNotionに移行しました。

Notionのライフログは1ヶ月1ページとして全体管理しつつ、週間テンプレートを吐き出す template button を埋め込んでおき、週が変わったらページ内でそれを叩く、次月になったらまたページを作る、という形に落ち着きました。入力時は週単位で物事を考え、見返すときはカレンダーをめくる感覚で一ヶ月を俯瞰したかったためです。

Evernote時代は1週間を1ページ、方眼紙時代も1週間を見開き1ページとしていて週単位でのログ管理が長らく習慣化していたのですが、そのへんの要求に全力で応えてくれるNotionのレイアウト自由度の高さには感銘を受けました。 たまった方眼ノートのライフログには個人情報は特に入っていなかった（健康情報くらい）ので、すべて写真に撮ってNotionに突っ込みました。この、画像ファイルの添付のしやすさもNotionの気に入っているところのひとつです。

また、この頃から同時に非技術系のストック情報もEvernoteからNotionに移行し始めました。（ライフハック、家事系など）

これはEvernoteの継続利用に懸念を抱き始めたのがきっかけでした。会社として大丈夫なのかという心配よりもスマホアプリが重すぎて使い物にならないという切実な問題がありました。デスクトップアプリもリニューアルのたびに使い勝手はむしろ悪くなっていく一方で本当に困り果てていました。従業員によるプライバシー侵害のニュースも一抹の不安を覚えた記憶があります。今は利用面では Evernote Legacy が提供されており、運営面では会社が買収されたようで、まぁ当面使うぶんには困らないかもしれませんが、Notionの利用体験が非常に良かったこと・カスタマーサポートが手厚く会社としても問題なさそうに思えたことで、移行を決めました。

問題は、積み上がりまくったEvernote上の情報をどうするかでした。８割がたは古い情報だったので捨てましたが、その分類や選別、Notionへのimportにはかなり手を焼きました。そもそもEvernoteのノート数があまりに多く、またweb clipperで保存したノートやテーブル表記を駆使したノートをNotionのimport機能にかけると高確率でフォーマットエラーにぶつかりimportが中断してしまうトラブルが多発していました。いらないものは捨てつつ色々試行錯誤して、import手順は最終的に以下に落ち着きました。

1. Evernoteのデスクトップアプリを使ってノートブックごとに.enex形式でDL
2. Joplinで.enexを読み込んで、すぐにmarkdownとしてexport
3. exportしたmarkdownを md2notion.py でNotionへimport
4. Notion上で再分類

「いらない情報は捨てる」というアンラーニングの概念と必要性をこの作業で身を持って学びました。

2022年 - Notion + VSCode(git) + Joplin 時代

Evernoteのものを全部Notionには移さず、一部毛色の異なるデータが有ったのでそこはそのままEvernoteに残していました。Notionを信頼していないというわけではないのですが連絡先などの個人情報に近いものはE2EE的に管理したいがどうやるべきか悩んでいたのが理由でした。

これについてはひとつ前のフェーズでJoplinを使っており、これがE2EEを備えているということを知って、.enexの変換作業後そのままJoplinで管理することにしました。そうしてついに、Evernoteは完全にお役御免となりました。

joplinが出始めたのは2016-2017年頃で当初から気になっていて触っていたのですが、当時はまだスマホアプリがEvernoteに比べ満足して使えるレベルに達していなかったので離れていました。現在は使い勝手も悪くなく必要な機能も揃っているので便利です。ただNotionの表現力の高さには到底かなわないので、やはり出番は少なめになります。

パスワードをKeepassXCで管理していたのでE2EEとしてそれを使ってもよかったのかもしれないですが、パスワードと個人情報がセットで漏洩するとかなり面倒なことになりそうなのでそれはやめました。

2023年 - Notion + Obsidian(git) + Joplin 時代

そして今年からVSCodeでのリポジトリ管理をやめてObsidianでの管理をはじめました。開発はVimなので、VSCodeはあくまでmarkdownエディタとして使っている状況でした。VSCodeは使い勝手が良く大きな不満はなかったのですが、できればDropbox paperのようにライブプレビューされるmarkdownエディタだと視認性や閲覧性がよくなってよりよいのだけどなぁ、という小さな悩みがありました。そういった機能を満たすmarkdownエディタがないものか随分探しました。

mark-text, zettlr, typora, そのほかwebブラウザ系のhackmdなどなど試せるものはほぼ試したもののどれもイマイチで消去法でtyporaかというところでしたがアウトラインとファイルツリーを同時に出せない・レイアウトの自由度がないなどが気になってしまいいまいち移行に踏み出せず、いつもVSCodeに舞い戻っていました。

非技術系はNotionにストックする方向で進めていたのですが、Notionは検索がイマイチというか全文検索としてはほとんど機能しておらず、特に巨大なページを含めた全文検索は無理に等しいという問題が出てきました。長文を書いたり非技術系でも長めの文章をストックしたり、ツイートログを保全することがたびたびあるので、これを何とかする必要が出てきました。

2022年はObsidianが日本語圏でもだいぶ流行り始めていたと思いますが、私も触ってはいたものの使うことはありませんでした。タグやエイリアス、バックリンク、相関図といった機能は執筆業をされる方にはよさそうですが自分はそういう京大ノート式な管理はデジタルでは合わなそうだとEvernote時代から思っていたためです。

ですが長文の扱いには当然gitで静的ファイルとして管理するのが最適だということと、レイアウトの自由度が非常に高くプラグインでさらに拡張可能なこと、エディタのライブプレビューの機能も優秀でタグやバックリンクを使いこなさなくても単純にmarkdownエディタとして使いやすいということに気づき、Obsidianを使い始めました。コミュニティプラグインはまだ使っていませんが、慣れてきたら導入していくかもしれません。ちなみにこの記事もObsidianで書いています。

正月の時間で少しずつnotionから長文系・ログ系のmarkdownをexportしてリポジトリに移植しはじめており、これもまた時間がかかりそうです。.enexからの変換・移植時に気づいていればこんな苦労はなかったのですが仕方ありません。

学んだこと

コンテキストに合わせたツール選定を意識する

利用コンテキストを考え、シーンに合わせたツールを選ぶとストレスが少ないです。 管理するものが増えることよりも体験がいいことに集中したほうが総合的な満足度は高いです。 管理はいずれ慣れるというか技術の進歩に伴い最適化されていくという側面もあります。

情報の性質に合わせた格納方法をとる

どこまで安全性を求めるのか、漏洩して許されるレベルはどこまでかを意識したツール選定をすべきです。 また、利用時のパフォーマンスや入力インターフェイス（スマホかキーボードか等）にも適不適があるのでその観点も重要です。

移植性の高さ・依存性の低さにはそれだけで一定の価値がある

結局情報をうまく管理していけるのもexportや変換がちゃんとできたことが大きく、そういった機能に劣るツールを避けてきたことの有り難みを感じつつ、移植特有の辛さも同時に体験することになりました。

アンラーニングを意識する

将来捨てることを前提として不要な情報だけを安全に捨てられるような配慮が必要だと痛感しました。 そのためにもツールの特性や仕組み上の限界を認識しておき、通常利用に耐えられるレベルのファイルサイズ・文字数の限度を意識して情報を配置していくこと、移植や破棄がバルクでできない場合はリスクと捉え選定時はよく考えるべきだと感じました。

Notionは非常に優れたユーザーインターフェースでここまで軽快に動くJavaScriptを管理している開発チームには本当に脱帽ですが、それでも1ページあたりのブロック数がある一定以上を超えると極端に画面のFPSが下がる（スクロールや移動でもたつく）ことがわかっています。synced blockを使ったりすれば回避できるものもありますが、適材適所の重要性を感じます。

まとめ

柔軟なレイアウト操作などの表現力や閲覧性の高さ スマホアプリの使い勝手の良さ	Notion
巨大なテキストファイルの扱いやすさ 技術系メモとターミナル操作との親和性の高さ markdownエディタとしての完成度の高さ	Obsidian(git)
E2EEが必要な情報	Joplin (パスワードはKeepassXC)

2023年はこの布陣でPKMを整備していくことになりそうです。

SaaSへの依存は事実上Notionのみとなりましたが、DecentralizedなNotion風インターフェイスが出てきたらこれもまた変わるのかもしれません。

Obsidianの書き心地が思いのほか良く、とりあえずInboxフォルダをリポジトリ内に新たに作って思いつくことを適当に何でも書いています。ライフログは今もNotionで継続できていますが、これからはライフログだけでなくブログ記事もいろいろ書いていけるといいなと思っています。