製造業アジャイルの事例リンク

製造業アジャイルの事例を見つけたのでメモ。
細谷さんが実践してきた事例になる。

【参考】
スピード感と品質を両立したアジャイル開発に対応する品質マネジメントシステムとは ～テスト設計方針を組み込んだ完成の定義と品質技術者の導入～ | SQiPソフトウェア品質ライブラリ

RSGT2026参加レポート

三菱電機におけるアジャイル開発への挑戦 ～過去20年の取組みと今後の展望～ | エンタープライズアジャイル勉強会 2025年10月 - YouTube

三菱電機 DX イノベーションセンターが ISO 9001 認証を取得

併設チュートリアル | ソフトウェア品質シンポジウム 2026
（引用開始）
併設チュートリアル４
アジャイル開発時代の品質マネジメントシステム
細谷 泰夫 氏
三菱電機株式会社
DXイノベーションセンター 開発・品質管理部 部長
概要
本チュートリアルでは、三菱電機がアジャイル開発とISO9001認証を両立させるために構築した、方法論に依存しない「QMSアーキテクチャ」と「品質ガバナンス」の具体的アプローチを解説します。

特にスクラムにおける「完成の定義（Definition of Done: DoD）」に着目し、品質技術者（QE）がどのように定義し、形骸化を防ぐかの実践手法を共有します。後半では、参加者自身が現場の文脈に合わせたDoDを策定するワークショップを実施します。組織の柔軟性と規律を両立させ、品質を自律的に向上させるための具体的なヒントを持ち帰っていただくことを目的とします。
（引用終了）

【1】製造業アジャイルの事例としては考え方が2つある。
1つは、ビジネス観点で、複数ドメイン事業にアジャイル開発を導入し、新卒1年目の若いメンバーからベテランまでアジャイルプラクティスを経験しながらチームの成長を得たこと。

もう一つは、ISO9001のQMSのWFシステムに、アジャイル開発プロセスを取り入れながらも、品質保証プロセスと品質担保の観点を取り入れていること。

いずれもすごく興味深い。
僕もこういう事例を作って発表したい。

Redmineのバージョンはなぜ使われないのか？

Redmineのバージョンはなぜ使われないのだろうか。
その事例を実際に見かけたのでメモ。

【参考】
チケット駆動開発の戦略: プログラマの思索

RedMineでチケット駆動開発！: プログラマの思索

【1】Redmineで一番重要な機能はバージョンだと思う。
バージョンがスプリントであり、イテレーションであり、マイルストーンであり、リリースバージョンになる。
バージョン単位にタスクをグルーピングし、小規模リリースする戦略がアジャイル開発だと考える。

よって、バージョンという機能はアジャイル開発と密接に関係する。
バージョンを使うことで、たとえば、LycheeRedmineでは、カンバンやバックログが使えるようになる。
つまり、1つのバージョンを特定すれば、カンバンになる。
複数のバージョン単位にカンバンを広げれば、バックログになる。

すなわち、カンバンやバックログのような機能を使うには、Redmineのバージョンを使う必要があるし、バージョンを使わざるを得ない。

【2】たとえば、Excelのタスク管理が混乱していて、何をすべきか分からないチームがいる。
PMOである僕は、彼らチームにRedmineを提供し、チケット駆動開発の運用ルールと運用ノウハウを伝える。
すると、若いメンバーほど、すぐにチケット管理に慣れて、タスクの消化が進んでチームが加速する。
彼らはすごく楽しそうにやる。

僕はさらに、リーダーである彼にカスタムクエリ設定、LycheeRedmineのガントチャートの操作方法を教える。
彼はカスタムクエリはSQLですね、と即座に理解し、PMOの僕が作ったクエリよりも、自分のチームなら彼が考えたクエリの方が便利だとクエリを追加する。
そして、実際に彼が作ったクエリを毎日の朝会で使って、昨日の実績、今日やること、をすぐに見える化した。
デイリースクラムが自然に身について、チームに一体感が生まれ、さらにチームが加速する。

しかし、PMOである僕が「バージョン」を設定するように説明しても、彼は納得しない。
チケットの期日から対象バージョンの期日が決まるから、機能が重複しているのでは？と彼は指摘する。

彼がカスタマイズし始めて運用を始めたRedmineでは、チケット一覧とガントチャートだけでタスク管理が回る。
ロードマップ、カンバン、バックログは使っていない。
そんな機能はなくても回るよ、と言いたげだ。

【3】では、なぜ、Redmineのバージョンは使われないのか？
理由は、バージョンを設定する人は、メンバーではなく、プロジェクトリーダー層であり、メンバーの自主性に任せて決定すべき機能ではないからだ。

バージョンはPJ設定画面でしか登録できないし、1個のプロジェクトで全てのチケットに横断して使われる。
さらに大規模PJになれば、ツリー構造のPJに対し、バージョンがPJ横断で設定される。

つまり、バージョンは、1つの案件に対し横断的に設定されて、統制をかける。
バージョンはスプリントであるから、大規模PJであれば、全ての子PJにて、基本は同じスプリントが強制設定されて、同期させることになる。
これがいわゆるアジャイルリリーストレインになる。

しかし、アジャイルリリーストレインとなるバージョンを設定できる人は、メンバーでもないし、サブチームのリーダーでもない。
1つの案件を担当するプロマネ、あるいは、プロマネの代理者でもあるPMOが担当すべきだ。
プロマネやPMOこそが、1つの案件のプロジェクトマネジメントをコントロールし責任を持つからだ。

だから、サブチームのさらにサブリーダーである彼にとって、バージョンは自分にとって身近なものではなかったのだろう。

【4】バージョンを使わない弊害は何か？

バージョンを使わないと、チケットがどんどん増えた時に収集がつかなくなる。
どのチケットを最優先にやるべきか、チケットの期日でしか優先順位の基準がない。
だから、毎日、1日分のタスクをどうやってこなすべきか、という観点しか身につかない。
1か月、数カ月レベルで案件を長く見る立場で、どのような戦略でタスクをこなしていくか、という考え方が出てこない。

スプリントという一定期間でチケットをグルーピングすれば、スプリントの中で、期日以外の優先順位付けを考えることができるようになる。
作業の優先順位は、期日だけではないからだ。
プロダクトバックログのように、1列に並べたチケットのスタックに対し、上から順に取り出せばいい。
それが唯一の優先順位であり、期日とは限らない。

【5】改めて、Redmineのバージョンは重要な機能だと思う。
今後も色々試していく。

なぜCCPMは挫折する？経営者の理想と現場の挫折をLycheeRedmineが解決する #redmine

製造業の管理職、経営者と話していると、彼らはTOCやCCPMが大好きだ。
確かに、TOCの発想はアジャイル開発にも通じるし、TOCの考え方は生産効率の向上にも使える。
CCPMの考え方も、ガントチャートの工程管理では有用だ。
しかし、実際の現場でTOCやCCPMを使おうとすると、ほとんど失敗する。
教科書通りの運用がとても難しい。

そこで、なぜ製造業の経営者はTOCやCCPMが大好きなのか、考えてみた。
ラフなメモ書き。

【参考】
Amazon.co.jp: TOC/CCPM標準ハンドブック クリティカルチェーン・プロジェクトマネジメント入門 : 西原 隆, 栗山 潤: 本

Project Management進化論 クリティカルチェーン・プロジェクトマネジメント | 後藤 智博, 渡瀬 智, 西郷 智史 |本 | 通販 | Amazon

最短で達成する 全体最適のプロジェクトマネジメント | 岸良裕司 |本 | 通販 | Amazon

【1】なぜ製造業の経営者はTOCやCCPMが大好きなのか？

理由は2つある。
1つは、ボトルネック工程を見つける発想が製造業の工程管理と相性が良いこと。
もう1つは、CCPMのフィーバーチャート分析を使えば、事業部内の全ての案件からバッファを集めてマネジメントバッファに集約することで、事業部内の要員管理に役立つことだ。

前者については当たり前だろう。
後者について考えてみる。

【2】TOCの理論を実際の現場でPJ管理に使おうとする場合、CCPMを適用することになる。
では、CCPMの本質とは一体何だろうか？

CCPMの本質は全てのタスクの残工数、つまりバッファをPJバッファに集約し、プロマネが一括管理して、PJ管理の進捗をコントロールする点にある。

CCPMでは、各タスクを見積もった時、各タスクの予定工数からバッファをバッサリ切り捨てて短縮する。
教科書では、各タスクが予定通りに終わる確率が50％になるまで、予定工数をバッサリ切り捨てる。

各タスクのバッファはPJバッファとして一括集約し、プロマネが管理する。
プロマネは、各タスクが遅れたら、PJバッファから余った工数を渡して、本来の予定工数通りに終了させる。

もちろん、各タスクがバッサリ切り捨てた予定工数で完了できれば、問題ない。
むしろ、担当者がサバを読んで見積もりを膨らませたことになるだろう。

プロマネは、PJバッファの出し入れを管理することで、PJの進捗管理を行う。
プロマネは、時系列でPJバッファ消費度合いを見ることで、PJのリスクを管理することになる。

そこで、フィーバーチャートを使って、PJが危険な領域に入ったか否かを定量的に判断する。
フィーバーチャート分析では、PJ進捗率ｘPJバッファ消費率のグラフを見て、PJ消費率が異常に高すぎるゾーンに入ると危険とみなし、早めに対策を打つべきだ、という意思決定に使う。
大抵の案件では、仕様変更や手戻り作業で当初の予定よりも遅延する場合が多いので、PJバッファをどんどん消費してしまう。
もちろん、PJバッファを全て使い切れば、予算オーバーの案件になる。

ここまでは、CCPMは一般的なPJ管理の手法だ。

CCPMがすごい点は、複数の案件の現状をフィーバーチャートにプロットし、その経緯をグラフ化することで、複数の案件管理を横串で意思決定できる点だ。

つまり、事業部内の全ての案件のPJバッファを集約することで、PJバッファをマネジメントバッファとみなし、事業部内の余裕リソースをどの案件に割り当てればよいか、という意思決定に使える。

ここで、
事業部内のマネジメントバッファ＝ΣPJバッファ＝ΣPJの各タスクの予定工数
より、
事業部が持つマネジメントバッファ費用＝ΣPJの各タスクの予定工数ｘ人月単価
になる。
一般に、事業部が持つマネジメントバッファ費用は、製造業ならば当初予算からリスク費用として取り出し、別で保持しているだろう。
一般に、リスク費用は、どこかの案件で赤字になってリカバリーする場合や、戦略的な案件に投資として使いたい場合などに使うだろう

よって、事業部が持つマネジメントバッファ費用、つまりリスク費用は、事業部長が戦略的意思決定で用いるお金に相当する。
このリスク費は、事業部長という強力な権力を持つ人だけが使える「へそくり」みたいなものだ。
へそくりであるからには、むやみやたらに使うべきではなく、大事な状況で使うべきだ。
それが、事業部長の戦略的意思決定に相当する。

すなわち、CCPMを事業部内の案件管理で使いたい欲求は、事業部長がリスク費用を事業部内の要員管理として意思決定する時に、定量的な根拠して使えるからだろう。

【3】しかし、CCPMの運用はExcelでやるのは事実上無理だ。

まず、残工数を入力する運用は現場で浸透させづらい。
残工数を把握するには、タスクの予定工数を見積もる能力、実績工数を入力する運用がセットになる。
そもそも、正確に見積もり工数を出せる担当者は少ない。
また、各タスクの実績工数を入力させる運用は、現場では非常に面倒だ。
1日のタスクは10個以上に及ぶときもあるから、勤怠時間と照合させようとすると破綻する。

次に、案件にある各タスクの残工数を収集し、PJバッファに集めて、PJバッファ消費率を追跡する処理は実装しづらいからだ。
Excelではフィーバーチャートをプロットするのは非常に難しい。
データを1個のシートに集めればフィーバーチャートを描けるだろうが、綺麗に出力しようとすると、Excelマクロを駆使することになるだろう。
本気でやれば、ExcelマクロでCCPMツールを自作するくらいのレベルになるだろう。
よって、CCPM専用の管理ツールをパッケージ製品やSaaSで利用することになるだろう。

しかし、CCPM専用の管理ツールは非常に高価であり、UIがダサくて使いづらいツールが多い。
肝心のガントチャート画面で操作がモッサリしていたり、WBS詳細化する操作が使いづらかったり、WBSの属性を登録する手間が多すぎたりして、使いづらいケースが多い。

結局、CCPMは教科書ではすごいけれども、実際の現場では使えないね、という結論になる。

【4】一方、CCPMを運用するツールの一つとして、LycheeRedmineのCCPMプラグインは使いやすいツールだろうと考える。
なぜならば、Redmineのチケット入力機能を上手く流用することで、CCPMが持つ複雑さを和らげて、CCPMを運用しやすくしているからだ。

CCPMツールならLychee Redmine｜フィーバーチャートでバッファ消費率を自動で可視化

LycheeRedmineでは、CCPMを運用したい時に上手く工夫されている機能がある。
たとえば、残工数を入力するIFとしては、チケット属性の「残工数（Lychee）」になる。
チケット属性の「残工数（Lychee）」に入力すれば、各タスクの残工数を把握できる。

LycheeRedmineでは、Redmine標準の予定工数・実績工数の機能を流用し、残工数を集めて、フィーバーチャートへ自動集計してくれる。
LycheeRedmineのCCPM設定画面では、「日次バッチでフィーバーチャート分析する」設定をONにすれば、日々でフィーバーチャートをプロットしてくれる。

LycheeRedmineのCCPM設定画面では、PJバッファをPJからどれくらい集めるかを設定する機能、フィーバーチャートの危険・警告・正常領域の閾値を設定する機能があるので、色々カスタマイズできる。
さらに、バージョンごとにPJバッファを登録する機能があるので、たとえば、各工程ごとにバッファを設けて、バッファ消費率を追跡する運用も可能だ。

フィーバーチャートを出せれば、プロマネはPJリスクを定量的に意思決定できるようになる。
これがやりたいことだ。

ただし、CCPM運用の前提は、作業者がチケットの残工数を毎日入力する運用を徹底できていることだ。
そこさえクリアできれば、教科書でしか運用できなかったCCPMが、Redmineの優れたチケット管理を使って簡単に運用できるようになる。

【5】そんなことを思うと、LycheeRedmineは非常に優れたツールだと思う。

なぜならば、Redmine標準の優れたチケット管理機能を流用して、CCPM運用をよく考えて機能実装できているからだ。
LycheeRedmineでは他にも、Scrumに特化した機能、つまり、カンバンやバックログもあるので、Scrumも運用可能だ。

Lychee Redmine、アジャイル開発向け新機能「Neoカンバン」をリリース| 株式会社アジャイルウェア

すなわち、LycheeRedmineを使えば、各PJでテーラリングすることで、CCPMをやるPJもあれば、ScrumをやるPJも併存して運用可能だ。
これはすごいことだと思う。

【6】LycheeRedmineの機能については、別記事で詳しく解剖してみたいと思う。

製造業DXを支える工程管理とは？Redmineの大規模プロジェクト階層化における課題：プロジェクトツリーの設定継承と関連チケット制限の壁

Redmineのプロジェクトツリー内の子PJに対し親PJの設定を継承させたり、関連チケット機能を制限して設定したいい欲求がある。
ラフなメモ書き。

【参考】
エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築

ドメイン駆動設計をはじめよう

Xユーザーのakipiiさん: 「@g_maeda Redmine では、カスタムクエリのAND OR検索は可能ですか？　最新バージョンではもう実現されてますか？」 / X

XユーザーのMAEDA Goさん: 「@akipii テキスト形式のフィールドに対する一つのフィルタでキーワード同士のAND/OR検索はできますが、複数のフィルタ同士の結合は常にANDです。」 / X

Xユーザーのakipiiさん: 「@g_maeda Redmine では、カスタムクエリ、カテゴリはプロジェクトツリー内で継承できますか？　大規模案件ではどうしてもツリー構造にたくさんのプロジェクトを作るしかないですが、それら項目や機能は共通化したいためです」 / X

XユーザーのMAEDA Goさん: 「@akipii カスタムクエリを全プロジェクト向けとすることはできますがプロジェクトツリーに限定することはできません。カテゴリは同一プロジェクト内でのみ有効です。」 / X

Xユーザーのakipiiさん: 「@g_maeda Redmine では、関連チケットはプロジェクトツリー内でしか使えない制限を課すことは可能ですか？　セキュリティ上ツリー外のプロジェクトには関連づけたくないためです」 / X

Xユーザーのakipiiさん: 「@g_maeda Redmine では、関連チケットはプロジェクトツリー内でしか使えない制限を課すことは可能ですか？　セキュリティ上ツリー外のプロジェクトには関連づけたくないためです」 / X

【1】Redmineのプロジェクトツリー内の子PJに対し親PJの設定を継承させたり、関連チケット機能を制限して設定したい理由は何か？

大規模PJでは、プロジェクトのツリー構造を利用して、親子PJの階層化によりタスク管理を分割統治したい。
その時に、親PJの設定をツリー構造配下にある子PJへ継承させて、運用を楽にしたい。

最近のソフトウェア開発では、７人以下の少人数チームで開発する場合が多いから、親子PJを複雑に作る必要はない。
しかし、製造業の案件では状況が異なってくる。

製造業の案件では、１つの案件に多数の部門から担当者が張り付く。
１案件の中に、営業、設計、調達、製造、品管、プラント建設などの部門が、各工程だけ関与する。
各工程のタスクは、納期から逆算して、予定期間、予定工数はガチガチに確定している。
生産管理の教科書通りに、月次レベルの大日程、週次レベルの中日程、日次や手順レベルの小日程へWBSとして細分化し、親子チケットでツリー構造化する。
ちゃんとやると、５階層、７階層くらいまで、彼らは細かく切ってくる。

また、１つの製品や機械が数億円レベルになると、SystemOfSytemsに近いハードウェア構成になってくる。
つまり、複数の部品、コンポーネントを組み合わせて、最終的な１つの製品になるわけだ。
すると、最終製品を構成する部品のうち、結合テスト前に納品してくるレベルの部品を１つのタスク管理として扱いたくなる。
それら複数の部品を組み合わせて、結合テスト、システムテストして、最終製品になるわけだ。
よって、最終製品を構成する部品ごとに子PJを作り、子PJごとにタスク管理したい欲求が出てくる。

換言すれば、製造業の案件では階層構造の深いチケット構成になりやすいこと、SystemOfSytemsを構成する部品ごとに子PJで管理したいために階層構造を持つPJ構成になりやすいこと、という特徴が出てくる。

【2】しかし、今のRedmine標準の機能では、親子PJのPJツリー構造を持たせたチケット管理では色んな不都合が出てくる。

一般に、１つの案件では、設計部門から品管部門まで多数の担当者が複数の構成部品や最終製品に薄くタスクを貼り付けるため、親PJも子PJも同じメンバーを配置したい。
しかし、親PJでメンバーを登録すると、親PJのメンバーを子PJにもそのまま継承できない。
子PJでは最初からメンバー登録する手間がかかる。

一般に、１つの案件では、チームで定めた標準プロセスがある。
標準プロセスに従って、進捗管理や課題管理、障害管理で設定したい属性項目がある。
子PJを部品単位に設定すれば、チケットのカテゴリには、設計・調達・製造・出荷・配置建設・保守サービスなどの工程を割り当てたくなる。
しかし、親PJのカテゴリを子PJのカテゴリに継承させる機能はない。

また、標準プロセスに従って、進捗管理や課題管理、障害管理で見たいチケット一覧のビューが定まる。
基本は、カスタムクエリを用意して、期限切れ、未完了、担当者別などのビューをたくさん用意するだろう。
しかし、親PJのカスタムクエリを子PJへ継承させる機能はない。

さらに、標準プロセスに従って、１つの案件内では、情報参照させるために相互に関連チケットを付けたくなる。
しかし、部品単位に子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

RedmineJapan Vol.5の司会を全うした。
すごく楽しかった。

【参考】
Redmine Japan ≫ Redmine Japan Vol.5

REDMINE JAPAN vol.5 オフライン開催＠ワテラスコモン - connpass

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築

ドメイン駆動設計をはじめよう

【1】Redmineコミュニティは、高校の部活、大学のサークル、文化祭に似ている。
皆でワイワイガヤガヤ一緒にやるのが楽しい。
何かの目標に向かって、若気の至りをフルに使って、好きなことをやるのがいい。

大の大人が30代、40代、50代になっても、高校大学のノリで騒げるのが好き。
OSSコミュニティだからこそ、そんな雰囲気を楽しめる。

【2】RedmineJapanの講演で興味を引いたテーマは2つある。
1つは、NTTドコモソリューションズ、東芝、島津製作所、パナソニックなどの大手企業のRedmine運用の話。
もう一つは、RedmineとAIの話。

【3】大手企業のRedmine運用では、ユーザ1千人以上がRedmineを使っている。
興味を引いたのは、Redmineがいかに社内で浸透して使われて成果を出している、とアピールするために、色んな定量データを準備している点だ。
正直、ユーザ数、チケット数の時系列推移だけでもいい。

大手企業の中でRedmine運用が成果を出しているとアピールしなくていはいけない理由は何か？
Redmine運用は所詮、管理コストなので利益はないから、コストセンターに過ぎない。
よって、Redmineが活発に使われて、社内では無くてはならないツールなのだ、と社内で、特に経営層に アピールしなくてはならない。
だから、色んな定量データを集めて、目に見える形にする必要がある。

今なら、ユーザCSV、チケットCSVを出力すれば、AIに食わせて、要約や傾向分析、洞察まで出してくれる。
そこから色んな知見が得られる。
ここにも、AIがRedmine運用に新たな知見をもたらした事例が出てくる。

【4】Redmineが最近盛り上がってきた理由は何なのか？
理由は、RedmineとAIの相性が良いからだ。

AIは、MDファイルのようなテキストをインプットとして扱う。
Redmineに蓄積されたチケット、WikiをCSV出力すれば、AIに食わせて、要約、傾向分析、洞察が簡単に得られる。
最近、Wiki一括ダウンロード機能がリリースされたが、その意図は、AIに食わせたいことにあるだろう。
日々の作業やナレッジをRedmineに蓄積する運用ができていれば、AIに食わせて色んな使い方が出てくる。

問合せチケットをCSV出力してAIに食わせれば、問合せの傾向分析で有用な結果が出るだろう。
障害チケットも同様だ。

全文検索プラグインにAIもミックスして、セマンティックサーチする講演もあった。
つまり、異音同義語のような表記揺れもAIが上手く吸収して、検索機能を強化してくれる。
すなわち、Redmineに蓄積されたデータをさらにフル活用して、有用な結果を得る機能を強化してくれる。

一方、Redmine AI Helperプラグインは、チケット入力補完や子チケット分割、表記揺れ対応などもサポートしてくれる。

他に、RedmineにMCPサーバ機能を追加して、Teamsと連携して、Teamsチャットからチケット作成する事例もあった。
RedmineにMCPサーバー機能が追加できれば、Teams、Outlook、GitHub、Slackなど外部リポジトリと連携して、更に強力にチケット入力やチケット検索を支援できるだろう。
ボウコバさんから聞いた話では、PCログなどもAIに食わせれば、PC作業者が1日でどんな作業をしたのか、その作業がどのチケットに紐づくのか、チケットの実績工数を支援する機能も可能だ、と話されていた。
つまり、Redmine実績工数入力をAIが支援してくれるわけだ。

たとえば、Redmine実績工数入力をAIが支援し、予定工数を入力できる運用ができれば、EVM出力も可能になる。
RedmineでEVM出力できれば、各PJの週次報告の定量データとして扱えるメリットがある。
PJ報告の文章は、RedmineチケットからAIが自動生成すればいい。
つまり、Redmine上でPJ報告を作成する管理工数をAIが減らしてくれる。

従来は、RedmineでEVM出力は可能だが、予定工数や実績工数の入力が大変で、手間がかかる割にはメリットが少なかった。
しかし、RemdineとAIを組み合わせれば、全てのプロジェクト管理をRedmine上で一括管理できるハードルが劇的に下がるはずだ。

RedmineとAIの組み合わせは、プロジェクト管理の手法に新たな可能性をたくさん引き出してくれる。

【5】他には、製造業のRedmine運用は、SIerのRedmineと異なる点があることだ。

SIerでは、1案件に基本は作業者が張り付き、兼務する場合は少ない。
兼務する作業者は、インフラ担当のように案件共通で基盤構築が必要な場合だけだ。

一方、製造業では、1担当者は複数案件を兼務し、1案件に薄い工数で張り付く。
なぜならば、製造業は機能別組織なので、1案件に多数の専門技術者が一定期間だけ関与する体制だからだ。
たとえば、製造業では、営業部門、R＆D部門、設計部門、調達部門、製造部門、建設配置部門、品管部門のように、事業部組織よりも機能別組織が一般的だ。
よって、1案件の各工程で、専門の技術者が担当し、工程が分断された形で工程管理する。
1担当者は複数案件を兼務するので、事実上、製造業の組織はマトリクス型組織になる。

マトリクス型組織のデメリットは、２ボス体制になるので作業者のレポートラインが複雑になりがちなこと、部課長は要員計画を立てにくくなることだ。
作業者は案件のPM、自組織の上司の２人に報告する必要があるので、意思決定が食い違うと迷ってしまう。
また、部課長は、複数案件を自組織で責任を持つが、どの期間に誰を担当させるか、意思決定が難しい。
なぜならば、一般的に、PJ横串で毎月これくらいの予定工数が必要と集計されたデータは出てくるが、どうアサインすべきか、具体的に判断しづらいからだ。

つまり、製造業の工程管理では、単純な進捗管理だけではなく、工数管理もRedmineでやりたくなる。
製造業では、PL、BSだけでなく製造原価報告書も会計上必須なので、元々工数管理を厳格に管理する動機はある。
しかしそれだけではなく、要員管理、つまり負荷計画をきちんとやりたい動機もある。

Redmine標準の機能ではリソース管理は難しいが、LycheeRedmineならば、リソースマネジメントやタイムマネジメントの機能もあるので、予定・実績工数入力をきちんと運用できれば、生産性・稼働率も集計表示してくれるメリットがある。
ただし、LycheeRedmineの機能はかなり複雑にカスタマイズしているので、相当な調査が必要だろう。

製造業特有の工程管理や原価管理と、LycheeRedmineの操作や利用シーンを理解する必要があるので、かなり難易度の高いプロジェクトマネジメント技法になると思う。

【6】まあ、とにかく楽しかった。
昨日は、Redmine誕生20周年だったので、皆で20周年記念のケーキで祝ってを食べた。
すごく大きくて迫力のあるケーキだった。
また来年も開催してくれるので、すごく楽しみにしてる。

【7】現代チケット駆動開発の課題とマイクロマネジメントの罠を再定義する話をショートプレゼン20連発で話してきた。