Redmine ＋ Lychee導入のアンチパターン

© 2018 Fuji Xerox Advanced Technology Co., Ltd. All rights reserved.
2018年2月15日 Developers Summit 2018
2018年8月9日 Lychee Redmineユーザー会
デバイスソフトウェア開発統括部／小林稔央
第3回 Lychee Redmineユーザ会
Redmine + Lychee
導入のアンチパターン

© 2018 Fuji Xerox Advanced Technology Co., Ltd. All rights reserved. 2
• 自己紹介
• 類似の文献について
• Redmine導入前のアンチパターン
• Redmine + Lychee導入時のアンチパターン
• まとめ
もくじ

自己紹介
富士ゼロックスアドバンストテクノロジー株式会社
プロジェクト管理者組み込みソフトウェア開発者新規事業ディレクター
サーバサイド開発、ミドルウェア開発を経て、2004年より組み込みソフトウェア開発に従事。
「楽しよう、楽しもう」をモットーに、当時の組み込み業界では珍しかったCIの導入をはじめ、
ツール活用を推進。現在はオフショアチームを率い、ハイブリッドアジャイル、OODAを取り入
れたプロジェクト管理をRedmine + Lycheeを活用して実施。担当チームは品質テスト、市場トラ
ブルともにゼロを五年間継続中。Redmineエバンジェリストの会メンバー。帽子が大好き。
楽に楽しく開発したい。ツール使おう。
トラブル発見は品質向上のチャンス!
トラブル発見したメンバーを大いに褒める。
コツコツ作業は苦手。自動化する。
Redmineエバンジェリストの会メンバー。
帽子が大好き。
簡単に言うとこんな人

今回は自称Redmineエバンジェリストとして、Redmine導入前のアンチパターンと、
Redmine Lycheeを利用する場合のアンチパターンについてお話しますが、
Redmineでアンチパターンといえば、以下のような文献が存在します。
有益な情報が満載ですので、ぜひ御覧ください。
【参考文献】
類似の文献について
■Redmine導入のアンチパターン
https://www.slideshare.net/hidehisamatsutani/redmine10
松谷秀久（@mattani)氏
■RedmineのFAQとアンチパターン～親子チケットの功罪
https://www.slideshare.net/akipii.oga/16redmineredminefaq
小川明彦 (@akipii)氏
■RedmineのFAQとアンチパターン集
https://www.slideshare.net/akipii.oga/redminefaq
小川明彦 (@akipii)氏

Redmine推進者に捧ぐ。。。
導入前のアンチパターン

「Redmine用意したから使って(使え!)」
傾向
• 推進者からの圧力。チームの意向無視。
• プロジェクト状況無視、導入結果をいついつに報告して。
対策
• ツール導入のメリットをチームに納得してもらい、自ら使いたいと思ってもらう
のが理想。改善活動は、押し付けられてもうまくいかない。
• 推進者は、チームに余計な作業を増やしたり、無理な導入を求めないこと。
• ツール導入はプロジェクトをうまく進めるための手段であり、目的ではない。
• チームの状況に合わせて、段階導入や一部だけの導入も検討する。
• Redmine警察、Redmineマイスターを用意して都度相談にのる。
「打ち捨てられていたRedmineが復活するまでの軌跡」@y_hokkey
ツールによる改善は、モチベーションが重要。
最優先はツール導入ではなく、プロジェクトの成功。

「なんか嫌だ、使いたくない。」
傾向
• 特にツールは利用していないが、なんとなくうまくいっている
チームや担当者でありがち。
• ただし、今のままではプロジェクト管理上、良くないことは理解している。
対策
• どこに不満があるか詳しくヒアリングし、不満の理由を明確化する。
• メンバーが感じた違和感は、都度解決すること。Redmine警察、Redmineマイス
ター。
• 放っておくとモチベーション低下→活用頻度低下。
ちょっとしたことでよいので、「良くなった!」という実感/成功体験を感じても
らうのが大切。
違和感がある=改善ポイントが見えるということ。
プラグイン他との連携で解決を図ろう。

「現状の開発プロセスを、厳密にRedmineに反映しようとする。」
傾向
• 複雑なワークフロー。ステータス変更権限が細かく分けられている。
• トラッカーの種類が多い。入力項目がまったく同じものがある。
• 使わない入力項目(測定値、ステータス)がある。形骸化まっしぐら。
対策
• 開発プロセスをワークフロー化しない。プロセス毎にチケット化する。
「RedmineのFAQとアンチパターン～親子チケットの功罪」@akipii では、
スタンプラリーと呼ばれているアンチパターン。
• トラッカーは入力項目を定義するもの。分類ではないことに注意する。
「最近は、トラッカーの追加とは入力フォームを設計して追加することだと説明
するようにしています。 @g_maeda とツイート。
• 導入初期は入力項目を最小限に。チームで相談し、できるところまでに絞る。
Redmine導入は開発プロセスを見直す良いチャンス。
この機会に最適化しましょう。

チケット更新が容易になったんで。。。
Redmine+Lychee導入時の
アンチパターン

「進捗率が信用できない」
■傾向
• 担当者がガントチャート画面から、進捗率を計画通りに合わせてしまう。
• 進捗率やチケット粒度のルール化が出来ていない。
■対策
• チケット粒度をルール化する。Lychee導入後は細分化しても管理可能。
• 進捗率ルール案1) %毎のルールを決める…作業毎に検討必要。結構大変。
• 進捗率ルール案2) ステータスと進捗率の連動機能を利用…ハマらない作業がある。
• 進捗率ルール案3) 進捗率を使わない。作業を小チケットに分割し、その小チケッ
トの完了/未完了だけで管理する(進捗は子チケット連動)…慣れれば一番簡単。
• ホントの報告ができるチームづくりが出来てますか?
• ホントの報告を受けてきちんとフォローする体制が取れていますか?
Redmine + Lychee アンチパターン
進捗率、ステータス、チケット粒度のルールを決める。
現実の進捗が報告でき、対応できるチームづくりを。

作業粒度をあわせて分割
進捗率とステータス管理の簡略化
小チケットで管理
小チケットの完了を親チケットの進捗として自動反映させることで、
進捗率を使わない方法を推奨 (「承認待ち」は運用次第で)
ステータスを限定
未着手作業中承認待ち完了

「どんどん伸びるガントチャート」
■傾向
• レビュー前までは計画通り進むが、レビューが直ぐに終わらない。
• レビューが終わらないので期日の延長を繰り返した結果、期間の長いチケットと
なってしまい、進捗が曖昧になる。
■対策
• 予定通り進めやすい作業と、予定通り進みにくい作業を、分離して管理する。例
として、レビューチケットや、調査チケット等が該当する。
• レビューの場合、指摘対応が多い(重い)場合は、幾つかの子チケットに分解する。
• 指摘対応が必須でない場合は、課題管理のチケットに変更し、後日改善を検討す
る。
計画しやすい作業チケットと計画しにくい作業チケットは分離する。
必須でない作業は課題チケットとして管理しよう。

分析
設計
実装デバッグ
サブ検査
統合検査
分析
分析レビュー
設計
設計レビュー
実装
実装レビュー
統合検査
レビュー
統合検査
サブ検査
レビュー
サブ検査
デバッグ
レビュー
デバッグ
開発プロセスチケット
作業とレビューの分離例

「いつのまにか無くなってる(完了している)。。。」
■傾向
• 担当者は、ステータスを「完了」にしないと残作業として残り続けるため、さっ
さと手離れしたい。(良い傾向)
• しかし「完了」にすると、管理者はチケット探しで困ってしまう。
• 残念ながらRedmineの検索機能は貧弱なため、未完了チケットと先週完了したチ
ケットを同時に表示するのは困難→見落としに繋がる。
■対策
• 「承認待ち」ステータスの追加。完了に出来る権限をもつメンバーを限定する。
• 定例会(週報会)などでガントチャート画面を表示しながら進捗確認し、リアルタ
イムで「承認待ち」→「完了」にすることで、チェック漏れを無くす。
• Lycheeチケットボードで未完了と完了チケットを同時に表示できる。
「承認待ち」ステータス追加でチェック漏れを回避。
ガントチャートからの更新機能を活用しよう。

Lychee チケットボード
完了しているチケットも
表示される。

• 推進者はツールを押し付けない。Redmine警察、Redmineマイスターを用
意して都度相談にのる体制を作る。
• Redmine導入時に現状のプロセスを見なおす。
• 進捗率、ステータス、チケット粒度のルールを決め、共有する。
• 管理しやすいチケットと管理しにくいチケットの運用方法を決めておく。
• 「承認待ち」ステータス追加でチェック漏れを回避する。
（or チケットボードの利用）
まとめ

Redmineエバンジェリストの会では、Redmine運用とその運用レベル(チーム
のツール活用成熟度)に応じて、どのような課題があり、どう対応していけば
よいかを、マズローの欲求5段階説、CMMI、抵抗の６階層などと組み合わせ
て議論をはじめました。いつかお話できる日がくることを。
http://madowindahead.info/2017/12/redmineeva/
「Redmineエバンジェリストの会」について

Xerox、Xeroxロゴ、およびFuji Xeroxロゴは、米国ゼロックス社の登録商標または商標です。

プロジェクト名：「ProjectA」
親チケット：「#1119 機能A」、
子チケット：「#1130 設計」のとき、
通知メールのタイトルは
[ProjectA - #1130] 設計
となり、何の設計作業か、メール本文を開かないと把握できなくなる。
そこで、Rubyの実装を直接編集し、メールタイトルを以下のように変更。
[ProjectA - #1119 機能A] #1130 設計(実施中)
Appendix.1) 通知メールの件名調整

Appendix.1) 通知メールの件名調整(mailer.rb)1

Appendix.1) 通知メールの件名調整(mailer.rb)2

Appendix.1) 通知メールの件名調整(issue_add.html.erb)

Appendix.1) 通知メールの件名調整(issue_edit.html.erb)

チームのRedmine利用状況
項目現状
Redmineバージョン V3.4.2(Windows Server 2012R2 + Bitnami) ※Linux移行予定
Lychee関連のプラグイン Lychee Association Chart plugin
Lychee Actual Date plugin
Lychee Gantt Chart plugin
Lychee Gantt Chart Pro plugin
Lychee Issue Set plugin
Lychee以外のプラグイン PlantUML plugin for Redmine
Redmine Checklists plugin (Light version)
Redmine Issue Templates plugin
Redmine Mermaid Macro plugin
My Page Customization
Redmine Wiki Extensions plugin
Redmine Wiki Unc plugin
Redmine Work Time plugin
正式導入時期 2016年4月 (3ヶ月トライアル実施)
プロジェクト数サブプロジェクト含め10件
メカ/エレキメンバーを加えた部門横断見える化活動実施中。
チケット数 2200件, 2/15現在のOpen数80件
トラッカー Q&A/問題課題/機能導入/仕様変更/調査
分析・設計・実装/分析・設計・実装レビュー/
デバッグ・検査/デバッグ・検査レビュー

Redmine ＋ Lychee導入のアンチパターン

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Redmine ＋ Lychee導入のアンチパターン

Ähnlich wie Redmine ＋ Lychee導入のアンチパターン (20)

Mehr von agileware_jp

Mehr von agileware_jp (20)

Redmine ＋ Lychee導入のアンチパターン

Hinweis der Redaktion