scrapbox-sta-taskmanagement

zangai_1

200524～200701

検討終了したもので、過程を残しておきたいもの

パートナータスク管理の定義が加速したときの思考回路
- :sta:ファミリータスク管理の方が自然な気がしてきた
  - 夫婦限定ではなく、親子と子どもなども含む
    - 後者は既に家事分担などで知られている
    - シェアメイトや寮生活なども
  - これらはプロジェクトタスク管理ではない
    - 何らかのゴールに向けて仕事するものではない
    - どちらかと言えばルーチンを誰がいつこなすか
  - 整理すると
    - 個人タスク管理
    - プロジェクトタスク管理
    - パートナータスク管理 ★これだけ「ルーチンを管理するもの」と狭い
  - 直感的にはこう
    - 個人タスク管理（1人）
    - プロジェクトタスク管理（n人）
      - パートナータスク管理（n人のうち、特に親しい者間でルーチンメインで管理するもの）
  - もともとは 3P にしたくて personal project partner とした
    - meceではない
    - meceにしたいよなぁ
      - 観点Aが2つ、観点Bが3つあるから計6パターンある、みたいな
    - 人数でやるなら
      - 1, 2, 3+で3パターン
      - だがprojectには2人のパターンもあるからダメ
      - とするとやはり個人、プロジェクトの二つか？
        
        :sta:うん、そうだね
    - 3Pマトリックスは初学者向けのわかりやすい説明用ってことで
      - マニアがやってる個人タスク管理でもなければ
      - 仕事でやってるプロジェクト管理でもない
      - これらとは別のジャンルなんですよ、怖くないよ、家事分担とかですでにやってるでしょ
      - ↑ こういう切り口
  - 改めて、パートナータスク管理とは
    - 家族など親しい者間で主にルーチンを管理するタスク管理の形態
    - 例：夫婦や親子による家事分担
      - 親子をパートナーと呼ぶのはちょっと強引すぎる気がする:sta:
      - だが3PでまとめるためにはP始まりが必要で、他に良い単語がない
    - プロジェクトタスク管理の一種だが、プロジェクトタスク管理の一種として説明するとハードルが高い
      - 3Pマトリックスでは個人でもプロジェクトではない、別のジャンルであることを強調する
3Pマトリックス検討初期時
- :sta:の造語
  - 既存は聞いたことない
  - 夫婦でSlackを使うという話 ← ここから着想を得た
  - 夫婦でタスクリストを共有するとか
    - 二人で一つのタスクリストを使う
- タスク管理の種類を「適用人数」と「仕事かプライベートか」で分類したもの
  - 「タスク管理」という言葉がどれを指しているか、よくよく確認が必要
    - :sta: プロジェクトが多い印象。マニアは個人も。パートナーは聞いたことない。
  - :sta: 個人のプライベートとビジネスは分けない。どちらも個人タスク管理かなぁという印象。ただ会社用とプライベート用で分けるだけという話。
    - いや分けた方がいい？
    - チーム側と合わせたい
    - 2Pになるか、4Pになるかだよなぁ
      - 4Pか……もう一つ P から始まる単語、浮かばん
      - ビジネス-自分、は仕事だから個数が多い。あと機密情報も入ってる。
        
        こっちは Pxxxx？
      - プライベート-自分、は仕事じゃないからゆるくていい。
        
        こっちが Personal だよなぁ
      - 違いがわからん
    - プロジェクトとパートナーは違うと思ってる
      - パートナーはただの仮説
        
        夫婦とかでタスクリスト共有したり ← こういう感じになるのではと思ってる
        
        家事分担 ← これはパートナータスク管理の一例にできるでしょ
        
        プロジェクトタスク管理を夫婦のプライベートでも使う ← これはさすがに無い気がする
        
        プライベートは ~~もっと簡単な手段になるはず~~ プロジェクトタスク管理とは異なる切り口が必要になるはず
        
        タスク管理知らないパートナーでも使えるシンプルさ、とか
        
        管理という堅苦しさを意識させないUI、とか？
セットどうする
- ブラックボックスどうする
- ホワイトボックスどうする
  - :sta:表現の仕方として見かけ上リスト（箇条書き）になることはありえる
    - ただどのタスクから実行しても良いことは保証されている
    - なら、ホワイトボックスとはその保証をいかに担保するかが鍵？
      - ランダムで中身を入れ替えるとか？
      - いや、アリだぞ
      - 見るたびに並びが変わっている
      - ミキサーみたいに「利用者が中身を見ている間」にも動くとか？
    - 要するに並びを意識させない制約を与えてしまう
      - ……ランダムとミキサーくらいしか思いつかん
    - 空間的配置、もありうるだろう
    - ブラックボックスみたく中身は見えないが、ステートフルってのもあるだろう
      - いやこれはステートフルブラックボックス
        
        ステートレスブラックボックスブラックボックスはこっち
        
        ステートフルブラックボックス ★これは？
      - ホワイトボックスの議論とは関係ないです
周辺概念やら周辺要素やら
- :sta:[タスク管理のピラミッド]
  - あとはやる気からモチベとか意志とかそのへんの全体像を辿れる感じ
- 環境
- 動機
- やる気
- 意識
- エコシステム？
- もう少しシンプルに登場人物
  - ATGV
  - 人
  - ツール
  - 環境
- 登場人物
  - 人
    - Environment 環境
      - Tool
      - Place
      - ……
    - Background
      - Ability
      - Context
      - ……
    - Motivation
      - 意欲
      - 意識
      - 意志
      - ……
    - Resouces
      - Time
      - Money
      - HP 体力
      - MP 注意資源
    - Tasks(観測されたタスク)
    - Things
      - 観測できる事柄（観測されていないタスク）
      - 観測できない事柄
  - システム
    - Tasks(管理されたタスク)
事柄の公理
- まとめ
  - :sta:たぶんこれでいける
  - 事柄=観測されていないタスクは、そもそも論点違う
  - 事柄プールから対象と行動を繋ぐ(観測する)、という構造になっている
- 事柄=観測されていないタスクか
  - no
  - 事柄を “やること” と解釈できるかどうかは、事柄が性質Aを備えているかどうかによる
  - Aを持つ事柄がタスク候補（観測されていないタスク）
  - Aを持たない事柄はタスク候補ではない
  - 例：りんご
    - りんごという事柄はタスク候補ではない
    - ここに性質Aとして「食べる」を付与する
    - そうしたらタスク候補になる
      - たとえば「りんごを食べる」という「やること」にできる
- 性質Aとは？
  - :sta:哲学になってきたが……
  - 事柄=観測されていないタスク、の方が楽ではある
    - 直感には反するが
    - 哲学は直感なんていくらでも裏切るものだが
  - タスクには対象と行動がある
  - どのレイヤーでどちらがどの程度明らかになっているべきか
    - 「対象Xに行動Aを適用する」という正解は存在する
    - それを正確に表現できているとは限らない
    - 表現しても通じるとは限らない
    - しかし正解を判定する方法はある
    - 判定できないこともある
      - 例；よくわからんけどこれはおわりでいいや
    - :sta:こうかな
      - layer0: ここでは正解が規定されていない
        
        対象や行動という事柄は存在する
        
        XにAを適用する、という関係を繋ぐことこそが観測！
        
        だとしたらlayer0は「プール」とでも言える
        
        対象と行動のプール
        
        ここから両者を選んで結びつけることが観測
        
        何と何を結びつけるかは人それぞれ
        
        プールの大きさや内容物も人それぞれ
      - layer1: ここで正解が規定される
      - layer2: ここでは正解にどこまで近づけるか（言語化するか）（管理するか）
- 事柄とは
  - 事物。概念。表象。記憶。感情。
管理対象はポジティブかネガティブか
- /taskmanagement/ライフプログラミング
  - やりたいことを管理する → ポジティブ
    - 玄武さん
  - やりたくないことを管理する → ネガティブ
    - 吉良野すた
- :sta:分けようとしていたが早速「実際は両刀遣いでは」疑惑が出てきた
  - 比率で整理した方がいいかも
  - 時間配分？
「やりたさ」というコンテキスト
- 「やりたさ」の名前
  - wantability
  - wantable やりたさがある
- /taskmanagement/ライフプログラミング
- またもや玄武さんからいただいた視点
- 「やること」の成分にやりたい部分、やりたくない部分などがあると思います。
  - たしかに
- 僕は「やりたさ」というコンテキストがある、と理解した
- 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:こっちだなぁ
- やりたいの中にやりたいとやりたくない
  - P/N in P
- やりたくないの中にやりたい
  - P/N in N
- :sta:マトリックスつくっておしまいな気がしてきた
  - p in P やりたいの中にやりたいが多い
    - めったにないので、多少 n があっても死守せよ
    - p in P の数で QoL は決まる？
  - n in P やりたいの中にやりたくないが多い
    - Pがどうしてもやりたいものなら、nが多くても仕方ない、いいからさっさと行動せい
    - というか行動できない場合、あなたにとってそのPはさほどやりたさが大きくないので、そのPは諦めていいです？
      - :sta:これ概念化したいなぁ
      - 本当に重要なタスクであるならば、どんなハードルがあろうと前に進むしかない。諦めるという選択肢がそもそも無いのだ。 [吉良野すた](/scrapbox-sta-taskmanagement/%E5%90%89%E8%89%AF%E9%87%8E%E3%81%99%E3%81%9F.html)
      - たぶんスタンスの一つなんだろうが
  - p in N やりたくないの中にやりたいが多い
    - pを分析して「どういうことがやりたいのか」を知るのが大事
    - そのNからは離れて、分析したpを多く含むPを探そう！
  - n in Nやりたくないの中にやりたくないが多い
    - 最悪
    - 今すぐ逃げよ
- やりたさをタスク管理ツールで実現するとしたら
  - コンテキスト
  - 値は3値かなぁ
    - やりたい、やりたくない、未入力
  - サブタスク扱えるツールでやるとしたら
    - 上記の p in N とかを判定できる
  - サブタスク扱えないツールでやるとしたら
    - 単に各タスクの「やりたさ」を可視化するだけ
    - DWMYのレベルでやりたさの比率がわかる
      - p:n:nothing = 1:3:11 とか
    - Tritaskに入れるとしたら
      - n:1でネガティブ
      - p:1でポジティブ
      - np:nとnp:pにする？
      - 入力はすぐに終えるようにしたい
- トラッキングもできる気がする
  - ネガポジトラッキング
  - :sta:仮説に仮説重ねてる感じで妄想感
    - いやでも僕の中ではリアルな想像だしシミュレーションなんだよ……
    - でも最低でも僕自身は取り入れて検証しないといけないよな
      - Tritaskにガンガンぶっこんでいくしかない
ちょっと整理
- オーバーヒートという言葉にくるめることにした
- :sta:タスク管理始める動機、で分類できそう！
  - オーバーウォント……やりたいことが多すぎる
  - オーバーマスト……やらなきゃいけないことが多すぎる
  - オーバーコスト……やっておきたいことが多すぎる
    - ここが微妙、そして少数
    - 僕のように「家事をできるだけ効率化したい」系
  - オーバーレスト……だらけが多すぎる
    - これはつくりすぎか
    - 三つくらいで収まる気がするんだがなー
    - そもそも「やることない」「持ってない」から持つ方向に至るのは、タスク管理でなくてもできる
    - むしろタスク管理以前のモチベ担保が大事
      - その手段としてタスク管理使うのはアリだが
やることのバランス
- 名前どうする
  - やりたい 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:この結論から言うと「バランス」という言葉じゃなくて「多すぎる」的な言葉で名前つけるのが適切だろう
      - オーバー
      - キャパオーバー
      - やりたいこと飽和
      - want over
      - オーバーウォント
        
        これ
        
        「オーバーウォントなあなたにおすすめするタスク管理は……」なんて言い方ができる
        
        しっくり来る
        
        :[sta:]たぶんこれでページつくる
      - オーバーマスト
  - MSEメソッドとも絡めそうだが
  - バランスというより「バランスが崩れていること」的な概念にしたい
    - すると「崩れている人向けのタスク管理」「崩れてない人がさらにすすむためのタスク管理」という分類ができる
  - 生活崩壊？
  - このままでは……
  - 危機
  - クライシス
  - 混乱混沌カオス
  - めちゃくちゃ散らかるぐちゃぐちゃ
  - 崩壊のサイン
  - バランス崩壊
  - バランス崩壊を調べるチェックシート
- /taskmanagement/ライフプログラミング
- 玄武さんから説明いただいてなるほどと
  - タスク管理に惹かれるのは、どこかで「やること（やりたいこと、やるべきこと、やれることなど）」のバランスを崩すからだと思います。
- 崩れた人は、そのままじゃ立ち行かないので何かが必要
  - タスク管理が筆頭
- 逆に崩れてない人は、別にタスク管理なくてもいい
  - タスク管理でさらに楽することはできる
  - が、何とかなってるところを更に最適化するので「管理されている感」が出る
- :sta:直感だが「タスク管理する人≒崩れてる人」な気がする
  - むしろ崩れてないのにタスク管理するのは「なんでわざわざ」
    - 僕は崩れてないけどタスク管理している
    - たぶんプログラマー脳だからと思う
      - 今よりも少しでも効率化したい
      - 家事にデイリーで45min、注意資源100かかっているとする
      - これをたとえば30min、注意資源50に減らせるだけでも価値がある
      - そのためにプロセスやらツールやら導入が必要ならするし、鍛錬が必要ならする
      - プログラマーはこんな感じ
        
        少しでも楽するために新たな制約つくって、それ守らせるツールつくって、そのツール使う
        
        自分を「新たに構築した（より効率的にこなせる）枠組み」に当てはめていく
        
        こういうことを日常的にやっている
やりたさというコンテキスト
- やりたさをかっこよくいうと「ウォンタビリティー」かしら？
  - 一般化できる
    - 重要の定義は主観で決まる
    - だからこそ自己啓発でも自分を大事にしろ、内省しろというわけで
    - タスク管理では重要という尺度はあまり使われない
    - だからこそ、あえて使う管理もアリなんだよなたぶん
      - 仮説だが
- マトリックスもちゃんと整理しておきたい
タスクハッシュ
- タスク名をハッシュ構造で集める
  - というかタスク名そのものをキーにする

taskhash = {}
taskhash['トイレ'] += 1

…
- …
  - 「あるタスク名」を何人が使ったか、を記録する
- タスクハッシュは誰でも見ることができる
- :sta:こういう「誰がどんなタスク名使っているか」には興味がある
  - タスク管理を一歩上に上げてくれる気がするんだよなぁ
- プライバシーの問題
  - たとえば上司が佐藤さんだとしてクソ佐藤との会議なんてタスクは誰にも見せたくないw
  - タスク名に個人情報入れるケースがある
    - secretなurlやpasswordを、あとで対応するためにとりあえず貼り付けておくとか
  - 恥ずかしい趣味を行うタスク、があるかもしれない
  - どうやってガードする？
    - 無理そうだが……
    - :sta:「タスク名にプライバシー情報を入れない」 ← こういうやり方がある気がする
      - あるいは「オープンなタスク名」という概念
        
        最初から「他者に見られてもいい」前提でタスク管理する
        
        そういうタスク名を最初から使う
        
        :sta:タスク名の付け方に規約を導入するって話になってきたかな？
        
        従来
        
        各自が好き勝手に書いている
        
        人に見せられないプライベートな情報も入っている（ので共有できない）
        
        これ
        
        主なタスク名が存在しており、書き方もある程度確立されている（ので従うだけでいい）
        
        自分でタスク名を書くよりも前に、既存のタスク名を探せ、的な
        
        プライベートな情報は含まれない or 公開エリアからは隔離されている
      - あるいはタスクハッシュに入らないように隔離する、チェックする
        
        gitignoreみたいに
調査対象
- ~~[/stask~~(https://scrapbox.io/stask) 2020/05/09(Sat) 09:51:51 end
- ~~タスク管理概説 - monolithic~~(https://stakiran.github.io/monolithic/task_management.html) 2020/05/13 08:01:07 end
- ~~タスク管理支援概説 - monolithic~~(https://stakiran.github.io/monolithic/task_management_support.html) 2020/05/15 07:16:13 end
- ~~タスク管理スタンス - monolithic~~(https://stakiran.github.io/monolithic/task_management_stance.html) 2020/05/16 08:35:54 end
- ~~ライフハック-タスク管理カテゴリーの記事一覧 - ガラパゴスタ~~(https://www.galapagosta.com/archive/category/%E3%83%A9%E3%82%A4%E3%83%95%E3%83%8F%E3%83%83%E3%82%AF-%E3%82%BF%E3%82%B9%E3%82%AF%E7%AE%A1%E7%90%86) 2020/05/17 09:57:35 end
- ~~/taskmanagement/やるおわに登場するキーワード一覧~~ 2020/05/19 08:52:54 end
- ~~タスクシュートの記事一覧 - jMatsuzaki~~(https://jmatsuzaki.com/archives/category/lifestyle/taskchute)
- ~~タスク・スケジュール管理の記事一覧 - jMatsuzaki~~(https://jmatsuzaki.com/archives/category/lifestyle/task-management) 22020/05/20(Wed) 16:47:04
- ~~【2020年度版】タスク管理ツール全まとめ│タスク管理大全~~(https://task-management-compilation.com/toollist/) カオスマップきりないので取捨選択完了 2020/05/26(Tue) 12:11:58
- ~~ひばち│タスク管理大全~~(https://task-management-compilation.com/author/hibachi/) 連続更新が5末で終わり落ち着いた 2020/06/13 09:52:21
- ~~タスク管理概論│タスク管理大全~~(https://task-management-compilation.com/overview/) 2020/06/13 10:04:47 更新されたらまた覗こう
- /taskmanagement
- ツール使ってみながら一般化していく
  - ~~タスクペディア~~
  - ~~Habitica~~ 個人タスク管理、特に習慣とゲーミフィケーション
  - ~~ClickUp~~ プロジェクトタスク管理で最新のやつ
  - ~~Asana~~ プロジェクトタスク管理で新しめで人気あるやつ
  - ~~Toggl~~ タイムトラッキングツールの老舗
  - ~~Trello~~ ボードカラムの老舗
  - ~~GitHub Issues~~ BTS
  - ~~Redmine~~ BTS GitHub扱ったしもういいか
  - ~~Outlook~~ オフィススイート系でタスク管理機能も持つもの
トラッキング検討時
- :sta:他にも既存で色々ある
  - カウントトラッキング
    - 何個中何個できたか
    - 「残量」トラッキング的な意味の方がよいかも
      - Restでレスト？
      - Remainingでリメイニング
    - チェックリスト
    - 当たり前すぎて名前ついてない
  - 「周辺環境やら周辺要素やら」のやつから洗い出せる気がする
    - タイム → 時間
    - ゲージ → 人（が持つ資源）
    - カウント → タスク
    - XXXX → YYYY
      - YYYYがわかれば、対応するXXXXとして新しいトラッキングを導ける気がする
- なんでもかんでもトラッキングと名付けるわけにはいかない
  - タイムトラッキングレベルのものだけ扱うべき
  - 個人的には「ゲージトラッキング」という概念を扱いたいがために、むりやりトラッキングという枠をつくった感ある
    - ここそのものが間違いの可能性も高い
- :sta:[タスク管理のパラダイムシフト]に絡む気がしてきた
  - 1 実行日ベースのリスト
  - 2 「時間」の導入 → タイムトラッキング
  - 3 「ゲージ」の導入 → ゲージトラッキング（仮説）
  - ……
  - こういう感じで
~~ゲーミフィケーションの一環で~~ ゲージトラッキングの話
- タスクを実行すると体力を消費する
- ゼロになったらこれ以上タスク管理できない
- ↑ こういうのはどうかしら
- TaskChute2はいちいち見積もりを書くことで見積もりの精度向上を狙っていた
- この案は、いちいち注意資源やら体力やらの消費量見積もりを書くことで……みたいな
- つまり 残り時間という尺度ではなく注意資源という尺度で見積もりしたい
- :sta:一筋縄にはいかないぞ……
  - 注意資源は起きてるだけで消耗していくので、ツール側で引いてやらないといけない
    - 計算式考えて実装しなきゃいけない
  - たぶん「注意資源に関する仕様や傾向」を体系化するのが先だ
    - 特に「注意資源が切れた状態」を判定できる手段が必要
- トラッキング
  - /sta/TMHM
    - タイムトラッキング
    - マネートラッキング
      - TogglのBilliable
    - 体力トラッキング
    - 注意資源トラッキング
  - ゲージというメタファ
    - 材料は3つ
      - タスク終了時に「どれだけ消費したか」を入力する、という操作:sta:
        
        あるいは「1分あたりの消費量」を入力する
        
        そしたら実績時間から自動的にゲージ消費量が計算される
        
        :sta:「ゲージベースの見積もり」を実現するにはあと何が足りない？
      - 「指定ゲージ以下になったら」というトリガー
      - アクションとして「コンテナを表示する」「コンテナを非表示にする」「ラベルAのついたタスクを表示する」……
        
        あるいは「<30でゲージ30以下になったらスキップされる」とか
    - /sta/ルーチンタスクにうんざりしてきたに対するクリティカルなアプローチになる気がした
      - ゲージが多い間はルーチンタスクには目を入れたくない
      - ルーチンタスクはゲージ少ない時にやればいい
      - ここの前提：知的生産メイン、ルーチンタスク≒家事であり注意資源死んでてもできる
  - timeは外に存在するもの、体力と注意資源は内に存在するもの
    - timeはコンピュータの処理で一瞬で出せる
    - 体力と注意資源は出せない
      - per hourでtimeに帰着させる？
        
        にしても体力や注意資源を語れる何らかの指標体系が必要だ。。
    - マネーも
      - TogglのBilliableでは $ per hour を事前定義することで、timeに帰着させている
アナログとデジタル
- :sta:どうまとめようか
  - アナログとデジタルで別々に？
  - アナログとデジタルで一気に比較する？
- 少なくとも連続と離散、という意味ではない
  - つまり本来の意味からすると誤用
    - アナログ - Wikipedia
    - 新しい基準持ち出した方が良さそう
    - なんとなく通じている誤用的ニュアンスを「Aの有無」だけで語れるようにする、というか
- アナログ
  - デジタルのレトロニム
  - ソフトウェアや機械を用いないもの？
  - 例
    - 紙、ノート、付箋
    - ペン
      - iPadでフリーハンドで書くとかどうする？
        
        これはアナログ？デジタル？
        
        デジタル機器をアナログに使う、というニュアンスだが
        
        手書き
        
        フリーハンド
        
        インターフェースの中継数？
        
        アナログは1
        
        デジタルは2+
        
        直接触れる=1?
        
        特別な操作の有無？
        
        アナログは誰でも使える（ない）
        
        デジタルは誰もが使えるとは限らない
        
        でもアナログも使い方学ばないとダメでしょ
        
        ただペンの使い方をおおよそ誰でも学んでる誰でも使えるってだけで
        
        そういう意味ではこう？
        
        操作1.0（アナログ）
        
        操作2.0（デジタル）
        
        :sta:いや、1.0から2.0になった要素それ自身がアナログ・デジタルの定義を分ける決定的な用語になるのだが
        
        【形】人力で動かせる
        
        mutableにちなんでhutable
        
        人力で動かせない
        
        imhutable
        
        XXXが物質的
        
        タスクが
        
        操作が
        
        タスクを表現するもの
        
        データ
        
        アナログ = タスクをデータとして扱わない
        
        デジタル = タスクをデータとして扱うもの
        
        :sta:これかなぁ？
        
        データというよりはデジタルデータ……
        
        電気がなくても使えるもの
        
        :sta:これだ
        
        アナログツール
        
        デジタルツール
        
        ↑ そして用語としてはこれだけに絞る
        
        「アナログな」みたいな他の用法は想定しない
        
        タスク管理の領分を超えている
        
        これなら「電気や装置の確保」というデジタルツールの問題も端的に説明できる
- デジタル
  - 【形】コンピュータ上で利用する？
- :sta:一言で表せる気がするが
  - 触れるのがアナログ？
    - Touchable
    - ちょっと独自路線すぎるかな
- 古いメモ
  - デジタルが好まれる
  - タスク管理は（網羅性や記録を重視すると）本質的に分量と操作が多くなるので、アナログだとしんどい
  - しかし目的を絞ってシンプルな運用を目指す場合は、アナログの表現力で済むこともある
  - アナログは親しみやすいので、マニア以外にも受けやすい
解釈議論
- :sta:分けた方が良い気がしてきた
  - 観測されていないタスク
  - 観測されたが言語化されていないタスク
    - 頭の中では認識している（したつもりになっている）等
  - 言語化されたタスク
    - 他者とコミュニケートできる
    - 自分の解釈どおりに伝わるとは限らないが
  - 管理されたタスク
- でも分けない方がシンプルにモデル化できる
- 「解釈」と「観測」も分ける？
:sta:属性的なコンテナ、的な概念を……
- 答え：ポインタコンテナ
- pj1にcolumn1があるとする
- column1にtask1があるとする
- column1からtask1を消すとどうなるか
  - task1自体は消えない
    - ゆえにcolumn、もっというとpjはコンテナではない
  - task1のタグ系属性であるprojectsからpj1が消える
- これは「projectというタグ系属性から見て、自分がひっついているタスクから離れる」という操作になる
  - これを直感的にやりやすくするため、自分（属性）が、自分がひっついているタスクを持っているという構造のビューを用意している
- どう名付けるのがいいだろう？
  - 見た目はコンテナ、中身は属性
  - タグから見たタスク
    - タグが親で、タスクが子
    - 逆コンテナ？
  - :sta:なんかこう、それ！って感じのセンス良い一言があるはずなんだよ……
ABCモデル - タスク管理のScrapbox
- まとめ
  - メインは「これや」の部分
  - カウンターパラメーターやチェインパラメーターの亜種として、以下をつくりだしたいね、ということ
  - タスクAを開始したときに、条件condがtrueだったとき、Aのpを変更する
    - できました
    - コンディショナルパラメーター
- 先行条件
  - こっちも着目されない
  - コンテキストで一部カバーしている
  - :sta:エンジニアな思考だが、条件を使って自動化したいなってのがある
    - 条件を満たしたときだけ登場してくれるようにする、とか
      - ルーチンタスク仕込んで定期的に手動判断するのではなくて
      - 例１：ウェブ漫画の更新チェック
        
        before: @15で更新チェック（なければおしまい、あればそのまま読む、見積もりは読むときの時間で）
        
        after: 更新されたとき、その日またはその翌日に自動でタスクが設定される
        
        遅延評価じゃないが、実行可能になったときにタスクが存在し始める
        
        条件付きタスクのオートメーション
        
        ルーチンタスクAにスクリプトを紐づけておく
        
        実行すると、スクリプトが走って処理を行う
        
        処理の結果、trueならAを続けなさい
        
        falseなら（続けられないので）skipします
        
        高度すぎるな……
        
        ウェブ漫画を例にするならこうなる
        
        トップページの前回の更新状態を保存しておく
        
        オートメーション時は、その部分を見に行って、保存していた値を違っているならtrueにする
        
        trueの場合、今の値に保存し直す
        
        こんなスクリプトをつくっておかないといけない
        
        タスク管理関係ない
        
        せいぜい「指定したスクリプトを起動する」「実行結果を受け取る」「実行結果次第で挙動を分岐させる」程度だろう
        
        :sta:これや
      - 例２：負荷に応じたコントロール
        
        if デイリータスクの消化数が20をこえたら
        
        if 午後8時 and デイリータスクの消化数が15以下
        
        こういうのを書けるようにしたら、もっと柔軟なコントロールができる
        
        Tritaskでもしたい
    - タスク管理してる最中の注意資源の消耗を減らしたい
      - ルーチンタスクを日々30個つくって回してる
      - 忘迷怠はなくなって良い、日々快適である
      - でも疲れる
      - 実際、知的生産とかにあまり集中できてない（20時にはバテバテ）
        
        そりゃ一日何十回も同じリスト見て、「これはやる」「これはやらない」「これは明日でいいか」みたいな判断をなんどもなんどもやってるわけですから……
      - 注意資源をもっと節約したら、いけるようになるんじゃないか？
    - ライフプログラミングのジャンルっすね
    - でもClickUpのAutomationみたいに、一部操作自動化する系はすでにある
- 行動
  - タスク管理が扱うのはここだけ
- 結果
  - ここはあまり着目されない
  - 評価とか実行後属性とかつくった
    - TaskChute2さんがここでも先駆者
日記を書く延長でタスク管理できないか
- まとめ
  - できることは「つまり」でまとめた
  - 有益かどうかは知らない
- つまり
  - 日記という「よく目を通すホームポジション」に「タスクっぽいもの」を書いておくことをアシストする
  - そうしたら、よく目を通すはずだから検討する機会は増えるよね、と
  - ノイズかなぁ？
- 〜〜したい
  - 未来
- 今〜〜してる
  - 開始中
- 〜〜してた
  - 報告的終了
- 日記ツールをベースとしてタスク管理機能を自然にもたせたい
- 既存のタスク管理ツール使えない人でも使えるようにしたい
- 43 Foldersの「フォルダじゃなくて指定日の日記スペース」、「書類じゃなくて文章」バージョンになりそう？
- たとえば
  - そうだ、買い物に行かねば
  - これは買い物タスクとして扱うことができる
  - 範囲選択して、どこに飛ばすかを選択する
    - 今日なら → そのまま（色強調されてるのであとで見返したらわかる）
    - 明日なら → 明日の記入スペースに引用的に入る
  - 終了したら打ち消し線引かれて、そばに終了日時が入る？
    - ポップアップで表示するとかでも良いが
  - ちょっと例を書く
    - これは買い物タスクとして扱うことができる範囲選択して、どこに飛ばすかを選択する今日なら → そのまま（色強調されてるの ~~あとで見返した~~らわかる）明日なら → 明日の記入スペースに~~引用的に入る~~ 終了したら打ち消し線引かれて、そばに終了日時が入る？~~ポップアップで~~ 表示するとかでも良いがちょっと例を書く
    - つまり日記的な長々文章に「タスク」というパーツを視覚的に差し込みたい＆簡単な操作を行えるようにしたい
    - 日記を書くという従来のインターフェースを尊重しつつ
    - タスク化したい部分は「文章を範囲選択する」という自然な動作起点で行える
実行中属性
- 実行前属性＝普通の属性でもない
- 実行後属性でもない
- 実行中に設定する属性
  - 実行中とはTaskChuteなどの「開始しているタスク」のこと
  - コメントとかかなぁ？
    - だがタスクは小さい＆使い捨て（ルーチンでない）が多いので活用しづらい
    - ルーチンタスクに「ここまでの所感を蓄積する」なんてのはありかもしれん
      - タスク管理ツールによくある繰り返し（ルーチン）機能を使わなくしたらルーチンタスクが少し楽しくなった｜玄武｜note
        
        :sta:この記事のおかげでこの概念に辿り着いたので本当にありがたい
        
        この部分
        
        ……次にルーチンタスクをやるときに何か書き足す（手順など）……こうすると次にルーチンタスクに取り組むときに、わずかばかり書き足したことの積み重ねができます。
      - 「リーンスタートアップを読む @1 m:30」というルーチンをファーストタスクにしたとする
      - 当面は毎朝、最初にこれを読むことになる
      - このときの所感を、このタスクに書き込んでおくことができる
      - 1ヶ月経って読み終えたとすると、データはこうなっている
        
        ログ
        
        2020/05/27 6:06 06:36 リーンスタートアップを読む
        
        2020/05/26 6:05 06:39 リーンスタートアップを読む
        
        ……
        
        ここにどうやって「蓄積したコメント」を紐つけるか
        
        Tritaskだとリファレンスポインタ
        
        2020/05/27 6:06 06:36 リーンスタートアップを読む comment:c1dYSEgjcV
        
        c1dYSEgjcV.md というファイルにコメントを蓄積する
        
        他のツールでも同じイメージ
        
        つまりログ中のルーチンタスクAは、どの日のAであっても同じコメント領域を参照する
        
        :sta:これってパラメーターじゃないよな
        
        あえていうなら共有領域
        
        <a href="https://gyazo.com/df99f25c26fa9ea887ad622ac39633a0" target="_blank" rel="noopener noreferrer">![](https://gyazo.com/df99f25c26fa9ea887ad622ac39633a0/raw)</a>
        
        パラメーターであるならば、ログ中のルーチンタスク各々（○）の中にコメントデータがなきゃいけない
        
        共有領域にしたくないなら習慣タスクみたいにカウンターにするしかなさそうだが
        
        が、ログ残らないのはしんどい
        
        ログは残す、途中で投下したコメントも残す
        
        共有領域的な概念がやっぱり必要
        
        実装は難しくない
        
        単にコメント書ける領域つくって、タスクからポインタ張ればいい
        
        ポインタは内容として張ってしまえばいい
        
        つまり書く領域とタスクは別物で、単にポインタで通じてるだけ
- 緩いパラメーター？
  - タスクに組み込まれたパラメーターではなく、参照関係などでポイントされているだけのデータ
  - いや違う
  - 実行中属性という概念はある
    - ただ実装方式として共有領域的な概念を使うこともある、というだけで
アイドルサマリー
- どっちがいい？
  - Summary of idletime、Soi SoIT soit ソイソイト
  - idle summary アイサマ？
  - 語呂で言えばアイサマ
  - 意味的にはsoit
    - ここではこっちが多くて堅苦しいので
  - 前者のアイサマにしてみましょう
- アイドルタイムを自動計測し要約表示する機能
- 例

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:まだうまく定まらん。何をリコメンドしてほしいか、からスタートしてみるか？
  - タスクをリコメンドする
    - これは湧く
    - ルーチンタスクを対象にして、「（今までの傾向から見て）このへんのルーチンタスクやったほうがよくないですか？」的な
      - トイレ掃除を@3にしていたとしても、実際@2でやっていた場合
      - @2でやりましょう的なリコメンドをしてくれたら嬉しい
      - ……高度すぎるか
        
        @3で配置してるトイレ掃除タスクを、実施するとき今日に引っ張ってきて開始する必要がある
        
        「といれそうじ」 ← いきなりこんなタスクつくって実施してもログは溜まる
        
        これを機械学習で「既に存在している@3のトイレ掃除ルーチンタスク」と同一視できる自信がない
    - 「あなたが今日行うルーチンタスクはこれです」 ← これを提案する
      - ログが一年くらい溜まってたらいける気はするが
    - 実行後属性が肝かも
      - 実行後に評価を入力させることで学習させる
      - 暗記支援ソフトのAnkiもそのアプローチで（復習サイクルを）（実際の出来に応じて）微調整している
      - リコメンド……ではないな
  - タスクをサジェストする
    - :sta:イメージ湧かない
    - フィルタリング時？検索時？
    - ソーシャルなタスク管理プラットフォームつくったとする
      - たくさんのユーザーがタスク管理している
      - 行動も（プライバシー損ねない程度に）記録
      - これらデータを用いればサジェストはできる
      - 何を？
- 仮説にするにしてももうちょい
- 何をサジェストする
  - タスク名入力中のキーワード
  - 次にやるタスク
    - ネクストタスク
    - daily
    - weekly
  - 設定するコンテキスト
- リコメンドとの違いは？
- リコメンド
  - 日課だけを管理する、にしたらサジェストしやすそう
既読スルー
- タスクリストの既読スルー - タスク管理のScrapbox
- タスクの既読スルー
  - 直列タスクリストという前提において、今目に入っているタスクを（次はそのタスクを実行するべき順番なのに）しない、ということ？
  - TODOリストなど適当に並べているリストにおいて、頻繁にスルーされるということ
  - VSRFWのうちどこのせいでスルーしているか
    - V、S、Wではない
    - RFのどれか
      - Readできてない
      - Findできてない
    - どれでもない
      - ReadもFindもできているが、Workにはつながらない
- タスクリストの既読スルーとは
  - :sta:ピンと来ないのこっちだ
  - 何かを行うためにリストを使う
    - リスト中の一部タスクをスルーするというのはわかる
    - リストをまるごとスルーするってどういうこと？
      - 「あー、リストに従うのだるいわ、テキトーにやっちゃお」こうかな
      - たとえば土曜日の掃除リストをつくっているが、このとおりにみながらやるのがしんどいから見るのやめて（既読スルー）、テキトーに掃除始める
      - ちょっと違うなぁ
      - 僕の前提、こんな感じか
        
        読むは「リスト」に対して行うもの
        
        既読スルーとは、読む対象の一部をスルーすることであって、読む対象そのものをスルーすることではない
        
        仮にリストAを既読スルーとしたら、それはAを包含した親リストBを読んでいるという文脈になる
        
        つまりリストBを読んでいるときに、その中にあるサブリストAをスルーする
- スルー
  - スキップとは違う
    - スキップは「明日でいいや」と判断が入っている
    - スルーはその判断さえもせずに放置する
      - 読み飛ばす
      - 見なかったことにする
忘迷怠の別ベクトルのやつ
- アンチルーチンのところでひらめいたのだが
- 集中とか生産性とかそういうやつ
- 支援概説であげた周辺
  - タスク管理支援概説 - monolithic
  - 分解、集中、資料、操作、心理、想起、予定
  - 忘迷怠からむのを弾くと
  - 分解、集中、資料、操作、心理、想起、予定
  - 集中という「深さや密度」に関するやつ
  - 操作という「操作効率」に関するやつ
  - 資料という「蓄積」に関するやつ
- 忘れず、迷わず、怠けずにできるようになった、その先は？
  - 集中はある
  - 他は？
  - できれば三つにまとめたい
  - 持続
  - 熱中
    - ●中？：集中、熱中、夢中
    - 集中：技術。高いパフォーマンスを出すこと。才能の世界でもあるが技術も使える。
    - 熱中：興味。取り組む対象に興味を持ち続けること。
    - 夢中：文脈。取り組み対象以外にはとらわれず、対象にフォーカスし続けられる状態であること。
    - 対象に熱中し続けること、夢中でいられること、そして集中して取り組めること
    - 熱中は動機。
    - 夢中は方向。
    - 集中は行動。
    - この順で言えば熱夢集
      - ねつむしゅう
      - あつゆめあつ
      - あつあつゆめ熱集夢集熱夢
    - ひらめかんので熱夢集でいいか
  - 三文字でいいたい
    - 集熱夢
    - 熱集夢
    - 熱夢集
    - 集夢熱
    - 夢集熱
    - 熱夢集
    - :sta:微妙だな……
    - 三中でいい？
    - 英語は？
      - 集中 Concentration
      - 熱中 Addict? Enthusiastic?
      - 夢中 mad? absorption infactuation ……どれもニュアンス違う。盲目盲信ってわけじゃなくてですね……
        
        あとBがあればABCにできて完璧だったw
      - 漢字にしたいなあ
        
        忘迷怠ぼうめいたい、これくらいきれいにしたい
  - タスク管理でどのようにカバーできる？
    - 取り組む対象の限定
      - アイビー・リー・メソッドは「5-6個だけあげる」と設定
      - 熱中・夢中（限定する対象を熱中や夢中の対象のみで固める）
    - 取り組み方のコントロール
      - ポモドーロテクニックは（人間の集中力の仕様に基づき）25-5サイクルを踏襲
      - 集中
    - つまり「多数のタスクを漏らすことなく管理」ではなく「少ない対象をいかに高い密度でやりきるかの支援」
      - 浅いタスク管理と深いタスク管理？
- 納期までに仕上げたい
  - これは忘だよなぁ
- 集中して取り組みたい
  - 結局のところ仕上げるため、なんだよなぁ
  - 過程を楽しむため、というのはあるが
    - それはもはやタスク管理ではなく「遊び方」の範疇だろう
終わらないリスト
- 別名
  - 終われないリスト
  - 終了状態存在しないエンドレス
  - エンドレスタスク管理？
    - エンドレス=終了という概念が存在しない、と決めてしまって良さそう
      - ここに一例としてHabiticaをおしこもう
      - 習慣系の管理は今後こっちのジャンルで発展していくはずだ
    - タスク管理スタンス - monolithic エンドレスというとこれだが
    - ~~エンド=ゴール~~ false
      - でも終わりがない習慣でも「30回継続する」のように区切り（Break）をつけることはできる
      - 達成（Achievement）
      - 区切り（Break）
      - ゴールレスという意味ではない
        
        ゴールの有無は解釈で決まる
        
        例：ブロガーとして収入月30万
        
        これ自体はゴール
        
        毎日更新を3年達成という区切り
        
        ブロガー=30万達成、は絶対的な定義ではない
        
        定義は人それぞれ
        
        区切りも達成も本質的に差はない
        
        そもそも解釈の公理だし
- 例：Habiticaの習慣タスクだけを並べたリスト
- カウントを増減できるだけで終了はない（項目が減らない）
- 減点式カウンターもこれで説明できる

2hop Links

→ 習慣タスク
- ← Habitica
- ← エンドレスタスク管理
- ← CTTL
- ← カウンター
→ 報告的終了
- ← Commitas
- ← ハードなタスク管理が単体で利用されない理由
- ← Tritask
- ← タイムトラッキング
- ← CTTL
- ← ツーオペな報告的終了
- ← 終了方式
- ← Report of Time
→ ポインタコンテナ
- ← GitHub Issues
- ← タスクポインタ
- ← マイルストーン
- ← リッチ属性
→ ポモドーロテクニック
- ← zangai
- ← テクニック
- ← 熱夢集
- ← 深いタスク管理
- ← ダッシュ法
- ← 集中管理
→ ブラックボックス
- ← ボーナス入りブラックボックス
- ← セット
- ← タスクガチャ
- ← ステートレス
→ 実行後属性
- ← 属性
- ← TaskChute2
- ← 終了コスト
- ← TMaaD
- ← 所感
- ← 評価
→ 観測
- ← タスクのライフサイクル
- ← 観測されていないタスク
- ← 観測されたタスク
- ← 観測と解釈の違い
- ← 解釈
→ ネクストタスク
- ← リコメンド
- ← 心理
- ← タスクペディア
→ アイドルサマリー
- ← アイサマ
→ アイビー・リー・メソッド
- ← trash
- ← zangai
- ← テクニック
- ← 深いタスク管理
- ← メリハリン
- ← キッティング
- ← クローズドリスト
→ アイドルタイム
- ← アイドルサマリー
→ コンディショナルパラメーター
- ← 連動系パラメーター
→ VSRFW
- ← スルー