Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

第15回RxTstudy『大規模組織や多様な業務におけるRedmineの課題』

13,005 views

Published on

第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想: プログラマの思索
http://forza.cocolog-nifty.com/blog/2016/07/65-searxtstudy-.html

Published in: Technology
  • Be the first to comment

第15回RxTstudy『大規模組織や多様な業務におけるRedmineの課題』

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

×