属性

では「2022/09/09 買い物」はどうか。実行日（そのタスクを行う日）という形で「いつ行うか」を切り取ったのは賢いと言えよう。これなら、仮にタスクが100個あったとしても何とかなりそうだ。というのも、今日は実行日が今日になっているタスクだけ済ませれば OK だからである（つまりデイリータスクリストの概念を実現できる）。もちろんその今日のタスクが100個だったらどうしようもないが、7個とか10個とかなら、まだ何とかなるのではないか。ちなみに「買い物 2022/09/09」も同じであるが、ただ属性の順番が違うだけである。どちらでも良いが、たとえばプレーンテキストタスク管理と相性が良いのは前者（日付が先）であろう。並び替えを行えば日付順で綺麗に並んでくれるからだ。

もう一つ、「2022/09/09 買い物 ~30」は、属性が3つもある。「何分くらいかかりそうか」という特徴も切り取っていることがわかる。このような属性は見積時間とか見積と呼ぶ。何分かかるかを見積もっているわけだ。これも実行日と同様、タスクが多数存在擦る場合に便利となる。たとえばあなたに26分のスキマ時間が出来たとする。タスクの一覧を見て、26分に収まる（見積の合計が26分以下）ように選べば良い。もちろん見積どおりに終了できるとは限らないが、何もないよりは読みやすい。そういうタスク管理を続けていけば、見積の精度も上がるだろう。

このように、どんな属性を採用するかによって、タスクの扱いやすさが異なってくる。属性があればあるほど「扱い方の多様性」も広がるわけだが、一方で、多機能すぎてごちゃごちゃするリスクも孕んでいる。そもそもツールというのはよく使う部分とそうでないものが出てくるものであり、無闇に属性を増やすのは得策ではない。心は踊るかもしれないが、管理には何ら貢献しない。

もちろん、明確な設計思想があって、あえて多くの属性を採用したツールもある。たとえばTaskChuteはそうであろう。いちいちあれもこれも記入させられて非常に面倒くさいが、その代わり、自分の生活のほぼすべてを記録に残すことができる。苦しんだ見返りとして、自分の行動を客観的データとして残せるのである。データが残れば考察ができる。分析ができる。作戦を立てることもできよう。闇雲ではなく、たしかなデータに基づいた改善に着手できるのである。

あるいは、色んな人の色んな用途を想定するために、あえて多機能にして間口を広げているケースもある。GitHub Issuesはそうであろう。これはプログラマ向けの課題管理ツールであるが、担当者、ラベル、プロジェクト、マイルストーンといった属性がサポートされている。ラベルを使えば好きなタグを運用できるし、「誰が」基点で管理したいなら担当者が使えようし、もちろんラベルと担当者を組み合わせても良い。ラベルが要らないなら使わなければ良い。他にも、ビジネスで使われる本格的なツールはこの傾向が強い。仕事は本質的に複雑であり、これと向き合うためには色んな観点が要るものなのだ。少量の属性を採用したスマートなツールだけでどうにかなるほど、ビジネスは甘くない。もっと泥臭いのだ。泥臭く使えるポテンシャルが要るものなのだ。

タスク管理ツールに慣れたければ、属性に注目すると良い。

ここまで述べたように、タスク管理ツールとはタスクの特徴を属性という形で切り取ったものだ。属性を見れば、そのツールがどういうコンセプトで何をしようとしているかがわかるであろう。あなたはその匂いや雰囲気に従えば良いし、そんな素直な歩み寄りは、理解や習熟を早めてくれる。

あるいは、一見すると多機能で意味不明なツールであっても、「私はとりあえずこれが使えればいいや」と取捨選択できるようになる。多機能で人気のツールは、やはり出来が良いから、多機能すぎてよーわからんと捨てるのはもったいない。

タスクの内容を表現する。

言葉を用いたものだけ扱う。

「言葉を用いないタスクがあるのか？」と思うかもしれないが、ある。物タスクなどビジュアルで内容を表現（というより想起）するものがそうである。が、デジタルのタスク管理ツールとしてはまだ存在しないだろう（アイコンや背景などアイキャッチやカスタマイズ用途で画像をサポートしたものならある）。逆にアナログの場合は既に存在する。たとえばゴミ捨てというタスクを表現するのに、ゴミ袋を玄関に置いておくことが考えられる。これはゴミ袋という物タスクを扱っていると言える。

タスク名、タスクの名前、Name、Title、Caption

最もよく使われる属性であろう。タスクについて表現する場合、たいていは何らかの言葉を使うしかなく、しかしいちいち細かい諸々を書くのもだるいから、端的な名前だのタイトルだのをつける。それがこれである。

小さなツールだと記述系属性はこれだけになる。逆にプロジェクトタスク管理など本格的なツールであれば、後述する詳細属性も使われることが多い。

一行レベルの端的なテキストであることが多い。フォーマットは基本的にフリーだが、文字数制限をかけられている場合が多い。この文字数制限が緩いと、詳細属性としても使えるポテンシャルも出てくる。たとえば2000文字まで書けるとしたら、詳細なコンテキストも一通り書けよう。無論、UI は一行入力ボックスなどであろうから、書きづらい・読みづらいことこの上ないが。

他の属性も記せるようにしたものもあり、プレーンテキストタスク管理でよく見られる。Tritaskやtodo.txtがそうであろう。Tritaskではrep:1と書けば「毎日繰り返す」というルーチンタスク設定をなるし、todo.txtでは+ABC案件というラベルを書ける。どちらも、タスク名の任意の位置に書ける。買い物をする rep:1でもrep:1 買い物をするでも良いわけだ。

タスクの詳細、内容、概要、Description、Overview

これも最も使われる属性の一つであろう。というのも、現代人には題名指向があり、名前属性は「ただの題名」としてのみ使うのが常識となっている（疑うことさえしない人も多い）。となると詳しい内容が書けないから、もう一つ属性を設ける必要がある。それがこの属性だ。

複数行を書くことのできるテキストエリアとして実装されることが多い。本格的なツールだとMarkdownなどの記法もサポートし、見出しや文字装飾やリンクや画像といったものも差し込める。タスク管理には過剰に思えるが、プロジェクトタスク管理の文脈だと他メンバーに専門的なことを伝える必要性が多いため重宝しがちだ。

Wikiやアウトライナーなどのライティングシステムをタスク管理として（あるいは「しても」）使った場合、属性が「詳細」のみのタスク管理ツールになることもありえる。このような世界観では、下手に属性で管理することよりも、とにかく本文を書くことを有線する。文章や言葉の力に頼るわけだ。2022/09 現在、このような潮流は少し出ており、たとえば倉下忠憲が文芸的タスク管理という言葉を使っている。

タスクの状態を表現する。

状態として最もわかりやすいのは「終了」であろう。タスクはそもそも終わらせるものであり、終わらせたら用済みとなる。よって、終了かどうかという状態を設け、終了したタスクを用済みする（たとえば非表示にする）のだ。そうすれば、終わっているタスクと終わっていないタスクが混在して見づらい、なんてこともなくせる。常にまだ終わっていないタスクだけを表示できる（もっと言えば「ここの表示をゼロにすれば全部終わり」という目標をつくれる）。

状態、ステータス、終了、完了、Status、Completion、Done

状態系属性に含まれる属性は、この状態属性だけである。

状態が取りうる値の種類は2種類(2値)か、3種類(3値)である。4種類以上のツールがあった場合、それは状態ではなく疑似状態である。他の属性（たとえばラベルのような分類系属性）を使って、擬似的に状態を表現しているにすぎない。また、1状態というケース（つまり状態がない）もありえない。タスクである以上、終わりはあるので、少なくとも2値にはなる。

どのような状態の種類を持っているかを状態の体系という。例を挙げる。

2値。完了、未完了

3値。未着手、開始、終了

本質的には、2値は「終わったかどうか」を表し、3値は「まだ手を付けてない」「手を付けた」「終わった」を表す。

ただ、ツールや人によって言い方が変わってくるだけである。たとえば未完了だったり未着手だったりするし、開始だったりオープンだったりするし、終了だったりクローズだったりDoneだったりCompletedだったりするし、進行中だったり着手中だったりStartingだったりDoingだったりする。

そういう意味で、状態の体系とは言い回しの流儀にすぎないと言ってもよかろう。

タスク個々を識別する。

いわゆるIDの概念である。もしタスクを識別できないと「買い物をする」「買い物をする」という、字面上は同じタスクを区別できない。もちろん最終的には（たとえば実行日属性などで）いつやるかが分かれるなどするであろうが、作業中、複製しただけだと純粋に同じタスクが2つできることもある。このような場合でも両者を区別できる必要がある。

ただし、見てのとおり、実装上の都合（プログラムの内部的な事情）でしかないため、通常ツールの利用者が意識することはないだろう。しかしTaskChuteでは各タスクに番号があり、しかも表示順に絡んでもいるから利用者は意識させられる。またRedmineやGitHub Issuesなどチケットベースのツールでは、#11のように番号名で当該タスクを参照する機能を持っていたりもする。この場合も、やはり意識せねばなるまい。

見かけ上はIDが存在していないように見えても、実質存在していると言える。たとえばTritaskはタスクのIDを持たないが、各タスクは行数で特定できるため、行番号が（実質的に）IDになっていると言える。

ID、識別子、番号、No、Number

識別系属性に含まれる属性は、このID属性だけである。

IDとして使われるものは主に以下のとおり。

番号。1,2,3……と連番で続いていく。

ランダム文字列。機械的に生成されたランダムな文字列。たとえばiVraQQWkMiDMやqGNTb5など。

名前。たとえばファイルシステムで1ファイル1タスクで運用した場合はこれになるであろう。この場合、タスクの識別はタスク名（ファイル名）によって行われる。

ID属性は基本的に操作できない。ツール上でタスクをつくると、勝手にIDが振られている。内部的に区別がつくようになっているだけで、利用者が直接IDの値を変えることはできない。例外はTaskChuteであろう。これは辞書順降順でタスクを並べる仕様になっており、タスクの先頭フィールドがID（というより番号）になっているため、上に持っていきたいタスクのNoを小さくする、といった形で並び替えを行うことになる。

タスクに紐づいた日付を表現する。

人の営みと時間は切っても切り離せない。人の営みは時間に基づいており、もっというと時刻と日付に従っているところがある。時刻は後述するとして、ここでは日付の方を扱いたい。人は日単位で活動と休眠を行う生き物であり、社会もその前提で動いているため、タスクを日単位で分割して扱うとなにかと都合が良い。

日付系属性は大別すると2種類――過去を記録するものと未来の目標を示すものがある。前者については、純粋に記録（ログ）として役に立つ。後者については、いつやるのか、あるいはいつまでにやらなければならないのかという目安を表現するのに重宝する。また、後者と前者を両方用いることによって、理想（目標）と現実（実際の記録）のギャップを計測することもできる。もっと言えば計画とその進捗管理という営為に持ち込むことができる。プロジェクトタスク管理においては事実上欠かせない概念であろう。

この属性との付き合い方は4通り考えることができる。

2 過去だけ使う

3 未来だけ使う

自分、あるいは自分のシチュエーションにあったものを選ぶと良い。仮にツールが4であっても、2や3で済むのであればそれだけ使えば良い。逆に、4がしたいのに、ツールが2や3しかサポートしていない場合は、4が使えるツールに移行した方が良かろう。もちろん、番号が多くなるほどツールも複雑になりがちであり学習と運用のコストが高くなる。

ちなみに曜日は管理しなくてもよい。日付が決まれば自ずと計算できるからだ。しかし、曜日は表示しておくと認知資源が減るのも事実であり、好みが分かれよう。私は表示したい派であるため、拙作Tritaskでも表示させている。表示する場合、(月) 月 月曜日 Monday mon MON mo などバリエーションが多数あり、こちらも好みが分かれる。賢いツールならカスタマイズできるようになっているだろう。

実行日、開始日、Execution Date

そのタスクをいつ実行するかを表現する。たとえば2022/09/11 自転車修理とあれば、この自転車修理というタスクは2022/09/11に行うつもりだとわかる。

この属性は日付系属性における最重要概念であり、デイリータスクリストを実現するのに必要である。この属性があれば、タスク達を今日と明日以降に分けることができる。そして今日は、実行日が今日となっているタスクだけをやればよい。こうすれば毎日「今日はここにあるタスクを全部やればいい」というゴールが設定され、メリハリがつく。他のタスクは明日以降の方に先送りされているので、また明日確認すれば良い。

本格的に使えば、より強い先送りが手に入る。たとえば2022/09/19に行うべきタスクAがあるとしたら、Aの実行日を2022/09/19に設定しておけばよい。これだけで2022/09/19当日にAが（デイリータスクリストとして）見えるようになる。あなたは毎日、目に見えるタスクを処理するだけで済み、2022/09/19にAを置いたという事実など忘れても良い（2022/09/19になればどうせ出てきて思い出せる）。もちろん、これを実現するにはツールに相応の能力が必要だし、あなた自身もデイリータスクリストを真面目に運用しなければならない（少なくとも毎日何回も見る＆空にする程度には）。

ツール側に十分な俯瞰能力（表示の広さと動作の軽さ）がある場合、カレンダーの代替になるポテンシャルも秘めている。たとえば私は予定リストという言葉で説明しているが、拙作Tritaskをカレンダー代わりに使っている。タスク管理ツール上で、カレンダーさながら予定も管理できているわけだ。もっとも、このレベルになると相当マニアックであり人を選ぶ。そもそも予定は通常、カレンダーで管理するのが無難だ。

作成日、Creation Date

そのタスクをいつ作ったかを表現する。

これはいわゆる投稿日時のようなもので、後でいつ作ったかを追えるようにするための記録でしかない。正直なくても問題ない属性であろう。少なくとも個人タスク管理では要らない。プロジェクトタスク管理では、チームという都合上、証跡は重要であるからとりあえず残すという意味で採用することも多い。というより、ツールの仕様として記録されるために事実上記録するしかない、が現実であろう。

締切日、期限、Due Date、Expiration

そのタスクをいつまでに終わらなければならないかを表現する。

これもプロジェクトタスク管理用の属性であろう。チームプレイでは全体の整合のため、「この日までにこれとこれをやる」という形で直近のタスクを決める。あるいは諸事情で「この日までに "やらなければならない"」と圧がかかることもあろう。いずれにせよ、このタスクはこの日までやる、と区切りをつけるわけだ。その区切りを締切という。

この属性は諸刃の剣であろう。というのも、たいてい、タスクとその締切は正しいとは限らないのに、締切日を守ることに過剰に注力しがちだからである。本懐はプロジェクトの成功であり、タスクの締切やタスクそのものが違う場合は修正すべきであろう。だのに、目の前のタスクを終わらせること自体が目的となってしまう。典型的な手段の目的化と言えよう。しかしながら、締切日がないとしまりがつかず、いつまでも終わらないタスクがぽつぽつ出始めて形骸化に向かっていく。そもそも、締切日を設定したところで守られるかというと、そうでもなく、結局フォローが必要なのである。とはいえ、管理する側としては「締切を超えないようにする」というルールだけで動けば良く、楽だったりする。そういう意味で、この属性は管理者（タスクを遂行する人達を管理する者）向けと言える。

個人タスク管理においては、おそらく必要がない。というのも、締切を意識して計画的に行動できる者はそもそもこんな属性に頼らずともコントロールできるし、逆にそうじゃない者はこの属性があったところでどうせ忘れるか、学生症候群的に当日慌てるだけである。だったらカレンダーとリマインダーを駆使して、雑に（しかし高頻度であるべきだ）俯瞰しつつ想起させてやれば良い。

締切という概念は誰もが知っており、身近でもあるため、この属性を見ると人は使いたがる。しかしその実、あまり役に立たず、この属性は管理コストばかりいたずらに引き上げる。よって、この属性は、まずは使わずにやってみる、くらい思い切るのが良い。あるいは締切タスクも検討してみるとよかろう。ただしルールや慣習として「管理すること自体が大事なのだ」という世界観が敷かれている場合は、おそらく抗えまい。必ず使う（使わされる）ことになるだろう。タスク個々に締切を設定することを是とする宗教信者は非常にありふれている。あなたが勝つことは難しい。

完了日、終了日、Completion Date

そのタスクが完了（終了）した日を表現する。

この属性は、プロジェクトタスク管理では（一応データとして見えないことはないが）活用はされない。終わったタスクに用は無いからである。ただし、締切日との差（締切からn日過ぎて終わった）を可視化すれば、仕事の遅い者を知ることができよう。

この属性は、個人タスク管理ではサポートされることがある。たとえばtodo.txtがそうだ。これは後の振り返りで役立てるためである。たとえば今日はn個のタスクを終わらせることができたとか、日ごとの終了数を可視化してみて傾向を調べるとか、あるいは「作成日と完了日の差」を求めてみて傾向を調べる（差の開いたタスクが多い場合、あなたはすぐには着手しないスロースタータータイプだと言える）、といったことが可能となる。もちろんツールが可視化機能をサポートしてない場合、あなたが自らプログラミングに勤しむことになる。いずれにせよ、意識が高いことに変わりはないので、単に終わらせられればいいとか忘迷怠を防げればいいという程度であれば、この属性は無視してよかろう。

タスクに紐づいた時刻または時間帯を表現する。ただし時間帯についてはセクションに譲るとして、ここでは時刻の方を取り上げよう。

通常、タスクは日単位で扱うものである。時以下の単位では細かすぎるからだ。そもそも時単位については、カレンダーという優秀なツールがある。

それでも時刻を扱うことには価値がある。いわゆるタイムトラッキングである。いつ、何に、どれだけ時間を費やしたのか。いつ始めて、いつ終わったのか。見込はどれくらいで、実際はどの程度だったのか（つまり見込との乖離はどのくらいか）――そういったことを事細かに記録し、自身の現状を定量的に把握するためには、時刻レベルでのデータが要るのだ。当然ながら、何度も何度も記録する操作を行うことになるため、利用者の負担も高い。ライフログであれば自動で記録もされようが、ものがタスク（≒言葉で表現された「やること」）である。手作業から逃れることはできない。リスト駆動生活は必須であろう。あるいは、タスク管理というより、純粋なタイムトラッキングツールや習慣トラッカーであれば、もっと楽に（それこそ普段使っているスマホでアプリを一つ追加する程度で）できようが。

時刻系属性を使いこなす（際に挫折しない）コツは2点ある。

1点目はタスクの操作、特に言語化と記入をできるだけ早く行うことだ。特に1日のすべてを可視化したいといった厳密なタイムトラッキングの場合、記入するタスク数はかなりの数になる。1日数十以上も容易く超えてこよう。100は、よほど細かくなければ超えないだろうが、50は珍しくない。記入に時間がかかればかかるほどもどかしく、面倒くさくなり、容易に挫折や手抜きに繋がる。数秒で記入できても決して早すぎることはない。

2点目は、時刻の記入をできるだけ省力化することである。タイムトラッキングツールであればほぼ自動化されていようが、タスク管理ツールだとそうもいかないことがある（特にタイムトラッキングに寄っていないツールで自力で時刻系属性を扱いたい場合）。ここは絶対に妥協できない。0.1秒でも早く済ませるべきだ。時刻など手で打つものではない。人間は時刻の手打ちに耐え続けるほど強い生き物ではない。というより、意外と認知資源を食っているというべきだ。いくら手入力が早かろうと資源は食う。休憩時間にネットサーフィンしているようなものだ。

日々の消化と記録の考察は分けて行った方が良い。考察とは、たとえば開始と終了の差や見積と実績の差を求める（そしてその値を見て考えたり判断したりする）ことであるが、これを普段のタスク消化時に行うと非常に認知資源を食う。唯一の例外はマジでこのタスクたちをこの順番で終わらせないといけないシチュエーションだが、そんな地獄は考えたくないのでこれ以上は割愛する。考察は、1日の終わりにするとか週末に今週分をまとめて行うといった形で、あとでまとめて行うのが良い。GTDのレビューとは相性が良いであろう。ただし、慌ただしいシチュエーションの場合は日単位ではなく、もっと短い単位――セクションごとに考察する必要があるかもしれない。もっと慌ただしいと、割愛したシチュエーションに近づいていく。もう一度言うが、非常に疲れるので、そんなシチュエーションを常態にしてはいけない。最低でも日単位で、まとめて考察が行える状態を日常にしたいところだ。

ロストの対処も頭を悩ませるだろう。ロストに対処するにはを参照されたい。

タイニータスクの扱いにも頭を悩ませるだろう。しかしこれも対処は単純で、タスク管理ツールでは（時刻系属性を）扱わない――それだけだ。潔癖な人はつい扱いたくなるかもしれないが、扱っても邪魔だし、管理コストも馬鹿にならない。1分で終わったタスクを記録するのに1分かかりました、そのようなタスクが何個も何個もあります、なんてことになりかねない。もちろん、タイニーであっても忘迷怠を防ぎたいなら管理すればいいが、時刻系属性はやりすぎである。

セクション、時間帯、Section

リンク先を参照。

開始時間、Start Time

そのタスクを開始した時刻を表現する。

よくある疑問として「マルチタスクにはどう対処すればいいか？」がある。つまり同時にnつのタスクを開始した場合に、どう操作すれば良いかという話であるが、答えは「諦めよ」である。そもそもタイムトラッキングには「一度に一つのタスクだけ行う」という前提がある。

終了時間、End Time

そのタスクを終了した時刻を表現する。

報告的終了を行う場合、しばしば操作コストが問題になる。たとえばTogglではマニュアルモードが存在するが、これは開始時間を自分で記入しなくてはならない（厳密に言うと開始も終了も現在時刻となっており、終了時間や現在だから修正は不要で、開始の方を修正しなきゃいけないというシチュ）。ロストの対処については前述した（そもそもロストがなくなるようにしろ）が、現実的にはそうもいかない。どうするかというと、記入を効率化するしかない。Togglのように一部でも省力化されているツールを使うなり、時刻を一瞬で入力できるよう辞書登録やText Expansionを使ったり、タイピングを練習したり、テンキーを導入したりするのも良い。特にタイピングやテンキーのくだりは馬鹿に聞こえるかもしれないが、入力の効率化は大事だ。あるいはプレーンテキストタスク管理などカスタマイズの余地が大きい場合は、自前で実装するのもアリだ。ちなみにTritaskでは、まさにこの報告的終了を行う操作を用意しており、一発呼び出すだけで記入できるようになっている。

実績時間、実働時間、Actual Time

そのタスクにかかった時間を表現する。終了時間と開始時間の差から求めることができる。

誤差の累積に注意したい。たとえば開始も終了もhh:mmだった場合、実態は1分未満にもかかわらずツール上は0になってしまう。このようなタスクが10個あると、最大10分近くの誤差が生まれることになる。1日全体の振り返りで見れば大した差ではないが、これが「～～に関するタスク」などで絞ると、2分と見えているのに実態は8分、といった乖離が生じる。ルーチンタスク管理を本格的にやっていたり、キャンセルタスクが多かったりすると、本質を捉えづらくなる（左記の例で言うと本当は8分なのに2分しかかかってない、という誤解のまま過ごしてしまう）。

見積時間、Estimate Time、Expect Time

そのタスクの予定消費時間を表現する。

たとえば30分と設定した場合、そのタスクは「30分（くらい）で終わる」という意味になる。また、すべてのタスクにこの属性値を設定すれば、「それらタスクを合計するとどれくらいかかるか（かかる見込みなのか）」がわかる。予実管理が行えるわけだ。

ルーチンタスクとも相性が良い。あなたは1日どれだけルーチンタスクに費やすことになるかがわかるし、実働時間と併せて、日々考察すれば「総時間をできるだけ減らす」「平準化する」といったコントロールもしやすくなる。たとえば私は「家事雑務は1日1h以内」を掲げ、Tritaskで記録を取っては「ここが時間かかりすぎてるな」「これとこれはまとめて行った方がいいな」「これは今4日に1回だけど、10日に1回でも良さそうだな」といった調整をして、といったことを繰り返して達成することができた。

中途半端に手を出すのが一番良くない。全く手を出さないか、全部に手を出すか（自分が扱うタスク全部に記入するか）、どちらかを選ぶべきである。というのも、中途半端に総見積時間を算出したところで使い道がないからだ。もちろん上述のとおり、ある種類のタスクにだけ全部つけるのならアリだ。いずれにせよ、もし手を出すのであれば、相応のコストは覚悟せねばならない。この属性に手を出すということは、実質実績時間とその考察にも手を出すことに等しい。あなたの、タスク管理に費やす時間は、おそらく30分は増えよう。己の予実管理と真面目に向き合うと、そのくらいはかかるものである。

ルーチンタスクに紐づいた出現頻度を表現する。

そもそもルーチンタスクをどうやって実現するのかというと、単にタスクを指定頻度で出現させるだけである。たとえば毎日行うタスクAは「1日に1回」出現させれば良い。Aを1日2回行いたいのなら、タスクAを2個つくれば良い。毎週月曜日と木曜日のゴミ捨てをルーチンタスク化したいなら、「毎週月曜日かつ毎週木曜日」のような設定になるだろう。あるいは毎週月曜日の「ゴミ捨て」タスクと、それを複製して出現頻度だけ「毎週木曜日」に変えた「ゴミ捨て」タスク、の2つをつくるかもしれない。いずれにせよ、ツール側では「指定頻度で出現させる」的な設定を入れるだけだ。もちろん、ツールがそのような設定能力を持つ必要がある。

小難しい話をしているかもしれないが、このような仕組みの理解は必要である。というのも、タスク管理ツールは、人間ほど曖昧に頻度を扱えないからだ。人間に「3日ごとにやってね」と言えば、適当に計算して実現できるわけだが、機械はそうではない。ツールもだ。結局、ツール上でそういったことを実現するためには、ツール上の言葉（すなわち設定）で指定してやる必要がある。このとき、仕組みを理解していないと扱えない。

頻度設定をどこまで柔軟に行えるかもツール次第となる。私がつくったTritaskは比較的ここがショボくて、「n日に1回」と「毎週xx曜日」しかない。なので月末日、みたいな指定は行えない。行おうとするなら「30日に1回」みたいなアバウトな指定になる。もちろん、「ある月の月末日から30日後」が翌月の月末日になるとは限らない（4月は30日だが、5月は31日だし、2月は閏年でさらにややこしい）。一方、月末日を綺麗に指定できるツールもある（Outlookなどビジネスユース前提の多機能なツールなら基本的には備えていよう）。よって、あなたがルーチンタスク管理を行いたくて、あるいは乗り換えたくてツールを探している場合、まずはこの能力を見るべきだ。

定期系属性がどう動作するかも見ておく必要がある。3種類ある。

1 End and Set。TaskChuteやTritaskの方式で、ルーチンタスクの実体はただ一つだけ存在し、それを終了したときに「次の」タスクをその都度生成するもの。メリットは変更のしやすさ（一つだけ存在しているそのタスクを書き換えるだけでいい）だ。デメリットは先の出現分布を俯瞰できないことであろう。たとえば4日に1回行うタスクAがあったとしても、Aは直近のもの一つしか存在しないため、カレンダーのように俯瞰して「Aはこの日のこの日にある」みたいなことを知ることができない。知りたいのなら手計算が必要だ。よって、ワイドアプローチがしたい人には向かないかもしれない。

2 Set all firstly。Outlookなどスケジューラーが採用している方式で、End and Setとは違い、ルーチンタスクの実体が未来日以降にも事前につくられるもの。メリットは俯瞰できること。どの日に何のルーチンタスクがあるかを、カレンダービューなどから俯瞰できる。デメリットは頻度設定の変更が少し面倒くさいこと。「この日だけを消す」「この設定全体に適用する」のような二択を選ぶ、といった手間が生じる。些細な手間に見えるが、本格的にルーチンタスク管理している場合は（設定変更の機会も増えるため）非常に鬱陶しく感じる。

3 Counter。Habiticaが採用している方式で、その日にやった（タスクを終了した）かどうかだけを記録する。メリットは操作コストが非常に小さいこと（ボタンを押すだけである）。デメリットは頻度設定の融通が効かないこと。今のところ、この方式は「毎日行う日課や習慣」の管理に特化しており、用は「毎日行うルーチンタスク」しか扱えない。またログも残らないため振り返りがしづらい。ただし日単位で実施可否を見返す程度ならできることもある（というより習慣トラッカーの十八番であろう）。ただ時間単位の詳細――いつ始めていつ終わったのか等はわからない。……と、聞くと、ルーチンタスク管理としては弱そうに聞こえるが、案外そうでもない。特にルーチンタイニータスクの管理には重宝するだろう。

どの方式も一長一短だが、クリティカルではない。その気になればどの方式でもルーチンタスク管理はできる。ただ、人によって合う合わないがあるので、可能なら自分にあった方式を選びたいところだ。ちなみに私は、ナローアプローチと迅速な修正を好むタイプなので断然 End and Set だ。

繰り返し頻度、間隔、パターン、Frequency、Interval、Pattern

そのタスクの出現頻度を表現する。

設定方式はいくつかある。

1 Day Interval。n日に1回。

2 WMY Interval。n週に1回、n月に1回、n年に1回。が、現実的に存在するのはW(eek)とM(onthly)までだろう。Y(early)はさすがに間隔が空きすぎており実用的でないため、あえてサポートしているツールは無かろう。

3 DOW Interval。毎週xx曜日。DOWとはDay Of Week（曜日）のこと。

いずれも間隔的（インターバル的）である。別の言い方をすれば機械的であり、単純なロジックであるとも言えよう。実際、内部の計算ロジックは、単にnを足すだけである。曜日についても、7日ごとに繰り返すものなので7を足すのみ。よって、繰り返し頻度属性では望みの頻度を表現できないことがある。たとえば右記は表現できない――平日のみ毎日。休日のみ毎日。休日（土日+祝日+会社特別休日）のみ毎日。毎月第二月曜日。月末日。

このような複雑な頻度（複雑な意味を持つ頻度ということで Semantic Interval という）を表現したければ、後述の繰り返し条件属性を使う必要がある。

プレーンテキストタスク管理でルーチンタスク管理をしたい場合、おそらくこの属性だけを使うことになるだろう。というのも、後述の繰り返し条件属性は、GUI（画面によるUI）でなければ設定しづらいからである。よって、プレーンテキストで実現したい場合、Semantic Interval は、他の原始的な Interval でカバーすることになろう。たとえば私はTritaskにおいて、月末日を表現するのに「27日に1回」を使っている。もちろん、そもそも素直に GUI のツールを使えば、こんな小細工に悩む必要はない。あるいはプレーンテキストベースでも Semantic Interval を扱えるようにすると良いのだろう。

小難しく書いているが、本質はシンプルである。

繰り返し頻度属性は、単純な繰り返しパターンのみ対応できる。

単純な分、扱いやすく、実装もしやすいが、表現できるパターンにも限りがある。

特にSemantic Intervalの表現が難しい。小細工を頑張る羽目になる。

小細工が嫌なら、後述の繰り返し条件属性を使うべし。

繰り返し条件、パターン、Condition、Pattern。

そのタスクの出現頻度を表現する。

繰り返し頻度属性よりも柔軟に指定でき、Semantic_Intervalにも対応している。その本質は「このような性質を持つ日だったら、出現させる」である。条件に当てはまるかどうかを見ているわけだ。

限界指定にも対応していることがある。具体的には「n回分だけ出現する」のような回数指定、「何月何日までは～～の頻度で繰り返す」のような期限指定などがある。

この属性を設定する手段は、おそらくGUIになるだろう。それもフォームが色々並んでいるような、煩雑な見た目になる。この属性が、それだけ本質的に複雑であることを意味している。とはいえ慣れの問題であるため、LD（算数障害）など障害者でもなければ適応はできよう。ただ、それでも、ルーチンタスクを育てる用途には向いていない。頻度設定を変えるのがいちいち面倒だからだ。とはいえ、個人の日常生活ならさておき、仕事であれば「育てるまでもなく決められている」も多いだろう。その場合は、単に忘迷怠を防げればいいので、むしろこの属性を使ってでも確実に仕込みたい。煩雑でも、面倒くさくても、忘れる怠ける迷うよりはマシだ。

まあ私であれば、そもそもそういう生き方が嫌なので盤外戦で抗うだろうが（苦笑）

ちなみに、この属性が必要なほど忙しい人は、おそらくカレンダーを使うことになる。言われるまでもないだろうが。タスク管理というより予定管理、スケジュール管理の世界の住人になっているわけだ。

タスクの性質を表現する。特に後からフィルタリングする目的で付与する（される）もの。

この手の言葉は多数存在し、たとえば右記がある――フォルダ。プロジェクト。カテゴリー。ラベル。タグ。ブックマーク。スター。優先度。

この属性は、ツールによって使っている言葉が違う。あるツールにおける「タグ」と、別のツールにおける「タグ」が同じとは限らない。しかし、この属性はタスク管理の主役でもあるから、たいていのツールが何かしら備えている。タスク管理を行う以上、必ず目にすることになるだろう。よって、混乱してしまう前に、あなたが使っているツールの用語（定義や意味）を確認しておくのが良い。

分類という言葉の意味も押さえておくべきだ。さきほど例として「優先度」を上げたが、これについてはどう思われただろうか？「分類なのか？」と思ったのではないだろうか。意外かもしれないが、優先度も分類だ。分類の本質は、観点の付与とフィルタリングである。優先度は、後から「優先度=高、だけ表示」みたいなことができる。ゆえに分類と言える。もっと言えば、そういうことができるものは、何であれ分類と言えるのだ。ただし、分類以外の便宜を提供するものは、分類系属性ではない。たとえば日付系属性や時刻系属性は、「2022年7月のタスクだけ表示」「14時台に終了したタスクだけ表示」といった形でフィルタリングできるわけだが、そもそも実行日や開始時間といった便宜の提供がメインである。よって分類系属性ではない（分類の便宜「も」持っているという言い方になる）。……と言うと、言葉遊びのようでうんざりするかもしれないが、大事なことだ。というのも、後でフィルタリングしやすいのは分類系属性（純粋に分類の便宜のみを持つ属性）だからだ。分類の便宜「も」持つ属性では、実はフィルタリングはあまり機能しないことがわかっている。

非常に紛らわしいのだが、この属性は「関係」とは関係がない。たとえばタスクAが、プロジェクトABCの仕事だからといって「ABC」カテゴリーをつけたとしても、これは関係を定義しているのではなく、単に「ABC」という分類項目をつけているだけである（ただし論理的には「AはABCに属する」という関係が事実上存在している）。

関係についてはこちら →タスクを構成する3つのA

この属性において外せない便宜の一つは視覚的強調であろう。このタグがついたタスクはこの色で表示、みたいな視覚効果があると、俯瞰時も非常に見やすい。タスク管理はただでさえ文字の世界になりがちなので、視覚効果に頼って負荷を減らすのは良い戦略であろう。もちろん、色使い次第ではかえってチカチカして疲れてしまったり、見栄えの洗練に入れ込んでしまったり（手段の目的化）するため諸刃の剣でもある。

カテゴリー、フォルダ、プロジェクト、Category、Folder、Project。

タスクに1つだけ付与できる分類項目である。

事実上、関係も表現できる。たとえばプロジェクトABCを示す "ABC" カテゴリーをタスクAに付与した場合、「AはABCの配下にある」と言えよう。あるいは「AはABCに関連するタスクである」と言えるかもしれない。階層関係にせよ、単なる依存関係にせよ、何らかの（というより何でも）関係を示せる。それだけに、つい関係を作り込むことに費やしがちだが、典型的な手段の目的化なのでハマりすぎないよう注意が要る。

カテゴリーには、あなたの責荷を端的に反映すると良い。思いつきの項目ではなく、あなたが日常的に接している・抱えているものを反映することで、迷うことなく運用しやすくなり形骸化を防げる。個数は10以内、できれば5以内が良い。少なすぎると思うかもしれないが、欲張ってはいけない。欲張っても形骸化するだけだ。

タスクに付与できる分類項目であり、カテゴリーとは違って2つ以上付与できる。

カテゴリーが厳選された分類項目であるならば、タグは雑な分類項目である。とにかくたくさんつけておき、あとで探したときにヒットしたらラッキー、というものだ。ヒット率を上げることに主眼を置く。よって、1つのタスクに5個や10個を付けても問題はない。よく勘違いされがちだが、カテゴリーのように厳選しなくてもいい。思いつきをガンガンつけてしまえばいいのだ。多ければ多いほど、ヒット率も上がる。もちろん、タスクを付けるという操作コストはかかるので、バランスではある。タグをつけるのに10分かかりました、はさすがにかかりすぎだろう（もし本当に重要なタスクであるならば、予定なりリマインダーなり別の手段を使って確実に仕込むべきだ）。

理論上、分類系属性はこの属性で表現しきれる。よって、もしツールに所望の分類系属性がない場合、あなた自身が何らかの属性をつくって運用することができる。たとえばツールに優先度属性がない場合、あなた自身が「0～5の数字を使おう」「0は優先度なし」「5が一番高い」と決めて、実際に0とか2とか4とかをつけて運用することができよう。ツールに担当者属性がなく、かつパートナーのタスクも管理したくて、でもパートナーには直接触らせず管理は自分で行いたいという場合、タグとして「自分の名前」「パートナーの名前」をつくっておき、パートナーのタスクには後者のタグをつけて管理する（で、終わってないとかあれば催促しに行く）――なんてこともできる。

ラベル、Label。

タスクに付与できる分類項目であり、機能的にはタグと同等だが、加えて視覚効果を持っている。具体的には文字色や背景色を設定できる。好例はGitHub Issuesであろう。

スター、ブックマーク、ストック、Star、Bookmark、Stock

タスクに付与できる分類項目であり、カテゴリーよりもシンプルなものである。取りうる値は2値であり、別の言い方をすれば「マークがついているかどうか」だ。フィルタリング時は「マークがついているもの」だけを表示する形となる。ツールによって、いろいろな名前がついているが、ブックマークやスターやストックといった名前であることが多い。

スターは最もシンプルな分類項目である。特別目立たせたいものにマークを付けておくだけで良い。人によっては、このスターだけでタスク管理をまかなえてしまうこともある。が、実態としては複数の意味を持たせている（頭の中で処理している）――つまりカテゴリーになっていることも珍しくない。

いわゆるインボックスとして活用することもできる。よりカジュアルに言えば「あとで読む」であろう。スターをつけたものは「未処理」であり、後で処理をしたときにスターを外す。そうすれば「スターのついたタスクをゼロにする」という目標に向かって日々活動する、という明快な営為が手に入る。

運用のコツはシングルパーパス（単一目的）だ。「あとで読む」「今日中に処理する」「私が持っているボール（なので誰かに渡すところまでやらなきゃいけない）」のように、何らかの目的をただ一つだけ定めるのである。よく陥りがちなのが、頭の中で複数の用途を使い分ける、であるが、これは認知資源に易しくない。そのうち忘迷怠が発生して形骸化してしまう。もちろん、何もしないよりは忘迷怠率を下げられるためマシではあるのだが、そんな中途半端なクオリティが通用するのは限定的（よほど個人的で重要でもない文脈か、自分の立場が強くて忘迷怠しても許されるか）であろう。

優先度、Priority

タスクに付与できる分類項目であり、そのタスクの優先度（優先的に取り組むべき度合い）を表現する。

採用される値は人次第、ツール次第である。以下にいくつか例を上げる。

この属性は雑に扱いやすいため多用されるが、一方で形骸化しやすいものでもある。人によって解釈が異なるからだ。かといって、「優先度=高は～～という意味であり、～～の対処を～～のうちにしなければならない」みたいなルールを決めたところで、守られるはずもない。そして、普段守ることができても、忙しくなったり量が増えたりするとすぐに形骸化する。この属性が破綻することなく成立する唯一の条件は、全員が（個人タスク管理の場合は自分一人で良い）「優先度に従ってタスクを消化しまくる機械」となること（ならざるをえないシチュエーション）である。典型例は救急現場で使われるトリアージであろう。対象が人命であろうと優先順位をつけ、四の五の言わずに行動し続ける――そんな世界と戦士であって、ようやく役に立つ。優先度とは本来そういうもの（Cruel and Busy）なのだ。よって、そういうシチュエーションでない平和な場所や、その気概を持てない軟弱者は、この属性は使わない方がいいし、使わないといけない状況であるなら外してもらった方が良い。

優先度がどうしても必要な場合、序盤は定着しづらいため、優先度名をより具体的にすると良い。たとえば0,1,2,3よりも0(いったん無視でいい)とか3(できれば一時間以内、最低でも今日中に)の方がわかりやすい。また、タグよりもラベルを使って、視覚的にも強調できるとなお良い（高優先度は赤くするなど）。もう一つ、このようなことを決めるときに荒れがち（特に重箱の隅をつつくようなコメントをして「別に具体的にしなくても数字だけでいいだろ」に倒そうとする派がいる）という問題もあるが、それでも決めなくてはならない。優先度が必要なシチュエーションは、前述したようにCruel and Busy――残酷で慌ただしいのだ。明快な基準というものが絶対に必要である。たとえ上手い基準をつくれる自信や保証が無かったとしても、やらねばならない。個を殺し、基準という宗教に則った狂人と化す。そうすることでしか切り抜けられないシチュエーションも、別に珍しくはない。

トリガーコンテキスト

コンテキスト、Context。

タスクに付与できる「そのタスクを実行できる状況」を表現する。

タスクにこの属性を付けておくと、今が～～の状況のときに「～～コンテキストを持つタスク」をフィルタリングすることで、そのときに実行できるタスクを抽出できる。デジタルツールである必要はなく、アナログツールでテリトリー的に実現することもできる。たとえばあな吉手帳術では、「夫がいないときにできること」エリアをつくって、そこにそれに当てはまるタスク（を書いた付箋）をはりつける、などする。

この属性は、オーバーヒートとの相性が良い。空いた時に行えることを事前に整理しておき、実際に空き時間が来たときにそのストックから消化していく戦略を取る者は多いが、ストックされたタスクが多いと取捨選択に苦戦してしまう。そこで、さらにこの属性を使えば、より小さく絞れる。夫がいないなら「夫がいないとき」を見ればいいし、病院で待っているときなら「待ち時間中」を見ればいい。もちろん、事前に（ストックした）タスクにこの属性を設定しておく必要はある。この手間を惜しんではいけない。が、オーバーヒートな人にじっくりと行う時間などないから、それこそアイデアをメモするように、サクサクと設定していく（思いついたら10秒、できれば5秒以内に設定できるとか）しかない。そのためには、自分が使うトリガーコンテキストのレパートリーに習熟しておかねばならない。「えっと、どういう選択肢があるんだっけ……」などと迷っていてはダメだ。「これはセクションの早朝、これは夫がいないとき、これは待ち時間中、これはセクションの夕方かつ夫がいないとき……」のように、サクサク判断できねばならない。すぐそうなれるような、自分にとって自然なトリガーコンテキストを使うと良い。そのようなものがない場合、あなたはたぶん頭の回転が遅いタイプ（オーバーヒートに向いていないタイプでもある）で、この属性にも向いていない。頑張って鍛えるか（受験勉強やスポーツ練習のように反復練習する）、諦めよう。

一般的には「コンテキスト」と呼ばれることが多い。が、コンテキストは多義語であってややこしいので、私はトリガーコンテキストと呼んでいる。その名のとおり、そのタスクのトリガー（実行の契機）となるコンテキスト（状況）だからだ。

主なコンテキストを以下に挙げる。特に先頭の4つ――PPST(Person, Place, Section, Tool)はコンテキスト四天王と呼ばれる。

人。上述した「夫がいないとき」のように「誰々がいないとき」、逆に「誰々がいるとき」。

場所。自宅、移動中、会社、病院や役所（待ち時間がある）。

セクション。早朝、朝、昼、夕方、夜、深夜。

たとえば洗濯は「朝」か「昼」になるだろう。早朝と深夜と夜は迷惑だし、夕方は乾かす以降の処理が夜になってしまう。もちろん場所が許すか、あなたがそういう迷惑を顧みない鈍感 or 夜型人間である場合はこの限りではない。後者の場合は近所トラブル発生率が高いだろうが。

道具。PC（PCデスクに座っているときにできること）、スマホ（スマホでもできること）。

モード。母親モードや父親モード、教師モード、上司モード。

コンディション。調子いいとき（にやるべきもの）、調子悪いとき（でもできるもの）

タスクに対する所感を表現する。

この属性も本質的には分類系属性である。こうして別に扱っているのは、分類系属性の方で扱うとわかりづらいからだ。

この属性の意義は、タスク管理に自分の実態――特に感情や精神やモチベーションといった機微を反映できるところにある。タスク管理というと、そういったものを度外視して利用者をタスク消化マシーンとみなしがちだが、当然ながら実際はそうではない。私たちは人間である。ゆえに、そういった実態も反映してやった方が、より使いやすく馴染みやすい管理になる。この属性は、その役に立つ。

この属性によってできることは2点ある。

1 迷をなくすため。たとえば2時間の空きが出来たとして、重要度の高いタスクAとそうでもないタスクB,C,Dがある場合、どのタスクをこなすべきであろうか？おそらくAであろう。これは、重要度という主観系属性を定義しているからこそ、できることだ。

2 自分の限界を把握するため。たとえば各タスクに3段階のストレスを付与するとしよう（高、中、低）。加えて、あなたは1日におおよそ4つの高ストレスタスクをこなせるとしよう。5つ以上は不調になりやすい傾向があるとわかっている。この場合、あなたは「このタスクを今日やっちゃうと高ストレスが計4になっちゃうから、明日に回すか」みたいな判断ができるようになる。これは、あなたがストレスという主観系属性を定義し、運用し、その上で「自分はどこまで耐えられそうか」の体感を学んだからこそ実現できることだ。

後者の2は、特に難しい。要するにHPやMPに相当するものを自分なりに体系化するということである。難しいのが、これをまがいなりにもできるようになれば、「HPヤバそうだから撤退する」みたいな、普段ゲームでやるような判断と行動を現実でも行えるようになる。非常に明快かつ迅速で、QoL上がること間違いなしだと考えられている。

重要度、Importance。

そのタスクがどれだけ重要であるかを表現する。

重要の定義は主観的であり、2値である。あなたが重要だと思うなら「重要」とマークすればいい。この属性は時間管理マトリクスとして知られているものであり、ご存知の方も多いだろう。

重要かどうかを決めるためには、より上位レイヤーの信念が必要である。例を挙げると、7つの習慣でいうミッションステートメントや、GTDでいう5000m、あるいはPARAメソッドでいうAoRなど。このような信念が無い場合、重要かどうかの決定は思いつきや場当たりとなる。というより、後で振り返ったときに納得感が出ず（その選択で良かったと自分が納得できず）、結果、形骸化につながってしまう。ただし、オーバーマスト下であれば、信念などなくとも重宝しよう。たとえば家賃の振込は、やらないと後々首が絞まるため重要であるはずだ。重要マークをつけておけば、後で見逃す率を減らせる（おそらく未来の自分が優先的に対処するはず）。

重要なタスク（重要とマークしたタスク）は10以下、できれば5以下に留めるのが良い。たとえばひろゆきは10以下だと言っている。彼ほどの人物でさえ10なのだ。そして、重要なタスクを減らすコツは、同様に彼が言っているように、なるべくその場で処理してしまうこと（タイニータスクも参照）である。あるいは予定として確定できるならそうしてしまい、その予定が来るまではいったん忘れる、でも良い。重要なタスクは、たった1つだけでも認知資源をガンガン奪う厄介な代物（そしてなまじメンタルが強いとこの消耗に気付けない）なので、とにかく抱えないことが先決である。

難易度、Difficulty。

そのタスクの主観的な難易度を表現する。開始の難易度も完遂の難易度も両方含む。

何をもって難易度とするかは様々である。答えが無いという意味での難しさ、答えはあるけど努力量が多いという意味での難しさ、集中力の要否、ストレスのかかる度合い、面倒くささ、やりたさ（やりたくないと難易度が高い）、好き嫌い――と、無数に考えられるだろう。しかし、扱う属性名は「難易度」のようなざっくりしたものが良いとされる。というのも、たいていそれらは一枚岩ではないからだ。やりたくないけどかんたんなタスクもあれば、ストレスはかかるしやらなくてもいいけどやりたいタスクもあるし、集中力が要るけどまあ無くても許容になるタスクもあれば、逆に許容できない（＝集中できるときにしか取り組めない）タスクもあるだろう。加えて、あるタスクには複数のサブタスクがあり、そのサブタスク各々の難易度が異なっていること（やりたいこととやりたくないことが混ざっているとか）もざらにある。……と、このように複雑である。だったら漠然と「難易度」としておき、ムズいなら高、チョロいなら低などと付けておけば良い。それだけで「これはムズいから後回しで」「これはチョロいからさっさとやってしまおう」といった判断ができるようになる。雑で、感覚的で、思いつきの判断になるかもしれないが、それで良い。（相手にしているのがあなたの無知なジャンルでないなら）直感や第一印象は大体当たる。

ここで「いや、タスクは全部必要なんだから難易度もクソもないだろ、ただひたすらやるだけだろ」という人がいるかもしれない。そういう人は、単に自覚なしに難易度を使っているだけだ。たとえば、優秀で残業してでもバリバリ働く上司がいるとしても、プライベートの生活や身体のメンテナンスはぼろぼろかもしれない。これは多くの場合、その上司自身が後者を難易度が高いと決め、後回しにしているだけだ。本当に気にしていない人や、気にしていてもできない発達障害者などもいるが、たいていはそうじゃない。気にするし、気になるのだ。その上で、やらない。やらないのは、難易度が高いからだ。向いていないのも、腰が上がらないのも、純粋に辛いのも、すべてはあなたにとって難易度が高いということだ。そう考えると、難易度という属性がいかに身近であるかがわかるだろう。単に自覚がないだけなのだ。

難易度の管理にはどのような意味があるのだろうか。

1 無理ゲーを回避するため。頭の中で考えるだけでは、「いやこれ明らかに無理だろ」という状況に気付けないことがある。あるいは雰囲気や制約に流されて「何が何でも終わらせる！」と盲信し猛進することもある。人間は愚かなので、当事者になると本当に陥ってしまうことがある。幸いにもタスクを管理し、難易度も扱ってみることで冷静になれる。もしかすると「いやそれでもやるしかない」と腹をくくることになるかもしれないが。これは別の言い方をすると、書いてみることで悩みが半減するとも言える。道は開けるでも散々言っていることだ。ただ、タスク管理を行い、難易度も扱うことで、単に書き出す以上の効果も期待できる。「ここはできる」「ここができない」「ここだけなら何とかだが、ここも加わるとダメだ」といったように、高い解像度で現状を俯瞰できるようになるのだ。半減どころか、4/5を減らすことができよう。

2 自分を楽させるため。まずタスク管理ツールに難易度を入れて管理することで、あなたは自分にとって難易度とは何か、どういうものが高難易度になるのか、といったことと向き合うことになる。自分自身の評価軸を手に入るだろう。そうすれば、後は（自身の評価軸ベースで）高難易度となるタスクにはなるべく手を出さない、とするだけで楽になれる。もちろん、人生は高難度なタスクと向き合うこともままあるため、そう甘くはないのだが、自覚できていると違う。余計な苦労は負いたくあるまい。

この難易度属性を真面目に扱い始めてから最もよく至りやすい結論は、「こんな属性は要らない」である。結局、難易度が高かろうが、低かろうが、やらなきゃいけないタスクはやるしかないし、そうでないタスクはやらなくていいからやらない。難易度を事前に俯瞰できたところで、現実は何も変わらないのだ。せいぜい気が少し紛れるだけである。人によっては「事前に見えるとかえって辛い」という人もいよう（ナローアプローチも参照）。この程度のために、難易度という属性を管理するコストを支払うかというと、普通は No と答える。そもそも特にオーバーマストに陥っているようなビジーな人には、支払える余裕さえ持っていない。あるいは、持っていても、こんな気晴らしに費やすつもりなど毛頭持たない。

難易度はツール上でどう表現すれば良いであろうか。

まだこれといった答えはない、というより答えられるほどの事例がない。

とはいえ、段階が多くても形骸化するだけであるから、シンプルで良い。いくつか例を挙げよう。

easy/normal/hardの3段階

3段階のうちnormalは無印にしたバージョン（easyとhardの場合のみ記入すればいいので少し管理が楽になる）

very hardとなるような激ムズのタスクにだけ印をつける案（たとえばドラゴンタスクはこれにあたろう）

🦁（ライオン）や🐶（イヌ）や🕊（ハト）など「どれだけかんたんに殺せるか」でたとえて絵文字を書く（🦁は無理ゲー、🐶は無傷ではないが何とか、🕊は汚れるけど余裕といったところだろうか）

これら難易度だが、視覚的・直角的に即座にわかるように目立たせると良い。ラベルを使っても良いが、絵文字をおすすめしたい。上述の例でもドラゴンや動物が出てきたが、このように難易度を連想するたとえも積極的に使いたい。そうなると、現状最も手軽に扱いやすいのが絵文字になる。あるいは、空間的なタスク管理を行っているのなら、🐲（ドラゴン）のテリトリーをつくってその中にタスクを入れて巣穴のように見せてもいいだろう。とにかく、即座にわかるような工夫を惜しまないことだ。ゲームも、物語も、童心も、すべてを使ってでも追求したい。

タスクに紐づいた人を表現する。

プロジェクトタスク管理において必要となる属性だが、本質は分類系属性と同様、フィルタリングである。この属性により、人に紐づいたタスクやタスクに紐づいた人を抽出でき、タスクの状況のみならずその人の状況も把握できる。

個人タスク管理とは違い、プロジェクトタスク管理ではタスク管理の力学が少し変わる。

1 責任。タスクは基本的に決定事項であり、責任が発生する。誰の責任なのかという点を、属性にて反映させる必要がある。最低でも担当者が存在し、本格的になるとさらに増える。といっても、管理者など責任を持つ者が所有し、その実行は担当者に割り当てるという二段が通例であろう。

ビジネスの世界では、三段以上の承認体制が組まれたツールも存在するが、この読み物では扱わない。

2 公開。タスクは特定少数の関係者または不特定多数にも閲覧される。場合によっては編集（特にコメントを書いたり、そもそもタスクを新規したり）もありえる。GitHub IssuesなどOSSの現場では珍しくなかろう。誰でも自由にタスク（何らかの課題や要望であることから Issue と呼ばれる）を切ることができ、他の利用者や開発者自身が追加情報を書き込んでいくことで情報が貯まる。もちろんタスクの進行に合わせて状態を変えたり、分類系属性をつけて便宜を図ったりもする。

この力学を応えるのが協調系属性である。

コメントについては属性ではなく「機能」に相当するが、ここでは扱わない。

フェーズやスプリントやマイルストーンといった期間の表現も必要であるが、これも属性ではなく「関係」で扱う。

→ タスクを構成する3つのA

See 個人タスク管理とプロジェクトタスク管理は何が同じで何が違うのか

担当者、作業者、Assignee、Worker。

そのタスクを実施する者。

ありがちなのは担当者の設定を忘れる、あるいは面倒くさくて確信犯的にサボることであろう。そうなると後でフィルタリングするときに正確な状況が取れないし、そうでなくとも担当者自身に「ちゃんと設定してね」と作業させることになり士気の低下に繋がる。この部分の省力化は、力を入れて対処した方が良い。といっても、ツール側が用意している仕組みを使う（このURLにアクセスしたら担当者欄が最初からXさんになっている等）か、打ち合わせの最中に投影してその場で設定してしまうか、物好きな作業者に一任してもれなく設定してもらうかくらいであろう。

発行者、Owner。

そのタスクを作成した者。

教科書的な運用では「管理者がタスクをつくり」「実作業者を担当者として割り当てる」であり、そうすると発行者属性に責任者が、担当者属性に実作業者が見える――という構図になるわけだが、実際この通りに行くことはほとんどないない。あるいはそう見えていても事実上形骸化しがちである（実際にタスクを操作しているのは担当者であり、発行者属性にはその人が機械的に上司の名前を入れているだけ等）。なぜなら、管理職はタスク管理には向いていないし、忙しくて管理する余裕もなければ、タスク管理を学び試す時間も取らない（取れない）からだ。よって、この属性は無視して良い。

貢献者、Contributor。

そのタスクに携わった者。

この属性は、そのタスクの情報を更新したりコメントを書き込んだりした人の一覧である。誰が干渉したのかがわかるようになっている。フィルタリング用途というよりも、そのタスクにおいて誰が携わったかを（参考までに）手早く確認する程度の便宜である。

購読者、Watcher、Subscriber。

そのタスクを購読している者。

そのタスクに何らかの更新があると、購読者に通知などが行く。重要なタスクや個人的に注目したいタスクがある場合、この属性に自分を設定して（というと変な言い方になるが、ツール上で単に購読ボタンを押す程度でできる）購読しておけば気づきやすい。また、タスクのビューにも誰と誰が購読しているかが見えるため、客観的な注目度もわかる。