Redmineが今後発展する方向のアイデアpart2

2017年末の時点で、Redmineが今後発展する方向について、考えたことをメモ。
2014年時点に書いた時から、幾分状況も変わっている。
以下はラフなメモ書き。

【参考】
Redmineが今後発展する方向のアイデア: プログラマの思索

日本の大企業におけるRedmineの利用事例の資料のリンク: プログラマの思索

以前、僕が考えていた時は、アジャイル開発への適用、プラクティスやアンチパターンなどのパターン言語への適用が主だった。

僕が今、Redmineによるチケット駆動開発で考えているテーマは下記になる。
幾分重複している。

【1】SW工学への適用
【2】PJ管理ツールとしての開発基盤
【3】Redmineと組織の関係
【4】チケット駆動がもたらす効果
【5】フローとストック、変更管理と構成管理の関係

【1】SW工学への適用

もう一度、Redmineに各種のプロセスや手法を適用した時に、フィットギャップ分析や導入・運用時の注意点などをまとめたい。

【1-1】PMBOKの実装
　→EVMはその一つ。

【1-2】CMMIレベル4を実現するためのRedmine運用方法

たとえば、パナソニック子会社の事例では、CMMIレベル4を目指すために、Redmineを導入・運用することで解決しようとしている。
開発現場を救うプロセス改善の進め方 - SPIJapan2014

CMMIレベル4を実現するには、Redmineのどの機能を使って、CMMIの各プロセス領域を実装すべきか？
フィットギャップ分析して、Redmineの標準機能が不足していると判明したら、その問題をどのように解決するか？
プラグインを作ってRedmineに組み込むか？
ExcelマクロやBIツールなど、外部システムで解決するか？

【1-3】GTD
　→かんばんを使えば実装可能と思っている。
　　課題は、より使いやすくするには、かんばんのUIをどのように実現すればよいか？

【1-4】ITIL
　→問合せ管理、サポートデスクの運用もこの範疇に入る。
　　ITIL特有の課題は、複数の相異なるワークフローをどのように組合せて、一つのプロセスを実装すべきか？

【1-5】メトリクス収集/集計のためのプロセス基盤
　→各種ソフトウェアメトリクス、進捗・品質・コストのメトリクスを出力する。
　　KPIもその一つ。
　　たとえば、最大放置日数、平均完了日数（＝平均リードタイム）、平均サイクルタイムなど。
　　基本はチケット集計のビューを増やせばいい。
　　それらメトリクスを使うと、どんな結果や効果を示せるのか？

【1-6】BPMや汎用帳票ワークフロー基盤の適用

【1-7】派生開発、ソフトウェアプロダクトラインへの適用

【1-8】ISO9001、ISMSへの適用

【2】PJ管理ツールとしての開発基盤

Redmineの柔軟な外部I/Fを洗い出してみると、汎用的な開発基盤とみなすことができることは以前書いた。

第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine～Redmineをカスタマイズするポイント」

【2-1】では、「RedmineはPJ管理の実験ツールである」と考えた時、標準のRedmineでは何が足りないのか？
今までのRedmine勉強会、redmine.tokyoの Unofficial Redmine Cooking を見た限り、いくつかある。

概要 - Unofficial Redmine Cooking - redmine.tokyo

カスタムフィールド内部の項目値設定は、システム管理者以外の権限でも有効化したい。

Redmineのワークフロー設定を拡張する機能提案～Redmineは汎用的なBPMツールになりうるか: プログラマの思索

ロードマップ画面で、チケットをD&Dで並び順に変更する。
この機能は、アジャイル開発でプロダクトバックログを整理する時に使う。

カレンダー画面はもっと改良して欲しい。
ユーザ別に週別カレンダー表示など、チーム内でどのメンバーがどのチケットを担当を予定しているのか、一目で分かるようなビューが欲しい。

文書、マイページなども、もっと画面改良できるはず。

他に、開発基盤であるからには、チケット画面のUIは今風にしたい。
スマホなどに慣れていると、RedmineのUIは古くなっている部分がある。

ViewCustomizeプラグインで、どの程度、RedmineのUIを改善できるか？

【2-2】他に、外部ツールとのツール連携はどのように構成すべきか？という課題がある。
たとえば、構成管理ツールGitlab、ビルド管理ツールJenkinsをRedmineと連動するのは普通だろう。

それ以外に、連携した方が良い外部ツールはあるか？

SW構成管理を実現するプロジェクト管理サーバー

【3】Redmineと組織の関係

経験上、「日本では、Redmineは組織に従う」。
日本企業は、自分達の標準プロセスに合うように、Redmineをカスタマイズしたがる。

実際、日本の大手SIが持つ自社の標準プロセスは、工程の名前が微妙に違うけれど、WF型開発の構造と何ら変わらないのに、自社の標準プロセスに非常にこだわりがある。
日本のメーカーも同じ。

【3-1】大規模組織にRedmineを導入した場合、小規模チームで編み出されたチケット駆動の運用ルールがそのまま適用できない場合がある。
複数の部署があり、部署ごとに異なる組織文化があれば、単純な一つのルールで実現するのは難しい場合もあるだろう。

大規模組織で多種多様なプロセスをRedmineで実現して運用する場合、どんな点に考慮すべきなのか？

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

【3-2】また、Redmineインスタンスと組織、プロセスの関係という問題が出てくる。
大規模組織では、唯一のRedmineインスタンスで標準プロセスを強制して、運用すべきなのか？
あるいは、あえて複数個のRedmineインスタンスを許し、各チームのプロセスに合ったRedmineへカスタマイズすることを許容すべきか？

Redmineインスタンスとプロセスの関係～Redmineは組織に従うのか、Redmineに合ったチームを作るべきか: プログラマの思索

たとえば、気象庁ではあえて複数個のRedmineインスタンスで運用されている。
なぜ、このような運用を採用したのか、その理由や背景、意図が知りたい。

気象庁の数値予報課におけるRedmine利用事例: プログラマの思索

数値予報モデル開発のための 基盤整備および開発管理 - 気象庁

(引用開始)
開発管理サーバの特徴として、一つのサーバ上に複数の Redmine を運用している点が挙げられる。
指針が定める開発管理サーバの利用範囲は、気象庁本庁と気象研究所を含めた複数の課室を想定していることもあり、管理する開発対象が非常に多岐にわたっている。
こうした背景からサーバ上で複数の Redmine を運用し、各 Redmine の管理方法の細目は利用するコミュニティに委ねる方式を採用している。
(引用終了)

【追記】
第18回Redmine大阪にて、気象庁が「あえて」複数のRedmineインスタンスを立ち上げた意図には、庁内で共通の開発基盤を導入する必要性は認識しているが、各開発コミュニティの組織文化を尊重することを優先した、という事があったらしい。

第18回Redmine大阪の感想　#RedmineOsaka: プログラマの思索

【4】チケット駆動がもたらす効果

一方、「Redmineが組織文化に変化をもたらす」場合もある。
そもそも、Redmineを新規導入したいという意図を持つ組織では、Redmineがもたらす効果を得たいために目指しているはずだから。

それは、単なる作業の見える化だけではない。
予定していなかったチケット駆動の副次的効果ももたらす。

たとえば、機能別組織で縦割りの雰囲気があっても、Redmine上ではあたかもPJ型組織の構造となり、メンバー間のコミュニケーションが活性化する。
あるいは、障害修正のように、テスターと開発者があたかもペア作業のようにキャッチボールしながら、障害を直していく。
たとえ、オフショアという地理的に離れたメンバーであっても、コミュニケーションの活性化がメンバー間の信頼関係を促進する、という場面を僕は何度も見てきた。

たとえば、Redmineの標準機能で不足している、と感じたならば、システム管理者が言わなくても、メンバーが自発的にExcelマクロやプラグインなどを作り出す。
つまり、ツールがプロセス改善の雰囲気を醸し出し、プロセス改善の方向へメンバーを動機づける、と言う場面を僕も何度も見てきた。

つまり、「Redmineが組織文化に好影響をもたらす」事例を抽出し、それら効果を整理したい。
そして、その効果を得るためには、Redmineの運用で何に気を付けるべきなのか、を明確にしたい。

【5】フローとストック、変更管理と構成管理の関係

【5-1】チケット管理ツール特有の観点として、フローとストックを別々に管理できて、フローとストックの間でトレーサビリティを実現できる点がある。

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索

その時、Redmineのどの機能をフローとみなすか、ストックとみなすか、で違いが出てくる。
チケットはフローでもあるし、ストックともみなせる。
たとえば、チケットをXPのタスクカードとみなせば、フローであるし、障害管理票や課題管理票や議事録とみなせばストックになる。

【5-2】では、Redmineでは、フローやストックはどの機能に相当するのか？

フローとストックのアイデアを突き詰めると、変更管理と構成管理の概念に行き着く。
フローは変更管理、ストックは構成管理の対象になるからだ。

昨今ではGit＋チケット管理によるモダンな開発が主流だが、その開発プロセスでは変更管理と構成管理が自然に実装されているので、あまり気にする必要がない。

【5-3】しかし、ISO9001などの運用で、構成管理されるべき成果物がExcel設計書である場合、問題がたくさん出て紛糾していると経験上思う。

理由は、変更管理されるべきExcel変更依頼書やExcel作業指示書と、構成管理されるべきExcel設計書が同じようなステータス管理の対象となって混乱しているからだ。
特にメーカーの運用はそうだろう。

チケット管理システムは作業の構成管理と同じ: プログラマの思索

混乱している理由は、Excelドキュメント自体がGitなどの構成管理ツールで管理できていないので、昔ながらのフォルダ管理で運用されているから。
また、作業指示書であるExcel変更依頼書がチケット化されていないために、それもステータス名の付いたフォルダに手作業で移し替える事で、ステータス管理されているから。

【5-4】では、Excel設計書などの成果物は、どのように構成管理すべきか？

本来は、ライフサイクルの長いExcel成果物はGitなどで構成管理すべき。
しかし、Excel文書は構成管理ツールの差分が見れない、などの問題がいくつかある。

JAXAでは、構成管理ツールではなく、Redmineの文書機能拡張のDMSFプラグインで運用していた。

第13回東京Redmine勉強会の感想～『Redmineの今と未来』 #redmineT: プログラマの思索

“CODA” チケット管理システム | JSS2@JAXA

一方、@akahane92さんの現場では、Excel設計書は全てSubversonで構成管理されている。

｢効率･品質･統制｣の共通課題に着目した現場主導による ITS 導入事例～OSS 運営ツールで効率的・低コストな導入を実現～　(IPA　「先進的な設計・検証技術の適用事例報告書 2016 年度版 」)

｢効率･品質･統制｣の共通課題に着目した現場主導による ITS 導入の効果検証～SQIP2014

どちらのやり方が良いのか、というのではなく、Excel文書の構成管理の実装方法をもっと整理したい。

【5-5】僕は、変更管理と構成管理を区別する、という考え方は重要と思う。
なぜなら、チケット駆動で運用しようとしてもチケットが起票されない、という問題の原因の一つに、チケットを仕様書のように細かく書こうとして入力コストが大きくなるから、という事象もあるのではないか、と思っている。

チケットをフローとして流すのを優先するか、ストックとして残すのを優先するのか。
その背後には、変更管理と構成管理の混乱があるのでは、と思ったりする。

【6】上記のように、Redmineで今後試すべき課題とその方向性を思いつくままリストアップしてみた。
「Redmineは先進的なプロセス基盤の実験場」とみなすならば、もっと色んなアイデアが出てくるし、色んな課題が出てくるだろう。

また、上記のアイデアはRedmineに限定されず、他のチケット管理ツールでも同様に実験することができるだろう。
そして、他のチケット管理ツールで実装できている機能は、Redmineに移植することができるはずだし、逆も然りだ。

さらに、「RedmineはPJ管理の汎用的な開発基盤」とみなすこともできるので、ソフトウェア工学やプロセスに興味を持つ人達だけでなく、Ruby開発者も上記の課題解決に加わることができるだろう。
背景の違う人達が数多く議論することで、より有用な結果が得られるだろう。

【追記】
門屋　浩文さんのツイート: "@akipii いろいろ意見だしあいましょう ４の副次的効果は同感です"

akipiiさんのツイート: "@MadoWindahead @MadoWindahead さんのつぶやきを読みながら、チケット駆動の副次的効果を整理した方がいい気がしました。導入する人は、予定していない副次的効果も期待しているから。それを説明できれば、より納得してくれるでしょう。"

門屋　浩文さんのツイート: "@akipii その辺りを具体的にまとめたいなあ ツール利用の副次効果で「信頼関係ができる」だけでは薄そうなので 今年も言って回ってますけど 感じてない人には響いてなさそう"

SW構成管理を実現するプロジェクト管理サーバー from akipii Oga