はじめに
(2019/05/28 追記) こちらのサイトにて全面的に書き直しました → Life Programming(ライフプログラミング) | monolithic
ライフプログラミングとは
ライフプログラミングとは、自然言語 を用いて 自分自身に対する命令（指示） を実装（記述）し、実装したコード（指示の集まり）を 自分という名のインタプリタに実行させる という活動です。「プログラミング」とありますが、この説明のとおり、本当のプログラミングとは性質が異なります。あくまで比喩にすぎません。
ライフプログラミングは、言ってしまえば TODO リスト（TODO を書いたものを自分が読んで対処する）の運用にすぎません。しかしライフプログラミングでは、プログラミングのアイデアを積極的に活用することで、プログラマーにとって親しみやすく馴染みやすい TODO リスト運用を確立することを狙います。
ライフプログラミングが誕生した背景
仕事や私生活においてやるべきことはたくさんあり、これらを頭だけで管理・運用するのは骨が折れます。
この問題に対処するのがライフハックであり、もっと言うとタスク管理ですが、この界隈はドキュメントが整っておらず、またビジネスライクでもあります（すぐに有料だとかセミナーだとかいった要素が顔をのぞかせます）。これはオープンで自由なリソースに慣れ親しんだプログラマーにとっては、とても馴染めるものではなく、どころか嫌悪感さえおぼえます。
しかしながら、このような知識、理論、概念などが有益なこともまた事実です。そこで「プログラマーにとってわかりやすく体系化すれば利用しやすいのではないか」と考え、整備され始めたのがライフプログラミングです。
ライフプログラミングは筆者 stakiran によって、2019/01 に提唱されました。というかここで初めて提唱します。はたして有益性をわかりやすく示すことができるのか……。
目次
本記事の全体構造は以下のとおりです。
- はじめに
- PART.1 ライフプログラミングのイメージを掴む
- PART.2 メインリストとネクストメインリスト
- PART.3 指示
- PART.4 実行
- PART.5 ライフプログラミングの具体例
- 付録
- おわりに
==== PART.1 ライフプログラミングのイメージを掴む ====
PART.1 では、ライフプログラミングのイメージを掴むための概要説明や基礎知識の紹介を行います。
プログラミングとの違い
ライフプログラミングのイメージを直感的に掴むため、プログラミングとの違いをあげてみます。
実装や実行方法の違い
プログラミング:
- プログラミング言語でコード（式、命令、文の集まり）を書く
- インタプリタに解釈させて実行する
- ※便宜のためコンパイルなど他の方式は取り上げません
ライフプログラミング:
- 自然言語で指示（具体的に行動が可能なキーワードや文章の集まり）を書く
- インタプリタ（自分自身）が読んで実行する
実行形態の違い
プログラミング:
- 処理が終わったら終了する（非常駐）
- 常駐してリクエストが来たら捌く（常駐）
ライフプログラミング:
- 指示の一部を実行したら終了する（非常駐）
ライフプログラミングでは後述するメインリスト（今日やる指示の集まり）を全部対処することを目指します。一回の実行で全部対処してもいいですし、何十回と実行を分けて少しずつ対処しても構いません。
基本用語
ライフプログラミングにおける基本用語を整理しておきます。
指示
指示 とは「自然言語で記述された、具体的に行動することが可能なキーワードや文章」です。
以下に指示の例を示します。
まずは良い指示の例です。
- 自作ソフト A の Issue に新着が無いかを見る
何をすればいいかが自明です。ソフト A を GitHub で公開していることは自分にはわかっているので、GitHub の A リポジトリの Issue を見ればいいのだとわかります。
次に、悪い指示の例です。
- A の新着
「A の新着」だけでは具体的に何をすればいいのかがわかりません。せめて「A の Issue 新着」くらいは書くべきでしょう。（ただし将来の自分が見ても正確に読み解けるのであれば「A の新着」でも「A」でも「新着」でも構いません）
実装
実装 とは指示を書くことです。
もっぱらリストに書くことを表します。
リスト
リスト とは一行に一つの指示を並べたテキストのことです。
リストはテキストファイルかもしれませんし、Web サービス上のテキストエリアかもしれませんが、とにかく指示が並んだもの、指示の集まりだと捉えていただければ差し支えありません。
実行
実行とはリストに書かれた指示を読み、一つずつ対処していくことです。
対処
対処とは、指示の一つについて、その内容に従って行動し、かつ行動後に当該指示（を記述した文章）を対応完了に更新することです。以下のように、二つの行動が必要であることに注意してください。
- 行動する
- （対応完了状態に）更新する
チェックリストでも対応後はチェックを付けますが、それと同じです。
主な登場人物
ライフプログラミングにおいて頻出する登場人物について、かんたんに取り上げておきます。
メインリスト
いわゆるメイン関数のような存在です。
メインリストとは 今日一日の指示 を実装したものです。
インタプリタである自分自身は、このメインリストを読み、書かれた指示に一つずつ対処していきます。すべて対処できたら、今日はおしまいです。
ネクストメインリスト
ネクストメインリストとは 明日以降の指示 を実装したものです。
ネクストメインリストは言わばテンプレートあるいはスニペットのようなものです。直接実行することはありませんし、メインリストから関数のように呼び出して実行することもありません。使い方としては、メインリストを 実装する時に 適宜参照したりコピペしたりします。
ネクストメインリストの存在意義は、 メインリストをできるだけ小さく保つため です。メインリストには今日やるべき指示だけを書いておき、それ以外は全てネクストメインリストに入れておきます。そうすればメインリストは今日の分だけで小さく済みます。明日になったら、ネクストメインリストを参考にしてまたメインリストを実装し直せば済むだけです。
インタプリタ
メインリストに書かれた指示を解釈（Interpret）する存在で、つまりは（ライフプログラミングを行おうとする）私たち自身のことです。
当然ながら私たちは人間であり、機械ではないため、一般的なインタプリタのような正確で高速な解釈は実現できません。ただし、自然言語という抽象的で複雑な文章を読み、解釈することができます。
サブリソース
サブリソースとは、メインリストに書かれた指示に対処する過程で適宜アクセスする資源（Resource）を指します。
指示は時として複雑かつ長大になりますが、メインリストにすべてを記述することはできないため、ライフプログラミングでは、以下のように
- サブリソースとして外に出す
- メインリストには「～～を使って～～をする」という指示を書く
二段階に分けて扱います。こうすれば指示としては一文で済みます。指示（として記述されたキーワードや文章）が、適切にサブリソースへと導けるように書いてあれば、指示を読むだけで確実にサブリソースにアクセスできます。
サブリソースの例は（きりがないですが少し挙げると）以下のとおりです。
- 何らかの資料
- テキストで書いたチェックリスト
- PDF で書かれた文書
- Web 上のリファレンス
- 何らかのツール
- 常用しているチャットツール
- フリーソフト
- Web アプリ
- 何らかの場所
- マシン室
- 倉庫
- 何らかの人
- 上司
- 先輩・後輩
- お客様 A 社の B さん
- ……
かんたんな始め方
ライフプログラミングのかんたんな始め方について取り上げます。足りない事項も多いですが、イメージを掴んでいただくことを目指します。
Step1. 道具を揃える
最低限必要なものはテキストエディタとテキストファイルのみです。
テキストファイルは以下の二つを準備します（以下個人的に好きな Markdown ファイルを前提にします）。
- メインリスト mainlist.md
- ネクストメインリスト nextmainlist.md
Step2. 運用の流れをつかむ
ライフプログラミングを用いて一日の生活を運用すると、以下のような流れになります。
- (1) 一日の生活または仕事の最初で、メインリスト mainlist.md を実装する
- 今日やらなくていいものはネクストメインリスト nextmainlist.md に実装する
- (2) 実装できたら、メインリストを実行する（一件ずつ対処していく）
- (3) メインリスト中の指示を全部実行できたら、今日はおしまい
ただし (1) と (2) は不可分であることが多く、たいていは メインリストを実装しつつ、実行しつつ といった行動になります。
その際、実行して対処し終えた指示は、対処済であることがわかるようにしておきます。次実行した時に、既に実行した指示を再度実行してしまわないためです。……というと難しく聞こえますが、要するにチェックリストで対処した項目にチェックを付けるのと同じです。
Step3. 運用する
Step2 のとおり運用しています。
つまり、一日の最初にメインリストを実装し、これを実行して、すべての指示を対処するまでを目指します。実行の途中で、また実装したくなる時もあるでしょう。「あ、この仕事も今日中にやらなきゃ」とわかればメインリストに追加実装しますし、「これは明日でいいか」とわかればメインリストからは削除して、ネクストメインリストに実装しておけば済みます。
Step4. 翌日になったら
翌日になったら、また Step3 のように運用していきます。
その際、ネクストメインリストを読むことを忘れないようにします。ここには昨日時点で「今日やらなくてもいいもの」と判断した指示が入っているはずなので、適宜メインリストに実装し直す必要があります。
まだまだ不完全
以上がライフプログラミングの流れになりますが、上記はあくまで最低限であり、実用上はまだまだ足りないことがあります。
例:
- 指示は自然言語で実装するというが、具体的にどのように実装するのか
- 繰り返し（たとえば1日1回）行う作業は、どうやって指示として実装すればいいのか
- 指示はどのファイルに、どんな書式で、どんなツールや開発環境で実装すればいいのか
- ……
以降では、ライフプログラミングにおいて重要な考え方、テクニック、プラクティスなどを取り上げていきます。
ライフプログラミングの基本フェーズ
はじめてライフプログラミングを行う際は、以下の基本フェーズに従って進めていくとわかりやすいです。
基本フェーズについて簡単にまとめます。しれっと見慣れない用語が登場しますが、詳しくは後述しますので、ここでは全体の流れやイメージをおおまかに掴むことを重視していただければ幸いです。
基本フェーズ
基本フェーズは事前準備、開発、運用の 3 フェーズに分かれます。
- 事前準備(Prepare)
- (1) 収集(Collect)
- (2) 分類(Categorize)
- 開発(Develop)
- (3) 設計(Design)
- (4) 実装(Implement)
- 運用(Operate)
- (5) 実行(Interpret)
事前準備では、実装（指示を書く）ために必要なインプットを集めます。これは一時間以上を書けて「やっていること」「やりたいこと」「気になること」などをひたすら洗い出し（収集）、続いて、洗い出したそれらを後で見返しやすいように振り分け（分類）します。
開発では、実際に実装を行います。いきなり指示を書き並べてもいいですが、統一性や効率など全体的な最適化を考えると、まずは大まかな書き方を決める（設計）ことが多いです。
運用では、開発した指示を読んで、一件ずつ対処していきます。ただし、途中で「あ、あれもやらなきゃいけないわ」 とひらめいて指示を追加するなど、実装に戻ることもあります。どちらかと言えば、実行と実装は不可分で、行ったり来たりしながら行うものと考えた方が良いでしょう。
(1) 収集
事前準備フェーズの一つ「収集」プロセスでは、実装（指示を書く）ために必要なインプットを集めます。
| 項目 | 内容 |
|---|---|
| 目的 | 指示の元となるネタを洗い出す |
| 成果物 | 指示の元となるネタを洗い出した何か |
| 実施頻度 | はじめてライフプログラミングを行う時 or 脳内がもやもやしてきた時 |
収集プロセスでは 1 時間以上をかけて、じっくりとひねり出すのが通例です。
フォーマットも内容もなんでも構いませんが、ブレストのように発想の数を重視し、また尊重することを心がけます。この時点で分類はしません。とにかく洗い出すことを優先します。
「何も思い浮かばない」という場合は、トリガーリスト（思い出しを支援するための質問集）を使うと便利です。末尾bに付録A.として載せましたので活用いただければ幸いです。
(2) 分類
事前準備フェーズの一つ「分類」プロセスでは、収集したネタを、以降のフェーズで利用しやすいように振り分けます。
| 項目 | 内容 |
|---|---|
| 目的 | 指示の元となるネタを（後で利用しやすいよう）整理する |
| 成果物 | 振り分けた内容を格納した何か |
| 実施頻度 | 収集プロセスを行った後 |
振り分ける先としては、とりあえず以下 3 つを用意して、括弧内に従って振り分けると良いでしょう。
- メインリスト（今日やること）
- ネクストメインリスト（明日以降やること）
- インボックス（それ以外）
ここでインボックスという言葉が出てきましたが、気になるネタをとりあえず貯めておく領域 くらいに捉えれば良いでしょう。
インボックスに貯めるネタの例:
- いつかやりたいこと
- 今すぐはやらなくてもいいが、いつかはやらないといけないこと
- やるかどうかは不確定だが、やるかもしれないこと
- その他気になること全般
逆にメインリストとネクストメインリストについては、**今日あるいは明日以降「やることが決まっている（やらなきゃいけない）ネタ」**を 入れましょう。
別に最悪インボックスだけでも構いませんが、後のフェーズでメインリストを実装することになるので、実装に使いそうなネタはこの分類プロセスの時に放り込んでおいた方が楽です。
(3) 設計
開発フェーズの「設計」プロセスでは、メインリストやネクストメインリストを実装する際の指針、ルール、フォーマット、他にも「指示をどこに書くか」「どんなツールを使って書くか」「どんな指示を書くか」といったことを定めます。
| 項目 | 内容 |
|---|---|
| 目的 | 実装を円滑に行うための下地を整える |
| 成果物 | 取り決めたルールやフォーマット、記入先ファイル、利用ツールなど |
| 実施頻度 | 適宜 |
つまりは すぐに実装に移れるよう諸々を整える 準備作業と言えます。
このプロセスは最悪無くてもよいですが、プログラミングでもいきなりコードを書く前に設計を行うように、ライフプログラミングでも設計をある程度は行っておいた方が無難です。
以下に、簡単な設計の例を挙げます。
メインリスト
基本:
- ファイル
- 指示は mainlist.md に書く
- 記入内容
- リーダブルな指示
- 記入方法
- 記入エリアは 1 日 1 回、大見出しでつくる
- 指示は一行に一つ、未対応セクションに書く
- 対応した指示は対応済セクションに移す
- 運用
- 実行する時は上から順番に読み、実行することを心がける（必須ではない）
- 今日中に未対応セクションを空にしなければならない
フォーマット:
# yyyy/mm/dd(今日の日付でつくる)
## 未対応
指示
指示
指示
...
## 対応済
指示
指示
指示
...
ネクストメインリスト
基本:
- ファイル
- ファイル名は nextmainlist.md
- 記入内容
- 翌日以降のメインリストを実装する際のネタ
- 記入方法・記入指針
- 書式は問わないが、極力一行に一つの指示で書いておく（コピペしやすい）
- メインリスト実装時によく参考にするものなので、参考にしやすいようにまとめる
フォーマット:
# 指示雑多 ★例1: 明日以降使う指示を書き並べておく
指示
指示
指示
# projectAの全体像 ★例2: 今取り組んでいるプロジェクトのタスク全体をまとめておく
- ――
- ――
- ――
- ……
- ――
- ……
# projectBの状況 ★3: 今取り組んでいるプロジェクトの状況を端的にメモしておく
- yyyy/mm/dd Aさん応答待ち
指示
※用語が色々登場しますが詳しくは後述します。
基本事項
- アドホックな指示
- 基本的にメインリストを実装するタイミングで実装する
- 日時や場所が固定された「予定」については、カレンダーに入れておく
- ルーチンな指示
- 各指示には必ず「実行頻度」を定める
- 各指示は「実行頻度」に従い、決められた頻度でのみ実装するよう制御する
実行頻度の記述
- 1日n回
- メインリスト中に当該指示を n 個書く
- n日に1回
-
@11日に1回 -
@71週間に1回 -
@301月に1回
-
- 毎週 XX 曜日
-
@sun毎週日曜日のみ -
@sun @fri毎週金曜日と日曜日のみ -
@weekday平日のみ
-
以下のルーチンな指示は必ずメインリストに実装する
- ネクストメインリストを眺めてメインリストに追記する @1
- 昨日のメインリストを眺めてメインリストに追記する @1
- 一週間前までのメインリストを眺めて反省を行い、来週やることを指示として最低 3 個書く @fri
- Twitter アカウント A の通知をチェックする @2
- メールアドレス A の受信箱をチェックする @1
- メールアドレス B の受信箱をチェックする @10
- 一週間先までのカレンダーを眺める @1
- インボックスに貯めたネタをネクストメインリストまたはメインリストに移す @10
- ……
(4) 実装
開発フェーズの「実装」プロセスでは、メインリストに指示を書きます。
| 項目 | 内容 |
|---|---|
| 目的 | 今日やることを洗い出す |
| 成果物 | メインリスト |
| 実施頻度 | 一日一回、なるべく早いタイミングで |
メインリストは朝一番、なるべく早いタイミングで実装します。
実装する際は以下のヒントを活用します。
- ネクストメインリスト
- 昨日以前に対処したメインリスト
(5) 運用
開発フェーズの「運用」プロセスでは、メインリストに実装した指示を読み、一つずつ対処していきます。
| 項目 | 内容 |
|---|---|
| 目的 | 今日やることをすべて消化する |
| 成果物 | 未対処の指示が 0 件となったメインリスト |
| 実施頻度 | 毎日 |
しかしながら実際は、ちょっと実行する → ちょっと修正する → 続きから実行する → また微修正する → ……といったように 実装と実行を行き来 します。また、ネクストメインリストやインボックスなど、他のリストを実装することもあります。
==== PART.2 メインリストとネクストメインリスト ====
PART.2 では、ライフプログラミングではメインリストとネクストメインリストの二種類を扱う。この二つについて詳しく取り上げる。
両者の役割を知る
メインリストは メイン関数 である。
- メインリストは直接実行（自分自身が読んで解釈）するもの
- メインリストは実行できるように実装する（わかりやすい指示を書く）必要がある
- メインリストにはその日一日に行うことを実装する、そのため一日に一回実装することになる
一方、ネクストメインリストは コードスニペット である。
- ネクストメインリストは直接実行しない
- ネクストメインリストは、メインリストから直接呼び出されることもない
- ネクストメインリストはあくまで メインリストを実装するための補助的なメモ、スニペット、テンプレート、リファレンス 等である
メインリストのフォーマット
フォーマットは人それぞれだが、本質はただのリスト（箇条書き）であるため、以下のようなフォーマットでよい。
- 指示1
- 指示2
- 指示3
- ...
あるいは先頭の文法さえ邪魔なのであれば、直接書いても良いだろう。
指示1
指示2
指示3
...
要するになんでもありである。
ただし、詳しくは後述するが、ライフプログラミングでは（指示の記述を省力化するために）専用のツールやスクリプトに頼るため、それらがパースできるようフォーマットを整える必要性が出てくることはあらかじめ断っておく。
ネクストメインリストのフォーマット
こちらについても自由である。要するにメインリストを実装しやすいよう、指示に関するメモ、スニペット、テンプレートなどを適宜貯めておけば良いだけである。
ただし、使いやすさのために メインリストと同じファイルに、同じフォーマットで書いてしまう（ミックスメインリスト） こともある。以下に例を示す。
# 2019/01/22
- 指示
- 指示
- ...
# 2019/01/23
- 指示
- 指示
- ...
# 2019/01/24
- 指示
- 指示
- ...
今日が 2019/01/22 だとすると、メインリストは 2019/01/22 のセクションが相当する。ここ以外の領域はすべてネクストメインリストである。たとえば翌日になれば、2019/01/23 のセクションがメインリストになる。このフォーマットは 未来のメインリストをあらかじめ実装している 書き方とも言える。
もちろん「この指示は明後日にやろう」「これは 10 日くらいでいいや、えっと 10 日後は……」といった判断を手作業で行うのは面倒くさいから、適宜ツールなりスクリプトなりマクロなりで省力化することになる。
手で書くか、省力化するか
メインリストにせよ、ネクストメインリストにせよ、実装方法として「手作業で書く」と「ある程度自動化する」の 2 通りがある。
最初のうちは前者「手作業で書く」が良い。直感的でわかりやすいからだ。これはプログラミングで言えば、IDE に頼らず、自力ですべてのコードを手打ちで書くようなものである。
しかし、手作業だといちいちすべてを書くのが面倒くさくなってくる。たとえば後述する「ルーチンな指示（繰り返し実行する指示）」は、頻度が1日1回であれば、毎日実装しなければならない。仮にこのような指示が10個あったとすると、毎日10個分の指示を手で書くことになる。苦痛だ。この苦痛をいかにして省力化するか、を考えるのは当然だろう。
参考までに、この例で省力化について考えると、以下のような流れになるだろう。
- (1) 1日1回行う指示を事前にどこかにリストアップしておく
- (2) 1 をメインリストにコピペするスクリプトを書く
- (3) メインリストを実装する時、2 を実行する
また、(3) の判断は手作業なので、ここさえも省力化できる。cron などジョブスケジューラに仕込む等、の方法が考えられる。
==== PART.3 指示 ====
ライフプログラミングにおける「指示」とは、自然言語で書く「命令」であるが、具体的にどのように書けばいいかがいまいちわかりづらい。
そこで本パートでは、指示についての詳細を扱うことで知識やイメージの強化を図る。
二種類の指示
指示は二種類に大別できる。
- アドホックな指示 …… 二度以上実行しないであろう、 その場限りの 指示
- ルーチンな指示 …… 繰り返し実行する 指示（n日に1回、1日にn回、毎週月木に1回ずつetc）
特に後者、ルーチンな指示は重要なので、ぜひ押さえたい。
アドホックな指示
その場限りの指示。
実装するタイミングは様々だが、大別すると 集中 と 散発 がある。
集中とは、どこかのタイミングで一気に実装すること。たとえば「朝一で今日やることを洗い出す」とか「～～について記事を書き上げたいから必要タスクを洗い出そう」といったこと。ライフプログラミングでは、洗い出した個々のタスクを、指示という形で、メインリストやネクストメインリストに配置することになる。
散発とは、思いつきや気付き、または割り込みなどによって実装の機会または意識が散発的に生じること。たとえばメールやチャットを見て「あ、これ対応しなきゃな」と思ったり、仕事中にふと「どっかで～～したいな」とひらめいたり、といったこと。ライフプログラミングでは、散発的に生じたそれらを、指示という形で文章化した上でリストに放り込んでおく。そうすれば失うことはない。
ルーチンな指示
繰り返し実行する指示。
いわゆるルーチンワークだとかルーチンタスクだとか日課だとか言われる類のもの。
ルーチンな指示は 繰り返し頻度 という設定を持つ。1日1回繰り返すなら「頻度 = 毎日」だし、平日のみ3日に1回繰り返すなら「頻度 = 毎日(ただし休日を除く)」といった設定になる。
当然ながら ルーチンな指示は適切な日に配置しなければならない。毎日実行する指示なら今日のメインリストに実装し、明日になってもまた実装し、明後日になっても実装し……と1日1回実装しなければならない。
ルーチンな指示の実装は面倒くさいので、いかに自動化できるかが重要 である。
指示の書き方
指示は自然言語で書くが、書き方にもコツがある。
一言で言えばリーダブルコードならぬ リーダブルインストラクション(Readable Instruction/リーダブルな指示) 。いつ、どの時点の自分が読んでもわかるような、読みやすくわかりやすい指示を心がける。
以下、コツを個別にいくつか取り上げていく。
一行に一つの指示を書く
指示は 一行の一つの指示を書いた箇条書き の形式で書き並べるのが良い。
中には「付箋を配置する」「カードを配置する」「ファイルで配置する」といったアイデアもあるが、どれも操作コストが高い割に視認性に難がある。
単純な「一行一指示の箇条書き」であれば、指示の書き方を工夫すれば十分見やすいし、テキストエディタでも編集しやすく、また行単位での読み込みや加工もしやすい。
表現を具体的かつ指示的にする
指示は具体的に書く。他人の目を気にする必要はないが、 未来の自分が読んでも行動に移せる 程度にはヒントが欲しい。
たいていの場合、指示を指示的に（自らに命じるように）書くと、上手い具合に具体的になってくれる。未来の自分という部下がちゃんと行動できるように指示を与える、と言ってもいいかもしれない。
共通要素は接頭辞(Prefix)でくくる
指示は何十行、何百行と並ぶことも珍しくない。指示全体の視認性をいかにして確保するかは重要だが、接頭辞はこの役に立つ。
関連する指示には同じ接頭辞をつける。
インデントではないが、行の先頭を同じものにすれば見栄えはグンと整う。また、昇順・降順ソートを行えば一発で並び替えることもできる（ただし昇順降順で見やすい並びになるようなフォーマットを採用する必要はあるが）。
専用のツールを使う
ライフプログラミングにおける指示の実装は、実はただのテキストエディタ + テキストファイルだけだと厳しい。以下のような性質を満たすことが難しい（というか面倒くさい）からだ。
満たしたい性質:
- 各指示は「その指示を実施するべき日（のメインリスト）」にのみ表示される
- ルーチンな指示については、実行頻度ごとに実行できるよう何度も実装する（再配置）
これらの面倒を軽減するためには、これら作業を自動化する何らかの仕組みが必要である。
一般的にはタスク管理ツールを使う。タスク管理ツールではタスク（指示）一件に「実施日」と「繰り返し頻度」をもたせることによって、各タスクが適切な日と頻度でのみ表示されるよう制御してくれる。
しかしながら、タスク管理ツールはテキストエディタとは程遠い、リッチな GUI ツールであることが多く、ライフプログラミング用途としてはとても耐えられるものではない（Word でプログラミングするようなものである。もちろん耐えられるなら使ってもよい）。
ちなみに私は耐えられないので自作した。
Windows の秀丸エディタ用だが、他のエディタでも実装は可能だろう。テキストエディタのマクロ・スクリプトといった拡張機能で実装することになるかと思う。あるいは、エディタの機能だけで足りない、または足りても実装が面倒くさい部分については、別言語で書いたツールやスクリプトをエディタから呼び出す、といった連携を使う。
※腕に覚えがあるなら Web アプリの形で実装しても良いが、ライフプログラミングはプログラミングと同様、手に馴染んだテキストエディタでガシガシ編集できることが必要なので、よほど実力があるか、テキストエディタにさしてこだわりがない限りは、ローカルでテキストエディタを生かす方向性になると思う。
サブリソースに誘導する
ライフプログラミングにおける指示とは「一行分のキーワードや文章」である。当然ながら、多くの情報を詰め込むことはできない。
そんな時は、必要な情報を別のどこかに置いておき（サブリソース）、指示としては「～～を見ろ」というふうにサブリソースへのポインタを指す形にすると上手くいく。
==== PART.4 実行 ====
ライフプログラミングにおける実行とは、要するに「指示の書かれたリストを自分が読んで、一つずつ対処していく」ことであるが、私たちは人間であり、機械ほど正確ではない。読み方や対処の仕方にも工夫が必要である。
本パートでは、この実行に関する話題を扱う。
ランダムかシーケンシャルか
メインリストに実装された指示を「どの順番で実行するか」については二通りある。
- ランダムアクセス …… メインリストの中から対処したい指示を選び、対処する
- シーケンシャルアクセス …… メインリストの一番上の指示から順番に対処する
ランダムアクセスは、実装が楽だが、実行に時間がかかる。というのも、「次はどれをしようか」といった判断が生じるからである。特にメインリストが何十以上と長大になると、いちいち全体を読んだり大きな視線移動やスクロールが発生したりするため、インタプリタ（つまり私たち自身）の負担も軽視できなくなる。
一方、シーケンシャルアクセスは、実行は楽（上から機械的に対処していけばいい）だが、実装が大変である。シーケンシャルな実行で仕事や生活がまわるよう、入念に実装しなければならないからだ。
現実的には 両方とも取り入れたハイブリッド方式になる だろうが、シーケンシャルアクセスはぜひとも積極的に、少しずつでも実装していきたい。上から流れるように実行するだけで済む、という状態はとても心地よく、また効率的である。
対処し終えた指示の取扱い
プログラミングでは、書いたコードは（通常）一度に実行しきるが、ライフプログラミングではそうではない。
ライフプログラミングでは、n 行まで実行した → メインリストをちょっと手直し（実装の再開） → 再び実行する → 手直し → ……というふうに 実行と実装を繰り返す。もちろん、一度実行した部分（既に対処した指示）は再度実行しない。
ここで問題となるのが、どうやって「一度実行した部分（既に対処した指示）は再度実行しない」を実現するか、である。最も愚直な方法は、実行の度にメインリストをすべて読み、対処済の指示をスキップすることであるが、これは手間だ。仮にメインリストに指示が 30 個あり、既に 20 個を対処できていたとしても、次の実行ではまた 30 個分読まなくてはならない。
じゃあどうすればいいかというと、以下の方法がある。
- 対処済マークを付ける
- 対処済のリストに移す
- 削除する
小難しく書いているが、要するに 対処し終えた指示は対処した旨がわかるようにしておく だけだ。そうすればメインリストの実装（のうち実行しなくてはならない指示）はどんどん減っていき、最終的にはゼロになる（= 今日の作業はすべて完了）。
実行記録
指示を実行する際、その指示をいつ実行したのか、またいつ対処したのかを 記録（実装）するかどうか は一つの争点となる。
記録しない:
- o 実行するのが楽
- x 実行記録が残らないため、あとで振り返りできない
記録する:
- o 実行記録が残るので、あとで振り返りできる
- x 指示一つずつに記録作業が必要で、面倒くさい
どちらも一長一短であるが、まずは「記録しない」で良いだろう。
もし記録しないことで何か不都合が生まれたら、記録するやり方に変えれば良い。
記録方式
記録する場合、何を記録するかで記録方式が 2 通りに分かれる。
- 対処記録 …… 対処した指示に対処済の印を付ける
- 開始記録 …… いつ開始したか(開始時間)、いつ対処できたら(終了時間)の二つを記録する
対処記録は、TODO リストやチェックリストとしておなじみだが、記録データとしての価値は薄く、「そのような指示が存在していて」「それに対処した」という事実しかわからない。
一方、開始記録は、開始時間と終了時間を記録するのは面倒くさいが、何の指示にいつ着手し、どれくらいかかったのかがすべてわかる。集計すればライフログみたく自分の行動を可視化できる。
以下にフォーマットの例を示す。
対処記録:
- [X] 対処済の指示
- [X] 対処済の指示
- [ ] 指示
- [ ] 指示
開始記録
- 15:00 15:03 対処済の指示
- 15:03 15:11 対処済の指示
- 15:12 開始中の指示はこのような実装になる
- 指示
- 指示
インタプリタを鍛える
指示を実行するのは自分自身というインタプリタであり、人間である以上、当然ながら実行の精度や正確性にはムラが生じる。
このムラが大きすぎるとライフプログラミングは破綻するため、インタプリタの癖や傾向はよくよく把握していき、必要なら運用方法の改善や強化も行っていく必要がある。いくつかポイントを雑多に取り上げる。
頭で覚えず、指示に残す
ライフプログラミングでは メインリストやネクストメインリストさえ見ればいい という状態の実現を目指す。そもそも頭の中だけで各種作業や予定やタスクを管理することが無茶であるから、リストという形で外に出し、これを使って上手いこと回るようなシステムを考えるのである。
これは言い方を変えれば、 「リストに書いてある指示に従いさえすれば生活がまわる」ように ライフプログラミングを行うとも言え、もっと言えばそのような指示を書いておけ、とも言える。
プログラミングの世界では、厳密に命令を書かねば意図した動作にはならないが、ライフプログラミングも同様に、「どの時点の自分が読んでもちゃんと生活が回るような指示」を書かねばならない。
「どんな指示を残しておけば、未来の自分は確実に対処できるか」
この点を常に意識し、実装していく必要がある。もちろん、一朝一夕に身につくものではなく、日々のライフプログラミング運用で少しずつ要領を覚えていく。
リスト駆動生活をおぼえる
「メインリストやネクストメインリストさえ見ればいい」という状態を実現できたとしても、これらを見なければ意味がない。それも一日一回だけ見るのではなく、何度も高頻度で見る必要がある。そうしないと、一部の（特に打ち合わせなど時間を指定された）指示を読み逃してしまう恐れがあるからだ。
理想としては、以下のような生活になる。
- 朝起きる
- メインリストを実行する（指示を一つずつ対処していく）
- メインリストの追加実装を行う（指示の書き換え）
- メインリストを続きから実行する
- メインリストの追加実装を行う
- ……
- メインリストを実行し終える（すべての指示を対処できた）
- 今日はおしまい
常に手帳やらメールやらタイムラインやらを見ながら仕事する人がいると思うが、そのリスト版みたいなものである。これを私は リスト駆動生活 と呼んでいる。
リスト駆動が身につくと、生活はグンと楽になる。いつ、何をやればいいかは全部リストが教えてくれるし、新たな「やること」が発生すれば、リストに突っ込んでおけばいいからだ。
指示はルーチンにする
仕事にせよ、生活にせよ、指示の大半は「ルーチンな指示」として扱うことができる。
いくつか例を見てみよう。
- 例1: 繰り返し実行している作業
これは繰り返し頻度を設定してルーチンな指示にすればよい。たとえば「あまり使わない Twitter アカウント A」を 3 日に1回くらいチェックしているのであれば、「Twitter アカウント A にログインして通知を見る」という指示を「頻度 = 3日に1回」で設定すればよい。
※頻度の設定とは、設定した頻度でのみ当該指示がメインリスト中に登場することを意味する。手作業で実装する場合は「3日に1回だけ実装しよう」と自分で判断して手で書くことになるが、ツールなりマクロなり何なりで自動化すればこの手間は省ける。
- 例2: いつかやりたいと思っていること
これもやはり繰り返し頻度を設定してルーチンな指示にする。指示内容としては、たとえば「やりたいこと "～～" について何かしてみないか？」と書く。頻度は、ケースバイケースだが、ここでは適当で、5日に1回にしておこう。
そうすると、この指示は5日に1回のタイミングで、メインリスト中に登場することになる。実行している時に目を通すことになる。
これは 5日に1回、～～について検討する機会を得たことに等しい。
注目してほしいのは「5日に1回だけ、～～について検討するんだ」などと頭で意識しているわけではない、ということだ。何も意識しなくてもいい。ただ日々ライフプログラミングをまわすだけで自然と気付ける。 システムが気づかせてくれる。
スモールスタートする
いきなりすべての仕事や私生活をライフプログラミングしようとしても破綻する。まずは一部だけライフプログラミングしてみて、少しずつ慣れていくことをおすすめする。
スモールスタートで取り扱うネタの例:
- 私生活の掃除
- メール、チャット、SNS、その他各種アカウントのチェック
- PC 内の整理（ファイル、ブックマーク、インストール済アプリなど）
集中的に実装する
ライフプログラミングには実装という「指示を書き並べる」フェーズと、実行という「書き並べた指示を消化していく」フェーズがある。
通常は実行の途中で適宜実装もはさむことになる。「あ、これも必要だわ」と考えて指示を書き足したり、「これは明日でいいか」と指示をネクストメインリストに移したりするだろう。
しかしながら、これは そもそも指示がある程度リストに実装されていることを前提としている。特にはじめてライフプログラミングを行う場合は、当然ながら指示そのものがまったく実装されない。
じゃあどうすればいいかというと、一時間以上かけて、まずは指示（あるいはその元になる思いつきやメモ）を洗い出す のである。アイデアを洗い出す時、まずはブレストを行った後に整理分類を進めていくと思うが、それと同じことだ。あるいはプログラミングでも、いきなり実装することはせずに、まずは全体像を洗い出したり、設計を進めていったりするはずだ。
このあたりの流れについては、PART.1 の基本フェーズの項でも説明した。
==== PART.5 ライフプログラミングの具体例 ====
ライフプログラミングの具体例として、拙作の Tritask について取り上げる。
ライフプログラミングのやり方や進め方についてのイメージになれば幸いである。
Tritask をライフプログラミング用語で説明する
全般:
- ミックスメインリスト
- メインリストとネクストメインリストを同じファイルに書く
- 一行の一つの指示を書く
- 指示の記録は開始記録型
指示のフォーマット例:
-
4 2019/01/20 Sun 06:54 07:23 write life-programming- 2019/01/20、06:54 に開始し、07:23 に完了した指示
- 指示内容は「ライフプログラミングについて執筆する」
メインリストとネクストメインリストの区別について:
- メインリスト = 実行日が今日の指示から成る部分
- ネクストメインリスト = メインリスト以外の部分
- 昇順ソートを行うと「メインリスト」「ネクストメインリスト」「昨日以前のメインリスト」の順で並び替わる
ルーチンな指示の扱い方について:
- 行中に
rep:Nと書くと、N 日ごとに繰り返す指示になる -
rep:N付の指示を完了すると、自動的に N 日後の指示が複製される
2019/01/20 Sun 07:25 メールアドレスAのチェック rep:1
↓ 指示を完了させる
2019/01/20 Sun 07:25 07:39 メールアドレスAのチェック rep:1
↓ すると rep:1 が働き、次の実行日(1日後)で指示が複製される
2019/01/20 Sun 07:25 07:39 メールアドレスAのチェック rep:1
2019/01/21 Mon メールアドレスAのチェック rep:1 ★
Tritask の仕様と意図
ファイル
- 拡張子は .trita
- 理由
- エディタ側でファイルタイプ別の設定をつくるため
- Markdown や TXT など既存文法と衝突させないため
全体構造
- *.trita …… お使いのミックスメインリスト
- tritask.mac …… テキストエディタのマクロファイル
- 日付入力など面倒くさい操作を自動化する
- helper.py …… マクロだけでは実現できない操作を実現する外部スクリプト
フォーマット
(SORTMARK) (DATETIME) (DOW) (START-TIME) (END-TIME) (DESCRIPTION-OF-INSTRUCTION)- 理由
- 昇順ソートするだけ上手いこと並べたいから
- いつ実施し、いつ対応したのかをすべて記録したいから
- 入力
- SORTMARK は外部スクリプト helper.py が付ける
- DATETIME, DOW(曜日), START/END TIME はいちいち手入力せず、自動で一発で入力する
- DESCRIPTION OF INSTRUCTION(指示) はフリーフォーマット
- 表示順をコントロールしたければ、指示の接頭辞を工夫する
詳しくは下記を。
運用例をいくつか
例1: 新しく Slack チーム A に Join したので、1日1回は確認したい
2019/01/20 Sun Slack-A にログインしてチェックする rep:1
例2: Slack チーム A の確認だけど、休日はやらなくていいや
2019/01/20 Sun Slack-A にログインしてチェックする rep:1 skip:休
例3: Slack チーム A の確認だけど、今日はだるいから明後日くらいでいいや
2019/01/20 Sun Slack-A にログインしてチェックする rep:1 skip:休
↓ Walk day 操作で +2 する
2019/01/22 Tue Slack-A にログインしてチェックする rep:1 skip:休
↓ ソート操作を行うと、上記指示はネクストメインリストのエリアに移る
2019/01/20 Sun メインリストの指示
2019/01/20 Sun メインリストの指示
2019/01/20 Sun メインリストの指示
...
2019/01/21 Mon ネクストメインリスト（明日の指示）
2019/01/21 Mon ネクストメインリスト（明日の指示）
...
2019/01/22 Tue ネクストメインリスト（明後日の指示）
2019/01/22 Tue Slack-A にログインしてチェックする rep:1 skip:休 ★ここに移る
ちなみに行の追加、複製から日付操作まで、面倒くさい操作は一発で行えるようにしてある（テキストエディタのマクロ機能でそれら操作を行うマクロをつくっている）。
==== 付録 ====
付録A. 収集プロセスを支援するためのトリガーリスト
以下を読み、思いついたネタや指示があれば、適宜書き溜める。
- [1] 朝にやること、昼にやること、夕方にやること、夜にやること、深夜や早朝にやることは何か。
- [2] 平日にやることは何か。休日にやることは何か。
- [3] 会社でやっていることは何か。
- [4] 衣食住、衣についてやっていることは何か。
- [5] 衣食住、食についてやっていることは何か。
- [6] 衣食住、住についてやっていることは何か。
- [7] 定期的に通っている場所はないか。
- [8] 定期的に買っている、補充しているものはないか。
- [9] 定期的に捨てているものはないか。
- [10] 定期的に会っている人はいないか。
- [11] 普段見ているテレビ番組、聞いているラジオ放送などはないか。
- [12] 普段読んでいる書籍やウェブサイトなどはないか。
- [13] 普段チェックしている SNS はないか。
- [14] パソコンを使っていて、いつも行っていることはないか。
- [15] 日頃から体調面で心がけていることはないか。
- [16] よく怒られることや尋ねられることはないか。
- [17] 自宅の間取りをイメージしてみよ。何かやり残しはないか。
- [18] 自宅から会社までの通勤経路をイメージしてみよ。何かやり残しはないか。
- [19] 少しずつ進めたいことはないか。
- [20] やりたい、あるいはやった方がいいが、放置していることはないか。
付録B. 筆者が利用しているルーチンな指示
筆者が実際に利用しているルーチンな指示（の一部）をまとめてみた。
平日：朝、出社するまでに行うこと:
- ひげ剃りと歯磨き @1
- 薬を飲む @1
- 交通状況を調べる @1
- ケータイにタスクを補充する @1
平日：出社後すみやかに行うこと:
- コミュニケーションツールを起動する @1
- 今日スケジュール確認とリマインダーセット @1
平日：会社で一日数回行うこと:
- メールチェック @1
- チャットチェック @1
- 連絡待ちリストの更新 @1
平日：退社前に行うこと:
- クリアデスクトップ @1
- 引き出しとロッカーを施錠する @1
- 傘を手元に持ってくる @1
- 個人テキストデータのバックアップ @1
- コミュニケーションツールを終了する @1
平日：会社で数日に一回行うこと:
- 社内通知を読む @2
- 技術サイトを読む @3
- グループスケジューラーの予定を転記する @2
平日：会社で週に一回行うこと
- 定例会議 @7
- 勉強会 @7
- 週報の作成および提出 @7
- 週一バックアップ @7
- ブックマーク整理 @7
- リモートサーバーのメールデータをローカルフォルダに @7
平日：会社で二週間以上に一回行うこと:
平日：夜、帰宅後に行うこと:
- 外出先メモの処理 @1
- メールチェック @n
- メールアドレスA @1
- メールアドレスB @2
- メールアドレスC @7
- LINE チェック @2
- Twitter の通知をチェックする @2
- 充電する @n
- スマホ @2
- ケータイ @3
- ポメラ @7
- 薬を飲む @1
- Web マンガを読む @n
休日：朝に行うこと:
- 洗濯 @7
- 食料と日用品の補充 @7
- 昼食 @1
休日：どこかで行うこと:
- 掃除 @n
- 掃除 ほこり 椅子 @7
- 掃除 ほこり コンセント周り @7
- 掃除 ほこり 本棚の中 @7
- 掃除 ほこり 本棚の周辺 @7
- 掃除 ほこり 机の上 @7
- 掃除 ほこり クローゼット床 @7
- 掃除 床 居間 机の下 @7
- 掃除 床 居間 机の下以外 @7
- ……
- 爪を切る @21
- 自転車の空気を入れる @21
- 財布の中身に一枚ずつ目を通す @30
- 書類受けを整理する @7
- 賞味期限チェック @30
- あまり使わないアカウントにログインする @45
付録C. 参考情報
関連する拙作情報についていくつか。
PART.5 で紹介したライフプログラミングの具体例(GitHub Organization アカウント)です。プログラム本体は tritask-sta で、仕様やフォーマットなどをまとめたのが tritask-spec、それから特設ウェブサイトが tritask-web です。
電子書籍です。いわゆる自己啓発書の類です。ライフプログラミングを、プログラミング関係無しに一般用語で解説した本です。「指示」ではなく「ルーチンタスク」という言葉を使っています。実は上記の付録 A. や付録 B. は、本書のコンテンツをほぼ丸々持ってきたものだったりします。
私がライフプログラミングを提唱する際に強く影響を受けたのが GTD ですが、この GTD について解説してみた記事です。
おわりに
生活をプログラミングする、というアイデア Life Programming(ライフプログラミング) を提唱してみました。
アイデアそのものは既存のライフハック、タスク管理、GTD といったものと大差ありませんが、これらはいまいちわかりづらく、またビジネス臭など不快なイメージもありました。せっかく有益なのにもったいないなと思い、また、もっとエンジニアさんやプログラマーさんに広まって、発展していったら私としても嬉しいと考え、今回このような記事を書いてみました。かなり長くなっちゃいましたが……(2万文字近くあります)。
何らかの参考や刺激になれば幸いです。