「情報を整理する」はタスク？
玄武.icon
直接は実行できないプロジェクトかもしれないです。
「情報を整理する」に含まれる例えば「データAをデータBに移す」といったことがタスク。
タスク管理といった場合、いかに「データAをデータBに移す」かといったことに焦点があたる。いかに「データAをデータBに移す」かといった問いに答えるのがタスク管理と言い換えられる。
rashita.icon自分が望む状況に至る為には、「データAをデータBに移す」ことが必要だなと思うことと、その「データAをデータBに移す」をどうすれば実行できるかを考えることが違う、というような意味でしょうか。
玄武.icon「いかに「データAをデータBに移す」かといった問いに答えるのがタスク管理」の中身は、『自分が望む状況に至る為には、「データAをデータBに移す」ことが必要だなと思うことと、その「データAをデータBに移す」をどうすれば実行できるかを考えること』のどちらも含む意味のつもりだったのですが、すみません、『いかに「データAをデータBに移す」かといった問いに答えるのがタスク管理』と書くと後者の『「データAをデータBに移す」をどうすれば実行できるかを考えること』しか含まないように読み取れるような書き方でした。
では、いかに「情報を整理する」かといった問いに答えるのは？
タスク管理ではなく情報整理が扱う範疇。
そこで問われているのは何か。
どこかで情報が発生し、それをキャッチし、しかるのちに分類項目を決定し、それに合わせて処理を行うこと、といったフローの手順（あるいは構成）を問うているのか。
ちなみに、上はようするにGTD的であり、GTDのあの部分は「情報整理」していると言える。タスク管理の中にある情報整理機構
そもそもGTDを一般的な文脈の「タスク管理」において良いのかは実際きちんと検討されるべきだろう。特に日本語のGTDが『ストレスフリーの整理術』であって、実はタスク管理的なものよりも情報整理的なものを想起させるから。
たとえば、上記のようなフローは、一つ一つは行動（実行できる行動）で構成されてはいるものの、そのようなフローを構成することを「タスク管理」と呼ぶかどうかは微妙なところ。少なくともrashita.iconの語感には合わない。
いくつか理由が考えられる。
フローの手順は、一種のモデルの構築であって、「具体的な行動」はそのモデルからの派生として生まれているから。
上記のフローの手順の構築と、「今上司から会議の設定を依頼された。えっと、やらなきゃならないことはなんだろうな。まずメンバーに告知して、……」などと具体的に行動に分解していくことには違いがあるように感じられる。こちらは、明確に「タスク管理」に加えられる。
また、フローが流れる中で、「しかるのちに分類項目を決定し」というときに、その決定がいかに行われているか（どのような基準によって意思決定を行うか）が極めて重要だと思うが、その基準の設定および正当性の評価は、はたして「タスク管理」の範疇なのだろうかとも感じる。
これは、rashita.iconの認識における「タスク管理」の階層の話
こうしたものすべても、極端に言えば、実行される行動なわけで、それをタスクと呼んで「すべてはタスク管理である」と呼ぶことは不可能ではないと思うのは以前も検討した。
玄武.iconは『こうしたものすべても、極端に言えば、実行される行動なわけで、それをタスクと呼んで「すべてはタスク管理である」』の認識でいますね。
ただ、これはタスク管理のなかにタスク管理が入れ子状態になるので、理解を妨げる（＝わかりやすくない）ということは言えそうです。
ただ、タスク管理としてみたときの「情報を整理する」は、どういったものになるのかが個人的に気になります。