« ^ »

タスクのゴールを管理する方法について考える

所要時間: 約 5分

抱えているタスクが一定量を越えると、手が止まり足が止まり、途端に何もできなくなる。この状態をなんとかできないかと考えて、今まで様々な取り組みをしてきた。

手が止まってしまう理由の一つは、ゴールの設定が出きていないからだろう。どの状態となったら、そのタスクが終わるのか、これを具体的に想像できていないと、何をやっていいのかも分からず、時間だけが過ぎていく。ただし、実際には手を付けてみないと、ゴールが想像できない事も多い。その場合はタスクを分割し、小さく管理するというのはよく行われる手法だろう。しかし小さいタスク管理は、それだけで重い作業となるし、小さいタスクでさえ具体的なゴールがイメージできていないと、やはり作業中に迷いが発生する。この迷いが作業の進行を邪魔する。

逆に、やる事が明らかで、迷いのない作業は総じて早く、品質も高くなるだろう。タスク精度と速度はゴールをどれだけ具体的に想像できるかと関係している。具体的な想像は、一時的には頭の中でできても、すぐに忘れてしまう。だから文章として残す必要がある。

こんな事を考えていた。

今回は、タスクとゴールの連携を強化し、ゴールの設定や変更を小さい認知的負荷で行えるように、org-agendaで一覧を目で確認できるようにする。

org-agendaにはカスタムコマンドという機能があり、特定のキーでカスタマイズされたビューを構成する事ができる。ここでは G というコマンドを追加し、=GOAL= プロパティとして設定されているゴールと、タスクを表示する。

(org-add-agenda-custom-command
 '("G" "Goal List"
   ((todo "TODO" ((org-agenda-overriding-header "TODO items:")
                  (org-agenda-prefix-format "%50(org-entry-get nil \"GOAL\" nil) |  ")
                  (org-agenda-sorting-strategy '(priority-down deadline-up))
                  (org-agenda-todo-keyword-format ""))))))

このビューでは以下のような表示となる。

TODO items:
                                               bbb |  XXXXX確認
                                               nil |  リリース判定会
                                               nil |  進捗確認
                                XXXXを開いて眺める |  BBBBBB確認
                                               nil |  log確認
                                               nil |  新規issue確認
                                               nil |  リファクタリング
                                               nil |  内容をまとめる
                                               nil |  デプロイ
                                               nil |  stagingでの動作確認

左側が設定されたゴール、右側がタスクの表題だ。ゴールがnilになっているタスクは、ゴールが設定されていない。このゴールが未設定のタスクが問題を起こしがちだ。このタスクにゴールを設定しつつ管理していく事にする。

次に、このnilの部分を間接的に編集できないかと考える事にした。

勿論 org-agenda-switch-to 1 を使いorgファイルに移動して編集する事はできる。ただ、それでは何度のバッファを行き来する必要がある。

私が学んだ事の一つに「画面の切り替わりは認知的負荷を与える」という事がある。何げなしに起動しているアプリケーションを切り替えていないだろうか。切り替えの度に、操作方法、見るべき場所などを頭の中で切り替えなければならない。この認知的負荷は集中力や、やる気を奪っていく原因となる。これと同様のことは、例えばWebブラウザのタブ機能にも同じ事が言える。目の前にあるパソコンやスマホで起動しているWebブラウザのタブを、今いくつ開いているだろうか。2個以上開いたら、少しずつ精神力を削られている。実際の作業や活動では、1つのタブで全てを行うなんて事はないだろうし、1つのアプリケーションに引きこもれるわけでもない。ただ、複数の何かが開いている時は、認知的負荷を受けていると考えている。少し面白いのは、Emacsのバッファは認知的負荷にそれほど影響を与えないような気がする事だ。一方で elscreen のような拡張で、Emacsにタブ機能を導入してみた時は認知的負荷が高いと感じた。これは個人的な感想だから、絶対にそうだという事柄ではないのだけれど、私には視覚的に「切り替えられますよ」とアピールしているような機能は、認知的負荷を高める要因となるように思えた。ただし複数の画面の状態を保持しておきたい時は、突発的にやってくる。Emacsでは、それは特に気にする必要はなく M-x make-frame RET 2によって、新しいフレームを作成すれば良い。必要なくなったら、そのフレームは閉じてしまって、フレーム1つだけに戻る。この操作がとても楽に感じている。

話がだいぶ逸れてしまった。バッファの切り替えは、それほど認知的負荷が高くないとはいえ、何度かキータイピングを行わないといけないし、多少の認知的負荷もかかる。そこで、一覧表示されているバッファ上から編集できるようにするという事だ。

org-agendaのアジェンダビューでは、状態の変更などができるように実装されている。このゴールビューでも、同様の方法で GOAL プロパティの変更が出来れば良い。

アジェンタビュー上でのプロパティの書き換えには org-agenda-set-property が提供されているが、プロパティ名を固定できず、どうも痒い所に手が届かない。そこで、その関数をコピーして、新しく GOAL プロパティの設定関数 org-agenda-set-property-goal を実装した。

(defun org-agenda-set-property-goal (goal-string)
  "Set a property for the current headline."
  (interactive "MGOAL> ")
  (org-agenda-check-no-diary)
  (org-agenda-maybe-loop
   #'org-agenda-set-property nil nil nil
   (let* ((hdmarker (or (org-get-at-bol 'org-hd-marker)
			(org-agenda-error)))
	  (buffer (marker-buffer hdmarker))
	  (pos (marker-position hdmarker))
	  (inhibit-read-only t)
	  ) ;; newhead
     (org-with-remote-undo buffer
       (with-current-buffer buffer
	 (widen)
	 (goto-char pos)
	 (org-fold-show-context 'agenda)
	 (org-set-property "GOAL" goal-string)))))
  (org-agenda-redo))

ゴールの設定後に、表示を更新するために org-agenda-redo を呼び出すことにした。やり方は少し雑だが、特に問題は無さそうだ。


1

私のキーバインドでは RET に割り当てている。

2

私のキーバインドでは s-t に割り当てている。