Redmineが使いづらいと言う質問～開発業務をRedmineへマッピングできていない

Redmineが使いづらいという質問をよく聞く。
それについて考えたことをメモ。

【1】Redmineを導入してみると、各チームで何となく回っているように見えるが、質問が色々くる。
よく来る質問は、だいたい二つだ。

一つ目は、ガントチャートの見栄えをもっとよくできないか？
日付を出して欲しい。
罫線を出して欲しい。
イナズマ線を出して欲しい。
担当者を出して欲しい。
PDFでもっと綺麗に出したい。

この質問については、下記で書いた。

MS Projectを使いこなせない理由: プログラマの思索

RedmineのガントチャートはMS ProjectのWeb版になりうるか？: プログラマの思索

Redmineのガントチャート改善part2: プログラマの思索

二つ目は、課題やタスク、問合せの一覧を出力するとき、Excelでもっと綺麗に出せないか？
意図は、Excelで課題一覧、問合せ一覧を管理していたが、Redmineのチケットにそのままマッピングしづらい。
チケットのカスタムフィールドを使わずに、説明欄にたくさんの情報を書き込んで更新しようとしている。
あるいは、チケットのカスタムフィールドを作ったとしても、デフォルトのCSV出力では、無関係のカスタムフィールドも出力されてしまって、整形し直すのが面倒、と。

彼らの使い方を見ていると、Excelでタスク一覧や課題一覧を管理して、ガントチャートで進捗管理している方法をそのままRedmineへマッピングしようとしている。
だから、ガントチャート上でチケットの開始日・期日・担当者を修正したがっている。
あるいは、Excelの課題一覧やタスク一覧と同じフォーマットで、綺麗なExcelがRedmineから一発で出ることを期待している。

彼らが言うには、iPadで新聞を読む場合、やはりiPadよりも紙の新聞の方が読みやすい。
だから、朝会や会議では印刷して、それを元にして議論したいようだ。
iPadのデジタル新聞と紙の新聞は用途が違うように、RedmineとExcelも用途が違うのだ、と彼らは言う。

【2】これらの質問が出てくるのは、現状の開発業務をRedmineへマッピングしようとして溢れている部分があることを示唆している。
僕の考えでは、課題一覧や問合せ一覧に出てくる項目（顧客提示の有無・対策期限など）はチケットの属性で表現できるわけだから、カスタムフィールドを使えばいいと思う。
そして、Excelで整形し直せばいいだけ。

二つの質問も、いずれもチケット集計のビューに関する質問だ。
集計の手作業のコストがかかるということは、Redmineにまだビューという機能が不足していることを意味している。

それらの機能は、Tracのクエリのように、彼らが欲しいSQLをRedmineへ投げればいい。
そのビューのプラグインを作ればいいだけのことだ。

【3】RedmineやTrac上で、チケット駆動開発を実践する利点は、単に工数の入力や集計が楽になるだけではない。
実は、プロセスの標準化と言う隠れた動機もある。
一つのツールないし開発環境でプロジェクト管理を統一すれば、どのチームも同じようなプロジェクト管理手法になる。
そうすれば、新米の現場リーダーもすぐに進捗管理ができるし、ツールの一機能にあるベストプラクティスに慣れるだけで自然に管理能力が身に付く。
又、新規メンバーや新人も、ツールに慣れてもらえれば、チーム作業のルールに自然に慣れる。

これがExcelの場合はそううまくはいかない。
Excelのフォーマットはカスタマイズしやすいから、すぐにフォーマットが発散するし、ワークフローは手作業ゆえに徹底しづらい。
Redmineならトラッカーに応じて、チケットのステータスの制御ができる利点もある。

チケット駆動開発の利点はそれだけではなく、開発業務をITSへマッピングして溢れた機能があれば、自分たちで不足した機能を実現すればいいという事実も示唆している。
つまり、プロジェクト管理という技術をプログラミングによる実装という問題に置き換えることで、現場リーダーの仕事を一機能の実装という問題にすりかえてしまう。

Redmineは所詮Railsアプリなので、テーブル設計さえできれば一瞬でCRUD画面はすぐに作れる。
不足した工数入力・集計機能は、Railsアプリの問題にすり替えてしまえばいいだけのことだ。

チケット駆動開発は、プロジェクト管理の技法をどんどんプログラミングと言う下流工程で置き換える技術の一つと言い換えることもできると思う。
丁度それは、オブジェクト指向がプログラミングの一技術から設計や開発プロセスを席巻した状況に似ている。