マルチプロジェクトのWF型開発にはRedmineのどんな機能が必要なのか

Redmineの全てのページに全プロジェクトへのリンクを設置したい要望を見つけたのでメモ。
その要望の背後には、「マルチプロジェクトのWF型開発にはRedmineのどんな機能が必要なのか」という問題があると思う。

【参考】
Redmine - 【Redmine】全てのページに、全プロジェクトへのリンクを設置したい【カスタマイズ】(19566)｜teratail

Redmineでヘッダメニューに項目を追加する(View customize plugin) - Enjoy*Study

【1】(引用開始)
■■知りたいこと■■
Redmineの全てのページのヘッダに、全てのサブプロジェクトへワンクリックで飛べるリンクを設置したいです。
このような事が出来るプラグイン、もしくは、redmineのどこのコードを弄ればよいのか、ご教授ください。

■■背景■■
数名で複数プラットフォーム（Web/iOS/Android/Farmware/Server）に跨った開発をしており、
Subversion/Gitとredmineを組み合わせた変更履歴・バージョン管理のセットアップを命じられました。
私自身、新卒で駆け出しのエンジニアであり、redmineの設置は初めてでruby / ruby on railsに触った経験はありません 。

■■問題点と解決したい方向性■■
しかし、実際にはサブプロジェクトは、Farmwareはハードウェアのバージョンアップ毎に3つほど、Serverは機能別に複数あり、
現状10個程のサブプロジェクトが想定され、今後も増えていくと思います。
プロジェクトの移動が煩雑になり、チーム内でredmineの運用に消極的なメンバーが発生する事が懸念されます。そのため、今どのプロジェクト・どのページを閲覧していても、別のプロジェクトへワンクリックで移動できるリンクがあればよいのではないかと考えています。
(引用終了)

上記の質問を読むと、新人SEと言いながらも、質問の内容がとても分かりやすく書かれていて、新人とは思えない。
上記の質問の背景としては、Web/iOS/Android/Farmware/Serverというアーキテクチャごとに複数チームが分かれていて、Redmineでタスク管理とバージョン管理を行いたいらしい。
その時、各プロジェクトから関連するプロジェクトにワンクリックで移動する方法が知りたいらしい。

回答は、ViewCustomizePluginで解決できるでしょう、とのこと。
僕も、この方法が最も簡単で、今後のカスタマイズもやりやすくなるので、お勧めと思う。

(引用開始)
こちらのページで紹介されているプラグインはいかがでしょうか？

Redmineでヘッダメニューに項目を追加する(View customize plugin) - Enjoy*Study

文化を変えていく、というのは難しいですよね。同じようにredmineの教育、運用に苦労しています。

プロジェクトの移動が手間、というのが根本問題になりそうであれば、サブプロジェクトを使わず、対象バージョンやカテゴリなどで種別わけするのも一つの方法かもしれません。共通のカスタムクエリを準備しておけば、移動もワンクリックです。
がんばってください。
(引用終了)

【2】改めて、上記の質問を読んで感じることは、アーキテクチャ別の複数チームがRedmine上でプロジェクト管理したい場合、Redmineにはどんな機能が不足していて、どんな機能を追加すべきなのか、という疑問だ。

たとえば、業務システム開発案件では、画面・帳票・バッチ・インフラのような機能別チーム構成になる。
あるいは、Webサービス開発でも、アプリ・スマホ・デザイナー・インフラのような機能別チームになりやすい。

すると、複数チームを横断した課題管理や障害管理がやりたくなるし、隣のチームに課題の解決を依頼したり、バグ対応の依頼を受けたりすることも多くなる。
つまり、チーム横断の課題・障害について、優先順位を決めたり、リソース配分を行うと言った、意思決定プロセスが必要になってくる。
その意思決定プロセスを支援する機能がRedmineにあるか？

複数プロジェクト機能、チケットの階層化機能を使えば、原理的にはRedmineで対応可能だ。
しかし、Redmineにもっとビューがあればいいな、と思う時もある。

その問題の真因を探ってみると「マルチプロジェクトのWF型開発にはどんな機能が必要なのか」という問題に落ち着くのではないか、と思う。
日本でRedmineをいきなり使いたい、という要望が多い理由は、たぶんこれがあるのではないか。

Redmineが日本人好みのツールであるという仮説 part2～日本の硬い組織構造をRedmineが柔らかくしてくれる: プログラマの思索

Redmineが日本人好みのツールであるという仮説: プログラマの思索

原理的には、Redmineのプロジェクトとチケットで、プロジェクトに存在するすべての情報は一元管理できる。
残った問題は、蓄積されたデータをどのように表示して、プロジェクトリーダーの意思決定に使えるビューにするか、だと思う。

【3】個人的には、ガントチャートとかんばんの2つの機能を組み合わせれば、ある程度解決できるのではないか、と思う。

【3-1】まず、各タスクの予定・実績は、プロジェクト横断またはプロジェクト個別でガントチャートで見たい。
プロジェクトリーダーとしては、WBSの枚数と個別のWBSの進捗の2つの観点を常にトレースしたいからだ。

一方、各タスクの現時点の状況は、かんばんで一瞥したい。
プロジェクトリーダーとしては、課題や障害をステータス別に見ることで、今どこで作業が滞留しているのか、ボトルネックを把握したいからだ。

たとえば、どこかのステータスでチケットが大量に滞留していれば、そのステータスがボトルネックなので、即対応したい。
一般にレビューで滞留する場合が多い。

【3-2】ガントチャートとかんばんの2つの機能は、WF型開発の観点とアジャイル開発の観点の2つのビューに相当する。
マルチプロジェクトでは、この2つの相反するプロセスのビューが必要であると直感している。
その理由を考えてみた。

【3-3】上記の質問にあるように、日本のソフトウェア開発は、アーキテクチャ別の機能別チームが作られやすい。
すると、機能別チーム単体では、リリースできるソフトウェアを作れないので、チーム間のやり取りがソフトウェアのI/Fを形成し、そこが複雑化し、バグの温床になる。
まさに「アーキテクチャは組織に従う」という事例そのもの。

その内容をそのままRedmineに反映すれば、組織構造がRedmineプロジェクトに反映される。
一般にプロジェクト計画時は、見積時のWBSがそのままチケット化される。
メンバーは、そのチケットに従って作業していく。
だから、ガントチャートでチケットの進捗状況を随時追跡していきたい。

【3-4】しかし、Redmineのサブプロジェクトが機能別チームであったとしても、親プロジェクトは、リリースできるソフトウェアないし開発案件になるので、別の観点では一つの有機体のPJ型チームを形成する。

今まで、メールや電話、打合せで、チーム間のやり取りが非公式に行われていただろう。
Redmineが導入されると、そのやり取りが全てチケット化されて、公式なやり取りとして全メンバーに公開されて、ペアプログラミングしているような雰囲気になる。
おそらく、プロジェクト後半には、障害や課題のように、メンバー一人が解決できるような作業は少なくなるはずだ。

すると、複数メンバーで問題解決していくタイプのチケットは、かんばんのようなステータス別チケット集計画面で、状況を把握したくなる。
普通は、レビュー担当やテスト担当、承認担当のように、ステータスごとにメンバーが固定されている場合が多いから。
どこでボトルネックになっているか、チケットが毎日スムーズに流れているか、フローとして見たい時に、かんばんはとても有効だ。

【3-5】換言すれば、ガントチャートは「全体の進捗」のスナップショット、かんばんは「チケットのやり取り」のスナップショットではないか。

【4】Redmineでは、ガントバーの赤・緑色の表示で進捗遅延の度合いが分かるし、イナズマ線を引けば、プロジェクトの進捗状況が一目で分かる。
但し、Redmineのデフォルト機能では、ガントバーの予定・実績の区別がないし、ガントチャート画面に担当者が表示されないので、頻繁に改善要望が出る。

一方、Redmineではチケット一覧で、ステータスにグルーピングすれば、かんばんと同等に使える。
但し、Redmineのデフォルト機能には、ビジュアルなかんばんLikeな機能はないので、プラグインを導入すればいい。

一番有名なプラグインは、海外製のRedmineAgilePluginだろう。
機能限定の無償版でも十分に使えるみたい。

Agile - Plugins - Redmine

最近、LyhceeAgileプラグインがリリースされたらしい。
日本で作られているので、こちらを試してもいいかもしれない。

LyhceeAgile | Lychee Redmine（ライチレッドマイン）でプロジェクトの見える化を。そして管理ももっと楽にしよう。

【5】そんなことを考えると、もう一つの問題「なぜRedmineのロードマップはもっと活用されないのか」に気づく。

本来は、マイルストーンやリリースバージョンごとの進捗はロードマップで見たい。
プロジェクトリーダーとしては、イテレーション単位の進捗状況やタスクのボリュームを見たいからだ。
つまり、2次開発や保守では、リリース計画そのものになる。
だから、チームのリソースや生産性に応じて、どれくらいのボリュームのチケットがこなせるか、リリースバージョンごとに、チケットの取捨選択を行う。

ロードマップは「イテレーション」のスナップショットなのに、なぜ使われにくいのか？
たぶん、日本のソフトウェア開発がWF型開発に偏っていて、WF型開発に最適化されたソフトウェア組織のために、最初のスコープをがっちり決める開発スタイルで、小刻みにリリースしていく開発スタイルがやりにくい、という状況があるのではないか。

この辺りの問題も考えてみる。