nDiki : デイリーノート

ワーキングノートを部門の情報共有ツールに書いてみた

月曜日に部門の情報共有ツール (Qiita Team) にワーキングノートを新規作成し、その週はそのノートを更新するというのを今週やってみた。

目的に対して

• コミュニケーションの補完という目的をどれぐらい果たせているかはまだ不明(1人から公開初日に良い取り組みだというフィードバックはいただけた)。
• 1つのワーキングノートの公開だけだと「公開で作業する」感はちょっと低め。

運用について

• 毎日1回以上更新は継続できた。
• ローカルのデイリーノートと今回の共有用ワーキングノートの2本立てで書き分けるのに、フリクションが発生する。
• 共有期間を終えたあとのローカルでのアーカイブをどうするかまだ見えていない。

これから

共有するかどうかとは別に、そもそもデイリーノートとワーキングノートを分けない方がいいという気持ちになった。知的作業空間としてはデイリーノート一本化に戻す。作業中に共有・非共有の判断にエネルギーを割かないようにする。

コミュニケーションの補完という目的では、雑感記事をデイリーで情報共有ツールに書いていくのが良さそうだ。

結局行き着くところは社内 Web 日記 (社内 Blog)か。

[ 組織内公開ワーキングノート ] [ 公開で作業する ]

ワークスペースノートをやめる

Obsidian 上に Workspace というノートを作り Homepage プラグインで startup 時に表示していた。「ワーキングノート」「アクティブなノートへのハブノート」「繰り返し目に触れるようにしたいノートをトランスクルージョンして見るノート」などとしての雑多なノートだ。

今週ワーキングノートについて考えるなかで知的作業空間はデイリーノート一本化に戻すのが良いなとなったので、その Workspace ノートは解体することにした。

Obsidian の startup 時に表示するノートはデイリーノートに変更。

デイリーノートと Things to Keep in Mind (Web ブラウザスタートページに設定してある)に表示しておきたいノートは Sticky Note としてそれぞれにトランスクルージョンしておくようにした。

部内 Web 日記を書き始めて約1週間

ワーキングノートを部門の情報共有ツールに書いてみた結果、コミュニケーションの補完という目的で部内 Web 日記として雑感を書くのがいいかなと思ったので、先週の月曜日から Qiita Team に1日1投稿を続けてみている。

「(その日の)トピックス」「(その日に確認し考察した)メトリクス」「雑感」と「(アイデアなどを含むちょっとした)バックログ」が今のところのセクション(該当内容がないセクションはカット)。

情報の鮮度を考えて1週間後に Qiita Team からは削除。ローカルでは非公開のデイリーノートと合わせて Markdown ファイルとして残しつつ、ローカルの他のノートと同じく整理のタイミングでマージされたりしていく想定だ。

また Web 日記を増やしてしまった。まあ Web 日記ドリブンも悪くない。

[ 社内 Blog ] [ 組織内公開ワーキングノート ] [ 公開で作業する ]

部内 Web 日記を書く実験完了

11月29日から4週間ほど部内 Web 日記として毎日雑感などを Qiita Team に書いてみた(記事)。仕事納めの今日は個人的な仕事の整理が多くてプロダクトについて書くネタが思い浮かばなかったというのもあり、惰性で続けずいったん昨日までで終わりとした。

良かった点

読み手を意識して書くため、デイリーノート(非公開)にメモ書きするより思考の整理・明確化につながった。

メトリクスについての考察などの意見を書いておく場所として適していた。

良くなかった点

仕事終わりの時点で書きたい話題が無いと何かないかなと無理やり考えることになって、それはちょっと違うかなと。

読まれているのかどうかが分からないと虚しくなりやすいというのも再認識した(読んでますと1人からフィードバックを頂いたのが心の支えだった)。

今回はお試しなので書きます宣言 & 宣伝をしなかったし、1週間後に削除する旨を冒頭に書いていたことでフィードバックを誘わない記事であったのも拍車をかけていたとは思う。

誰が読んだかわかる既読表示のある DocBase の方が読まれている実感があり継続に繋がりやすいのではと思う。

今後

コミュニケーションの補完という目的で部内での情報発信はしていきたいなあというのは引き続きあるので、来年も何か実験してみたい。

[ 社内 Blog ]

年末年始休暇1日目は家でこまごまと【日記】

今日から年末年始休暇。初日の今日は外出せず家で。

昨日までの日記を書きデイリーノートを整理。今年お金を払ったサブスクリプションサービスを書き出してひえぇとなったり。

今日のさえずり: 14年ぶりに買い替えた目覚まし時計、当たりだった

• 18:02 今週平日分のデイリーノートと日記の整理・まとめ書き終わった。
• 19:40 その日にやったこと Tweet やっぱり 25:00 ファイナルに設定しておく。
• 20:30 お祝い #photography RICOH GR IIIx #GR #GRIIIx #GR3x https://t.co/fRFUWICeSI
• 21:39 14年ぶりに買い替えた目覚まし時計、当たりだった。 https://www.naney.org/...
• 21:42 14年使った目覚まし時計も結構気に入ってた。ボタンが壊れなければまだまだ使ってた。
• 24:52 劇場公開日ぶりにようやく『シン・エヴァンゲリオン劇場版𝄇』を観た。 満たされた。
• 25:00 2022年1月22日(土) やったこと - 食料買い出し - 日記まとめ書き - 劇場公開日ぶりの『シン・エヴァンゲリオン劇場版𝄇』

お祝い#photography
RICOH GR IIIx #GR #GRIIIx #GR3x pic.twitter.com/fRFUWICeSI

— Naney (@Naney) January 22, 2022

Logseq を使ってみる

以前から気になっていた Logseq を MacBook Pro にインストールして触ってみた。Logseq は WorkFlowy や Roam (Roam Research) などからインスパイアされて開発されているアウトライナーで、類似のインタフェースや機能を備えている。

• https://logseq.com/

ローカルの Markdown ファイルにデータが保存されるアウトライナー

ローカルの Markdown/Org ファイルにデータが保存されるので、他のアプリケーションと併用したり乗り換えたりするのが容易だ。ローカルで閉じて使えるのでネットサービス上に置きたくない情報を扱うのにも向いている。

ジャーナルとページをつないでいくモデル

Logseq の名前の由来が

What does "Logseq" mean? You can read it as "Log sequence" or "Logical sequence" (thank you Ed). — logseq.github.io

とあるように、ジャーナルに思い浮かんだことをキャプチャし書き出しながらナレッジやプロジェクトなどのためのページをつないでいくのが標準の構成となっている。このため Logseq グラフ(ページの集まりのことで、ファイルシステム上では指定したフォルダ以下に保存される)を新しく作成すると初期状態で Journals (journals フォルダ)が作られる。

自分は Obsidian でデイリーノート管理をしている。 Logseq を使うとジャーナル管理が2箇所になってしまうのがちょっと悩ましい。ジャーナル管理をオフにできるけれどそうすると Logseq らしさが無くなってしまいそうではある。

ファイル管理とファイル更新まわりが良くわからない

All pages に Contents・Favorites・card というページが表示されるのだがこれが何なのかまだ分かっていない。 refresh や re-index 操作があるのだけれどそれぞれいつ実行すべきかわからない。 どちらをやっても変更が反映されない場合があって、その時は All Graphs からグラフを開き直すときれいになったりする。

「Google ドライブ」フォルダ以下のグラフがおかしくなる

Google ドライブアプリで同期している「Google ドライブ」フォルダ以下にグラフを作ると、ファイル管理がおかしい。グラフフォルダの中にさらに Users/naney/Google ドライブ/... のようなフォルダ階層が作られてしまう。

いろいろ試したところグラフのフォルダまでのパスに濁点が含まれるフォルダ名があると駄目のようだ。Unicode 正規化まわりの問題に引っかかったようだ。

1日目終了

Google ドライブ同期フォルダ以下にある Obsidian vault フォルダ Logseq グラフとして開いてみる実験をしていて上記問題にぶつかり今日は終了。

アウトライナーは思考にするのにとても便利だが、作成したアウトラインは時間が経つと扱いづらくなる。自分としては Obsidian をメインに使う中で補助的に Logseq が使えればいいなと。明日もうちょっと触って構成を検討しよう。

Logseq のジャーナルページ機能が心地よい

Logseq + GitHub Pages で昨日作成した組織内公開ワーキングノートサイト向け Logseq graph で実際にいろいろ書き始めてみた。

ジャーナルページに思い浮かんだことをスレッド的にダンプする

ジャーナル機能を使うかどうか迷ったけど使ってみている。 inbox として取りあえずさっと書けるのに加えて、関連して思い浮かんだことを子リストとしてスレッド的に書き足していけるのが心地よい。inbox として理想的だ。Tweet せずにここにダンプしておけば十分ではと思えてきた。

MkDocs + GitHub Page のページを移す

Markdown ファイルを順次移しながらチェック。

logseq-mermaid-plugin を使えば Logseq でも mermaid の図を入れられるが mermaid.ink という外部サイトでレンダリングさせる方式なのでそのまま使えない。fenced code block ではなく独自記法で囲む必要があるのもマイナスポイント。

セル内改行している表が Logseq ではうまく表示されなかったのでこれも移すのをいったん保留した。

Obsidian vault の中に Logseq graph を置くのをやめる

Logseq のスタイルで頻繁に graph を更新していくには Obsidian vault の中に置いておかない方がやはり良いな。組織内公開ワーキングノートサイト向け graph は外に出した。

ただそうすると Logseq のジャーナルと Obsidian のデイリーノートで2重管理が発生する。Logseq の backlink を活用するためには Logseq に書いておきたいし、後で参照するためのアーカイブとして Obsidian にも書いておきたい。 Logseq から Obsidian に転記したら 📋 でマークしてみたけれど、うまくいかない気がする。

Logseq でエクスポートした静的サイトは Google 検索エンジンにほとんどインデックスされない

公開ノートサイトにも Logseq を使ってみるのどうかと思ったけれど、 index.html にページデータを書き出した SPA になるのでページ数が増えた時に読み込みが遅くならないかなど懸念を感じた。 https://logseq.github.io/ はトップページしか Google 検索でヒットしていなさそうだし SEO も不利そうだ。公開サイトで使うメリットは少ないな。

capture の書き込み先を Logseq ジャーナルに変更してみる

Obsidian QuickAdd プラグインや Alfred ワークフローからサクッと capture する時の書き込み先を Logseq ジャーナルに変更してみた。

capture した内容に付随することを後で書き足していくのはアウトライナーである Logseq が便利だなと。

翌日 Obsidian のデイリーノートに戻す

しかし翌日に Logseq を使うのをやめることしたので、 capture 先を Obsidian のデイリーノートに戻したのだった。

今日のさえずり: 頭に思い浮かんだのは第3新東京市

• 07:10 15年。2007年4月登録の生き残り組であります。 #MyTwitterAnniversary https://t.co/zrv0P5lkiO
• 12:14 頭に思い浮かんだのは第3新東京市。 #photography RICOH GR IIIx #GR #GRIIIx #GR3x https://t.co/ZoD7hfHBJf
• 17:26 Logseq に「ジャーナル以外のページを作らない」設定が欲しい。
• 25:01 2022年4月6日(水) したこと - 花粉症の薬を手配 - capture 先を Logseq のジャーナルファイルから Obsidian のデイリーノートに戻す

頭に思い浮かんだのは第3新東京市。#photography
RICOH GR IIIx #GR #GRIIIx #GR3x pic.twitter.com/ZoD7hfHBJf

— Naney (@Naney) April 6, 2022