コンテナの概要
概要
コンテナ（Container） とはタスクを分類したもの、あるいは分類の各項目を指します。
書類をクリアファイルで分類したり、本を本棚や仕切りで分類したり、パソコンではファイルをフォルダで分類したりしますが、タスクも同様に色々な分類に分けることができます。物理的に物を分けるというよりは、論理的に意味を分けるニュアンスが強いです。
また、分類というと厳密な分け方をイメージしがちですが、そうとも限りません。むしろタスク管理は各個人各組織それぞれにあった分類を自分で設計するものなので、雑な分け方もありがちです。
コンテナの例
タスク管理に登場するコンテナには色々な名前がつきます。ツールやメソッド、あるいは人によって使い方が変わります。
よく使われるのは以下のような名前です:
- フォルダ
- カテゴリー
- グループ
- タグ
- ラベル
- ワークスペース
- プロジェクト
中には小難しい単語もあり、身構えてしまうかもしれませんが、所詮は何かを（少なくともタスクを）分類しているだけです。各用語の細かい意味については後述します。
リッチコンテナ
コンテナにはタスクのみを分類したものと、タスクも分類するしついでに他の情報や機能も入れたものとがあります。後者を リッチコンテナ（Rich Container） と呼ばせてください。前者を明示的に指すときは、純粋なコンテナということで プレインコンテナ（Plain Container） と呼びます。
上記のよく使われるコンテナ名を筆者の肌感覚で一般的に分けてみると、こんな感じになるでしょう。
- プレインコンテナ
- フォルダ
- カテゴリー
- タグ
- リッチコンテナ
- グループ
- ラベル
- ワークスペース
- プロジェクト
フォルダやカテゴリーはプレインコンテナとしてわかりやすいと思います。
一方で、ワークスペースやグループといった大きめの単位は、単にタスクを分類するだけでなく、メンバーの情報だったりアップロードしたファイルの情報なども持っていたりしますよね。これらはリッチコンテナです。ラベルは色つきのタグであり、色という情報も持っているので一応リッチの扱いです。
箱モデルと接続モデル
コンテナとして「何かを入れる箱」を思い浮かべがちですが、それだけではありません。
何かを入れるような世界観（箱モデル）の他に、何かと何かを繋ぐ世界観（接続モデル）もあります。フォルダやカテゴリーは前者、タグやラベルは後者になることが多いです。
箱モデルは、ある対象を同時に一つの箱にだけ入れられます。必ずどこかの箱に一つだけ入っている（どこにも入れてないと見つかりませんが）ことが保証されるのでシンプルではありますが、こだわりだすと一貫性を保ちにくくなります。「どっちにも該当するけどどっちに入れたらいいんだろう」のような問題もよく起きます（※1）。
接続モデルは、ある対象に目印をつけるイメージです。上図では誰のものかという目印をつけています。つけるだけなので一つの分類項目（この場合は「誰」）が複数の分類対象につけることもできますし、ある分類項目と別の分類項目（この場合は「僕」と「私」）が同じ対象につけることもできます。箱モデルよりも柔軟性は高いですが、つけすぎると形骸化します。
- ※
- 1 こうもり問題と呼ばれます。こうもりは哺乳類だから獣にも分類できるし、翼もあるから鳥にも分類できるし、とどちらに分類すればいいか迷いますよね。こうもり問題をなくすのは一般的にかなり難しいです。図書館で見かける日本十進分類法のようなものもありますが、あのような分類をつくるには専門家が長い時間をかける必要があります。また、そうして出来上がった分類はそもそも複雑であり、分類作業自体にも苦労するでしょう。個人のタスク管理において、このレベルを確立できるかというと、おそらくできないのではないかと思います。筆者もできませんでしたし、正直人類が挑むものではないとさえ思います。もちろん、これは分類にこだわりすぎた場合の話です。雑に分類する分には困りませんし、それだけでも何も分類しないよりは便宜が得られます――一方で、かえって混乱して害悪だという場合もあるので、一筋縄には行きません。
コンテナはどう扱うか
タスクとして扱わない
まずコンテナはタスクとして扱わないべきです。
仮にタスクとして扱ったとしても十中八九うまくいきません。コンテナは分類であり、分類とは粒度の粗い事柄ですので具体的に何をすればいいかがわからなかったり、あれもこれもやらないといけなくて決断ができなかったりします。一方で、タスクは粒度が細かいものであり、何をすればいいかが明確です。明確だからこそ管理もできます。
粒度
粒度 という言葉が出ましたが、事柄の細かさだと考えてください。よく「具体的じゃないタスクは分解して具体的にしろ」「大タスクは中タスクや小タスクに分解しろ」といいますが、これは粒度の粗いものを細かくしろと言っています。なぜかというと、繰り返しますが粒度が粗いと理解や行動がしづらいからです。
別の言い方をすると、コンテナとは粒度の粗いタスク だとも言えます。ただし、粗いがゆえにタスクとして扱うのは難しいから分類として扱うのです。
コンテナの扱い方は 4 つ
ではコンテナをどう扱えばいいかというと、以下に分かれます。
- 1: ツールのコンテナ機能を使うし、ツールの通りに使う
- 2: ツールのコンテナ機能を使うが、独自に使う
- 3: ツールのコンテナ機能を使わないが、何らかのコンテナは使う
- 4: 何も使わない
上に行くほど制約がきつくなりますが、普通は 2: が多いです。ツールとしても「コンテナをつくる機能はあるけど、どんなコンテナを使うかは皆さんに任せます」となっていることが多いです。状況は人それぞれだからですね。たいていのツールにはカテゴリー、フォルダ、タグといった機能がありますが、実際どんなカテゴリーやフォルダやタグをつくるかは皆さん次第です。元からつくられていることもありますが参考程度であり、そのまま使うことはあまりなく（とっかかりとしてとりあえず従うのはアリ）、それらは消した上で自分なりに作り直すのが定石です。
最も制約のキツイ 1: は、筆者は見たことがありませんが、例を挙げるとGTDです。ツールの話からは離れてしまう（GTDはメソッドです）のですが、GTD ではインボックス、プロジェクト、いつかやる、連絡待ち、ネクストアクションといった箱がいくつか登場し、いつどれをどのように使うかも定まっています。私たち利用者はその辺をちゃんと勉強して、そのとおりに従う必要があるわけです。勝手に一部の箱を使わなかったり、新しい箱を追加したりしてもいけません。設計されたとおりに従わなかった場合は GTD 本来の効果が得られないからです（※1）。
すでに良さそうなコンテナのあり方と運用を知っている場合は、おそらく 3: になるでしょう。つまりツールの機能を使わず、独自に管理するのです。たとえばカレンダーを重用している人は、他のツールを使っていてもそのコンテナを使わず、わざわざカレンダーの方に予定として追加すると思います。この場合もカレンダーというコンテナ（タスクを日や週で分類している）は使っています。
と、このように何らかのコンテナは使うはずですが、中にはそもそも分類なんてしたくない人もいます。その場合は 4: です――とはいえ、そのような人でも実は雑な分類は使っていたりします。戦略の章では一箇所にまとめるを紹介しましたが、これはコンテナをただ一つだけつくってそこに全部ぶっこんでいるとも言えます。そういう意味では 3: の一種です。
- ※
- 1 余談ですが、ソフトウェア開発では「設定より規約」という言葉があります。開発で使われる道具は通常、汎用的につくられていて、どう使うかは開発者が決めるのが主流でした。設定項目が豊富なわけですね。一方で、そうじゃなくて、道具の開発者が「設定の余地はなくしたぞ。この道具が言うとおりに使え。ちゃんと使い方を学べ。そしたら便宜は保証してやる」とある種傲慢なスタンスで道具をつくるケースも出てきました。設定の余地はなく、ただただ俺のやり方に従えというわけですね。扱い方の 1: は、いわば設定より規約です。
それはタスクか、コンテナか
そもそもタスクとコンテナの区別はどうやるのでしょうか。
結論を言うと人次第であり、粒度をどう捉えるかです。
筆者なりに一つの捉え方を書きます。タスクとは具体的で、実行可能で、始めれば数日以内で終了できて、終わったかどうかがはっきりとわかるものです。一方、それ以上の粒度になるとコンテナ――複数のタスクを束ねる単位になります。たとえば「引っ越し」はタスクというよりもコンテナになるはずです。タスクというのは「全体スケジュールを組む」「引越会社をリストアップする」「引越会社各々に見積もり依頼をする」「すべての見積結果を比較してどの会社を選ぶか決める」などです。人によってはもうちょっと細かいかもしれません。筆者ですと「会社Aに見積もり依頼」「会社Bに見積もり依頼」レベルで分けますね。
以下に箇条書きで階層的に書いてみます。コンテナには📦、タスクには📝、どちらか怪しいものには❓をつけます。
- 📦引っ越し
- ❓スケジュール組む
- 📝試す
- 📦引越会社の選定
- 📝リストアップ
- 📝見積もり依頼 A社
- 📝見積もり依頼 B社
- ...
- 📝選ぶ
- 📦荷造り
- ❓クローゼット系
- 📝試す
- ...
- ❓クローゼット系
- 📦廃棄
- ...
- 📦新しい家を探す
- ...
- ❓スケジュール組む
これはあくまで筆者の場合です。筆者は頭の中で考えるのが苦手なので、細かく洗い出してタスク管理しがちです。スケジュールとクローゼット系には❓がついてますが、これは「一見するとすぐ出来そうだけど」「たぶん洗い出すとタスクが色々出てくるんだろうなー」「たぶんコンテナになると思う」のようなことを考えています。まだ確定ではないのでいったん❓をつけています。こういうときは考えても仕方がないので、とりあえず試してみるのが良いです。それを「試す」というタスクとして書いています。
また、タスクを属性や性質で分類したいときも、同様にコンテナになります。たとえば自宅のデスクで調べ物をする系のタスクに「調べ物」タグをつけたい場合、この「調べ物」はタグにするべきであって、タスクにするべきではありません。「調べ物」というタスクを管理したところで、あらゆる調べ物タスクを適切に管理・遂行できるかというと、できないと思います。一方、タグにしておけば、（日頃から適切に調べ物系タスクにこのタグをつけているのなら）調べ物タグから各種タスクを辿れるようになります。
分類の話
コンテナとはタスクの分類ですが、そもそも分類とは何でしょうか？
分類の一般論を、タスク管理も適宜絡めながら見ていきましょう。
分類のメリット
分類のメリットはコストの軽減 です。具体的には探すコストと切り替えるコストの二つです。
探すコストについては、図書館などがわかりやすいですが、種類ごとにエリアを設けて同じ種類のものを集めておくと探しやすくなります。Aに関するものは分類Aの中に入っている、を保証したいわけですね。分類というと厳密で几帳面なものをイメージしがちですが、雑でも構いません。それこそ「タスクは全部ここに入れます」という箱を一つつくって、全部ぶちこんでしまうのも立派な分類です。
切り替えるコストについては、頭の切り替え――コンテキストスイッチングの話で、同じものをまとめておけば「同じ頭の使い方で扱える」ため楽できます。逆に違うものが混ざっていると、頭の切り替えに苦労します。極論ですが上司として部下を厳しく指導する立場と、子煩悩な親として子供を甘やかす立場は違うわけで、リモートワークの会議中に子供を甘やかしながら部下を厳しく指導するのは難しいでしょう。通常は両方とも独立した時間を確保するでしょうし、間に休憩もはさむと思います。フィクションでは切り替えを一瞬で行う「集中の化け物」が描かれることもありますが、現実的ではありません。
分類の対象と分け方は様々
上記メリットに対して「何を当たり前のことを……」と思われたかもしれませんが、意外とタスク管理では盲点になりがちです。というより分類を応用できる余地は意外と多いのです。
すでに「分類は雑でいいこと」と「頭の使い方を分けること」を挙げています。分類というとタスクを「仕事」「家庭」「趣味」と分けていくことだよねと考えがちですが、それ以外の分け方が色々とあります。何を分類するのか（分類対象）とどこに分類するのか（分類先または分類項目）は様々なのです。
自分で分類をつくる
分類とは「誰か偉い人がつくったものを使う」イメージを持つかもしれませんが、一方で自分でつくることもあります。日常生活では基本的に誰もが何らかの分類を少しはつくっているはずです。
タスク管理も同様で、後者のように自分でつくることが多いです。一方で、「こんな分類をすれば上手くいくよ」という事例やパターンもあり、適宜参考にすると捗ります。それでも自分に合った分類を自分でつくるのが基本だという点はぜひ押さえてください。
逆を言うと、自分で分類をつくっていく気がない人や従うつもりがない人は、雑に向き合う程度で良いでしょう。世の中は分類、特に階層の思想がまだまだ強く、各種ツールやメソッドにも何かとこの概念が現れがちですが、別に無理して従う必要はないです。（タスク管理からは離れますが）この潮流に抗ったのがScrapboxで、階層的な整理をせずに書いても破綻しない Wiki となっています。その本質はリンクであり、ページとページをリンクにより繋ぐことによって、あとから辿ってたどり着けるようにします。人間の脳と同じネットワーク構造なだけであって、これが意外と成立するのです。筆者も23000ページ超えのScrapboxを持っていますが、破綻することなく続いています。この世界観には感動しまして、Scrapboxの解説本を書いたほどです。
と、少々脱線してしまいましたが、分類が絶対的ではないこと、自分なりにやればいいこと、何ならやらなくてもいいことはぜひ押さえてほしいです。分類作業が目的になってしまっているパターン――分類に適応できない自分を責めたり、維持するために苦労して作業を続けたりといったことがあまりにあるあるだからです。タスク管理という言葉も堅苦しくて助長しがちですが、惑わされてはいけません。
コンテナの例とニュアンス
コンテナの例としてプロジェクトやフォルダなどいくつか挙げましたが、本項ではそれぞれの一般的なニュアンスをまとめます。
フォルダ
フォルダ（Folder） は、主にファイルやノートを分類する概念として使われている言葉ですが、タスク管理としても登場することがあります。
たとえば Wrike です。以下引用します。
タスクをフォルダーに追加することで関連情報を1箇所にまとめます。また、スペースの組織構造を構築し、情報の検索や共有を容易にします。 フォルダーはタスクやプロジェクトとは異なり、実行可能な項目ではありません。また、フォルダー自体に一連の属性はありません。 チームや部門全体をカバーするスペースよりも、より小規模で詳細なレベルで使用できます。
フォルダーという字面からは箱モデルを思い浮かべますが、むしろ接続モデルだとわかります。「引っ越し先の家を探す」タスクがあるとして、これを「引っ越し」フォルダーと「待ち時間中にできること」フォルダの双方に入れることもできるわけです。本質的には「引っ越し」タグや「待ち時間中にできること」タグをつけているのと変わりませんが、あえてフォルダーという言い方にしているのは階層性を持たせたいからです。実際にサブフォルダーとの用語もありますし、結局タグと呼ばれますとの説明もあります。
そういうわけで、フォルダーという言葉には階層的に分類するニュアンスがある、と捉えておくと良いでしょう。
カテゴリー
カテゴリー（Category） は、コンテナとしてよく登場する言葉の一つです。直訳しても「分類上の区分」「ジャンル」「範疇」などとなります。
ニュアンスとしては箱モデルです。カテゴリー A に入れたタスクは、カテゴリー B に入れることはできません（あるいは入れるなら A からは取り出すことになる）。1-カテゴリー 1-タスクを守って、きっちり分類するための機能と言えます。フォルダーと同様、階層性を持つこともありますが、持たないこともあります。
グループ
グループ（Group） は、人を束ねる概念とのニュアンスが強いです。タスク管理においてもタスクグループといった言い方で使われることがありますが、あまり例がありません。Yahoo!カレンダーくらいでしょうか。
意味的にはカテゴリーと同義だと捉えれば良いでしょう。つまり接続モデルというよりは箱モデルです。
タグ
タグ（Tag） もコンテナとしてよく登場します。直訳は「札」であり、タスクが性質 A を示す場合に A というタグをつけておく、というニュアンスです。
モデルとしては接続モデルであり、1つのタスクに複数のタグをつけられます。タグもたくさんつくることができるので、雑に運用していると何十何百というタグがすぐに出来てしまいます。これをちゃんと運用するのは不可能に等しく、形骸化します（あるいは良くて「よく使う少数の選ばれしタグ」が運用されている程度）。
X のハッシュタグなど、デジタルツールとしては非常に一般的な概念でもあります。こちらには性質の表明とのニュアンスもあります。ポストに #タスク管理 と書いてあれば、そのポストはタスク管理に関するものですよ、と表明しているに等しいですし、検索もできます。
そういう意味で、分類というよりは性質の表明と捉えるのがわかりやすいでしょう。
ラベル
ラベル（Label） は、タグと同義ですが、色の指定もできることが多いです。
たとえばGitHub Issuesではタスク（を指す単位である Issue）にラベルをつけられますが、このラベルには名前と色があります。重要性の高いラベルを赤色にしたり、廃止や中断を示すラベルを灰色にしたりできるので視認性が上がります。一方で、乱用するとちかちかして見づらくなります。
プロジェクト
プロジェクト（Project） はタスク管理においてトップを争うほどの多義語です。
ざっくりと言えば、すぐには終了しない、ある程度きりのよくまとまった一連のタスクの集まり、とでも言えるでしょう。生活でたとえるなら「引っ越し」はまさにプロジェクトという言葉で捉えられるものだと思います。一方で、ビジネスでは非常に粒度が大きいことがあります。たとえば数年以上継続する大規模な事業もプロジェクトと呼ぶことがあります。
メソッドや体系によってはさらに制約が加えられることもあります。体系として PMBOK では一時的であること（永遠には続かないこと）や独自の成果を生み出すことなどが指定されていますので、延々と続けているルーチン的な作業はプロジェクトとは言えません。メソッドとしては GTD もこの言葉を使いますが、PMBOK とは定義がずいぶんと違います。
と、状況によってだいぶ意味が違いますので、タスク管理として捉えるのであれば、単に「活動」あるいは「事業」の一言で問題ありません。ただツール（とその背景にあるメソッドや体系）次第では何らかの含意が込められていることがあるので、できれば知っておくと良いかな、というくらいです。たとえばツールとしては規模の小さなプロジェクトのみ想定されているから、規模の大きなプロジェクトを管理しようとしてもなんだか上手くいかない、といったことが起こります。前者の想定がわかれば、後者の管理は諦めがつきます。
ワークスペース
ワークスペース（Workspace） は作業場、作業空間といった意味になり、典型的なリッチコンテナです。つまり単にタスクをまとめる単位というだけでなく、タスク以外の情報も色々とまとめます。というより、まさに「場所」を示すニュアンスがあり、仕事中は高頻度に皆が集まってくる場所になりがちです。
タスクについても、ワークスペースに直接ぶら下げるというよりは、さらに別のコンテナが使われます。たとえば、
- ワークスペース
- プロジェクト
- タスク
- タスク
- ……
- プロジェクト
のような形です。
様々な分類対象と分類項目
先ほど分類対象と分類項目は様々だと書きましたが、コンテナとしてよく使われるものを紹介します。
大中小タスク
大きなタスクを小さなタスクに分解するシチュエーションはよくあります。すでに引っ越しの例は述べました。
どこまで分解するかは自由ですが、あまり深すぎても全体像を把握しづらくなるため、3段か、多くても4段がいいでしょう。大・中・小の三段階はわかりやすいと思います。書籍でも章節項の形で目次を構成したりします。PARAメソッドではノートツールが 4 段階までサポートしていることに注目しています。4 Based と呼んでおり、人間のワーキングメモリ含め色んな研究結果を踏まえているそうです。
3 段にせよ 4 段にせよ、このような階層的分類において重要なのは、各階層のニュアンスを固定することです。たとえば小タスクは一日以内に終われる具体的なもの、中タスクは小タスクの集まりで特定の目標を表現したもの、大タスクは中タスクの集まりで特定の方向性を表現したもの、とすれば、どのタスクを大中小どこに入れるかもわかりやすいですよね。方向性は大タスク、目標は中タスク、そして具体的な個々のタスクは小タスクで捉えて、中タスクを満たすにはどんな小タスクをこなしていけばいいのかとか、大タスクを満たすにはどんな中タスクを集めていけばいいのか――といった感じで当てはめていけるようになります。
タスクと情報の仕分け
特にメールがわかりやすいですが、受信箱に届いたメールを色んなフォルダに分類すると思います。このとき、特にメールは「タスク」と「情報」に分かれます。大半は情報ですが、たまにタスクも混ざっています。タスクを表すメールついては「タスク」フォルダをつくってそこに入れたり（箱モデル的）、あるいはフォルダには入れないが、タグやマークをつけたりします（接続モデル的）。
と、このようにタスクと情報を区別するシチュエーションもよくあります。割合としては情報の方が明らかに多く、逆にタスクの方は少ないので、後者のタスクの方をコンテナとして特別扱いすると良いでしょう。箱モデルで分けるのか、接続モデルで付けるのかは人次第です。人によって箱モデルが適していたり、逆に接続モデルで雑に付けた方が上手くいったりします。ここは本当に人次第ですので、自分がどちらに合うかを探りたいところです。
いずれにせよ、重要なのは タスクだとわかった時点ですぐにコンテナに入れる（つける） ことです。あとでまとめて行うのは苦しくて、たいてい形骸化しますので、日頃からすぐにコンテナに入れる癖をつけておいた方が良いです。こう言うと「通知や受信が来る度にすぐ分類するのか」と思われがちですが、そうではありません（慌ただしいとそれしかできなくなりますが）。どちらかと言えば、チェックする時間を設けてそこで一気に行ないます。メールでいうと、たとえば一日朝、昼、晩と三回くらいチェックするタイミングを設けて、そこで一気に仕分ける（タスクをコンテナに入れる）のです。
と、このように、タスクと情報の仕分けはそれなりに奥が深いです。特に情報は多いですから、いかに省力化してタスクという本質だけをさっさとコンテナに入れられるかがポイントになります。メーラーの話になりますが、HEY など、まさにこの仕分けの部分を明示的に強化したツールもあったりします。
コンテキストタグ
筆者は コンテキストタグ（Context Tag） と呼んでいますが、タスクにつけておく「いつ実行できるのか」「どんな性質なのか」を示す用のタグを使うと便利です。
たとえば通勤中、電車内やバス内でこなせるタスクには「通勤中」タグを付けておきます。すると、車内にいるときにスマホで通勤中タグの一覧を見ることでタスクをこなせるわけです。あるいはもっと単純な例は「あとで読む」タグです。より生々しい例で言うと「夫がいないとき」タグや「上司がいるとき」タグも使い所が結構あります。特に忙しい人は対人関係が多い人は、この手の制約が色々あるはずですから、コンテキストタグとして上手く反映してやると、スキマ時間などでガンガンタスクを消化しやすくなります。
セクション
戦略の章で少し述べましたが、時間帯のことを セクション と呼びます。人はどの時間帯に何をするかが大体決まっているので、セクションをコンテナと捉えて、タスクをどのセクションに入れようかと考えると生活が円滑になります。
筆者の場合、生産的・創造的な仕事は午前中が捗るとわかっているので、午前セクションに入れるようにしています。もっと言えば「1: 起床後から出勤までの間」、「2: 自分が出勤してから皆が出勤するまで」、「3: 皆も出勤してきた後の午前残り」と 3 つのセクションがありまして、1 にて一番やりたいこと、2 にて仕事で集中してやりたいことをやるようにしています。3 は同僚からの割り込みがあったり、会議があったりするのであまり集中できません。
コンテナのパピプペポ
コンテナのパピプペポとは、コンテナとしてありがちな使い方をパピプペポで整理したものです。
| 1文字 | カナ | 英語 | 意味 |
|---|---|---|---|
| パ | パーパス | Purpose | 目的や目標。大タスクや中タスクになる |
| ピ | ピープル | People | 人。どの人に何を任せるか、何を言うか（インプットしておくか） |
| プ | プレイグラウンド | Playground | 遊び場。遊びたいこと、やりたいことを雑多に入れておく。おもちゃ箱 |
| ペ | ペンディング | Pending | 待ち。何らかの事情で待ち状態になるものを入れておく。GTDでいう「連絡待ち」 |
| ポ | ポスト | Post | 受信箱と送信用下書き箱。届いたものや外に出す（発信や投稿や提出）ものを一時的に溜めておく |
パーパスやポストやペンディングのような真面目な用途もあれば、プレイグラウンドのような不真面目に見えるものもあります。
ピープルは半ばこじつけですが、人をコンテナとみなして、誰に何を入れておこうかと捉えています。人はツールではないので不確実性が高いですが、同時に人という存在はツールよりも覚えやすく親しみやすいので、案外役に立ちます――というより、ツールよりも人で捉える人の方が多いかもしれません。筆者は「コミュニケーション1.0」と呼んでいますが、人には「常に特定の具体的な誰かを想定する」というメンタルモデル（行動特性）があると思っています。情報共有の観点では皆に見える場所に情報を置くことが重要ですが、これが出来ない人が多いです。なぜかというと、1.0のメンタルモデルでは扱えない行動だからです。タスク管理もそうで、特定の人を想定するとは限らないため、1.0にとらわれている人にはやりづらいと考えられます。なので、開き直って「誰に何を言うか」に帰着させてもいいわけですし、ツールでやりたいなら、たとえば上記のコンテキストタグを使って「Aさん」タグをつくって、Aさんが絡みそうなタスクにこのタグをつける、とかをしてもいいわけです。ピープルコンテナは、1.0の人には親しみやすい考え方だと思います。
と、このように、コンテナの扱い方に決まりはありません。真面目だろうと不真面目だろうと、あるいは厳密だろうと雑だろうと、やりやすいやり方でいいのです。
まとめ
- コンテナとはタスクを分類するもの、あるいはしたもの
- 本質的には分類の性質が当てはまるが、タスク管理の文脈ではさらに特徴がある
- タスクのみを分類したものと、タスク以外も含めたもの（リッチコンテナ）がある
- 箱に入れるモデルと、性質を付けるモデルがある
- 「それはタスクか？コンテナか？」の判断は人次第、状況次第であり、正解はない
- 自分で分類をつくってもいいし、雑に分類してもいい
- 既存の用語や活用事例も色々あるので、押さえておくと生かしやすい
- フォルダ、カテゴリー、プロジェクトなどの用語
- コンテキストタグやセクションなどのセオリー
- コンテナのパピプペポ