見出し画像

「作業記録の読み返し」について / 正規表現の勘所その２ / 『ファスト教養』を読む その３」

倉下忠憲

Weekly R-style Magazine ～読む・書く・考えるの探求～ 2022/10/24 第628号

はじめに

先週紹介していた、Twitterスペースの録音が公開されております。

紹介記事は以下。

◇テクノロジーカルチャー・セッション 第４回 ゲスト：倉下忠憲さん（文筆家）｜池谷和浩｜note

「テクノロジーカルチャー」の感覚は、なかなか言語化が難しいですが、こうして話していくなかで立ち上がっていくものはたしかにありますね。

あと、誰かと話すことの効能はやっぱり大きいです。思考の刺激効果がたいへん強く感じられます。

月に一回くらいでも、こういうイベントごとをやりたいなと思いながらも、なかなか難しく感じております。

〜〜〜まぐまぐ大賞2022〜〜〜

まぐまぐで購読されている方に向けての情報です。

今年もまた、あの賞がやってきました。そう、まぐまぐ大賞です！

といっても、そう大げさな話ではなく、いろいろなジャンルのメルマガでランキングをしよう、というもの。読者の方の投票結果に応じて大賞が決まったりするようです。

投票期間は、10月20日（木）から12月6日（火）の12時まで。

当メルマガへの投票は以下のページの「このメルマガをまぐまぐ大賞2022に推薦する!!」ボタンから可能です。

◇倉下忠憲 | Weekly R-style Magazine ～読む・書く・考えるの探求～ - メルマガ

もしよろしければポチっと投票してみてください。

〜〜〜日記のトリガー〜〜〜

毎日、朝の時間帯に「昨日の一行日記」を書いています。これまでは、一行日記.mdというファイルを開き、その一番上に日付と一行の日記を手動で書き込んでいました。デジタルだけども、アナログ感のある操作です。

あるとき思いついて、この流れを変えました。

毎朝、同じ時間に「その日の作業記録」用のファイルを自動的に作成するのですが、そのプログラムに「昨日はどんな一日でしたか？」と表示させ、入力を受けつけるようにしたのです。

そうすると、作業記録のファイルは毎日作成するので、昨日の日記書きも毎日行うことになります。しかも、ファイルを開いて追記、みたいな操作をする必要がありません。そのままターミナルにテキストを打ち込めば、それが一行日記.mdのしかるべき位置に、日付つきで書き込まれます。

これぞプログラミング、という感じがしますね。

Gitを使っていると、コミット時にメッセージの入力が求められますが、それと似た感覚があります。

もう一つ、自分なりにこだわったのが、日記の入力を促す際に、直近5日分の過去の日記をターミナルに表示させることです。実際、手動で一行日記を書いていたときも、昨日の日記を書きながら、前日以前の日記を読み返し、「そういえば一昨日は……」みたいなことを想起していたのでした。

そうした「所定以外のデータ」が目に触れるという「アナログ」な感覚を、プログラムにも実装してみたわけです。今のところは、なかなか良い感じです。

〜〜〜カレンダーの効用〜〜〜

最近、カレンダーをまったく見ていません。もちろん、家には壁掛けのカレンダーがありますし、ツールとしてGoogleカレンダーは使っています。しかし、主要な予定はほぼそこには書いていないのです。

では、どこに書いてあるのかと言えば、リストです。箇条書きリスト。

具体的には、schedule.mdというテキストファイルに、日付順に予定が書き込んであります。でもって、これで問題ありません。

もともと、「予定」（≒アポイントメント）がほとんどない仕事生活を送っているので、書き込む情報も少なく、リストであっても一覧性が損なわれることがありません。そして扱いはリストの方がはるかにラクチンです。

とは言え、たまに他の人と予定を合わせるときなどはカレンダーを見る必要があるので、先日、自作のTextboxにカレンダーを設置してみました。JavaScriptで作った、ごく普通の日付が表組みで並んでいるカレンダーです。

そのカレンダーを眺めていると、不思議な感覚が湧いてくることに気がつきました。あえて表現すれば「公共とつながっている感覚」です。自分の外には「世界」があって、そこと自分が接続しているんだぞ、というのが再確認されるような感覚です。

何によってこの感覚が引き起こされるのかを考えてみると、それは「予定のない日の表示」であろうと思いつきました。

予定を箇条書きリストで管理していると、予定のない日はそのリストには存在しないことになります。だからこそ、リストでの予定管理は非常にコンパクトに成立するのです。自分の予定がある日だけが項目として存在するので、どう考えても365行にはなりません。

一方で、カレンダー形式ではすべての日付がそこに表示されます。私の予定とは無関係に365日（あるいは366日）が存在しているのです。プログラミング的に言えば、nullではなく0が示されているのです。

示されるその０は、「その一日の存在」を感じさせてくれます。私の予定がない日でも、その一日はたしかに存在して、他の誰かは予定を入れているかもしれない、という感覚があるのです。その感覚が公共への接続です。

そもそも、一年が365日だったり、一週間が7日に分割されていたり、というのは物理的なルールではありません。そうではなく、この社会で一般的に通用している決めごとです。公共的なルールなのです。

自分の予定だけが示されているリストだと、その「公共的」な感覚が非常に薄れてしまうのです。

もちろん、それが良いことなのかどうかはわかりません。弊害ももしかしたらあるかもしれません。

ただ、その是非の判断の前に、「私たちの目に入るものが、私たちの感覚を支えている」という事実をまず直視した方がよいでしょう。これは存外に軽い問題ではなさそうです。

〜〜〜Q〜〜〜

さて、今週のQ（キュー）です。正解のない単なる問いかけなので、頭のウォーミングアップ代わりにでも考えてみてください。

Q. カレンダーや手帳は利用されていますか。どのように利用されているでしょうか。

では、メルマガ本編をスタートしましょう。今回は倉下の仕事術として「作業記録の読み返し」を紹介します。加えて、二つのエッセイをお送りします。

「作業記録の読み返し」について

今回は、作業記録の読み返しについて書きます。作業記録を書くことではなく、それを読み返すことです。

なぜ、読み返しをテーマにするのか。

もちろん、そこに大きな問題が横たわっているからです。

■作業記録を書きながら作業する

私は普段、作業記録をつけながら作業を進めています。一日の終わりに日誌を書くのではなく、作業が一区切りつくたびに、その記録を残すのです。その仕事を進め方を「ロギング仕事術」なんて呼んだりもしています。

これは電子的なツールで作業を進めているからこそ可能なアプローチでしょう。すべて手書きであれば、面倒すぎてここまで細かい単位で記録を残すのは不可能だったと思います。

たとえば、今このメルマガの原稿を書いている真っ最中ですが、これが終われば、その旨を作業記録に書き、「n文字の原稿を書いた」なんて添えると思います。

そうやってごく短い時間で作業を振り返り、一区切りつけてから次の作業に向かえる、という心理的な切り替えがロギング仕事術の一番のメリットです。

デジタルツールであれば、こうした書き留めが簡単なのは良いのですが、問題は読み返しです。

書き留めるのが簡単だからこそ、読み返しの難しさが増大してしまう、という問題が起きるのです。

■読み返しの面倒さ

話は至極簡単です。たくさん書けば、それを読み返す量もたくさんになる。当たり前の帰結です。そうなると、だんだん読み返すのがしんどくなってきます。

一応、作業記録はnoteのサークルやPixivFanboxで共有しており、他の人が読める文章で書いています。その意味での読みづらさはありません。しかし、大量の文章はそれだけで負荷になるものです。特に、一週間単位でざっと振り返りたいときなどは、非常にうっとうしい（≒圧が大きい）のです。

こうしたときに役立つのが、アウトライナーでしょう。

かたまりごとにグループを作り、それに見出しを与えることで、視点を一つ上にあげてくれます。振り返りのときは、まずその見出しだけをざっと振り返ればOKです。

とは言え、私が使っているのはテキストエディタ（VS Code）です。アウトライナーのような階層構造の構築はできません。見出しの中身の開閉は可能ですが、アウトライナーと同じような視野の広さまでは確保できません。

だからといって、作業記録を書くためだけにアウトライナーを使いたいとは思いません。なぜなら、単につらつら書くだけならばテキストエディタの方が快適だからです。

作業記録は、時系列で書き留めていくものであって、後からその順番を動かすことはありません。すべての出来事は、「その日」という単一のレベルにフラットに並ぶことになります。

つまり、書いているそのときには、階層構造は不要なのです。一方で、それを後から見返すときには、階層構造が役立ちます。ここにジレンマがあるのです。

別の言い方をすれば、書くときのグッドなフィーリングと、読み返すときのグッドなフィーリングは必ずしも一致しない、となるでしょう。

■ファイルへのアクセス

もう一つ、一日一ファイルの形で作業記録を書いていると、「アクセス」に関する問題が発生します。

たとえば、今日が10月18日でその日の作業記録を書き、次の日になったからもういらないと、その日の作業記録ファイルを閉じたら、もうその日の記録は「目に入らなく」なります。

もちろん、ファイル自体は存在しているので開けばいつでも閲覧できますが、逆に言えばそのような意図的な操作をしない限りは、目の前からは消えうせるのです。

これが手帳や日記であれば話は変わります。ページは連続して綴られているので、次の日になっても、その次の日になっても、記録は「目の前」に残り続けます。意図的な操作をしなくても、ふらっと目に入ることが起こりえるのです。

この点、Logseqであればバッチリです。ファイル自体は分かれていても、日誌用のファイルはスクロールすれば過去分が表示されるようになっています。操作は必要ですが、それでも「ある日付のページを開く」のような意図はなくても構いません。ざっとページを振り返ることができます。

しかも、Logseqはアウトライナーの機能もあります。先ほど述べたような視点を上にあげる使い方もできるのです。

だったら、Logseqが最強なのかと言えば、なかなかそうは言えないところが、この問題の難しさです。

■実際の体験から

実際私も、一ヶ月ほどLogseqで日記・日誌的なものを書いてみたことがあります。そして、たしかにそこには便利な体験がありました。上記で検討したような流れがスマートに実現できていたからです。

特に、ハッシュタグを使うことで、特定のプロジェクトの記録を串刺して検索できるのがグッドです。

しかし、そのような意図的な検索ではない、ふわっとした振り返りにはあまり役立ちませんでした。アウトライナー的に階層構造を作って、見出しだけを読み返しても、振り返ったことにはならないからです。

たとえば、「project-TH」「project-BCB」などのプロジェクト名が見出しになりがちですが、そんなものが列挙されていても、結局何をやったのかはわかりません。

かといって、何をやったのかの詳細を知るために項目をすべて展開するならば、結局それはテキストエディタで全文を閲覧しているのと変わりません。

つまり、ものすごく中途半端な塩梅なのです。

このやり方をうまく機能させるには、作業記録の見出しをつけるときに、「project-TH」のような単純なプロジェクト名だけではなく、その時間に何をしたのかの要約（サマリー）をつける必要があるのでしょう。

しかしながら、毎回そんなことをやっていたら、根本的に作業記録をつけるのが面倒になることは目に見えています。少なくとも、ロギング仕事術の頻度でそうした細かい要約作りは現実的ではないでしょう。

■ビューを変える

だったら、どうすればいいのでしょうか。

長らく悩んでいたこの問題を、一つの天啓が解決してくれました。

「書くときのビューと、見るときのビューは同じでなくてもよい」

これです。

具体例をお見せした方が早いでしょう。私は普段VS Codeで作業記録をフラットに書いていますが、一日が終わると、そのファイルから以下のような形式で表示できるファイルが（自動的に）生成されます。

https://i.gyazo.com/955573cd1b3cdc23c95bece79ee91681.png

これはTextboxで閲覧できるファイル、つまりmdファイルです。それぞれの見出しのかたまりごとに一つのブロックが作られ、その中身が少しだけ見えるようになっています。すべての行でなく、先頭の数行だけが目に入るようになっているのです。

こういう見え方は、アウトライナーではなかなか難しいでしょう。基本的に「開閉」──すべて見えるか、すべて隠すかの二択になっていて、より細かく制御したければ、階層をもう一段階深くする必要があります。もちろん、それはフラットに書きたい作業記録とは相性がよくありません。

今回作った形式であれば、冒頭の数行だけが読めます。でもって、その数行で、その作業で何をしたのかがわかります（だいたいその部分で、宣言しているからです）。

また、このブロックはスクロール可能です。CSSで言えば、overflow-y:scroll;になっています。よって、見えている部分以降の記述もスクロールすればそのまま読めます。何かをクリックする必要すらありません。

まだ、この体制をはじめて一ヶ月も経っていませんが、非常に快適です。まるで手帳を使っていた頃のように、気安く前日以降の記録を閲覧することができています。非常にグッドです。

■二つのポイント

ポイントは、以下の二点にまとめられるでしょう。

・書き終わった作業記録は、静的になる
・書くときのビューと、見るときのビューは同じでなくてもよい

書き終わった作業記録は、以降追記されることはなくなります。だから、そのファイルを変換しても問題が起きにくいのです。その性質を利用して、より「見る」に特化したビューに合わせたファイルを生成する。そんなイメージです。

もちろん、もともとの作業記録はそのまま残っていますので、VS Codeを使えば全体に対する検索も容易です。プロジェクトごとの串刺しなどは、プロジェクト名で検索すれば一発で行えます。両方の性質をいいところとりできるのです。

以上のように、「変換を行う」「多重にファイルを持っておく」というのが、デジタル的なノート術の特徴と言えるでしょう。そういう考え方をベースにした運用方法を今後も開発していきたいところです。

（次回は定期的に荷を下ろすことについて）

ここから先は

6,332字 / 3画像 / 1ファイル

¥ 100

この記事が気に入ったらサポートをしてみませんか？