機能 #113
完了[Redmine] 常時遂行・バックグラウンドのタスクの管理 (2024-01)
100%
説明
一般的な “タスク” と異なり、 daemon のように日常に薄く広がって常時遂行している扱いになるべきチケットがいくらか存在するため、これらについて適した運用を考えたい。
たとえば基本的には放置できる設備・備品の運用のメタチケット (例として #96 等)、行動傾向の調整 (例として #61 等)、中長期目標 (例として #78) 等がある。
これらは扱いとしては確かに「進行中」ではあるものの、何らかの作業を必要としているわけではない場合が多いため、何か隔離する仕組みかカスタムフィールドを考える必要があるかもしれない。
あるいは、せめて作業を要求するタスクよりも目立たせない工夫はしたい。
たとえば優先度を最低にするなどは考えられる。
NO nop_thread さんが2年以上前に更新
- 題名 を [Redmine] 常時遂行・バックグラウンドのタスクの管理 から [Redmine] 常時遂行・バックグラウンドのタスクの管理 (2024-01) に変更
NO nop_thread さんが2年以上前に更新
- 説明 を更新 (差分)
NO nop_thread さんが2年以上前に更新
- 関連している 機能 #112: [Redmine] 設備管理用トラッカーの検討 (2024-01) を追加
NO nop_thread さんが2年以上前に更新
機能 #112: [Redmine] 設備管理用トラッカーの検討 (2024-01) にも同じことが言えるが、そもそも Redmine のチケットステータスそのものについてのメタデータが「終了したチケット」フラグしか存在しないことが事を面倒にしている。
カスタムフィールドがステータスに全自動で連動して設定されてくれればそれでも良いのだが。
自分で書くしかないか？
NO nop_thread さんが2年以上前に更新
- 関連している 機能 #118: [Redmine] チケットのステータスそのものに属性を追加したい (2024-01) を追加
NO nop_thread さんが2年以上前に更新
- pinned を いいえ にセット
NO nop_thread さんが2年以上前に更新
- 説明 を更新 (差分)
NO nop_thread さんが2年以上前に更新 · 編集済み
行動傾向 #136: [今月の趣味] 2024-02 のようなチケットを 03-01 に更新しようとすると「2024/02/29 (1日 遅れ)」と表示されるのは、あまり体験が良くない。
そもそもこのチケットの「適用期間の終了」は 02-29 で、それ以前にチケットを閉じることは基本的に想定しない。
閉じるとしたら必ず適用期間の終了よりも後のはずである。
ところが Redmine 標準の「期限」の意味は、行動の完了期限、また行動完了に伴ってチケットを閉じるまでの期限といえる。
つまり期限よりも前に閉じるのが正常ということになる。
これらの2つの用法は性質が大いに異なるものであり、常時遂行やバックグラウンドの状態管理の終了予定日に「期限」フィールドを使うのはおそらく適切ではない。
「期日」フィールドを使うのをやめて、カスタムフィールドを作るか「確認予定日」 (#148) を流用するなど別の手を考える必要がありそう。
NO nop_thread さんが2年以上前に更新
- 優先度 を 通常 から 高め に変更
月1回まとめて提出する通勤費申請のためのチケット (#156, private) ではコメント機能を使って勤務実績のログを残すなどしており、これは前半が常時遂行タスク「ログ追加」で後半が作業タスク「申請記入と提出」になるというハイブリッドなパターン。
この場合チケットを分割するかは悩ましいところだが、いずれにせよ常時遂行・バックグラウンドのタスクは実用したくなる概念であることがわかったので真面目に考えることにする。
個人的には分割するほどのことではなく単一のチケットで済ませば良いと思うが、そうなるとワークフローをしっかり考える必要がある。
「バックグラウンド」トラッカーのようなものを用意してしまうのは必ずしも適当とは限らないということである。
(トラッカーを途中で変更することをワークフローに組み込むのは流石に暴挙が過ぎると思う。)
NO nop_thread さんが2年以上前に更新
- ステータス を 新規 から 進行中 に変更
NO nop_thread さんが1年以上前に更新 · 編集済み
サブスクリプションやインフラ等も類似の「有効な間存続」系のチケットで管理できそう。
NO nop_thread さんが1年以上前に更新
- 関連している 機能 #507: [Redmine] 持続する契約の管理 (2024-10) を追加
NO nop_thread さんが1年以上前に更新
- 前回確認日 を 2024/10/15 にセット
nop_thread さんは #note-11 で書きました:
サブスクリプションやインフラ等も類似の「有効な間存続」系のチケットで管理できそう。
バグ #529: [Redmine] 設備・備品管理の方法を再検討 (2024-10) の description で記述したが、そもそも Redmine のチケットや関連の概念は状況追跡と相性が悪い可能性がある。
ひとまず範囲を限定して設備と備品について #529 で検討するが、おそらくその結果をこのチケット (113) にも反映することになりそう。
NO nop_thread さんが1年以上前に更新
- 関連している バグ #529: [Redmine] 設備・備品管理の方法を再検討 (2024-10) を追加
NO nop_thread さんが1年以上前に更新
- 関連している 機能 #94: [Redmine] プロジェクトの単位 (2024-01) を追加
NO nop_thread さんが11ヶ月前に更新 · 編集済み
- 前回確認日 を 2024/10/15 から 2025/08/28 に変更
nop_thread さんは #note-8 で書きました:
行動傾向 #136: [今月の趣味] 2024-02 のようなチケットを 03-01 に更新しようとすると「2024/02/29 (1日 遅れ)」と表示されるのは、あまり体験が良くない。
そもそもこのチケットの「適用期間の終了」は 02-29 で、それ以前にチケットを閉じることは基本的に想定しない。
閉じるとしたら必ず適用期間の終了よりも後のはずである。
ところが Redmine 標準の「期限」の意味は、行動の完了期限、また行動完了に伴ってチケットを閉じるまでの期限といえる。
つまり期限よりも前に閉じるのが正常ということになる。
いくつかのアイデアはある。
- 終了フラグは立っているが後始末が残っている状態 (「ふりかえり」ステータスとか？) を用意しておく
- 遅延未完タスクとして扱われないのはメリット。
- タスクとしては残っているのに未完タスク一覧に表示されないのはデメリット。
- 期限を適宜更新する
- チケット内の直近のタスクの期限をチケットの期限として設定しておくということ。
- そもそもチケットの期限としてチケットの期限でないものを設定することになるのがデメリット。
- 機能面では「リマインド予定日」カスタムフィールド (#148) に近いかもしれない。
- 「リマインド予定日」を直近のタスクの期限としても使う (流用する)
- タスクの期限より前にリマインドしたいことは多々あるため、リマインド優先で運用すると本来の期限がメタデータに残らないのがデメリット。
- 直近のサブタスクの期限用のカスタムフィールドを用意する
- サブタスクへ分割する必要のないチケットで冗長になるのがデメリット。
- 冗長な場合は入力を省略する運用もなしではないが、検索やマイページで使いづらくなる。
- プラグインで自動入力すれば緩和可能か？
- おとなしくサブタスク用のチケットを用意する
- 大袈裟すぎる。あまりに小さな単位でチケットが分割されてしまうと、1箇所にまとめても十分なほど小さかった情報がさらに散らばってしまうので扱いづらいのがデメリット。
- 外部のタスク管理を利用する/連携する
- #805 で検討中だが、良い選択肢が見付かっていない。
- 5. のデメリットが激しくなったものになりかねない。
どれも微妙。
NO nop_thread さんが約1ヶ月前に更新
nop_thread さんは #note-16 で書きました:
- 終了フラグは立っているが後始末が残っている状態 (「ふりかえり」ステータスとか？) を用意しておく
- 遅延未完タスクとして扱われないのはメリット。
- タスクとしては残っているのに未完タスク一覧に表示されないのはデメリット。
#303#note-7 のとおり、現在「完了待機」ステータス (完了フラグつき) を運用している。
これは「進行中ではなく期日の束縛を受けない状態だが、全てが終わったものとして忘却する前にすべき作業はまだ残っている」という状態を表現している。
たとえば何かを発注したら「完了待機」にして受領・検品したら「終了」にするとか、あるいは何らかの申請をしたら「完了待機」にして承認が下りたり所望のサービスが実行されたら「終了」にするとか、そういった使い方をしている。
「ふりかえり」とは少し違うが、「ふりかえり」を内包するものであると考えて良いだろう。
NO nop_thread さんが約1ヶ月前に更新
- ステータス を 進行中 から 終了 に変更
- 進捗率 を 0 から 100 に変更
- 前回確認日 を 2025/08/28 から 2026/06/02 に変更
nop_thread さんは #note-9 で書きました:
月1回まとめて提出する通勤費申請のためのチケット (#156, private) ではコメント機能を使って勤務実績のログを残すなどしており、これは前半が常時遂行タスク「ログ追加」で後半が作業タスク「申請記入と提出」になるというハイブリッドなパターン。
この場合チケットを分割するかは悩ましいところだが、
今のところの運用は、ログ追加段階では「進行中」か「新規」状態 (どちらを使うかは注目や期日の近さの程度による) でログを蓄積しつつ、申請の作成と提出の作業の段階は「進行中」で表現している。
もし申請段階への移行の日程が明確にわかっているなら、「リマインド予定日」フィールドを使うことで見落としのリスクを多少は軽減できる。
「新規」ステータスでログを追加する場合にも、「リマインド予定日」フィールドで見過ごしによるログ追加忘れを多少は防げることを期待している。
よって、「リマインド予定日」カスタムフィールドと #note-17 に記載した「完了待機」ステータスの組み合わせで、常時遂行やバックグラウンドのチケットもそれなりに安定した形で表現できていそう。
優先度については引き続き検討の余地があるが (たとえば #529 でも優先度については悩んでいる)、日常の運用に必要なことがらについては概ね安定したとして良い。