1. このドキュメントについて
    1. (2020/06/02) NO LONGER MAINTAINED
    2. 目次構造
    3. 書き方について
  2. タスク
    1. タスクとは
      1. タスクが満たすべき条件
      2. TODO との違い
      3. ジョブとの違い
      4. シードとの違い
    2. 記述
    3. 粒度
      1. 分解
      2. 細かいタスクと粗いタスク
      3. 細かい立場と粗い立場
    4. パラメーター
    5. 内部パラメーター
    6. 階層構造
  3. タスク管理
    1. タスク管理の効果
    2. タスク管理の目的
    3. タスク管理の位置付け
      1. 委譲管理
    4. タスク管理の種類
      1. 各タスク管理の特徴比較
      2. 各タスク管理の具体例
    5. コンポーネント
      1. ユーザー
      2. システム
      3. データ
    6. 終了方式
      1. リードオンリー
      2. チェッキング
      3. スタートエンド
    7. シーム性
      1. シームレス
      2. ハーフシーム
      3. シームフル
    8. 表示方式
      1. リスト方式
      2. カード方式
      3. イシュー方式
  4. タスク管理データ
    1. コンテナ
      1. 明示的コンテナと暗黙的コンテナ
      2. コンテナのネスト
      3. コンテナのパラメーター
      4. 擬似的なコンテナ
      5. 密度
    2. アクティブデータ
    3. ログ
    4. 設定
  5. パラメーター-属性
    1. 属性の目的
    2. 分類-必須属性
      1. 記述
      2. 状態
    3. 分類-日付系
      1. 実行日
      2. 予定日
      3. 作成日
      4. 締切日
      5. 完了日
    4. 分類-時刻系
      1. 見積時間
      2. 開始時間
      3. 終了時間
      4. 実績時間
      5. セクション
    5. 分類-繰り返し系
      1. 繰り返し頻度
      2. 繰り返し回数
      3. 繰り返し境界
    6. 分類-タグ系
      1. 優先度
      2. プロジェクト
      3. コンテキスト
      4. ラベル
      5. モード
      6. スター
  6. パラメーター-関係
    1. 関係に関する全般事項
      1. 関係パラメーターの種類
      2. ポインティング
      3. 関係の目的
      4. 二種類の言及
    2. 分類-親子関係
      1. 親タスク
      2. 子タスク
    3. 分類-ポインター
      1. ポインター
  7. パラメーター-機能
    1. リッチとは
      1. サイズリッチ
      2. カスタムリッチ
    2. 分類-サイズリッチ系
      1. コメント
      2. 添付ファイル
      3. チェックリスト
  8. タスクの種類
    1. オルタスク
      1. コンテナ
      2. イベント
      3. モットー
      4. メモ
      5. テストデータ
    2. デイリータスク
    3. ルーチンタスク
    4. マスタータスク
      1. マスタータスクリスト
      2. マスタータスク
    5. エントリータスク
    6. フィジカルタスク
      1. フィジカルタスクの要件
    7. ファーストタスク
    8. レスタスク
    9. 不発タスク
      1. 不発
      2. 不発タスク
      3. 不発の誘惑
    10. A タスク
    11. バッファタスク
    12. テンプレートタスク
    13. 凍結タスク
      1. 凍結
      2. 凍結タスク
      3. 凍結タスクリスト
    14. 区切りタスク
    15. 条件付きタスク
      1. 暗黙的な条件付きタスク
      2. 暗黙的な条件の静的性質
      3. 暗黙的な条件の有無
    16. 転送タスク
    17. タイニータスク
    18. ～～としてのタスク
  9. タスクの操作
    1. 基本操作
      1. 追加
      2. 編集
      3. 複製
      4. 移動
      5. 物理削除
    2. 編集操作のエイリアス
      1. 論理削除
      2. アーカイブ
      3. 開始
      4. 終了
      5. スキップ
    3. 内部パラメーター操作のエイリアス
      1. ロック
      2. 凍結
  10. タスク管理界隈
    1. 定義と権威について
    2. 歴史
  11. 参考書籍
    1. 書籍
    2. ウェブ資料
  12. 更新履歴

このドキュメントについて

タスク管理の体系化を試みた文書である。

※タスク管理に直接関与しない周辺については タスク管理支援 や 主なタスク管理手法 を参照。

(2020/06/02) NO LONGER MAINTAINED

ここはもう更新されていません。

体系化は下記 Scrapbox にて引き続き行っています。

:point_right: タスク管理の体系化

目次構造

大見出しの構造と概要についてのみまとめる。

「このドキュメントについて」の項では、本文書に関する前提や背景などを雑多に取り上げる。

「タスク」の項では、タスクそのものの性質について取り扱う。内容は実践よりも理論や概念がメインになる。

「タスク管理」の項では、タスクを管理するという文脈の事柄を扱う。内容は理論や概念のみならず、具体的なツールや運用方法にまで言及する。

「タスク管理データ」の項では、タスク管理において扱うデータを大別した上で、各々の詳細に言及する。

「パラメーター - XXXX」の項では、タスク一件に付与されるパラメーターとして何があるか、また各々は何のためにあるかなど、各パラメーターに関する詳細を扱う。

「タスクの種類」の項では、何らかの性質を持つタスク(～～タスクと名前がついている)について雑多に取り扱う。

「タスクの操作」の項では、タスクに対して実行する主な操作を網羅する。

「タスク管理界隈」の項では、タスク管理を取り巻く世界の性質や歴史について雑多に取り扱う。

書き方について

用語定義の書き方。用語 XXXX の定義は以下のように書く。

文字装飾。太字 や 斜体 などは用いない。

括弧。括弧は「」のみ用いる。使用ケースは様々だが、例を挙げる。

タスク

タスクとは

タスクとは「やること」の意。

タスクが満たすべき条件

以下をすべて満たすもののみがタスクである。

TODO との違い

TODO とはマルチ属性でない「やること」を指す。

たとえば「タスクの記述」のみを列挙したタスクリストは TODO リストとも呼ばれるが、これはタスクリストではなく TODO リストと呼ぶのが正しい。ただしこれは本文書における定義であり、文脈によっては異なる意味を持つことがある。

参考: タスクと TODO の違い

ジョブとの違い

ジョブ(Job)とはコンピューターにおける仕事の単位を指す。これをタスクと呼ぶ文脈も存在するが、本記事では「やること」としてのタスクとの混同を避けるため、こちらはジョブと呼ぶことにする。

シードとの違い

シード(Seed)とはタスクの元になるネタのうち、それを見ればタスクを想起できるものをいう。

シードの例:

たとえば「ガス料金をコンビニで支払う」タスクを処理する場合、自宅に届いた支払書を読んだ後でタスク管理ツールにタスクを追加する方法と、支払書をどこか目立つ場所に置いておき次に目にした時に対処させる方法の 2 つがあるが、この時の後者の支払書がシードである。支払書というシードを見ることで、料金を支払うというタスクが想起される。

なお、文脈によってはタスクという言葉をシードとして用いることがある(マスタータスクリストにおけるタスクなど)。

記述

記述とはタスクを表す文章。

例:

粒度

粒度(Granularity)とは「”やること” がどれだけ分解(細分化)されているか」という観点を前提とした時の、「やること」の「分解の細かさ」の度合い。

粒度が大きいことを粒度が細かい(Fine)といい、粒度が小さいことを粒度が粗い(Coarse)という。

より詳しい基準を言うと、一般的に「具体的に行動可能で、かつ短時間で終了できる」ところまで分解されているものを粒度が細かいという。逆にそうではないものは粒度が粗い。

分解

分解(Breakdown)とは、ある粒度の粗い「やること」に対して、その「やること」に必要な行動を洗い出すこと。洗い出した各々の行動もまた「やること」であるが、これらは粒度が細かい。

以下は分解の例である。A という粒度の粗い「やること」を、a～e という粒度の細かい「やること」に分解している。c については、さらに細かい粒度 1～3 に分解している。

分解せずに粒度の粗い A を見ても、具体的にどう行動し管理していけばいいかがわからないが、上記のように分解してやると a や 1 といった小さな単位各々を管理することができる。

細かいタスクと粗いタスク

粒度が細かいタスクを細かいタスクという。粒度が粗いタスクを粗いタスクという。

基本的にタスクは細かいタスクであることが望ましい。というのも単純に管理しやすいからである。極端な話、何をすればいいかわからない巨大な「粗いタスク」1個よりも、それをブレイクダウンして具体的に行動可能な小さな単位に分解された「細かいタスク」100個の方がタスク管理はしやすい。前者では管理が成立しない。

ただし管理による弊害が大きい場合は、あえて粗いまま管理することもある。極端な話、あらゆる「やること」を 1 分でこなせる単位に分解して管理することは非現実的である。粒度が細かすぎると管理の手間が増える。

タスクの粒度をどこまで細かくするかはユーザー次第、状況次第である。

細かい立場と粗い立場

タスク管理において細かいタスクを主に扱うことを細かい立場という。逆に粗いタスクを主に扱う(あまり細かく分解しない)ことを粗い立場という。

細かい立場のユーザーはしばしば日常生活の(数分以内に終わる)雑事も管理する。たとえば「トイレ」「歯磨き」「持ち物確認」といったレベルでタスクを洗い出している。一日のタスク数が数十以上に及ぶことも珍しくない。この性質上、複雑な TaM ツールを利用していることが多い。また後述するルーチンタスクも積極的に管理する傾向にある。

粗い立場のユーザーは「本当に重要な事項」のみを最低限、抽象的な記述で管理する傾向にある。細かいタスクを管理する手間を惜しみ、具体的な行動は都度自分の頭で決めることを好む。この性質上、複雑な TaM よりもシンプルな ToM を好む。付箋でタスク管理を行うタイプもこの立場である。

パラメーター

タスクはパラメーター(Parameter)を持つ。

パラメーターとはタスクに関する情報のこと。パラメーターは以下の三種類から成る。

属性とは 1-key N-value なパラメーターで、そのタスク単体でも不足なく値が完結されるもの。

関係とは「そのタスクに紐付いているタスク」に関するパラメーター。親子関係とポインターがある。

機能とはそのタスクに関するリッチなパラメーター。添付ファイルやコメントなどがある。

内部パラメーター

内部パラメーター(Internal Parameter)とは、ユーザーが直接変更することを想定していない、タスクに関する情報である。

例: Read Only パラメーター

多人数利用を前提としたツールでは各タスクを複数人が編集できるが、これを行えないようにするロックという操作がある。これは内部的には Read Only パラメーターを有効にしている。

ただし内部パラメーターとは論理的な概念にすぎない。この概念の存在異義は、ユーザーが直接編集できるパラメーターのみでは説明が付かない操作を説明するためである。たとえば上述したロック操作は、ユーザーが直接何らかのパラメーターを編集するわけではない。あくまでも内部的に Read Only なパラメーターがあり、それをシステムが適当に操作することで、ユーザーに「ロック」という直感的な状態を見せている。

階層構造

タスクは階層構造を持つ。

階層構造の実現方法は二種類ある。

ツールの表現例:

タスク管理

タスク管理とはタスクを管理するための心構え、方法論、仕組みやツールなどの総称。

タスク管理の効果

タスク管理によってもたらされる効果として表面化、具体化、可視化がある。これを三大効果(3E - 3 Effects)という。

タスク管理の目的

タスク管理の目標は「何かを管理するため」である。この「何か」が何であるかは人それぞれだが、以下に大別できる。

タスク管理の位置付け

タスク管理は手段であって目的ではない。何らかの目的を達成するためにタスク管理という手段に頼る。このようなタスク管理の位置付けは、GTx レイヤー(GTx Layer)という三層のモデルで表現できる。

GTx レイヤー:

[         Goal            ] 
[    Target Management    ] 
[     XXXX  Management    ]

GTx レイヤーでは「何かの達成」を Goal、Target、XXXX の三層で表現する。

XXXX Management は複数存在するが、その一つが Task Management ことタスク管理である。これを GTT レイヤーと呼ぶ。

GTT レイヤー:

[         Goal            ] 
[    Target Management    ] 
[     Task  Management    ] 
[Task][Task][Task]...[Task]

タスク管理では「やること」をタスクという単位で捉え、これをシステマチックに扱うことで日々の「やること」を効率的に収集、整理、達成していく。もっと言えば目標を達成するために、目標が「やること」から構成されると捉えた上で、これを効率的に扱うことを考えるのである。そういう意味で、タスク管理とはゴールや目標ありきの手段と言える。

※ただしタスク管理という概念やシステムそのものの考案や考察といった行動は趣味にもなりえる。この場合、タスク管理は手段ではなく目的であると言える。

委譲管理

XXXX Management は複数存在すると述べたが、Task Management 以外の例として委譲管理(Delegation Management)を挙げておく。

委譲管理とは目標を達成するには「目標を達成できる人員(スタッフ/Staff)に仕事を任せれば良い」と捉え、スタッフの調達、依頼、命令、管理などを行うことで目標を達成していくアプローチ。

[          Goal            ] 
[    Target    Management  ] 
[  Deligation  Management  ] 
[Staff][Staff][Staff][Staff]

委譲管理の例:

委譲管理を前提とした GTx レイヤーは GTD レイヤーと呼ぶが、これは Getting Things Done の GTD と紛らわしいため、GTDel レイヤーと呼ぶことも多い。

タスク管理の種類

以下の三種類がある。

個人 TODO 管理とは TODO を管理すること。

※TODO は個人的なものであるため、チーム TODO 管理なる概念は存在しない。仮に TODO をチームで扱おうとしても、少なくとも担当者属性が発生するため TODO は TODO ではなくなり、それはもはやタスク管理となる。

個人タスク管理とは個人のタスクを管理すること。関係者は自分自身のみである。

チームタスク管理とは複数人のタスクを管理すること。関係者は自分を含めた複数人である。チームタスク管理ではタスクが担当者属性を持つ。

各タスク管理の特徴比較

種類 対象 必須属性 粒度 備考
ToM TODO 記述 粗い もっぱら個人のやり忘れ防止目的
TaM Task 記述,状態 細かい ToM よりもストイックに管理する
TTaM Team Task 記述,状態,担当者 粗い もっぱらプロジェクト管理目的

各タスク管理の具体例

例: タスク管理本を出版する

ToM:

TaM:

TTaM:

コンポーネント

タスク管理において登場する要素について。

登場人物一覧:

ユーザー

タスク管理に携わる者を便宜上ユーザーという。

ユーザーは消費側と生産側に大別できる。

利用者とはタスク管理を利用する者全般。

提唱者とはタスク管理に関する何らかのシステムを考案した者。

提唱者の例:

開発者とは提唱されたシステムを実利用できる形で実装した者。

システム

タスク管理というシステムは以下を含む。

システムには明示的なシステム(Explicit System)と暗黙的なシステム(Implicit System)がある。

明示的なシステムとはそのシステムに名前が付いており、かつシステムの内約が形式化されており共有が可能なもの。一般的に知られているものはごく一部であり、一部のチームや個人内でのみ利用されるものも多いとされている。

暗黙的なシステムとは明示的でないシステムのこと。人は各々が自分に適したタスク管理を(タスク管理という概念を知らずとも)構築し、運用しているという意味では誰もが暗黙的なシステムを持っていると言える。これを無自覚の利用者と呼ぶ。

データ

タスク管理において扱うデータ(Data)には以下 4 種類がある。

コンテナとはタスクを分類するための概念や単位。アクティブデータとは未消化のタスク。ログとは消化済のタスク。設定とはタスク管理ツール自体の設定。

詳細はタスク管理データの項を参照。

終了方式

一つのタスクを開始してから終了するまでの操作として、どんな手順を踏むか(終了方式という)。

リードオンリー

リードオンリー(Read Only)方式とは特別な操作を何も行わない方式。

タスクは単なるメモであり、その用途は、必要に応じて読むだけである。

チェッキング

チェッキング(Checking)方式とは終了操作のみ行う方式。

チェックマークを付ける、削除するなど。

スタートエンド

スタートエンド(Start-End)方式とは開始操作と終了操作を行う方式。

シーム性

シーム性(Seamness)とはタスク管理ツールにおいて一覧画面から直接タスクを編集する能力を指す。

シーム性には以下三種類がある。

シームレス

シームレスとは一覧画面から直接すべてのタスクのすべての属性を編集できること。

シームレスの特徴:

シームレスなタスク管理ツールの例:

ハーフシーム

ハーフシームとは一覧画面から直接一部タスクの一部属性を編集できること。

ハーフシームの特徴:

ハーフシームなタスク管理ツールの例:

シームフル

シームフルとは一覧画面から直接タスクを編集できないこと。

シームフルの特徴:

シームフルなタスク管理ツールの例:

表示方式

タスクをどのように表示するか。

大別すると一覧表示と個別表示の二種類がある。

なお一覧表示については「タスクの表示方式」ではなく「コンテナの表示方式」と表現することもある。

リスト方式

一覧表示の一つ。リストとは箇条書きのことで、一行一タスクを並べる方式。

※リストという言葉(特にタスクリスト)には単に「タスクが並んだもの」という意味もあるが、本節では表示方式としてのリストのみ取り扱う。

リストは運用目的に応じて以下種類に分かれる。

EFL におけるリストの最大の特徴は、前行/次行のタスクにシームレスにアクセスできること。もっと言えば別画面やダイアログを介することなく、一画面上で編集できること。テキストエディタでテキストを編集するかのごとき使い心地を実現したものもある。このような性質をシームレスエディタブルという。

EFL リストの例:

一方、VFL におけるリストは観点(Condition)を持つ。VFL リストとは、ある観点によって抽出(フィルタリング)されたリストということもできる。フィルターリスト(Filtered List)とも呼ぶ。

VFL リストの例:

カード方式

一覧表示の一つ。カード方式とは一タスクを一つのカードで表現し、このカードをボードやカラムに配置する方式。

カード方式の例:

イシュー方式

個別表示の一つ。イシュー方式とは一タスクを一つのページで表現する方式。

イシュー方式の例:

※イシュー(Issue)とは元々はソフトウェアの BTS(Bug Tracking System) における一問題を扱う単位。発生日、発生要因、発生バージョンから担当者や進捗まで、多彩なパラメーターを持つため、ページ内は煩雑な画面になりがち。

タスク管理データ

コンテナ

コンテナ(Container)とはタスクを分類するための概念や単位。

コンテナはタスクではない。タスク自身が分類機構を持つ場合はコンテナではなく関係パラメーターを持っているという。コンテナはファイルフォルダでいうフォルダのようなもので、コンテナそのものにタスクの機能はない。

明示的コンテナと暗黙的コンテナ

コンテナには明示的コンテナと暗黙的コンテナがある。

明示的コンテナとはカテゴリー、フォルダ、プロジェクトなどシステムによって明示的に提供されるコンテナ。

明示的コンテナの呼び方の例:

暗黙的コンテナとは明示的コンテナを利用せずに実現された(無意識に実現されたものも含む)コンテナで、たとえば TODO リストには必ず「TODO を束ねたリストという構造の暗黙的コンテナ」が一つ存在する。コンテナという言葉が何を指しているか(明示的コンテナか、暗黙的コンテナか、両方か)は文脈次第であるため、注意深く読み解く必要がある。

コンテナのネスト

明示的コンテナには明示的コンテナを含めることもできる。これを明示的コンテナのネストという。単にコンテナのネストともいう。

通常コンテナのネストがシステムに実装されることはない。これはタスク管理が「多階層の分類」よりも「フラットなタグ付け」をもって管理されるのが主流だからである。仮に多階層が必要な場合でも、コンテナではなく関係パラメーターやリスト(つまり暗黙的コンテナ)などを用いる。

コンテナのネストの呼び方の例:

コンテナのパラメーター

コンテナもパラメーターを持つ。これをコンテナパラメーター(Container Parameter)という。

コンテナパラメーターの例:

コンテナのパラメーターには明示的パラメーターと暗黙的パラメーターがある。明示的パラメーターはシステム側が定義するパラメーターであり、設定すればそのとおりに動作する。一方、暗黙的パラメーターはコンテナという概念に備わる性質であり、性質を実現するかどうかはユーザー自身の運用次第である。たとえば「ふた」は一般的に暗黙的なパラメーターである。

擬似的なコンテナ

擬似的なコンテナ(Virtula Container)とは、コンテナの機能ではないが別の機能(特にパラメーター)により擬似的にコンテナを実現すること、あるいは実現されたそれら。

例として、タスクの記述中に観点を記述した「フラットコンテナ」がある。

2019/04/01 Proj-A 週報を書く
2019/04/01 Proj-A 引き継ぎ用資料作成を進める
2019/04/01 Proj-B 新人向けキックオフ
2019/04/01 Proj-B 週報を書く
2019/04/01 家事 洗濯

上記ではフラットコンテナとして Proj-A、Proj-B、家事の 3 つがある。

タグ(コンテキスト)との違いが紛らわしいが、タグは単に「後で抽出を行うための目印」であるのに対し、フラットコンテナは(上記のタスク一覧画面において)階層構造を表現している点が異なる。上記の場合、行単位でソートを行えば各フラットコンテナごとに固まった並びとなる。この塊一つ一つが階層の一つ一つを表している。ちなみに 2019/04/01 もまたフラットコンテナなので、上記は「2019/04/01 という(擬似的な)コンテナの中に、Proj-A、Proj-B、家事という(擬似的な)コンテナが入っている」と解釈できる。

密度

コンテナの密度とはコンテナ内に存在するタスクの密度を意味し、一月分、一周分または一日分といった時間幅のうちどこまでをタスクが占めているかを示した指標である。

例を示す。デイリータスクリスト A と B があるとする。A は平日会社業務に関するデイリータスクを、B は平日の朝夜および休日のデイリータスクを並べている。この時、たとえば以下のようなことが言える。

密度には定性的なものと定量的なものがある。上記の例は定性的な密度である。

定性的な密度とは定量的でない密度のこと。定性的な密度という言葉は、ある時間幅におけるタスクの密度(タスク数が多い = 詰まっている = 濃いのか、それともタスク数が少ない = 詰まっていない = 薄いのか)を直感的に扱うために用いる。

定量的な密度とは、時間系のパラメーター(開始時間/終了時間/見積時間など)を用いて、時間幅のうちどこまでをタスク(の見積値および実績値の合計)が占めているかを数値化できるような密度を指す。たとえば午前 9 時から午後 6 時までのすべての行動をタスク管理ツールに落とし込んだ場合、(一日という時間幅なら)密度は 37.5% と表現できる。

密度の濃淡については、一般的に以下が言える(ただし密度が濃い場合のみ取り上げ、密度が薄い場合は濃い場合の逆なので割愛する)。

密度が濃い:

一日時間幅のうち、定量的密度が 50 % を超えるようなタスク管理をヘビーなタスク管理と呼ぶ。ヘビーなタスク管理では、起床後のトイレ、歯磨き、朝食、着替えといった行動のレベルでタスクを登録し、日常生活レベルで無駄無く行動することを目指す。その性質上、スマホから操作できる Taskuma のようなツールや、あるいは(PC を電源つけっぱなしにした上で)テキストエディタ上で軽快に動作する Tritask など、携帯性や操作性に特に優れたツールが好まれ、またライフログを兼ねることもある。

アクティブデータ

アクティブデータ(Active Data)とはシステムにおける未消化のタスク。

アクティブデータという言葉はレトロニムである。元々タスク管理におけるタスクとは「(未消化の)やること」を指し、「(消化済の)やったこと」は取り扱っていなかったが、後者にも価値があることがわかってきた。後者をログと名付け、研究や利活用が進むようになった。前者に対する呼び名がないため、アクティブデータと名付ける。

ログ

ログ(Log)とはシステムにおける消化済のタスク。

ログは言わばユーザーの行動記録であり、ログを見返すことで自身の傾向把握や振り返りに活用できる。

ログを実現するためには、システムに「実行日」「開始日時」「終了日時」といったパラメーターが必要となる。これらパラメーターを備えたシステム上で、日々の行動をタスクとして取り扱うことではじめて「いつ、何を、どれくらいの時間をかけて行ったのか」という記録が残る。

設定

設定(Configure)とはタスク管理ツールに関する設定を指す。

タスク管理ツールはユーザーが効率的かつ快適にタスク管理を行えるよう設定項目を設けており、ユーザーは好みの設定に変えることができる。

設定の例:

パラメーター-属性

一つの属性は一つのキー(Key/設定名)と複数のバリュー(Value/設定値)を持つ。

タスクは複数の属性を持つことができるが、必須属性は必ず持たなければならない。

属性の目的

一言で言えば、何十何百と存在するタスクを管理しやすくするため。付加情報(属性)を付与することで意味付けを行い、分類や特定に役立てる。一度にすべてのタスクを相手にするよりも、何らかの属性に基づいて絞り込んだタスクのみ相手にした方が楽である。

分類-必須属性

必須属性とはタスクに必ず付与されている属性。

必須属性を持たない情報はタスクではない。

必須属性として以下がある。

記述

記述とはタスクを表す文章。

記述はタスクの必須属性である。

状態

状態(Status)とはそのタスクの進行に関する状態を示す属性。

方式としては「2値」と「3値」がある。

状態はタスクの必須属性である。システム次第では終了状態を非表示(消去や転記)をもって表現しているが、この場合も状態という属性は存在するものとみなす。

分類-日付系

タスクにはしばしば締切や予定といった形で日付が絡むため、日付系の属性は頻出する。

実行日

実行日(Execution Date)とはそのタスクをいつ実行するか(したいか)を示す属性。

実行日は WANT な日付であり、いつ実行するかの融通は利く。

実行日の意義は、各タスクを「日」という軸で分類できることにある。各日のタスクはその日に実行すればよく、また、ある日においてやるべきことはその日のタスクをすべて終わらせることだけである(明日以降のタスクはやらなくていい)。このような「日」基準の運用を可能にするのが実行日。

予定日

予定日(Scheduled Date)とはそのタスクはいつ実行されるべきか(しなければならないか)を示す属性。

予定日は MUST な日付であり、いつ実行するかの融通は利かない。事前に定められているケースと、一度決めたら変更できないケースの二通りがある。

作成日

作成日(Creation Date)とはそのタスクが(ツール上に)登録された日を示す属性。

作成日の意義は、放置されがちなタスクに対して「何日放置されているのか」を定量的に把握できるところにある。この情報を応用すれば「n 日経過したタスクを知らせる」といったリマインドも可能となる。

締切日

締切日(Due Date)とはそのタスクをいつまでに完了させなければならないかを示す属性。

主に粗いタスクに付与する。細かいタスクはすぐ終了できる上に、細々と多数存在することが多いため、いちいち付与しない。

完了日

完了日(Completion Date)とはそのタスクが完了した日を示す属性。

完了日の意義は、いつ何のタスクを終わらせたかという「ログ」を残せるところにある。

分類-時刻系

時刻系の属性は、主に高精度に実働時間を計測・記録するために用いられる。

見積時間

見積時間(Estimate Time)とはそのタスクの完了に要する時間を示す属性。

見積時間の意義は、複数のタスクの所要時間を計算できるところにある。各タスクに見積時間を付与しておき、見積時間を所要時間とみなせば、すべてのタスクを終えるのに要する時間がわかる。もっと言えばすべて終わるのが何時であるかがわかる。特にデイリータスクリストに用いる。

開始時間

開始時間(Start Time)とはそのタスクを開始した時間を示す属性。

開始時間の意義はログにある。すべての行動をタスク化し、また終了時間属性とセットで各タスクに開始時間を記録することで、いつ何をやったのかを記録できる。

終了時間

終了時間(End Time)とはそのタスクを終了した時間を示す属性。

終了時間の意義はログにある。すべての行動をタスク化し、また開始時間属性とセットで各タスクに終了時間を記録することで、いつ何をやったのかを記録できる。

→スタートエンド方式

実績時間

実績時間(Actual Time)とはそのタスクの完了に要した時間を示す属性。

見積時間が「見込みの所要時間」であるのに対し、実績時間は「実際の所要時間」を示す。したがって見積時間とセットで記録すれば、見積と実績の乖離を知ることができ、正確な見積に近づくためのヒントとして活用できる。

実績時間の記録方法としては、開始時間と終了時間を用いる。つまり開始と終了を記録しておけば、あとからツール等で差分計算して導出できる。

セクション

セクション(Section)とはそのタスクを実行するべき時間帯を示す属性。

セクションは「ある時間帯に対するエイリアス」として表現される。たとえば 09:00 ～ 12:00 を A、12:00 ～ 13:00 を B、と表現し、朝に実行するタスクにはセクションとして A を付与する。

セクションの意義は、「次に実行するタスクを決める判断」に要する労力を減らすところにある。ヘビーなタスク管理ではデイリータスクリストとして一日何十ものタスクが並ぶが、次にどれを消化するかをいちいち眺めるのは骨が折れる。幸いにも、タスクの大半は実行すべき時間が決まっている(あるいは決めることができる)ため、これをセクションという形で表現しておけば、ユーザーは日々「この時間帯はこれとこれをやる」といったふうに、判断を介さずに淡々と処理していける。

分類-繰り返し系

繰り返し系の属性は、そのタスクを再び実行できるよう複製して再設定するための属性。

繰り返しの実現ロジック:

繰り返し系の属性によりルーチンタスクを実現できる。

繰り返し頻度

繰り返し頻度(Repeat Frequency)とはそのタスクを繰り返す頻度を示す属性。しばしば実行頻度(Execution Frequency)あるいは単に頻度(Frequency)と呼ぶ。

頻度の例(Layer については後述):

頻度レイヤー(Frequency Layer あるいは単に Layer)とは頻度表現を大別する単位であり、どの時間単位で繰り返すかという観点で分類したものである。

どの Layer を実装しているかはツール次第である。以下に例を示す。

頻度には厳密性(Strictness)がある。厳密性は厳密(Strict)と妥協(Loose)の二値で表現する。妥協とは、30日後を一月後とみなす、など実装上単純な「n日後」をもって頻度を実現すること(Tritask など)

繰り返し回数

繰り返し回数(Repeat Count)とはそのタスクを何回繰り返すかを示す属性。

繰り返し回数には以下種類がある。

繰り返し境界

繰り返し境界(Repeat End)とはそのタスクを「この日までは繰り返す」ことを示す属性。

繰り返し境界は、繰り返し回数とは異なる切り口で繰り返しの終了タイミングを定めたものである。

分類-タグ系

タグ系の属性は、あとでタスクを抽出するためにあらかじめ付与されるもの。

タスクはえてして大量に存在し、その中から直近必要なものを抽出する機会に迫られることが多い。また、そうでなくとも、大量のタスクをいちいち一つずつ読み返して次のタスクを決める手間は犯したくない。これに対処するため、タスク管理では各タスクにタグを振っておき、あとから指定タグのみ抽出するというアプローチを取る。

タグにどのような意味や名前を持たせるかは様々だが、著名なタグも多数存在する。本節ではこちらを扱う。

※類似する概念として「カテゴリ」が存在するが、カテゴリもタグの概念で表現できるためタグ系の範疇に含める。

優先度

優先度(Priority)とはそのタスクの優先度を示す属性。

優先度は番号やアルファベットなどで表現され、昇順降順の並び順に優先度の高低を意味づける。たとえば A が最高で、E が最低、といった具合。

ツールの表現例:

プロジェクト

プロジェクト(Project)とはそのタスクが属するプロジェクト(仕事の単位)を示す属性。

「プロジェクト」という言葉の定義は特に無いが、「XXX プロジェクト」「家事」「書籍 YYYY の執筆」「引越し」など、きりのいいゴールの単位で設けることが多い。概念としてはタグ(意味を付与する)よりもカテゴリ(意味を持つ箱に振り分ける)が適していることもある。

ツールの表現例:

コンテキスト

コンテキスト(Context)とはそのタスクが属するコンテキスト(文脈)を示す属性のこと。文脈とは「置かれた状況や制約」を意味する言葉であり、たとえば「場所」「状況」「使用道具」「気分」「(そのタスクに着手する)時間帯」などがある。

コンテキストの意義は、その時実行できるタスクを素早く抽出するところにある。タスクはしばしば「特定の条件がなければこなせない」ことが多いため、いたずらに抽出しても「これは今は実行できない」といった不発が生じやすい。コンテキストを付与しておけば、これを解決できる。たとえば「自宅でできるタスク」「通勤電車中でできるタスク」といった観点で抽出できる。

発祥は GTD。

※ただしコンテキストという言葉は、「コンテキストスイッチング」等で用いられる意味でのコンテキスト――諸情報(必要な知識、背景、現在の進捗や状況など付随する情報のすべて)を意味する――を表すこともあることに注意する。

→ Getting Things Done - Wikipedia

ラベル

ラベル(Label)とはそのタスクの性質や特徴などを示す属性。

ラベルは名前と色を持つ。ラベルを付与したタスクが表示されると、そのラベル(の表示領域)は、設定しておいた色で表示される。各タスク(特に一覧表示されたタスク)の意味を視覚的に素早く知るのに役立つ。

モード

モード(Mode)とはそのタスクを実行するのに適したモードを示す属性。

モードとは「勉強モード」「読書モード」「集中モード」「だらだらモード」など、ユーザー自身の状態を端的に表現した俗語のこと。

タスクにモードを付与しておくことで、「このタスクはこのモードで行うものだ」ということを可視化できる。特に特定のモードで行うべきタスクを抽出し、一気に消化する用途で用いられる。

モードの意義は、タスクには特定のモードでなければ消化しづらいものがあるということを明示・体感させるところにある。典型例なのは集中を要する生産的タスクと、いつでもこなせる作業的雑務的タスクであり、これらは適当に混ぜて行うのではなく、集中モードの時に前者を、お疲れモードの時に後者をこなした方が効率的である。このような判断や消化を行う際に、モードという分類が役に立つ。

発祥は TaskChute。

→ TaskChute2 スタートアップガイド.pdf

スター

スター(Star)とはそのタスクが強調されていることを示す属性。

タグ系の属性は「タスクを特定の観点で n 段階に分類する」とも言えるが、これの最も単純なケースが n=2 の 2 段階であり、この 2 段階タグの一つがスターである。

パラメーター-関係

関係パラメーターは他のタスクとの関連を示すパラメーターである。タスク以外との関係を示すパラメーターは関連ではない。

関係に関する全般事項

関係パラメーターの種類

関係パラメーターには以下二種類がある。

親子関係は親タスク(自タスクを包含するタスク)や子タスク(自タスクが包含するタスク)を示すパラメーター。

ポインターは単に関連するタスクを示すパラメーター。

ポインティング

タスク A がタスク B への関係を保持することをポインティング(Pointing)と呼ぶ。

タスク A の立場をポインター(Pointer)と呼び、タスク B の立場をポインティー(Pointee)と呼ぶ。

関係パラメーターはポインター側でのみ保持されるが、ツールによってはポインティー側にも「タスク A から関係が設定されている」旨を保持させることがある。これをトレース(Trace)と呼ぶ。

関係の目的

タスクはしばしば単体では意味をなさず、関連するタスクとまとめて、はじめて意味をなすことが多い。したがって、その「関連するタスク」を効率的に管理する仕組みがあると便利だが、これを実現するのが関係パラメーターである。

二種類の言及

後述する関係「親タスク」や「小タスク」については、これらが指す対象が二通り存在するため注意が必要である。

たとえば以下のようなタスク関係があったとする。

ここで「小タスク」という言葉を用いた場合、これは「Task1 の小タスクというパラメーター」を指す場合と、「Task1 の子タスクである Task1-1 や Task1-2 そのもの」を指す場合がある。前者がパラメーター言及で、後者がターゲット言及。

関係パラメーターについて議論する際は、言及先がパラメーターなのかターゲットなのかを明示的に述べると理解しやすい。

分類-親子関係

親子関係は木構造である。ファイルやフォルダを同様で、あるタスクが複数の親タスクを持つことはない。これは言い換えるならば、(親子関係が構築されている木構造中の)あるタスクの親タスクを辿り続ければ、必ず一意なルートでゴールたる「根のタスク」に辿り着けることを意味する。

親タスク

親タスクとは自タスクを包含するタスクを示す関係。

主にチームタスク管理のように Visualization(進捗の可視化) に重きを置く場合に用いられる。手動設定は手間であるため、トレースの形で自動反映させることが多い。

子タスク

子タスクとは自タスクが包含するタスクを示す関係。「サブタスク(Subtask)」とも呼ばれることも多い。

子タスクは複数包含できる。

子タスクの包含には順序関係があるものとないものがある。前者については、リスト方式において頻出する。リスト方式では、サブリストをもって親子関係を実現するが、このサブリストの並びに「上から順番に実行するべき」といった意味を持たせることがある。

分類-ポインター

ポインター

ポインター(Pointer)とはそのタスクのポイント先を示す関係。

例: GitHub Issues

パラメーター-機能

機能パラメーターとはそのタスクに関するリッチなパラメーター全般を指す。

リッチとは

「リッチなパラメーター」という文脈におけるリッチ(Rich)とは以下のいずれかを満たすことをいう。

リッチなパラメーターをサポートするのは TTaM、イシュー方式、高機能な TaM 用のツールである。

サイズリッチ

サイズリッチ(Size Rich)とは上限サイズ(ファイルサイズや文字サイズ)が小さく定まらない、定めると支障が出る、データサイズが属性と比較して大きい、といった性質を持つパラメーターであること。

例:

カスタムリッチ

カスタムリッチ(Custom Ritch)とは「ユーザーが独自の属性を定義できる仕組み」によって定義されたパラメーターであること。

例:

分類-サイズリッチ系

コメント

コメントとはそのタスクに投稿されたコメントを示すリッチパラメーター。

コメントは各タスクに Append する形で追記される。複数人が同時に投稿しても衝突しないため、TTaM に適している。

ツールによってはコメントの中に他のリッチパラメーターを記述できるものもある(GitHub Issues など)。このような性質をリッチネスト(Rich Nest)と呼ぶ。

添付ファイル

添付ファイルとはそのタスクに添付されたファイルを示すリッチパラメーター。

チェックリスト

チェックリストとはそのタスクに添付されたチェックリストを示すリッチパラメーター。

チェックリストとは TODO のリストである。言うなればタスクに対して、n 個の TODO をぶら下げることができる。ツール側では終了数のカウントや割合を表示するといった便宜を図っていることが多い。

タスクの種類

オルタスク

オルタスク(Altask)とはタスクのようでタスクではないものを指す。名前の由来は「タスク(Task)としても使える(代用できる/Alternative)」より。

オルタスクは以下五種類から成る。

オルタスクをタスクとして扱おうとすると、タスク管理はしばしば煩雑化する。しかしながら扱えないことはない他、上手く扱えば管理手段の集約化やその他便宜を獲得できる。

コンテナ

→ コンテナ

イベント

イベント(Event)とは予定日を持つ事柄。

イベントはタスクとして扱うこともできるが、しばしば「粗いタスクになってしまう」「予定日中の指定時間帯中は漏れなく拘束される」「そもそも別の日に実施することができない」といった性質があるため、(特に細かいタスクを扱う場合に)扱いづらい。通常はカレンダーなど専用ツールで別管理する。

モットー

モットー(Motto)とは心構えや目標、標語などのこと。

モットーは、タスクとして扱うことで、目に入れやすくすることができるため、オルタスクになりえる。

モットーの運用方法は以下二種類。

メモ

メモ(Memo)とはメモ全般。

メモの例:

アイデアとは何らかの発想を表したもの。

リソースは資源の所在を表したもの。

ナレッジは知識全般。

インフォメーションは情報全般。

テストデータ

テストデータ(Test-data)とはツール上で何らかの試行を行うためにつくったタスク。

テストデータはゴミであるため、試行を終えた段階で削除しておくことが望ましい。

デイリータスク

ある実行日 yyyy/mm/dd を定めた時の、実行日がその日になっているタスクをデイリータスク(Daily Task)という。特に実行日が今日のタスクを指すことが多い。

デイリータスクは特に TTaM における最重要概念であり、多数存在するタスクを確実に消化していくためのアプローチである。つまりタスクに実行日パラメーターを与えて日単位で分割し、その日に行うべきタスクを「実行日がその日のタスクのみ」に絞るというルールを設けることで、ユーザー側の発散や混乱を防ぐ。

ルーチンタスク

ルーチンタスク(Routine Task)とは特定の頻度ごとに繰り返し実行するタスクのこと。しかし意味的には以下の二つに分かれる。

1 は単なる概念を示したものであり、「毎週月木の朝に可燃ゴミを出す」などがこれに相当する。一方、2 はツール上でデータとして存在するルーチンタスクを示すものであり、ツール上では「可燃ゴミを出す(頻度=月/木)」のような形で存在する。単に月曜日と木曜日に「可燃ゴミを出す」というタスクを配置しても、これはルーチンタスクではない(普通のタスクを二箇所に配置しただけである)。

ルーチンタスクは TaM において重宝する。というのも、個人のタスクは大半がルーチンタスクである or ルーチンタスクとして扱うことができるがゆえに、タスク管理による効率化やストレス軽減をドラスティックに味わいやすいからである。もっと言えば、ルーチンタスクの導入(必要なタスクの網羅と適切な配置)により、ユーザーは「必要なタイミングで必要なタスクを(ツールから)教えてもらえる」状態を実現でき、頭で意識したりやり漏らしたりするストレスから解放される。

ルーチンタスクは特に仕事や日常生活における雑事として散財するが、各々は軽微である(やった方が良いが最悪やらなくてもいい)ことが多いため、あえて管理しない立場を取ることもある。また、裕福なユーザーや立場を持つユーザーは、家政婦やアシスタントに委譲させて自身では管理しないこともある。

マスタータスク

まずはマスタータスクリストについて説明し、その後でマスタータスクについて説明する。

マスタータスクリスト

マスタータスクリスト(Master Task-List)とはすべてのタスクを記載したリストを指す概念。

マスタータスクリストの目的は「ここにすべてのタスクが集まっている」「ここを見れば最悪すべてがわかる(やることを忘れることはない)」といった状態を担保すること。つまりはタスクの一元集約。

しかしマスタータスクリストが単一のリストとして実現されることは稀で、たいていは複数のリストやシステムを指す。

たとえば GTD では Inbox や Someday といった複数のタスクリストが存在するが、これらをすべてテキストファイルで一行一タスクで記述し、かつすべてのテキストファイルを同じフォルダ内に格納すれば、これは「フォルダ単位で」マスタータスクリストになっていると言える。Grep を使えばすべてのタスクを対象とした検索が行える。

マスタータスク

マスタータスク(Master Task)とはマスタータスクリストに記述されたタスク。

マスタータスクにおけるタスクとはシードを指すことも多い。つまりタスクになりきれていない、タスクになりえるネタ(シード)である。

エントリータスク

エントリータスク(Entry Task)とは、素早く必要最小限な記述で記録されたタスクのこと。

タスク管理においては、発生したタスクをどのように管理し始めるかが一大テーマであるが、よくあるアプローチとして「とりあえず素早く書いておく」「そこは後で見返して改めてツールに投入する」という二段階式がある。この一番目の「素早く書いておく」によって書かれたタスクがエントリータスクである。

メリット:

デメリット:

フィジカルタスク

フィジカルタスク(Physical Task)とは何らかのタスクを発生させることが明示的な物品のこと。

フィジカルタスクを活用すると、いちいちタスクをツールに転記する手間を軽減できる。ただし「そのフィジカルタスクをいつ処理するか」はコントロールできないため、予定日や締切日を持つものをフィジカルのまま放置しておくのは望ましくない(予定日や締切日の前に処理する保証がない)。

フィジカルタスクの要件

ある物品がフィジカルタスクであるかどうかは人次第である。

ただし状況次第ではない。フィジカルタスクから発生するタスクは一意である。たとえばレシートというフィジカルタスクが「家計簿に転記する」というタスクを発生させる場合、このフィジカルタスクは常に「家計簿を転記する」というタスクを発生させる。その時その時で「家計簿に転記する」「妻に任せる」「捨てる」と他のタスクを発生させることはない。この性質は、以下のように言い換えることもできる。

ファーストタスク

ファーストタスク(First Task)とは「その日の、一番最初に実施するタスク」を指す。

より正確に言えば、以下のような前提を持つタスク。最も頭がスッキリしている「朝一番のタイミング」に、自分が取り組みたい(あるいは取り組むべき)タスクを一つだけ決めた時の、このタスクがファーストタスク。

ファーストタスクの目的は、自分にとって重要なタスクを毎日少しずつ切り崩していくことにある。一日数分でも良いので、とりあえず取り組んでみることで、不明瞭だったタスクがくっきりとしてくる。

例: 「オーロラを見に行く」

レスタスク

レスタスク(Restask / Rest Task)とは休憩、排泄、入浴、睡眠といった休息や気分転換に関する活動をタスクとして扱うこと、あるいはそのようなタスクを指す。

タスク管理をライフログ(のような高精度なログ)として用いる場合は、レスタスクも律儀に記録する必要性が生じることが多い。

不発タスク

まず不発について説明し、その後に不発タスクについて説明する。

不発

不発(Misfire)とは、あるタスク A に対して、A を実行しようとした時に、A を実行する必要がないと判明すること。

たとえば 2019/01/01 時点で「彼女の誕生日プレゼントを買う」タスクを 2019/02/20 に設定したとする(彼女の誕生日は 2019/03/01 とする)。ところが 2019/02/20 を迎える前に彼女と別れてしまったとする。2019/02/20 になると、このタスクを扱うことになるが、彼女はいないため、このタスクは実行する必要がない。

不発タスク

不発タスク(Misfired Task)とは不発になったタスクを指す。

不発タスクの対処として以下がある。

不発の誘惑

不発の誘惑(Misfire Trap)とは、不発タスクと遭遇した時に「代わりに別のことをやろう」と、その場で新たなタスクを設定すること、あるいは設定無しに即座に行動に移すことを指す。

不発の誘惑は、タスクを黙々と消化しているユーザーのコンテキストを妨害してしまう。新たなタスクを検討する、という検討のコンテキストに割り込みされると言っても良い。

不発の誘惑に対処するためには、意思で問答無用に無視するか、あるいは「代わりにやることを考える」といったタスクを作って放り込んでおくだけにする、などの方法がある。

A タスク

A タスク(A Task)とは記述が「あ」や「a」など露骨に手抜きされたタスク。名前の由来は、このタスクをつくる時にしばしば「あ」や「a」とだけ打つことから。

A タスクは「新しいタスクを思いついたけど、今やってるタスクを中断したくない」「でも思いついたこれを忘れたくはない」場合に用いる。つまり、記述を手抜きしたタスクをとりあえず登録しておいて、今の作業に戻る。あとで A タスクを見返した時に、少なくとも何も残さなかった場合よりは思い出しやすい。これが A タスクの意義。

A タスクには以下種類がある。

バッファタスク

バッファタスク(Buffer Task)とは見積時間を設定しただけのタスク。

バッファタスクの目的は、バッファ(時間的余裕)をタスク管理上で取り扱うところにある。たとえばデイリータスクリストをつくる際に、見積時間が 2 時間のバッファタスクを 1 つ置くことにすると、その日の終了時間は 2 時間ほど長くなる。しかし、これを前提としてデイリータスクリストを設計すると、最初から 2 時間分の余裕をつくることに繋がる。迂闊に見積がパツパツになってしまうのを防ぐことができる。

テンプレートタスク

テンプレートタスク(Template Task)とは複製することを想定したタスク。

同じタスクを多数作成する方法としてルーチンタスクがあるが、別の方法がテンプレートタスクである。元となるタスクを登録しておき(これがテンプレートタスク)、必要に応じてそれを複製してタスクをつくる。複製にかかる操作コストは新規操作よりも少ないため、楽にタスクを作成できるというメリットがある。

テンプレートタスクの例: 休憩タスク

凍結タスク

まずは凍結について説明した後、凍結タスク、そして凍結タスクリストについて説明する。

凍結

凍結(Freeze)とはタスクまたはタスクリストを Read Only にすること。

凍結の意義は「意味の局所化」にある。「パラメーターを編集できる」「タスクを追加・削除できる」という能力を意図的に削ぐことにより、意味をシンプルにし、扱いやすくすることができる。

凍結の利用例:

もし凍結を利用しない場合、以下の弊害が生じる:

凍結タスク

凍結タスク(Frozen Task)とは凍結されたタスクのこと。

凍結タスクは状態の変更も含めて編集することができない。たとえば「未完了の凍結タスク」を完了にすることはできない。

凍結タスクリスト

凍結タスクリスト(Frozen Tasklist)とは凍結されたタスクリストのこと。

凍結タスクリストはタスクの追加削除はもちろん、既存タスクの編集も一切行うことができない。

クローズドリストとの違いは、クローズドリストがタスクの追加削除のみを禁止しているのに対し、凍結タスクリストでは既存タスクの編集も禁止している点にある。

区切りタスク

区切りタスク(Separator Task)とはタスクリスト中の表示を見易くするために「区切り」として作成したタスク。

以下にシンプルな TODO リストにおける例を示す。区切りタスクが 2 つ作成されている。

==== ここから今日買うもの ====
たまねぎ x3
じゃがいも x1
にんじん x4
カレールー x2
牛乳 x4
ヨーグルト x1
==== 今日やる ====
カーテン張替え
洗濯
冷凍庫整理

条件付きタスク

条件付きタスク(Conditional Task)とはタスクの記述中に「そのタスクを実行するべき条件」を書いたタスク。

例:

条件を記述しておくことにより、あとでタスクを実行する際の判断労力を抑えることができる。特にルーチンタスクと相性が良く、ルーチンタスクの実行に対する抵抗感を下げることができる。つまり条件を満たさない場合に実行をスキップできる分、手間がかからない。

暗黙的な条件付きタスク

タスクには暗黙のうちに条件が付与されていることが多い。

たとえば「牛乳を買い足しに行く」といタスクを実行する際、機械的に必ず買いに行くのではなく、牛乳の有無をたしかめたり思い出したりするのが自然である。これは「もし牛乳があるなら買いに行く」という条件が暗黙のうちに存在するとも解釈でき、もっと言えばこのタスクが「不足しない程度に牛乳をストックしておく」という目的を持っていることを意味している(もちろん人によってはストック数によらず機械的に買いに行くことを想定していることもある)。

このような(暗黙的に存在する)条件情報を「暗黙的な条件」と呼ぶ。暗黙的な条件を持つタスクを「暗黙的な条件付きタスク(Explicit Conditional Task)」と呼ぶ。

暗黙的な条件の静的性質

「暗黙的な条件」は動的なパラメーターではなく静的なパラメーターである。つまり、あるタスク A に対して、ユーザーの気分次第で A の「暗黙的な条件」が出現したりしなかったりするのではなく、A の「暗黙的な条件」の有無は A を作成した時点で決定している。ユーザーが「暗黙的な条件」を読んだり読まなかったりするのは、単に「元から存在している “暗黙的な条件”」を素直に解釈するかスキップするかの違いであり、「暗黙的な条件」自体が現れたり消えたりしているわけではない。

暗黙的な条件の有無

あるタスク A に対し、「暗黙的な条件」が存在するかどうかはユーザーまたは状況により異なってくる。

「牛乳を買い足しに行く」というタスクを例にする。

小さな冷蔵庫のみを持ち律儀に賞味期限と気にする X さんの場合、「暗黙的な条件」は存在するだろう。「(もしストックが 2 本以内なら、上限である 6 本を超えない範囲で)牛乳を買い足しに行く」といった条件が隠れている。

一方、大きな冷蔵庫を持ち、賞味期限を気にしない Y さんの場合、「暗黙的な条件」は存在しないかもしれない。Y さんはとにかく牛乳を切らさなければそれで良く、一週間にせいぜい 4 本しか消費しないことがわかっているので、タスクはせいぜい「牛乳を(ちょうど 4 本だけ)買い足しに行く」程度であろう。

転送タスク

転送タスク(Forward Task)とは別のタスクリストまたはシステムを見に行くような指示を記述したタスク。

一般的にツールには、あるタスク A に関する情報をすべて収容する余裕がない。そもそもツールはタスク管理ツールであって情報管理ツールではないから、情報すべてを管理するには限度がある。しかし、タスク遂行に必要な情報が多量かつ多岐に渡ることは珍しくない。

そこでタスク A には「別の場所に保存してある情報 B を見ろ」という命令だけを記述していき、B 側で必要な情報を用意しておくというアプローチを取る。これが転送タスクである。

例: 10 のチェックリスト項目から成るタスク A の運用案

案 1 と 2 は転送タスクではない。どちらも 10 項目というボリューミーな項目を無理にタスクに押し込めようとしているため、タスク管理に手間がかかる。一方、案 3 と案 4 は転送タスクである。ボリューミーな項目を task_a.txt に外出しし、タスクとしてはこれを開くよう指示する。これならタスク管理はシンプルで済む。ただし、外出しした先に任せすぎると行動内容が曖昧になりがち(案3)なので、適宜具体化しておくと良い(案4では「開く」ことと「実施する」ことを分けている)。

タイニータスク

タイニータスク(Tiny Task)とはすぐに終了できるタスク。「すぐに」の定義はシステム次第。

例:

タイニータスクはタスク管理しないのが一般的である。理由としては、タイニータスクが実行コストよりも操作コスト・管理コストの方が高くつくことや、愚直にタイニータスクを洗い出し始めるとタスク数が膨れ上がることなどが挙げられる。つまりタスク管理の費用対効果が薄い。

～～としてのタスク

「～～としてのタスク(TAAx)」とは、タスクを～～として扱うこと。あるいはそのようなタスク。

例:

タスクの操作

基本操作

追加

タスクの追加(Add)とは新しいタスクをコンテナに追加すること。

編集

タスクの編集(Edit)とは既存のタスクのパラメーターを変更すること。

複製

タスクの複製(Copy)とは既存のタスクを複製すること。

移動

タスクの移動(Move)とはコンテナ A に含まれる既存のタスクをコンテナ B に移動すること。

同じコンテナ内の移動(表示位置の変更)はこの範疇ではない。

物理削除

タスクの削除(Delete)とは物理削除を意味し、既存のタスクを削除すること。削除したタスクを復元することはできない。

編集操作のエイリアス

よく使う基本操作あるいはその組み合わせに名前を付けたもの。

論理削除

論理削除であり、既存のタスクを削除すること。削除したタスクは復元できる。

移動のエイリアス。

アーカイブ

アーカイブ(Archive)とは既存のタスクを Read Only の領域に移動すること。

削除操作の代わりとして用意することが多い。この理由はディスクの仕様による。一般的に削除操作がディスクの当該領域を「削除したことにする」ことで擬似的に実現していることや、ディスクを用いたデータベースにおける削除操作のコストが高いことなどから、実装上は「物理的な削除は行わず、論理的に消したことにする」ことが多い。アーカイブは、その手段としてよく知られた概念であり、和訳のニュアンスとしては「書庫や倉庫への退避や保管」になる。

移動のエイリアス。

開始

既存のタスクを開始(Start)すること。開始時刻パラメーターに現在時刻を記入すること。

編集のエイリアス。

終了

既存のタスクを終了(End)すること。

実際の挙動はタスクが持つパラメーターによって異なる。

編集のエイリアス。

スキップ

スキップ(Skip)とは既存のタスクの実行日を未来日に変更すること。

スキップのニュアンスは「今日行うつもりだった(実行日が今日である)タスク」について、「実行するのをやめる」判断をし、かつ「そのタスク自体は実行が必要だから翌日以降に回す」というものである。したがって予定日の未来日への変更などはスキップではない。

編集のエイリアス。

内部パラメーター操作のエイリアス

基本操作のエイリアスではまかなえないが、よく知られた操作を取り上げる。

ロック

ロック(Lock)とは既存のタスクをタスクの所有者以外は編集できないようにする(Read Only にする)こと。

ロックは特に多人数利用を前提としたツールがサポートする。このようなツール上では、各タスクを複数人が編集できるが、当該タスクに関する議論が終了した後は編集は無用である。こういう時にロックを行い、以後の議論を行えないようにする。ただし、当該タスクの所有者のみは、メンテナンス等のために継続して編集できることもある。

例: GitHub Issues

凍結

凍結(Freeze)については凍結タスクの項を参照。

タスク管理界隈

タスク管理界隈とはタスク管理に関する分野、コミュニティ、エコシステムなどの総称。本記事では界隈と略す。

定義と権威について

2019/02 現在、界隈には世界的権威や統一的定義等は存在しない。界隈に認知された用語は、いずれも特定個人または組織によって発祥し、それが広まったものである。

歴史

界隈においてキーとなるパーソン、組織、書籍、ツールやサービスの公開や出現などを筆者主観で選定し、時系列で並べた。なお人名は敬称略とし、プロジェクト管理色の強いものは扱わない。

参考書籍

書籍

書名、著者名、言及内容を簡単に記す。順不同。

ウェブ資料

非公式には x を付与。

更新履歴

Back to the toppage.