🐼
暗中模索の作業メモを取る際の成功体験
TL;DR
- 暗中模索で作業するときに、メモを取るのは大事
- あとで振り返リやすくするために、書く場所を分離すると良いかもしれない
- Zennのスクラップは「やったこと」「考えたこと」を残すのに適してる
- Issueのコメントは「悩み」「TODO」を残すのに適してる
背景
作業メモを取ることの大切さ
漠然とした目標を持って取り組みはじめて、模索しながら作業すると、様々な形で迷子になることがあります。
- 全体で何を目標にしていたのか見失う
- 目標到達までに消化するべき課題の、何をどこまでこなし、この後どうしようとしていたのか見失う
- 傍流の課題に取り組み始めてしまって、本筋を見失う
これらを防ぐために、作業メモを取ることにしています。
対象としている「作業」
作業と単純に言っても、様々な様態がありますが、今回の記事で対象としているのは以下のような経過を辿るものを指しています。
- あまり前もって目標をマイルストンに分解しない
- 大きな目標を設定しただけで作業にとりかかる
- 目標到達に向けて消化するべき課題を作業中に順次分解する
- 分解した課題を順次こなしていく
作業メモにおける課題
これまでは、GitHub Issueを使っていました。
- 課題が見つかった時点でIssueを立てる
- Issueのコメントにメモを書きつらねる
ですが、この作業メモを上手く機能させるのは思いのほか難しく、1つのIssueに連なるコメント群では、
- 作業中に残課題を見つけることが難しい
- 後で何をしたのか分かりにくい
というデメリットがありました。
- 目的を達成するまでに複数の課題と向き合う必要がある
- 作業中に新しく課題をみつけても、即座に対応できるわけではない
- 対応してもよいが、コンテキストが無用に深い入れ子構造になってしまうためよろしくない
ことから、時系列順に書き連ねるだけでは内容が複雑に絡み合ってしまい、とても読みづらくなってしまうようです。
今回の成功体験
先日、Neovimのプラグインマネージャーをpacker.nvimからlazy.nvimに乗り替える作業をした際のことです。
試しにメモを2か所に分割してみました。
- GitHubに立てた「lazy.nvimに乗り替える」というIssue : https://github.com/kyoh86/dotfiles/issues/5
- Zennに起こしたスクラップ : https://zenn.dev/kyoh86/scraps/65b3b0b5f7130a
何の気なしに始めたことなので、最初は何のポリシーもなく、まったく住み分けができていなかったのですが、途中からいくつかの発見がありました。
- Zennのスクラップには、「やったこと」「考えたこと」を書くと良い
- スクラップは取り組んでいる課題ごとにスレッドを分割するとよい
- ひとたび解決したと思った課題も、後から追加の作業が発生するが、元のスレッドに連ねて書き始めることができる
- 一度作業を中断しても、復帰した際に、何がどの程度まで進行しているのか分かりやすい
- GitHubのIssueのコメントには、見つかった課題、「迷い」「悩み」を残すと良い
- 「未解決の課題」がコメントの一覧という形で見通しよく管理できる
- 解決した課題はコメントのHide (Resolved)で隠すことができる
他の解決
この成功体験は、あくまでサンプル=1の例でしかないため、他にも解決する手段はいくらでもありそうです。
- 異なる媒体を使う(例:scrapbox)
- GitHub Issueを複数に分割する
- そもそもそんな曖昧な状態で作業しない
私自身も未だ強い確信を持つほどの方法論ではありませんが、参考にでもなればと思います。
Discussion