機能 #89
完了
[Redmine] トラッカー運用見直し (2024-01)
nop_thread さんが11ヶ月前に追加.
7ヶ月前に更新.
説明
現状は以下の通り。使えてはいるもののあまり満足していない。
- バグ
- 問題を直すとき雑にこれを使っている。
- ソフトウェア以外には不適な名前だが、不具合を雑にバグ呼ばわりするオタクしぐさもそれはそれで面白いかもしれないので放置。害はない。
- 機能
- 何かを作る、獲得する、改良するようなダイレクトなタスクにはだいたいこれを使っているが、名前が微妙。
- かといって良い名前の代替案もない。「生産的ないいこと」にしても、起票するようなほとんどのタスクは非生産的でもないし悪いことでもないからなぁ。
- 何かを作ったり獲得したり改良するダイレクトな行動でないこと、たとえば主には生活の雑事を想定して、「生活行動」トラッカーを用意してみたが、これもこれで微妙 (後述)。
- サポート (未使用)
- 他人とのインタラクションを主な内容とするタスクが仮に発生したとして、この Redmine 上でやることはまずないだろうし、それが「サポート」と呼べるものである可能性も低そう。少なくとも、より適切な別の名前はあるはず。
- コンテンツ鑑賞
- 鑑賞したいコンテンツの管理に使っている。
- 現状ではノベルゲームが主だが、映画等にも (劇場・配信など問わず) 使えるはず。
- 本については例外的で、 Bookwyrm や Ryot で管理している。これは数が多くかつ短時間で1単位を消化できる場合が多いことと、チケットを立てるまでもなく突発で複数の鑑賞が発生したりすること (また、そのチャンスをチケット立ての手間で妨害したくないこと) による。
- さしあたって問題は見えていない。利用継続。
- 買い物・物欲
- 欲しいものの検討や選定に使っている。
- 素朴な TODO 管理 (たとえば CalDav や Tracks によるもの) による買い物リストは、買うことが確定したものの購入管理 (まさに買い物メモ) には向いているものの、検討と選定の段階に向いていない。
- さしあたって問題は見えていない。利用継続。
- braindump
- トラッカー自体は便利だが、『吐き出しかた』カスタムフィールドについては検討の余地がある。たとえば「トピックとしては確立しているが内容の具体案はなく、とにかくアイデアを垂れ流してメモしておきたい」みたいな用途に使えるものがない。
- そもそもこのトラッカーが別媒体への出力を目標にしているのか情報整理そのものを目標にしている (別媒体への出力ないし公開を目標にしていない) のかが曖昧。
- 行動傾向
- 「今月の目標」や「やめたい習慣」などのように、明確なゴールや進捗度や行為判定を持たない (あるいはゴールが「しない」のような否定形になっている) 場合があり、時間的区間全体を通して生活全体にぼんやりと存在する「注意」のような感覚を必要とする目標を明文化したもの。
- 便利だし他のトラッカーではだいたい不適なので、個人の行動管理には良いアイデアに思うが、引き続き利用して問題点や必要なメタデータの炙り出しを行う。
- なお集団の行動管理には向いていなそう。使えないこともないのかもしれないが。試していないし試す予定もないので深く考えていない。
- 生活行動
- 何かを作ったり得るためのものではない、生活の雑事に使っている。
- 当初の想定用途は、家事や事務手続きなど。ただしこれに限るつもりはない。
- そもそも生産系の活動との境界が曖昧というのもある。事務手続きによって自動的に何か物品を得られたり環境改善が行われるとき (たとえば家の工事依頼みたいな？)、これは結果を得るための「直接的な」行動だったのか、それとも雑事の範疇なのか。
- 根本的には、トラッカーを使い分ける際に行動そのもので分けたいのか目的で分けたいのかが曖昧なことに起因する混乱といえる。たとえば「買い物」を考えると、目的で切るなら「調達」になるが、行動で切るなら「通販でボタンﾎﾟﾁｰ」の場合もあるし「外出して購入してハンドキャリーで持ち帰る」の場合もあるし「外出して購入して搬入の手続きをして、搬入当日に設置を監督する」かもしれない。これらの行動そのものの性質は明らかに互いに異なる。
関連するチケット
2 (0件未完了 — 2件完了)
そもそもこのような「検討」に「機能」を使うことにも違和感があるのだが、一方で機能実装や改善の前に (あるいは実装中にも適宜) 調査や(再)検討フェーズが入るのは自然で、そのためにわざわざ子チケットを立てるのも不毛。
タスクで分けたくないからといって目標で分けようにもそれはそれで不便で、たとえば検討の結果がないと目標が定まらないこともある。これは詳細に考えると、適切な目標を定めるというタスクを別名として『検討』と呼んでおり、かつ目標確定後にその『検討』チケットがそのまま新目標に流用されるという現象であると言える。 execve(2) とか exec(3) をチケットでやっているようなイメージだ。
もちろん『目標決め』チケットと『決まった目標の達成』チケットを分けても良いのだが、せっかく有用な情報が目標決めチケットに溜まっているかもしれないし文脈も強く繋がっているのに、わざわざ分けることに実用上の価値がそんなにあるだろうか？
もうひとつ、 tracking issue を必要とするようなメタな追跡項目や “分類” についての扱いが悩ましい。
サブチケットについては、 Redmine の進捗率の仕組みからすると親チケットには具体的なタスクは一切割り当てず全てをサブチケットに払い出すのが良いように思われる。
さもなくば、現存のサブチケットが全部完了していて親チケットのタスクが残っているような状態で、完了していないにも関わらず進捗率 100% と計算されてしまう。
このように、 tracking issue は特殊な運用をすることになるので、トラッカーを別にすることも検討すべきかもしれない。
現状では真偽値を持つ "meta" フィールドで区別しているが、果たしてこれが良いことなのかわからない。
たとえば tracking issue 自体に具体的な作業などが割り当てられないのであれば、トラッカーとして何を選択すべきか曖昧になることは考えられる。
tracking issue の代わりにプロジェクトを小さく切っては閉じていくといった方法も考えられはするが、プロジェクト分割の望ましい運用についてはもっと悩ましい。
JAXA の報告書 (『CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム: Redmineの事例と利用のヒント』) では、「プロジェクト分割の指針は Redmine を使用する組織の性格や考え方により異なると思われるが，」としつつ、以下のように列挙している。
(なお JSS2 は JAXA のスーパーコンピュータ。)
- セキュリティなどの理由により参加メンバーが異なるときは分割する．
- 参加メンバーは同じでもロールを変更する必要があるときは分割する．
- 業務範囲により，フィールドの要・不要が異なったり，更新頻度が大きく異なるときは分割する．
- Redmine の保守関連作業のプロジェクトは分割する．
- 「カテゴリ」フィールドの選択肢を業務分野毎に分けて，選択・検索しやすくするときは分割する．
概ね、権限まわりで差が出るかメタデータの扱いに大きな差が出る箇所を切りどころと考えているようである。
また、「カテゴリ」フィールドの値の集合がグローバルではなくプロジェクト毎である点についてはおそらく重要で、これを重視しながら考えるのは良いアイデアなのではないかと思う。
以上のことを参考にすると、プロジェクト分割によって tracking issue の代替とするのは、参加メンバーや権限の割り当てが違う場合には適切と考えられるが、参加メンバーやタスクの性質に大差のない状況では過剰であるように思われる。
- 題名 を トラッカー運用見直し (2024-01) から [Redmine] トラッカー運用見直し (2024-01) に変更
- プロジェクト を 鯖缶 から 人生管理運用 に変更
- 関連している 機能 #112: [Redmine] 設備管理用トラッカーの検討 (2024-01) を追加
- 関連している 機能 #119: [Redmine] tracking issue (メタチケット) の扱い (2024-01) を追加
nop_thread さんは #note-1 で書きました:
そもそもこのような「検討」に「機能」を使うことにも違和感があるのだが、一方で機能実装や改善の前に (あるいは実装中にも適宜) 調査や(再)検討フェーズが入るのは自然で、そのためにわざわざ子チケットを立てるのも不毛。
タスクで分けたくないからといって目標で分けようにもそれはそれで不便で、たとえば検討の結果がないと目標が定まらないこともある。これは詳細に考えると、適切な目標を定めるというタスクを別名として『検討』と呼んでおり、かつ目標確定後にその『検討』チケットがそのまま新目標に流用されるという現象であると言える。 execve(2) とか exec(3) をチケットでやっているようなイメージだ。
もちろん『目標決め』チケットと『決まった目標の達成』チケットを分けても良いのだが、せっかく有用な情報が目標決めチケットに溜まっているかもしれないし文脈も強く繋がっているのに、わざわざ分けることに実用上の価値がそんなにあるだろうか？
検討段階でプロトタイプ実装や実験のような作業が必要になる場合もあるから、検討と実装を分離するのはあまり効果的ではなさそう。
安定してきたと思うので一旦閉じる。
- バグ: 不具合や不都合、その対処についての管理全般。
- 機能: 不具合や不都合への対処でないようなタスク一般。
-
サポート: デフォルトで用意されていたが、要らないので消してもいいかも。 →消した。
- コンテンツ鑑賞
- 買い物・物欲: 欲しいものリストや調達作業の管理。
- 生活行動: またの名を雑事。
- braindump: 情報の出力 (仮出力を含む)。 場合によっては情報収集も含む。
- 行動傾向: 具体的な作業ではなく、行動の傾向や作業の選択の傾向を管理するトラッカー。 あるいは、必要性もなく気分で決めたぼんやりとした目標を追跡するトラッカー。
- 設備・備品: 設備あるいは補充の必要な備品についての、継続的な追跡および作業ログのためのメタチケット。
- 観光: 行きたい場所などの管理。
他の形式にエクスポート: Atom
PDF