プログラマの思索

第8回#RxTStudy勉強会の感想をメモ書き。

第8回RxTstudy : ATND

RxTstudy

【1】@hakuraiさん「BacklogチームのGit運用」

BacklogチームのGit運用のお話。
Gitは1年前から使い始めたとのこと。

初めの頃は、masterからフィーチャブランチを作り、cherry-pickでマージしていた。
この運用方法は、Subversionのマージ方法と同じ。
しかし、cherry-pickなので、元のコミットと別物のため、どのリビジョンからマジされたのか後で分からなくなること。

次に、masterからトピックブランチを分岐して修正した後、-no-ffでマージして、ブランチの履歴を残すようにした。
すると、コミットグラフにどのブランチからmasterへ取り込まれたのかが分かる。
A Succeccful Git Branch Modelを参考にしたのと事。
しかし、トピックブランチが乱立して、コミットグラフがわかりにくくなった。

そして、今は、コミットログに必ずチケットNoを残し、rebaseを使ってマージするか、Fast Fowardでマージするようにしたとのこと。
No Ticket, No Commitがあれば、ブランチの履歴はコミットグラフに逐一残す必要がない。
rebaseやFast Fowardマージによって、リビジョングラフが一直線になり、見えやすくなる。

この運用方法は、Redmineコミッタのまるやまさんが質問されていたが、Redmineの開発スタイルと同じ。
RedmineはSubversionで管理しているため、Gitが使えず、rebaseでマージするしか仕方ない理由もあるが、大人数で開発する時はこのやり方がBetterなのだろうと思っている。

【2】@g_maedaさん「Redmineによるメール対応管理の運用」

Redmineをヘルプデスクに使った運用事例のお話。
顧客からの問い合わせメール対応を行うヘルプデスクの問題点は
・どのメールが未対応なのか分からない
・メールは履歴を追いにくい
・問い合わせメールが埋没しやすい
点がある。

上記の問題点を解決するために、
・Redmineの機能である「メール発行でチケットを自動登録」する方法を使う
・返信メールのような履歴は、チケットの注記(コメント)で記録する
・添付ファイルもチケットで集中管理する
・問い合わせメールから発生したタスクも関連チケットで管理する
ように対応した。

メールでRedmineチケットを自動登録する方法は、メールサーバー上でリアルタイムにチケット発行する手法と、Redmineサーバーからメールサーバーへ定期的にPOP3経由でメールを取得してチケット発行する手法がある。
やり方は下記に書いた。

メールでRedmineチケットを登録する機能のアーキテクチャ: プログラマの思索

メールでRedmineチケットを登録する機能の可能性: プログラマの思索

@g_maedaさんは、メールサーバー上でリアルタイムにチケット発行する手法を採用したらしい。
だから、Redmine設定画面でメール登録用のAPIを発行して、mail_handler.rbをメールサーバー上に配置して実行しているらしい。

メールによるRedmineチケット登録機能には、
・Subjectに「[#123]」のようにブラケットとチケット番号があれば、返信メールも該当チケットのコメントに追記してくれる
・添付ファイルもチケットに自動で添付してくれる
点があるのでとても便利。

また、ステータス管理は
・新規：問合せメール到着
・進行中：問合せメールを対応中。要返信。
・解決：問合せメールを返信済み。回答待ち。
・終了：「ありがとうございます」の返事で対応完了。
に置き換えて運用しているとのこと。

問い合わせメールをRedmineチケットで管理する利点は
・対応漏れをチェックしやすい
　(一定期間更新されていないチケット(例：3日以上)をクエリでフィルタリングして、スタッフに対応させる)
・メール到着状況やメール対応状況をチェックしやすい
　(ステータスをgroup byして、進行中や解決中のチケットを日々追跡してスタッフに対応させる)
点がある。

但し、問合せメールのRedmineチケット管理にはまだいくつかの問題点が残っている。

(1)返信時のSubjectのチケットNoが間違っている場合、別チケットのコメントに追加されてしまう。
(2)メールソフトとRedmineを行ったり来たりして面倒。
　メール対応という一つの目的で2つのツールを使っている。
　だから、一つの対応方法としては、Redmine画面上で返信メールを送信できる機能をプラグインで作るべきか？
(3)古いメールに新たな問合せを返信メールで送る顧客もいる。
　古いチケットNoがSubjectに入っている場合が多い。
(4)サポート担当者からメールを発信する場合、SubjectにチケットNoがないので、チケットが登録されない。
　顧客発信のメールによるチケットとサポート担当者が発信したメールによるチケットを、一つのチケットでまとめたい場合がある。
(5)ステータス変更し忘れる。
　忘れた頃に、終了チケットへ返信メールが追加されるが誰も気づかない。
(6)発信元アドレスがチケットに記録されない。
　メールによるRedmineチケット登録機能では、匿名ユーザとしてチケット登録されるため、メール送信者(顧客)の情報がチケットに残らない。

上記の運用は、Redmineがコールセンターのヘルプデスクシステムとして使えること、つまり、RedmineがCRMシステムとして運用できる可能性を秘めている事実を示している。

いわゆるCRMソフトでは、顧客からの要望や苦情のメールを一つのメールアドレスで受信する機能(インバウンドメール)、CRMソフト上から特定の顧客へ返信したり、顧客全員にメールを一括送信できる機能(アウトバウンドメール)がある。
「メールによるRedmineチケット登録機能」はまさに「インバウンドメール」機能そのものであり、Redmineに不足している機能である「Redmine画面上で返信メールを送信できる機能」はまさに「アウトバウンドメール」機能だ。
つまり、Redmineにもアウトバウンドメールの機能が追加されれば、CRMソフトとして一通り揃っていることになる。

SugarCRMを参考にしたら面白いと思う。
SugarCRMにも実は問合せ管理のためのチケット管理機能があるからだ。

SugarCRMの運用サイクル: プログラマの思索

Redmineチケットに顧客の問合せメールが転記されることによって、チケットが顧客情報に対応付けられ、チケット集計機能によって、顧客の行動を分析できるインフラが自動的に整う。
CRMではいわゆるバケット分析など、顧客の行動を分析するデータマイニングの手法はかなり揃っているので、Redmineのチケット集計機能へ応用すれば面白いと思う。

【3】＠marutosijpさん「Redmine本体の開発スタイル(仮)」
Redmine本体の開発スタイル

詳細は上記の資料通り。
興味深かった点は、Redmineはテストが厳しいこと。
日々CIでテストを自動化しているし、カバレッジも測定している。

RailsはVer2とVer3では、フォルダ構造もアーキテクチャもガラリと変わったため、VerUp対応はとても大変だった。
Redmineはテストが厳しく、テスト自動化の環境があったからこそ、RailsをVer2からVer3へ無事にアップグレードできた、とのこと。

RedmineがRails3対応を始めた時、コミッタのJPLは、まずテストのカバレッジを100％にすることから始めた。
その点はJPLはすごい、とのこと。

実際、Redmineから派生したChiliProjectやOpenProjectはRails3へのVerUpに成功していない。
コミッタやコントリビュータはいるが、ほとんどコミットされていないことからも分かる、とのこと。
RailsをVer2→3へアップグレードする作業がいかに大変であるかが分かると思う。

第3回品川Redmine勉強会の感想 #47redmine: プログラマの思索

おそらく、Railsの古いバージョンで作られたWebアプリはいずれも、Railsのバージョンアップに苦しんでいるだろうと思う。
システムがVerUpする速度に追いつけない理由の大半は、テスト自動化の環境がないために、品質が劣化してしまうからだろう。
解決の鍵は、テスト自動化にある点がとても興味深い。

【4】懇親会で@akahaneさんと話していて気づいたことは、RedmineがERPの情報系システムとして使える可能性を秘めていること。
GoogleのPageRankでは、あるWebページが他のWebページから参照される回数が多いほど有用であると判断するアルゴリズムがある。
すると、Redmineのチケットに関係するタスクや障害などを関連チケットや子チケットとしてリンクしておくと、そのチケットは、PageRankアルゴリズムの検索エンジンで上位に表示される可能性が高くなる。
何故なら、他チケットから参照される回数が多いからだ。

つまり、チケットという情報を有用であるデータにするには、単に障害をチケットに起票するだけでなく、過去のチケットと関係していれば関連チケットに紐付けたり、コミットログにチケット番号を書いたりして、そのチケットのWebページが他のページから参照できるように運用した方が良い。
すなわち、URIというWebページ表示のインターフェイスを通じて、チケットを検索する機能を有効にするには、チケットを他チケットやリビジョンから参照するように、チケットを保守する運用が大切なのだ。

同様に、Amazonのレコメンドエンジンでは、ある商品を買う顧客に対して、同じ客層の購買履歴から関連商品をお勧めする機能がある。
すると、Redmineでも、一つのソースを修正した時、他に関連するソースも修正した方がいいよ、とお勧めする機能があってもいいはずだ。
そのイメージは下記に書いた。

Redmineにお勧めソース機能が欲しい: プログラマの思索

つまり、Redmineのチケットに貯められた情報は、PageRankアルゴリズムやレコメンドエンジンを使ってデータマイニングすることで、有用な結果を抽出して分析に使える可能性があると思う。
RedmineをいわゆるBIとして使えるようになる可能性があると思う。

BTSをBusiness Intelligenceとして使う: プログラマの思索

ITSをBusiness Intelligenceとして使う方法こそが本来のソフトウェア工学におけるメトリクスの分析ではないかと思ったりする。

僕はRedmineをアジャイル開発に適用した事例しか持っていないけれども、@g_maedaさん、@akahaneさんのお話を聞くと、Redmineを単なるソフトウェア開発のタスク管理ツールとして使うだけでなく、他の用途にも使える可能性がある事実を示唆しているように思える。
Redmineのメーリングリストでも、Redmineを「製造業での工数実績収集分析ツール」として使いたいと考えている人もいる。

利用の可能性 - Google グループ

そんなことを考えると、Redmineはカメレオンみたいなツールだと思う。
ある時は、障害管理システムであり、タスク管理であり、ヘルプデスクシステムであり、工数実績収集分析ツールでもある。
その背後にあるチケット駆動開発には、どの場面に適用できるのか、という問題意識さえ持てば、たくさんの可能性が秘められているのだと思う。