[ Redmine index ]

Redmine運用メモ

Redmineを、単なるバグ管理システムとしてではなく、開発作業（いわゆるチケット駆動開発）に使った経験から思うところをメモに残すページ。

前提

• プロジェクト全体ではなく、システムの一部機能を開発する10人弱のチームでRedmineを使用
• プロジェクトの開発工程はウォーターフォールを使用
• プロジェクト管理は、Microsoft ProjectをツールとしWBSおよびガントチャートで実施
• 各チームは定期的にWBSおよびガントチャートで進捗報告

運用メモ

チケット管理に関する運用

チーム管理者（作業場所には常駐してない）がチーム各員から進捗状況を逐一ヒアリングすることなく、作業状況をRedmineを見れば調べられる仕組みを作りたい

背景

• プロジェクト全体で管理するWBS／ガントチャートは、基本設計、詳細設計、という工程毎に機能が列挙される観点の階層構造だったので、そのままRedmineのタスクに持ってくると「センサー設定画面詳細設計」のようなチケットになる。これではチケットの粒度が粗すぎて、何の作業をするのか、チケットの終了はいつかが見えない。
• 開発作業の観点でチケットを作ると、「センサー設定項目をリストアップする」、「項目の有効範囲を定義する」、「Swingでテーブルの項目別ソートの実現方法を調べる」、といったチケットが乱立するが、これをプロジェクト全体で管理するWBSに載せると、大混乱になる。
  • 上級管理者は、WBSに基づくガントチャートをめくってプロジェクト状況を把握したがるが、把握可能なボリュームを越えると怒りを覚える（「こんなんじゃ分からん！」）。しかし、その割に、ピンポイントでは詳細粒度なところを聞きたがる（たいてい個人的な技術興味で）という不思議な種族らしい。
• WBS上の作業は短くても数日以上の期間なので、進捗を入れると主観的な%表現となり、90%問題が発生する。

やったこと

• WBSの作業項目と１：１に対応するチケットを作成する（通称「親チケット」）。
• 親チケットを完了させるための開発チームの実作業は、この親チケットの子チケットして作成した。
• 子チケットは最大でも3日内に終わる細かい粒度とし、進捗率はチケットのステータスに連動させ主観的な値は入れない。
  • ステータスが新規：0%、進行中：50%、解決／終了：100%となるようRedmineで設定した。
• 親チケットの進捗率は、Redmineの集計機能で自動的に出るので、これを定期的にMS Projectに転記した。
  • 転記するのはチーム管理者で、進捗報告の前にRedmineにアクセスして進捗報告資料を作成する。従来ならチーム全員にヒアリング（良い管理者なら各メンバー個別に聞きまわって進捗把握、だめな管理者だと全員拘束して進捗会議を実施）していたところが、ヒアリング作業はほとんどなくなった。
• カスタムフィールドに上級管理者向けWBS／ガントチャート記載作業を示すチェックボックスを付けた。
  • WBSの作業項目に対応するチケット一覧をフィルタ表示するため。
• カスタムフィールドに状況項目を定義し、親チケットはそこに状況のサマリを記入するようにした。
  • 親チケットは集計にしか使わないので、子チケットをなめて見ないと状況が分からないため。状況の項目をチケット一覧画面に表示することで、親チケットをフィルタ条件で一覧を出した時に、管理者好みの「Excel一覧」イメージに近づけることができる。
• XLS Exportプラグインを入れた
  • 試しに入れた1時間後にはチーム管理者がさっそく見つけて使っていた。察知力おそるべし

検討・考察

• チーム全体の進捗把握・報告がほぼRedmineをさらってまとめるだけになったので、チーム内の進捗会議は不要となった。
  • チケットの書き方が不十分（情報不足、分かりにくい書き方）なときはその担当者に個別質問することで、チケットの不備が浮き上がる。
• チケットの切り方に工夫がいる。親チケットをあらかじめ作成し、担当者にはチケットを子チケットとするよう伝達する必要がある。進捗会議の代わりに、作業予定（計画）会議を行うようになった。
• あいまいなWBS項目の作業は、着手してからどんどん子チケットが増大し、集計された作業時間が増え、進捗率が逆行することもある。（それが分かることはマネージメント上いいはず・・・）
• 親チケットのカスタムフィールド状況項目は更新が滞って現状とかい離しがちとなった。
  • 誰が状況項目を更新するか曖昧であったのが一因。チーム管理者が進捗把握の際に記入するのが理想（このフィールドの存在目的は管理観点なので）。

いつまでも完了しないチケットでゴミ溜めにならないようにしたい

背景

• 環境構築、とか作業手順を決める、というチケットがいつまでも終了しないままとなっている。
  • 環境構築は「とりあえず困らないようにはなっているが、一元管理ができてないので」
    作業手順は「暫定版を作って適用されているが、ちゃんとした手順にしたい」など
• 着手してみたら、想定外作業がどんどん発生し泥沼化している。
  • 仕様（基本設計）が曖昧で、調べていくうちに仕様再定義をしている状況になった。
• 設計書のレビューをする、とチケットに書いたが、時間がとれず片手間に見ているので終わらない。

やったこと

• チケットの記載ルールとして、必ず終了条件を書くこととした。
  • 環境構築なら、具体的に「Redmineからステータス変更メールが飛ぶようメールサーバーを用意しチーム全員のアカウントを作成し、チーム全員に伝達する」などと条件（必要条件）を記載する。
    これならば、メールアカウントが一元管理されていようがべたに（メールサーバのローカルにユーザーアカウントを作ってしのぐ）管理してようがチケットは終了となる。さらにやりたいこと（アカウントの一元管理）があれば別チケットをつくればよい。
• 終了条件が書けない曖昧な作業は親チケットとし、具体的に定義できる細部作業を子チケットとして作る。

できなかったこと

• チケットの定期的な棚卸
  • チーム内で気の利く人が周囲に放置チケットの状況を聞いてつついてくれたのでうまく回っていた。

チケットに成果を書いてしまわないようにしたい

背景

• チケットに設計成果を含めてすべてを書いてしまい、調査結果や設計結果を聞くと、チケットを開いて回答する人がいた。
  • チケットにデータベースのスキーマ設計の表などが書かれていたりする。

やったこと

• 作業の成果物はチケットではなくWikiなどに書いてとお願いした（のみ）

できなかったこと

• 成果物管理
  • 作業の成果物をどこに記載するか明確な定義ができなかったので、Subversionのドキュメントディレクトリに作成したもの、Wikiのどこかに作成したもの、チケットに書かれたもの、と成果物が散在してしまった。

不具合管理に関する運用

不具合一覧をExcelで見たい

背景

• 上級管理者は会議室にいってその場で紙資料で渡される不具合一覧を（はじめて）見る
• 会議室にPCの持ち込み／ネットワークアクセスといったインフラがないのが常態、唯一のホワイトボードも印刷できればめっけもの（たいてい紙がない、故障、などで印刷すらできないことも）
• 意思決定の場ではなく、各チームからの報告を聞き状況把握の場、不具合一覧をみて、各不具合がどんな内容でどんな処置をしたのか「分かった気になる」資料が望まれる

やったこと

• Excel一覧に記載するため、トラッカー「バグ」には、カスタムフィールドとして「障害内容」、「処置内容」を追加
• チケット一覧から未完了の「バグ」一覧をExcelにXLS Exportプラグインの機能でエクスポート

できなかったこと

• 不具合の処置予定日が計画／管理できなかった。予定を決める

不具合のステータス

基本フローの運用

Redmineのデフォルトのステータスは、トラッカー「バグ」については、基本フローは「新規」→「進行中」→「解決」→「終了」となる。

一般的な運用は次のようになるだろう。

• バグを発見したら、新規チケットを作成し、ステータスを「新規」とする
• バグの処置担当者を決めたら、担当者を変更するが、ステータスは「新規」のままとする
• バグの処置担当者が処置を開始したら、ステータスを「進行中」とする
• バグの処置担当者が処置を完了したら（変更をリポジトリに反映、等）、ステータスを「解決」とする
• 処置が含まれたソフトウェアがリリースされたら、ステータスを「完了」とする

承認制度があるならステータスを追加

古くから、不具合（バグ）チケットのステータスについてはいろいろな考え方がある。多くは、レビュー（承認）制度に影響されるので、組織のルール（実体）によって決めることになる。

組織のルールがRedmineのデフォルトのワークフローと合わない場合、ワークフローを新たに定義する。例えば、バグの解決は開発リーダーの承認が必須、という組織では、「新規」→「進行中」→「承認待ち」→「解決」→「終了」とするなど。

開発リーダーに加え、品質リーダーの承認も必要となれば、「新規」→「進行中」→「開発承認待ち」→「解決」→「品質承認待ち」→「終了」とするなど。

意見

ワークフローを考えるとき、「しっかり作らないと」と意気込んで、凝った厳格なワークフローを作ってしまいがちである。しかし、実際現場で運用すると、ワークフローを考えたときには想定していないいろいろな事情による逸脱が必要になる。これに対してルール厳守の原則主義で臨み、それら事情を排除してしまっては本来の目的である円滑な不具合処置の運用から外れてしまう。承認ルーチンも、承認権限を持つリーダーが忙し過ぎれば不具合処置が承認で滞り、プロジェクトの最適な状態である不具合が速やかに処置される状態と反対の状況を招いてしまう。

ワークフローを考案する場合、「あったほうがよいだろう」というステータスは大抵なくても問題ない。「なくては困る」というものをワークフローに取り入れるのがよい。

構成管理に関する運用

仕様書（機能定義文書）をバージョン管理下におきチケットで作業管理

背景

ソフトウェア開発対象機能がなかなか明確に定まらなく、また定めたことが後で違ったことが判明するなどの手戻りが多かった。また、開発が進んで不明点が出て仕様を確認すると、曖昧だった／考えてなかった、といったこともあった。

やったこと

仕様書の位置づけとして機能定義を文書化し、バージョン管理ツールに置いた。そして、機能定義について不明点、指摘事項を開発者からチケットとして挙げてもらった。それに対して順次機能定義文書を修正してコミットしチケットをクローズすることで残量がチケット件数で把握できるようにした。ただし、チケットは時間とともに発生し続け、いわゆるバーンダウンチャートのような右下がりにはならなかった。

この運用によって機能定義が連日修正され続けることになり、ソフトウェア開発側で追従しきれず悲鳴が上がった。そこで、Redmineのバージョン機能とSubversionのブランチを使って、機能定義をブランチし、既存機能の明確化／微修正は現行バージョンで、新機能や既存機能の大幅修正はブランチに反映した。

Redmineのバージョンアップ（データ移行）

Redmineはオープンソース製品であり、ユーザーニーズを受けて日々開発が行われ、新しいバージョンが時折登場する。新機能はぜひ使いたいところだけれど、トラブルなくバージョンをあげられるか不安ではある。

そこで、バージョンアップを容易にすること、阻害することを整理して蓄積しておきたい。

プラグインを伴うバージョンアップ

経験的に、バージョンアップで起きたトラブルの過半数が、プラグインに伴うものであった。Redmine本体のバージョンアップと、プラグイン側の対応には当然タイムラグがある。また、Redmine側のバージョンアップがプラグインの動作を阻害するかどうかということもある。現状は各プラグイン開発側で確認よろしく、というものである。

プラグインによるバージョンアップトラブルの一例は、あるプラグインがデータベースを変更（既存テーブルにカラムを追加）し、そのプラグインが新しいRedmineバージョンに対応してないため入れなかったが、プラグインの正式な削除手順を踏んでいないためデータベースの変更が残ったままとなり、それが原因でエラーになる（例えば、追加カラムがNOT NULL制約で、プラグインがない場合そのカラムにデータをインサートすることはないためNOT NULL制約違反画発生した）。

そこで、現実的なプラクティスは、

• 使用中のプラグインがすべて新しいRedmineに対応してから、Redmineのバージョンアップを行う
• 対応してないプラグインはあらかじめバージョンアップ前の環境でアンインストールしてから移行する

のどちらかとなるでしょう。

前者は、バージョンアップをしばらく見合わせることになるので不満が残る。結局、後者の手段をとることになる。

以下、大まかな手順を示す。

• 現在運用中のRedmine環境を壊さないよう、現行バージョンのRemineディレクトリを丸ごとコピーをとる
• データベースを別データベース名に複製する
• コピーしたRedmineのデータベース接続先を上の複製先のデータベース名に変更する
• プラグインのアンインストールを実施する
• 動作確認し問題なければ、データベースをバックアップする
• 新しいRedmineバージョンを構築する
• データベースのマイグレーションを実施する

ということで、Redmine本体のバージョンアップに追従したいなら、プラグインは極力少なくするのが良策。

Redmine所感

Wiki機能

ページの階層化は便利

RedmineのWikiページは、PukiWikiやTrac Wikiのようにページ名にスラッシュ'/'を含めることで階層化を表現するのではなく、関連付け（親ページを指定）で階層化する。Wikiは思いついたらページを作成し、あとで構造を整理するやり方がWikiのメリットだ。そのため、あとで整理するときにページ階層を移動させることが頻繁にある。RedmineのWikiでは、該当ページの設定で親を変更する。ページ名に階層が含まれていないので他のページのWikiリンクが切れる心配などもない。パンくずリストも親ページを指定すれば自動で変更される。

改行が改行になる

RedmineのWiki記法では、改行がそのまま改行で扱われる。他のWikiは、HTMLの段落やTeXのパラグラフのように、ソーステキスト上の改行は表示上の改行にはならない。この振る舞いについては賛否両論だろうが、日本語を入力する場合はうれしい振る舞いである。Wikiの記法を知らなくても、ほぼ入力した形で表示される。

構成管理（変更管理）したいドキュメント（仕様書）はWikiに書かない

Wikiは、随時変更が可能なので、徐々に発展させていくドキュメントには向いている。ということは、その逆に仕様書のように正式な資料（変更する場合、変更内容をきちっと周知が必要）はWikiには向かない。かってに変更した、いつの間にか変わっていた、などの問題に波及する。構成管理したい文書はリポジトリに置き、変更理由が生じたらチケットを作成し、修正／レビュー／完了が分かるようにする。

フォーラム機能

フォーラム機能の使用アイデア

今一つ使い方に悩むフォーラム機能であるが、いくつか使用例をメモ。

日誌

個人日誌用にフォーラムを作成し、各個人ごとにメッセージを作成。各日の日誌は、返答で作成、その際題名を年月日にしておくと後から参照しやすい。

普通三日坊主になるので９割方不要な心配だが、長くなってきたら、メッセージを新しく作ってもいいかと思う。

息の長い作業

チケットは、長くても１週間くらいで完結する１つの作業を切り出し、完了したチケットは後から見ることは稀なので、アクセス性はそれほどよくない。そこで、半年以上のスパンで継続する作業があれば、Wikiでもいいがフォーラムを使うのもよい。特に経緯を残したい作業は、Wikiよりフォーラムがよい。

物品管理

息の長い作業の例として、物品の貸借管理が挙げられる。経緯が残るので、フォーラムが向いているかと。

アドミニストレータ管理

インフラとなるマシン、ユーザーアカウントなどの作業を記録するのに、チケットが億劫であればフォーラムでも代替えできるかもしれない。ただ、こちらは管理プロジェクトを作ってチケット管理した方がよい気がする。

技術調査

技術調査は最終報告はWikiに上げるが、調査作業が進行している間の記録をフォーラムに残すとよい。技術調査は結果以上に過程が大事だったりする。チケットの場合、結果が出れば過程は捨ててもよいものに適する。

メールの経緯

ある議題で何回もメールのやり取りをするとき、そのメールをフォーラムに残しておくとよい。

Q&A

掲示板に近い運用なので、Q&Aとして使うとよい。

定例な会議実施

会議の開催、議題、議事進行、会議後のアクションなどをフォーラムで行う。会議形態（会議体）の名称でフォーラムを1つ作成し、各会議毎にメッセージを1つ作成、そのメッセージにおいて開催連絡、議題の事前記載、議事録、議事後のアクションを返答で随時追記していく。

統合性

Redmineが、他のBTS（Bug Tracking System）と違う一つの特色が、「情報共有サイト」としての機能を統合している点。

チケット／ワークフロー機能でバグ管理・タスク管理を行い、Wiki／フォーラム／ニュース機能で情報共有を行い、文書／ファイル機能でファイル共有を行うほか、バージョン管理ツールとの連携、ビルドツール（jenkins）との連携などがある。また、REST APIによる外部からRedmine機能を利用するインタフェースも提供しているので、他のツールとの連携もしやすい。

プロジェクトインフラを整える立場として、この統合性は高く評価したい。