Redmineはプロジェクトを横断して使うべきか否か

syotaro @syotaro85

「redmineは、開発チームごとにたてられるのが理想」 という話をちらほら聞くけど、 社内の複数プロジェクトを横断的に管理してこそ、真価を発揮するのだと思っている。 プロジェクト間の人の移動コストを減らせるし、加わったばかりのプロジェクトに直ぐに入り込める

Oja @kawanishi_ameya

@syootaro 方向性や作業分野の違うチームもまるごとひとつのRedmineで管理したら、トラッカーやステータス、プラグインの数やチケットの使い方とかがひどいことになったので、「管理責任者の目と声が届く範囲」にしておく必要はあると思っています。

syotaro @syotaro85

@kawanishi_ameya 「社内の複数プロジェクト」とは言っても、確かに、「事業部」の枠を超え始めると、プロジェクトのメタ情報（トラッカーやワークフロー等）が破綻しそうですね（汗 管理責任者の力量（管理可能範囲の広さ）と見極め力が問われますね！

akipii @akipii

興味深い議論。RT @syootaro: @kawanishi_ameya 「社内の複数プロジェクト」とは言っても、確かに、「事業部」の枠を超え始めると、プロジェクトのメタ情報（トラッカーやワークフロー等）が破綻しそうですね（汗

Oja @kawanishi_ameya

@akipii @syootaro 1つのRedmineで様々な要求を満たすために、プロジェクト単位でトラッカーやステータスetcを作って持てるプラグインを作って導入した結果、大量のローカル項目と性能劣化と他のプラグインやRedmine自体との不整合を生み出したりしました

syotaro @syotaro85

@kawanishi_ameya @akipii project単位でトラッカー等持てるプラグインを導入するというのは project単位でredmineホスティングしているのとほぼ同義と言えそうでしたが、性能劣化という面もありますか… 貴重な経験談としてストックさせて頂きます

Oja @kawanishi_ameya

@syootaro @akipii プラグインのコードの質が悪かったというのもありますが、トラッカーを選ぶ場面ごとに「このトラッカー(とそれに紐付くステータス)は、このプロジェクトで使用可能か」という処理を入れていたりしたので・・・。さらに考慮漏れのページがあるとエラーになったり

syotaro @syotaro85

@kawanishi_ameya @akipii Redmineは本当によく出来ていると感じていて、plugin拡張は出来る限り控えるようにしています。 「こうしたい→拡張する」よりも 「何故redmineはこうなっているのか？」 と自分に常々問うと、新たな発見をよくします。

syotaro @syotaro85

@kawanishi_ameya @akipii 話が少しそれてしまいましたが 「管理責任者の目と声が届く範囲に抑える」 と共に 「redmine管理できなくなる(メタ情報氾濫する)ような現実のワークフローは見直す」 両方をバランスよく実施→管理可能領域を広げ は可能なのかなと

syotaro @syotaro85

@kawanishi_ameya @akipii 現実を見なおしてみても、「事業部」が違えば、ワークフローから何からがらっと違うので、それを一元的に管理できる管理者の存在というのは稀なので、やっぱり破綻しやすいのでしょうね

syotaro @syotaro85

@kawanishi_ameya @akipii 結論 redmineによるプロジェクト管理が破綻するのは ・現実のワークフローが複雑すぎて抽象化不可 ・redmine管理対象が管理者の力量を超えている ・redmineの本質からずれた使い方をしている と思いました。

syotaro @syotaro85

@kawanishi_ameya @akipii 「redmineは、開発チームごとにたてられるのが理想」 ↓ redmine管理者の力量（管理可能範囲）が、開発チームのみにとどまるのであれば、そう言える。

Oja @kawanishi_ameya

@syootaro @akipii 自分はそれを理解するのにRedmineと度付きあいをした挙句に泣かされてようやくなので、ITS/BTSを初めての運用から成立されられる人がどのくらいいるのだろうかとよく考えます。失敗経験必須なシステムってのもアレですし。

syotaro @syotaro85

@kawanishi_ameya @akipii 確かに、redmine（ITS/BTS）によるプロジェクト設計スキル習得は、失敗経験必須ですね。今のところ。 というのも、体系的な、事例込み資料が世の中に少なすぎる。社外秘を含みやすい領域なので仕方ない気もしますが。

syotaro @syotaro85

@kawanishi_ameya @akipii redmine（ITS/BTS）によるプロジェクト設計を 体系的に学ぶために 体系的に知らない状況で 体系的にやってみるしかない。

Oja @kawanishi_ameya

@syootaro アジャイル開発なんかだとアジャイルサムライが(自分の時は)バイブル扱いでしたが、Redmine(ITS/BTS)では今のところそういうコンテンツがないんですよね。

syotaro @syotaro85

@kawanishi_ameya チケット（イシュー）サムライ… 　　( ﾟдﾟ )　ｶﾞﾀｯ 　　.r　　 ヾ ＿_|_|　/￣￣￣/＿ 　　＼/　　　　/

Oja @kawanishi_ameya

@syootaro チケットタスクをゲームの「クエスト」に例える人もいるので「チケットクエスト」とか

syotaro @syotaro85

@kawanishi_ameya クエストいいですね！ そうやって、特に若い層に、興味を持って貰えるバイブルの存在が望まれます。

akipii @akipii

@syootaro @kawanishi_ameya @sakaba37 さんが、初心者向けの本が必要とよく言っていて、僕は既に全て書いたから興味なかったけど、アジャイルサムライのようなチケット駆動本のニーズがあるわけですね。ようやく理解しました。

Oja @kawanishi_ameya

@akipii @syootaro @sakaba37 個人的には「とりあえずこの本に書いてあるようにやりましょう/やります」と言えれば上とも下とも意識合わせがし易いと思うのですよね。(根拠もないですが)

syotaro @syotaro85

@akipii @kawanishi_ameya @sakaba37 個人的にはそう思います。 変化の激しいプロジェクトが増える中 プロジェクト内の意識を早期に併せるための共通言語、アジャイルサムライ風のプロジェクト管理バイブルが求められているかと。

akipii @akipii

@syootaro @kawanishi_ameya @sakaba37 アジャイルサムライやスクラムブートキャンプは上手く書かれていて絵もコミカルで読みやすい。個人的には、redmineはチームでチケットを消すゲームという感覚を表現したい。

さかば @sakaba37

@akipii @syootaro @kawanishi_ameya リーン開発の現場のリアルさも捨てがたいですね。

syotaro @syotaro85

@akipii @kawanishi_ameya @sakaba37 イメージをストーリー形式で、イラストを用いて伝える、というのは、大事ですね。 管理手法というのは、技術のようにかっちり決まったものではなく、概念的なものなので。