Chapter 22
タスクの属性

2024.09.11に更新
このチャプターの目次
タスクには様々な属性があります。たとえば「名前」「開始日」「終了日」「優先度」「担当者」「タグ」などはすべて属性です。タスク管理的にはタスクとはnの属性を持つ項目と言えますし、属性を使ってソート（並び替え）やフィルタリング（抽出）も行えます。そもそもツールや手法ごとにどの属性を使うかが異なっています。
と、このようにタスク管理と属性は、実は切っても切り離せないものです。通常、意識することはありませんが、もし自分でタスク管理をつくったり、ツール上でカスタマイズしたりするのであれば知っておくと便利です。
本章ではタスクが持つ属性をリファレンス的に取り上げます。

 タスクの 3Aタスクは以下の 3 つから構成されます。
Attribute/属性
Arrow/関係
Attachment/機能
本章では属性について扱い、次節から解説します。本節では残る関係と機能について軽く触れておきます。3A を紹介するのにちょうどよいタイミングだったのでここで取り上げます。属性とは関係がないため、興味なければ読み飛ばしてください。

 関係関係（Arrow） とは他のタスクと関係――包含、参照、依存を扱ったものです。英訳が特殊に見えますが、矢印（Arrow）が向いているからだと考えてください。3A で揃えると覚えやすいため、少々強引ですがそうしました。
さて、関係はさらに 3P でまとめることができ、Parent-Child（親子関係）、Point（ポイント関係）、Pre and Post（依存関係）があります。
親子関係 は最も身近な関係です。親タスクに対して子タスクがぶら下がっているとか、タスク A にサブタスク A1、A2、A3 が存在するとかいった言い方をします。また粒度の面でも登場することがあり、たとえば「引っ越しをする」という粗いタスクは、分解すると「引越し先を洗い出す」「次の引越し先を一つ決める」「引越し業者を洗い出す」「引越し業者を決める」――といったようになるでしょう。
「引っ越しをする」
「引越し先を洗い出す」
「次の引越し先を一つ決める」
「引越し業者を洗い出す」
「引越し業者を決める」
……

これは 4 つの子タスクをつくったことに等しいです。このように親子関係は、タスク管理を知らない人であっても自然と行き着くくらいには自然なものです。網羅性を出したいときには重宝しますが、愚直で泥臭いため負担も大きいです。仕事以外ではやりたくない人も多いでしょう。
次に ポイント関係 ですが、これはリンクでつなげた関係です。タスク A からタスク B にリンクしたとき、A がリンク元で B がリンク先となります。リンク、もっと言えばネットワークの構造は、対人関係やインターネットのウェブサイトなど多くの場面で登場しますが、タスク管理ではあまり使われません。ありえるとすれば、Scrapbox や Obsidian などリンク機能を持つノートツールを用いてタスク管理を（も）行う場合です。たとえば「引っ越しをする」ページと「将来住みたいところ」ページがあったときに、前者のページから後者のページにリンクすると、以下のような関係になります。
「引っ越しをする」 → 「将来住みたいところ」
引越し先を絞り込むために、「引っ越しをする」ページから「将来住みたいところ」ページを開くかもしれません。逆になんとなく「将来住みたいところ」ページを見ているときに、被リンク一覧に「引っ越しをする」ページがあるのを見て「そうだよなー、そろそろ引っ越しを考えるか」と意識が変わるかもしれません。ポイント関係は、タスクとタスクをゆるく繋いでおいて、未来の自分が目にして何か化学反応を起こすのを待つといった使い方で重宝します。親子関係ほどの網羅性は期待できませんが、ゆるく始められるし続きやすいのがメリットです。実は、このノートベースのタスク管理はそれなりに奥深いため、本書でも後で一章分を使って解説します（文芸的タスク管理）。
最後に 依存関係 ですが、これはワークフローの文脈で使われます。タスク A は、タスク B と C が終わったあとに開始したい、といった場合、B,C → A のような依存をつくっておくのです。専用のツールを使います。すると、いきなり A を始めようとしても「まだ B や C が終わっていません」と警告してくれたり、自動化できるのであれば B と C が終わったときに自動的に A も終わらせたりできます。たとえば今忙しくしている案件 X が終わった後に引っ越しを済ませてしまいたい場合、案件 X の最後のタスクである「佐藤さんへの引き継ぎ」が完了した後に「引っ越ししたい！」タスクが浮上するようにしたいとして、依存関係を設定すると、以下のようになります。
現在のタスク:
・佐藤さんへの引き継ぎ

将来浮上するタスクと浮上条件
・引っ越ししたい！（条件="佐藤さんへの引き継ぎ" is done）
これで実際に「佐藤さんへの引き継ぎ」タスクを完了させると、「引っ越ししたい！」タスクが浮上するので「あ、そうだった、引っ越ししたいんだった」と気付けます――と、このとおり、依存関係は親子関係以上に関係の設定が面倒ですし、設定というよりもはや設計が必要なレベルですが、その代わり、上手く作れれば最も楽ができます。特に自動化との相性が良く、この手の機能はすでに様々なタスク管理で見られる他、IFTTT や Zapier のようなワークフロー専用ツールもあります。そうでなくともチャットツールでも他ツール連携は珍しくありませんし、ローコードやノーコードといった「パズルゲーム感覚でプログラミングを行う」潮流も来ています。これらの本質は「X → Y（もし X が起きたら Y をする）」の定義であり、連携元・先のツールが自動操作に対応している前提でそれらを上手く組み合わせることで X → Y → Z → A → B のように処理を連鎖させていくわけです。といっても、あなたが抱えているタスクを自動でこなしてくれるわけではなく、あくまで「自動操作に対応しているツール」同士をその機能の範囲内で連携・連鎖させるだけです。どんなピースが存在して、どう組み合わせられるかはちゃんと調べないといけません。これは実はプログラミングの本質でもあります。タスク管理というよりもプログラミングの両分なのです。本書でもこれ以上の解説はしません。

 機能機能（Attachment） とはタスクが持つ各種機能のことです。以下に例を挙げます。
コメント
添付ファイル
Attachment（添付）の英訳はここから来ています

チェックリスト
リマインダー
リアクション（いいね等スタンプをつけることができる）
機能を充実させたタスク管理ツールもよく見かけますが、これらはあくまで機能であってタスク管理ではありません。本書でもこれ以上の解説はしません。
一つだけ言っておくと、機能の利便性や世界観に惑わされて、タスク管理をするのだとの本質を見失わないようにしてください。まずは何も使わない前提で始めて、気になるものや便利そうなものを一つずつ試していくのが良いでしょう。合わなければやめればいいですし、良さそうならそのまま定着させれば良いだけです。いきなり全部を使おうとすると持て余してしまいます。
タスク管理ツールに限らず、ツールというものは私たちの心をつかむために機能を拡充させがちです。ふらっと誘われて、あれこれ真面目に試しているつもりでも、それはタスク管理ではない、ただの遊びにすぎません。趣味としてそうしたいのなら構いませんが、本当にタスク管理を行いたいのであれば、機能に惑わされないようにしたいところです（※1）。懐疑的な目を向けるくらいでもちょうど良いくらいです。機能よりも関係と属性に目を向けましょう。関係と属性を使って己のタスク管理をどうこなすのかを考えるべきなのです。
※
1 機能自体が害悪だとか有用ではないなどと言っているわけではありません。むしろ機能が主役級に有用であるケースもあります。たとえば（個人からは離れますが）パートナータスク管理ではチャットという機能は主役になります。


 属性詳細は次節で扱うこととして、ここでは定義と軽い説明だけ書きます。
属性（Attribute） とはタスクの構成要素です。どの属性を採用するかは、そのタスク管理ツールやメソッドの根本でもあり、開発者の腕の見せ所でもあります。
わかりづらいので例を見ます。タスクリストを考えましょう。
まずは属性として「名前」だけ採用してみます。以下のようになります。
- 引っ越しをする
    - 引越し先を洗い出す
    - 次の引越し先を一つ決める
    - 引越し業者を洗い出す
    - 引越し業者を決める
これは一見すると普通ですが、実はとても不便です。たとえば引越し先の洗い出しが終わったのでその旨を反映したいとしても、できないのです。なぜなら属性として「名前」しか使っていないからです。「終わったかどうか」は「名前」ではありません。
ですので属性をもう一つ追加しましょう。「状態」を追加します。なお状態として未着手・未完了の [ ] と、完了の [X] を使うとします。
- [ ]引っ越しをする
    - [X]引越し先を洗い出す
    - [ ]次の引越し先を一つ決める
    - [ ]引越し業者を洗い出す
    - [ ]引越し業者を決める
引越し先の洗い出しが終わったことがわかります。
次のタスクを行うとしましょう。ここでわからないことが一つ出ます。このタスクリストは上から順番にこなさないといけないものでしょうか？それとも順番は適当で良いのでしょうか？もちろん、そんなことはわかりません。属性がないからです。
というわけで属性を追加しましょう。「No」という属性を追加します。これは番号の意で、色んな意味をもたせられますが、ここでは「常に小さい順から実行しないといけない」「番号が同じなら実行順不同で良い」とします。
- [ ]引っ越しをする
    - [X] 1 引越し先を洗い出す
    - [ ] 2 次の引越し先を一つ決める
    - [ ] 1 引越し業者を洗い出す
    - [ ] 3 引越し業者を決める
1～3 の番号を振りました。洗い出し系は独立して行えるので 1 にしています。引越し先を決めるのは、洗い出しが終わった後じゃないとできないので 2 にしています。業者決めは引越し先も決まってから考えたいので 3 にしました。これを見れば、どれから取り組めばいいかがわかりやすいですね。
ここまでで 3 つの属性を採用しました。「名前」「状態」「No」です。これくらいならある程度実用的なタスクリストとして使えるでしょう。紙やテキストファイルに自分で書いて運用することもできますし、既存のタスク管理ツールで運用したり、自分でツールから開発したりすることもできるでしょう。いずれにせよ、名前、状態、No の 3 つの属性を意識しながら運用することになります。
もちろん属性はこれだけではなく、他にも多数あります。かといって全部を採用したところで持て余すだけです。特に各属性は値を入れたり更新したりといったメンテナンスが必要であり、属性が多いほど（できることも増える代わりに）メンテナンスコストも増えます。これを 属性のジレンマ と呼びます。要はトレードオフであり、重要なのはバランスです。自分にとって必要な属性だけをコンパクトに取り入れることです。

 読み方本章の残りでは、リファレンス的に各属性とその解説を行っていきます。

 二つの立場が混ざります解説には利用者としての立場と、開発者としての立場の両方が混ざります。明示的に区別はしませんので、読者の方で適宜読み解いてください。
利用者とは属性を使う者です。読んだり書き込んだり更新したりします。開発者とはタスク管理のツールやメソッドなどをつくる者です。どのような属性を選び、どのような見せ方をして利用者に使わせるのかを設計・実装する必要があります。

 1-段落 1-性質です内容については、1-段落 1-性質の形で並べていきます。段落が変わる度に話題が変わる（別の性質を述べる）ものと考えてください。箇条書き的に並べていると捉えても問題ありません。

 性質の他にプラクティスも解説します属性の性質を述べる以外に、扱い方や使い分けといったプラクティスも解説します。

 ===
 記述系属性タスクの内容を表現します。
表現には言語を用います。つまり言語化できないとタスクも表現できません。経験的に言語化されていないタスクをツールで管理するのは難しいと感じる人も多いと思います。言語化されていないタスクとしては物タスクなどがありますが、このようなタスクを管理するツールは現状ありません。将来的には画像管理ベースで、物タスクを可視化するような形のツールも生まれるかもしれませんが、仮にそんなツールがあったとすると属性は「画像系属性」等になるでしょう。本書では扱いません。

 名前/Nameタスクの名前。タスク名とも。
名前といっても表現は多用です。「引っ越し」「引っ越しをする」「将来住みたいところをリストアップする」「北海道について調べる」「都会と田舎の違いについてAさんに聞く」は全部名前です。単語に限らず文章でも良いですし、むしろ文章にして具体的にした方が扱いやすく取り組みやすいです。
名前の中に他の属性を持たせることがあります。たとえばtodo.txtは、理論的には「1行1タスクで名前を列挙したもの」であり、タスクとして 先方にお礼の電話をする と書くこともできれば、(A) 2017-07-14 先方にお礼の電話をする @phone +HogeProj と書くこともできます。後者は名前に優先度や実行日やタグが混ざっています。哲学的な話になりますが、「属性」なのか、それとも「名前（の中に書かれた属性）」なのか、の違いに正解はありません。一つの明快な定義としては、ツールの力で「属性を扱った処理（ソートやフィルタリング）」を行えるのだとしたら、それは属性です。逆に行えない場合、たとえば人間が読んで判断するだけであれば、それは属性ではなく名前です。
名前は通常、1行かつ100文字以内のテキストを想定します。複数行になったり、100文字（100という数字に大した意味はありません）を超えるような長いテキストは想定しません。長いテキストが必要な場合は詳細属性を使います。

 詳細/Descriptionタスクの詳細。タスクの記述とも。
名前は1行のテキストでしたが、詳細は複数行のテキストです。特にプロジェクトタスク管理のような本格的なツールで使われますが、個人レベルのタスク管理では持て余しがちです。
名前以上に他の属性も持たせることもできますが、複数行のテキストに書かれた属性を人間が見て判断するのには限界があり、容易に形骸化しますので推奨はされません。たとえば締切が 2024/07/22 だからといって、詳細属性の中に「2024/07/22 までお願いします」などと書くのは良くないです。属性を使いたければ、タスクの属性として別途きちんと扱うべきです。この場合は、締切日属性に 2024/07/22 を設定するべきです。
ちなみにコメントやノートといった機能がありますが、それは 3A における機能（Attachment）であって属性（Attribute）ではありません。機能は属性ほどタスクと紐づいていないので、タスク管理の最中には軽視されがちです。軽視されずにちゃんと扱いたいのであれば、よりタスクと密に紐づいた属性である詳細属性を使いたいです。しかし、そうは言っても、詳細属性自体が複数行のテキストとなり、文章量が多くなりがちで読まれづらいです。ベストプラクティスとしては、詳細はなるべく使わないか、分量を少なくするか、テンプレート化して読み書きの負担を減らす（統一化することで減らす）ことです。

 状態系属性タスクの状態を表現します。
状態とは「未着手」「進行中」「完了」といったもののことです。

 状態/Statusタスクの状態。英語では Completion や Done など「完了」寄りの意味で表現されることもあります。
状態が取りうる値は事前に定義されます。2値だとオープン/クローズ、3値だと未着手/進行中/完了、4値だと未着手/進行中/ペンディング/完了、5値だと未着手/進行中/ペンディング/完了/中止、となるでしょう。唯一の正解は無く、定義は様々ですが、理論的には「開始前」「開始後」「終了前」「終了後」の 4 ステップがあります。少し分かりづらいですが、進行中は「開始後」、ペンディングは「終了前」に属します。特に「終了前」がわかりづらいですが、これは「スムーズな進行を妨げる何らかの兆候が見られる（終了に倒れるかもしれない）」といったニュアンスですが、状態として表現するのは難しく、現在知られているのは保留中とか審議中とかレビュー中とかいったペンディングの概念です。
状態は少なくとも未完了と完了の 2 値を扱うのが望ましいです。特に完了したタスクにはもう用がありませんから、削除するなり、別の場所に退避（ログ化やアーカイブ化）するべきです。これを怠ると、タスクリストの中に未完了と完了が混ざってしまい、見る度にこれは完了したのかしてないのかといった認知コストを消耗します。部屋でたとえると、使っていないものを片付けずに放置したり、ゴミをゴミ箱に捨てずに机や地面に置いているようなものです。
状態の更新は頻繁に行う操作の一つなので、できるだけ少ない手間で行えるべきです。GUI の場合はクリックやタップ一回で行いたいです。テキストベースの場合は、多くても数回以内のキー入力で済ませたいですが、[ ]にXを追加して[X]にするなど追加する方式と、未完了に!がついているのを消せば完了になるなど削除する方式があります。更新を行わずに別の場所に移動させることもできますが、一般的には進捗（完了と未完了の比率）を見たいと思いますので、移動は少し時間を置いた方が良いです。日や週の単位がきりが良いでしょう。

 識別系属性タスク個々を識別します。

 IDタスクの ID。
ID があると同じ名前のタスクを複数扱えます。たとえばID=1の「引っ越しする」タスクと、ID=13の「引っ越しする」タスクは、名前は同じですが別物です。ID=13の方を「妹の引っ越しを手伝う」に変えたとしても、ID=1の方は変わりません。両者を別物として扱うことができます。しかし同じ名前のタスクを複数扱う用途は、タスク管理においてはあまりありません。ID はもっぱらタスクごとに専用のページをつくりたいときに使われます。逆に単に task.txt にタスクリストを書いているだけ、など個人でシンプルに運用している場合は出番がありません。
ID の表現方法は多用ですが、重複を防ぎたいのとプログラムで処理すればいいのとがあって、人間には読めない文字列になりがちです。利用者が目にする機会も通常はありませんが、URL を見れば載っていることがあります。あるいは #1 や #152 など連番が使われることもあります。

 番号/Numberタスクの番号。
番号は ID の一種ですが、「連番や連アルファベットなど連続した英数字である」ことと「順序性がある」のが特徴です。本質は順序性であり、番号が若いほど「先に実行するべき」とのニュアンスがあります。このニュアンスがなく、ただの ID として連番や連アルファベットを使っているものは番号ではなく ID です。
番号を用いたツールの好例はタスクシュートです。クラウド版でなく Excel 版の話です。かつ単純化した説明になります。タスクシュートではタスクを操作してはソートして並び順を維持する、という営みになりますが、このソートは単に行ごとに辞書順で並び替えているだけです。なのでタスクを意図した並びにしたければ、先頭に 001 とか 002 と番号をつければいいのです。昇順ソートの場合、番号が若い方が前に表示されます（かつ 00 のようにパディングして揃えるのがより確実です）。このようなソートを常に想定しているため、タスクシュートでは各タスクに自動で連番を振ります。しかし利用者が「これを前の方に入れたい」と考えて 001 などに修正すると、それはそのまま反映されます（なのでソートすると 001 のとおり前の方に並びます）――といった世界観となっています。これはテクニカルな例ですが、もっと単純な活用例を言えば、属性の項でも述べたように、手作業で番号をつけて運用することもできます。
番号が被ったときの対処は考えておいた方が良いでしょう。タスクシュートでは番号の次の属性を見る、となってます。属性の項の例では「どちらから実施しても良い」としています。

 日付系属性タスクに紐づいた日付を定めます。
日付の表記は様々です。240722、20240722、2024/07/22、2024-07-22、2024/07/22 (Mon)、2024年7月22日(月)、などはすべて同じ日付を示しています。ツールの場合は自動で読みやすい形式になると思いますが、手作業で運用する場合はなるべくシンプルな表記が使いやすいでしょう。デジタルであれば現在日時を自動で挿入する機能を使えば少しは楽できます。
曜日は通常含めません。年月日がわかれば曜日も自ずと計算できます。しかし私たちは曜日で時系列（過去現在未来）をはかるところがあるため、常に表示されていた方が読みやすかったりします。しかし、常に表示していると表示領域を圧迫します。特に1行1タスクで表示するようなツールや、スマホのような幅の狭い画面だと削らないとかえって見づらくなることが多いです。
※タイムゾーンなど高度な話題は本書では扱いません。それはプログラミングの両分となります。また本書ではJST――日本標準時のみを想定して解説します。

 実行日/Starting Dateタスクを実行する日。開始予定日とも。
たとえば 2024/07/22 であれば、そのタスクは 2024/07/22 に開始することを示します。
実行日が有効なのは計画と先送りです。まず計画については、大きな何かを成すためにまずはこれ、次はこれ、と小さく分解して一つずつこなすよう設計していくと思いますが、この小さなタスクを配置していくのに実行日を使います。タスク A は 2024/07/22、タスク B は 2024/07/23、タスク C は 2024/07/24 といった形ですね。この用途だと番号属性の意味合い、つまり順序性も事実上持つことになります。この例ですと、A → B → C の順に行うことが想定されていますね。次に先送りについては、Dailerの戦略がわかりやすいですが、日ごとにタスクリストをつくる運用がまずあったとして、このとき実行日を変えることで先送りができるという意味です。たとえば今日が 2024/07/22 だと、タスクリストには 2024/07/22 に行うタスクが並んでいるわけですが、そのうちタスク D を「今日はだるいので明後日くらいでいいか」と捉えたとします。捉えただけでは忘れてしまいますので、D の実行日を 2024/07/24 に変えます。そうしておくと、明後日 2024/07/24 のタスクリストに D が出現するので忘れません（忘れていても見れば思い出せます）。
いわゆるカレンダーは、実行日属性（としばしば開始時間属性も）のついたタスクを格子状に表示しているものと言えます。改めて言うまでもないですが、実行日をつけたタスクを週や月といった単位で俯瞰することは非常に便利です。これは実行日という概念を導入しているからこそ行えることです。俯瞰の方法は一つではなく、たとえばカレンダーを使わずに予定をリストで書いて管理したり、2024/07 のタスクを順序性を無視して表示したりといった方法も考えられます。タスク管理は本質的に個人的なものであり、合理的な手段だから続くとは限りません。続かないと意味がないわけで、続くのであれば多少非合理な方法でも実は構いません。あえてカレンダーではないトリッキーな俯瞰の仕方を構築することもアリなのです。筆者も一時期はカレンダーを使わず予定をリストで管理していた時期があります。とはいえ、合理性を考えるならば、やはり俯瞰はカレンダーか少なくとも順序性を保持してソートして表示するのがベストです。特にカレンダーを超える俯瞰方法をまだ人類は編み出していません。物好きでなければ、俯瞰にはおとなしくカレンダーを使うのがベストです。もっと言えば、もしお使いのツールにカレンダー機能がない場合で、それでも俯瞰したい場合は、何とかしてカレンダーに落とし込むべきだと言えます。カレンダービューを自製するか、既存のカレンダーツールとの連携（API）を調べて連携することになるでしょう。

 作成日/Creation Dateタスクを作成した日。作成したときの日付を記録する属性です。
個人タスク管理においては通常、この属性は不要です。強いて言えば、作成日を記録しておくことで、あとで取り組むときに「作成してから二週間も経ってるなー」など経過感を知ることができる程度です。一見すると、有益かもしれないと感じます。経過感がわかれば、たとえばある程度経っているとわかったら優先度を上げるなり、逆に要らないと判断して消すなりできるからです。しかし、そういった判断をいちいち行うのは認知コストを食います。筆者としては使わなくて良いと考えます。認知コスト節約の方が大事です。
作成日属性は、自動化が前提であれば重宝することもあります。まずツール側で自動で記録するのであれば利用者のコストはありませんし、現在日時との差分（何日経過したか）も自動で計算できるのなら、ワークフローに組み込めます。要は「n日以上未着手であれば催促する」あるいは「用がないとして削除する」といった処理を実現できるのです。扱うタスクの量が多くて未着手のまま放置されることが多い場面では役に立ちます。が、個人タスク管理レベルでは通常はないと思います。逆にプロジェクトタスク管理では珍しくありません。特に GitHub などオープンソースの文脈で、活発なソフトウェアになると毎日何十という Issues が発行されますが、メンテナーは限られておりいちいち整理などしていられません――というわけで Bot という自動巡回プログラムをつくっており、「14日間誰からも返事がなかった Issue は自動的に閉じる」といったことをしています。

 締切日/Due Dateタスクの締切。完了予定日とも。
締切という言葉が指すニュアンスは利用者次第です。目安程度の軽さもありえますし、基本的に厳守であり守れないなら報連相が必要ですねもありえます。
個人タスク管理では形骸化しがちな属性です。実行日属性を使って代替できるからです。たとえば 2024/07/22 が締切のタスク A があるとしたら、締切日=2024/07/22 と設定すると思いがちですが、実は実行日=2024/07/22 でもまかなえます。要は締切当時に行えば良いわけです。ここで「いやタスク A は実行に数日以上かかる大きなタスクなんだよ、実行日にしちゃうと 22 日当日しかできないじゃないか」と思われるかもしれませんが、そもそもそんな大きなタスクは分解するべきです。たとえば A1, A2, A3 の 3 つに分解できたとして、それぞれの実行日を 2024/07/19、2024/07/20、2024/07/22 とします。もちろん A1～A3 は 1 日以内に終われる程度の大きさです。このように分解をうまく行えるなら締切日は要らず実行日で代替できるのです――と書きましたが、原理的にはもちろん締切日属性を使って律儀に締切を意識することも可能です。十中八九形骸化するでしょうが……。意識ほど脆いものはありません。
締切日属性が重宝するのは、プロジェクトタスク管理など本格的な管理を行うときです。このような場面だと、通常は綿密な計画が立てられ、タスクごとに締切が引かれて全体の流れが設計されます。締切日が設定されていれば「あと 2 日しかないのに進捗が乏しいから追加でフォローしよう」といった調整も行いやすくなります。この性質上、タスクを締切日でソートして俯瞰する機能も事実上必要です。一方で、現代では計画にあまり頼らず、軽めの仮説検証を繰り返すアジャイルなスタイルも台頭しており、この場合は締切日属性は無用です。アジャイルはたいてい「今週は何するか」「次の二週間では何をするか」など週単位で捉えるので、実行日ならぬ実行週属性なるものが使えれば事足ります。2024 年現在、実行週属性を扱ったツールはないと思いますし、本書でも解説はしませんが、GitHub Issues のマイルストーン機能など近しいものはあります。

 完了日/Completion Dateタスクを完了した日。終了日とも。
完了日があると振り返りに役立ちます。前提としてサイクルを回している必要があります（週単位でまわすアジャイルの例は前述しました）――つまり一サイクルごとに振り返る際に、この完了日属性を使って（振り返りで使う）インプットを計算します。たとえば締切日属性と比べると締切をどれだけ守れたかがわかりますし、作成日属性と引き算すれば経過がわかるので、たとえば平均して何日経過して終わらせたか等がわかりますし、実行日属性があるなら当日完了した率もわかります。ただし表面的に比率を求めたところで、せいぜい目安にしかなりません。調子が悪ければペースなどかんたんに乱れますし、かんたんなタスクが多かったり逆に難しいタスクがあったりした場合などでもばらつくからです。それでも、生産性を読みやすい「作業」系のタスクが多い場面では役に立ちます。いずれにせよ、少なくとも他の日付系属性を用いた計算を要するのが大変です。その機能がツールにないか、あるいは自分で手計算する手間を負えないのであれば、完了日属性は意味がないので無視して構いません。
完了日属性は状態属性の代替になりえます。つまり、完了日属性が記入されたことをもって「状態=完了」とみなせます。再びtodo.txtの話になりますが、このメソッドでは YYYY-MM-DD YYYY-MM-DD ティッシュ箱を買う のようなフォーマットを使うことができます。前の日付が完了日で、後の日付が追加日です。たとえば 2024-07-22 2024-07-18 ティッシュ箱を買う とあるなら、ティッシュ箱を買うタスクを 18 日に追加して、22 日に終わらせたことがわかります。

 時刻系属性タスクに紐づいた時刻を扱います。
単に操作日時を記録する用途ではないことに注意してください。時刻系属性の目的は日付系属性よりも――つまり日の単位よりも細かい単位で管理することです。時、分、秒という細かさで管理したいからこそ導入します。逆を言えば、日単位で済む程度の融通があるのなら時刻系属性は要りません。

 セクション/Sectionタスクを実行する時間帯。
セクションは実行日ならぬ「実行時間帯」だと捉えて差し支えません。実行日属性は時間軸を日単位で区切って、日ごとにタスクを配置することで扱いやすくするものですが、この単位を少し細かくしたのがセクションです。もう少し細かくすると開始時間属性になります。つまり単位として日、時間帯、時・分・秒の 3 種類があって、セクションは 2 番目の単位を示しています。あまり一般的な単位ではありませんが、人には生活リズムがあり、生活リズムはセクションから構成されていることが多いです。詳細はコンテナの章を参照してください。
セクションが取りうる値に正解はありません。わかりやすいのは朝/昼/夕方/夜ですが、これだとたいていは粗すぎます。セクションは生活リズムと結びついており、自分にとって最適なものを定義するべきです。たとえば会社員であれば出社前/出社中/出社後午前/昼休憩/午後1/午後2/退社中/退社後/就寝前くらいの粒度になるでしょう。また平日と休日でも変わってきますし、旅行や出張など普段と異なる生活パターンになれば当然壊れます。雑に扱いたい人は就業中の時間帯を「会社」という単一のセクションに押し込めてしまうこともできます――と、運用はどうとでもできますので、セクションの値は自在にカスタマイズできるようにするべきです。
セクションを取り入れたツールの例はタスクシュートです。

 開始時間/Staring Timeタスクを開始した時間。
※本項ではタイムトラッキング全般の話も扱います。
開始時間は終了時間属性とともに用いられ、そのタスクにかかった時間を計算するのに使います。計算は単純で、終了時間から開始時間を引くだけですので、自動計算のないアナログなタスク管理でも（面倒ですが）不可能ではありません。しかし、タスクを始めたり終わらせたりするたびに記入や計算を行うのは思っている以上に面倒であり、容易に形骸化に繋がりますので、できる限り自動化するべきです。現状の最適解は、ボタンを一回押す程度の手間で開始する（開始時間を記録する）ことです。あと数年すれば音声でも問題無く開始できる水準が手に入り、そのようなツールも登場すると思います。
開始時間属性によりタスクにかかった時間を計算できますが、それだけでは意味がなく、計算結果を俯瞰して振り返りに役立てる必要があります。この分析や可視化も手作業でつくるのは大変なので、通常はツールの機能に頼ります。この用途に特化したジャンルがタイムトラッキングであり、Togglなど専用ツールがあります。通常のタスク管理ツールでもサポートしていることがあります（タスクシュートなど）。また、タスク名をいちいち指定させず、単に開始と終了の記録だけを取るタイマーのジャンルもあり、ポモドーロ・テクニックが有名です。
並列実行――同時に複数のタスクを開始する場合の取り扱いは、事前に検討しておくべきです。通常は並列実行は許可しないか、少なくともツールのコンセプトとして想定しないことが多いです。というのも、並列実行を認めてしまうと、後の計算や分析に支障が生じるからです。たとえば朝9時から12時の間は3時間ですが、並列実行していると3.3時間とか、雑な記録だと4.5時間になったりしてめちゃくちゃです。あえて言うなら自分のマルチタスク具合を可視化する用途としては使えますが、そもそも並列実行のすべてを律儀に記録する（開始と終了の二回、かつ開始時はおそらくタスク名の入力も必要）ことができずに形骸化します。並列実行するシチュエーションそのものが忙しいがゆえに、記録する暇や余裕が普段より無いという点も拍車をかけます。
扱う単位としては秒レベルが望ましいです。というのも、開始と終了が一分以内に終わるケースがあり、秒レベルで扱えていないとここの記録が粗くなる（かかった時間が 0 分になるか 1 分になる）からです。特にタイムトラッキングのように細かく行動を記録するシチュエーションだと、一分未満に終わったタイニーなタスクが十数個以上存在することがあります。仮に 15 個だとすると、最大 15 分もの誤差になります。内部的に秒で管理していると、秒レベルの計算で正確にわかります。しかし、表示時に秒まで出すのは細かすぎてノイジーですので、表示は分が良いでしょう。一方で、神経質な利用者だと秒レベルで見たいことがあります。理想を言うと秒と分、どちらも切り替えられるようにしておくことです。

 終了時間/End Timeタスクを終了した時間。
連続的にタスクを行う前提であれば、次のタスクの開始をもって現在のタスクを終了させることで終了操作を省力化できます。たとえばタスク A を 10:37 に開始し、11:03 にタスク B を開始した場合、A は終了したとみなして終了時間を 11:03 にしてしまえば A の終了操作は不要です。
終了時に追加のアクションを行うどうかは設計しておくべきでしょう。たとえばタスクシュートは「行う」コンセプトであり、その場で感想や振り返りを記入できるようになっています。一方で、タイムトラッキングツールでは「行わない」がメインであり、あくまでもタスクの実行と開始終了の記録に専念します。一つの目安として、定量的な記録を用いて分析したい場合は「行わない」が良く、定性的な感想も入れたい場合に新鮮な感想をすぐ書きたいなら「行う」が良いです。
その他省力化に繋がる操作を検討できる余地があります。たとえば「このタスクをもう一度開始する」ボタンや「今日終了したタスクを選択してもう一度開始する機能」があれば、同じタスクを即座に開始できて便利でしょう。共通するのは終了という操作が契機になっていることです。タスクの終了とは終了時間を記録することですので、終了時間の記録は次のタスクを行う直前のタイミングでもあると言えます。次のタスクの選択・開始をシームレスに上手くサポートできたら、グンと快適になるのです。開発者の腕の見せ所でしょう。
キャンセルタスクの扱い方も検討しておきたいです。キャンセルタスク とは開始したタスクを取り下げること、特にその取り下げることになるタスクを指したものです。開始時間を消してその名のとおりキャンセル（実行しなかったことにする）するか、あるいは終了時間を記入していったん終わらせるか、のどちらかに対処が必要です。どちらを選ぶかは利用者の好みになりますが、キャンセルタスク自体も情報の一つであり、分析時に把握できると便利ですので、可能ならツール側で支援したいです。たとえば上述した追加のアクションとして「キャンセルマークをつける」機能があるとワンタッチでキャンセルできて便利ですし、あとで振り返るときも区別できます。そうでなくとも終了時にメモを記入させる設計であるなら、メモとしてキャンセルの旨を書くことができます。

 見積時間/Estimation Timeタスクにかかる時間の見込み。Expect Timeとも。
見積時間属性の目的は、タスクの見積もりを行うことです。開始時刻属性と終了時刻属性により「かかった時間」がわかります（実績時間）が、それだけでなく、開始前に見積時間を定義しておくことで予定化・計画化に役立ちます。たとえばタスク A、B、C をこの順で、30 分、45分、45分で終わるものと見積ったとします。つまりA、B、Cの 3 タスクを 2 時間で終わらせたいという計画です。この後、タスクをこなして開始と終了を記録していくと、実際かかった時間がわかります。仮に 40分、50分としましょう。この時点で 1.5 時間かかっており、タスク C は予定では 45 分かかるが残りは 30 分しかない、まずいかもしれない、とわかります。見積もりは奥深いジャンルであり、本書でもこれ以上は扱いませんが、タスク単位で見積もりを行うためにはこの見積時間属性が必要です。
デイリータスクリスト上のタスクすべてに見積時間を設定すると、「今日のすべてのタスクがいつ終わるか」がわかります。終わりが見えるため精神衛生を保つのに重宝します。逆を言うと、扱うタスクのすべてに、あるいは少なくとも一連の連続したタスクのすべてに対して見積時間を設定しないと意味がありません。たとえば午前中にタスクが A～H の 8 個あったとして、C の部分だけ見積時間を記入して見積もりができたとしてもさほど意味はないでしょう。少し極端に言うと、All or Nothing です。All ができないのなら見積時間はスルーした方がマシです。ツールの例としてはタスクシュートがあり、現在のクラウド版はわかりませんが、Excel 版の時代では一コンセプトとして強調されていたと記憶しています。

 実績時間/Actual Timeタスクの実行にかかった時間。
開始時間属性と終了時間属性から求めることができます。もっと言えば、開始時間の記録と終了時間の記録から求めることになりますので、記録の仕方に問題があれば現実と乖離します。たとえばタスク A を 13:10 に終了したのに終了操作（終了時間の記録）を行わず、あとあと 14:00 に気付いて終了したとすると、記録上は 50 分多めにかかったことになってしまいます。もちろん「実際は 13:10 くらいに終わってたから……」と修正するのも面倒なことです。

 定期系属性タスクを繰り返し実行するための設定値を扱います。
タスク管理では、繰り返し行うタスクをルーチンタスクと呼びます。ルーチンタスクは出現の仕方が指定されたタスクです。たとえば 2 日に 1 回行うタスクであれば 2 日ごとに出現しますし、毎週水曜日であれば毎週水曜日にのみ出現しなくてはなりません――と書いてもわかりづらいですが、前提としてデイリータスクの概念を使っている必要があります。実行日属性の項では「日ごとにタスクリストをつくる運用」と表現しました。その上で、じゃあどの日に出現させるのかを制御するのがルーチンタスクです。つまり定期系属性とはルーチンタスクを管理するための属性です。
ルーチンタスクを実際にどのように出現させるか――もっと言えばどのように設置するか、には複数の方法があります。最もわかりやすいのはカレンダー等に見られる Set all firstly 方式であり、一度定期系属性を設定しただけで、該当するすべての日にタスク（カレンダーの場合は予定）が刻まれます。ですので「この日だけはスキップしたいから消す」といった例外対応もやりやすいです。次にタスクシュートなどが採用している End and Set 方式は、終了した（終了時間を記入した）ときに、次のタスクを生成します。2 日に 1 回行う設定なら 2 日後にのみ作成します。カレンダーのように高度に抽象化されたツールですと Set all firstly 方式にて無限に広がる未来のすべてに設定できるのですが、ツール上そうもいかない場合はこの End and Set 方式で直近にのみ設定することになります。他にもHabiticaや習慣トラッカーなどが採用する Counter 方式があり、これはとりあえず毎日出現させるというものです。やるかやらないかは利用者が決めて、やったのならその旨を記録します。ルーチンタスク管理では力不足ですし、いちいちやる・やらないを判断するのは認知コストを酷使するため疲れますが、最もわかりやすい方法ではあります。
以下に 3 つの方式の特徴をまとめておきます。
ルーチンタスクの設置方式
Set all firstly
定期系属性の設定値に基づいて、該当する未来日すべてにタスクを設置する
カレンダーなど抽象化しやすいツールでは使える

End and Set
タスク終了時に、定期系属性の設定値に基づいて、次のタスクのみ設置する
Set all firstly 方式が使えない場合はこの方式でしのぐ

Counter
とりあえず毎日表示して、実行するかどうかは利用者に任せる
定期系属性を使わないシンプルな方式だが、ルーチンタスク管理には力不足


タスク A をある日 D に出現させたい場合は、A の実行日属性を D にします。たとえば今日が 2024/07/24 水曜日で、「可燃ごみを捨てる(@毎週月金)」ルーチンタスクがあった場合、このタスクの次の実行日は 2024/07/26 金曜日になります――と、ルーチンタスク管理を行うなら（開発者だけでなく）利用者もこのような考え方を心がける必要があります。この考え方ができて、はじめてルーチンタスクを自在に操れるようになります。たとえば今週の金曜日のごみ捨てをスキップしたい場合、「実行日 2024/07/26 の可燃ごみ捨てタスクを削除すればいい」と捉えなければなりません。そうしないと実際にツール上にタスクの情報を反映できないからです。

 繰り返し頻度/Repeat Frequencyタスクを出現させる頻度。
繰り返し頻度は「n 日ごとに x 回行う」との形で記述できます。たとえば「1日1回（毎日）」「2日に1回」「7日に1回（週に1回）」などです。x は通常 x=1 のみを想定するのが良いです、というのも管理上扱いやすいからです。「1日に2回」など日よりも密な頻度を表現したい場合は、単に「1日1回」のタスクを 2 個つくります。2 個つくったタスクをいつやるかは時刻系属性も使って制御してください。繰り返し頻度含む定期系属性はあくまで日以上の単位を扱うべきです。この棲み分け、いわば役割分担を徹底することで、タスク管理が煩雑にならずに済みます。
繰り返し頻度には表現力に限界があります。たとえば毎週末（毎週土曜日と日曜日）、毎月30日、月末、第 2 水曜日といった頻度は、繰り返し頻度属性だけでは表現できません。あるいは End and Set 方式で設置したタスクの実行日を都度修正する手間が発生します。この表現力を使いたいなら、後述の繰り返し条件属性を使ってください。

 繰り返し条件/Repeat Conditionタスクを出現させる条件。
繰り返し条件属性は、繰り返し頻度属性では表現しきれない細かい頻度を実現するために使います。
利用者に対してはわかりやすい見せ方をする必要があります。開発者の腕の見せ所ですが、一から考える必要はなく、既存のカレンダーツールの「定期タスク」の設定画面を見れば事例はすぐに集められます。たとえば「毎週水曜日と金曜日」のような頻度を指定させるには、月から日まで 7 つのチェックボックスを並べて、出現させたい曜日にチェックをつけさせる――といったインタフェースが使われています。一方で、設定画面は全体的に煩雑になりがちで、（一度設定したら終わりな）予定の管理はまだしも、（一日何十回何百回と操作する）ルーチンタスク管理として使うには厳しいものがあります。
繰り返し条件は、開発者としては負担が大きい属性です。複雑な日付計算を負うことになりますが、日付計算ライブラリだけでは足りない可能性があります。特に「第三水曜日」や「会社休日」など文化固有、組織固有の表現や制約も混ざってくると自製する手間からは逃げられなくなります。仮につくりこみが甘くて、本来出現するべき日に出現しなかったなんてことがあっては大問題ですから、品質のつくりこみやテストも大変です。そもそもルーチンタスク管理などという神経質な管理は（鉄道の正確性にも見られるように）日本的な文化であり、世界的に見てもマイナーだと感じます。どこまでつくりこむかにもよりますが、繰り返し条件属性を用いた本格的なルーチンタスク管理ツールをつくりたいのであれば、（2024/07 現在では）自らつくって品質を担保する手間を負うことになると考えてください。
繰り返し条件として有用なものの一つに Manual Listup があります。これは出現させたい日を利用者に選択させるものです。たとえばカレンダーを表示して、出現させたい日を選択させます。既存の繰り返し条件や繰り返し頻度を使って事前に選択させておき、気に入らないところだけ追加や削除させると（一から全部選択する手間がなくて）なお良いでしょう。この方式の主な問題点は利用者に選択させる頻度とその周知ですが、頻度は週一か月一のいずれかにして、かつ忘れないようツール側でリマインドさせると良いでしょう。

 分類系属性タスクの性質を表現します。
分類系属性の目的はフィルタリングを可能にすることです。タスク A に分類項目 X を付与すると、「X が付与されている」という条件で A を（もちろん他にも X が付与されたタスクも）洗い出すことができます。タスク管理ではしばしばタスクの数が何十、何百、下手すると何千にもなるので、このようにフィルタリングできることは重要です。
3A における関係（Arrow）は扱っていないことに注意してください。カテゴリーなど一見すると包含関係を扱ってそうな名前に聞こえますが、関係における親子関係では タスクがタスクを 包含（同族包含）するのに対して、属性における分類系属性では 分類項目がタスクを 包含（メタ包含）します。同族包含ではフィルタリングよりも関係の可視化を重視します。メタ包含では前述のとおり、フィルタリングを重視します。
他の属性を分類系属性として使うこともできます。たとえば日付系属性は、日付という分類項目が付与された分類項目と呼ぶこともできます。しかしこれはあくまで（本来別の用途として存在していた）時間軸的情報を、ついでにはフィルタリング用途としても使うというだけの話です。フィルタリングの便宜は限定的です。一方、分類系属性は、時間のみならず他の体系や、それこそ言語そのものも使いますので、分類項目が非常に柔軟です。あまりに柔軟すぎて、適切に採用・運用できなければすぐに形骸化してしまいますが、それは利用者の問題でありタスク管理ツールの問題ではありません。ここに踏み込みすぎると、タスク管理ツールではなく情報整理ツールとなってしまいますので開発者は注意しましょう。
分類系属性はアナログなツールでも使うことができます。バレットジャーナルでは項目の先頭にアイコンをつけることで意味を付与します（ラピッドロギング）し、あな吉手帳術では「夫がいないときにできること」エリアをつくって、そこにタスク（を書いた付箋）を貼り付けておくといったことができます――と、マークをつけるなり領域で区切って集めるなりすれば分類系属性の付与と同等のことを実現できます。
その他詳細はコンテナの章も参照してください。

 カテゴリー/Categoryタスクに 1 つだけ付与できる分類項目。
カテゴリーとはタグの一種であり、タスクに 1 つしか付与できないタグだと考えて差し支えありません。したがってカテゴリー C を削除しても、C の付与されたタスクは削除されません。これが関係（例: 大タスクに包含された中タスク）であれば削除されますが、分類系属性としてのカテゴリーはただのタグであり付与なので、タグという付与が外れるだけです。逆を言えば、削除が連動されるような「入れ物」を実現したいのなら、分類系属性としてのタグではなく、関係としての親子関係を使うべきです。
カテゴリーは自由に CRUD（作成・参照・更新・削除）できるようにするべきです。何のカテゴリーをどれだけ使うかは利用者次第であり、利用者が自ら CRUD していくことになるため、かんたんに CRUD できる方が便利だからです。一方で、カテゴリーはタグとは違って乱用するものではない（後述）ため、あえて CRUD のハードルを上げるのもアリです。
カテゴリーの CRUD は乱用するべきではありません。巷に存在する「分類」と呼ばれる体系がそうであるように、カテゴリーとは事前に注意深く設計した上で採用し、厳格に分類していくものです。タスクに 1 つしか付与できないという制約もそのためです。タスクをどのカテゴリーに入れるかを厳選するべきなのです。これは厳選が正しいと言っているのではなく、単にスタイルの問題です。カテゴリーという分類項目は厳選に基づいた分類を行う体系だ、というそれだけの話です。この厳しさを許容できない場合は、タグを使ってください。

 タグ/Tagタスクに単一また複数付与できる分類項目。
タスクには複数のタグをつけることができます。近年では SNS において投稿物にハッシュタグを付けますが、概念的にはこれと同じです。対象の性質を示す札（Tag）を貼り付けるイメージです。
タグはたくさんつけた方が良いと思われがちですが、タスク管理においてはそうではありません。たくさんつけた方が良いのは、SNS などアクセス数を稼ぐ文脈に限った話です。タスク管理は違います。目的は前述のとおり、フィルタリングにありますので、実際にフィルタリングできなければ意味がありません。「～～に当てはまるタスクを知りたい」というときに、「～～」に相当するタグ（の名前）をすぐに思いつけるか、または発見できるかどうかが重要となります。ですので、たくさんつけていると、タグ個々の印象が薄くなって思い出しづらいですし、一覧から探すにも大量になって混乱します。カテゴリーほど厳選する必要はありませんが、無闇につければ良いというものではありません。一つの意識としては、タグを新しく作成する、タグ名を変更する、タグを削除するときに毎回軽微なお金がかかるとしたら、を考えてみることです。10 円でも 20 円でも 50 円でも構いませんが、蓄積すれば下手なサブスクに至るような金額です。それくらいお金がかかるとしたら軽率なことはできず、多少は慎重になると思います。と、これくらいの意識が望ましいのです。
理論的には属性はタグで表現できます。なのでツールがサポートしていない属性を使いたい場合でも、タグがサポートされているなら擬似的に再現できます。たとえば実行日属性ならぬ実行月属性なるものを実現したいとするなら、単に 2024/07 や 2024/08 といったタグをつくって付与するだけです。2024/07 のついたタスクは「実行月=2024/07」と解釈でき、2024/07 タグでフィルタリングすることで表示できます。もちろん、「2024/07 以前のすべて」のような高級な処理は行えません（あるいは 2024/07、2024/06、など該当するタグすべてを指定してフィルタリングする必要がある）。とはいえ、このような手動の運用は手間であり、容易に形骸化します。サポートしていない属性をタグで再現するよりも、サポートしているツールを探して使った方が確実です。元のツールに離れられないくらいの愛着がある場合は、元のツールと、そのサポートしたツールの 2 ツールを使い分けることになるでしょう。一見するとこちらの方が手間ですが、手動運用の面倒くささによる形骸化は非常に手強いです。この手ごわさを減らせるツールがあるなら（新しく導入してでも）使った方が良いのです。

 ラベル/Labelタスクに単一また複数付与できる分類項目。
ラベルは色付きタグです。ラベルにはラベル名とラベルカラーがあり、視覚的に識別しやすくなっています。
ツールの例としてはGitHub Issuesなどの BTS です。重大なバグには赤色のラベルを、重複したイシューや対応不要に倒したイシューには灰色のラベルを、といったように色のニュアンスを尊重しながら付与すると、視覚的な識別のしやすさがグンとあがります。
ラベルはタスクの分類を素早く認識するのに便利です。医療現場におけるトリアージも黒・赤・黄・緑の四色に分けており、たとえば黒色を見るだけで一瞬で「既死」「蘇生の可能性がない」と判断できます。文字で「死亡」と書かれたものを読むよりも素早く判断できることは容易に想像できるでしょう。人は一般的に言語よりも非言語（色はこちらです）情報の方が素早く認識できます。とはいえ、個人タスク管理において、このレベルの素早さが求められることは稀だと考えます。あるとしても、プロジェクトタスク管理として非常に慌ただしく、かつ大量のタスクを扱っていて、秒単位で素早く動くことが求められるようなシチュエーションでしょう。トリアージはまさにその例の一つです。
ラベルは色付きタグとして使うべきです。つまり色による視覚的な識別のしやすさ、特に早さを重視するために使います。ツールによってはフィルタリングを備えていることもありますが、タグ属性のように扱うと（フィルタリングと色の 2 つの観点を扱うことになるので）かえってノイジーです。フィルタリングを行う場合は色無しのタグ属性を、そうではなく一覧から視覚的に探したい場合はラベル属性を、という形で使い分けることを推奨します。もしタグ属性がなくラベル属性のみがある場合は、ラベルの一部をタグとして使うと良いでしょう。たとえば白背景黒文字のラベルをタグとして使う、などです。

 スター/Starタスクに 1 つだけ付与可能な、カスタマイズ製のない分類項目。ブックマークとも。
カテゴリーは利用者により CRUD できましたが、スターはできません。スター属性は単に印をつけておくものであり、つけたかつけてないかの二値となります。こうしておくと、あとで「スターがついているタスク」をフィルタリングできます。能力的にはカテゴリーの下位互換ですが、CRUD さえさせないシンプルさが特徴です（スターは常に一つであり、たとえばスター1とスター2の二つをつくって使い分けよう、といったことはできません）。
ツールの例としては、タスク管理よりもシンプルなツールによく見られます。たとえば Slack などチャットツールにはメッセージをブックマークしたり保存したりする機能がありますが、これはスターをつけているに等しいです。あとでブックマーク一覧や保存メッセージ一覧を見ることで確認できます。スターをつけて、一覧画面で確認する――非常にシンプルです。タグはもちろん、カテゴリーよりも表現力は乏しいですが、これだけでもそれなりには便利です。
スターの典型的な利用例はインボックスです。「あとで読む」や「未読」の概念はよく知られています。これらは原理的には「あとで読む」マークや「未読」マークをつけておき、マークのついたものをフィルタリングしているだけ、とスターそのものです。
スターはシンプルですが、形骸化しやすい属性でもあります。原因の大半は外すコストの高さです。「あとで読む」「あとでやる」といった用途でスターを用いている場合、あとで読んだりやったりした後はスターを外す必要がありますが、このコストが馬鹿になりません。たとえスターを外すというワンクリックの操作であっても面倒くさいのです。そのためメールやチャットのように自動で外す（未読は一度でも読むと自動で解除されます）ようにして、未読にしたいなら利用者の側で明示的に行わせるのが望ましいです。利用者の心理として「勝手に外されたくない」「自分の意志で操作して外したい」と思いがちですが、実際は外すコストが高くて外さなくて形骸化してしまうため、この心理には従わないでください。どうしても自分でやりたい人向けには、「自動で外すのやめる」のような設定を入れておくと良いでしょう――と小難しく書きましたが、これらはすべてメーラーが実装しています。開発者としてスター属性を扱う場合、メーラーの設定やインタフェースを参考にしてください。よりモダンなもの（特にすっきりした見せ方など）がほしければチャットツールや SNS も参考になりますが、筆者としてはメーラーの方が勉強になると感じます。メールはメッセージというよりもタスクに近い概念であるため、メーラーには（スターに限らず）タスク管理に必要なエッセンスが色々と盛り込まれています。ただ詰め込み方や見せ方が上手くないだけです。
カテゴリーやタグでスター属性を代替することもできますが、あまり望ましくはありません。既に述べたとおり、スターはシンプルさと素早さ、特に外す部分を自動化するレベルで最適化したいため、カテゴリーやタグでは力不足になる可能性が高いです。タグの項でも述べましたが、お使いのツールがスター属性をサポートしていなくて、かつそれでもスターを使いたい場合、代替よりも「スターをサポートした別のツール」をさらに使った方が定着しやすいです。心理的には代替的であっても今のツールで使いたいと考えがちですが、力不足な代替では形骸化しやすく定着しません。直感には反しますが、しっかりとサポートされたツールを（新たに増やしてでも）使った方が、最終的には定着しやすいのです。これを ツールのパラドックス と呼びます。キッチン用品などはわかりやすいと思います。包丁でも箸でも皿でも何でもいいですが、一つの種類を使うよりも、複数の種類を使い分けた方が上手くいきます。

 優先度/Priorityタスクに 1 つだけ付与できる分類項目。
優先度属性は優先順位を制御するために使います。たとえば高、中、低の三段階の優先度を用意し、各タスクに付与することでタスクごとの優先度がわかりますし、「高優先度のみ表示する」といったフィルタリングも可能になります。
優先度の値は多岐にわたります。高/中/低、極高/高/中/低、High/Middle/Low、5/4/3/2/1。また問題管理や障害管理の文脈では問題の深刻度を指す指標として使うことがあり、この場合は Emergency/Alert/Critical/Error/Warning/Notice のような定義になることもあります。いずれにせよ、どのような値を使うかは自由であって正解はありません。
個人タスク管理では通常、優先度属性は使用しません。優先度属性はプロジェクトタスク管理など本格的な管理で用いるものです。というのも、これは定義をしっかりと定めて、使用も周知させることでようやく機能するものだからです。たとえば「高」はこういう条件が当てはまったら付与します、高をつけたタスクには必ず担当者をひとり以上つけて、チャットでも全体メンションを打って周知させます――のように運用のレベルで定めます。個人の範疇でここまで行うモチベーションは通常無いでしょう。逆に、個人であってもこのレベルでしっかりと運用できるのならば、使っても構いません。よくあるのが主観で判断して優先度をつけることですが、判断にブレが生じますし、ブレた分類項目はすぐに形骸化します。感覚的に区別したいのならスター属性（高/それ以外、の二値から成る優先度とも言えます）で十分です。

 トリガーコンテキスト/Trigger Contextタスクに単一また複数付与できる分類項目。
トリガーコンテキストは、そのタスクを実行できる状況を示します。詳細はコンテキストの章を参照してください。
トリガーコンテキスト属性は通常ツールではサポートされません。代わりにタグ属性やラベル属性として――つまりタグ名やラベル名としてトリガーコンテコストを書いて使います。たとえば電車やバスなど移動中に行いたいタスクを管理したいとして、「移動中」という名前のトリガーコンテキストをつけたいとするなら、「移動中」タグや「移動中」ラベルをつくります。ただしツールによってはサポートしていることがあります。GTD ベースの OmniFocus では「コンテキスト」と呼ばれていますし、タスクシュートでは「モード」という言葉が使われていますが本質的には同じです。
トリガーコンテキストはタスクに複数付与できますが、可能なら一つのみ付与することを推奨します。なぜなら複数付与は疲れるからです。たとえば「移動中」と「パートナーがいないとき」の二つのトリガーコンテキストが、またタスクとして「タスク管理を噛み砕くを読む」があるとします。このタスクにはどのトリガーコンテキストをつければいいでしょうか。一見すると「移動中」も「パートナーがいないとき」も両方つけておけば良いだろう、どちらのシチュエーションでも探し出せて便利なはずだ、と思えますが、実はアンチパターンです。トリガーコンテキストが複数ついているということは、そのタスクは複数の状況で実行できることを示しているわけですが、これは言い換えると、その複数の状況（この例では移動中とパートナー不在時の両方）が来る度に実行するかどうかの判断が必要だと言えます。判断の数――つまりは認知コストを食う機会が増えるため、疲れるのです。タスクが少ない、特に PC やスマホなどでスクロールせずとも見切れる程度に少ないなら問題になりませんが、タスクの数が増えれば増えるほどこの形骸化は加速します。認知コストの負荷を舐めてはいけません。それよりも「移動中に読むか」と割り切って、「移動中」のみつける方が良いのです。あるいは「パートナーがいない静かな自宅でゆっくり読むか」と考えて「パートナーがいないとき」をつけても構いません。別の言い方をすると、あるトリガーコンテキストでフィルタリングをしたときの表示数（表示されるタスクの数）はなるべく小さくしてください。複数付与を許すと、すぐに長いリストになってしまいます。長い TODO リストが容易に破綻するように、長いフィルタリング結果も形骸化します。

 主観系属性タスクに関する所感を表現します。
主観系属性は主観的に決めるものであるため、正解や厳密性はありません。むしろこれらに頼らず、率直な所感を素直に反映するべきです。主観である分、厳密な記録としては役に立ちませんが、それでも自分が感じたことの記録ではあるため何もしない場合よりは役に立つ可能性があります。
主観系属性は定量的に決めるべきです。何らかの文章や単語を書くような営みは、すべて記述系属性か機能（Attachment）として扱ってください（※1）。ただし、いくつかの単語や絵文字から選択させる場合は定量的と言えます（本質的には 1～n 番目の選択肢から 1 つを選んでいるに等しい）。なぜ定量的にするべきかというと、タスク管理――特にあとで実行するタスクを選んだり、実行したタスクを振り返ったりするときの認知コストを減らしたいからです。文章を読んで理解することにはかなりのコストを費やします。文章と向き合いすぎて認知コストを酷使するせいで続かない、はよくある失敗例の一つです。そうではなく、数字や選択肢の中から選ぶだけ、という形にしておくと、書くときもかんたんですし、あとで読むときも認知コストは少なくて済みます。自分でつくった体系に慣れる必要こそありますが、定性的な文章を扱って認知コストを酷使するよりははるかにマシです。
※
1 記述系属性として扱う場合、（本章では取り上げていませんが）備考属性や所感属性なるものをつくって、そこに書くと良いかもしれません。結局はあとで読み返せれば良いだけなので、詳細属性を使っても良いでしょう。


 重要度/Importanceタスクの重要性。
重要度属性の目的は、利用者にとって重要なことを可視化して行動を促すことです。重要度属性のついたタスク、特に重要度が高いとなっているタスクは、利用者にとって重要ですので優先的に向き合うべきです。人は重要なことを見失いがちですし、自覚がないこともありますが、重要度属性を運用することでそこに明示的に介入できます。
定義の仕方については、優先度属性と同じで構いません。というより、重要度属性は本質的には優先度属性と同じものです。優先度の定義方法として「主観的な重要度」を使うと、この重要度属性になります。
重要の基準は主観で決めますし、文脈から決めても構いません。つまり同じ人であっても、あるタスクの重要度が 3 日前は「低」だったのに今日は「高」と感じる、といったことが起こります。統一感が無くて、つい基準をしっかり定めたくなりますが、堪えてください。主観系属性はあくまで主観に頼った属性であり、その場その時の主観を大事にしてみるというアプローチです。もしこれが嫌で、もっと統一的な基準に基づいて運用したいのであれば、優先度属性を使ってください。
重要の定義に正解はありません。タスク管理における重要、と聞くと時間管理マトリクスがよく挙がりますが、ここでも重要の定義はありません。何が重要かは人それぞれですから当然のことです。
重要の定義に重要以外の意味を含めないでください。たとえば時間管理マトリクスでは重要と緊急を区別しており、単に緊急性の高いタスクが重要であるとは限りません。緊急性、収益性、稀少性といった因子はよく重要の定義に混ざりがちですが、これらは状況や性質を表しているにすぎず、利用者自身が考える重要と必ずしも被っているわけではないのです。
重要度の高いタスクをどう処理するかは利用者が柔軟に決めます。「すぐに着手するべき」と考えがちですが、これは前述のとおり緊急性の観点にとらわれすぎています。重要だがすぐには実行できないとか、重要だからこそまずは考えを深めておくべきとか、重要だが現状は成す術がないのでとりあえず静観していこうなど、どう動けるかは様々です。もちろん、タスク管理のセオリーとしては、ただ単に決定するだけでは意味がないため、具体的に予定なりタスクなりを仕込んだり、モットーとして掲げたりするなり何らかの行動に移した方が良いでしょう。

 難易度/Difficultyタスクの難易度。
難易度属性を使うと、タスクの実行タイミングを主観的に調整することができます。難易度の高いタスクは取り組み方を工夫しなければなりませんし、逆に低いタスクは後回しにできるでしょう。もちろん人によって「かんたんなものから先に全部済ませる」派だからまずは難易度の低いタスクから潰す、もありえます。このような判断を行えるようになります。特に難易度の定義はしばしば「自分が持つコンテキスト」と重なるため、難易度を上手く捉えることでミキサーのように「一気に処理する」ことも可能になります。
定義の仕方については、優先度属性を参照してください。難易度属性も本質的には優先度属性と同じです。優先度の定義方法として「主観的な難易度」を使うと、この難易度属性になります。
難易度の定義に正解はありません。いくつか取り上げると、不確定性（決まってないことが多い）、技術的難易度（技術的にむずかしい）、時間的難易度（時間が足りない）、好き嫌い（※1）、ロードコンテキストの量（先に進めるために思い出すことが多くて再開が苦しい）、拘束の程度（場所や時間を指定される＝拘束が厳しい）などです。
難易度属性は事後評価の用途で使うべきではありません。たとえばタスクを実行したあとの記録として難易度を書いておく、等がありがちです。難易度属性はあくまで事前（実施前）の難易度を決めるものです（※2）。
※
1 好き嫌いについては、嫌いだから難易度が上がる（好きだから下がる）とは限りません。好きだからこそこだわりすぎて衝突してしまうため難易度が上がる、ということもありますし、嫌いゆえにどうでも良くて最低限の対応で済ませるから難易度は案外高くない、といったこともあります。また最低限で済むという意味ではかんたんだが、精神的には疲弊するので自分にとっては難易度は高い、といった捉え方もあります。主観系属性ですから捉え方は自由です。
2 本書では解説しませんが、主観的な難易度を用いた見積もりも可能です。本項で取り上げた難易度属性は「事前評価」的な難易度であり、注釈元の「事後評価」的な難易度と組み合わせると、事前はどう感じて事後はどうだったか、という難易度の印象の見積もりが行えます。見積もりというと通常、時刻系属性で示したような時間量――もっと言えば「蓄積される数量」が使われがちですが、難易度のような離散値でもできないことはないのです。ただし、これをサポートしたツールやメソッドは筆者の知る限り、無いと思います。効果も想像の域を出ませんが、おそらく難易度との向き合い方を最適化することで QoL が上がるのだと思います。仮に筆者が名前をつけるとするなら、Difficulty Driven Work-style（難易度駆動）とでも名付けるでしょう。


 協調系属性タスクに紐づいた人を表現します。
協調系属性は個人タスク管理では扱いませんが、プロジェクトタスク管理では（特に担当者属性は）欠かせないものです。
※本書は個人タスク管理を扱った本であるため、協調系属性の解説は軽く行うに留めます。

 担当者/Assigneeタスクの実行を担う者。
担当者属性の目的は二つあります。一つ目は、タスクを実行する（状態属性を終了や完了に持っていく）責任者を指定することです。これにより担当者はタスクの遂行はもちろん、状態の変更といった操作を行う責任を負います。もう一つは利用者自身が抱えるタスクの洗い出しです。通常、プロジェクトでは多数のタスクが存在し、自分が担当するタスクを探し出すのは容易ではありませんが、担当者属性の設定が適切なら「担当者=自分」でフィルタリングするだけで済みます。

 発行者/Ownerタスクを作成した者。
発行者属性は自動で記録するべきです。
発行者属性は通常使われません。タスク管理において重要なのはタスクの内容、そして実際に責任を負う担当者であり、誰が発行したか（作成したか）に価値はないからです。仮に発行したタスクに問題がある場合でも、完了操作などを行ってクローズすれば済みます。もし発行者属性を使用している場合は、良くない兆候だと考えられます――過度に複雑な管理になっているか、政治が発生している可能性が高いです。ただし、これは複雑な管理や政治が不要と言っているわけではありません。

 貢献者/Contributorタスクに携わった者。
貢献者属性を使うと、そのタスクに誰が絡んだかを一目で知ることができます。BTS などタスク上（タスクの個別詳細ページのコメント欄など）で議論が活発になる世界では、どの議論をどれだけ読むかという取捨選択が重要となりますが、このときに使う端的なテクニックが「誰がどの議論に絡んでいるかを確認する」ことです。貢献者属性はその役に立ちます。
貢献者属性は自動で記録するべきです。
貢献者属性は、メンバーのアバターアイコンを並べる等の形で視覚的にわかりやすく強調することを推奨します。可能ならばタスクの一覧画面でも表示して、一覧的に視認できるようにするとさらに便利です（いちいちタスクの個別ページを確認せずに済みます）。一方で、これは個別ページを読まない怠慢も後押ししてしまい、特定の、たとえば気に入った人のタスクだけ読むとか嫌いな人のタスクは読まないとかいった事態が生じます。政治色を強めるのです。そういう意味で、貢献者属性には読み手のコストを削減する効果がありつつも、やりすぎると政治力を強める危険性があります（ 貢献者属性のジレンマ ）。

 購読者/Subscriberタスクを監視している者。Watcher とも。
購読者属性は、購読――更新通知を実現するために使います。タスク A を購読したい人は A を購読します。すると A の購読者にその人が追加され、A の状況が更新されたときに A に通知が行きます。あまり動きがないタスクの動きを知りたいときや、逆に重要なタスクで動きがあったらすぐに知りたい場合などに使えます。当然ながら SNS やチャットと同様、購読しすぎると通知量が増えて首が絞まります。決して万能ではなく、ここぞで使う程度がバランスが良いでしょう。
購読者属性を重視したタスク管理は現在開拓されていません（※1）。
※
1 開拓の余地があると思います。購読の概念は RSS リーダーや SNS などですでに有用性が示されており、その本質は「自分が購読したものを」「更新順で」知らせることですが、意外なことにタスク管理では積極的に使われていません。特に BTS など議論を行うような場面では重宝するはずです。これに近い使い方ができるのが Scrapbox で、ページをタスクとみなし、一覧のソート順序を Date Modified（更新順）にしてアイコンフィルターも適用すると、ほぼ実現できます（ただし購読の機能はなく「自分のアイコンを書き込んだこと」を購読とみなす）。筆者としては、この概念を盛り込んだタスク管理はキラーアプリになるポテンシャルがあるとさえ思います。特に自律的にあちこち関わりつつ、活発に議論しながら進めていく今風の組織（たとえばティール組織）と相性が良いはずです。ティール組織も現在は出社など物理的に固まって密に活動するのが主流のようですが、これを開拓できればリモート化でも実現できる気がするのです。