本日ページの運用 /AmazonからopenBDを引くブックマークレット３ /デジタルテクノロジーについて
Weekly R-style Magazine ～読む・書く・考えるの探求～ 2022/09/12 第622号
「はじめに」
ポッドキャスト、配信されております。
◇第百十三回：Tak.さんと原稿のバージョン管理について 作成者：うちあわせCast
今回は、お互いがどうやって原稿を管理しているのかをお話しました。倉下はさまざまな方法を試しているのですが、基本的にはテキストファイルベースの方法となっております。
こういう話も、なかなか外側からは見えないので面白いですね。
〜〜〜これからについて考えた〜〜〜
思うところあって、自分の今後の執筆活動に関していろいろ考えました。
物書きの仕事をはじめてもう12年ほどになりますし、このメルマガやシゴタノ！も同じくらい続けています。R-styleは18年くらい。かなり長くやってきました。その他、最近はじめた媒体もいくつもあり、全体としては混沌としています。
本棚と同じように、自分の活動もまた定期的に点検し、必要ならば整理を行うことも視野に入れたいところです。
私が今年掲げたテーマは「ライティングフローを確立する一年」でした。これは、「メモから原稿への流れ」とか「日々の執筆の流れ」をイメージした目標ではあったのですが、実際に取り組んでみると、それだけで終わる話ではないことに気がつきました。
・どんなメディアを使っていくのか
・そこでどんな方向性のコンテンツを書いていくのか
これらのコンセプトとセットになっているのです。というか、こうしたコンセプトを変えないままに、「作業」だけを変えたとしてもたいした変化にはならないでしょう。大きな枠組みが固定されたままだからです。
この仕事を始めてから、ともかく目の前の仕事を片づけることで精いっぱいな日々を送ってきましたが、一年ほどの休業期間をはさみ、その後一冊の本を──それもそれまでとかなり毛色の違う本を──書いたことで、私の目の前に広がる風景が変わりつつあります。
とあれば、ここから進み始める一歩もまた、変えていきたいところです。
別段、大きな野心があるわけではありません。広げる風呂敷自体は（いつものように）大きいでしょうが、やっていくことはこれまでと同じです。
文章を書き、本を作ること。
そこに「自分なりの仕事」を加えていくことを目標に、これまでの仕事を振り返りながら、これからの仕事について考えていきます。
もちろん、これくらい大きな「考え事」は一日で済ますことはできないでしょう。それこそ、今年いっぱいを使って、じっくりと考え続けていきます。
〜〜〜読了本〜〜〜
以下の本を読了しました。
『哲学の門前』（吉川浩満）
面白いです。非常に面白いです。とは言え、何がどう面白いのかは、簡単には説明できません。概要ではなく、細部にその面白さがあるからでしょう。
タイトルに「哲学」とありますが、哲学史の本ではありません。哲学の「入門書」でもないでしょう。ジャンルで言えば、エッセイ集・随筆集です。
ただし、本書全体からは「哲学」のにおいがします。ラーメン屋に入ったときに鼻腔をくすぐるトンコツのにおいと同じくらいに充満しています。
学術分野の一つとして、あるいはその専門家として「哲学」とかかわっていくのではなく、「市井の哲学者」として、人生に起こる事柄から「考える」という営みを行っていくこと。その内実がありありと示されている一冊です。
ここまで読むと、いかにも小難しい内容に思えるかもしれませんが、ユーモアに溢れていて、楽しく読める本でもあります。
100回逆立ちしても、私にはこのような本は書けないでしょう。
ほんとうに、本というのは、いろいろな書き方ができるものです。興味がつきるところがありません。
〜〜〜Q〜〜〜
さて、今週のQ（キュー）です。正解のない単なる問いかけですので、頭のストレッチ代わりにでも考えてみてください。
Q. 仕事の節目（5年や10年）ごとに振り返ることはあるでしょうか。そのとき、どんなことを考えますか。
では、今週のメルマガをスタートしましょう。今回は倉下のタスク管理の紹介の続きと、エッセイを二つお送りします。
「本日ページの運用」
前回は、今日のやることを書き込むリストを使っている、という話を紹介しました。いわゆる「デイリータスクリスト」です。
今回は、このリストの使い方をもう少し詳しく紹介してみましょう。
■記号の使い方
デイリータスクリストは、「* [ ] hoge」のような形でタスクを記述します。GitHubで使われているMarkdonw方式でのチェックボックスの書き方に、箇条書きの記法を加えたものです。
私がテキストファイルで開くと、「* [ ] hoge」と表現されますが、これをマークダウン変換した状態でプレビューすると、以下のように表示されます。
https://i.gyazo.com/682258d2c3a2dcc8413ede746133043c.png
Obsidianをお使いの方ならば、おなじみの記法でしょう。
この記法では、「* [x] hoge」と記述することで、チェックマークをチェックできます。
https://i.gyazo.com/d995b6a3d94c95c34097596801cf78ee.png
非常にわかりやすいですね。私はこれに「* [-] hoge」という独自の記法を採用しています。「未実行」の状態を表す記法です。タスクではあったが、結局実行されなかったものに割り振られる記法です。
残念ながら、この記法を使ってもプレビューでチェックボックスには変換されませんが（＊）、私はその意味を理解できるので十分です。
＊自作の処理を噛ませれば変換自体は可能です。
よって、私は４つの「状態」を扱うことができます。
・項目だけが書いてある
・項目がタスクになっている
・項目が終了タスクになっている
・項目が未実行タスクになっている
おおむね、この四種類があればだいたいが事足ります。そして、重要なのは「項目だけがある」状態です。
■タスクとタスク未満
私が毎朝作成しているのは、いわゆる「デイリータスクリスト」ですが、完全なデイリータスクリストではありません。なぜなら「タスク以外のもの」が記載されるからです。
「タスク以外のもの」には二種類があります。
・スケジュール
・タスク未満のこと
前者はわかりやすいでしょう。その日の14時からポッドキャストの収録があるなら、「14:00 ポッドキャストの収録」のように書かれます。そうしたものはタスクになっている──つまり、チェックボックスが前についている──ものもあれば、そうでないものもあります。
その「そうでないもの」は、私がそれに大きな注意を向けなくてもよいものです。たとえば「病院に行く」などは、大それた準備も必要ありませんので、単にそれを思い出せればOK、という感じです。
ただし、チェックボックスがついていない場合でも、それを実行したら「* [x] hoge」のように書き改めます。つまり、後からチェックボックスをつけ足します。そうすることで、これは「終わったこと」だと私の脳に認識させるためです。
同様に、「これはできれば今日中にやっておけたらいいけども、優先するほどではないかな」と思えた項目については、その項目だけ書いてチェックボックスはつけません。「* hogehogeについて調べる」のように、箇条書きの記法だけに留めます。
もし状況が変わり、その「hogehoge」の優先度が上がったり、他のタスクに一切やる気が生じないので仕方なくそれに取り掛かろうと思ったときは、チェックボックスを書き加えます。同様に、なんかしらないけどその作業やっちゃった、というときも、同様に後からチェック入りのチェックボックスをつけ足します。
どのような経緯で実行されたにしても、「実行されたこと」は同一なので記法を揃えておくわけです。
■おおざっぱに書く
上記のように、朝一で作成されたリストは「そのまま」終わることがほとんどありません。「予定」がそのまま実行に変化するわけではないのです。
また、その「予定」の形も変わることが前提として運用をしています。
たとえば、とあるプロジェクト（gtとしておきましょう）を着手しようとは思っているけども、具体的に何に取り掛かるかはまだ決められない、はっきりしない、というときは「* [ ] gt+」のような形でプロジェクト名だけ記述します。
私の運用においては、プロジェクトのタスクはプロジェクト名＋具体的なタスク名になっているのですが、朝一の時点ではっきりしないならば、その「はっきりしない状態」を記録しておくわけです。
そして、よし取り掛かろうか、というときになったら何をするのかを決めて、「* [ ] gt+アウトラインの作成」のようにリストを書き換えます。
さらに、終了したタスクに関しては、実際にどんなことをやったのかを付け加えて書きます。たとえば、「* [x] gt+アウトラインの作成（全体のアウトラインが完成）」といった感じです。
こうしておけば、タスクの項目として書いたこととは異なる「成果物」があっても、そのタスクを終了させることができますし、自分がそもそも何をしようとしていたのかの「意図」もそのまま残すことができます。
こうした些細な情報を、ちゃっちゃと残しておけるのが、テキストファイルを使ってデイリータスクリスト（っぽいもの）を作るメリットです。
■やり残したことはどうなる？
上記のようにデイリータスクリストを使いながらタスクを実行していくと、どこかの時点で一日が終わります。
無事終了したタスクは、そのままで問題ありません。（一旦は）完全に頭から消し去って大丈夫でしょう。問題は、やり残したタスクです。つまり、タスクとして設定されたにもかかわらず、実行されなかったもの。これについては、何かしらの処置が必要です。
とは言え、難しい話ではありません。次の日の朝に、前日のデイリータスクリストを見返して、残ったタスクの扱いを決定すればいいだけです。今日やるのか、それとも「もういいや」とするのか。それを判断します。
私の場合は、上記の振り返りをプログラムに支援してもらっています。どういうことかというと、その日のファイルを作成するコマンドを叩いたら、前日に作成されたタスクを表示してくれるのです。
たとえば、前日「* [ ] gt+アウトラインの作成」というタスクがあったら、
「gt+アウトラインの作成は、残しますか？」
とプログラムが尋ねてきます。yを押してリターンをすると、そのタスクは「タスク箱」（これは後の回で紹介します）に送られます。一方でnを押してリターンすると、そのタスクはどこにも送られません。
どちらの処理になっても、もともとのタスクリストには変更が加えられ、ハイフンがつきます。つまり「* [-] gt+アウトラインの作成」と変化します。何かしらの処理（あるいは判断）を施した足跡がつくわけです。
これで「その日のページ」に書かれたタスク群は役割を終えます。よほどのことがない限り、この部分を読み返すことはありません。基本的には保管されるだけの状態となります。
■まとめ
以上が、デイリータスクリスト部分の基本的な流れです。
簡単にまとめておきましょう。
・朝一に「その日やろう」と思うことを書き出す
・その際、一行一項目で書き、頭にチェックボックスをつける
・プロジェクトの場合は、コードネーム＋タスク名で書く
・スケジュールも合わせて書く
・途中で追加発生したものがあれば書き加える（タスク or 項目だけ）
・タスクを終えたらチェックボックスを書き込む
・その際、やったことを具体的に追記する（こともある）
・タスクとして書かずに実行したことも後から実行済みタスクとして書く
・タスクとして書いたがそうでなくなったらチェックボックスを消す
・やり残したタスクは次の日に判断して、処理する
だいたいはこんな感じです。もうちょっとシンプルにまとめられたらよいのですが、実際にやっていることが上記のように複雑なので仕方がありません。これを無理に「簡略化」してしまうと、きっと大切なものがこぼれ落ちてしまいます。
それでもなお、要点をまとめるとすれば、
・タスク以外のことも書く
・タスクの状態を複数持つ
・途中で気にせず書き換える
・すべてを掌握しようとしない
あたりがポイントとなるでしょうか。
ある意味で、非常に緩いルール設計です。他のタスク管理方法に比べれば、雑多な感が否めません。少なくとも、厳密でシンプルな方法ではないでしょう。それでも、長く続けていく上では、こうした緩さが個人的は役立っています。
（次回：作業記録について）
ここから先は
¥ 180
この記事が気に入ったらサポートをしてみませんか？