一週間の振り返り / ScrapboxのUserScrip / 次の10年に向けて
Weekly R-style Magazine ～読む・書く・考えるの探求～ 2022/10/03 第625号
「はじめに」
ポッドキャスト、配信されております。
◇BC047『リベラルアーツ 「遊び」を極めて賢者になる』 | by goryugo | ブックカタリスト
今回は、ごりゅごさんが『リベラルアーツ 「遊び」を極めて賢者になる』を紹介してくださりました。
「リベラルアーツ」がなんなのかはさておき、「遊び」を（つまり、ある種の不真面目さを）評価する視点はたいへん好感が持てます。
〜〜〜Scrapbox、5000ページ〜〜〜
ふと右下を確認したら、Scrapboxの総ページが5000を超えておりました。
◇倉下忠憲の発想工房
さすがにEvernoteの7万ページと比べれば少ないですが、やたらめったらWebクリップしていたEvernoteに比べると、Scrapboxは小さくても一つひとつ「意味のあるページ」を作っているので、5000ページはかなり多いと感じます。
ちなみに「足跡」は以下の通り。
・2019/5/1 1537 pages
・2019/5/2 1562 pages
・2019/5/10 1601 pages
・2019/6/04 1700 pages
・2019/7/7 1852 pages
・2019/7/18 1900 pages
・2019/11/3 2112 pages
・2019/11/24 2276 pages
・2019/12/8 2325 pages
・2020/3/3 2437 pages
・2020/3/26 2502 pages
・2021/08/18 4000 pages
・2022/1/21 4440 pages
・2022/4/7 4560 pages
・2022/4/21 4608 pages
・2022/6/6 4721 pages
・2022/8/15 4880 pages
・2022/9/29 5002 pages
気が向いたときにしか記録していないので、期間はまちまちですが、だいたい一年で1000ページ増えている感じです。一日で均すと、2.7ページほど。まあ、無理のない範囲といえるでしょう。
これまでこうしたwiki的ツールは、一ヶ月も使えば疎遠になってしまうのがオチだったことを考えれば、この5000ページは大きな達成と言えるでしょう。
でもって、そこまで熱心に「よし！ページを増やすぞ」と思っていなかったのにもかかわらず、じわじわとページが増えてきたことが面白いと思います。
というよりも、熱心に思わなかったからこそ、じわじわと続けてこれた、というのが正確なのかもしれません。wiki的なものは、最初「あれも書いて、これも書いて」と盛り上がるものの、結局面倒になってやめてしまうことが多いので、そういう熱量をあえて上げないようにしているScrapboxに手助けされている面はありそうです。
もちろん、ページの数が多ければすごい、というものではありません（もしそうならEvernoteがチャンピオンでしょう）。そうではなく、「同じ情報ツールを、無理なく使い続けられている」という点がすごいのです。
このすごさは、目に見える「多機能さ」とは逆向きの、押さえ込んだ「機能」──ネガティブ・ケイパビリティになぞらえて、ネガティブ・ファンクションとでも呼びましょうか──によってもたらされるので、使いはじめた頃はなかなか気がつけませんが、使い続けていくうちにジワジワとその良さが染み込んでくるはずです。
というわけで、そういう「良さ」を伝える本も、また改めて書いてみたいところです。
〜〜〜リコリコ最終回〜〜〜
アニメ『リコリス・リコイル』が最終回を迎えました。いろいろな終わり方ができる物語だったと思いますが、一番「きれい」な終わり方だったと思います。
＊この「きれい」には含みがありますが、ネタバレになるので言及は控えます。
◇オリジナルTVアニメーション「リコリス・リコイル」公式サイト
前評判の段階では、そこまで関心を持っていなかった作品ではありますが、蓋を開けてみれば今期一番の作品と呼んでも誇張はない結果になっています。たしかに面白い作品なのです。
何がそんなに面白いのか？
これがうまく言葉にできません。優れた作品の証左です。
いろいろな要素を思い浮かべることはできますが、「これ！」というものはまだ見つかりません。霧の向こう側です。
もう一度、全体を見返しながら、この作品について考えて──できれば文章にして──みたいと思います。
〜〜〜Q〜〜〜
さて、今週のQ（キュー）です。正解のない単なる問いかけなので、頭のストレッチ代わりにでも考えてみてください。
Q. 日常に「遊び」はありますか。どれくらいありますか。
では、メルマガ本編をスタートしましょう。今回は、倉下の仕事術として「一週間の振り返り」と、あと二つのエッセイをお送りします。
「一週間の振り返り」
本格的な「週次レビュー」を止めてから、かなりの時間が経ちますが、あれやこれやと模索しているうちに、結局「週に一回の振り返り」を行うようになっています。
実施しているスパンで言えば、この二つ──週次レビューと週一回の振り返り──は、まったく同じですが、しかし目指すところは違っています。
GTDの週次レビューが、自分が使っているリストを最新の状態にセットアップし直すことを目的とするならば、週一回の振り返りは、自分がその週に実行したことを確認し、次週「やろうとしている」ことを設定することを目的とします。ずいぶん違う目的です。
あるいは、GTDの週次レビューの目的が「リストの再セットアップである」という私の認識が間違っているのかもしれません。しかしながら、アレンの本を読んでいると、「とにかく、適切なリストを維持しておくことが大切なのだ。それさえできていれば、行動を選べるようになるのだから」という雰囲気が醸成され、注意のターゲットが"リスト"に向きがちです。
一方で、今の私がやっている週一回の振り返りは、「意志」に注意を向けるようにしています。自分は何をやろうとしているのか。それを確認するために振り返りを行っているのです。
■実際にやっていること
では、実際に何を行っているのかと言えば、主に以下の三つを行っています。
・ツイートの振り返りと処理
・「やったこと」の振り返りと次週の設定
・「プロジェクト」の振り返りと次週の設定
まず、一週間分のツイートを読み返し、有用なツイートを拾い上げ、それを適切だと思える主題ノートにコピペしていきます。
この「主題ノート」は現在15個あり、仕事術・知的生産・読むこと・書くこと・テクノロジー、といったテーマを持っています。拾い上げたツイートを読み返し、「これはこのテーマだな」と思える主題ノートに配置していくわけです。
ポイントは、これは「カテゴライズ」ではない、ということです。そうではなく、「似たものをまとめて置いている」だけです。だから、後から置き場所を変えることもありますし、似たものがなければ新しい主題ノートを作ることもあります。
この主題ノート作りでやっているのは、「自分がどんなことに関心を持ち、アイデアを出しているのか」という傾向の確認です。
その意味で、次に紹介する「やったこと」の振り返りと目的は似ています。別の言い方をすれば、「考えたこと」も「やったこと」の一つとして処理しているのです。
■「やったこと」の振り返り
次に、実際の行動的な「やったこと」の振り返りです。
一週間で「やったこと」のうち、プロジェクトに関するタスクは、week.mdというファイルに自動的に収集されます。
具体的には、
「メモの整理」
というタスクは収集されず、
「TH+chapter08」
というタスクは収集されます。
記法で言えば、プロジェクト名+タスク名、という形で記述されている実行済みタスクが week.md に収集されるわけです。
よって、一週間が経つと、week.md には一週間分のプロジェクト系タスク（実行済みタスク）が集まっています。
週に一度の振り返りでは、まずそのタスク群を「整理」します。タスクは、実行順の時系列で一列に並んでいるので、それをプロジェクトごとに並び替えるのです。
つまり、以下を、
・TH+chapter08
・メルマガ+main稿
・PT+chapter02
・メルマガ+sub稿
・TH+chapter08の続き
以下のように整えます。
・TH+chapter08
・TH+chapter08の続き
・メルマガ+main稿
・メルマガ+sub稿
・PT+chapter02
この並び替え処理は、スクリプトを使えば自動的に行えますが、今のところは手動で行っています。むしろ、そうやって手を動かすことが必要だとすら感じています。
そうやって整理しているうちに、「ああ、今週はこのプロジェクトのタスクをたくさん実行できたな」と思えるからです。そういう実感を得ることが、存外に大切です。
■文章でまとめておく
そうして並び替えの整理を終えたら、「今週の概況」を短い文章で綴ります。今週やろうとしていたことはできたのか、できたことはどんなことだったのか、どういう状況でそうなったのかを軽く振り返るわけです。
それが終わったら、それらをまるっとコピーして、done.md というタスクアーカイブ用のファイルに移します。そうして、week.md まっさらな状態に戻すわけです。
その上で、「じゃあ、次週はこれを目標にしよう」と決めて、それをweek.mdに書き込んでおきます。
■「プロジェクト」の振り返り
上記は、一週間の全体的な振り返りですが、それが終わったら個別のプロジェクトに関する振り返りを行います。
とは言え、手持ちのすべてのプロジェクトを対象するわけではありません。そもそも、手持ちのプロジェクトはわんさかあるので、すべてを振り返っていたらいくら時間があっても足りません。
さらに言えば、手持ちのプロジェクトをすべてレビュー対象にしてしまうと、プロジェクトが増えるごとに、総レビュー時間は増えていきます。そうなると、次のどちらかが起きるでしょう。
・時間がかかりすぎるようになってレビューが嫌になる
・面倒なので、「プロジェクト」にしないようになる
どちらにせよ、本末転倒です。
そこで私は、振り返りの対象を「３つのプロジェクト」に限っています。どれだけプロジェクトを作っても構わないが、ある時期にコミットするプロジェクトは最大３つまでと決めるのです。
別にこの「３つ」に大きな意味はありません。２つでもいいですし、４つでもいいです。もしかしたら最大６つくらいまでならケアできるかもしれません。
なんにせよ、上限となる数字を決めておくのです。そうすれば、プロジェクトがどれだけ増えたところで、振り返りにかかる時間がそれに比例して増えることは抑制できます。振り返りが嫌になりにくいのです。
もしかしたら、GTDにおける「プロジェクト」というのは、私にとっての「３つのプロジェクト」に相当し、それ以外のプロジェクトは「いつかやること」リストに入れるべきものなのかもしれません。
一方で、プロジェクトリストの項目はかなりの数になるとアレンが書籍で述べている箇所があります。その数が10や20を超えてくるならば、私の運用と同じとは言えないでしょう。
この辺り、GTDではどうなっているのかはわかりませんが、とりあえず私はプロジェクトを作り、その中で「定期的に振り返る、コミットしているプロジェクト」と「そうでないプロジェクト」を分けて管理し、前者についてだけ週に一度振り返るようにしています。
■何を振り返るのか
振り返りは、簡単です。
先ほど整理した「やったこと」には、プロジェクトのタスクがまとめられていますので、それを見返しながら、進捗を確認します。今週やろうとしていたことはできたのか、できたことはどんなことだったのか、どういう状況でそうなったのかを振り返るのです。
そうした振り返りも文章で書き留め、プロジェクトの情報を記録してあるノート（ファイル）に保存します。そして、次の週の目標を新たに書き出します。
それが終わったら次のプロジェクトでも同様のことを行い、さらにもう一つのプロジェクトも振り返ったら、それでプロジェクトの振り返りは終わりです。
■過去への視点と、未来への視点
ご覧のように、私のこの「週に一度の振り返り」は、リストの更新を目的としていません。というか、更新されるリストはほとんどありません。
・week.mdを空っぽにして新しい目標を設定する
・done.mdにその週にやったタスクと振り返りをアーカイブする
・各種プロジェクト.mdにその週の振り返りと次週の目標を書き足す
基本的にはこれだけです。「更新する」というよりは、「情報を追加する」が近しいでしょう。それまでの自分の「やったこと」（＝
成果）を確認し、そこからの自分の「やろうとすること」を書き記すのです。
むしろ、「来週はこれようしよう」と決めるためには、「今週（まで）は何をしてきたのか」を振り返り必要があるのだと言えるかもしれません。そうしないと、いつまで経っても無茶な目標を立て続けてしまう可能性があります。
「今週はこれだけやった。次週も同じだけやろう」とか、「今週は目標に対してこれだけしかできなかった。目標を少し落とそう」といった決定が可能なのは、自分の足跡を振り返っているからです。いつもまっさらな状態から目標を決めてしまえば、毎回同じような「失敗」を繰り返すだけです。
だからこそ、「やったこと」を振り返るのです。
■タスクは作らない
もう一つのポイントは、この振り返りでは、ほとんど「タスク」は発生していません。単に次の週の「目標」を決めているだけです。
この「目標」を、私は「ターゲット」と呼んでいますが、具体的な行動を示すものではなく、その週に達成できたらよいと思う状態を示すものです。たとえば「Chapter08の本文を書き上げる」といったものがターゲットになります。
このターゲットから、個々の具体的なタスクが生まれるのですが、振り返りの段階ではそのタスクの生成までは行いません。具体的なタスクは、「その日のリスト」を作るタイミングまで遅延させておきます。
そうすることで、具体的な行動を選ぶ自由が（明日以降の私に）生まれます。その感覚を、個人的には大切にしたいと思っています。
■まとめ
まとめておくと、私の一週間の振り返りは、
・「やったこと」を振り返り、短く文章でまとめる
・一週間と３つのプロジェクトの「目標」を再設定する
・具体的な「タスク」を決めることはしない
という要素で形成されています。
この形に落ち着くまでは、本当にいろいろな形を試しましたが、今はかなりしっくりと来ていますし、実際に無理なく継続もできています。
なんにせよ重要なのは「自分がタスクを実行する気持ちになるのはどういうときで、そうならないときはどういうときなのか」という点を理解しておくことです。さまざまな試行錯誤は、その理解を助けるためにあると考えておけばよいでしょう。
（次回はプチレポを書くことについて）
ここから先は
¥ 180
この記事が気に入ったらサポートをしてみませんか？