鯖缶 » 人生管理運用

後日確認¶

cron.daily みたく、「定期的に、あるいは『後で』確認する必要のあるチケット」を集積する場所が欲しい。
1年後まで眠らせておくチケットなど絶対に忘れる。

「開始日」フィールドは存在するが、これはどちらかというと次の作業の追跡というよりは、作業着手日のヒストリを残す目的で使われている気がする。

「yyyy-mm チケット」のようなものを作って relation を設定する手はあるかもしれないが、あまりすっきりしないし、日付単位での設定が難しそうなのもつらい。
下旬開始でも月の頭に activate することになるのでは粗すぎる。
リマインダー的な機構をプラグインか外部サービスで用意するべきか？

「期日」フィールドは Redmine のリマインダメール発射に使えるらしいが、開始日より前に期日を設定するというのも違和感がある。
そもそも「期日」の意味論をはっきりさせていないので、先にそちらをどうにかすべき (→ #note-3)。

「確認予定日」フィールドを作ってカスタムクエリで近日確認予定のものを列挙できるようにするなどが現実的かもしれない。
リマインダメールの発射は使えないが。

一時的な状況と永続的な履歴¶

チケットには多くのメタデータや紐付いているが、これをおおまかに「状況」と「履歴」に分類して考える。

「状況」は現状を管理することを目的として与えられ、その構造は過去や未来と互換であることを保証されない。
今もっとも状況やチケットの管理に都合の良い形をとり、必要に応じて柔軟に変更される、一時的な情報である。
また、終了したチケット等については放置を原則とし、現在アクティブなチケット等と一貫した形で管理することは考えない。

「履歴」は過去と現在を記録として保持することを目的として与えられ、その構造はシステム (ここでは redmine.potato.immo) 全体で一貫し安定したものとして維持管理される。
必要に応じて過去の情報として参照されるために都合の良い形をとる、永続的な情報である。
終了したものや開始されていないものまで含め、原則として全てのチケットを通して共通の構造や解釈を適用できるよう運用する。
廃止したり置き換えたりすることを前提として一時的に用意するものではなく、もし廃止や置き換えが必要であれば、そのような移行作業は全チケットに対して一斉に行う。

何が履歴か¶

「履歴」として意味と表示の安定的な持続を期待すべきデータは、おそらくあまり多くない。
今のところ、以下のもの。

• 作業時間ログ
• コメント (自然言語)
• チケットの最終ステータス

その他の要素、たとえばトラッカーの変更履歴、カスタムフィールドの値の変更履歴、チケットステータスの変遷などもシステム上は履歴と一緒に残される可能性はあるが、完全に既知の解釈によって利用可能な機械可読データとして残るものとは期待すべきでない。
実際には機械可読データとしてデータベースに残るだろうが、敢えてそのような信念に基いて運用する方が、おそらくより楽に、よりよく整理できる。

状況とは何か¶

その他のほとんどの情報、たとえばトラッカー、最終的でないチケットステータス、担当者、期日、優先度などは、専ら「今」なにをすべきかを管理する目的で整備されるべきで、「チケットがどのようなステータス変遷を経たか」に信頼に値する情報として依存すべきではなく、そのような情報が残っていたとしても、そこから意味ある情報を取り出せると期待して運用すべきでない。
別の言い方をすれば、これらの情報は運用上の理由や単なる気紛れによって、深い意味やメリットなしに変更されるという前提で扱われるべきということである。
チケットステータス変遷を見て人間が懐しむ分にはどうでも良いが、これをチケット管理上重要な情報源として扱ってはいけない。

「状況」の変化をどうしても後から参照・活用できる形で記録する必要があるなら、システムによる変更記録に依存せず、コメントとして人間向けテキストの形で残し、機械可読にしようと試みないこと。
これによって、トラッカーやステータスの整備状況そのものから堅牢性や互換性の要求を取り除くことができ、また履歴として残されるべき情報であると明確に示せる。
この種のコメントを機械可読にしようとしてしまうと、結局のところコメントのテキストフォーマットが固着してしまい、将来その構造を変更したくなった際に移行が困難になる。
結局「状況」を無理に「履歴」に埋め込んでいるだけで、「『状況』は一時的なものである」という原則に違反したことによるデメリットをそのまま受け止めることになってしまう。

チケットの最終ステータス¶

チケットは終了した後原則としてそのステータスを変化させないので、基本的にステータス自体は「状況」であるものの、チケットの最終ステータスだけは「履歴」として扱うことができる。
つまり、未着手や進行中のステータスはロバストに作って運用で柔軟にカバーすることが許される (そしてその方が楽) だが、終了のステータスだけはある程度詳細に、しっかりと設計・分類すべきということになる。
とはいえ、選択に迷わない程度に明確な分類でなければならない。
迷うということは判断がブレるということで、そのようなブレは「履歴」の信頼性を低下させるとともに一斉操作による一貫した構造変更を困難にするからである。

また、これを「履歴」として扱う都合から、トラッカーに関係なく最終ステータス (終了に分類されるステータス) は共通である必要がある。

その他のメモ¶

meta カスタムフィールド

meta カスタムフィールド (#119#note-6) なども永続的に見えるかもしれないがそんなことはなく、たとえば最初は小さなチケットにしていたが後から関連タスクが多いことがわかってきて分割した、などの場合には途中での変更が考えられる。
終了したチケットについても、後から別チケットをぶらさげるような変更は (望ましくないかもしれないにせよ) 考えられない話でもない。

トラッカー¶

終了したチケットのトラッカーは安定しているのではないかという考えもあるだろうが、トラッカーを後から分割することに決めた際に、過去の終了したチケットをいちいち分類していくのは不毛であるという事情がある。
できないことはないが、運用の利にならないから避けるという判断である。

たとえば全てのタスクを「機能」トラッカーにしていたところ、後から「買い物」トラッカーを作ったという場合を考える。
過去の済んだ買い物について分類しなおすため終了した全ての「機能」チケットを洗い直すのはあまりに不毛で得るものがない。
また、トラッカーが分類されていないがゆえに買い物とそれ以外のタスクが混在してひとつのチケットになっていたケースもあるかもしれず、その場合分類は困難である。
このような問題があることから、終了したチケットのトラッカーについて厳格な運用や一貫性維持のための変更というのは考えない方がよく、ゆえに最初から過去や未来との互換性を保証されないものとして扱うことにしたい。

「期日」フィールドの意味論¶

期日とは何の期日？
チケット全体を resolve する期限？ それとも resolve のみならず close する期限？
あるいは、チケット内に複数タスクがあるとき、現状の小タスクの完了・再評価期限？
未着手のチケットなら、開始期限？
可能な用途が多すぎるため、雑に使い始める前に意味論を定めておきたい。

参考までに、親チケットの開始日と期日は子チケットから自動算出する設定にできるため、 Redmine のシステム的にどう扱う想定なのかはここから多少読み取れるかも。
開始日は子チケットの同フィールドのうち一番早いもの、期日は子チケットの同フィールドのうち一番遅いものにされるらしい。
つまり、少なくとも「着手開始日」としては期日より開始日の方が適している。

ただ、「開始日」は個人的には目標というより履歴のような側面もある気がしており (つまり #note-2 の語彙を使うなら「状況」よりも「履歴」寄りの面があるように思われる)、どう扱うにせよ違和感があるので、これも実は持て余している。
「開始した日」なのか「開始すべき日ちょうど」なのか「開始の期限」なのか。
「期日」と併せて考えるべきかもしれない。

チケット内の小タスク (“開始する” も含む) の期日はチケット全体の期日とは別フィールドであるべきかもしれない。
小タスクを別チケットにするのも概念的には整理されているといえるだろうが、運用上は煩雑になるばかりでメリットが薄いようにも感じられる。

チケットとして幾分異質ではあるが、常時遂行/バックグラウンドのチケットの文脈では #113#note-8 の問題もある。

ステータスと待ち状態¶

Redmine のデフォルトでは進行中タスクのステータスには「進行中」 (In Progress) と「フィードバック」 (Feedback) があるが、前者はさておき後者のステータスの用法は特に曖昧で共通の見解がない。
たとえば担当者を変更したとき in progress 状態をリセットしたいので new にする代わりに使うものだとする意見もあれば、 resolved になった後で問題が発覚したときの差し戻し時に使うという意見もあり、また needs feedback の意であって担当者以外の返答を待っているときに使うという意見もある。
どのように解釈するかはそれこそトラッカーの運用と状態遷移の規則によって決まるものであって、 feedback という文面だけで共有された理解を得るのは無理のある話である。
いずれにせよ個人的に運用している場合はレビュアーの存在や担当者変更の可能性はかなり低いため、この曖昧なステータスはそのままでは使いづらく、意味を定めて別のステータスで置き換えることが望ましい。

あると便利な情報として、「気が向いたとき/必要になったときいつでも着手できる」という自分にコントロールのあるステータスと「自分のコントロールの及ばない何らかのイベント (特定日時までの時間経過も含む) を待つ必要がある」という待ち状態のステータスの区別がある。
これらを分離できると、「今から着手できるタスク」の一覧が欲しくなったとき可能なアクションの存在しない待ち状態のチケットを除外することができる。
強いて言えば needs feedback 説寄りの定義になるが、「待機中」などのようなステータスがあるとこれを表現できるので便利そう。

作った (2024-03-09 06:55)。

「進行中」と「待機中」は、既に「買い物・物欲」トラッカーで利用している「購入確定」と「発注済」に関係が近い。
「発注済」は「注文したが未受領」を表現するつもりで用意したステータスで、キャンセルによる発注取消で手戻りが発生したり、入荷遅延への対応や監視が発生したりする可能性があるため、受領を表現する「終了」と別で用意している。

厳密には「終了」は受領というより納品を受けたことを表しており、その後の “検収” で問題が発覚する可能性は残っている。
しかしこの場合「買い物・物欲」トラッカーのチケットで追跡するよりは、返品や交換を目的とする「生活行動」チケットや自前修理を目的とする「バグ」チケットを新たに立てることで対応できると判断した。