タスク管理について考えてみる
はじめに
世の中にはたくさんのタスク管理方法があり、色んなタスク管理アプリがある。タスク管理機能だけのアプリであったり、SaaS の拡張機能としてあったり、それ扱うタスクの「性質」や扱われる「環境」はさまざまである。何を大切にしたいか、それは集団にとってなのか個人にとってなのかによっても変わる。主観的に、その様は宗教と何らかわりがないように見える。
エンジニアは常日頃性質の異なるタスクに追われているイメージが個人的にある。そのため、状況に合わせたタスク管理方法や、自分のベストプラクティス的なものがあるイメージを持っていると勝手ながら感じている。それは多くの場合〇〇駆動開発的なところで見え隠れしている。
そういったことを思いながら、タスク管理というものについて記してみようと思う。あまり散文になり過ぎてもいけないので、ここでは「性質」と「環境」に分ける。
性質
タスク管理上、最低限以下の情報が必要であると考える。
- 何をするか
- 完了状態（ステータス）
- （誰がやるか）
人によっては単純に終わったかどうかでよい場合もあるが、複数人で、しかもチェックルーチンが入る場合はもっと細かく状態を見る必要がある。コーディングであれば、記述が終わってもプルリクが通らなければ終わったことにはならないなど、「やったから終わり」ということがない場面であったりする。
複数人が対象となる場合は、加えて誰がやるかが必要になる。一人なのか、あるいは複数人なのか。多くのタスク管理ソフトは肌間だが、一人にしか割り当てられないように感じる。責任者という意味ではその通りだと思うが、作業者という意味ではいささか不便が生じる。
また、共通してタスク管理で必要なこととして一覧性が高くなければならないと考える。そうでないとそもそも「管理」がしにくく、健全とは言えないと考える。
日付・時間・期間
タスクによっては「日付」「時間」「期間」が必要になる場合がある。
これが非常にややこしく、「開始」「終了」「締め切り」など、時間的性質を示す情報というのはそこそこ多い。加えて、この時間管理ができるかは本人の力量に依存するので、設定しても上手く機能するとは限らない。
タスクと似ているものとしては「予定」だと考える。「予定」として以下のような情報が必要だと考える。
- 何をするか
- 日付
- （時間）
- （期間）
「予定」には「完了状態」を含まない場合がある。時間が過ぎればおおよその場合、完了状態と考えて良い。人によっては「予定」≒「タスク」と捉えて良い場合もある。ただし気を付けなければならないのは、似てはいても確実に「予定」≠「タスク」であることは忘れてはならないということである。
グループ化
タスクは日頃さまざまな場面で無限に増えるので、同じレイヤにすべてまとめてしまうと、分からなくなってしまう。そのため、何がしかの方法で整理する必要がある。
たとえば「家庭」「仕事」「趣味」などといったように、分けるだけでも効果的である。それぞれそのタスクとしての性質も大きく異なる。「仕事」であればあらかじめ 1week 程度タスクを積んだりはするだろうが、「趣味」であればある程度行き当たりばったりでも良いかもしれない。「家庭」のことを考える際に、「仕事」の情報なんてものは目に入るだけ毒である。
グループ化は、以上のように特定の括りでまとめることとする。グループ化する際には、セレクト、マルチセレクトはそれぞれあると良いかもしれない。このあたりの考え方を突き詰めるとタスク管理は「プロジェクト管理」になると考える。
関心度合い（重要度）
これはグループ化に似る所がある。しかし「重要かどうか」は単純なグループ化よりも特筆されることが多いと考える。「重要かどうか」なのか、「どのくらい重要なのか」なのかによっても扱い方は変わる。これを重視する前に、そもそも「場当たり的な作業」が多く存在してしまうことが問題の場合があり、それを踏まえずにいると結局「全部重要」みたいな形になる。いかに「先のタスク」を見据えられるかも、それはそれで重要な要素なのかもしれない。
親子関係・前後関係
こういった管理系のことを考えると、必ずといっていいほど粒度の問題が出ると考える。タスク管理において、それの 1 つの解決策としてタスク間の相関関係の設定だと考える。
類似したものはある意味それもグループ化し、詳細な内容は”サブタスク”といった形で管理する場合がある。そうすると、「めちゃくちゃタスクが貯まって見るだけ嫌になる」といったことは避けられる。
また、それとは別に前後関係を作ると状況が整理できて良い。どのタスクをどの順番に行わなければならないかがわかると、タスクも取り掛かりやすいと考える。
環境
タスク管理を考える上で気にしなければならないものの中に、それを行う環境があるだと考える。そもそもタスク管理をしても失敗する場合と成功する場合と、結果はさまざまで、多くの場合失敗に終わっていると考える。これは、タスク管理をする前に環境を整えてあげないといけないということだと考える。
コミュニティ
ここで、自分 1 人の状態であってもそれを「1 人のコミュニティ」ということとし、もちろん 2 人以上の場合もコミュニティということとする。このとき、タスク管理をする上では以下のことを前提であると考える。
- タスク管理に対するモチベーションが近い
- 計画する意義を共有できている
- 負の感情を発露しない
- ツールを使用する場合、全員が最低限の理解があり、操作ができる（自分で管理する意識がある）
モチベーションに差があったり、負の感情の発露が多かったりすると、そもそもコミュニティにいたくないと感じる。ツールを利用する場合は、ある意味それが共通言語のようなものになるので、「分からないから仕方ない」となってはいけない。
実装環境
多くの場合は「よく使用するツール」の中にタスク管理の機能があると良いと考える。エンジニアであればツールが増えようが、元々使っている多くのツールにちょっと加わる程度なのかもしれないが、大体の人はそういうわけにいかない。
Goole Calendar であれば「Todo」かもしれないし、GitHub であれば「issue」なのかもしれないし、業界向けアプリなのかもしれないし、そもそもそれでは手に負えないから専用のプロジェクト管理サービスなのかもしれない。
実装する環境の選定基準としては使用者の人数かもしれないが、多くの場合はツールに対するアレルギーが低い状態を以下に作るかであり、それが上手くいった環境に実装するのが良いかもしれない。
おわりに
散文であるが、タスク管理について大きく「性質」と「環境」で分けて考えてみた。あまり断定できるようなことは少なく、結論という結論は正直出しようがないと考える。偉そうに書いているが、正直自分も上手くいっていないのでこうして考えているという。
基本的に一人でいれば、管理なんて大仰なこと言わなくてもいいかもしれない。ただ、ちょっと難しいことをしようとし始めると、人手が必要になり、自分でやった方が早いことも誰かに任せなければならない時は出てくるものだと考える。そうなると、適切なタスクを設計しなければならないし、それを管理しなければならない。もっと言ってしまえば、モチベーションすら保つようにしないといけない。そこまで考えると、単純に「タスク管理」なんて感情のない言い方は段々不適切な気もしてくる。とかなんとか、話が脇道に逸れていく。
結局のところ、その管理すべきタスクを設計するのがもっとも大変だったりするのは、如何せん卵鶏な話だと感じる。それを上手く設定してあげる・または指導してあげるのも、管理者の役割なのかもしれない。そうでないと、おそらくタスク管理は上手くいかないと考えるこの頃。
Discussion