Redmineを活用したプロジェクト管理業務の改善

一般論文

Redmineを活用したプロジェクト管理業務の改善
神戸事業所

横浜センター

技術第3課
有田 忠生

そのため、Redmineや管理台帳に記録された情報を手１．まえがき

動で集計しながら工程を立案する必要があった。

当所では、主に電力事業者向けのシステムを開発しており、複数の電力事業者に対応した開発を行っている。シス
テム開発時には、標準パッケージが提供する共通機能を各要件電力事業者向けにカスタマイズしているため、機能の要否細分化してチケット起票①イナズマ線がなく進捗確認が困難②手入力が多く工程立案の効率が悪い③担当者ごとの作業負荷把握が困難
チケット状況
更新

プロジェクトリーダーや固有のカスタマイズの有無などの細かな調整が発生し、プロジェクト管理が複雑になっている。

チケット進捗
更新

このようなプロジェクトを効率的に遂行するためにプロ

REDMINE

作業の詳細化・担当者割り振り

担当者①の回避策としてイナズマ線は管理台帳併用
管理台帳更新がプロジェクトリーダーに集中

Microsoft Project
Microsoft Excel
管理台帳による進捗管理

ジェクト管理ツールRedmine（注1）及び拡張プラグインであるLychee（注2）を導入した。本稿では、これらを活用したプ

進捗確認

図１．工程管理の問題点

ロジェクト管理業務の改善について紹介する。

２．工程管理の問題点

３．Lycheeの導入

当所では、顧客から提示される機能変更点ごとに開発を工程管理の問題点を解決するため、Redmine用のスケ進めるためチケット駆動開発

ジュール管理や、担当者ごとの作業時間管理等、利便性がを採用している。プロジェ（注3）

高い拡張プラグインがセットになったLycheeを導入した。

クト管理ツールにはチケット駆動開発で代表的に使用されLycheeは、｢もっと“見える”、“さわれる”プロジェクト管ているRedmineを採用している。

理｣を目指した拡張プラグインであり、以下の機能を提供する。

Redmineの運用は定着したが、以下の問題により工程管（1）可視性の向上

理に要する工数が増大し、15名規模の開発プロジェクトで・ガントチャートでイナズマ線の表示ができる。

年間290時間を費やすこととなった。

・チケットの階層表示と、子チケットの表示/非表示（折（1）進捗確認が困難

り畳み表示）切替えができる。

Redmineはガントチャートにイナズマ線を表示できな

・先行チケットと後続チケットの紐づけ、クリティカルい。週次のプロジェクト会議では、登録済みの数百件のパスを設定できる。

チケットを1件ごとに進捗確認しており、会議時間が増大（2）操作性の向上した。

・ガントチャート、及びチケット一覧画面からのマウス回避策として、Microsoft ProjectやExcelの管理台帳操作で、開始日や作業期間を変更できる。

を併用したが、ライセンス数により利用者が限られるこ（3）便利機能の追加と、管理台帳を複数人で並行して更新することが難しい・マイルストーン表示ができる。

ことから、プロジェクトリーダーに入力業務が集中し、・リソースマネジメント機能で担当者ごとの負荷状況を工程の組替え作業に対応できない状況となった。
（ 図1の見える化できる。

①）

上記の機能による工程管理作業の省力化を目的として、（2）工程立案時の作業効率低下導入を決定した（図2）。

各チケットが独立しているため、工程を見直す場合には、全てのチケットに対して、担当者、開始日、及び終了日を手入力する必要があり、作業効率が低下した。
（図1の②）（3）担当者ごとの作業負荷の把握が困難（注１）チケットを管理する無償Webアプリケーション。
（注２）“さわれるガントチャート”などの機能を持ったRedmineを拡張する有償プラグイン。
（注３）開発手法の一種。作業を細分化したタスクをチケットとして起票して作業を管理する。

工程立案時には、担当者の負荷状況を考慮しながら工程を調整するが、Redmineには担当者ごとの負荷を集計する機能はない。
（図1の③）
43

Redmineを活用したプロジェクト管理業務の改善

細分化してチケット起票要件

作業の詳細化・担当者割り振り進捗管理の一元化

プロジェクトリーダー①リリースバージョンや機能で進捗フォロー対象を絞り込む

チケット状況・進捗更新

REDMINE②進捗会議までに終了予定のチケットを絞り込む

担当者

進捗確認

③遅延しているチケットを重点的にフォロー

Microsoft Project
Microsoft Excel
2重管理の廃止

図２．Lychee導入
図４．進捗会議での使用例

3.1

進捗確認、工程管理の省力化
3.2

Lycheeを活用することで、チケットを機能単位で集約で担当者ごとの負荷状況の見える化

担当者の負荷状況把握のため｢予定作業時間｣、｢実績作業きるようになると同時に、ガントチャートのイナズマ線の時間｣をチケットに入力する運用を徹底している。しかし、表示が可能になった。
（図3の①）

Lychee導入前は個人ごとの負荷状況を視覚的に確認する術

その結果、フォロー項目の削減と工程遅延作業の可視化がなく、負荷状況の判定が非常に困難であった。

が可能となり、会議時間の大幅な短縮を図ることができた。
さらに、ガントチャートをマウスで直接操作することでLycheeが提供するリソースマネジメント機能では、負荷作業順序の入れ替えや、作業期間の見直しが容易（図3の②）状況が容易に可視化（図5の①）できるため、いつでも担当者になったこと、ガントチャート上で担当者のチケットの情ごとの負荷状況の確認が可能となった。
その結果、｢担当者の高負荷による工程遅延のリスク｣の事報を変更できるようになったことから、スケジュール見直前検出や、担当者間での負荷調整が可能になった。

しの省力化を実現できた。
また、担当者が日々の進捗を直接更新することによって、タイムリーな進捗確認が可能となった。
Lychee導入後、年間290時間を費やしていた工程管理に①担当者ごとの予定/実績時間を日単位で集計要する工数を年間50時間に削減（導入前比83%削減）できた。

項目ツリーの折り畳み可能

担当者

図５．担当者の負荷状況の見える化①イナズマ線
表示可能
チケット一覧

担当者

開始・終了日

高負荷になっている
担当者は色替表示

工数

3.3

Lychee導入後の残課題

前述の通り、Lychee導入によって管理工数を削減できた。
ただし単にLycheeを導入しただけでは解決できない、以下の運用上の課題が表面化した。

②マウスドラッグで時期・期間変更可能（1）チケットの粒度や階層構造があいまい
チケットのツリー構造、粒度に関する運用ルールがな

図３．進捗確認、スケジュール見直しの省力化

く、チケット起票者任せとなっていた。Lycheeの有用な実際のプロジェクト進捗会議では、リリースバージョン機能であるチケットの階層構造表示を活用しようとするや機能でチケットを絞り込み（図4の①）、さらに終了予定日際、あいまいな構造による分かりにくさが新たな課題となった。

を過ぎているチケットのみに絞り込む（図4の②）ことで、遅（2）品質情報が一元管理できない延のあるチケットに着目したフォローが容易になった。
（図4

品質を分析する際に必要となる情報が複数の資料に分の③）散しており、品質情報の入力、収集に多くの手間がかかっていた。
（図6の①）（3）品質分析に時間がかかる
品質分析は｢開発フェーズごと｣ではなく、より粒度の細かい｢機能変更点ごとの開発フェーズ単位｣で行うため、
44

Redmineを活用したプロジェクト管理業務の改善

短期間で品質分析を繰り返し行う必要がある。一方、品第3階層のチケット起票時には、必ずチケットの担当者が質情報は手作業で集計していたため、品質資料の作成や1名となるよう、細分化を徹底した。

フェーズ移行審査に多大な時間を要していた。
（図6の②）②手動集計に手間がかかる

品質情報
確認
品質情報
手動集計
プロジェクトリーダーこれによって、チケットのツリー構造、粒度を統一し、新たなプロジェクト参加者にも理解しやすい運用環境を構築できた。

品質資料

4.2

Redmineであらかじめ登録されている｢担当者｣、｢作業開①品質情報が分散
品質情報
生産量（ページ数）
DR指摘件数
作業工数始日｣等の入力項目に加え、｢ドキュメント頁数｣、｢DR指摘件数｣等の品質情報を入力項目へ追加（図8）することで、品質︓
︓

品質情報
入力

チケット更新ルールの見直し

情報を一元管理するための｢品質データベース｣を確立した。
品質情報
生産量（ライン数）
障害件数
進捗率

担当者

チケット
編集画面

︓
︓

図６．品質分析の課題

品質情報の入力項目を追加

４．プロジェクト管理業務の見直し
3.3で述べた課題に対し、プロジェクト管理業務の見直しを実施した。以下に見直した3点について述べる。

4.1

チケット運用ルールの見直し

図８．品質情報の一元管理

チケットの階層表示を有効活用するため、チケットのツまた品質情報を集計するため、新たに追加した入力項目リー構造を以下の構成で定型化するとともに、進捗率の考はチケットの担当者が更新するよう、運用フローを見直した。

え方を明確化するように運用ルールを見直した。

（図9）

第1階層：機能的な変更内容を記載する。（図7の①）担当者が対処時に品質情報を入力することによって、品第2階層：｢S/W設計｣、｢製作｣等、開発フェーズを記載質情報を早期に確認できるようになった。

する。（図7の②）

さらに入力作業を担当者が行うことで、プロジェクトリー

第3階層：｢作成｣、｢DR｣、｢DR是正｣等、具体的な作業項ダーと担当者の重複作業を削減し、プロジェクト管理の作目を記載する。（図7の③）
①第1階層

②第2階層

親チケット
XX機能追加

子チケット
調査・検証

業効率が改善した。

③第3階層

子チケット
基本設計

プロジェクト
リーダー

孫チケット
設計書作成

REDMINE

孫チケット
設計書レビュー
子チケット
詳細設計

要件

孫チケット
設計書作成

受付

子チケット
結合試験

チケットの確認・処置
チケットの状況・進捗更新

孫チケット
製作：：

細分化してチケット起票
チケット対応を指示

孫チケット
設計書レビュー
子チケット
製作

担当者

フィードバック

品質情報の入力
進捗のフォロー孫チケット
コードレビュー

品質情報の収集・分析

孫チケット
試験実施

チケットクローズ

孫チケット
試験結果レビュー

図９．運用フローの整備

図７．チケットツリー構造の見直し

45

Redmineを活用したプロジェクト管理業務の改善

4.3

現在は、監視者が定期的に入力遅れをチェックし、フォ品質分析用ツールの開発ローしている。
入力遅れがあるとチケットを更新できないようにすると品質情報を効率的に集計するためにRedmineの｢品質いった対策や、構成管理サーバから自動で品質情報を収集データベース｣を活用した自動集計ツールを開発した。

する仕組みなどを検討し、入力遅れの防止を進めていく。

自動集計ツールはRedmineから出力した品質情報のCSVファイルを読み込み、読み込んだ値を集計、整形するため（3）チケット単位でのフェーズ移行審査の見直し
当所ではより詳細に生産物を審査することを目的に、チのExcelマクロである。
本ツールを利用することで、開発フェーズごとの品質情ケットの単位でフェーズ移行審査（設計／製作／試験の報の集計や、案件ごとの品質情報の集計作業を効率化する

フェーズごとに、生産物の審査を行うこと）を実施している。
しかし、チケットの件数が多い場合には、手作業で品ことができた。
（図10）

質指標と比較して評価することは、作業量が膨大となる。

自動集計ツールの活用により、15名のプロジェクトで年実績値を自動で収集し、指標値と差異をタイムリーに間120時間を費やしていた品質情報の集計時間を、年間25比較し、ガントチャート上に視覚化して表示できるよう時間へと削減（導入前比80%削減）することができた。にできると理想的である。
品質資料

自動集計ツールの改善を進め、プロジェクトの更なる自動集計による品質確認の効率向上見える化・効率化を図っていく。

品質情報
確認
CSV
プロジェクトリーダー

担当者

LycheeRedmine

品質情報
入力

６．むすび
Lychee導入により、スケジュール見直しの省力化、担当

チケット
品質情報
生産量（ページ数）
生産量（ライン数）
障害件数
進捗率
DR指摘件数
作業工数（見積と実績）者の負荷状況を見える化して負荷平準化が容易となった。
また確立した品質データベースを有効活用することで、品質確認の効率を向上させることができた。

︓
︓今後は、品質データベースの更なる有効活用を目指し、生産効率や品質情報を担当者ごとに集計する仕組みの構築

CSVファイル内容
品質資料に手動コピーして使用するや、品質情報の入力の自動化を進め、組織の弱点分析に活用していく。
最後に、本改善及び執筆に当たり、様々な面で支援いただいた関係者の方々に深く感謝を申し上げる。

図10．品質確認の効率向上

５．今後の課題と改善に向けた取り組み
Lycheeの運用が定着しつつある中、新たな課題も明らかになってきた。以下に今後取り組むべき課題を記述する。
（1）チケット初期投入の作業効率化
4.1節に記述のルールに従い、改造項目ごとに複数のチケットを作成するため、チケットの初期投入に手間がかかっている。

執筆者紹介

作業項目はほぼ定型化されているため、入力データのテンプレート化、及びテンプレートからの自動入力といっ有田た仕組みを実現することで、初期投入作業の効率化を進忠生

アリタタダオ

1994年入社。主に電力事業向けシステめていく。

ムのソフトウェア開発に従事。現在、神（2）品質情報入力遅れの防止

戸事業所横浜センター技術第3課。

担当者の作業が繁忙の際には、進捗に直接関連しない品質情報の入力がおろそかになりがちとなる。
46