Redmineのアンチパターンは２種類に区別できるのではないか

以前、Twitterで、日付カスタムフィールドに関するRedmineのアンチパターンが議論されていた。
その議論を読みながら、Redmineのアンチパターンには、プロジェクト管理の要件のブレかフィットギャップ分析の甘さの２種類に区別されるのではないか、と考えた。
ラフなメモ書き。

【問題の発端】
nekosanzさんのツイート: "難問。１つのプロジェクトではなく、１つのチケットにマイルストーンがほしい。こんなこと言われたの初めてだ"

門屋　浩文さんのツイート: "チケット割るか説明に書く！… "

nekosanzさんのツイート: "結論が日付カスタムフィールドを10個ぐらい追加してほしいという炎上物件… "

【問題の真因を突いている議論】
neta＠筋肉 筋肉???さんのツイート: "Redmine の日付カスタムフィールドはあかん。ウチも『期日』という名称が気に入らなかったらしく、『希望納期』という残念なカスタムフィールドを作ってしまった。ガントには出ねーわ、リマインダーは効かないはマイッタマイッタ。今は反省している… https://t.co/MSqH2RmwwQ"

門屋　浩文さんのツイート: "日付のカスタムフィールドはあまり良くない 標準のガント使わなくなったのが実績日が出てこないからという理由なので… "

【アンチパターンに関する感想】
akipiiさんのツイート: "久しぶりにRedmine のアンチパターンを集めたいですなぁ笑… "

nekosanzさんのツイート: "みなさんおっしゃる通り。コミュニケーションツール不在の会社にRedmine 導入するとアンチパターンの温床になりえますね。… "

akipiiさんのツイート: "アンチパターンの種類にも、プロジェクト管理の要件を詰めきれてないことと、Redmine の機能を理解しておらずフィットギャップ分析が甘いこと、があるから区別したいな。… "

【1】チケットにマイルストーンが欲しい、という要望を元に、Redmineに日付カスタムフィールドを１０個も追加してしまった、という事例。

おそらく、障害管理票、課題管理票のような類の帳票をチケット化した時、数多くの異なる日付を入力する必要になったのでは、と勝手に推測する。

しかし、上記の指摘の通り、Redmineチケットの「期日」を使わなくなると、ガントチャートに表示されないし、リマインダーのメール通知機能も使えなくなる。
よって、本来は、チームの要望にある「日付」の概念をRedmineの「期日」に合うように修正すべきだったのだろう。
あるいは、ja.ymlにある「期日」の文言をチームの組織文化に合った文言、たとえば「納期日」などへ修正しても良かっただろう。

【2】そういう話をふりかえると、Redmineのアンチパターンには、２つの観点で綺麗に分類できるのではないか、と思う。

【2-1】一つは、プロジェクト管理や開発プロセスの本来の設計思想に関する理解が浅いために、プロジェクト管理の要件を詰め切れていないこと。

よくある例は、WBSは工程単位に作るべきなのか、機能単位に作るべきなのか、どちらがいいのですか、という質問が相当するだろう。
この質問に関しては、下記の記事で明確に回答が述べられている。

ＷＢＳはプロジェクト組織を規定する : タイム・コンサルタントの日誌から

ＷＢＳはコスト見積の基準を規定する : タイム・コンサルタントの日誌から

WBSの作り方はプロジェクト型組織の構造を決めるという考え方はRedmineチケット管理にも通じる: プログラマの思索

また、「チケット無しの作業不可」の運用ルールの理解が浅いために、作業履歴やレビュー履歴をチケットに残してナレッジを蓄積し、最終的にはプロセス資産になる、という思想まで考えが及ばない、という話もあるだろう。
その他にも、チケットの棚卸し、トレーサビリティなどの話も同じ論点ではないか、と思う。

つまり、Redmineのようなチケット管理ツールとは無関係な観点で、プロジェクト管理や開発プロセスの理解が甘いために、RedmineやJiraであろうが、どのチケット管理ツールも使いこなせていない、という結果になるのだろう。

すなわち、この観点のアンチパターンは、ツールとは無関係な一般論に近いレベルまで昇華できるだろう、と思う。

【2-2】もう一つは、チームの開発プロセスの要件とRedmineの機能について、フィットギャップ分析が甘いこと。
これは、今回の日付カスタムフィールドの話に相当するだろう。

他に、親子チケットの作り方、ロードマップの使い方などもあげられるのではないか。

【事前公開】【第16回Redmine大阪】RedmineのFAQとアンチパターン～親子チケットの功罪: プログラマの思索

Redmineの親子チケットの功罪: プログラマの思索

最近よく聞くRedmineのFAQ～Excel添付のチケットから野良Redmineまで: プログラマの思索

最近なら、デブサミ2018のRedmine利用事例の講演でも、アンチパターンに関する話があった。
その中で、@g_maedaさんの下記の話は、Redmineにおけるトラッカーを使いこなせていないアンチパターンがある事実を示唆している。

MAEDA, Goさんのツイート: "最近は、トラッカーの追加とは入力フォームを設計して追加することだと説明するようにしています。… "

つまり、Redmineに埋め込まれた本来のチケット管理の機能要件を理解できていないために、Redmineの優れた機能を発揮できない結果に陥る、という結果があるだろう。

すなわち、この観点のアンチパターンは、Redmineの設計思想とユーザが利用したい要件に関して、Redmineのフィットギャップ分析が甘い点に原因があるだろう、と思う。

【3】では、Redmineのアンチパターンを「プロジェクト管理や開発プロセスの一般論」と「Redmineのフィットギャップ分析」で分類したら、どんな面白い内容が出てくるだろうか？

【3-1】まず、僕は、「プロジェクト管理や開発プロセスの一般論」のアンチパターンは、Redmineが機能豊富になるにつれて、最終的にはどんどん難易度が高くなるのではないか、と思う。
一般論の話は、実際にチケット管理して経験して、失敗したり、成功してみたら、すぐに理解できて解決できる。

よって、Redmineに上手く当てはまれば解決できるアンチパターンは、Redmineが誕生して10年経った今、知見やノウハウとして、普通の経験者は理解できているだろう。
そして、じきに、本来のユーザ利用要件をRedmineに当てはめられなくなった、というレベルまでたどり着いて、改めて考えなくてはならない、という方向に落ち着くだろう。

つまり、一般論の話で解決できないアンチパターンは、ソフトウェア開発やソフトウェア工学に関する本質的な問題まで辿り着くのではないか、と思う。

たとえば、チケットの粒度に関する議論は、ソフトウェア工学における「ソフトウェアの本質的な複雑性」に由来するがゆえに、そう簡単に解決できる話ではない、と思っている。

チケット駆動の罠～複雑さはチケットの粒度に関連している: プログラマの思索

【3-2】一方、「Redmineのフィットギャップ分析」のアンチパターンでは、Redmineの標準機能で解決できる事例はどんどん公開されてしまい、最終的には、Redmineをカスタマイズすることでしか解決できないアンチパターンが多数出てくるだろう、と思う。

たとえば、最近よく聞くRedmineのFAQ～Excel添付のチケットから野良Redmineまで: プログラマの思索でもあげたが、ロードマップ画面におけるチケットの並び順をドラッグ・アンド・ドロップで制御する機能パッチは、アジャイル開発におけるプロダクトバックログ管理に相当する機能なのに、未だに実現されていない。
つまり、先進的なアジャイル開発のプラクティスをRedmineで運用したい、と思っても、Redmineの標準機能では不足しているのだ。

他に、MSProjectみたいにRedmineのガントチャートを使いたい、とか、色んな要望が出てくるだろう。

つまり、「Redmineのフィットギャップ分析」のアンチパターンを完全に解決するには、Redmineにプラグインを導入したり、Redmineそのものをカスタマイズする、という方向性が必要になる事例が数多く残ってくるのではないか、と思う。

【4】個人的には、Redmineのアンチパターンを上記の2種類の観点で区別した時に、下記のテーマがあると思う。

(1)既によく知られているアンチパターンは、上記2種類のどちらに分類されるか？

(2)未解決のアンチパターンの原因は、上記の考え方で合っているか？
そして、解決の方向性も、上記の考え方で進められるか？

この辺りも色々考えてみたい。