« 残業申請ワークフローやITIL運用プロセスをRedmineで実現した事例の記事 | トップページ | 【事前公開】【第16回Redmine大阪】RedmineのFAQとアンチパターン~親子チケットの功罪 »

2017/03/14

Redmineのワークフロー設定を拡張する機能提案~Redmineは汎用的なBPMツールになりうるか

Redmine本家のチケットを見ていたら、Redmineのワークフロー設定を拡張する機能提案のパッチが起票されていて、Planioの Jan とやり取りしていた内容が興味深かった。
ラフなメモ書き。

【参考】
Patch #20384: Proposal: Workflow enhancement - Redmine

【1】Frederico Camaraさんの発言

(Google翻訳による引用開始)
私はブラジルの大規模なICT公開会社に勤務しています。
ここではRedmineを使用しています。

最初は、Redmineのワークフローツールが何らかの制限を加えることは明らかになりませんでした。
しかし、より複雑なワークフローを構築し、さまざまなプロジェクトやチームのロールとトラッカー名を再利用するようになると、特定のロールやトラッカーに固有のワークフローによって、ロールやトラッカーと同様の名前と同義語が使用されるようになりました。
当社のさまざまな分野の新しいワークフローを開発することができます。
これには、名前の大文字と小文字の使用、数字の追加、両方の性別の単語の使用(ポルトガル語の実体は性転換を持つ)などがあります。
同様のエントリがRedmineのさまざまなメニューに表示されるため、最終的には迷惑になりました。

また、クローズステータスは発行ステータスに固有であり、ワークフローでは重複してエントリを複製するため、一部のステータスでは問題が終了しますが、別のワークフローでは同じステータスにはなりません。
ワークフローは依然として役割とトラッカーに固有のものであるべきだと思いますが、プロジェクトには異なるワークフローセットが用意されているため、同じワークフローを使用して異なるプロジェクトを作成し、同時に異なるワークフローを使用する異なるプロジェクトを作成できます。

また、クローズされたステータスは、使用されているワークフローに固有のものでなければなりません。

最初の提案では、管理画面にワークスペース、ワークフローセット、ワークフロースペースなどの項目が表示されます。
そこから、ワークフローはワークスペースの一部になり、各プロジェクトでは使用するワークスペースを選択します。
移行の目的で、既存および新規のワークフローおよびプロジェクトはすべて、デフォルトのワークスペースに割り当てられます。
新しいサブプロジェクトは、作成時に親と同じワークスペースを選択する必要があります。
プロジェクト間にワークスペースの継承はありません。

主な利点は以下のとおりです。

・作成される発行ステータスの数が少なくなります。
・ワークフロー間の簡単な移行
・複雑なインフラストラクチャに対するより多くの制御。
・より単純なインフラストラクチャへの影響は非常に小さい。
(引用終了)

(Google翻訳による引用開始)
私は、コミットをチェリーピックし、Redmine3.3安定に対して必要な調整を行った。
ここにパッチがあります。

「管理」メニューに「ワークスペース」が追加され、既存のすべてのワークフローが「デフォルト」のワークスペースに移行されます。
プロジェクトごとに、使用するワークスペースを選択できます。
ワークスペースは、ワークフロー(遷移とアクセス許可)を互いに分離して、異なるプロジェクトが異なるワークフローを持つことができるようにします。
また、管理を手助けしようとします。
このパッチはLinux上で作成されました。
Windowsでは改行文字を修正する必要があります。

変更点:管理では、「ワークスペース」にワークスペースを追加できます。
管理>ワークフローには、新しいフィルタ「ワークスペース」があります。
ワークスペースを変更すると、異なるワークフローセットが切り替わります。
これは、フィールド許可タブの場合にも機能します。

[管理]> [ワークフロー]> [概要]には、異なるワークスペースからのビューを切り替えるためのドロップダウンメニューがあります。
管理>プロジェクトは、各プロジェクトが使用しているワークスペースを示します。
各プロジェクト>設定で、プロジェクトが使用しているワークスペースを変更することができます。

「すべて」をクリックすると、ロールがフィルタリングされたトラッカーを表示/非表示できます。
ロールは、ワークスペース上でワークフローを持つロールと、割り当てられていないロールによってフィルタリングされます。
(管理>ロール)フィルタリングされたロールの表示/非表示を「すべて」をクリックするデフォルトのワークスペースを削除することはできません(また、移行する場合は、これまでのワークフローをすべて削除します)。
(引用終了)

【2】Jan from Planio www.plan.io さんの発言:

(Google翻訳による引用開始)
これは面白い(広範囲で複雑なパッチだが)、それを提案してくれてありがとう。
この大きさのパッチが考慮されるためには、完全なテストカバレッジが必要であり、既存のテストを破ってはいけません。
可能であれば、一連のパッチに分解して、各パッチがすべてのテストをパスしたRedmineの実用バージョンになりますが、作業を別々のチャンクに分割することをお勧めします。

Planioの非常に大規模な組織のRedmineとの共同作業の主な要件は、プロジェクトチームが管理者を必要とせずに他のプロジェクトに干渉することなく独自のトラッカー、ステータス、ワークフローを作成することでした。
あなたのパッチは後者の課題を解決するようだが、前者の問題は解決していないようだ。
あなたのソリューションでは、異なるワークフローを必要とするプロジェクトチームは、依然としてRedmine管理者にそれらを作成するよう依頼する必要があります。

特に大規模な組織では、管理者が多くの帽子をかぶり、さまざまなシステムを管理するため、これは大きな課題となります。
彼らは、Redmineの管理領域の設定インタフェースや、特定のワークフロー変更を要求するプロジェクトマネージャのビジネスニーズにどのように対応しているのかを100%理解しているわけではありません。
これは、プロジェクトマネージャが電子メールまたは電話で異なるワークフローのセットを要求しているときに誤解を招く可能性があります。
管理者と一緒にプロジェクトを作成することはしばしば実現するのが難しく、プロジェクトで必要なワークフローを実装するには数週間かかることがあります。

私は、特定の役割がプロジェクトのトラッカー、ステータス、ワークフローを個別に管理できるソリューションが、多くの大企業で見られた課題に適したソリューションであると考えています。
(引用終了)

【3】Redmineを大規模な組織に適用して運用していくと、ユーザグループやカスタムフィールド、ワークフローなどの「設定だけ」をシステム管理者ではなく、一部のPJ管理者に権限委譲したくなってくる。
そのPJだけに必要なマスタ保守は、そのPJ管理者だけが更新する方が早いし、逐一、システム管理者に連絡する必要もないはず。

Janの意見の通り、非常に大規模な組織において、プロジェクトチームがシステム管理者を必要とせず、他のプロジェクトに干渉することなく、独自のトラッカー、ステータス、ワークフローを更新できるようにしたい。

システム管理者はRedmineの全機能にアクセスできるが、PJ管理者にはそこまでの権限を緩めたくはない。
PJ管理者は、Redmineの全機能、Redmineに付与されたマスタ設定の意味まで100%知っているわけではないからだ。

つまり、PJ間同士でマスタ不整合が起きない限り、PJに関するマスタ保守は、PJ管理者に権限委譲して、システム管理者の作業負荷を下げたい。
すなわち、システム管理者無しで、Redmineのあらゆる機能の権限制御をもっと細かく設定したい。

上記のチケットの意図は、おそらくそんな所にあるのだろうと思う。

まだ、上記のチケットに添付されたパッチを適用していないので分からないが、上記のパッチは、以下のような機能を持つらしい。

・「管理」メニューに「ワークスペース」が追加され、プロジェクトごとに、使用するワークスペースを選択できる
・ワークスペースは、ワークフロー(遷移とアクセス許可)を互いに分離して、異なるプロジェクトが異なるワークフローを持つことができる
・ワークスペースにあるワークフローには、ロールやカスタムフィールドなどがあり、PJごとに、ロール単位で制御できる

しかし、Janの意見では、上記のパッチでは、「プロジェクトチームが他のプロジェクトに干渉することなく独自のトラッカー、ステータス、ワークフローを更新できる」機能を提供するが、システム管理者なしでPJ管理者だけでコントロールするには不十分らしい。

【4】では、このパッチが提供する機能の本来の課題は何なのか?
それは、Redmineを汎用的なBPMツールへ機能拡張する方向性を示したい、ということだろうと思う。
そのアイデアについては、以前書いた。

RedmineをBPMツールとして使うアイデア: プログラマの思索

Redmineは事務処理の申請承認ワークフローに使えるか?: プログラマの思索

Redmineにワークフローエンジンとして必要な機能~ワークフローに組織マスタの情報を持たせる: プログラマの思索

上記のパッチが提供するイメージとしては、最終的には、Redmineのマスタ保守をPJごとに保存でき、PJ単位で保守できるようにすることだ。
つまり、PJ単位でワークフロー設定情報をXML出力してバックアップでき、そのXMLをインポートすれば即座にRedmineのPJごとにマスタを復元できるイメージ。

管理画面から、PJごとにワークフロー情報を画面から更新できるならば、その情報を出力したり、一括インポートできる機能があって然るべきだろう。
実際のRedmineではそんな機能はないが、そこまで実現できれば、RedmineはOSSのBPMツールとして、十分に通用するだろう。

そもそも、RedmineにBPMツールのような機能が必要なのか、と言われると、正直分からない。
でも、Redmineの管理画面の権限制御の課題は、東京RedmineでもRedmine大阪でも、一部のユーザからは似たような問題意識が提起されていた。
つまり、彼らも、Redmineを運用している組織が大規模になってくると、管理画面の権限制御をシステム管理者なしで、PJ管理者がPJ単位で制御できるようにしたくなってくるわけだ。

QA #263: カスタムフィールドの選択項目定義(KVS)を、admin以外にも可能としたい。 - Unofficial Redmine Cooking - redmine.tokyo

QA #265: カスタムフィールド(list)の選択肢定義をadmin以外編集可能にしたい(KeyValueList以外で) - Unofficial Redmine Cooking - redmine.tokyo

QA #266: ユーザグループの定義内容変更をadmin以外も可能にしたい - Unofficial Redmine Cooking - redmine.tokyo

上記チケットのやり取りを見ていると、今後のRedmineの発展の方向性は、そこにあるのかもしれない。

|

« 残業申請ワークフローやITIL運用プロセスをRedmineで実現した事例の記事 | トップページ | 【事前公開】【第16回Redmine大阪】RedmineのFAQとアンチパターン~親子チケットの功罪 »

Redmine」カテゴリの記事

コメント

コメントを書く



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


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



« 残業申請ワークフローやITIL運用プロセスをRedmineで実現した事例の記事 | トップページ | 【事前公開】【第16回Redmine大阪】RedmineのFAQとアンチパターン~親子チケットの功罪 »