第5回品川Redmine勉強会の感想 #47redmine
第5回品川Redmine勉強会にスタッフとして参加してきました。
盛り上がって楽しかったです。
資料をリンクしておきます。
感想をラフなメモ書き。
【参考】
第5回勉強会 - shinagawa.redmine
第5回品川Redmine勉強会 2013/6/29 - Togetter
【1】@sakaba37さんの資料。
共通結合、データ結合などのソフトウェア結合度の観点と業務フローの類似性のお話と、社内業務にRedmineを適用した事例のお話。
構造化設計のお話は、今では情報処理試験に出るくらいしか使わないから、ピンと来る開発者はいたのかな?
社内業務で、PC資産のタスク管理にRedmineを使った事例は興味深かった。
ある業務でタスクが発生して、そのタスクを管理したい時、チケット管理は有効であるように思う。
【2】その後、「マネージャ」「開発者」「運用担当者」「Redmineシステム管理者」の観点でワークショップ形式で議論した。
いろんな議論が出てきた。
皆同じような問題を持っているのね、と共感している人も多かった。
僕が興味を引いたのは、顧客との打合せ管理にRedmineを使っている人の話。
顧客との打合せや会議の準備で、タスク管理と工数管理をチケット管理で実施している。
トラッカー=顧客単位でチケットを発行し、全て打合せや会議の工数を記録し、月末に工数集計して顧客報告して請求するという流れ。
実績工数の作業分類にも、打合せの作業の種類に分けて、実績工数に色付けして入力・集計しているらしい。
この事例は、RedmineをCRMソフトとして使おうという発想であり、更に工数集計ツールとしても使おうとしている。
このアイデアは、第8回勉強会の感想~RedmineはCRMや情報系システムにも適用できる #RxTStudy: プログラマの思索にも書いたけれど、顧客問合せ(つまり、コールセンターやサポートデスクの管理)の管理機能にも関連する。
この辺りのアイデアはあとでまとめる。
他には、@naitohさんのRedmineシステム管理者としてのノウハウや事例が面白かった。
RedmineのVerUp作業は結構面倒だ。
Redmineを導入すると、開発チームはRedmineなしでは作業できなくなるので、気軽に改造したりVerUpして正常動作しなくなるのが怖いので、VerUpするのが難しくなる。
@naitohさんの話では、Ver1.4からBundlerでRubyGemをインストールするようになったおかげで、インストールしたRedmineの単位でRubyGemを管理できるようになった。
だから、Ver1.4以降では、異なるバージョンのRedmineを併存するのも問題ないとのこと。
特にVerUpするための検証作業で、既存の古いバージョンのRedmineと、検証中の最新バージョンのRedmineを一つのサーバーに入れている時は、Ver1.4以降なら問題ないみたい。
但し、プラグインはRedmineのVerUpで動作しなくなるので要注意とのこと。
Redmineは2.1になるまでに、Rails2→3、Ruby1.8→1.9、Prototype→JQueryへアーキテクチャが変わったために、追いつけていないプラグインが多い。
第8回RxTStudy勉強会で@marutosijpさんが言っていたように、プラグインと言えどもテスト自動化して日々ビルドする環境がなければ、ミドルウェアやライブラリのバージョンアップ作業に追いつけずに破綻してしまう危険があるのだろう。
改めて、TDDとCIの強みを印象づけられた。
また、Redmineのバックアップはやってますか?という質問もあった。
@naitohさんは、SQLiteなのでファイルコピーでやってます、とのこと。
@akiko_pusuさんからは、MySQLならDMP出力、Redmineの添付ファイルはrsyncでお手軽にやっています、というお話もあった。
DBのDMP出力、ファイルの同期作業は、Cronで日次に夜間に実施するなどすればよいだろうと思う。
【3】@tkusukawaさんのテーマ説明やLTでは、ヘッダに電子公告のように流れるメッセージが面白かった。
Twitter / hiyoshism: 勉強会の真っ最中に上司から「Redmineの導入は見送ります」というメールが届いた俺が来たよ。 #47redmine
【4】日経システムズの記者さんのLTでは、記者の眼 - 「新3種の神器」で開発現場を改革しよう:ITproの記事の裏話を少しだけ聞くことができた。
読者アンケートを取った結果では、Redmineの読者評価が高いらしい。
Twitter / akiko_pusu: Redmineの特集は何回もやってます。なぜか読者評価が高いです。アンケートでは普及率22% #47redmine
日経システムズという雑誌は、IT業界でしか読まれないだろうし、日経の雑誌を購入する層を考えると、SIの中堅~大企業の30代以降のSEやPM層が多いだろうと思う。
20代の開発者はそもそも購入する人はかなり少ないのではないだろうか?
また、日本のSIではアジャイル開発を採用している会社はほとんどないだろうし、おそらくウォーターフォール型開発が主流の会社で、Redmineを使っている現場が多いのだろう。
そういう読者セグメントを考えると、Redmineは日本のSIの開発現場で好まれやすいツールなのではないか、という仮説が思いつく。
ウォーターフォール型開発が主流の中では、XPやScrumを実践できないけれども、それでも軽量かつ規律ある開発をやりたい現場にチケット駆動開発がマッチしているのではないか、と想像する。
その議論については、以前、本来のチケット駆動開発(TiDD)とは何なのか? - Togetterでまとめた。
この辺りのアイデアも色々まとめてみたい。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
- 信頼度成長曲線の落とし穴(2021.02.12)
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
「Redmine」カテゴリの記事
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ(2021.01.02)
「ソフトウェア工学」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
「Agile」カテゴリの記事
- TeamsとSlack、Zoomの違いは組織文化の違いを助長しているのではないか(2021.02.15)
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
- 「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい(2021.01.17)
「Ruby」カテゴリの記事
- JRubyの終焉(2020.06.09)
- PythonとRubyの違い(2020.05.10)
- Ruby技術者認定試験の感想(2020.05.08)
- 「Rubyのしくみ」を読んだ後のRubyの感想(2020.04.07)
- Ruby初心者が間違いそうなこと(2020.03.06)
コメント