zangai_1
200524～200701
検討終了したもので、過程を残しておきたいもの
パートナータスク管理の定義が加速したときの思考回路
sta.icon*2ファミリータスク管理の方が自然な気がしてきた
夫婦限定ではなく、親子と子どもなども含む
シェアメイトや寮生活なども
何らかのゴールに向けて仕事するものではない
どちらかと言えばルーチンを誰がいつこなすか
整理すると
個人タスク管理
プロジェクトタスク管理
パートナータスク管理 ★これだけ「ルーチンを管理するもの」と狭い
直感的にはこう
個人タスク管理（1人）
プロジェクトタスク管理（n人）
パートナータスク管理（n人のうち、特に親しい者間でルーチンメインで管理するもの）
もともとは 3P にしたくて personal project partner とした
meceではない
meceにしたいよなぁ
観点Aが2つ、観点Bが3つあるから計6パターンある、みたいな
人数でやるなら
1, 2, 3+で3パターン
だがprojectには2人のパターンもあるからダメ
とするとやはり個人、プロジェクトの二つか？
sta.iconうん、そうだね
マニアがやってる個人タスク管理でもなければ
仕事でやってるプロジェクト管理でもない
これらとは別のジャンルなんですよ、怖くないよ、家事分担とかですでにやってるでしょ
↑ こういう切り口
改めて、パートナータスク管理とは
家族など親しい者間で主にルーチンを管理するタスク管理の形態
例：夫婦や親子による家事分担
親子をパートナーと呼ぶのはちょっと強引すぎる気がするsta.icon
だが3PでまとめるためにはP始まりが必要で、他に良い単語がない
プロジェクトタスク管理の一種だが、プロジェクトタスク管理の一種として説明するとハードルが高い
3Pマトリックスでは個人でもプロジェクトではない、別のジャンルであることを強調する
sta.iconの造語
既存は聞いたことない
夫婦でSlackを使うという話 ← ここから着想を得た
夫婦でタスクリストを共有するとか
二人で一つのタスクリストを使う
タスク管理の種類を「適用人数」と「仕事かプライベートか」で分類したもの 「タスク管理」という言葉がどれを指しているか、よくよく確認が必要
sta.icon プロジェクトが多い印象。マニアは個人も。パートナーは聞いたことない。
sta.icon 個人のプライベートとビジネスは分けない。どちらも個人タスク管理かなぁという印象。ただ会社用とプライベート用で分けるだけという話。
いや分けた方がいい？
チーム側と合わせたい
2Pになるか、4Pになるかだよなぁ
4Pか……もう一つ P から始まる単語、浮かばん
ビジネス-自分、は仕事だから個数が多い。あと機密情報も入ってる。
こっちは Pxxxx？
プライベート-自分、は仕事じゃないからゆるくていい。
こっちが Personal だよなぁ
違いがわからん
プロジェクトとパートナーは違うと思ってる
パートナーはただの仮説
夫婦とかでタスクリスト共有したり ← こういう感じになるのではと思ってる
家事分担 ← これはパートナータスク管理の一例にできるでしょ プロジェクトタスク管理を夫婦のプライベートでも使う ← これはさすがに無い気がする
プライベートは もっと簡単な手段になるはず プロジェクトタスク管理とは異なる切り口が必要になるはず
タスク管理知らないパートナーでも使えるシンプルさ、とか
sta.icon表現の仕方として見かけ上リスト（箇条書き）になることはありえる
ただどのタスクから実行しても良いことは保証されている
なら、ホワイトボックスとはその保証をいかに担保するかが鍵？
ランダムで中身を入れ替えるとか？
いや、アリだぞ
見るたびに並びが変わっている
ミキサーみたいに「利用者が中身を見ている間」にも動くとか？
要するに並びを意識させない制約を与えてしまう
……ランダムとミキサーくらいしか思いつかん
空間的配置、もありうるだろう
ブラックボックスみたく中身は見えないが、ステートフルってのもあるだろう
いやこれはステートフルブラックボックス
ステートフルブラックボックス ★これは？
ホワイトボックスの議論とは関係ないです
周辺概念やら周辺要素やら
あとはやる気からモチベとか意志とかそのへんの全体像を辿れる感じ エコシステム？
もう少しシンプルに登場人物
人
ツール
環境
登場人物
人
Environment 環境
Tool
Place
……
Background
Ability
Context
……
Motivation
意欲
意識
意志
……
Resouces
Time
Money
HP 体力
MP 注意資源
Tasks(観測されたタスク)
Things
観測できる事柄（観測されていないタスク）
観測できない事柄
システム
Tasks(管理されたタスク)
事柄の公理
まとめ
sta.icon*3たぶんこれでいける
事柄=観測されていないタスクは、そもそも論点違う
事柄プールから対象と行動を繋ぐ(観測する)、という構造になっている
事柄=観測されていないタスクか
no
事柄を "やること" と解釈できるかどうかは、事柄が性質Aを備えているかどうかによる
Aを持つ事柄がタスク候補（観測されていないタスク）
Aを持たない事柄はタスク候補ではない
例：りんご
りんごという事柄はタスク候補ではない
ここに性質Aとして「食べる」を付与する
そうしたらタスク候補になる
たとえば「りんごを食べる」という「やること」にできる
性質Aとは？
sta.icon哲学になってきたが……
事柄=観測されていないタスク、の方が楽ではある
直感には反するが
哲学は直感なんていくらでも裏切るものだが
タスクには対象と行動がある
どのレイヤーでどちらがどの程度明らかになっているべきか
「対象Xに行動Aを適用する」という正解は存在する
それを正確に表現できているとは限らない
表現しても通じるとは限らない
しかし正解を判定する方法はある
判定できないこともある
例；よくわからんけどこれはおわりでいいや
sta.iconこうかな
layer0: ここでは正解が規定されていない
対象や行動という事柄は存在する
XにAを適用する、という関係を繋ぐことこそが観測！ だとしたらlayer0は「プール」とでも言える
対象と行動のプール
ここから両者を選んで結びつけることが観測
何と何を結びつけるかは人それぞれ
プールの大きさや内容物も人それぞれ
layer1: ここで正解が規定される
layer2: ここでは正解にどこまで近づけるか（言語化するか）（管理するか）
事柄とは
事物。概念。表象。記憶。感情。
管理対象はポジティブかネガティブか
やりたいことを管理する → ポジティブ
やりたくないことを管理する → ネガティブ
sta.icon分けようとしていたが早速「実際は両刀遣いでは」疑惑が出てきた
比率で整理した方がいいかも
時間配分？
「やりたさ」の名前
wantability
wantable やりたさがある
またもや玄武さんからいただいた視点
「やること」の成分にやりたい部分、やりたくない部分などがあると思います。
たしかに
僕は「やりたさ」というコンテキストがある、と理解した
task
task
task
task
↑こんなのがあったとする
やりたさは人それぞれで、たとえばこうなる（ABCでAがやりたい、Bがまあやる、Cがやりたくない）
やりたいタスクの中にやりたくないもある
task(A)
task(C) ★これ
task(A)
task(A)
task(A)
task(C) ★これ
task(C) ★これ
task(A)
やりたくないタスクの中にやりたいがある
task(C)
task(C)
task(A) ★これ
task(C)
やりたさコンテキストを導入すると？
各タスクに対する「やりたさ」が見えるようになる
何らかの対処を講じやすくなる
やりたくないサブタスクを多く含むタスクを何とかしよう、と強く考えて行動する契機になるとか
ログを見て「やりたいタスクややりたくないタスク」がいつどのように実行されているかの傾向を知るとか
やりたい、やりたくないのネーミング
want, want not？
positive, negative？
sta.iconこっちだなぁ
やりたいの中にやりたいとやりたくない
P/N in P
やりたくないの中にやりたい
P/N in N
sta.iconマトリックスつくっておしまいな気がしてきた
p in P やりたいの中にやりたいが多い
めったにないので、多少 n があっても死守せよ
p in P の数で QoL は決まる？
n in P やりたいの中にやりたくないが多い
Pがどうしてもやりたいものなら、nが多くても仕方ない、いいからさっさと行動せい
というか行動できない場合、あなたにとってそのPはさほどやりたさが大きくないので、そのPは諦めていいです？
sta.iconこれ概念化したいなぁ
本当に重要なタスクであるならば、どんなハードルがあろうと前に進むしかない。諦めるという選択肢がそもそも無いのだ。 吉良野すた p in N やりたくないの中にやりたいが多い
pを分析して「どういうことがやりたいのか」を知るのが大事
そのNからは離れて、分析したpを多く含むPを探そう！
n in Nやりたくないの中にやりたくないが多い
最悪
今すぐ逃げよ
やりたさをタスク管理ツールで実現するとしたら
コンテキスト
値は3値かなぁ
やりたい、やりたくない、未入力
サブタスク扱えるツールでやるとしたら
上記の p in N とかを判定できる
サブタスク扱えないツールでやるとしたら
単に各タスクの「やりたさ」を可視化するだけ
p:n:nothing = 1:3:11 とか
n:1でネガティブ
p:1でポジティブ
np:nとnp:pにする？
入力はすぐに終えるようにしたい
ネガポジトラッキング
sta.icon仮説に仮説重ねてる感じで妄想感
いやでも僕の中ではリアルな想像だしシミュレーションなんだよ……
でも最低でも僕自身は取り入れて検証しないといけないよな
ちょっと整理
sta.iconタスク管理始める動機、で分類できそう！
オーバーウォント……やりたいことが多すぎる
オーバーマスト……やらなきゃいけないことが多すぎる
オーバーコスト……やっておきたいことが多すぎる
ここが微妙、そして少数
僕のように「家事をできるだけ効率化したい」系
オーバーレスト……だらけが多すぎる
これはつくりすぎか
三つくらいで収まる気がするんだがなー
そもそも「やることない」「持ってない」から持つ方向に至るのは、タスク管理でなくてもできる
むしろタスク管理以前のモチベ担保が大事
その手段としてタスク管理使うのはアリだが
やることのバランス
名前どうする
やりたい want やるべき should やらなければならない must やることができる can バランス balance
単純化して want should にする
wが多すぎる、sが多すぎる
wが多すぎる、sがなさすぎる
wが多すぎる、sはふつう
sが多すぎる、wが多すぎる duplicate
sが多すぎる、wがなさすぎる
sが多すぎる、wはふつう
wがなさすぎる、sが多すぎる duplicate
wがなさすぎる、sがなさすぎる タスク管理ではない
wがなさすぎる、sがふつう タスク管理ではない
sがなさすぎる、wが多すぎる duplicate
sがなさすぎる、wがなさすぎる duplicate
sがなさすぎる、wがふつう タスク管理ではない
やりたいことを管理する系
やるべきことを管理する系
やりたいこと・やるべきことを見つける系 ← タスク管理ではないかなぁ
sta.icon*2この結論から言うと「バランス」という言葉じゃなくて「多すぎる」的な言葉で名前つけるのが適切だろう
オーバー
キャパオーバー
やりたいこと飽和
want over
オーバーウォント
これ
「オーバーウォントなあなたにおすすめするタスク管理は……」なんて言い方ができる
しっくり来る
sta.iconたぶんこれでページつくる
オーバーマスト
バランスというより「バランスが崩れていること」的な概念にしたい
すると「崩れている人向けのタスク管理」「崩れてない人がさらにすすむためのタスク管理」という分類ができる
生活崩壊？
このままでは……
危機
クライシス
混乱 混沌 カオス
めちゃくちゃ 散らかる ぐちゃぐちゃ
崩壊のサイン
バランス崩壊
バランス崩壊を調べるチェックシート
玄武さんから説明いただいてなるほどと
タスク管理に惹かれるのは、どこかで「やること（やりたいこと、やるべきこと、やれることなど）」のバランスを崩すからだと思います。
崩れた人は、そのままじゃ立ち行かないので何かが必要
タスク管理が筆頭
逆に崩れてない人は、別にタスク管理なくてもいい
タスク管理でさらに楽することはできる
が、何とかなってるところを更に最適化するので「管理されている感」が出る
sta.icon直感だが「タスク管理する人≒崩れてる人」な気がする
むしろ崩れてないのにタスク管理するのは「なんでわざわざ」
僕は崩れてないけどタスク管理している
たぶんプログラマー脳だからと思う
今よりも少しでも効率化したい
家事にデイリーで45min、注意資源100かかっているとする
これをたとえば30min、注意資源50に減らせるだけでも価値がある
そのためにプロセスやらツールやら導入が必要ならするし、鍛錬が必要ならする
プログラマーはこんな感じ
少しでも楽するために新たな制約つくって、それ守らせるツールつくって、そのツール使う
自分を「新たに構築した（より効率的にこなせる）枠組み」に当てはめていく
こういうことを日常的にやっている
やりたさというコンテキスト
やりたさをかっこよくいうと「ウォンタビリティー」かしら？
一般化できる
重要の定義は主観で決まる
だからこそ自己啓発でも自分を大事にしろ、内省しろというわけで
タスク管理では重要という尺度はあまり使われない
だからこそ、あえて使う管理もアリなんだよなたぶん
マトリックスもちゃんと整理しておきたい
タスク名をハッシュ構造で集める
というかタスク名そのものをキーにする
code:python.py
taskhash = {}
「あるタスク名」を何人が使ったか、を記録する
タスクハッシュは誰でも見ることができる
sta.iconこういう「誰がどんなタスク名使っているか」には興味がある
タスク管理を一歩上に上げてくれる気がするんだよなぁ
プライバシーの問題
たとえば上司が佐藤さんだとしてクソ佐藤との会議なんてタスクは誰にも見せたくないw
タスク名に個人情報入れるケースがある
secretなurlやpasswordを、あとで対応するためにとりあえず貼り付けておくとか
恥ずかしい趣味を行うタスク、があるかもしれない
どうやってガードする？
無理そうだが……
sta.icon*2「タスク名にプライバシー情報を入れない」 ← こういうやり方がある気がする
あるいは「オープンなタスク名」という概念
最初から「他者に見られてもいい」前提でタスク管理する
そういうタスク名を最初から使う
sta.iconタスク名の付け方に規約を導入するって話になってきたかな？
従来
各自が好き勝手に書いている
人に見せられないプライベートな情報も入っている（ので共有できない）
これ
主なタスク名が存在しており、書き方もある程度確立されている（ので従うだけでいい）
自分でタスク名を書くよりも前に、既存のタスク名を探せ、的な
プライベートな情報は含まれない or 公開エリアからは隔離されている
あるいはタスクハッシュに入らないように隔離する、チェックする
gitignoreみたいに
調査対象
[/stask 2020/05/09(Sat) 09:51:51 end
/taskmanagement/やるおわに登場するキーワード一覧 2020/05/19 08:52:54 end
ツール使ってみながら一般化していく
タスクペディア
Habitica 個人タスク管理、特に習慣とゲーミフィケーション
ClickUp プロジェクトタスク管理で最新のやつ
Asana プロジェクトタスク管理で新しめで人気あるやつ
Redmine BTS GitHub扱ったしもういいか
Outlook オフィススイート系でタスク管理機能も持つもの
トラッキング検討時
sta.icon他にも既存で色々ある
カウントトラッキング
何個中何個できたか
「残量」トラッキング的な意味の方がよいかも
Restでレスト？
Remainingでリメイニング
チェックリスト
当たり前すぎて名前ついてない
「周辺環境やら周辺要素やら」のやつから洗い出せる気がする
タイム → 時間
ゲージ → 人（が持つ資源）
カウント → タスク
XXXX → YYYY
YYYYがわかれば、対応するXXXXとして新しいトラッキングを導ける気がする
なんでもかんでもトラッキングと名付けるわけにはいかない
タイムトラッキングレベルのものだけ扱うべき
個人的には「ゲージトラッキング」という概念を扱いたいがために、むりやりトラッキングという枠をつくった感ある
ここそのものが間違いの可能性も高い
1 実行日ベースのリスト
2 「時間」の導入 → タイムトラッキング
3 「ゲージ」の導入 → ゲージトラッキング（仮説）
……
こういう感じで
ゲーミフィケーションの一環で ゲージトラッキングの話
タスクを実行すると体力を消費する
ゼロになったらこれ以上タスク管理できない
↑ こういうのはどうかしら
この案は、いちいち注意資源やら体力やらの消費量見積もりを書くことで……みたいな
つまり 残り時間という尺度ではなく注意資源という尺度で見積もりしたい
sta.icon一筋縄にはいかないぞ……
注意資源は起きてるだけで消耗していくので、ツール側で引いてやらないといけない
計算式考えて実装しなきゃいけない
たぶん「注意資源に関する仕様や傾向」を体系化するのが先だ
特に「注意資源が切れた状態」を判定できる手段が必要
マネートラッキング
体力トラッキング
注意資源トラッキング
ゲージというメタファ
材料は3つ
タスク終了時に「どれだけ消費したか」を入力する、という操作sta.icon*4
あるいは「1分あたりの消費量」を入力する
そしたら実績時間から自動的にゲージ消費量が計算される sta.icon「ゲージベースの見積もり」を実現するにはあと何が足りない？
「指定ゲージ以下になったら」というトリガー
アクションとして「コンテナを表示する」「コンテナを非表示にする」「ラベルAのついたタスクを表示する」……
あるいは「<30でゲージ30以下になったらスキップされる」とか
ゲージが多い間はルーチンタスクには目を入れたくない
ルーチンタスクはゲージ少ない時にやればいい
ここの前提：知的生産メイン、ルーチンタスク≒家事であり注意資源死んでてもできる
timeは外に存在するもの、体力と注意資源は内に存在するもの
timeはコンピュータの処理で一瞬で出せる
体力と注意資源は出せない
per hourでtimeに帰着させる？
にしても体力や注意資源を語れる何らかの指標体系が必要だ。。
マネーも
アナログとデジタル
sta.iconどうまとめようか
少なくとも連続と離散、という意味ではない
つまり本来の意味からすると誤用
新しい基準持ち出した方が良さそう
なんとなく通じている誤用的ニュアンスを「Aの有無」だけで語れるようにする、というか
アナログ
ソフトウェアや機械を用いないもの？
例
紙、ノート、付箋
ペン
iPadでフリーハンドで書くとかどうする？
これはアナログ？デジタル？
デジタル機器をアナログに使う、というニュアンスだが
手書き
フリーハンド
インターフェースの中継数？
アナログは1
デジタルは2+
直接触れる=1?
特別な操作の有無？
アナログは誰でも使える（ない）
デジタルは誰もが使えるとは限らない
でもアナログも使い方学ばないとダメでしょ
ただペンの使い方をおおよそ誰でも学んでる誰でも使えるってだけで
そういう意味ではこう？
操作1.0（アナログ）
操作2.0（デジタル）
sta.iconいや、1.0から2.0になった要素それ自身がアナログ・デジタルの定義を分ける決定的な用語になるのだが
【形】人力で動かせる
mutableにちなんでhutable
人力で動かせない
imhutable
XXXが物質的
タスクが
操作が
タスクを表現するもの
データ
アナログ = タスクをデータとして扱わない
デジタル = タスクをデータとして扱うもの
sta.iconこれかなぁ？
データというよりはデジタルデータ……
電気がなくても使えるもの
sta.icon*3これだ
アナログツール
デジタルツール
↑ そして用語としてはこれだけに絞る
「アナログな」みたいな他の用法は想定しない
タスク管理の領分を超えている
これなら「電気や装置の確保」というデジタルツールの問題も端的に説明できる
デジタル
【形】コンピュータ上で利用する？
sta.icon一言で表せる気がするが
触れるのがアナログ？
Touchable
ちょっと独自路線すぎるかな
古いメモ
デジタルが好まれる
タスク管理は（網羅性や記録を重視すると）本質的に分量と操作が多くなるので、アナログだとしんどい
しかし目的を絞ってシンプルな運用を目指す場合は、アナログの表現力で済むこともある
アナログは親しみやすいので、マニア以外にも受けやすい 解釈議論
sta.icon分けた方が良い気がしてきた
観測されていないタスク
観測されたが言語化されていないタスク
頭の中では認識している（したつもりになっている）等
言語化されたタスク
他者とコミュニケートできる
自分の解釈どおりに伝わるとは限らないが
管理されたタスク
でも分けない方がシンプルにモデル化できる
「解釈」と「観測」も分ける？
sta.icon属性的なコンテナ、的な概念を……
pj1にcolumn1があるとする
column1にtask1があるとする
column1からtask1を消すとどうなるか
task1自体は消えない
ゆえにcolumn、もっというとpjはコンテナではない
task1のタグ系属性であるprojectsからpj1が消える
これは「projectというタグ系属性から見て、自分がひっついているタスクから離れる」という操作になる
これを直感的にやりやすくするため、自分（属性）が、自分がひっついているタスクを持っているという構造のビューを用意している どう名付けるのがいいだろう？
見た目はコンテナ、中身は属性
タグから見たタスク
タグが親で、タスクが子
逆コンテナ？
sta.icon*4なんかこう、それ！って感じのセンス良い一言があるはずなんだよ……
まとめ
メインは「これや」の部分
カウンターパラメーターやチェインパラメーターの亜種として、以下をつくりだしたいね、ということ
タスクAを開始したときに、条件condがtrueだったとき、Aのpを変更する
できました
先行条件
こっちも着目されない
sta.iconエンジニアな思考だが、条件を使って自動化したいなってのがある
条件を満たしたときだけ登場してくれるようにする、とか
ルーチンタスク仕込んで定期的に手動判断するのではなくて
例１：ウェブ漫画の更新チェック
before: @15で更新チェック（なければおしまい、あればそのまま読む、見積もりは読むときの時間で）
after: 更新されたとき、その日またはその翌日に自動でタスクが設定される
遅延評価じゃないが、実行可能になったときにタスクが存在し始める
ルーチンタスクAにスクリプトを紐づけておく
実行すると、スクリプトが走って処理を行う
処理の結果、trueならAを続けなさい
falseなら（続けられないので）skipします
高度すぎるな……
ウェブ漫画を例にするならこうなる
トップページの前回の更新状態を保存しておく
オートメーション時は、その部分を見に行って、保存していた値を違っているならtrueにする
trueの場合、今の値に保存し直す
こんなスクリプトをつくっておかないといけない
タスク管理関係ない
せいぜい「指定したスクリプトを起動する」「実行結果を受け取る」「実行結果次第で挙動を分岐させる」程度だろう
sta.icon*3これや
例２：負荷に応じたコントロール
if デイリータスクの消化数が20をこえたら
if 午後8時 and デイリータスクの消化数が15以下
こういうのを書けるようにしたら、もっと柔軟なコントロールができる
タスク管理してる最中の注意資源の消耗を減らしたい
ルーチンタスクを日々30個つくって回してる
でも疲れる
実際、知的生産とかにあまり集中できてない（20時にはバテバテ）
そりゃ一日何十回も同じリスト見て、「これはやる」「これはやらない」「これは明日でいいか」みたいな判断をなんどもなんどもやってるわけですから……
注意資源をもっと節約したら、いけるようになるんじゃないか？
行動
タスク管理が扱うのはここだけ
結果
ここはあまり着目されない
日記を書く延長でタスク管理できないか
まとめ
できることは「つまり」でまとめた
有益かどうかは知らない
つまり
日記という「よく目を通すホームポジション」に「タスクっぽいもの」を書いておくことをアシストする そうしたら、よく目を通すはずだから検討する機会は増えるよね、と
ノイズかなぁ？
〜〜したい
未来
今〜〜してる
開始中
〜〜してた
日記ツールをベースとしてタスク管理機能を自然にもたせたい
既存のタスク管理ツール使えない人でも使えるようにしたい
43 Foldersの「フォルダじゃなくて指定日の日記スペース」、「書類じゃなくて文章」バージョンになりそう？ たとえば
そうだ、買い物に行かねば
これは買い物タスクとして扱うことができる
範囲選択して、どこに飛ばすかを選択する
今日なら → そのまま（色強調されてるのであとで見返したらわかる）
明日なら → 明日の記入スペースに引用的に入る
終了したら打ち消し線引かれて、そばに終了日時が入る？
ポップアップで表示するとかでも良いが
ちょっと例を書く
これは買い物タスクとして扱うことができる範囲選択して、どこに飛ばすかを選択する 今日なら → そのまま（色強調されてるの あとで見返したらわかる） 明日なら → 明日の記入スペースに引用的に入る 終了したら打ち消し線引かれて、そばに終了日時が入る？ポップアップで 表示するとかでも良いが ちょっと例を書く
つまり日記的な長々文章に「タスク」というパーツを視覚的に差し込みたい＆簡単な操作を行えるようにしたい
日記を書くという従来のインターフェースを尊重しつつ
タスク化したい部分は「文章を範囲選択する」という自然な動作起点で行える
実行中属性
実行前属性＝普通の属性でもない
実行中に設定する属性
コメントとかかなぁ？
だがタスクは小さい＆使い捨て（ルーチンでない）が多いので活用しづらい
ルーチンタスクに「ここまでの所感を蓄積する」なんてのはありかもしれん
sta.iconこの記事のおかげでこの概念に辿り着いたので本当にありがたい
この部分
……次にルーチンタスクをやるときに何か書き足す（手順など）……こうすると次にルーチンタスクに取り組むときに、わずかばかり書き足したことの積み重ねができます。
「リーンスタートアップを読む @1 m:30」というルーチンをファーストタスクにしたとする 当面は毎朝、最初にこれを読むことになる
このときの所感を、このタスクに書き込んでおくことができる
1ヶ月経って読み終えたとすると、データはこうなっている
ログ
2020/05/27 6:06 06:36 リーンスタートアップを読む
2020/05/26 6:05 06:39 リーンスタートアップを読む
……
ここにどうやって「蓄積したコメント」を紐つけるか
2020/05/27 6:06 06:36 リーンスタートアップを読む comment:c1dYSEgjcV
c1dYSEgjcV.md というファイルにコメントを蓄積する
他のツールでも同じイメージ
つまりログ中のルーチンタスクAは、どの日のAであっても同じコメント領域を参照する
sta.iconこれってパラメーターじゃないよな
あえていうなら共有領域
[https://gyazo.com/df99f25c26fa9ea887ad622ac39633a0]
パラメーターであるならば、ログ中のルーチンタスク各々（○）の中にコメントデータがなきゃいけない
が、ログ残らないのはしんどい
ログは残す、途中で投下したコメントも残す
共有領域的な概念がやっぱり必要
実装は難しくない
単にコメント書ける領域つくって、タスクからポインタ張ればいい
つまり書く領域とタスクは別物で、単にポインタで通じてるだけ
緩いパラメーター？
タスクに組み込まれたパラメーターではなく、参照関係などでポイントされているだけのデータ
いや違う
実行中属性という概念はある
ただ実装方式として共有領域的な概念を使うこともある、というだけで
どっちがいい？
Summary of idletime、Soi SoIT soit ソイ ソイト
idle summary アイサマ？
語呂で言えばアイサマ
意味的にはsoit
ここではこっちが多くて堅苦しいので
前者のアイサマにしてみましょう
例
code:example of soit
8:00 8:10 タスクA
8:14 8:22 タスクB
8:22 8:30 C
8:36 9:00 D
この場合、アイドルタイムは以下
8:11～8:13
8:31～8:35
これを手動でログ化するのはしんどい
アイドルサマリーだと、機能として「今日のアイドルタイムはこれです」を一覧表示するイメージ
ここから「8:11～8:13はトイレだな」と記入してログ化できる
「今日のアイドルタイム一覧」としてデータを残すことができる
サジェスト
用語
サジェスト
google検索時のオートコンプリートはこれ
だが本質は「膨大なデータから候補を選んでいる」という点
amazonのおすすめ
オートコンプリート
単に何かを自動で補完すること
辞書データから機械的に補完するのもある
IMEみたいに利用頻度や品詞などから重み付けするのもある googleみたいに意味的な補完をするのもある
つまり
何かをすすめるリコメンド
入力中に補完するオートコンプリート
そのうち意味的な補完がサジェスト
タスク管理に応用するとしたら？
sta.iconまだうまく定まらん。何をリコメンドしてほしいか、からスタートしてみるか？
タスクをリコメンドする
これは湧く
ルーチンタスクを対象にして、「（今までの傾向から見て）このへんのルーチンタスクやったほうがよくないですか？」的な
トイレ掃除を@3にしていたとしても、実際@2でやっていた場合
@2でやりましょう的なリコメンドをしてくれたら嬉しい
……高度すぎるか
@3で配置してるトイレ掃除タスクを、実施するとき今日に引っ張ってきて開始する必要がある
「といれそうじ」 ← いきなりこんなタスクつくって実施してもログは溜まる
これを機械学習で「既に存在している@3のトイレ掃除ルーチンタスク」と同一視できる自信がない
「あなたが今日行うルーチンタスクはこれです」 ← これを提案する
ログが一年くらい溜まってたらいける気はするが
実行後に評価を入力させることで学習させる
暗記支援ソフトのAnkiもそのアプローチで（復習サイクルを）（実際の出来に応じて）微調整している
リコメンド……ではないな
タスクをサジェストする
sta.iconイメージ湧かない
ソーシャルなタスク管理プラットフォームつくったとする
たくさんのユーザーがタスク管理している
行動も（プライバシー損ねない程度に）記録
これらデータを用いればサジェストはできる
何を？
仮説にするにしてももうちょい
何をサジェストする
タスク名入力中のキーワード
次にやるタスク
daily
weekly
設定するコンテキスト
リコメンドとの違いは？
リコメンド
日課だけを管理する、にしたらサジェストしやすそう
既読スルー
タスクの既読スルー
直列タスクリストという前提において、今目に入っているタスクを（次はそのタスクを実行するべき順番なのに）しない、ということ？ TODOリストなど適当に並べているリストにおいて、頻繁にスルーされるということ V、S、Wではない
RFのどれか
Readできてない
Findできてない
どれでもない
ReadもFindもできているが、Workにはつながらない
タスクリストの既読スルーとは
sta.iconピンと来ないのこっちだ
何かを行うためにリストを使う
リスト中の一部タスクをスルーするというのはわかる
リストをまるごとスルーするってどういうこと？
「あー、リストに従うのだるいわ、テキトーにやっちゃお」こうかな
たとえば土曜日の掃除リストをつくっているが、このとおりにみながらやるのがしんどいから見るのやめて（既読スルー）、テキトーに掃除始める
ちょっと違うなぁ
僕の前提、こんな感じか
読むは「リスト」に対して行うもの
既読スルーとは、読む対象の一部をスルーすることであって、読む対象そのものをスルーすることではない
仮にリストAを既読スルーとしたら、それはAを包含した親リストBを読んでいるという文脈になる
つまりリストBを読んでいるときに、その中にあるサブリストAをスルーする
スキップとは違う
スキップは「明日でいいや」と判断が入っている
スルーはその判断さえもせずに放置する
読み飛ばす
見なかったことにする
集中とか生産性とかそういうやつ
支援概説であげた周辺
分解、集中、資料、操作、心理、想起、予定
忘迷怠からむのを弾くと
分解、集中、資料、操作、心理、想起、予定
集中という「深さや密度」に関するやつ
操作という「操作効率」に関するやつ
資料という「蓄積」に関するやつ
忘れず、迷わず、怠けずにできるようになった、その先は？
集中はある
他は？
できれば三つにまとめたい
持続
熱中
●中？：集中、熱中、夢中
集中：技術。高いパフォーマンスを出すこと。才能の世界でもあるが技術も使える。
熱中：興味。取り組む対象に興味を持ち続けること。
夢中：文脈。取り組み対象以外にはとらわれず、対象にフォーカスし続けられる状態であること。
対象に熱中し続けること、夢中でいられること、そして集中して取り組めること
熱中は動機。
夢中は方向。
集中は行動。
この順で言えば熱夢集
ねつむしゅう
あつゆめあつ
あつあつゆめ 熱集夢 集熱夢
ひらめかんので熱夢集でいいか
三文字でいいたい
集熱夢
熱集夢
熱夢集
集夢熱
夢集熱
熱夢集
sta.icon微妙だな……
三中でいい？
英語は？
集中 Concentration
熱中 Addict? Enthusiastic?
夢中 mad? absorption infactuation ……どれもニュアンス違う。盲目盲信ってわけじゃなくてですね……
あとBがあればABCにできて完璧だったw
漢字にしたいなあ
忘迷怠 ぼうめいたい、これくらいきれいにしたい
タスク管理でどのようにカバーできる？
取り組む対象の限定
熱中・夢中（限定する対象を熱中や夢中の対象のみで固める）
取り組み方のコントロール
集中
つまり「多数のタスクを漏らすことなく管理」ではなく「少ない対象をいかに高い密度でやりきるかの支援」
浅いタスク管理と深いタスク管理？
納期までに仕上げたい
これは忘だよなぁ
集中して取り組みたい
結局のところ仕上げるため、なんだよなぁ
過程を楽しむため、というのはあるが
それはもはやタスク管理ではなく「遊び方」の範疇だろう
終わらないリスト
別名
終われないリスト
終了 状態 存在しない エンドレス
エンドレスタスク管理？
エンドレス=終了という概念が存在しない、と決めてしまって良さそう
習慣系の管理は今後こっちのジャンルで発展していくはずだ
エンド=ゴール false
でも終わりがない習慣でも「30回継続する」のように区切り（Break）をつけることはできる
達成（Achievement）
区切り（Break）
ゴールの有無は解釈で決まる
例：ブロガーとして収入月30万
これ自体はゴール
毎日更新を3年達成という区切り
ブロガー=30万達成、は絶対的な定義ではない
定義は人それぞれ
区切りも達成も本質的に差はない
カウントを増減できるだけで終了はない（項目が減らない）
減点式カウンターもこれで説明できる