torutkのブログ

ソフトウェア・エンジニアのブログ

第5回shinagawa.redmine勉強会に参加しました

昨日開催された第5回shinagawa.redmine勉強会に参加してきました。
半日の勉強会で、講演とワークショップ(グループ討議)の構成です。講演のスライドは上述のリンク先から見ることができます。

また、今回は次の2冊の書籍を著した小川さん、阪井さんが見えられてました*1

チケット駆動開発

チケット駆動開発

Redmineによるタスクマネジメント実践技法

Redmineによるタスクマネジメント実践技法

会場では、赤本、青本と呼んでいる人がちらほら。

会場について

今回の会場を提供いただいたIIJでは、社員有志が技術勉強会の支援として会場を提供する活動をしていますとのことです。

「チケットシステムの可能性 - 開発から業務まで -」(阪井さん)

最初の講演です。「Excelでもできるやん」に対する回答という想定で、Excel管理からチケット管理への道を紹介する内容です。Excelによる情報共有を、ソフトウェア工学のモジュール間結合度に当てはめて解説しているのはとても興味深いものがありました。モジュールを人に、データをExcelに喩え、Excelの共有の仕方をモジュール間結合度のレベルと対比してみたものです。

モジュール間結合度 課題管理方法 デメリット
共通結合 スプレッドシートをファイル共有 他のユーザに破壊される
スタンプ結合 スプレッドシートをメール転送で共有 手間が増える(転送とマージ)
データ結合 スプレッドシートを分割してメール転送で共有 コピー&ペースト増える
  • 上から下に向かってモジュール間結合の仕方としてはよくなっていく
  • 結合度の種類は、この3つ以外にも内容結合、外部結合、制御結合、非直接結合がある

これに対して、DBMSとテーブルプログラミングで結合するのをRedmine等のツール活用にたとえています。

Excelでも共有は実現できるけれど、共有の仕方によってデメリットがあるよ、デメリットはなるべく減らしていくのがいいよ、ということを「Excelでもできるやん」に対する回答としています(と解釈しました)。

次は、社内業務(資産管理)へのRedmine適用事例を紹介していました。PC1台1台について、ウィルス対策、ワイヤーロック有無などの情報を毎年更新する作業で、現状はこの資産管理をExcelでまとめており、担当の人(庶務さん)が1件ごとにその担当者に更新依頼をメールして回答を集約するという多大な労力を払ってるとのことです。これをRedmine化したことにより大分負荷が軽減できそうだということでした。Redmineのメール通知機能をうまくいかして多数への連絡、督促をすることなどうまい活用をしている様子が分かりました。督促は、回答がないものについてチケットの優先度を上げ、するとRedmienのメール通知機能で担当者に連絡がいくというもので、うまい使い方だな!と思いました。

ワークショップ(グループ討議)1回目

まず、討議の呼び水として、開発者向け/マネージャ向けと2つの講演があり、それを受けて
開発者向け/マネージャ向けと分かれてテーブルごとに議論しまとめを発表する、という形態です。

今回は、開発者向けのテーブルに座り、討議をしました。たまたま座ったテーブルは、阪井さん、日経SYSTEM編集部の中山さんが座るテーブルでした。
自己紹介でそれぞれRedmineの自分たちの活用を紹介し合ったことから、活用にあたってうまくいったこと、こまったことなど議論が発展していきました。印象に残ったトピックを列挙します。

  • 計画はMS Project(あるいはExcel)のガントチャート
  • 現状の作業はRedmineのチケットで把握
  • 完了までにこの後どれくらいかかるかはRedmineのチケットで把握
  • Redmineで計画作業をするのは向かない
  • 作業チケットには、ファイルエクスプローラのフォルダのように他のチケットを束ねるもんがあるといいね
    • 親子チケットでフォルダのような管理をしている
    • フォルダ相当のチケットとガントチャートWBSと関連付けしている
  • 遅れたタスクでマネージメント上知りたいのはあと○日
  • 定例進捗会議をなくす工夫(会議で聞かなくても状況を把握する)
  • 楽しく使ってもらえる工夫
    • 日経SYSTEMの最新号記事より、Backlogでの工夫事例
    • 進捗率をステータスで自動に入れる
    • 子チケットの進捗率を集計して親チケットの進捗率に反映
    • コードレビューなどチケットで「ほめる」
  • 影舞評判いい(Redmine難しい)

他のチームの発表から

  • 客先ごとにトラッカーを用意し、客先ごとに作業工数を集計
  • 活動の種類をカスタムフィールドに定義
  • 会議チケットを作成
  • 営業部門とRedmineの相性がいいかも
  • チケットはフィーチャーとタスクの2種類
    • 要件を確定したらフィーチャーチケット作成
    • フィーチャーを実現するのに必要な作業を、その子チケットにタスクとして作成
    • フィーチャーの完了判定は人間系で実施
  • 見える化がモチベーション
  • Monitoring & Controllingプラグイン
  • チケットが終了したらおめでとうアニメーションが出るといいな
  • Redmineをシンプルに使いたい
  • ガントチャート表示では題名が20文字位しか見えないのでその範囲で題名をつける
  • チケット入力方法をWikiに書き、プロジェクトコピーで各プロジェクトに反映
  • メール通知は大量になるのでRSSを活用
  • 色(テーマ)を変える

今回の討議を通じて、計画、現況、予測(計画見直しの材料)ということを思いました。
計画はMS ProjectやExcelでもよいですが、現況はガントチャートに恣意的な進捗率を埋めるのではなくRedmineで実作業(チケット)を元に集計したものを見たほうがよいでしょう。
予測はRedmineの問題タスクを詳しく調べて、このままいったらいつか、方針をこうしたらいつかを考えることで出てくるかと。

ワークショップ(グループ討議)2回目

運用者向け、Redmine管理者向けの2つのテーマで講演があり、その後各テーブルごとにどちらをテーマにするか決めて討議しました。

講演からのトピック

  • プレゼン画面にツイッターが大きな文字で流れてびっくり
    • そんなこととは露知らずツイートしてまい恥ずかしかった
    • n2witterというアプリで実現(Windows)
  • サーバー台帳
    • 1サーバー1チケット起票、資産情報、経緯を記入
  • 議事録
    • 1会議1チケット、参加者が回覧チェックする表、参加者が追記修正
  • 残業チケット
  • プラグインは〜7個のケースが大半(会場の挙手)
  • Ruby 1.8.7のサポートは明日で切れます
  • プラグインRedmineバージョンとの対応状況
  • プラグインにdb/*ファイルがあるか否かを見極めよう
  • 最新版の1つ前を使うのがベストプラクティス

ワークショップ

  • Redmine動作環境は、Bitnami、ALMinium、自前で構築、といろいろ
    • Bitnami、意外とさくっと入れられた
    • ALMinium、リポジトリのtrunkから取り出すので不安定なことも
    • CentOSRubyが1.8.5と古いので自分で1.8.7以降を入れる手間がかかる
  • バックアップどうしていますか?
    • 仮想イメージをバックアップ
    • RDBMSだけバックアップ(添付ファイルは使っていないから)
    • サーバーのディスクを丸ごとバックアップしている環境で使用
  • バージョンアップしたいことってありますか?
    • 新機能を使いことも、例えば親子チケット、複数リポジトリ参照
      • それって使っているのが開発者だからでは? 営業とかならあるままに使う
    • バージョンアップするのではなく、新しいRedmineを立てるのはどうか?
  • 仮想イメージのスナップショットを取ってからバージョンアップ(うまくいかなければ戻すだけ)

Redmineのバージョンアップでよくトラブる原因となるのがプラグイン回りでした。
プラグインについてはDBをさわっているかどうかで判断するとよいのはなんとなく経験的に感じていましたが、プラグインのdbディレクトリを見て判断するというのはなるほどと思いました。

LT

日経SYSTEMSの中山さん、先月号で新3種の神器としてRedmineを取り上げた話からいろいろと。

@tkusukawaさん、SubversionRedmineを使ってサーバーの設定管理をするYggdrasilを開発しましたという紹介。

日経SYSTEMSのRedmine利用率のアンケートは対象がITPro会員とのことです。IT開発者コミュニティですね。日経SYSTEMSはソフトウェア開発者というよりはその上のマネージャーやシステム設計者が購読層と思います。「Redmine何それ?」という状況から、「あのRedmineか」という状況に変わるかと少し期待しています。

サーバー設定管理は、/etc/xxx などの設定ファイルをSubversionリポジトリにサーバーごとにディレクトリを作って管理するというものです。自力でSubversionに設定ファイルをコミットするのに対して、まとめて(簡単なコマンドで)放り込んだり、変更してもコミットしていないものを検知したりとうれしい機能が満載でした。
最近仮想化で多数のサーバーを立てて似たような設定をして回っていたので、使ってみたいと思いました。

懇親会

参加者の半数くらいが参加していました。勉強会にしては参加率が高いかと思います。
Redmine運用/管理者は、組織内ではけっこう孤高な人が多いので、Redmineについて情報交換ができる場は貴重なのも一つ理由としてあるのかもしれません。懇親会の場では、悩みをけっこういろいろ相談しました。
懇親会後もお店の外でRedmine話が続いていたので、その場で誰かが半強制的に2次会幹事に指定され(まるでチケットの担当者を変更したような感じで)、2次会も開催されたようです。
残念ながら子供の世話を親戚に頼んでいたので、あまり遅くなることができず、2次会には参加せずに帰宅しました。

*1:当日は書籍をしっかり持参し、サインを両名から頂きました