第15回RxTstudy『大規模組織や多様な業務におけるRedmineの課題』
•
5 likes•15,352 views
第65回 SEA関西プロセス分科会＆RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想: プログラマの思索 http://forza.cocolog-nifty.com/blog/2016/07/65-searxtstudy-.html
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (16)
More from akipii Oga
More from akipii Oga (20)
Recently uploaded
Recently uploaded (11)
第15回RxTstudy『大規模組織や多様な業務におけるRedmineの課題』
- 2. 自己紹介 • ハンドルネーム： • @akipii、技術士(情報工学) • 出版した著書 • 「Redmineによるタスクマネジメント実践技法」 (with 阪井さん) • 「チケット駆動開発」 (with 阪井さん) • 「Redmine超入門」(with redmine.tokyoスタッフ) • 「Redmine 実践ガイド」 (with (株)アジャイルウェア) Copyright2016 akipii@XPJUG関西 2
- 3. Agenda • 問題提起とその背景 • 解決の方向性 • WF保守のルール • トラッカーのルール • PJ分割ルール • まとめ • 課題 Copyright2016 akipii@XPJUG関西 3
- 5. Redmineの現状 • SW開発の作業だけでなく、多様な業務にチケット 管理を適⽤する事例が多くなってきた • 例：汎⽤的な事務処理のワークフロー管理 • 例：Redmineを帳票ワークフローシステムとして扱う • 大規模な組織へ運⽤を拡大する事例が増えてきた • 例：1つの事業部や会社全体 • 例：ユーザ数は100人以上 • 例：PJ数が100個以上 Copyright2016 akipii@XPJUG関西 5
- 6. Redmineのメリット • 変化に強いタスク管理がやりやすい • BTSの設計思想は、突発的に発⽣した障害を管理すること • アジャイル開発と親和性が高い • 自分たちの組織に合ったプロセスを実現しやすい • プロジェクト型組織の雰囲気で機動的になる • 機能別組織でも、体制上はPJ型チームになる • 一つの有機的なチームが形成されやすい • マトリクス型組織を作りやすい • 実際の業務担当は複数PJに属する • サイロ型組織の悪習を打破しやすい Copyright2016 akipii@XPJUG関西 6
- 7. Redmineの運⽤拡大イメージ Copyright2016 akipii@XPJUG関西 7 導入期 拡大期 安定期 衰退期 ユーザ数 PJ数 ユーザが増大して トラッカーやPJが 増大 ⇒WFも複雑怪奇 問題噴出！
- 8. 運⽤拡大のフェーズ • Redmine運⽤拡大中に、トラップが幾つかある Copyright2016 akipii@XPJUG関⻄ 8 No フェーズ 状況 発⽣する問題 1 導入期 環境構築 初心者はインストールでつまずく 2 1チームの運⽤ プロセスを安定させるために試⾏錯誤する 3 拡大期 他部署へ展開 ①ユーザ、トラッカー、PJが増大 ②他チームに定着させるために試⾏錯誤する 4 機能改善 Redmineの機能改善の要望が増える (ガントチャート改善、メトリクス集計) 5 安定期 保守維持作業 ①カスタマイズしたRedmineはVerUpしにくい ②Redmine設定が複雑になる ③運⽤プロセスが複雑になる
- 9. 問題点 • 他チームにどうやって、チケット管理を定着させるか？ • 自分達のプロセスが、自社の多種多様な案件に対応できるか？ • チケット管理とExcel報告書を使い分ける基準は何か？ • 組織構造や権限をどのように反映させるか？ • 例：既存の組織構造がモロに反映される • 例：運⽤プロセスが複雑怪奇になる • Redmineの機能拡張や保守負担をどのように下げるか？ • 例：ガントチャート改善やメトリクス集計の要望が多い • 例：Redmine本体のVerUpに追随しにくい Copyright2016 akipii@XPJUG関西 9
- 11. 解決の方向性 • 「組織構造や業務とRedmineのFG分析」にフォー カスを当てる • JAXAのRedmineモデルを⽤いて分析してみよう • Redmineのレイヤ構造を綺麗に整理してくれている • Redmineのレイヤ構造から、対策を考えよう • 「運⽤の定着」「機能拡張」「保守コスト増」の問題 は、今回の講演のスコープ外とする • パネルディスカッションで議論しましょう Copyright2016 akipii@XPJUG関西 11
- 12. Redmineのレイヤ構造 Copyright2016 akipii@XPJUG関西 12 JAXA Repository / AIREX: CODA: JSS2の運⽤・ユーザ⽀援を⽀えるチケット管理システム: Redmineの事例と利⽤のヒント https://repository.exst.jaxa.jp/dspace/handle/a-is/557146
- 13. Redmineの各レイヤ • Redmineのレイヤは6層構造になっている • 論理層を使う人＝Redmineシステム管理者 • 物理層を使う人＝Redmine利⽤ユーザ Copyright2016 akipii@XPJUG関西 13 No フェーズ 層名 役割 1 論理層 モジュール定義層 機能(モジュール)の全体設定 2 ロール層 ロールや権限の定義 3 チケット定義層 システム管理者が、ワークフローや トラッカーなどの全般の設定を⾏う 4 物理層 PJ定義層 利⽤者がPJ全般の設定を⾏う 5 ロール割当層 PJメンバにロールを割当る 6 ユーザ層 初期画面でユーザが使う機能
- 14. 運⽤ルールの考え方 • 組織構造や業務の複雑さに対処するために、以下 の考え方を取り入れてみる 1. WF保守の影響箇所を小さくしたい 2. トラッカーを増やさずに流⽤したい 3. PJ分割の基本ルールを策定したい Copyright2016 akipii@XPJUG関西 14
- 16. WF保守の問題点 • Redmineを使う組織が増えるとロールが増大する • ロールとワークフローの似たような組合せが増える • ユーザが多いとPJメンバのロール割当が面倒 Copyright2016 akipii@XPJUG関西 16
- 17. JAXAのWF保守のルール • JAXAのWF保守ルールは、以下と考えられる Copyright2016 akipii@XPJUG関西 17 No ルール名 概要 利⽤シーン 1 WFと権限の分離 ルール WFだけ、権限だけの ロールを作る 承認者ロールと保守担当ロールを 分離 2 ロール単位の WF分割ルール WFをロール単位に AND分割する 作業者ロールと承認者ロールを分 離 3 ロールのORルール PJメンバのロールは複 数のロールを組合せる PLは作業者ロールと承認者ロール の組合せ 4 グループ割当ルール PJメンバはユーザグ ループで割り当てる 設計or開発グループで割当
- 18. ①WFと権限の分離ルール • WFだけ、権限だけのロールを作る • WFだけのロールと権限だけのロールを組合せて、一つの ロールを形成する設計思想 Copyright2016 akipii@XPJUG関西 18 文書係：権限だけ 承認係：WFだけ JAXA Repository / AIREX: CODA: JSS2の運⽤・ユーザ⽀援を⽀えるチケット管理システム: Redmineの事例と利⽤のヒント https://repository.exst.jaxa.jp/dspace/handle/a-is/557146
- 19. ②ロール単位のWF分割ルール • WFをロール単位にAND分割する • 例：承認ステータスは、申請者ロールと承認者ロールを組合せて 形成する Copyright2016 akipii@XPJUG関西 19
- 20. ③ロールのORルール PJメンバのロールは複数のロールを組合せる Copyright2016 akipii@XPJUG関西 20 JAXA Repository / AIREX: CODA: JSS2の運⽤・ユーザ⽀援を⽀えるチケット管理システム: Redmineの事例と利⽤のヒント https://repository.exst.jaxa.jp/dspace/handle/a-is/557146
- 23. トラッカーの問題点と対策 • 現状の問題点 • WFが同じなのに、違う名前のトラッカーが増えやすい • 項目は共通だが、トラッカーごとにCFが微妙に異なる • 例：「タスク」「会議」「連絡」はWFが全て同じ • 例：「障害(結合テスト)」「障害(ベンダー名)」を作ってしまう • 対策 • 1業務＝1トラッカーだけのPJに分割する • (後述)PJ分割ルール①業務単位 • CFのANDルールで、PJごとにトラッカーのCFを割り当てて、 細かく分ける Copyright2016 akipii@XPJUG関西 23
- 24. ⑤CFのANDルール Copyright2016 akipii@XPJUG関西 24 JAXA Repository / AIREX: CODA: JSS2の運⽤・ユーザ⽀援を ⽀えるチケット管理システム: Redmineの事例と利⽤のヒント https://repository.exst.jaxa.jp/dspace/handle/a-is/557146 ①PJごとに業務を割り当てる ⇒1業務＝1トラッカー ②カスタムフィールドの ON/OFFで、 入⼒項目を制御する
- 25. WF保守・トラッカーのルールの効果 JAXAの運⽤ルールで、Redmineの複雑さを制御できる Copyright2016 akipii@XPJUG関西 25 No ルール名 概要 メリット 1 WFと権限の分離 ルール WFだけ、権限だけのロール を作る (+)ワークフローのパターン増大を防 ぎ、WF保守の負担が減る (－)ロールを細かく作ってWFを制御 する為、設定が複雑になりやすい 2 ロール単位のWF 分割ルール WFをロール単位にAND分 割する 3 ロールのORルール PJメンバのロールは複数の ロールを組合せる 4 グループ割当 ルール PJメンバはユーザグループで 割り当てる 5 CFのANDルール PJごとにトラッカーのCFを割 り当てて、細かく分ける (+)1個のトラッカーで複数の業務を カバーできる (－)PJを細かく作ってトラッカーを制 御する為、PJが増大しやすい
- 27. PJ分割の問題点 • PJが野放図に作られてしまう • 例：ルール無しで階層構造が深くなる • 例：全PJの進捗を横串で参照できない • 組織構造とRedmineプロジェクトはどのように対応 付けれるのか？ • 経験上、組織構造がRedmineプロジェクトの階層構造 に反映される気がする Copyright2016 akipii@XPJUG関西 27
- 28. 組織構造の分類 会社の組織構造は、一般に4種類に分類される Copyright2016 akipii@XPJUG関西 28 No 構造 特徴 イメージ図 1 機能別組織 個別の機能単位による集権型 組織 例：営業・設計・製造部門 2 事業部制組織 事業部という採算単位に編成し た分権型組織 例：製品別・事業別 3 PJ型組織 プロジェクト(案件)ごとに編成し た分権型組織 (SIでは最も普通) 4 マトリクス型組織 職能別組織と事業部制組織を 組み合わせた横断的組織 例：派⽣製品別、 顧客向け派⽣システム別
- 29. 組織構造とRedmineプロジェクトの関係 • 経験上、おそらく次のような関係を持つだろう Copyright2016 akipii@XPJUG関西 29 プロジェクト型組織 ⇒ 一般のソフトウェア開発 (Redmine本来の設計思想) マトリクス型組織 ⇒ 派生開発や プロダクトライン開発向き 機能別組織 ⇒ 普通の集権型組織 事業部制組織 ⇒ 採算単位 の分権型組織 高 ← 環 境 の 不 確 実 性 → 低 い 低←多角化の程度→高 多角化 範囲の経済 PJ恒常化 権限委譲 (仮説)Redmineが向いている組織
- 30. PJ分割のルールの方針(@akipii) 利⽤シーンごとにPJ分割のルールを定める Copyright2016 akipii@XPJUG関西 30 No ルール名 概要 利⽤シーン 1 業務単位 1PJ＝1業務＝1トラッカー PJメニュー＝業務プルダウン ⽀援業務、庶務 2 システム単位 1PJ＝1システム＝1リポジトリ 通常の受託開発案件 3 案件単位 1PJ＝1案件＝採算単位 受託開発案件と保守案件 4 派⽣製品単位 1PJ＝1製品(派⽣ごと) ・パッケージ製品を顧客別に展開 ・組込製品をプロダクトライン開発 5 組織単位 1PJ＝1工程＝1組織 一部の工程にベンダー発注が絡む 例)設計工程PJ＝国内チーム 例)製造工程PJ＝オフショアベンダー 例)テスト工程PJ＝国内チーム＆ベ ンダー
- 31. PJ分割ルール①業務単位 • CFのANDルールを使って、1業務＝1トラッカーにする • PJプルダウンメニューをトラッカーグループのように扱う • 右上のPJプルダウンメニューで、業務ごとの子PJを選択すれば 良い Copyright2016 akipii@XPJUG関西 31 業務 業務A レギュラー 業務B レギュラー 業務C レギュラー 同一のトラッカー (但しCFは異なる)
- 32. PJ分割ルール②システム、③案件単位 • Conwayの法則「アーキテクチャは組織に従う」に合わせる • ②システム単位＝リポジトリ単位に合わせる • ③案件単位に分割する Copyright2016 akipii@XPJUG関西 32 開発案件 1次開発 保守 顧客X システムA システムB リポジトリA リポジトリB PJの⽣存期間と リポジトリの期間は 同じ 【メリット】 PJ型組織になるので メンバー間の やり取りが 活発化しやすい開発ブランチ master
- 33. PJ分割ルール④派⽣製品単位 • 製品シリーズの派⽣した製品単位で区別する • 親子PJ機能が有効に使える • チケットのコピー、関連チケットの機能が重要になる • 例：Apache不具合修正を他の派⽣製品でも実施する。 しかし、リリース日は各PJで異なる。 Copyright2016 akipii@XPJUG関西 33 製品X コア基盤 顧客A向け 派生製品B リポジトリA リポジトリB リポジトリC PJの⽣存期間と リポジトリの期間は 同じ 【メリット】 コア基盤と 派⽣製品の寿命は 異なる為、 管理しやすくなる
- 34. PJ分割ルール⑤組織単位 • 組織構造がPJにモロに反映される場合もある • 例：ベンダーに製造工程を一括発注契約 • 例：地理的に離れたオフショアチームに製造工程を発注 Copyright2016 akipii@XPJUG関西 34 開発案件 設計工程 製造工程 結合テスト工程 経験上、 工程と組織が 対応付けられる 場合が多い 【感想】 あまり好きでない
- 35. PJ分割ルールの効果 Copyright2016 akipii@XPJUG関西 35 No ルール名 概要 組織構造 メリット・デメリット 1 業務単位 1PJ＝1業務＝1ト ラッカー 全社向け 1PJ＝1トラッカーなので操作に迷 いにくい 2 システム単 位 1PJ＝1システム＝1 リポジトリ PJ型組織 システムの⽣存期間と合わせやすい ※Redmine本来の設計思想 3 案件単位 1PJ＝1案件＝採 算単位 事業部制組織 PJ型組織 採算の単位で管理しやすい ※Redmine本来の設計思想 4 派⽣製品 単位 1PJ＝1製品(派⽣ ごと) マトリクス型組織 派⽣製品やシステム機能ごとに 分類して管理しやすい 5 組織単位 1PJ＝1工程＝1組 織 機能別組織 (+)PJごとにチケット操作の権限を 分割しやすい (－)PJ運営が複雑になりやすい (Conwayの法則) (－)「工程単位のPJ」アンチパター ンになりやすい • PJ分割ルールは、組織構造と対応付けられる
- 37. まとめ • Redmineは組織を良い方向へ変える • PJ型組織の雰囲気になり、一体感が出る • 自発的な⾏動を⽀援する • 運⽤プロセスが標準化される • Redmineは組織に従う • 例：既存の組織構造がモロに反映される • 例：業務フローがスリムにならない • 例：運⽤プロセスが複雑怪奇になる • Redmineの設定で組織や業務の複雑さを制御する • そのためにRedmine特有の運⽤ルールを設ける • ロールのORルール、CFのANDルール、PJ分割ルール Copyright2016 akipii@XPJUG関西 37
- 38. 課題 • Redmineの保守コストを下げる方法はあるか • 例：保守体制、機能追加、VerUp作業など • Redmine保守を外部委託したくなる • どの業務システム(例：Jira)でも同様の問題 • Redmineガイドラインをコミュニティで作りたい • Redmineの業務テンプレートを集めて公開したい • Redmineの機能に、組織や業務をどのように適合させるか？ • 組織とプロセスは、Redmineにどのように反映させるか？ • メリット①：初心者はベストプラクティスをすぐに使える • メリット②：経験者は以前の設定を流⽤できる Copyright2016 akipii@XPJUG関西 38