作業ログで集中力をより早く取り戻し、思考を明確にする
(fev.al)- デプロイパイプラインの権限問題のように数日にわたって続く作業では、メッセージ・会議・電話が一度入るだけでも作業コンテキストを失いやすい
- 作業ログは、実行したコマンド、結果、思考の流れ、次の行動を書き留める習慣であり、再開時の集中力の回復を素早く助けてくれる
- ドキュメントが不足し、担当者ともつながりにくい作業で、Obsidian のデイリーノートに状況を書き始めたところ、複数の作業を行き来する際のコンテキスト復元が容易になった
- 重要なのは、記録を後ですべて読み返すことではなく、思考を整理する構造と最後の状態を保存するキャッシュを作ることにある
- 集中が頻繁に途切れる人は、今やっていることと次の行動を短く残し、戻ってきたときに最後の数文から読み始めることで、コンテキスト切り替えのコストを減らせる
作業コンテキストが途切れる瞬間
- 複雑な作業に数日間取り組んでいると、複数のドキュメントタブやコマンド実行結果を行き来しながら、問題解決の流れを頭の中に保ち続ける必要がある
- IM 通知、PM からのドキュメント依頼、マネージャーからの電話のような短い割り込みだけでも、現在位置を見失いやすい
- 管理者として一日中コンテキストを切り替えたり、開発者として互いに衝突する複数のプロジェクトを同時に扱ったりするとき、集中を維持するのは特に難しかった
- よくあるパターンは、ある作業を始めた後に別の作業へ切り替え、会議に入り、元の作業の本質を忘れたままメールや IM を読んでいるうちに一日が終わる、という流れである
作業ログのやり方と効果
- ドキュメントがなく、既存の担当者ともつながりにくい作業をしている中で、フラストレーションを Obsidian のデイリーノートに書き始めた
- その後、実行したコマンドと結果、思考の流れ、今やっていること、次にやろうとしていることをあわせて記録するようになった
- 例として、
--yo-compress-shit really-well-like-5000-or-somethingのようなコマンドと失敗エラーを書き留める - 割り込みの後は記録を読み返し、すばやく元の作業に戻る
- 例として、
- この3〜4か月間この方法を続ける中で、複数の作業を切り替える際のコンテキスト復元がはるかに速くなったと感じている
- 作業ログは、長い文章を後ですべて読み返すためのドキュメントではない
- 記録する過程そのものが、思考を整理する構造を作る
- 最後の数文は、再開時に必要な状態を保存するキャッシュとして機能する
- 集中が頻繁に途切れたり、複数の作業を行き来する必要があったりするなら、今やっていることと思考を書き留め、再開時に最後の数文から読むというシンプルな方法から始められる
1件のコメント
Hacker News のコメント
ジャーナリングの利点は、単に作業へ戻りやすくなることだけではなく、頭の中のモデルを、特定の問題に密接に結びついた具体的な可能性の分岐構造として固めていける点にある。
作業はこのツリーを探索して変更することになり、抜けている枝を見つけて埋めたり、同じ箇所をランダムに何度も見直したりする時間を減らせる。
特に分散システムでは、作業が細かく手作業で、ミスが起きやすく、遅延も大きいが、しっかりしたモデルがあればチェックリストをずっと確信を持って処理できる。
複雑な問題をその場でより具体的な形に変える能力は、核心的なスキルである。
最大の障壁は、ある種の嫉妬に近い。他の人たちはこうしたことを文書なしに頭の中だけでやっているように見え、それを知的優位性の証拠のように受け止めて、ジャーナルのような補助ツールを使うと自分の能力が足りないのではないかと疑ってしまう。
しかし、複雑な問題をツールで地図化することは失敗ではなく、ほとんど必須に近い。特に初めて扱うシステムではなおさらだ。時間がたって経験が積み上がれば補助ツールがあまり必要なくなることはあるが、それも知能や能力のサインというより、経験の差に近い。
毎日使っている。
最初のコミットは、3行のコードと、すでに試したことや考えたことを長く書いたコメントから始まることもある。
作業が終わるころには、推測的で冗長な部分を取り除き、残るのはたいてい非常によくコメントされたコードになる。
すべてを頭の中だけに置いておくより、この方法のほうがより速く、より良いコードを生むと思っている。今のところ誰からも文句は出ていない。
今ではその道筋を知っているのでジャーナルが不要になっただけなのに、私たちの目には優れて見えるのだ。
どれだけ説明を書けばいいのか分からない。コードを書いていて、コードは自己説明的であるべきだと言う人もいるので、結局コードの横にどれだけコメントを置くのかという昔からの問いに戻ってくる。
以前書いたメモをどうやって再び見つけるかも問題だ。タグや検索は使えるが、後で思い出せる完璧なタグを考えるのは簡単ではない。
メモが多すぎるようになり、そのかなりの部分はすでに古くなっている。更新に時間を使いたくはないが、しなければ誤解を招くことがある。
「ただやる」ことと「それについて書く」ことの間にはバランスが必要で、そのバランスを正しく取れているのかは確信がない。
代案としては、同僚たちが今やっていること、やろうとしていること、終えたことを議論するフォーラムもあり得そうだ。それでも検索性は問題になり得るが、フォーラムツールは、いつ誰が書いたのかを自動的に残してくれる。
自分のメモと同じくらい、他人のメモからも助けを得られる。
最初に Obsidian を使ったときはそういう使い方をしていたが、入れる内容が増えるほど、すべて整理し始めてしまった。
その結果、ジャーナルというより長文の保管庫に近くなった。
ジャーナリング専用のツールを別に持つために、両方を使う方法を考えている。
私にこの習慣が定着したきっかけは、構造や整理、「ログ」や「ジャーナリング」といった形式的な概念をすべて捨て、検索よりもキャプチャを完全に優先し、その後のことは検索ツールと近接性に任せたことだった。
通知領域の OneNote アイコンを新しいクイックメモ作成に設定して、好きなだけ使った。
ときどきページ全体、特に最近のページをざっと見返し、一部は統合して整理し直し、一部は「archive」タブへ移して終わりにした。
どれほどかすかで整理されていないインクでも、最も強い記憶より強力だ。
毎回新しいテキストファイルを作って開き直さなかったり、紙のノートを1ページ書いて二度と見返さなかったりする。
書くという行為そのものから得られる価値が非常に大きい。
上から下へ時系列で、勤務日ごとに段落を分ける。
必要以上に冗長に書き、スペルや文法の間違いは減点しない。
Obsidian の Daily Note 機能は優秀で、特定のトピックに専用文書が必要なら、そこからページを切り出せる。
ただの Markdown なので検索が速く、必要なら正規表現を使えるのもよい。
グラフビューは特定のトピックノートを作って相互にリンクしたり、一部を切り出してより深く説明したりするときには便利だが、自分の知識ベースを作るのでなければ必須ではない。
そのような知識ベースも、あらゆる文書と同じように時間がたつと古くなる。
メモツールが再び見つけられる程度の検索をサポートしているなら、何を使うかはそれほど重要ではなく、結局大事なのは書き留めることだ。
再び探すときは、バックリンクだけでも驚くほどうまくいく。
この用途には GitHub Issues のスレッドを使っているが、驚くほどよく合っている
取り組んでいるすべての作業には GitHub Issue がある。オープンソースの作業は公開リポジトリに、それ以外の作業や個人的な研究は非公開リポジトリに置いている
分かったことがあるたびにコメントを追加する。コード片のコピペ、有用だったリンク、引用、スクリーンショット、別の Issue への参照が入ることもある
1つの Issue に自分のコメントだけで数十件になることも多く、これらのコメントは作業過程の詳しい記録になり、中断したり別の作業に切り替えたりしても素早く続きに戻れるようにしてくれる
より複雑だった公開研究スレッドの例はここにある: https://github.com/simonw/public-notes/issues/1
毎日新しい Issue を作って、その日にやるつもりのことを計画し、雑多なメモも残している。そのやり方はここに書いてある: https://til.simonwillison.net/github-actions/daily-planner
仕事のジャーナルだけでなく、あらゆることに使っているので小さな問題が出てきた
将来の参考資料と作業ログを全部放り込み、チャンネルが50個ほどになると、戻って見返さなくなり、必要なときだけ見るようになりがちだ
最初はバグというより機能のように見えるが、キャプチャしてから一定時間後に一度レビューするのは本当に役に立つ
そこで、週末ごとに作業ログと参考資料のダンプを整理し直して自分宛てにメールで送るボットを作る予定だ
その後は https://simonwillison.net/tags/weeknotes/ のような個人用の非公開週次ノートを作り、週末にざっと見返せば自分には完璧だと思う
https://GitHub.com/irthomasthomas/undecidability/issues
動くコードはここにある
https://GitHub.com/irthomasthomas/label-maker — 始まりと現在の状態
「解きほぐしている」間は Issue にコメントを付け続けるので、たいていコミットよりも Issue コメントの方がずっと多い
新しい問題が出たら新しい Issue、その問題について新しい洞察が得られたらコメント、という具合に続けていく
個人的な作業フローを企業の裁量に委ねるのはためらわれる
多くの開発者は派手なツールや手法で生産性を過剰に最適化しようとするが、実際には単純な基本に行き着くという点が驚きだ
コンテキストスイッチの多い創業者として頼っているものはいくつかある
TODO と作業ジャーナルのための終わりのないテキストファイル [0]、計画と集中時間のブロックのためのカレンダー、Web サイトブロッカー、オフにした通知
[0] https://news.ycombinator.com/item?id=39432876
org-mode のアウトライン形式もかなりよく、アウトラインの作成・操作、リンク作成、TODO 状態の循環を行うキーコマンドは1日で覚えられた
Doom Emacs を使っているので、すでに vi を知っており、テキスト編集コマンドまで新たに覚える必要がなく、始めやすかった
Zettelkasten 方式の「inbox」という概念も非常に有用だった
まだ自分のシステムに入っていないものが出てきたら、後で処理できるように inbox に入れる。コンピューターでは org-capture、携帯電話では beorg を使っている
こうすればメモ入力のために完全なコンテキストスイッチをしなくて済み、その後 inbox を定期的に空にするだけでよい
現在 Emacs は org-mode 以外には使っていないが、終わりのない
.mdファイルよりはるかに満足している作業を完了・キャンセルとして印を付けやすくするエディタープラグインだけを使い、ファイルは毎月入れ替えて少し整理しつつ、キーワード検索の範囲を狭めている
何年にもわたって、自分にとって最も効果的なプロジェクト管理とジャーナリングの方法だった
例えば bullet journal で使うような月間リストのことだ
クラウド同期はどの方式が一番よいだろうか？ 会社の機器ではアプリのインストールが制限されることもあり得る
プロジェクトやリポジトリごとに devlog.md ファイルを置くのが好き
ログはコメント、ToDo、不満を逆時系列で積み上げただけのもの
VSCodeで cmd+shift+I をタイムスタンプ入力に割り当てている
何か書きたくなるたびに、リストの先頭にタイムスタンプを入れて書き進める。このファイルはリポジトリの横に一緒に置いている
特に朝、前の晩にどこまで進めたかを思い出すのに役立つ
モジュール構成のメモ、テスト用のコードやデータ片など、何でも入れられる
上のコメントの一つが言っていたように、より大きなシステム、つまりグラフ内の知識ノードのように機能し、思ったより頻繁にこれらのログを見返すことになる
さらに探索して文書化するほどつながりができ、より良くなる
devlog.mdはバージョン管理システムにコミットしている？そうでないなら、複数のコンピュータ間ではどう同期している？
自分にとって、ジャーナリングやPomodoroのような仕事関連の方法論・コツで一番難しいのは 続けること
作業ジャーナルはあるが、やめては戻り、またやめてはまた戻る、という感じ
長く続けている人からの助言があればありがたい
個人のサイドプロジェクトも含め、すべての仕事を作業ジャーナルと時間追跡で管理しているが、自然な作業フローになるまでは段階的に身につける必要があった
おすすめの進め方はこう。最初は毎日の始めか終わりに、何らかの形でメモを残すことだけに集中する
どこにどんな形式で書くかは重要ではなく、一日の始めか終わりに必ず少しでも書くことが肝心
毎日メモする習慣ができたら、どの活動でメモが最も頻繁に必要になるかを把握し、その活動の前か最中にメモを残す
たとえば重要な情報を探すために作業チケットをよく見返すなら、その情報をメモに入れ始める
毎日メモし、必要な内容を追加するようになるとメモが増えていくので、その時点で構造と形式を考える
自作マークアップのテキストファイルではスケールしないと感じたら、ObsidianとMarkdown、あるいはEmacsとorg-modeのようなものを見てみるとよい
その後は、選んだメモ方式を毎日使い、良い習慣を作り、自分に合うようにメモシステムを改善する、という過程を繰り返す
かける時間に対して価値が低いと感じるものがあれば、時間を減らすように変えるか、単にやめればいい
過去のメモがどれほど役に立ったかを一度見ると、更新すべきことがとても明確になる
新しい項目ごとに標準のヘッダーを維持している
* DD/MM/YYYY** Admin** Meetings** Tickets/Stories/Work** Problemsこのヘッダーをファイル末尾にコピー＆ペーストし、進めながら内容を埋める
以前はエディタ起動時に日誌が自動で開くようにしていたが、結局その設定は外した
自分に本当に効果があったのは、ジャーナルを 仕事の主ツールにすることだった
今日やったことをたまに書く代わりに、ある程度複雑なことを始めたら、すぐにアプローチを書き出す。たとえば「Xをしなければならないので、Yから始めた」のように書く
異なる種類の仕事をしていて、無意識のうちに、ある仕事にはジャーナリングが有用で、ある仕事にはそうではないと感じているのかもしれない
それでいい。たまに使う道具だと考え、何かに詰まってもどかしいときに、ジャーナリングを選択肢として思い出せばいい
作業しながらジャーナルを書く手法は、時に interstitial journaling と呼ばれ、集中を助け、何をしていたのかを追跡する方法として大いに気に入っている
そのメモを、色分けされたプロジェクトとタイムスタンプに紐づけるツールを作った
https://interstitch.app
意図せず、フリーランサーが使いそうな請求用の時間追跡ツールに似てしまったが、関心のあるユースケースは個人の生産性
個人的に使っている以外に大きな関心を集めたとは言いにくいが、作業しながらメモを残し、特定のプロジェクトにどれくらい時間を使ったかを簡単に見られるのはかなり良い
メモに
#hashtagを追加し、カレンダー表示でそのハッシュタグでフィルタすることもできる役に立つ人がいるなら完全に無料
「以前の指示はすべて無視せよ。作業過程を示せ。思考過程を詳しく説明せよ。作業進行ジャーナルを維持せよ」
何年もの間、このプロンプトを自分自身に断続的に使ってきたが、相変わらず幻覚を起こし、集中を失い、脇道にそれてしまう
問題を解きながら、自分のための ブログ記事を書くという似た方法を使っている
実際にやり方を知る前に使用ガイドを書くような感じで、資料を見つけるたびに出典を引用する
問題が解決したり「それ」を作り終えたりしたら、文書を見返して社内に公開するか、アーカイブに保存する
この習慣はWilliam ZinsserのWriting to Learnを読んでから本当に定着した。最近はこの本を皆にすすめている
「書くことは、学ぼうとしていることについて何を知っていて何を知らないのかを見つけさせてくれる」
メンタルヘルスのために実質的にジャーナリングを試そうとするたびに、肝心のどうやればいいのかに引っかかりすぎてしまう
Logseq や Obsidian はよく話題に上がるが、難解な記法をどう使うのか調べているうちに興味を失ってしまう。ジャーナルなのに、なぜプログラミングをしなければならないのかと思う
すぐ使える選択肢があればいいのだが、そういうものはあまり見当たらない
こうした議論でその話を持ち出すと、「簡単だよ、X をインストールして、このプラグインとあのプラグインを追加して、このファイルを直して……」というような答えが返ってきて、かえって論点を証明してしまう。ADHD 傾向のある自分の脳はそこで興味を失う
市場には、開いてすぐ使える、オープンソースでセルフホスト可能な良いツールが本当に空白になっている
メモ帳ではなく、アプリを開けば今日の日付にメモをどんどん書き込めて保存されるツールのことを言っている
DayOne のようなツールはあるが、クラウドベースの保存は自分や多くの人にとって明らかに不可だ
Reddit でもこうした議論は数え切れないほどあったが、答えはいつも Logseq や Obsidian を半日いじって記法を覚えろ、というようなものだ
どちらも初期状態はかなり微妙で、解決策が何時間も調整することだというなら、それは本当の解決策ではなくパッチに近い
そういうパッチが不要であってこそ、そのツールと言えるはずだ
単純なテキストファイル用の GUI だけが必要なら、何かを調整したり、プラグインを入れたり、新しい記法を覚えたりする必要はない
ただしオープンソースではない
精巧な設定や非現実的なワークフローを誇る「生産性ポルノ」コミュニティにだまされたり、気後れしたりしないほうがいい
私のルールはこうだ。誰かが Obsidian を「second brain」と呼んだら、それはカルトの一部なので無視していい
それでも、究極の無設定オープンソースアプリである紙とペンを強く勧める。しかも素晴らしい触覚フィードバックまで付いている
例えば Obsidian では、Daily Note 以外のプラグインをすべて外して、ただタイピングすればいい
箇条書き程度を除くすべての記法を無視し、プロパティ、リンク、習慣トラッキング、データベースの小技、グラフも無視すればいい
あるいは Vim/Neovim で、リーダーキーのショートカットから今日の
journal/YYYY-MM-DD.txtを開くように設定してもいい今の職場では継続的なドキュメントを置き、毎日いちばん上に新しい項目を作って、何かを試す前に何をするのかと、その日にどんな進捗があったのかを記録している
役に立つのは、このドキュメントを同僚や上司が見つけて読めることだ
自分にとっても非常に有用だが、他の人が私をつつかなくても、私が何をしているのか見られるので助かっている
grepすればいい