TODO 管理の方法を GTD っぽくしようと考えている

ブログを再開したと言ってるが、 結局前回の記事を書いてから1週間ほど経過している。 ま、1週間しか間が開いてないという前向きな考え方もできるのでそっちで考えておこう。

このところは org-mode によるタスク管理もうまくいってないというか 管理がだるくなって放置している……。

今のところ業務の種類でファイルを分けつつ さらに日別でファイルを作ってるので、 ファイルの移動がだるいのと毎日ファイルを作って定期的に整理するのだるいことが分かってきた

というわけで、今度は思い切って1ファイルで管理しようと思う。 既存の区分けはタグでも使えば代用できるだろうし。

今のところは大体以下のような構成になってる

• tasks

  develop.org

  開発系タスク

  interupted.org

  割り込みタスク

  management.org

  管理系タスク。といいつつ雑用を突っ込んでる

  research.org

  調査タスク

  reviews.org

  レビューしないといけないやつ

  各日のファイル

  2020-04-01.org みたいな感じ

• old_day_files
  • 各日のファイルを適当なタイミングで移動してきている

各日の中身はこんな感じになってる

* 休憩
** 昼休み
** その他
* 会議
** 朝会
** 夕会
* その他
* Report

って感じ。 Report 部は org-clock での計測結果を入れてる。

ほんで、これをやってると タスクを積むのがどのファイルだったっけみたいになってる。 org-mode を使ってるから org-agenda でアクセスはできるはずなんだけどね。 積む時も org-capture で積めるし。

まあやっぱりこれまでの人生でタスク管理をまともにやったことがなく 基本的に脳内メモリで処理していたし、今のところ割とそれでまだ回ってるので ま、ある意味使わなくてもそれほど問題ない気がする……。

あと TODO リストの優先順位が低いタスクが増えていく問題、 みんなどう解決しているんですかね。 大体 TODO リスト管理をしなくなって来るのって それが溜まってしまってげんなりするところにある気もすんですけどどうでしょう。

ま、それはともかくとして、 一旦自分が知ってるタスク管理方法である GTD に近い感じにしてみる。

ファイル構成は

• tasks

  gtd.org

  基本はこっちに放り込む

  interupted.org

  割り込みタスク

ぐらいにしておいて、gtd.org の中身は

* Next Actions
* Projects
  いつかやるやつも含めたタスク
  ステータス等はタグで管理
* Daily log
  定例会議などの定期タスクや
  org-clock の計測結果を突っ込むところ。
** YEAR
*** MONTH
**** DAY
***** 会議
***** Reports
* Pointers
  整理の結果資料として保管することになったもの
* Inbox
  ひとまずタスクを溜めるところ

ぐらいにする。 Inbox に色々溜め込み、 ちょっと先の TODO は Projects に移動し、 資料は Pointer に移動する。 要らない作業はさくっと消すか archive SOMEDAY はステータス管理にしておく。 Next Actions はその日でやるタスクを入れると。

Daily log という概念は GTD にはないけど org-clock の計測結果を入れたいし、 あと会議などの定期イベントはそっち側で管理して時間計測する

ここに入れる際にはそれなりに分割するのが良さそう。

というのも GTD とスクラムのバックログの考え方が似てるなと思ってて Projects はプロダクトバックログ、 Next Actions はスプリントバックログ、 そして1スプリントが1日と考えると、大体似た感じかなという気がしている。

というわけでスクラムのプラクティスで考えると スプリント開始前、即ち始業時にでも計画を立てて スプリント終了時、つまり終業前にふりかえりをしたら良さそう。 終業前に両方やることも考えられるけど。

さて、そうすると、プロダクトバックログリファインメントにあたる行為をいつするかが悩ましい……。 毎日やるとしたら、ふりかえり前後か。

終業直前にこの手の定期イベントを入れると 業務上のイベントと重なりがちなのが困るな……。まいっか、ひとまず。

ステータスは

• TODO
• DOING
• Waiting
• DONE
• SOMEDAY

ぐらいで考えてる。

あとは元々ファイルとして分類してたやつをタグで分類する感じで

• Management
• Develop
• Review
• Research

とする。

基本的には1日の中で

• 実作業
• リファインメント(Projects の見直し、分割)
• ふりかえり
• 計画(Inbox の整理、Next Actions へ移動、分割)

をやっていく感じで進めるか。

あとは GTD の考えに則り、週1ぐらいで別途見直しをする工程を入れてもいいかもしれない。

という大体の方針が決まったので、しばらくそういう運用をしていこうと思う。 さて、なんか結構色々詰め込んでしまった気がするが果たしてうまくいくか……。

GitHub Issues から記事の下書きを作れるようにしている

Issue 上で書いてる内容

ブログの記事を書くのをより手軽にしたいなと思い、 Issues に特定のラベルを貼って立てたらそれがブログの記事の下書きになるようなやつを作ってる。

元々は Emacs で下書きを書き始められるようにはしているものの、 Emacs は時々何かの拍子で設定をぶっ壊してしまっているので たまに書こうと思った時に本当に動くのか心配になってしまってかえって書く気力が削がれるのと Emacs なので PC を開いて作業する必要があって、 現代的なスマホの民としては、結構それがだるい。

というわけでなんとかブログ記事を書き続けられるようにということで そうやって書けるようにしようとしている。

seesaa blog に書いているので、 そっちにログインして書くという手口ももちろんあるんだが、 元データは別で残しておきたいという願望があるので そっちに直接書いてしまっては本末転倒なのである。

なぜ別で元データを残しておきたいかは、 引っ越しとかしたい時にデータを抜いて来るのがだるいし、 わざわざそこから加工することになりそうだから。

というわけで早速今この記事を GitHub Issue で書いている。 一応、Issue を書いたら org 形式にして PR を作るところまでは大体テスト済。

テスト済なんだけど、実際に動かしてみる、というテスト手段になってしまってるので ここは改善が必要だなと感じている。

現状の作りは GitHub Actions 用の yml ファイルにゴリゴリに steps を書いているのだけど 多分、それが良くないなと感じている。

多分、他のやつでよく見るように Node.js などの他言語にメインの処理はやらせて そのメインの処理に対してテストを書くような仕組みがいいんだろう。 自分の場合だと Ruby で書くのが妥当か? ただわざわざ Ruby まで使うような処理でもない気がするから Shell Script で留めたい気持ちもある……。

ま、一旦これで Issue を立てて続きは Emacs からにする Issues から記事の下書きを作れるようにしている.org

Issue から作られたファイルを編集してる時に書いたやつ

ちょっと対応が雑でダメだったところがあるのに気付いた

• Issue タイトルをそのままファイル名にしようとしてるが空白文字が入ると Shell Script でアレになる
• Issue の body の本文は \r\n で改行されてるので \r を取り除かないといけない

というわけで後でその対応を取り入れる必要がある。だる。

他にもやらないといけないなと思ってるところはあって それは、PR をマージしたら自動で記事を作成するとかそういうの。 今だとそれは用意してないので、手元から Publish する必要がある。

あと seesaa blog って API からカテゴリは設定できても タグが設定できない気がするけどどうなんだろ……。

ま、いいや。どうせこれ日記レベルだしタグはなくても。

ブログを再開することにした

昔はよく頑張ってブログを書いてたなあ偉いなあと思って ブログを再開するこにした。

元々は技術ブログという位置付けだが、 こうも更新してないと、まずは更新することを優先した方が良さそう。

ちょうどいいことに seesaa-blog-mode という 自分がブログを書くための、 自分が使ってるサービスで使える Emacs 拡張を遥か昔に用意していたので 一旦それをそのまま使って元々持っていたブログの方を更新することにする

といっても、更新をサボってたからか書くことはあまり思い付かない。

ひとまず、今後の構想的なことを書くと 上述の seesaa-blog-mode はメンテも特にしてないしユーザーもいないはずなので 必要な機能を GitHub Actions に持って行こうかなと考えている。

必要な機能というのは、 org-mode で書いてるソースからそれっぽい感じに HTML に変換してくれる機能と、 seesaa-blog に投稿する機能ぐらいかな。

で、GitHub Actions にするにはリポジトリが必要なので とりあえず private でそれ用のリポジトリを用意した。 そこにはこのブログ記事の元データの方を保存するつもり。

そういえば過去の記事も org で書いててどこかに元データはあるはずなんだけど オンライン上には保存してないので、今どこにあるのかよくわかってない。 ま、探せたら探そう……。

あ、そうだ。 多分、機能としては、ソースと投稿後の URL とを紐付ける機能もあった方がいいな どういう紐付け方をしたらいいのかは思い付いてないけど、 ま、実装する時に考えれば良かろう。

さて、そもそもブログ再開してどれぐらい続くかな…… 前回は結構すぐ止まったし。