« 第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想 | トップページ | ViewCustomizeプラグインでRedmineをマイクロコア化できるか »

2016/08/03

Redmineに向いている組織はPJ型組織やマトリクス型組織ではないかという仮説

第15回RxTStudy勉強会で、「大規模組織や多様な業務におけるRedmineの課題」を講演してきた。
話し足りなかったことをラフなメモ書き。

【参考】
第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想: プログラマの思索

Redmineを運用している規模について - Google グループ

Redmineの運用が大規模化していく上での課題~@Will_meaningさんとのやり取り - Togetterまとめ

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

逆コンウェイ戦略のメモ~望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

Redmineのプロジェクト間チケットコピー機能で縦割り組織のサイロ化を打破する記事のリンク: プログラマの思索

【1】今の自分のテーマとして、「Redmineが組織構造に与える良い影響は何か、そして、どうやってそれを引き出すのか」「組織構造がRedmineを従属させるとしたら、どんな影響が出るのか」がある。

過去8年以上、数多くの現場でRedmineを導入してきた。
その経験を振り返ると、Redmineを導入して、チームが活性化して上手くいった現場もあれば、期待通りの効果が得られず、Redmineが廃れていった現場もある。
その違いは何なのか、を考えると、その現場にある組織構造とそれに由来する組織文化が大きな要因ではないか、と気づいた。

組織文化が重要、と言うのは誰でも分かる。
でも、その組織文化を生み出した組織構造は、会社ごとに非常に異なる。
その部分を経験を元に整理してみたのが、上記の資料。

【2】一般に、会社という組織は、機能別組織・事業部制組織・PJ型組織・マトリクス型組織の4つに分類される。
どの業界のどの会社も、どこかに当てはまる。

【2-1】SIで多いのは、事業部制組織だ。
たとえば、パッケージ製品の事業部、受託開発専門の事業部、発注元の業界別の事業部などのように、採算単位に組織が分かれている。

事業部制組織の特徴は、分権型組織でありながら、かなり集権的な組織であることだ。
事業部長が事実上、中小企業のオーナーに近い独裁権限を持ち、事業部の売上・コストに最終責任を持ち、事業部内の事業ボートフォリオの決定に大きな影響をふるう。

SIの事業部制組織では、マネージャ、プロジェクトリーダー、プログラマ、デザイナー、インフラ担当者など全てのリソースが揃っているので、自分たちで自由にやり繰りできる。
しかし、その中の業務は標準化できず、一人の担当者が複数の仕事を掛け持ちして忙しすぎて、逆に作業効率が悪くなっている場合が多いように思う。

【2-2】一方、メーカーや古い体質の企業で多いのは、機能別組織だ。
たとえば、営業部、生産計画部、製造部、品質保証部などのように、一つの製品を計画・製造・出荷するプロセスを複数の部署が縦割りに分割する。

機能別組織の特徴は、人の専門化、業務の標準化によって、業務の効率化を重視した集権型組織であることだ。
いわゆる「範囲の経済」「規模の経済」を活かした組織構造になる。
すると、縦割り組織なので、その部署内で業務は局所最適化されるが、会社全体としては、横のつながりが非常に悪いので、全体最適になっていない場合が非常に多いと思う。

【2-3】機能別組織では、横のつながりが悪いので、Redmineを導入すると、Redmineプロジェクト上であたかも、複数部署の担当者が一つの有機的チームを形成するような雰囲気が出てくる。
たとえば、チケットのやり取りでペア作業したり、ノウハウをチケットやWikiに集約したり、自分たちで自発的にチケットを起票したり棚卸しするようになってくる。

つまり、Redmineが公式の機能別組織とは別に、PJ型組織という非公式な組織構造を擬似的に実現して、組織を再活性化してくれるメリットがあるのだ。

一方、事業部制組織は、内部である程度自由があり、その雰囲気が好きであれば仕事しやすい。
でも、作業の効率化ができていないので、Redmineを導入してみるのは有効だろう。
特に、Redmineでチケット駆動開発を実践すれば、アジャイル開発の運用がスムーズにいく。

また、パッケージ製品の派生開発や、組み込みソフトウェアのプロダクトライン開発では、Redmineの親子プロジェクト機能を使って、似たような案件だがタスクは別管理したい時にRedmineが有効に使える。
たとえば、コア基盤の親プロジェクトに、派生開発の子プロジェクトや、顧客向けにカスタマイズしたシステムの子プロジェクトを配置することで、リアルタイムにチケット管理しやすくなる。

つまり、Redmineが公式の事業部制組織とは別に、マトリクス型組織という非公式な構造を擬似的に表現して、作業の効率化をRedmineがサポートしてくれるのだ。

【2-4】一般に、昨今のように、ビジネスの不確実性が高まる状況では、従来の機能別組織や事業部制組織といった「規模の経済」の論理で作られた組織構造では、柔軟性がないことが既に指摘されている。
すなわち、たくさんの人員を、ヒエラルキーに基づいた中央集権的な組織で管理することは向いていないのだ。
むしろ、PJ型組織やマトリクス型組織、タスクフォース、スクラムチームといった柔軟でフラットな組織形態が望ましい、とよく言われる。

その傾向によって、Redmineの利用場面が多くなってきたのではないか、と思う。

【3】そんな経験を整理すると、RedmineはPJ型組織やマトリクス型組織に有効ではないか、という仮説が思いつく。

【3-1】PJ型組織やマトリクス型組織の特徴は不確実性が非常に高い状況で有用な組織であることだから、不安定で不確実性が高い状況では、Redmineが有効ではないか、という仮説に至る。

その理由は、本来、Redmineは障害管理ツールから発展したツールなので、突発的に発生した障害やタスクを簡単に登録し、更新し、作業状況をリアルタイムに管理できる特徴を持つからだろう。

【3-2】また、Redmine本来の設計思想では、1プロジェクト=1リポジトリの前提がある。
ver1.xの頃は、マルチリポジトリ機能がなかったので、Redmineプロジェクトに対し、SVNやGitリポジトリを1個しか設定できなかった。
逆に言えば、Conwayの法則に従うように、1個のシステムは1個の案件だけに対応付けるべき、アーキテクチャ(システム)は組織・管理上の単位に従わせるべき、という発想だったのだろう。

この特徴は、RedmineプロジェクトがPJ型組織と本来調和していることにつながっているのだろう。

【3-3】さらに、Redmineの生誕当時から複数プロジェクト機能を持っていた特徴により、マトリクス型組織にも向いている特徴が自然に出てきたのだろう。
たとえば、派生開発やプロダクトライン開発のように、ある製品の作業が、そこから派生した製品の作業に影響するが、開発要員のスケジュールの違いやリリース日の違いによって、別々に管理したい場合がある。

そんな時に、Redmineプロジェクトを親子関係で分ければ、子プロジェクトごとに作業を別々に管理し、親プロジェクトで子プロジェクトのチケットも含めた全てのチケットを集計することで、一括で進捗管理できるようになる。

その場合、チケットのコピー機能やチケットの関連機能が重要になってくるだろう。
理由は、派生先のチケットに対し、派生元のチケットからコピーしたり、派生元チケットに関連付けることで、派生先チケットがどこから発生したのか、が分かりやすくなるからだ。
つまり、一つのインシデントに対し、関連するシステムの影響範囲をチケットで表現した場合、チケットのコピーや関連チケット機能で実現できることを意味している。

たとえば、Apacheの不具合パッチをリリースするインシデントが発生した場合、影響する他システムにも同様のチケットをコピーないし関連付けるが、システムごとにリリース日が異なるから、別々に管理することができるようになる。

この運用が徹底できれば、作業後の品質管理で、インシデントのインパクト分析に役立てることもできるだろう。

【3-4】他にもRedmineの特徴として、ペア作業、構成管理ツールと連動したトレーサビリティ、小規模リリースを実現するタイムボックス開発、等がある。
これらのプラクティスも取り入れれば、より一層の効果が出るはず。

【3-5】しかし、組織がRedmineに悪影響を与える時もある。
複雑な組織構造がRedmineの設定にモロに反映されると、運用プロセスが複雑になりがち。

よくある例は、ステータスやロールが多くなり、その結果、ワークフローが複雑になり、トラッカーが増えてしまうことだ。
組織をまたぐ時に、誰がボールを持っているか、を明確にするためにステータスが必要になるので、縦割り組織が多いほど、ステータスは多くなる。

また、組織のロールをそのままRedmineに反映すると、ロールの数もロールの設定箇所も増える。
特に、社内だけでなく、外部のベンダーが絡むと、チケットや成果物のアクセス権限を制御する必要があるため、ロールを増やして、アクセス権限を制限する必要が出てくるからだ。

【4】そんなことを考えると、Redmineに向いた組織構造や組織文化は、「PJ型組織」「マトリクス型組織」のような不確実性の高い状況の組織に向く、と言えるのではないか。
逆に言えば、不確実性の高い状況で作業せざるを得ない組織では、Redmineを積極的に導入してみてはどうか、と推薦することもできるかもしれない。

組み込みソフトウェア開発のように、本来はメーカーの開発スタイルであるWF型開発が中心である組織であっても、派生開発やプロダクトライン開発に取り組まざるをえない状況では、Redmineが適している部分があり、Redmineの特徴を上手く引き出せれば、有機的なチームの雰囲気や文化を作り出すことができるはず。

その辺りの事例も集めてみたいし、ノウハウも整理してみたい。

逆に、複雑な組織構造はRedmineの設定を複雑にする。
Redmineが複雑な設定になってしまうパターンも整理してみたい。

|

« 第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想 | トップページ | ViewCustomizeプラグインでRedmineをマイクロコア化できるか »

Redmine」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« 第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想 | トップページ | ViewCustomizeプラグインでRedmineをマイクロコア化できるか »