Redmine運用の感想を集めてみた

Twitterを眺めていたら、Redmine運用の感想が目を引いたのでメモ。

【元ネタ1】
Twitter / @polo_kwsk: Redmineが優秀すぎる・・・普通にソフト会社に開発させたらウン千万取られるところだ・・・PJ管理インシデント管理その他もろもろ使えるいいオープンソースソフトやでぇ。社畜SEさんにもおすすめ。

Twitter / @Sean_SF: そういうのってホントにあるんだなぁ? RT @sonoyu670 あるお客さんのところでは「それredmineでええやん」という使い勝手の悪い独自のPJ管理システムを持ってて、これウン千万とかかけて作ったんだろうな、馬鹿だな、って思ってた。

フリーのBTSがまだ普及していない頃、障害管理やタスク管理の重要性に気づいた会社は独自でBTSやITSを作り込んでいた。
そういう会社は先見の明があったに違いない。
だが、長年使ってくると、オープンソースのBTSやITSの方が普及してかつ高機能になって、逆に足枷になっている場合が見られる。
システムを長く使うのか、それとも新しいシステムにリプレースして移行するのか、判断が難しい。

【元ネタ2】
Twitter / @process_ok:Redmine を使い始めてすぐに気づいたこと。 やっぱり、チケットの発行単位とか、報告ルールとか、メトリクスの設定とか、マネジメントの本質的な価値の部分はツールだけでは決まらないので、自分で決めなくてはいけない、ということ。運用次第で、使えるツールにもゴミにもなる。

Twitter / @process_ok: あと、Redmineのようなツールが多彩な機能を持っているからと言って、それに引きずられて業務フローを考えるとか、ついやりたくなってしまうけど、危険危険。 あくまでやりたいことを先に書いた方が良い。

Twitter / @process_ok: たとえば、Redmineを使えばチケットを記入したり、ガントチャートを眺めたり、というのはすぐできるのだけど、それはあなたのマネジメント目的のどの部分に合っているのか、報告する必須の情報は何なのかを説明できないといずれ行き詰まると思う。

Twitter / @process_ok: それでも、きちんとしたツールがあれば、マネジメントはマネジメント本来の業務に集中することができるので、非常に助かる。さっき書いたのはツールがまともであれば発生する贅沢な悩みだ。

Remineのカスタマイズと運用 - satospo

RedmineやTracを上手に活用する6つのポイント ? Offside

小さなチームでの Redmine 運用で気をつけている 3 つのこと - Born Too Late

Redmineによるチケット駆動開発は、プログラマ上がりの現場リーダーのための開発プロセスだと思っている。
マネジメントの経験は少ないかもしれないが、手を動かす方が好き。
マネジメントで行き詰まる時は、技術力でカバーする方が多いだろう。

そんな状況で、ツールを使って進捗管理や課題管理、コスト管理、リスク管理などをフォローしていけば、自分なりのノウハウが色々貯められるだろうと思う。
既に、CMMI・PMBOK・ITIL・RUP・Scrumなど各種プロセスのベストプラクティスもアンチパターンも公開されているのだから、ツールを使って実際に試してみればいい。

すると、Redmineのようなツールはソフトウェア開発のERPのようなものだと思える。
開発チームという貴重なリソースをいかに有効活用して、顧客へ価値ある製品を届けるのか、という問題をソフトウェアで解いていく問題に置き換えてくれる。

Redmine導入はERP導入に似ている #tidd: プログラマの思索

ALMはSW開発のERPと同義: プログラマの思索

また、Redmineによるチケット駆動開発で面白い点は、ソフトウェア開発のタスク管理以外にも、課題管理・インシデント管理・ストーリー管理にも適用できること。
受託開発のタスク管理だけでなく、運用保守におけるインシデント管理、アジャイル開発のかんばんに似たストーリー管理も可能なのだ。
チケット入力の運用ルールさえしっかりしていれば、色んな観点のビューでプロジェクトの状況をモニタリングできる。

チケット駆動開発の適用範囲: プログラマの思索

チケット駆動開発の適用範囲Part2～チケット駆動開発の運用パターン: プログラマの思索

チケット駆動開発の適用範囲part3～ストーリー駆動のチケット駆動開発: プログラマの思索

他にも集めてみる。