Redmine Japan Vol2 登壇資料

1. 1
Redmine Japan Vol2 事例セッション
全社業務改善ツールとなったRedmineの振り返り

2. 2
発表者の紹介と環境について

3. 3
発表者の紹介と環境について
オンプレ(2016-2020)→Redmine（Myredmine）
チケット数：154,500チケット
プロジェクト数：95
ユーザ数：700
※今日発表の内容は、あくまで弊社のケースです。

4. 4
１．Redmine導入の背景

5. 5
１．Redmine導入の背景
まじめで礼儀正しく
2016年頃の弊社
タスク管理、問題管理、契約手続き、社内・部署ルールがメールや表計算ソフ
トで管理されている状態。

6. 6
１．Redmine導入の背景
蔓延する毒
2016年頃の弊社・・・・全社共通の毒
①表計算が表計算をリンクし、関係資料やバージョンも増える。
②メールが大量に飛ぶので見落とす、ミスが増える。負担が増える
③誰かがミスをする→是正(Excel)という名の重いルールが重なる。

7. 7
１．Redmine導入の背景
やられる管理職（先輩）たち
2016年頃の弊社・・・・ついにダウン
障害管理を行っている部署が破堤。
障害管理に関連する表計算ファイルが100個以上、
進捗管理する件数が1000行、30列を超える。
→ 毎週障害管理MTGの前日は管理者が徹夜で全ファイルをチェック
顧客対応、障害対応、
問題解決、報告精度
にも影響が出てくる。

8. 8
１．Redmine導入の背景
問題解決に呼ばれ導入を即決
2016年頃の弊社・・・・障害管理だけでもシステムで回せないか？
・以前見た（かるねが使っていたTrac）チケット管理システムを
構築してもらえないか。
・サーバー代は出すけど、最小限で。（予算なし）
キタコレ！
先輩方 わたし

9. 9
１．Redmine導入の背景
ほかの部署も・・弊社が陥った表計算とメールの蔓延による危機感
2016年頃の弊社・・・・実は全社全体に蔓延
・いろいろな部署にヒアリング
・やっぱり全社で蔓延しまくってた。

10. 10
１．関係者の人数に比例して暗黙社交辞令爆誕
２．データの再利用性がなく、再集計が必要
↓
礼儀正しく時間を奪う。(澤円さんのお言葉)
１．Redmine導入の背景
弊社が陥った表計算とメールの蔓延による危機感

11. 11
通常Redmineを導入する多くのケース
・ プロジェクト管理ツールとして使いたい
・ 開発プロジェクトで使いたい
・ 小規模な作業や運用管理を行いたい
弊社の場合
・ 全社規模でタスク纏めないとやばいことになる。
全社で使える（全社展開）ことが前提
１．Redmine導入の背景
つまり・・・導入のきっかけは

12. 12
２．全社展開前の準備

13. 13
２．全社展開前の準備
弊社でのターゲットとなる活用領域
Code
Issue Task
Management
Backoffice
Tasks
Managemet
ターゲットは？
営業
事務
委員会

14. 14
２．全社展開前の準備
継続プロジェクトのゴールは自立
チケット
最高💛 プロジェクトのように特定の期間で
終わるものは少ない。
長期的に使うものなので、一旦のゴールは
「チケットライフサイクルの自立※」

15. 15
２．全社展開前の準備
自立とは？
・対象管理プロセスの関係者が全員チケットを使う。
・プロセスの開始と終了が明確で現実と一致している。
・Redmineの管理者がいなくても、放置チケットの削除や
ルール（Ｗｉｋｉ等に書いたり統制したり）が自然と成り立っている。
・定期的に改善要望がでてくる
・関係者でチケット番号での会話が成り立つ チケット
中毒💛

16. 16
２．全社展開前の準備
準備①：システムの使い方を絞ることで、大きな課題にも適用する。
アンチパターンをしっかり読む。
・使う機能は標準機能に絞っておく。
・カスタムフィールドは多く使わない。（できれば全部必須）
・トラッカーとステータス、遷移前後のフィールド入力を意識する。
・Redmineワークフロー ≠ 組織ワークフロー
※上長承認がある場合はルールを決める。複雑な承認階層はしない
・関係者が多く、問題意識が大きいところを最初から狙ってもいい。
Project
Ticket
Ticket
主題
トラッカー
CF
添付
システム上シンプルな構成 ＝ Redmineのベストプラクティス
クエリ
ロール
グループ
Wiki/ﾌｫｰﾗﾑ/ﾌｧｲﾙ
必要な
ルール
関連文書

17. 17
トラッカー：「貸出管理」の例
CF(選択)：申請組織
CF(日付)：返却予定日
ステータス：「新規」 ステータス「返却待ち」 ステータス：「返却済み」
（終了）
必須項目（全員更新可）
カスタムフィールド(日付)
：返却日
必須項目（貸出担当者のみ）
全員が利用できるステータス
貸出担当者のみが遷移できる
ステータス
２．全社展開前の準備
準備②：テンプレートとなるトラッカーを用意しておく
カテゴリ：貸出カテゴリ
必須項目（貸出担当者のみ）
「これから作ります」よりも画面イメージを持ったほうがいい。
いくつかのトラッカーを事前に準備しておくのがよい。※CFの乱立を防ぐこともできる。
全社展開する上で、事前にテンプレートトラッカーを用意した。
・タスク、問題（初期をアレンジ）
・申請業務
・貸出管理
・案件管理（タスクをもう少し細分化した単位）

18. 18
２．全社展開前の準備
準備③：ステークホルダーとマインド
上司や同僚が既にチケットドリブンの有用性を把握し、全社に適用することに
理解があれば問題なし。
※上司や同僚に見方がいないか知見がない場合
・何かの改善活動（委員会や分科会等）に飛び込んでみる。
・上司や同僚に相談して組織パワーを使う。
・スモールスタートや検証という名ではじめてしまう（ゲリラ戦法）
なるべくおじさん（元部長や役職者など）を巻き込んでおくといろいろ都合がいい
マインド：失敗8割、成功2割
ただ、失敗しても有用性を見出してくれる人はいる。
１つでも成功したらファンが一気に増える。
チケット一つ作ってくれたら「ありがとう」、クエリを作ってあげて「ほめまくる」
困ったら、迷ったら：Twitterでつぶやく。#redmine #redmine.tokyo

19. 19
３．Redmine全社利用を目指して

20. 20
課題一覧全体報告.xlsx
個別課題報告書.xlsx
進捗・打ち合わせ履歴.xlsx
部別進捗報告.xlsx
関連報告やメール
過去の同様の問題など
３．Redmine全社利用を目指して
実際のケース①：部内（本部・全社）の課題・問題管理を報告書でやりとりしているケース
Project（課題管理）
Ticket
Custom Field(Link)/添付
関係チケット
Custom Field
Query
管理番号や一意に呼ぶときの総称
（例のあの件という表現）
Ticket ID/添付
関係者が１００人以上の規模で、問題解決を管理するケース。
問題の発生から完了までを報告書やメールで管理し、後日管理台帳に別途転記する運用から
Redmineに切り替えた。

21. 21
1年目：作業管理も何とかしたい
作業申請書／報告書.xlsx
作業計画一覧_yyyymmdd.xlsx
３．Redmine全社利用を目指して
実際のケース②：部内（本部・全社）の作業計画・報告を纏めたケース
作業予定や作業記録、報告もExcelからRedmineに変更
年間5000件ほどがチケットとして管理されることになった。
Project（作業計画）
Ticket
Custom Field
Query

22. 22
1年目：作業管理も何とかしたい
３．Redmine全社利用を目指して
実際のケース③：受発注、会計入力依頼を纏めたケース
受注したり発注したり、なんらかの会計計上を伴う手続きや契約書面を作成する
手続きなどの依頼をメールから全てRedmineに切り替えた。（依頼管理）
この依頼件数は年間15000チケットを超える。計上月を明確にするために初めて「バージョン」を活用する。
・受注や発注の計上依頼
・契約書面（検印）作成依頼
営業 事務
￥
Project
バージョン:22年１月度受付
期日：2022年1月31日まで(残り１日）
進捗率：95%
完了
進行中
ロードマップ
バージョン:22年2月度
期日：2023年2月28日まで(残り３０日）
進捗率：10%
新規
進行中

23. 23
４．成功したプロジェクトのヒント

24. 24
要因①： No Ticket No Commit
No Ticket No Work
３．成功したプロジェクトのヒント
４つの要因
要因②：
チケットステータス更新 ＝ 次の動作のスタート
or 終了
要因③：パス回しはチケットで。
チケット担当者 ＝ 実際の担当者
Ticket
ステータス：作業中
Ticket
ステータス：〇〇登録待ち

25. 25
要因④：
プロジェクトの成功は管理者次第！
管理者不在は失敗する
→ ファンから管理者へ
３．成功したプロジェクトのヒント
４つの要因

26. 26
４．Redmineで得られた効果

27. 27
４．Redmineでできるようになること
いろいろなことをチケット化
・障害管理
・作業申請/報告管理
・会計事務管理
・法務管理
・契約管理
・保守/運用管理
・IT資産管理
・リース/レンタル管理
・書籍の管理
・連絡事項(ニュース)/各種統計公開
・チーム進捗管理
・ＩＤ貸出管理
・ＲＰＡロボットへの依頼
など。いっぱいやりました。

28. 28
４．Redmineでできるようになること
２つの意識の変化
タスクはできるようになったが文化は変わったのか？
→ プロジェクトによるが、多くのメンバーの意識が変わってきた。
１．もう元には戻れない。精神的に安心できる。
２．データの再利用性できて効果やばい（語彙力）
次回Redmine.tokyoで

29. 29
４．Redmineでできるようになること
データの再利用から得られたもの：①行動の証明
①．行動の証明
そのタスクの起源や発生、タスク実行の履歴を記載することで、自身や他人の行動を
証明することができるようになった
＜効果のあったシーン＞
「昨日なにやったっけ？」「これ誰が触った？」「いつまでにやるんだっけ？」
「あの時頼んだ例のあれ（謎の圧力）」「あ。私のタスクほかの人でもできるわ」
「もともとどういう経緯だったか」「過去これぐらい時間が掛かった」等

30. 30
４．Redmineでできるようになること
データの再利用から得られたもの：②量の証明
②．量の証明
タスクの総量（チケットの数や実行時間の総数）自身や他人のタスクの総量を
証明することができます。
＜効果のあったシーン＞
「自身のタスク量が増or減している」「あの人働いていない気がする」
「今月のタスクは先月に比べてこうだった」
「このタスクが大きいから何とかしたい」

31. 31
４．Redmineでできるようになること
データの再利用から得られたもの：③所有者の証明
③．所有者の証明
タスクの所有者が誰なのかを証明することができた。
「特定地点の１タスク＝１担当者」でタスクを所有する人は
１名であることでチーム間の疎連携ができた。
＜効果のあるシーン＞
「このタスクの最新状況はだれが知っているのか）」
「担当者が休みになったけど、今しなきゃいけないタスクはないか」
「過去に対応したのは誰か」「誰が球をもっているのか」

32. 32
４．Redmineでできるようになること
データの再利用から得られたもの：行動、量、所有者証明の間接的な効果
シームレスなタスク引き継ぎと流動性の向上
タスクの引き継ぎのためだけに資料を書きなおすことが少なくする。
引き継ぎ時に手順と運用フローは重要だが、
＜過去の事例＞や＜対応の詳細＞を正確に引き継ぐことは困難です。
常に日ごろからタスクを他者と回している場合、タスクの流動性が向上し、
「自分しかできない（属人性）」を排除することができます。
担当者変更や増員根拠の証明
担当者の采配や増員などで、決裁者や他のメンバーに対して必要性を説明することは
非常に難しい。タスク量の証明や担当者を明確にすることで、
数字根拠を提示することができ、「自他ともにその判断が正当である」こと
を支援することができます。

33. 33
４．Redmineでできるようになること
データの再利用から得られたもの：行動、量、所有者証明の間接的な効果
複数視点の集計
同じチケットを見るにしても、見る人の視点によってみる項目が違います。
それぞれロール（役割）が異なりますので、当然の流れになります。
Aさん 全体のタスク量を集計したい人 ＝ 全チケット数や工数の一覧
Bさん 特定のタスクだけを集計したい人 ＝ 自分のチケットで、特定の条件を一覧
Cさん 皆さんが見る一覧を管理したい人 ＝ 全員が共通してみてほしい一覧
これらに対して、自分の必要とする一覧を作成し、記録することができる仕組みがあります。
これがないと、BさんはAさんに「集計して報告して！」といわれる可能性もあります。
※自分で見てほしいけど。だいたい偉い人は見ません。
もし機能があれば、必要な時にこのボタン(クエリ）を押せと言えばいいだけです。

34. 34
５．実際に導入してみて

35. 35
・ Redmineで多くのデジタイゼーションは可能
・ チケット文化のはじめの一歩は超えた。
「チケット作って」部署問わず普通の動作になった
・ 「チケット便利だよね」「Redmine好きです★」
ファンがめっちゃ増えた。
・ 外部発信したり、他社の相談に乗る機会があった。
・ チケット文化の次を考えるようになった。
実際Redmine導入してみて
次回Redmine.tokyoで