製造業でアジャイルが定着しない理由～スプリント不在とチケット二重管理の壁 #Redmine

製造業でアジャイル開発が定着しない根因は「スプリント」概念の欠落だ。
WF型の現場ではスコープ調整が機能せず、大日程とチケットの二重管理や階層的なマイルストーンが壁となる。
Redmine運用が破綻する背景から、製造業特有の構造的課題とチケット駆動開発の実態を紐解く。

【参考】
Redmineのバージョンはなぜ使われないのか？: プログラマの思索

第29回東京Redmine勉強会の感想～今話題のテーマはJTC運用とAIによるプロマネ作業支援 #redminet: プログラマの思索

【0】製造業でアジャイル開発できないのはなぜか？
原因にスプリントの概念が不明確な点があると考える。

【1】ソフトウェア開発では、スプリントの概念は自然に現れる。
たとえWF型開発であってもだ。

アジャイル開発をやっているならば、1～4週間の単位で、定期的にリリースするタイミングがある。
それがスプリントだ。
スプリントの単位で、どの機能を最優先にするのか、決める。
あれもこれも機能実装するわけにはいかない。
限られた期間、限られた人数では、やれる範囲は限られる。
そこで、スコープを調整することで、やるべき機能を優先順位付けし、スプリントの工数に当てはまる範囲に絞り込む。
一般に、カンバン機能を使うだろう。
スプリントレビューで成果物を関係者がレビューし、スプリントデモで実際に成果物を見せる。
そこで得られたフィードバックを元に、また次回のスプリントに活かす。

複数のスプリントを見渡して、どの機能をどの順番でリリースしてシステムを拡張していくべきか？
それがリリース戦略になる。
リリース戦略の観点では、各スプリントの成果物はインクリメント、増分だから、計画的にどのようにインクリメントを積み重ねて最終ゴールに辿り着くのか、という考えになるだろう。
これが、小規模リリースの考えにつながるだろう。
一般に、複数のスプリントをカバーする機能はバックログ機能になるだろう。

一方、ソフトウェア開発の保守案件であれば、普通は月次の単位でリリースする運用が多いだろう。
月次の単位がスプリントになるだろう。
保守契約の工数の範囲内で、リリースする機能の優先順位を決めて、順次作業してリリースしていく。

これが開発のリズムになる。
ソフトウェア開発者にとって、この開発リズムは心地よい。
タスクの優先順位や作業順序は明確だし、自分たちの作業ペースを守って作業できるので、基本は作業負荷が高くなるケースはないからだ。

【2】しかし、製造業の現場では、スプリントの概念がしっくり来ない。

製造業の現場では、基本はWF型開発がほとんどだ。
設計工程、製造工程、試験工程、保守工程になるだろう。
各工程の大日程計画がマスタスケジュールとしてベースラインになり、ガントチャートで予実管理を行う。
そこにはスプリントという概念がない。

たとえば、Redmineのバージョンはなぜ使われないのか？: プログラマの思索に書いたように、Redmineバージョン機能は作業者レベルでは出てこない発想だ。
Redmineバージョンは期日に紐づく機能ではない。
バージョンは、スプリントでありリリースする単位であるので、期日とは別物だ。

そこで、PMOである僕は、PJ全般を見渡す権限を持つ担当として、Redmineバージョンを事前に計画する。
たとえば月次や週次でRedmineバージョンを設定する。
たとえ、製造業の案件であっても、経営層向けの報告のタイミング、顧客に報告するタイミングはあるので、それをマイルストーンに割り当てれば、それがリリースと同じ内容になるからだ。

しかし、製造業の担当者は、このバージョン、スプリント、マイルストーンをあまり意識していないように思える。
彼らはマイルストーンを意識していても、タスク量というスコープをコントロールする意識がない。
理由は簡単だ。
設計工程は確かに試行錯誤する作業が多いが、設計できたCADデータを元に製造工程、試験工程は日程が定まり、リードタイムもきっちり固まる。
設計図をもとに、全ての部品や材料を一括発注し、製造工程でまとめて組み立てて、まとめて試験するからだ。
製造工程以降ではアジャイル開発にはなりえない。

【3】Redmineバージョンが使われないタスク管理ではどんな悪影響が出るのか？

LycheeRedmineには、カンバンやバックログ機能があり、とても使いやすいUIになっている。
しかし、Redmineバージョンが設定されていないと、スプリント単位にタスクがグルーピングされないので、カンバンやバックログを有効に活用できない。
だから、製造業の現場では、カンバンやバックログの機能が使いづらい。
むしろ、ガントチャート画面で、大工程から中日程までのWBSを詳細化して階層化する方を彼らは好む。

でも、僕が第三者観点で見ると、LycheeRedmineのガントチャート画面はUIも優れているし使いやすいが、製造業の彼らは進捗管理に上手く使えているように思えない。
大工程は月次レベル、中日程は週次レベルなので、毎日の朝会でタスク確認すると、あまり進捗が進んでいないように見える。
実際、5日程度の作業量なので、毎日の進捗はせいぜい20％くらい進む程度であり、1日程度の差ではそんなに変わらない。
本来は朝会で進捗状況から課題を把握したいが、担当者が手を上げてエスカレーションしない限り、課題は分からない。
課題は現場でしか落ちていないので、現場すべてを見ていないリーダーからは、課題がないように見える。

そこで、リーダーは小日程レベルのタスクをチケット登録し、WBS管理したがるが、そうなるとタスク管理が発散する。
製造業であっても、小さなタスクはいくらでもあるので、それらを逐一登録すれば、あっという間に1案件でも数千行のWBSに膨れ上がる。
そうなれば、リーダーであってもすべての作業を追跡して把握するのは難しくなる。

本来は、スプリント単位に大量のタスクをグルーピングして、リーダーが追跡できるボリュームにタスク量を減らすべきだ。
すると、カンバンで現在のスプリントのタスク管理ができるようになる。
バックログで、現在と未来のスプリントのタスク管理ができ、出荷までの戦略を立てれるようになる。

でも、製造業の彼らはそんな管理はしていない。

【4】なぜ、製造業ではスプリントの概念が現場で上手く根付かないのか？

今僕が現場を見て認識する組織的課題は「製造業では、スプリントの単位で仕事していない。だからLycheeが提供するカンバンやバックログを利用するメリットをメンバーは感じていない」だ。
製造業でもマイルストーンはあるが、ソフトウェア開発におけるアジャイル開発の概念と根本的に異なると感じている。
僕が設定したRedmineバージョンでアジャイル開発をやろうとしても、製造業のメンバーは理解がしっくり来ず、運用できていない。
ソフトウェア開発では、スプリントに収まるタスク量をスコープ調整することで、スプリントを意識しながら作業できる。
しかし製造業ではWF型開発の観点が強いので、マイルストーンを決めると、マイルストーンに従ったスコープは確定して変更できない。
そこで、バッファを持たせてタスク管理しようとするが、よくあるようにバッファをすぐに食い潰す。
製造業でアジャイル開発をやるにはマイルストーン管理、スプリントの実装が必要だが、何か上手くいかない。

【5】もう一つの問題もある。
製造業では、大日程計画のマスタスケジュールに基づくタスク管理と、突発的な作業依頼や月次報告のためのタスク管理が混在するので、実際のタスク管理は二重管理になっている。
詳細はこうだ。

一般に、大日程計画のマスタスケジュールは顧客と締結する。
いつまでに設計が終わって製造を開始して、半年後、1年後に納品します、と顧客に提示する。
顧客に提示するマスタスケジュールは、小日程計画レベルのような細かいスケジュール表ではない。
月次レベルの荒いスケジュールであり、パワポやExcelのポンチ絵だ。
このマスタスケジュールがベースラインとなる。
製造業の社内でも、承認されたスケジュールとして保管されて、ISO9001のような監査でも使われるだろう。
つまり、大日程計画のマスタスケジュールは、顧客向け、監査向けのタスク管理だ。

一方、日々の詳細なタスク管理もある。
僕はチケット駆動開発が好きなので、製造業の現場であっても、メンバー自らチケットを発行してタスク管理を促している。
製造業の担当者もチケット管理に慣れると、自分のTODOみたいにどんどん書き出して、作業漏れを無くすように自ら動く。
また、製造業のタスクは先行後続関係が生まれるケースが多いので、彼らはRedmineチケットの先行・後続関係を使い始める。
LycheeRedmineのガントチャート画面は、先行後続関係を簡単に紐づけできるUIなので、彼らは率先して使い始める。
LycheeRedmineのクリティカルパス機能、Redmine標準のイナズマ線を使えば、ガントチャート画面上で、最優先でやるべきタスクが分かるし、進捗の遅延があるか否かを判別できる。
製造業の彼らも、Redmineのチケット管理に慣れると、こういう機能を自ら使い始めて、進捗管理を始めてくれる。

しかし、僕は、この日々のタスク管理はマスタスケジュールに故意に連動させない運用にしている。
なぜならば、せっかくチケット駆動でやり始めたタスクを大工程に紐づけると、親子チケットが発生し、WBS100%ルールに縛られて、大工程の予定期間や予定工数が上書き更新される状況が発生するからだ。
大日程計画のマスタスケジュールは顧客と握ったものだから、勝手に予定の期間や工数を変えるべきではない。

他方、大工程のマスタスケジュールと日々の詳細なタスクを紐づけたとして、WBS100％ルールを課さない設定で運用すると、マスタスケジュールよりも遅れたチケットが発生し、予実管理の意味がなくなる。
マスタスケジュールより遅れたチケットがあるならば、マスタスケジュールを更新すればよいだろうが、顧客と交渉して変更する必要があり、それは非常に難易度が高いことは誰でも知っている。

つまり、顧客に見せた綺麗な大日程のマスタスケジュールと、案件にあるチーム内のタスク管理で二重管理が発生する。
わざわざ連動させようとすると、チケットメンテ工数が肥大化するし、その管理工数はそもそも案件の目的に沿わない作業になるので無駄だ。

よって、製造業のタスク管理をRedmineでチケット管理しようとすると、PM層や顧客にきれいに見せるガントチャートと、メンバーが日々作業するチケット管理の２種類が混在するようになる。
これらを上手く管理する方法が僕にはまだ分かっていない。

【6】製造業でRedmineバージョンが上手くいかない理由は何か？

１つ目は、すでに上記で書いた。
製造業には、スプリントでスコープ管理する発想がないこと。

２つ目も、すでに書いた。
大日程のマスタスケジュールと日々のチケット管理という二重管理が発生している状況に対し、Redmineバージョンを大日程のマスタスケジュールや日々のチケット管理にどのように割り当てるべきなのか、という問題がさらに状況を複雑化させているからだ。

３つ目は、以前発表したように、製造業のタスク管理でマイルストーン管理を行う場合、メカ・エレキ・ソフトのような機能別組織があるために、マイルストーンを階層化する複雑性が発生するからだ。

第29回東京Redmine勉強会の感想～今話題のテーマはJTC運用とAIによるプロマネ作業支援 #redminet: プログラマの思索

how-we-operated-ticket-driven-development-in-jira-pdffrom akipii ogaoga

【7】ソフトウェア開発では上手くやれるアジャイル開発を製造業の現場で上手くやるには何が必要なのか？
それは、Redmineバージョンをいかに製造業のタスク管理に実装できるか、が鍵を握る。
そのためには、上記の３つの問題を解決しなければ、本来のチケット管理の良さを引き出せないだろう。

今後も考える。

Redmine利用成熟度モデルによる運用戦略

Redmineを単なるタスク管理で終わらせるな。
全社展開で組織のプロジェクトマネジメント能力を獲得するには明確な運用戦略が不可欠だ。
僕が独自で考えた「Redmine利用成熟度モデル」を提唱し、7段階のステップで現在地から理想のゴールへ導く実践的ロードマップを以下に示す。

【参考】
Redmineによるタスクマネジメント実践技法

operational-strategy-based-on-redmine-utilization-maturityfrom akipii ogaoga

【1】今、JTC全体にRedmineを運用推進する立場にあったとする。
その時、どんな戦略を立てて、Redmineを全社の案件に適用し、推進していくべきか？
Redmineを利用していく前提に対し、どんなゴールを目指すのか？

その時に考えるべきモデルが必要だ。
僕は「Redmine利用成熟度モデル」を提唱し、そのモデルを基準として運用戦略を立てる方針とした。

【2】なぜ、Redmine利用成熟度モデルを考える必要があるのか？
そもそも、そんなモデルは役に立つのか？

前提として、Redmineを個別最適化された一つの案件だけでなく、全社に展開し、全ての案件に適用したい立場にある。
すると、Redmineというツールを単に導入するだけの仕事になってしまう。
しかし、本来は何かしらの目的があるはずだ。
そうでなければ、わざわざ、工数やコストを支払ってでもやる必要がない。

Redmineを導入する目的は、Redmineという柔軟なチケット管理ツールを用いて、組織としてのプロジェクトマネジメント能力を獲得したいからだ。
さらには、多種多様なプロジェクトを一つのツール内のタスク管理や進捗管理、コスト管理に収めて、一元管理することによって、全ての案件の健康状態を即座に把握し、管理職層や経営層にエスカレーションし、意思決定できる基盤を提供することだ。

つまり、組織のプロジェクトマネジメント能力を獲得できている状態が目指すべきゴールになる。
そういう組織的能力が身につくからこそ、単なる進捗管理だけでなく、予定工数や実績工数を入力してEVM活用やプロジェクト報告を出力することにより、複数案件をまたいだ要員管理や予算計画のようなコスト管理まで可能になる。
そうなれば、事業部長レベルの意思決定支援にRedmineを有効活用できるようになる。

そんなゴールを目指すためには、組織のプロジェクトマネジメント能力がどのレベルにあるのか、を把握する基準やメトリクスが必要になってくる。
その基準を組織に当てはめることにより、現在地を知り、ゴールに向けて後どれくらいの階段が残っているのか、を見極めて、戦略を練ることができる。

【3】組織のプロジェクトマネジメント能力、具体的にはRedmineの利用レベルがどんな状態にあるのか、それを把握する基準の考え方が、Redmine利用成熟度モデルという概念だ。

ネタバレとして、CMMIやIT経営成熟度モデル、DX成熟度モデルなどを参考にしたが、Redmineの利用状況をより具体的に明確に定義するために、７段階で定義した。

operational-strategy-based-on-redmine-utilization-maturityfrom akipii ogaoga

【4】レベル１は、Excelで進捗管理している状態。
案件が順調ならまだしも、３人のチームであっても、突発的な作業依頼や仕様変更、手戻り作業が発生すれば、すぐに破綻する。
まだ、Redmineを運用できていない状態だ。

【5】レベル２は、ガントチャートの工程管理ができる状態。
Redmineを利用して、チケット管理を通じて、ガントチャートの工程管理ができる。
WBSをチケットにすれば、３階層、５階層でも複雑なWBSも実現できる。
ただし、標準プロセスが確立していないので、プロジェクトごとに運用ルールがバラバラであり、ノウハウも共有できていない。
各案件ごとに個別最適化されたRedmineプロジェクトが乱立している状態だ。

この状態が続くと、運用はじきに破綻する。
なぜならば、Redmineを単なるタスク管理としてしか使っておらず、全社でナレッジを共有したり、プロセス改善する仕組みがないからだ。
よって、プロジェクトリーダーの手腕に案件の成功が依存する。
したがって、組織のプロジェクトマネジメント能力が向上できるとはいえない。

【6】レベル３は、最低１タイプの標準プロセスが確立し、各プロジェクトに適用して運用できている状態。
具体的には、全社で使うべきトラッカーの種類が確定し、ワークフローが定められて、全てのPJに適用できている。
たとえば、「タスク」以外にも、「障害」「課題」「カスタマーサポート」などのトラッカーとワークフローが準備されているだろう。

さらに、製造業であれば、ISO9001などの国際規格に準じたプロセスに適用する必要がある。
そんなプロセスの実装手段として、チケットテンプレート、チケットセット、プロジェクトテンプレートのような機能があるだろう。

たとえば、チケットの書き方として、作業内容だけでなく、作業手順や完了条件、資料リンク、対応履歴などの記載をチケットテンプレートとして案件に提供し、記載内容の粒度を揃える。
つまり、LycheeRedmineのチケットテンプレートを使う。
そうすれば、システム監査やISO監査でも、調査しやすくなる。

たとえば、CADの画面を出図する設計プロセス、製品の部品や役務を購買する発注プロセス、製品の試験や品質保証を規定するプロセスがある。
つまり、各プロセスには、既に定められた手順がある。
その手順をチケット化してテンプレート化すればいい。
LycheeRedmineには、チケットセットという機能があり、標準WBSとして階層構造のチケットの塊をテンプレートとして保持し、コピーすることで使える。
つまり、出図プロセス、発注プロセス、製品試験プロセスの標準WBSをチケットセットで作っておき、必要な時にコピーして案件に取り込めばよい。

たとえば、製品の派生開発の案件に対し、以前の製品開発の案件設定をそのまま流用して使いたい場面が出てくる。
派生製品であれば、カスタマイズする場所は特定できている前提ならば、トラッカーやカテゴリなどのチケット機能、メンバー、WBSなどもそのまま流用したくなる。
あるいは、親PJの設定を子PJへ流用して同様に設定したい場合も多々ある。
そんな実装手段として、LycheeRedmineのプロジェクトテンプレートが使える。
そうすれば、以前のプロジェクト、親プロジェクトをそのまま流用して適用すれば良い。

【7】ここまで到達すれば、Redmineを運用する基盤は整う。
僕の経験上、レベル３に到達するには、一般に、SEPGと呼ばれる「Software Engineering Process Group（ソフトウェアエンジニアリング・プロセス・グループ）」の部門が必要になるだろう。
つまり、ソフトウェア開発の品質向上や業務効率化を目的として、組織の標準的な開発プロセス（進め方）の企画・構築・改善を専門に行うチームや推進者を指す。

SEPGは主に下記３点のミッションがあるだろう。
・プロセスの標準化: 組織全体で一定の品質を担保するため、開発手順やルールを定めた「標準プロセス」を策定。
・プロセス改善（SPI）: 現場の課題を分析し、より効率的で安全な開発ができるようにプロセスを改善・更新。
・現場への展開と支援: 新しいプロセスを現場のプロジェクトに導入・定着させるための教育やサポート実施。

【8】ただし、レベル３以上の機能に確実に対応するには、Redmine標準の機能だけでは足りない。
LycheeRedmineのような有償機能の導入が必要になる。
コスト面さえクリアできれば、Redmine利用成熟度モデルに従って、組織のプロジェクトマネジメント能力の現在地に応じて、どこまでのレベルを目指すべきなのか、検討できる。

【9】レベル４では、Redmineに蓄積されたデータを元に定量分析・測定できる状態にある。
具体的には、Redmineに蓄積されたチケット、Wiki、外部リポジトリを集計して、案件のQCDを把握するための情報を測定し、分析し、プロセス改善を行う。
たとえば、Redmine標準ならサマリの機能があるし、LycheeRedmineならダッシュボードがあるだろう。

一般に、SEPGが定量分析・測定を行い、各案件のQCDのメトリクスを出力し、診断レポートを作成し、案件のリーダーやメンバーに配布して、プロセス改善を促す
あるいは、案件のQCDを見える化して、プロジェクトの組織的課題やプロセス観点の課題を抽出し、マネジメント層や経営層へエスカレーションして、意思決定を促す。
これこそが、SEPG本来の仕事になる。

なお、LycheeRedmineだけでなく、Tableauなどの外部BIツールを使ってもいいだろう。

【10】レベル５では、各タスクの予定工数や実績工数を入力し、EVMを出力し活用できている状態になる。
EVMのメリットは、案件の進捗やコストの状況を定量的にリアルタイムに把握できる点だろう。

PMBOKではEVMの定義と計算をやらされるが、実際のプロジェクトマネジメントで適用するのは非常に難しい。
単純なExcel管理では実現できないからだ。
だから、EVMは机上の理論に過ぎないとよく言われる。
しかし、たとえば、僕の経験では、能力の高いプロマネは、ExcelマクロでEVM機能を実装しておき、社内の予算管理システムから予算、原価管理システムから実績工数や実績原価を取得し、Excelマクロに取り込んで、EVMを測定し、独自に分析していた。
EVMのグラフを出力できれば、一目瞭然に案件を傾向分析できる。
彼は、EVMを案件のリスク管理に使っていたわけだ。

一方、2010年当時に「Redmineによるタスクマネジメント実践技法」本を出版した時は、EVM活用はまだアイデア段階だった。
しかし、LycheeRedmineによりついに機能として実装された。
標準プロセスが確立し、予定工数や実績工数を入力する運用を徹底できれば、EVMの出力は簡単になる。

【11】EVM運用できる状態にあるメリットは、リソース管理により、生産性、稼働率を把握でき、負荷計画を立てやすくなることだ。
たとえば、人別の実績工数から、案件の稼働率も把握できる。
製造業にとって、稼働率というKPIは非常に重要だ。
設備機械、担当者の稼働率が高いほど、工場にある資源を有効活用できている状態になるからだ。
彼らは月別の稼働率を色んな観点で把握し、遊んで休んでいる設備や人がいないか、いつもチェックしている。
そんな管理作業にRedmineが使える。

たとえば、人別の予定・実績工数より、人別生産性が分かる。
最近では、36協定による労働時間規制が厳しくなったので、メンバーの労働時間を正確に把握する必要がある。
Redmineに実績工数があれば即座に把握できるし、生産性を把握することで、リソース配分のKPIとして使うこともできる。

このやり方を更に発展できれば、複数の案件を一括集計して、部内全体の要員管理にも適用できるだろう。
この観点では、案件リーダーのような一人のプロマネではなく、複数の案件を管理するプロマネないし、課長・部長クラスの仕事になる。
彼らにもRedmineが有効なツールになるわけだ。

【12】レベル６では、Redmineに蓄積された情報から集計出力されたQCD情報を元に、PJ報告を作成し運用できている状態になる。
具体的には、EVM運用できている状態であれば、案件のQは課題や障害チケットを集計すればいい。
案件のDはタスクの進捗率やステータスから把握できる。
案件のCはEVM運用により、予定・実績工数を把握できているので、工数ベースで把握できる。
ここで、LycheeRedmineには経費機能があるので、直接コストを円入力することで、原価ベースで保持できる。
この機能により、Redmine上で週次や月次でPJのQCDを報告する運用が可能になる。

今なら、生成AI機能を使って、Redmineのデータを食わせて、報告文章を自動生成すればいい。
LycheeRedmineでは、PJ報告の機能があるので、週次レベルのPJ報告をバッチ出力させて、週次で書かせればいい。

従来は、案件リーダーがExcelやパワポの週次報告をせっせと作って、管理作業が無駄に発生していた。
しかし、LycheeRedmineを使えば、案件リーダーは週次報告作成のような管理作業は必要無くなる。

Redmine上のチケットが正しい状態であれば、週次PJ報告は精度の高い内容になり、単に案件リーダーだけでなく、マネジメント層や経営層に報告して意思決定する情報を提供できる状態になる。
これこそが本来の組織が持つプロジェクトマネジメント能力を測る指標になるだろう。

ただし、LycheeRedmineのPJ報告機能はビジネスプランでしか提供されておらず、一般に使われるプレミアムプランには入っていない。
その点だけ注意が必要だ。

【13】レベル7では、多種多様なプロジェクトへテーラリングできる状態にある。
たとえば、ScrumやCCPMが相当するだろう。
つまり、Redmineによるチケット駆動開発やWF型開発プロセスだけでなく、他のプロセスを主体的に選択できる状態にあるわけだ。
LycheeRedmineにはCCPM、Scrumに特化した機能が用意されている。
CCPMは、製造業の経営層が大好きなマネジメント理論なので、やりたければ、運用ルールを指定してCCPM機能と使えばいい。
Scrumも、NeoバックログやNeoかんばんの機能を使えば、よりアジャイル開発に即したプロセスで運用できるだろう。

しかも、Redmineには複数プロジェクト機能が標準で実装済みなので、CCPMの案件やScrumの案件を、従来のWF型開発案件と併存して運用するのが非常に簡単だ。
CCPMやScrumの運用ルールと、Redmineに即した機能の運用ルールを事前に検討できていれば、個人的にはそんなにハードルは高くないと考えている。

【14】以上が、Redmine利用成熟度による運用戦略のアイデアだ。
Redmine利用成熟度のレベルに応じて、SEPGが目指すべきゴールを定めて、現在地とのギャップをどのように解決していくか、を個別に撃破していく。
そんな戦略を考えるのに、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連発で話してきた。

プロセスには「学習のループ」が必要だ

スクラムやリーンスタートアップにあって、従来型の開発プロセスに欠けている決定的な違いがある。
それは意図的に仕組まれた「ある構造」だ。
人とチームが失敗や成功から自ら学習し、確実に成長し続けるための仕掛けとは何なのか？

【参考】
Xユーザーのakipiiさん: 「RT @hiro_gamo: イーロン・マスク氏も「興味深い」と言及していたMicrosoftのCEOサティア・ナデラ氏の発言を補足を入れつつ和訳しました。昨今ループエンジニアリングなどの言葉も叫ばれていますが、過去に製造業で一世を風靡した「カイゼン」、似た発想をビッグデータの…」 / X

Amazon.co.jp: Clean Agile 基本に立ち戻れ : Robert C.Martin, 角 征典, 角谷 信太郎: 本

More Effective Agile ~“ソフトウェアリーダー"になるための28の道標 | Steve McConnell, 長沢 智治(監訳), クイープ |本 | 通販 | Amazon

アジャイルな見積りと計画づくり

【1】ナデラは、AIと人間の間の相互作用プロセスの中に、人間による学習というフェーズを故意に入れて、プロセスをループ化し、人間が成長させるプロセスへ故意に変化させた。

全てのプロセスは、故意にループを作る必要があるのではないか？

たとえば、Scrumも、PBL作成→スプリント計画作成→デイリースクラム→スプリントデモ→スプリントレビュー→スプリントレトロスペクティブ。
チケット駆動開発も、ロードマップ作成→スプリント計画作成→チケット登録更新完了→バージョン完了→ふりかえり。
リーンスタートアップも、Build→Measure→Lean。

【2】なぜ、ループ構造を持つプロセスが必要なのか？
ループするプロセスには学習するチャンスが埋め込まれていて、それを経て人もチームも成長するからだ。

たとえば、WF型開発プロセスではPJ終了するとそれでお終い。
ふりかえりもしない。
だから改善しない。
学習しないからその場限りで終わる。

しかし、Scrumもチケット駆動開発もリーンスタートアップも、チームがふりかえり学習する機会がある。
学習するからこそ、次フェーズで対策案を実行して改善を試みる。
失敗した経験、成功した経験をその場限りで終わらせない工夫がプロセスに埋め込まれている。

つまり、学習により、人もチームも成長する。
そういう機会をプロセスに故意に埋め込むことが必要だ。

JTCの壁を壊す「Redmine参謀本部」という戦略～現場の職人気質を活かす組織論

redmine.tokyoでのJTCとの対話から見えたのは、硬直化した管理と現場の職人気質のジレンマだ。
激変する製造業に今こそアジャイルが必要である。
マイクロマネジメントを脱し組織力を高める鍵、それを提供する「Redmine参謀本部（AMET）」という新たな運用戦略を紐解く。

【参考】
アドレナリンジャンキー プロジェクトの現在と未来を映す

Amazon.co.jp: 組織パターン (Object Oriented SELECTION) : James O.Coplien, Neil B.Harrison, 和智 右桂: 本

エンジニアリングマネージャーのしごと

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

【1】前回のredmine.tokyo勉強会の休憩時間で、いわゆるJTCの人達と色々話し込んだ。
やっぱり愚痴が多くなる。
せっかくRedmineと環境を用意しても、社員がなかなか使ってくれない。
標準プロセスや標準ワークフローで縛ると、不満が多くなる。
一方、JTC内部で各PJにRedmine環境をホスティングすると、開発プロセスが乱立し、Redmineのバージョンアップも難しくなる。

【2】製造業では、マスタスケジュールに基づく工程管理が基本だ。
つまり、ガントチャート画面で予実管理したい。

しかし、現代では製造業と言えども、ホルムズ海峡の石油不足、半導体不足、サプライチェーン激変などの外部環境変化により、当初立てた計画通りに進捗管理もままならない。
しかも、顧客からの仕様変更、注文も頻繁に起きているので、製造リードタイムが長い製造業ほど、顧客満足させるために凄く苦労する。
つまり、量産品であれ、特注品の製造業であれ、いずれもアジャイル開発が必要とされている。

【3】一方、日本のSIerでは、プロジェクトマネージャやプロジェクトリーダーのような手配師が重宝される。
しかし、やっぱり日本人の気質は職人だ。
だから、プログラマとしてエンジニアとして、技術を磨く方が好きな人が凄く多い。
エンジニアであれば、やはりアジャイル開発がしたい。
でも、マネージャやリーダーは、マイクロマネジメントしたがるので、どうしても衝突しがちになる。

【4】このような状況は、製造業でも同じだ。
製造業でもマネージャのようなマネジメント能力の優れた人が重宝されるが、ほとんどの真面目な社員はエンジニア気質だ。
製造業なので、メカ・エレキ・ソフトのいずれかの技術に長けた人が多い。
彼らはマネジメントなんかよりも、技術を磨きたい気持ちが強い。

【5】そんなマネジメント環境において、Redmineをどのように利用して、組織のマネジメント能力をどこまで目指すべきなのか？
Redmineをマイクロマネジメントのツールではなく、個人の能力を活かし、チームとして一体感を醸成し、組織のマネジメント能力を上げるには、何が必要なのか？

直感的には、Redmine参謀本部が必要だ。
いわゆるRedmine運用事務局、Redmine運用推進部をもっとかっこよく言った部署が、Redimne参謀本部だ。

Redmine参謀本部の役割は、Redmine運用の戦略を策定し、高性能なサーバや開発能力を調達し、JTC内部に展開するための組織体制を整備して、推進していくことだ。
つまり、参謀本部であるから、軍事戦略の策定、兵站というロジスティックスやリソース調達、そして、将校や兵隊の教育訓練の役割を担う。

Redmine参謀本部が協力に動くからこそ、JTCという古い組織であっても、それなりにRedmineを運用し活用できる。

【6】Redmine参謀本部は、「アーキテクチャモダナイゼーション」に出てくる「AMET（Architecture Modernization Enabling Team）」に似ている。
各プロジェクトを技術的にもマネジメント的にも支援する役割だからだ。

Redmine参謀本部という考え方を使って、JTCにおけるRedmine運用の戦略をどのように立てるべきなのか？を考えていきたい。
まずJTCでは、Redmine参謀本部を作れ！

PM理論で読み解く日本人リーダーの弱点

多くの日本人リーダーは、管理しすぎるか放置するかの両極端に陥りがちだ。
その背景には、日本特有の組織文化と育成環境がある。
PM理論とアジャイルの視点から、これからのソフトマネジメントスキルを考える。

【1】組織論の中で、日本人が生み出した唯一の理論がある。
それが三隅二不二のPM理論だろう。
リーダーシップ論に当たる。
定量的に集めたデータを下に統計処理して生み出した社会学の理論だったからこそ欧米でも受け入れられたのだろう。

PM理論｜グロービス経営大学院 創造と変革のMBA

【2】PM理論が教えるところでは、リーダーシップの傾向には2つある。
タスク志向とメンテナンス志向。
タスク志向は業績重視、仕事重視、成果重視。
メンテナンス志向は、人間関係志向、チームワーク志向。

PM理論はもはや古典的であって、現代では使えない代物と思っていた。
しかし、実は、PM理論は、チームビルディングにおいてリーダーがリーダーシップを発揮する時に使えるのではないか？

その理由や経緯を書いてみる。

ＤＸ時代の部下マネジメント―「管理」からサーバントリーダーシップへの転換 | ロッシェル・カップ |本 | 通販 | Amazon

ソフト・マネジメントスキル: こころをつかむ部下指導法 | ロッシェル カップ, Kopp,Rochelle |本 | 通販 | Amazon

【3】ファシリテーション協会のイベントで、チーム運営のワークショップがあった。
チーム運営では、リーダーは上司であるマネージャの指揮命令系統の配下にあり、メンバーに対して指揮命令できる権限を持つ。
つまり、リーダーはまさに中間管理職に当たる。
そういう指揮命令系統の前提で、あるアウトプットを出す。

では、リーダーはどのようなリーダーシップを発揮して、チーム運営すべきなのか？

ほとんどの日本人はリーダーシップ経験が非常に少ないので、たぶん、両極端になりがち。
つまり、メンバーに細かく指示して管理したがるマイクロマネジメントのタイプ。
または、和を重視して、メンバー内でいざこざを起こさないように事勿れ主義になり、何も指示しない自由放任のタイプ。

マイクロマネジメントのリーダーは、タスク志向だけでメンテナンス志向がない。
メンバーに配慮せず、成果重視、業績重視だけでメンバーに指示する。
資本主義社会で営利企業に勤めている限り、売上重視、利益重視になりがちなので、そういうタイプのリーダーは多いだろう。
日本では、終身雇用や社会保険のためにそういう風習がまだ残っているかもしれない。
しかし、メンバーは口うるさい上司に従っているだけで、心の中では反発しているだろう。
メンバーを配慮するメンテナンス志向が欠落している。

一方、自由放任のリーダーは、マイクロマネジメントに反発しているせいなのか、メンバーに何もしない。
最低限の指示だけであって、助言やフィードバックもない。
すると、メンバーは好き勝手に振る舞うことになる。
メンバーは遅刻しても、勤務中に新聞を読んでも、居眠りしても怒られない。
結果的に、チームとして意味をなさなくなる。
つまり、名ばかりのメンテナンス志向だけであって、タスク志向が欠落している。

よって、PM理論は、タスク志向とメンテナンス志向の両方のスキルが必要だ、と示唆している。

【4】なぜ、日本人のリーダーは両極端になりがちなのか？

ソフト・マネジメントスキル: こころをつかむ部下指導法 | ロッシェル カップを読んでその理由が分かったような気がした。

ソフト・マネジメントスキル: こころをつかむ部下指導法 | ロッシェル カップによれば、日本人は子供の頃から、集団のしつけが厳しい環境で育てられる。
アメよりもムチが多い。
すると自分がムチで育てられてきたので、自分が指導者になっても同様に部下を罰してしまう指導しかできない。

日本人マネージャのマネジメントスタイルは、部下をマイクロマネジメントするか、部下を放置するか、どちらかの両極端になりがち。
その原因は、最初の上司にそのように扱われたために、マイクロマネジメントの方法しか知らないのか、逆にそのマイクロマネジメントスタイルに反発して、何もしない放置プレーに走ってしまうのではないか。

つまり、日本人マネージャは人間関係を通じて部下の行動を変化させるソフトマネジメントスキルを教わった経験もないし、受けた経験もない。
そういうソフトマネジメントスキルがある人も稀にいるが、多分、最初の上司が優れた人だったか、自分自身にソフトマネジメントスキルの素養があったのか、どちらかに限定されるだろう。

採用基準 地頭より論理的思考力より大切なもの | 伊賀泰代でも、日本人にはリーダーシップの能力が決定的に欠けているという指摘があったのを思い出す。

「採用基準」の感想～日本の根本問題はリーダーシップの総量が不足していること: プログラマの思索

現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ: プログラマの思索

また、日本人の組織は上限関係が強すぎる。
先輩後輩、年長年下、の上限関係は、言葉遣いを見ればすぐに分かる。
日本人は、目上の人に敬意を示す行動は多いが、目下の人、目上でない人へのコミュニケーションが下手だ。

日本人は以心伝心に頼りすぎだ。
腹芸、阿吽の呼吸。

今まで同じ背景を持つ人の組織に慣れすぎている。
だから、フィードバックというソフトマネジメントスキルを通じて、部下を影響させる技術を持っていない。

【5】米国では人事制度や評価制度を整備して、能力がある人には報酬を増やす制度を充実させて、労働者にアメを与える仕組みを整えてきた。
他方、日本では、能力評価制度や実力主義の人事制度は、リストラや賃金カットの手段として否定的に捉えられている。
つまり、日本人は会社の人事制度や評価制度を根本的に信用していない。
その背景には、彼らが上司から粗雑に扱われてきた経緯があるし、会社も内発的動機に働きかける制度作りやその運用方法を知らないし実践できていないからだ。

日本企業は今まで、年功序列に従う賃金報酬、長期雇用の人事制度に頼って、社員を管理してきたと言われる。
でも、僕は、年功序列、長期雇用の保証という組織人事制度は、嘘だろうといつも思っている。
たぶん年功序列の長期雇用の保証制度は、昭和の世代までであって、今までの会社で見たことがない。
年功序列で長期雇用を保証されているから、社員を大切にし、福利厚生を充実させて、社員教育も充実させてきた、と多数の本で言われてきたが、実際の現場で見たことがない。
実際、日本人の大半は中小企業に所属していて、公務員や大企業のような恵まれた環境で働いているわけではない。
たぶん、かなり大手の大企業で羽振りの良い環境に限られていると思う。

日本企業は、年功序列や長期雇用の保証により、社員の忠誠心を保ってきて、それに依存したマネジメントをやってきた。
日本企業は従来のやり方に甘えて、マネジメントスタイルを時代に合わせて変えていく作業を怠ってきた。

しかし、社員が会社への忠誠心を持たなくなった場合、どうやって管理するのか、そのスキルを持っていないだろう。
ソフト・マネジメントスキル: こころをつかむ部下指導法 | ロッシェル カップでは、堺屋太一さんが「米国企業は忠誠心を持っていない会社員を管理する技術を持っているが、日本企業は持っていない。そこで破綻するかもしれない」と言っていたらしい。

実際、日本企業の従業員エンゲージメント調査では、エンゲージメント率が世界的に低いとよく言われる。
たぶんその理由は、日本人マネージャのソフトマネジメントスキルが決定的に欠落していて管理能力が低いこと、日本企業の人事評価制度が従業員の内発的動機に働きかける仕組みや運用になっておらず形骸化していること、があるだろうと思っている。
賃金カットやリストラのための仕組みだと思っているわけだ。
つまり、時代の環境変化に日本企業が追随できていない。
これだけ多様な環境が必要になり、外部環境が激変しているのに、マネジメントスタイルも人事評価制度も日本人に根付いていないわけだ。

【6】僕もそんなチグハグな環境で働いてきた。
IT業界にいる他の人達も同様に悩みながら働いているだろう。

そんな状況の中、IT業界ではアジャイル開発がソフトマネジメントスキルを身につけるのに役立つ技術として認知されているだろうと僕は思っている。
たとえば、Scrumは開発プロセスのフレームワークである一面、スクラムマスターがチームメンバーの内発的動機に働きかけて自律的な行動を促す仕組みを作りだす。
さらに、チームやメンバーを影響させるソフトマネジメントスキルがふんだんに盛り込まれている。
Scrumのコミュニティでは、そういうプラクティス、アンチパターン、事例がたくさん公開されているから、誰もが自分に合ったソフトマネジメントスキルを習得できる環境があると思う。

他にも、日本独特のマネジメントスタイルとして、プロジェクトファシリテーションが20年以上前に提唱されていた。
WF型開発が主流でガチガチな環境の中、日本人マネージャがソフトマネジメントスキルを身につけるためのプラクティス集として公開されていた。
これもそういう流れの一環として捉えることができる。

プロジェクトファシリテーションはIT企業の中間管理職研修みたいだ: プログラマの思索

すなわち、IT業界では、アジャイル開発はソフトウェア開発の単なる一技術ではなく、管理職層のソフトマネジメントスキル習得の一技術として捉えることができると思う。
だからこそ、日本でもアジャイル開発がこれだけ注目されている。
だからこそ、コミュニティで活発にアジャイル開発のノウハウが皆で共有されている。

たぶん、日本人の我々も薄々知っているのだ。
今までのマイクロマネジメントスタイルではやっていけないからこそ、ソフトマネジメントスキルの習得が必要だ、ということを。

【7】では、日本人が身につけるべきソフトマネジメントスキルとは何なのか？

ファシリテーションの本をたくさん漁って読んだ後に改めて、ソフト・マネジメントスキル: こころをつかむ部下指導法 | ロッシェル カップを読み直して気づいたことがある。
身につけるべきソフトマネジメントスキルは、たとえば、コーチング、カウンセリング、ネガティブ・フィードバック、ポジティブ・フィードバックなどがある。

それらソフトマネジメントスキルは、タスク志向のスキルとメンテナンス志向のスキルで分類できる。
タスク志向のスキルは、コーチング、カウンセリングのように、目標達成しようとするメンバーを助言・支援したり、悩みを持つメンバーに対して、求められる仕事の水準や基準を提示して動機づけして成果を出させる。
つまり、モチベーションが高いがスキルが低いメンバーにはアドバイスして後押しして成果を引き出したり、モチベーションの低いメンバーには動機づけして、低レベルの状態から、普通に力を発揮できるレベルへ元に戻し、普通の成果を出させるように助言する。

一方、メンテナンス志向のスキルは、ネガティブ・フィードバック、ポジティブ・フィードバックのように、メンバーの行動に対し問題点や改善点を指摘して是正処置を行ったり、メンバーが良い行動をすれば感謝の気持ちを伝えたりして望ましい行動を促進させる。

そういうソフトマネジメントスキルがリーダーに求められるわけだ。
そういうスキルを言語化して、人を動かすヒューマンスキルが身につけられるわけだ。
たぶん日本人にはそういうソフトマネジメントスキルが足りないと言われているのだろうと思う。

リプレースとアーキテクチャモダナイゼーシヨンの違いの本質は何なのか？

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読み始めて、色々考えたことをメモ。

【参考】
アーキテクチャモダナイゼーション 組織とビジネスの未来を設計する | Nick Tune, Jean-Georges Perrin, 元内 柊也, 岩﨑 勇生, 角谷 太雅 |本 | 通販 | Amazon

More Joel on Software | Joel Spolsky, 青木 靖 |本 | 通販 | Amazon

アーキテクチャモダナイゼーションとはそもそも何なのか？: プログラマの思索

アーキテクチャモダナイゼーションにおけるAMETチームの役割と責任範囲は何か: プログラマの思索

システムのリプレース案件が最も危険な理由: プログラマの思索

【1】リプレースとアーキテクチャモダナイゼーシヨンの違いの本質は何なのか？
まだ違いが分からない。
アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するでは何を語ってくれているのか？

【2】リプレース案件はIT業界の人なら誰でも経験するデスマーチ案件だ。

ユーザや顧客から見れば、既存システムは動いているのだから、その機能をそのまま移し替えるだけでしょ。
動く既存システムが仕様そのものだから、見れが分かるでしょ、とユーザは思う。
しかし、リプレース案件を担当すると、どんな技術者も苦労すると思う。

リプレース案件の特徴は３つあると思う。

一つ目は、アーキテクチャの構成要素のバージョン依存関係の難しさ。
インフラ基盤のサーバー、OS、DB、ミドルウェア、プログラミング言語のバージョン違いから出るバージョン組み合わせの品質担保の難しさ。
構成要素のバージョンが１つ違うだけで、すぐにシステムは動かなくなる。

二つ目は、システム移行、データ移行の難しさ。
同じ機能のシステムを単に入れ替えるだけなのに、システム移行、データ移行で必ずトラブル発生。
たとえば、システム移行の障害では、構成要素のバージョン依存関係が原因になるケースが多い。
データ移行の障害では、既存データのボリュームが多すぎて処理時間が想定よりも長くなって業務トラブルが発生したり、既存システムのインフラ基盤やRDBに思わぬ落とし穴が原因のケースが多い。

三つ目は、同じ機能をそのまま入れ替えるだけなのに、現行と新規システムの機能比較テストで必ず差異が出てテストに苦しむ。
ユーザから見れば、なぜ現行システムと新規システムでテスト結果が異なるのか分からない。
しかし、ちょっとした環境の違いによって、プログラムやデータの振る舞いは予期しない結果になりやすい。
テスト計画やテストマネジメントの方がプログラミングよりも大事。

その他にも、業務移行の難しさがある。
古い現行システムは使いにくいUIや既存バグがそのまま残って使いづらい。
よって、ユーザもバグあり前提で業務を運用している。
安易にUI改善や既存バグ修正すると、既存業務も変わってしまう。
リプレースのついでにBPRも行ってしまうと、マニュアル改訂やユーザ説明会みたいな工数も増えてしまい、業務移行コストが想定以上に増えてしまう。

つまり、リプレース案件には新規開発案件や機能改修案件とは異なる特徴がある。

【3】リプレース案件では、テストや移行という後工程の作業にかなりの工数が割かれるケースが多い。
そういう特徴を理解して、アーキテクトやプロジェクトマネージャはリプレース案件のプロジェクト計画を立てる。
特に、テスト計画や移行計画の精度の高さが、リプレース案件の成功度合いに直結するだろう。

【4】では、改めて、リプレースとアーキテクチャモダナイゼーシヨンの違いの本質は何なのか？
NotebookLLMの回答は下記の通り。

既存システムを新規システムへ移行するという点では共通していますが、リプレースとアーキテクチャモダナイゼーションの違いの本質は、その「範囲」「アプローチ」「目的」の3点に集約されます。

1. 範囲の本質：技術刷新か、ソシオテクニカルな刷新か
リプレース：主に古い技術スタックを新しいものへ置き換えるといった、純粋に技術的な側面に焦点が置かれます。
モダナイゼーション：技術だけでなく、人、組織構造、ビジネス戦略、働き方のすべてを深く連携させる**「ソシオテクニカル（社会技術的）」な刷新**です。
組織のコミュニケーション構造がシステム設計に影響を与える「コンウェイの法則」を前提とし、組織とアーキテクチャを共同で最適化します。

2. アプローチの本質：革命（大規模刷新）か、進化か
リプレース：最初に全体を設計してからゼロから新しいコードを書く「ビッグデザイン・アップフロント」が主流であり、既存システムをすべて廃棄して作り直す**「大規模刷新プロジェクト（革命）」**になりがちです。これはしばしば「悪夢」のような困難を伴います。
モダナイゼーション：完成形を最初にすべて定義するのではなく、**「進化的アーキテクチャ」**の考え方を取ります。3～6カ月といった短期間で段階的に価値を提供し、継続的な学習とフィードバックを通じてアーキテクチャとロードマップを改善し続ける「終わりのない旅」と捉えます。

3. 目的の本質：負債の返済か、資産の再構築か
リプレース：既存の機能をそのまま新しい環境へ移植する「リバースエンジニアリング」に終始しやすく、古いシステムの欠陥や不要な複雑さを引き継いでしまうリスクがあります。
モダナイゼーション：単なる「負債の返済」ではなく、「資産の再構築」競争優位性のある資産へと転換し、高速なフロー（迅速かつ安全なデリバリー）を実現することを目指します。
結論として、両者の違いは**「システムを新しくするだけでなく、変化に適応し続ける組織能力そのものをアップデートしようとしているか」**という点にあります。

【5】NotebookLLMの回答を読む限り、アーキテクチャモダナイゼーシヨンには下記の観点があるらしい。
・技術視点よりも、組織戦略や経営戦略の観点で組織とアーキテクチャ最適化を重視
・「大規模刷新プロジェクト（革命）：よりも、「進化的アーキテクチャ」を重視
・「リバースエンジニアリング」という単なる「負債の返済」よりも「資産の再構築」を重視

この観点が、リプレース案件の特徴から発生する諸問題、特に移行やテストの難しさをどのように解決してくれるのか？
まだ理解できていないので、じっくり考えてみたい。

PMPとCSM取得者数推移（日本 vs 中国）から読み取れる指針は何か？

PMPとCSM取得者数推移（日本 vs 中国）を調べて、色々考えたことをメモ。

【参考】
アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント | 平鍋 健児, 野中 郁次郎, 及部 敬雄 |本 | 通販 | Amazon

SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発 | 西村 直人, 永瀬 美穂, 吉羽 龍太郎 |本 | 通販 | Amazon

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection) : Kenneth S.Rubin, 岡澤 裕二: 本

スクラム実践者が知るべき97のこと | Gunther Verheyen, 吉羽龍太郎, 原田騎郎 |本 | 通販 | Amazon

PM教科書 PMP完全攻略テキスト PMBOKガイド第7版対応 改訂版 (EXAMPRESS) | 鈴木 安而, PMアソシエイツ株式会社, 株式会社NTTデータユニバーシティ |本 | 通販 | Amazon

図解即戦力　PMBOK第7版の知識と手法がこれ1冊でしっかりわかる教科書 | 前? 和哉 |本 | 通販 | Amazon

【0】Gemimiに、PMPとCSM取得者数推移（日本 vs 中国）を調査させてみた。
結果は圧倒的に、中国人の方が取得者数が多いだけでなく、認定スクラムマスターは4倍、PMPに至っては10倍以上の差があった。

【1】Gemimiより：PMP（Project Management Professional）の日本および中国における取得者数について、PMI（Project Management Institute）の公開データ（Fact File）や年次報告書に基づき、2010年から2025年（最新予測・公開値）までの推移をまとめました。

中国は2010年代半ばから爆発的に取得者が増加し、現在は米国に次ぐ世界第2位の市場となっています。一方、日本は安定した増加傾向にありますが、その成長スピードには大きな差が出ています。

【PMP取得者数推移（日本 vs 中国）】
※2025年は最新の公開統計および市場動向に基づく推定値、その他はPMI公式データに基づきます。

年度 日本 (Japan) 中国 (China) 備考
2010 約 24,000 約 45,000 中国の伸びが加速し始めた時期
2011 約 26,000 約 55,000
2012 27,841 70,256
2013 29,150 85,000
2014 31,500 110,000 中国が10万人を突破
2015 33,200 135,000
2016 34,800 150,000
2017 36,400 190,000
2018 37,200 240,000 中国の増加ペースが年5万人規模へ
2019 38,500 300,000
2020 39,200 330,000 パンデミックにより試験休止等の影響
2021 41,000 380,000
2022 42,500 450,000
2023 44,100 520,000
2024 45,649 580,360 中国が日本の10倍以上の規模に
2025 約 47,000 約 630,000 (予測値)

【2】Gemimiより：スクラムマスターの普及は、PMP以上に「アジャイル開発」の浸透速度と比例しています。
日本は2010年代後半から急速に伸びている一方、中国はPMP同様に圧倒的な母数で推移しています。

【CSM取得者数推移（日本 vs 中国）】
※数値はScrum Allianceの年次報告書および公開統計に基づきます。2025年は最新の四半期統計からの予測値です。

年度 日本 (Japan) 中国 (China) 状況の推移
2010 約 250 約 1,200 日本ではごく一部の先進層のみ
2011 約 450 約 2,000
2012 710 3,400
2013 1,020 5,800 日本で1,000人を突破
2014 1,450 8,200
2015 2,100 12,000 中国で1万人を突破
2016 2,800 18,500
2017 3,900 26,000
2018 5,500 35,000 日本でDXの機運が高まり増加加速
2019 7,800 48,000
2020 10,200 55,000 パンデミックによりオンライン研修が普及
2021 13,500 68,000 日本で1万人を突破
2022 17,000 82,000
2023 21,500 98,000
2024 26,800 115,000
2025 約 32,000 約 135,000 (予測値)

【3】PMPとCSM取得者数の比較より、Geminiにも聞きながら、何が読み取れるか？

1つ目は、中国の方が日本よりも、PMPやCSMの取得者数が多い事実より、特にプロジェクトマネジメントが個人のスキルではなく、グローバル競争における「共通言語」として定着していること。
数値の差は、そのままグローバル市場での「交渉力」や「信頼性」に直結する。
つまり、IT業界だけでなく、製造業や建設業、公共事業などの他業界でも、巨大なプロジェクトを統制するための型があり、共通言語もあり、意思決定が速いだろう。

一方、日本国内では「阿吽の呼吸」で成立していたプロジェクトも、グローバル市場では通用しない。
色々な場面で、日本人が太刀打ちできないシーンが増えているのだろう。

日本では、PMPもCSMも会社や国家が強制することもなく、個人の自己研鑽が主に発生源となって資格取得しているだろう。
つまり、中国では組織的な徹底力で取得人数も圧倒的に増やして、それを標準プロセスとして強制的に運用しているのに、日本では資格取得が「個人の自己研鑽」に留まるケースが多く、取得した知識を組織全体のプロセス改善（BPR）にまで昇華させる力が弱い。

すなわち、日本人単独の意思が強くても、その人数は非常に限られていて、「資格＝学習」で止まり、「組織の武器」にならない。

2つ目は、日本では、「マネジメントの二極化」による断絶があること。

日本ではPMPの伸びは緩やかだが、CSM（アジャイル）の伸び率が近年高まっている。
これは、ウォーターフォール型の管理から、より柔軟な開発体制（DX推進）へ急速に舵を切っている過渡期にあることを示唆している。
やはり、日本人のソフトウェア開発者もその問題意識を持っている。

特に、日本でのスクラム普及は、組織の上層部からの命令（トップダウン）ではなく、現場のエンジニアや若手リーダーが「このままでは開発が回らない」と危機感を持って取得し始めるボトムアップ型が多いのが特徴らしい。
実際、僕の周囲でも、開発現場の危機感から認定スクラムマスタを取得するパターンを多く見かけた。
そもそも、日本のSIerはこういう研修にお金を支払わないから。

しかし、日本ではPMP的な「管理層」とCSM的な「現場層」が分断されがち。
経営層は依然としてウォーターフォール型の進捗（ガントチャートやマイルストーン）を求め、現場はアジャイルで動こうとするため、その摩擦で中間管理職であるプロジェクトマネージャが疲弊すうｒ
中国や米国では、管理者がアジャイルを理解した上で「ハイブリッド型」のガバナンスを構築するスピードが速いらしい。
つまり、PMP的な管理層もアジャイルの価値を認識したうえで、PJ全体はWF型であっても、マイルストーン単位に区切ったスプリントではアジャイルに開発するなど、現実に柔軟に対応しているわけだ。

すなわち、日本では、現場の開発者は危機感や自己研鑽を持ちながらも、経営層はそのモチベーションを有効活用できず、ビジネスの環境変化のスピードに追随できていない。

特に、PMPやCSMの取得者数の伸び率（傾き）は、そのまま「ビジネスの意思決定スピード」の代用指標になる。
中国が日本の10倍以上の速さで標準化を進めている間、日本は「どの資格が自社に合うか」の検討に時間をかけすぎて、スピードが遅すぎる。

まあ、結局、組織として推進する力も必要なのだろう。