2012/03 発表資料

1. - 失敗は成功の糧 -
2012/03/16
OCC Corporation
Miyazato

2. 2
株式会社オーシーシー
IT開発本部 民需・Webシステム部
Webサービスグループ 課長
宮里 匡
 1999年 株式会社オーシーシー入社
 1999年 ～ Webグループウェア WebMagic 開発
 APITT PMコース 6期生、7～9期では講師を担当

3. 3
 Redmine はオープンソースのプロジェクト管理
ソフトウェアです。
 プロジェクトのタスク管理、進捗管理、情報共有
が行えます。Subversion や Git などのバージョ
ン管理システムとの連携機能も備えており、ソフ
トウェア開発や Web サイト制作などの IT プロ
ジェクトで特に威力を発揮します。
※Redmine.JP より引用
http://redmine.jp/overview/

4. 4
 導入のきっかけ
◦ 別の部署が既に Redmine を使っていた
◦ 一緒に使わせてもらった
 導入した業務
◦ 新規開発
◦ 保守案件
◦ 問い合わせ対応
◦ etc..
プロジェクト、タス
ク管理は微妙。
ナレッジベースとし
ては成功。

5. 5
 Redmine の仕様を理解できていなかった
◦ プロジェクト、トラッカー、チケット、時間記録
◦ トラッカーとワークフローにロール
 業務全てを Redmine で行おうとした
◦ 業務フローに設定をあてはめる想像力が足りなかった
 管理者が多くいて、各々好きに設定してた
◦ 変更管理等の規約もなく設定のカオス化
 当時の Redmine の機能では限界があった

6. 6
 導入のきっかけ
◦ 社内で仮想化が進んで、独自にサーバーを立てることが
容易になった
◦ 管理者多数の全社共有で使っている Redmine では運用
に限界を感じ、再構築を検討
◦ 部署に対してインシデント発行・管理の周知徹底があり
、メールでの管理は無理と感じていたので Redmine を
使ったインシデント管理(課題管理)を提案

7. 7
 部門で Redmine を適用した業務
◦ インシデント管理
◦ 問い合わせ情報
◦ 課題管理
◦ 時間外勤務申請管理
◦ 電子媒体管理 ※一部
◦ 保守プロジェクト ※一部
◦ 開発プロジェクト ※一部
◦ 各業務のドキュメント類 ※一部

8. 8
 全社的に発展している業務
◦ インシデント管理
◦ 問い合わせ管理
◦ 課題管理
 課題の見える化
◦ 時間外勤務申請管理 (システム部門)
 実作業のチケットと関連付けられる
ナレッジ化

9. 9
 保守・開発業務で使用している部課が一部にとど
まっている
 登録する人としない人がハッキリしている
 営業等の他部門への周知が十分ではない

10. 10
 Redmine の仕様を理解する
 業務を絞って導入し、徐々に広げていく
 業務を分析する
 最小設計、最小導入を心掛ける

11. 11
 先に実績を作ってアピール
 メリットに気付いてもらう
 判りやすいキャッチコピー大事
 スモールスタート大事
 面倒でも小まめな勉強会やフォローを行う

12. 12
時間があれば
設計例でも

13. 13
1. ターゲットにする業務を選ぶ
2. 業務で必要な役割を洗い出す
3. 業務で必要なタスクを洗い出す
4. 役割をロールとして登録
◦ アクセス権の設定
5. タスクをトラッカーとして登録
6. トラッカーにワークフローを設定
7. 所属等をグループとして登録
8. ユーザーをメンバーとして登録
◦ グループに紐づける
9. プロジェクトを作成
◦ モジュール、トラッカー、グループ(メンバー)、作業分類を設定

14. 14

15. 15
 ロール
役割のことで、例えば「課長」や「SE」などが考えら
れます。プロジェクトや各モジュールへのアクセス権の
設定、トラッカーの承認経路設定等、権限にかかわる設
定に使われます。
◦ プロジェクトごとに役割を変えられます
◦ トラッカーごとに承認経路(ステータスの変更権限)を設定できます
グループウェア
開発 PJ
役割：SE
財務会計開発 PJ
役割：PG
機能追加
新規 着手 完了 承認 or 否認
役割：SE 役割：SE役割：PG 役割：PG

16. 16
 トラッカー
仕事を割り振る単位となります。プロジェクトのタイプ
によって変わってきます。
◦ 保守・運用
例：機能追加、仕様変更、バグ・不具合、マニュアル、保守作業、
メーカー問い合わせ、構築・導入
◦ アジャイル開発
例：機能追加、仕様変更、バグ・不具合、マニュアル、リリース
◦ ウォーターフォール開発
例：営業支援、プロジェクト計画、要件定義、開発準備、基本設計、詳細設計、
プログラミング、単体テスト、結合テスト、総合テスト、受入テスト、
マニュアル、リリース、プロジェクト完了
※ トラッカーの付け替え(変更)は簡単なので、整理する手間を惜しまず、
運用にあうトラッカーを作り整理していく

17. 17
 グループ
ユーザーをグルーピングするときに使います。組織やプ
ロジェクトグループになります。
◦ グループをプロジェクトに紐付ける事ができます
 ユーザー
ユーザーごとに認証方式を設定することが可能です。
財務開発 PJ プログラムセンター財務グループ
役割：SE 役割：PG

18. 18
 ステータス
チケットの進捗を表します。
~
◦ 進捗率をそのまま使う
0%：0%
10%：10%
100%：100%
◦ プロジェクトで決めた進捗率を使う
新規：なし
着手：50%
完了：90%
承認：100%
保留：なし
 作業分類
作業時間を記録する時、「どの作業」にかかった時間な
のかを分類する。
◦ トラッカーを大まかに設計されていて、且つ細かい作業実績をとりたい
時には詳細にする
◦ トラッカーが詳細に設計されている時は、作業分類はシンプルにする

19. 19
 プロジェクト
運用に合わせて、ユーザー、グループ、トラッカー、作
業分類など複合的に設定する。
 どのトラッカーを使おう？
 誰(どのグループ)を加えよう？
 役割はどう割り当てよう？
 Wiki やフォーラムは必要？
開発 PJ
モジュール チケットトラッキング、時間トラッキング、Wiki、ガント
チャート、リポジトリ
トラッカー 機能追加、仕様変更、バグ・不具合、マニュアル
メンバー(ロール) 開発グループ(SE)、プログラムセンター(PG)
作業分類 設計、開発、検証、文書、会議