Redmineのトラッカーをヘーゲル弁証法とフッサール現象学の観点で議論してみた議論のリンク

@tw_yukiaさんとの楽しい会話と、自分のラフな考えをメモ。

【参考】
Redmineのトラッカーをヘーゲル弁証法とフッサール現象学の観点で議論してみた - Togetter

Redmineをどうも好きになれない人のための、20%の基礎を抑えれば、80%位の業務に対応できると気がついた長話。｜ゆきあ｜note

「Redmineのトラッカーは弁証法の結論的なので、人に向けて説明する事でしか適切な説明が出来ない」という@tw_yukiaさんの仮説は、僕も完全に分かっていない。
おそらく「トラッカーとは行動パターンの大分類である」という主張から、実際に行動してみて初めてトラッカーの意義が分かることかな、と推測したりするが分からないので、今度聞いてみようと思う。

僕が理解する弁証法は、「勝つための論文の書き方」に記載のある、人文科学や社会科学でよく使われるアウトラインのイメージ。
つまり、ある人の主張に対し、その主張の穴を見つけて論理的に崩し、最後に自分が正しい回答を提示するイメージ。

論文作成の技法part1～論文の構造: プログラマの思索

僕が理解するトラッカーは、ワークフロー、帳票、Issue Trackingの3種類。
個人的には、@g_maedaさんが主張される「トラッカーとは帳票である」意見が重要と考える。
理由は、業務のExcel管理台帳や紙の帳票は、トラッカーにマッピングできれば、全てチケット管理で実現できるからだ。
そのおかげで、Redmineがソフトウェア開発以外に社内の簡単な業務ワークフローにも応用された事実があると思う。

だから、@g_maedaさんはRedmineの「トラッカー」を「チケット種別」へ変更するチケットが提案されたのだ、と理解している。

Redmineの「トラッカー」を「チケット種別」へ変更するチケットが提案されている: プログラマの思索

一方、@akahane92さんが主張されるIssue Trackingの意見も重要と思う。
僕は、Issue Trackingとは、No ticket, No commitに代表されるトレーサビリティがその性質の核心にあると考えている。
単にチケットにログが記載されているだけでなく、構成管理の配下にあるソースや設計書の変更履歴とチケットが密接に連携されることで、変更管理もチケット管理で代用できる、という考えだ。

Patch #29045: Change Japanese translation for Tracker - Redmine

（引用開始）
--- Japanese Part ---
意見者の背景
Redmineを利用して10年余りになります。主に製造業の業務システムと装置研究開発向けのIssue Tracking System及び知識基盤としてRedmineを利用しています。現在、国内外1400名の利用者があり、300プロジェクトに40万チケットが記録され、閲覧回数は70万ページビュー/月です。（ 事例紹介論文とスライド ）
意見
この翻訳提案には賛成できません。
「トラッカー」のままに維持するか、どうしても和訳を変更するなら「課題追跡様式」が良いと私は思います。
理由
Redmineの最大の価値は「追跡パターンの選択によって課題解決を促進させる仕組み」にあると私は考えています。
現実社会の多様かつ難解な課題を解決に導くには、戦略（ここでは「課題解決のための追跡パターン」を指す）の選択が不可欠です。
どのような戦略で課題にアプローチするのかが、複雑な課題を解決できるかどうかの決め手になります。
Redmine における Issue Trackerとは、課題を解決に導くための戦略をパッケージ化して、ITSプロジェクト毎の取捨選択を可能にしたものなのです。
なぜなら、解決対象のプロジェクトの領域と目的よって、選択すべき戦略（パターン）の組み合わせは異なるからです。
ゆえに、Redmineの最大の価値を体現している Issue Tracker の和訳には、追跡戦略、パターンといった特徴が包含され、利用者に向けて表現されていなければなりません。
（引用終了）

こういう議論も次回のRedmine大阪でやってみたいと思う。

第21回 Redmine大阪 これからはじめる Redmine 2020(令和2年)　2020/04/04（土） 13:00～- connpass