製造業DXを支える工程管理とは?Redmineの大規模プロジェクト階層化における課題:プロジェクトツリーの設定継承と関連チケット制限の壁
Redmineのプロジェクトツリー内の子PJに対し親PJの設定を継承させたり、関連チケット機能を制限して設定したいい欲求がある。
ラフなメモ書き。
【参考】
エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド
アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築
Xユーザーのakipiiさん: 「@g_maeda Redmine では、カスタムクエリのAND OR検索は可能ですか? 最新バージョンではもう実現されてますか?」 / X
XユーザーのMAEDA Goさん: 「@akipii テキスト形式のフィールドに対する一つのフィルタでキーワード同士のAND/OR検索はできますが、複数のフィルタ同士の結合は常にANDです。」 / X
【1】Redmineのプロジェクトツリー内の子PJに対し親PJの設定を継承させたり、関連チケット機能を制限して設定したい理由は何か?
大規模PJでは、プロジェクトのツリー構造を利用して、親子PJの階層化によりタスク管理を分割統治したい。
その時に、親PJの設定をツリー構造配下にある子PJへ継承させて、運用を楽にしたい。
最近のソフトウェア開発では、7人以下の少人数チームで開発する場合が多いから、親子PJを複雑に作る必要はない。
しかし、製造業の案件では状況が異なってくる。
製造業の案件では、1つの案件に多数の部門から担当者が張り付く。
1案件の中に、営業、設計、調達、製造、品管、プラント建設などの部門が、各工程だけ関与する。
各工程のタスクは、納期から逆算して、予定期間、予定工数はガチガチに確定している。
生産管理の教科書通りに、月次レベルの大日程、週次レベルの中日程、日次や手順レベルの小日程へWBSとして細分化し、親子チケットでツリー構造化する。
ちゃんとやると、5階層、7階層くらいまで、彼らは細かく切ってくる。
また、1つの製品や機械が数億円レベルになると、SystemOfSytemsに近いハードウェア構成になってくる。
つまり、複数の部品、コンポーネントを組み合わせて、最終的な1つの製品になるわけだ。
すると、最終製品を構成する部品のうち、結合テスト前に納品してくるレベルの部品を1つのタスク管理として扱いたくなる。
それら複数の部品を組み合わせて、結合テスト、システムテストして、最終製品になるわけだ。
よって、最終製品を構成する部品ごとに子PJを作り、子PJごとにタスク管理したい欲求が出てくる。
換言すれば、製造業の案件では階層構造の深いチケット構成になりやすいこと、SystemOfSytemsを構成する部品ごとに子PJで管理したいために階層構造を持つPJ構成になりやすいこと、という特徴が出てくる。
【2】しかし、今のRedmine標準の機能では、親子PJのPJツリー構造を持たせたチケット管理では色んな不都合が出てくる。
一般に、1つの案件では、設計部門から品管部門まで多数の担当者が複数の構成部品や最終製品に薄くタスクを貼り付けるため、親PJも子PJも同じメンバーを配置したい。
しかし、親PJでメンバーを登録すると、親PJのメンバーを子PJにもそのまま継承できない。
子PJでは最初からメンバー登録する手間がかかる。
一般に、1つの案件では、チームで定めた標準プロセスがある。
標準プロセスに従って、進捗管理や課題管理、障害管理で設定したい属性項目がある。
子PJを部品単位に設定すれば、チケットのカテゴリには、設計・調達・製造・出荷・配置建設・保守サービスなどの工程を割り当てたくなる。
しかし、親PJのカテゴリを子PJのカテゴリに継承させる機能はない。
また、標準プロセスに従って、進捗管理や課題管理、障害管理で見たいチケット一覧のビューが定まる。
基本は、カスタムクエリを用意して、期限切れ、未完了、担当者別などのビューをたくさん用意するだろう。
しかし、親PJのカスタムクエリを子PJへ継承させる機能はない。
さらに、標準プロセスに従って、1つの案件内では、情報参照させるために相互に関連チケットを付けたくなる。
しかし、部品単位に子PJを設定すると、A部品PJのチケットをB部品PJのチケットに関連させるには、管理画面で「複数PJ間でチケットを関連付ける」設定をONにする必要がある。
しかし、設定ONにすると、全てのPJで全てのチケットを関連付けることができてしまう。
一般に、製造業では、製品同士の情報はライバル企業同士なので情報共有不可、企業秘密の情報は他部署に共有不可などの規則があるので、この設定はマズい。
本来は、プロジェクトツリー内の子PJ同士で関連チケットさせる機能が欲しい。
つまり、本来は、標準プロセスを案件内で定めたならば、全ての子PJにも同様のルールを課したいが、Redmine標準に機能はないので不便だ。
おそらく、Redmineの利用シーンとしては、プロジェクトツリー内の子PJへ親PJの設定を継承させたり、プロジェクトツリー内のチケットであれば関連チケットを設定できるがそれ以外のPJのチケットは関連付けられない設定にすることは、考えられていなかったのだろう。
【3】製造業の工程管理にRedmineの機能を当てはめていく運用は、今後も考えて提案してみたい。
| 固定リンク
« Redmine × AIがプロジェクト管理を変える:祝・Redmine20周年!RedmineJapan Vol.5の司会を全うして見えた「AI連携」と「製造業マネジメント」の未来 #RedmineJapan | トップページ | なぜCCPMは挫折する?経営者の理想と現場の挫折をLycheeRedmineが解決する #redmine »
「プロジェクトマネジメント」カテゴリの記事
- 掃き溜めの鶴を活かすマネジメント、それは強みSと環境Oを組み合わせたクロスSWOT分析と同じだ(2026.10.01)
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
- 製造業でアジャイルが定着しない理由~スプリント不在とチケット二重管理の壁 #Redmine(2026.07.18)
- Redmine利用成熟度モデルによる運用戦略(2026.07.12)
「Redmine」カテゴリの記事
- Redmineのブロッキング機能で工程単位Redmine運用とトレーサビリティを解決するアイデア(2026.09.21)
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
- AIエージェントのハルシネーションは「チケット駆動」で防ぐ~次世代アジャイル開発の実践論(2026.08.04)
- 製造業でアジャイルが定着しない理由~スプリント不在とチケット二重管理の壁 #Redmine(2026.07.18)
「ソフトウェア工学」カテゴリの記事
- AIが思考を代行する時代に人間が「知識を繋ぐ」固有の価値とは何なのか?(2026.10.12)
- Redmineのブロッキング機能で工程単位Redmine運用とトレーサビリティを解決するアイデア(2026.09.21)
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- AI時代のソフトウェア開発者とはアーキテクトの役割として再定義される(2026.08.30)
- AI時代の「コードと人間の関係」を問い直す—デブサミ関西2026で考えた、アーキテクチャの未来とコミュニティの価値 #devsumi(2026.08.22)
「チケット駆動開発」カテゴリの記事
- Redmineのブロッキング機能で工程単位Redmine運用とトレーサビリティを解決するアイデア(2026.09.21)
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- 人の成果物は品質基準に不足しすぎるが、AIの成果物は品質基準を超過しすぎる(2026.08.16)
- チケット駆動でAIを制御する仕組みのアイデア(2026.08.13)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)


コメント