scrapbox-sta-taskmanagement

trash

いったん検討を中止したもの。

zangai

線表
- ただしタスク管理に帰着できることが多い
  - 仮にプロジェクトAのタスクが1,2,……25まであったとする
  - 線表を引くと、1～25まで順に並べてスケジュールを引く
  - そのとおりに進められるケースは少ない
  - もう少し緩い方が上手くいく
  - こうする
    - 1～25が洗い出されていることは必要
      - プロジェクトによってはこれさえも曖昧なことがあるが
    - 1～25各々の進捗も必要
    - 順番通りにやらねばならない＆このタスクはこの期間内にやらねばならない
      - これを撤廃する
    - 締切日に依存するものはマイルストーンなどで固める
  - Issuesのようなリストだけで完結できるはず
    - ガントチャートみたいなコストかかる手段は要らない
- 例外
  - 顧客側に「いついつまでにやります」を掲示する必要がある
    - SIの契約などで締結された場合
    - 生活道路の工事など
客観的重要度の没
- 没理由
  - パートナータスク管理は「夫婦間の高度なタスク管理」ではなく「ハードル低いファミリー間ルーチン管理」になったから
  - ルーチン管理に客観的重要度という大げさな属性は出番ない
- パートナータスク管理において重要となる概念
  - 主観的重要度では相手に重要度が伝わらず衝突の原因となる
  - お互いが「そのタスクが当人にとって重要である」と認識できるようにするべき
    - 優先度
    - しかしすり合わせが難しい
      - 「優先度Aとは〜〜である、と定義しよう」といった議論は万人に行えるものではない
      - お互いがマニアか、最低でもアクティブユーザー以上でなければ議論まで至れない
        
        タスクキャズム理論
  - そこでリーサルという客観視しやすい指標を扱う
画像+タスク管理
- ツール上で表現するタスクは文章がメイン
- 絵や写真はどうだろう？
- ボックスと相性が良さそう
  - この中からやりたいものを選ぶ
  - 文章だとおもちゃ箱のメタファーとして弱いが、絵だとそれっぽくなる
- タスクのアイコン化
- タスクの擬人化
- 分類アイコン
  - 分類系属性をアイコンで表現したもの
  - コンテキスト=Homeの場合、家のアイコンにするとか
  - SlackやGitHubでEmojiうつときみたいに、入力時は文字列だが表示時はアイコン
    - ScrapboxのハーフWYSIWYGをイメージしてもいいか
動画+タスク管理
- タイムラプス
- :sta:イメージ全然膨らまないので時期尚早
タスク管理を用途や効用別に整理したい
- ノウハウは単にテクニックだけではなく、その人がどんな欲求を持って（どんな体験を求めて）実施しているのかという情報もセットで提示してもらえるとありがたい。そうでなければ、取り扱い説明書がついていないに等しい [ひとそれぞれの、しかし類型的な理由 – R-style](https://rashita.net/blog/?p=30099)
- そろそろ用途、効用、適性といった観点でも整理していきたい
  - と思ったが、タスク管理の分類とかがもっとまとまってきてからかあぁ
- 現時点で言えるとしたら
  - 個人で管理したい人と、チームで管理したい人
  - 忘迷怠を軽減したい人と熱夢集を手に入れたい人
  - TODOだけ管理したい人と、行動も管理したい人
  - ルーチンを管理したい人とそうじゃない人
  - 自然に管理していきたい人と、そうじゃない人
    - 佐々木正悟は自然派だと思ってる
      - ログ記録して自己理解しようというTaskChute思想のパイオニアの一人
    - jMatsuzakiは不自然派だと思ってる
      - とにかく夢に向かって進む
      - 自分にとって自然かどうかは重要じゃない、必要なら不自然でも取り入れる、変えるイメージ
  - :sta:まだまだ少ないね
    - 心理面が弱い気がする
    - 自律性に頼りすぎている
      - たとえば脳内で注意それまくるADHDにとっては使い物にならないだろう
    - 具体的な立場を想定する
      - 学生
      - 高校生
      - 子ども
      - タスク管理、とは違う気がしてきた……
        
        タスク管理をどう運用させるかという方法論であって
        
        タスク管理そのものではない
:sta:「リピート」の方が含意が正確な気がしてきた
- ルーチンはリピートの一部で、ある程度身についた的な含意がある
- 定期性も英語で言えば repeatfulness とかになるだろうし
- ルーチンタスクにできる、は repeatable がわかりやすい
  - routinable とかは造語すぎる
- ルーチンのままでいきます
  - 「身につく」に近づける、は利用者が目指すべき目標でもある
  - ……というのは建前で、僕がもう「ルーチン」という言葉に染まりすぎている
  - 体系化している僕自身が使いやすいもので
純粋なタスク管理ツール
- まとめ
  - この概念は要りません
  - リッチで事足りてる
  - 「リッチを含んでいないもの」を指す言葉は今のところ必要ない
    - 「純粋」という言葉がかっこよくて使いたくなるが
    - それに対義語で言えば純粋（Pure）というよりは簡素（Poor）では？
      - スタンス分けられそうだが
        
        リッチであるべき派
        
        タスク管理ツールであってもタスク管理以外も欲しい
        
        そのほうがシームレスじゃないか
        
        そのほうがいろんなツール覚えたり連携や運用整えたりしなくていいじゃないか
        
        プアであるべき派
        
        タスク管理ツールはタスク管理だけすればいい
        
        それ以外は別のツールでやるからいらない
        
        必要なら連携すればいいし
        
        :sta:でも連携機能持つツールってリッチだよな
        
        そもそも連携機能そのものがリッチ
        
        純粋のジレンマ
- ツールのうちタスク管理に特化したもの
- タスク管理以外の機能を持つツールは純粋ではない
  - 純粋でなくなる条件
    - リッチな機能を持っている
      - リッチコンテナ
      - リッチ属性
- プロジェクトタスク管理ツールの大半は純粋ではない
  - タスク管理+αになっている
  - :sta:ちょっとまだもやってる
    - プロジェクトタスク管理できるという意味での純粋さもある
    - 純粋=個人タスク管理？
    - たとえばpermission機能があると、もう純粋じゃないと思う
    - たとえばファイル管理機能があると純粋じゃない
    - とするとやはり個人タスク管理？
    - いや、プロジェクトタスク管理レベルの純粋もある
      - 担当者は必要
      - ファイル管理は要らない
        
        あれば便利だが、必須ではない
    - 「これがないとタスク管理が成立しない要素」のみから成る = 純粋？
    - なんで純粋という概念が必要？
      - タスク管理に集中したいから
      - たとえばTaskChuteという概念は、純粋じゃないと出てこない
  - 「高級なタスク管理」は？
    - 機能パラメーター系
食事というメタファ
- 栄養と嗜好
- 栄養は取らなきゃいけない、的な？
- 栄養は取らなきゃいけない
- 嗜好品は取らなくてもいいが、取れば豊かになる
- タスクにも栄養と嗜好品の二つがある
- これ、リーサルじゃね
- もっとたとえる
  - 頻度は微妙だ
    - 摂取 → do complete
    - 一日三回、食事をする → 一日三回、タスクリストを見てメンテする
      - ストイックなタスク管理してる人が「ずっと食べまくってる食いしん坊」になるけどw
      - 違う。一日三回、do complete する機会があるって対応になる
  - :sta:閃かん
    - またサクサク閃くときを待て
    - 無理にひねっても（論理の組み立てでもなければ）大したものはでてきません
子供向けタスク管理
- :sta:広がりません
- 仮説立てる意味でもページ化しておきたい
- が、子どもいないので仮説さえも書けない
- メタファ、ゲーミフィケーションあたりが鍵だとは思うが
- 無意識のタスク管理？
  - 本人に管理作業を自覚させない
- 年齢別に分けるというのは？
どこまでを管理対象にするかという分類
- TODOのうち、どこまで
- アクションのうち、どこまで
- 何段階くらいある？
  - 全部
  - :sta:（この間よ）
  - 厳選
    - アイビー・リー・メソッド
- n段階として、todoとアクションとで2パターン
  - 仮に3段階としたら、全部で9パターンあるよ
  - ひとまず3段階でいいでしょ、モデルは単純にするべき
慌ただしいタスク管理
- :sta:うまくまとまらない
- タスク管理が通用しない状況とは
  - VUCA？
    - というか前提がひっくりかえりやすい状況下
      - 顧客が上が無能で、思いつきでひっくり返すとか
  - リアルタイム
    - 締め切りが短いということ？
      - min以内
  - 手段的拘束
    - 物が使えないセキュリティ高い場所とか
- 忙しすぎる（動的）状況下。タスクの存在を忘れないようにする。変わるのは当たり前なので「今日一日のデイリータスクリストつくるか」とかが通用しない
- 慌ただしくないタスク管理
- なんかマトリクスで分類できるはず
- 状況可変、不変
- 割り込み多い、少ない
- 発生的、調整的
境地による分類？
- :sta:広がらない
- 個人タスク管理の到達点を表す 4 つのモデル - ガラパゴスタ
  - 秘書
  - ロボット
  - 作業者
  - 特攻兵
- MECEじゃないのが気になる
  - 発散してる
- 個人タスク管理限定かしら
- 作業者はレイヤー違うから除外かしら

2hop Links

→ 行動
- ← 物タスク
- ← VUCA
- ← 注入
- ← タスクシュート時間術
- ← PassiveWeak
→ 締切日
- ← 属性
- ← Outlook
- ← Trello
- ← Asana
- ← GitLab Issues
- ← タスクとTODOの違い
- ← ClickUp
- ← タスクカレンダー
→ 熱夢集
- ← workspace
- ← タスク管理
- ← タスク管理概論
- ← zangai
- ← WhatとWhyにあたるコンテキストはまだ発見されていない
- ← 深いタスク管理
- ← アンチルーチン
→ アイビー・リー・メソッド
- ← zangai
- ← zangai_1
- ← テクニック
- ← 深いタスク管理
- ← メリハリン
- ← キッティング
- ← クローズドリスト
→ 心理
- ← タスク管理概論
- ← 忘迷怠
→ リッチ
- ← 純粋のジレンマ
- ← 純粋派
- ← 純粋
- ← リッチパラメーター
- ← 機能
- ← リッチコンテナ
- ← クリッカブルリンク
→ 客観的重要度
- ← MSEメソッド
- ← リーサル
- ← 重要度
→ リーサル
- ← 客観的重要度
→ リッチコンテナ
- ← Trello
- ← Asana
- ← GitHub Issues
- ← ワークスペース
- ← 自動チェイン
- ← コンテナ
→ zangai
- ← zangai_1
→ アクティブユーザー
- ← workspace
- ← タスクキャズム理論
- ← 一般人
→ 忘迷怠
- ← タスク管理
- ← タスク管理概論
- ← 緩いロボット
- ← zangai_1
- ← ブラックボックス
- ← ゲージトラッキング
- ← VUCA
- ← 脳内複製
→ リッチ属性
- ← Toggl
- ← GitHub Issues
- ← マイルストーン
- ← リッチパラメーター
→ 自己理解
- ← タスク管理
- ← タスク管理概論
- ← zangai
- ← コンテキスト
- ← 深いタスク管理
- ← VUCA
- ← 不自然な管理
- ← 自然な管理
→ リスト
- ← タスク管理概論
- ← 俯瞰表示
- ← Asana
- ← ホワイトボックス
- ← セット
- ← ブラックボックス
- ← トリガーイメージ
- ← ClickUp