なぜ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連発で話してきた。

パランティアテクノロジーズの正体とはAI時代のSIerだ

謎多きAI企業パランティアの正体は、オントロジーを駆使して情報の縦割りを壊す「AI時代のSIer」である。
最前線に立つエンジニアが現場を掌握し、新たな軍産複合体を生み出す恐るべきビジネスモデルと、概念データモデルがもたらす技術の核心に迫る。

【参考】
教養としてのパランティア・テクノロジーズ: 世界の意思決定を支える企業の正体 | 宇田川博史 |本 | 通販 | Amazon

【1】パランティアテクノロジーズの社名は知られているが謎に包まれている。
ある人はすごくAIテクノロジーの会社だ、と言っていて、他の人は、監視社会を作り出す悪の会社と言う。
パランティアテクノロジーズに関する分厚い本は読みづらい。
そこで、「教養としての～」ナントカシリーズを読んで、理解した気持ちになりたいと思い、教養としてのパランティア・テクノロジーズ: 世界の意思決定を支える企業の正体を読んでみた。

個人的はすごくよかった。
教養としてのパランティア・テクノロジーズ: 世界の意思決定を支える企業の正体から理解できた点は4つある。

・オントロジーで情報を可視化し理解を促す
・プロダクトは3層構造を持つ
・投資偏重で赤字の財務体質
・技術利用の倫理に説明責任を持たせようとしている

【2】「オントロジーで情報を可視化し理解を促す」とは何か？

パランティアテクノロジーズの社長はドイツの大学の哲学科出身。
理系エンジニアではない。
彼の説明によれば、「社会の攻撃性は、情報のサイロ化から生まれる」
たとえば、国家機関では、縄張り争いのために情報を活用できていない。
オントロジーにより、各機関の収集データを関係性でグラフ化し見える化する。
つまり、政府部門や大企業では、縦割り組織になりがちで情報は共有されず、部門という村だけで通じる方言を生み出す。
方言を理解できる村人たちの村が、排他性を生み出す。

その課題を解決するために、オントロジーを使う。
オントロジーを介することで、誰もが理解し合える環境を用意する。

パランティアテクノロジーズでは、オントロジーを監視ではなく、理解を支援する（拡張知能）ために使う。
パランティアのAI基盤は、人間のアナリストに意思決定するデータを提供するだけ。
人間の理解と洞察を加速する基盤として扱う。
最終的には、人が判断し意思決定する。
なぜならば、全てをAIが判断できないからだ。
やはり、人が持つ暗黙的なコンテキストにより意思決定の質を向上させることに主眼を持つ。
それが拡張知能であるわけだ。

【3】「プロダクトは3層構造を持つ」とは何か？

プロダクトは3層構造を持つ。
具体的にはまず、インフラ層はAppolo。
クラウドからエッジ、オンプレまで環境を問わずSaaSで自動デプロイできる。
次に、コアエンジン層はOntology。
現実世界をデータモデル化する心臓部。
オブジェクト指向モデリングやドメイン駆動設計に現れる概念データモデルに相当するだろう。
最後に、アプリケーション層はGotham、Foundry。
Gothamは政府・軍事向けの意思決定プラットフォーム。
Foundryは民間企業向けのビジネスオペレーションのOS。

オントロジーは多様なデータと人間の間をつなぐ。
ただし、インフラ層のデータ基盤はクラウドとは限らない
潜水艦とかローカルな場所にも配置できるらしい。

【4】投資偏重で赤字の財務体質とは何か？

財務構造はすごく偏っている。
つい最近まで赤字だった。
売上に対し、売上原価23％、販売マーケティング費用35％、研究開発費25%、株式報酬費用50％。
研究開発費や株式報酬費用がなければ、営業利益率は40％を超えるので優良企業。
しかし、エンジニアにストック・オプションを渡す株式報酬費用が突出している。
それくらい投資偏重の企業だった。

パランティアテクノロジーズのビジネスモデルは、BtoGやBtoB向けのコンサル支援、グローバル企業向けのSIerに近い。
Acquireフェーズで、FDEというエンジニアが現場に常駐し、無料でPoC開発して成果を出す。
Expandフェーズで、初期成功を元に適用範囲を隣接部署に次々に拡大し、データ統合の恩恵が広がる。
Scaleフェーズで、政府、企業全体を動かすOSとなり、大規模契約につながり、最終的にはベンダロックインされる。

つまり、伴走型支援なので、コンサル支援に近い印象を持った。

また、ロックオンされると、継続利用になるビジネスモデル。
実際、オントロジー基盤が一度構成されると、それを手放すことは不可能に近い。

また、日本のSIerのように、顧客に張り付き、御用聞きとなって、顧客に入り込むビジネス。
実際、FDEは客先常駐なのでSESに似ている。

【5】技術利用の倫理に説明責任を持たせようとしている仕組みは何か？

技術的なガードレールがある。
強力なアクセス権限や監査ログ。

FDEが倫理の番人になる。
FDEが顧客成功と倫理的利用のインセンティブを一致させる。

社長自ら説明責任を持つ。
オントロジー技術の利用に関して逃げずに、積極的に説明責任を果たそうとしている。
しかし、これだけで監視社会への対応に十分なのか？という疑問は残る。

【6】上記説明後に議論した内容が面白かった。

エンジニアへのインセンティブのストックオプションで大赤字になっている理由は、たぶん節税対策ではないか？
減価償却費みたいなものだろう。

また、FDEはSESみたいな環境にいるのであれば、モチベーションが高くなければやってやれない。
だから、ストック・オプションで巨額の報酬を約束して動機づけする必要がある。
FDEは派遣エンジニアではなく、戦場に飛び込む兵卒みたいな人だ。
弱々しいエンジニアではなく、ムキムキのソルジャータイプのエンジニアのイメージだ。

FDEは前線に立ってヒアリングしPoC開発するので、成果が出たら契約して先に進めるというような感じだろう。
エンジニアがコンサルのような感じのように思えた。

パランティアテクノロジーズのビジネスモデルは伴走型モデルと聞こえは良いが、クライアントとずぶずぶの関係になる。
昔の日本の企業みたいに寝技が得意。

エンジニアは能動的に動いていくタイプ。
俺たちがクライアントを支配してやるというタイプ。
オントロジーに埋め込む業務データを得るために、入り込んだ現場との関係性が重要になるが、社員にとってはメリットはないのでピリピリしてるだろう。
オントロジーに業務ノウハウや暗黙知が取り込まれると、社員は不要になるからだ。

オントロジーは概念データモデルそのものだ。
エンタープライズアーキテクチャを作るプロセスそのものだ。
今ならば、RAGのおばけみたいな感じだろう。
各拠点に散らばっている暗黙知を集約してオントロジーという形式知にできる点はメリットが大きい。
データのアクセス権を確保して、RAGに全てぶち込むところをやっている点がすごい。
FDEはかなりの政治力を持つコンサルだ。

パランティアテクノロジーズのビジネスモデルの強みは、他企業が模倣できない仕組みだ。
スイッチングコストが非常に高い。
ベンダーロックインで寝技に持ち込むイメージ。
パランティアテクノロジーズは、AI時代のSIerみたいだ。
しかし、SIerという言葉は日本でしか通じないはず。
日本人にはノスタルジックな風景だが、アメリカでは新しいのかもしれない。

パランティアテクノロジーズは、技術ガードレール、倫理という組織文化で守られていると言う。
しかし全データはパランティアに握られている。
この仕組みは、新しい軍産複合体だ。
つまり、BtoGビジネスで政府の全データ、BtoBで企業の全データをパランティアテクノロジーズが握っているので、軍産複合体みたいな会社になっている。
換言すれば、一民間企業に過ぎないので、危険な存在でもあるわけだ。

【7】個人的には、概念データモデルがオントロジーという発想で実装基盤になり、今のAI時代ではより簡単に作れて、強力なデータ基盤になる点が面白かった。

「部門ごとの情報のサイロ化を防ぐ」基盤としてオントロジーを使う発想は昔のエンタープライズアーキテクチャと同じだ。
その設計思想が先祖返りしながらも、AIによって実装方法が簡単になり更に価値を増している点が面白い。
このあたりの情報も追いかけていく。

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

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

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

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

組織変革の鍵を「聞く」体験から探る

組織やチームに変化をもたらすリーダーシップを模索中。
ファシリテーションの「聞く」ワークショップに参加し、相手を論理的に分類する自身の癖に気付くと共に、ただ話を聞いてもらうことの「癒やし」を実感した。
クライアントの現場を活気づけ、変革を起こすヒントはどこにあるのか。

【参考】
ファシリテーションの教科書

問いのデザイン: 創造的対話のファシリテーション

「具体　抽象」トレーニング 思考力が飛躍的にアップする29問 (PHPビジネス新書) | 細谷 功 |本 | 通販 | Amazon

PMOはスクラムマスターである: プログラマの思索

PM理論で読み解く日本人リーダーの弱点: プログラマの思索

管理職に求められる能力はPM理論そのものではなかったのか: プログラマの思索

「チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ」の感想: プログラマの思索

【1】最近、ファシリテーションに興味を持っている。
システム設計、プロジェクト管理のやり方は今まで随分考えてきた。
あるべき論も自分の中では何かしら持っている。
しかし、自分から他人、チーム、組織に働きかけて、変化をもたらし、自分が理想と掲げるゴールに彼らを追随させる必要が出てくるのに、そのやり方がわからない。
まさにリーダーシップ論なわけだが、そのヒントを探したくて、色々探ってる。

【2】昨日、ファシリテーションのワークショップに出てきた。
聞く行為を3パターンに分けて経験してみようというワークショップ。

僕が聞き手、相手の女性が話し手では、いきなり、アドバイザーから、あきぴーさんはいきなり思考範囲を絞るような質問をしてきましたね、もっとオープンクエスチョンであれば相手が話しやすかったのでは？というフィードバックをもらった。
たぶん僕は、相手が考えているテーマ、意見、問題意識を構造化したいために、探るような質問、推測を絡めて質問をしてしまう癖がある。
その態度が行き過ぎると、あきぴーさんは人をカテゴライズしすぎですよ、バイアスかかってますよ、と言われる。

30年以上前の話だが、後輩の女の子にも、あきぴーさんは数学者かもしれないけど、人のタイプを分類するのは嫌われますよ、と同じように言われた経験があった。
数学者、自然科学者は、論理対象や自然現象をある観点、ある特性に基づいて整理するために、カテゴライズするのは当たり前にやる。
これを人間に対して実施すると、相手は反発する。
自分はそれだけの側面ではないよ、と。
このギャップにいつも悩んでたが、なるほどね、と気付きはあった。

【3】他方、僕が話し手で聞き手の女性のパターンでは、僕が一方的に話しまくり、相手の方があまり質問せず頷いてくれるだけなのだが、「癒された」という感情が沸き起こった。
僕が奥さんに話している時も、こんな感覚だった。

たぶん、僕が考えている、PMOのあるべき論、チケット駆動開発のあるべき論、製造業のアーキテクチャのあるべき論とか、相手の女性も、ましてや奥さんもちゃんと理解できていないだろう。
しかし、聞いてくれるだけで「癒された」感覚があった。
時々、こういう感覚を求めたくなる時がある。

ドジャーズの佐々木投手が大リーグ挑戦で海を渡った時、ちょうど結婚したニュースが流れた時があった。
たぶん、彼も同様の気持ちを持っていたのかもしれない。

【4】今の僕は、クライアントの現場で人・チーム・組織に変化をもたらせて活気を起こすには何が必要なのか？をずっと探っている。
そのヒントがどこかにないか、仕事でも、コミュニティでも、そしてファシリテーションでも探し続けている。

自動車・半導体・防衛産業から読み解く、業界を制する設計思想

SIerから製造業に飛び込み見えてきたのは、業務を根本から支配する設計アーキテクチャの存在だ。
自動車のECU、半導体の巨大サプライチェーン、防衛産業のキルチェーン。
これら業界を制する概念を紐解き、アーキテクチャ主導による製品開発の重要性と本質を考えてみる。

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

アジャイルサムライ　達人開発者への道 | Jonathan Rasmusson, 西村 直人, 角谷 信太郎, 近藤 修平, 角掛 拓未 |本 | 通販 | Amazon

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで | 市谷 聡啓, 新井 剛 |本 | 通販 | Amazon

作る、試す、正す。　アジャイルなモノづくりのための全体戦略 | 市谷 聡啓 |本 | 通販 | Amazon

【1】SIerで長年働いてきて、製造業に入ってみると、彼らの業務を支配する設計アーキテクチャを知りたくなってくる。
製造業のそれぞれの業界で使われる製品固有の前提、制約条件を元に、彼らはどんなルールに支配されているのか？

【2】たとえば、自動車ならば、ECUのアーキテクチャになるだろう。

（Gemini翻訳）
車ECU（Electronic Control Unit）は、自動車のエンジン、ブレーキ、エアバッグなど様々なシステムを電子的に制御する「車載小型コンピューター」です。センサーから得たデータをもとに最適な動作を計算し、1台の車に約100個搭載されることもあります。現代の車には不可欠な「頭脳」です。
ECUの主な特徴と役割
役割（自動車の「頭脳」）: エンジンの燃料噴射・点火制御、ブレーキ（ABS）、パワーステアリング、車線維持支援など、安全・快適・性能を包括的に管理します。
構成: マイクロコントローラ、メモリー（ROM/RAM）、入出力インターフェースで構成され、厳しい耐熱・耐振動設計が施されています。
連携: 車載ネットワーク（CAN）を介して、それぞれのECUが連携して動作します。
種類: エンジン系、シャシー系、ボディ系（ライト、ドア）、情報系（ナビ）など、機能ごとに分散しているほか、これらを統合する「統合ECU」の採用も進んでいます。
近年は、自動運転や電動化の進展に伴い、より高度な処理能力を持つECUの重要性が高まっています。

では、ECUを支配するアーキテクチャにはどんな種類があるのか？

（Gemini翻訳）
自動車の脳にあたる「コンピューター（ECU）」の配置ルールは、進化とともに3段階あります。
・ドメイン型：役割ごとのチーム制。「走る」「止まる」など機能別に脳を分ける方式です。機能が増えるほど配線が複雑になり、車が重くなるのが弱点です。
・ゾーン型：場所ごとのエリア制。「右前」「後ろ」など車の場所で脳をまとめます。近くの部品を最短の配線でつなぐため、線を劇的に減らして軽量化できます。
・セントラル型：一極集中制。車の中央に超高性能な「1つの脳」を置き、全てを指揮します。スマホのようにソフトの更新だけで車の性能を後から進化させやすくなります。
現在は、配線を減らしつつ高度な制御を行うため、2と3を組み合わせた形が主流になりつつあります。

最近では、自動運転（AD）や走行制御（ADAS）が全てのECUを指示・制御する必要があるために、ADやADASの機能を持つ統合ECUが必須となるセントラル型アーキテクチャが主流になっていると思う。
ハード面でもソフト面でもアーキテクチャ設計が以前よりも遥かに重要な印象だ。

昔は、トヨタやホンダが「ハードの部品のすり合わせ」により1つの自動車を作っていた印象。
しかし、今は、SDVという「車のAPI化やOTAでソフトウェアによるハード制御などの実装に近い設計手法」になったために、20～50個ものECUを結合して、性能、品質、セキュリティなどを担保するのは、昔ながらの「すり合わせ」では実現不可能。

「すり合わせ」という複数チームのコミュニケーション活動による解決ではなく、ハード面でもソフト面でも「アーキテクチャにより自動車の構造をすり合わせる」へ時代が変わったと考える。
だから、MBSEのような「アーキテクチャ主導の製品開発」が重要になってきたと考える。
※OTA＝いわゆるスマホのソフトウェアアップデート機能みたいなもの。自動車用語特有。

自動車の組込ソフトウェア開発が難しい理由は、3つあると思う。

１・ECUというハードとソフト双方を結合した部品を作った後に、さらに複数のECUを統合して初めて1台の自動車が完成するので、結合・統合テストで非常に苦労する。

２・自動運転（AD）や走行制御（ADAS）のように、全てのECUに指示制御する統合ECUが初めて出現したために、従来のハード中心のゾーンアーキテクチャからソフトウェア主導のアーキテクチャに変わったので、ソフトウェア開発力が弱いメーカーは非常に苦しい。

３・A-SPICE、機能安全、サイバーセキュリティのような監査プロセスを踏んで品質担保を保証する必要があるので、ソフトウェア開発チームはソフトウェア開発だけでなく、監査ドキュメント作成の作業負荷も増えている。これらの規格をOEMメーカーがTier1の部品メーカーに要求するため、開発現場はいつも人手不足で作業が大変な印象。

自動車のアーキテクチャ設計で面白い点は、分散アーキテクチャから集中型アーキテクチャへ移り変わってる流れであり、マイクロサービス設計の発想とは異なる点だ。
理由は、自動運転機能が自動車の全ての機能に関わるので、集中型アーキテクチャでオーケストレーションせざるを得ない。

残念ながら、日本のOEMメーカーは、この流れに全く沿っていない。
中国メーカーとテスラに負けていると言えるだろう。

【3】一方、たとえば、半導体ならば、どんな設計アーキテクチャが重要なのか？

半導体の製造工程は、高度に専門化されて細分化されていて、巨大なサプライチェーンと化している。
もはや1社で全ての工程をカバーできる代物ではない。
最先端の半導体技術、ナノレベルの微細加工や洗浄の製造技術、超高純度の素材を必要としている。
半導体製造工場を1つ建てるだけでも数兆円掛かるのではないか。

半導体の製造工程では、高度に専門化された製造装置や超高純度の素材が使われる。
それら製造装置、素材を製造するメーカーは、各工程で5社未満に限られる。
日本なら、東京エレクトロン、スクリーン、信越化学などがあるだろう。
一般に、半導体製造において、最も重要とされる「露光（リソグラフィ）工程」を担い、圧倒的な市場シェアを誇るオランダの企業はASMLだろう。
ASMLが製造するEUV露光装置は1台あたり数百億円にのぼる超高額機器。
究極の、すり合わせ技術の塊。
ASMLだけで、半導体製造工程の付加価値の半分くらい占めているのではないか。

彼らのお客はTSMCやサムスン、インテルなどの巨大ファウンドリー。
彼らがどんどん積極投資するから膨大な売上になる。
だからこそ、今は、半導体に絡む株式投資をしたら、すぐに億万長者になれるだろう。

半導体製造工程のサプライチェーンを知り尽くすことが、半導体業界を理解できる鍵になる。
すべての技術、設計はサプライチェーンの細分化された工程に深く埋め込まれているからだ。

【4】では、防衛産業において、重要な設計思想、アーキテクチャ設計の思想は何だろうか？

重要なアーキテクチャ設計の思想は「Kill Chain」になるだろう。

防衛産業や軍事用語における「キルチェーン」とは、標的の発見から攻撃の実行、そしてその効果の判定に至るまでの一連の軍事プロセスを「チェーン（鎖）」に見立てた概念だ。
キルチェーンは一般的に「F2T2EA」と呼ばれる6つの段階で構成される。

Find（発見）: 敵や標的がどこにいるかをセンサーや偵察で探知する。
↓
Fix（特定）: 標的の正確な位置情報や動向を割り出し、特定する。
↓
Track（追跡）: 移動する標的を継続的に監視・追跡する。
↓
Target（照準・目標選定）: どの兵器で攻撃するのが最も効果的かを選択し、照準を合わせる。
↓
Engage（交戦・攻撃）: 実際にミサイルや戦闘機などで攻撃を実行する。
↓
Assess（評価・戦果確認）: 攻撃が成功したか、標的が破壊されたかを評価する。必要であれば再攻撃のプロセスに戻る。

Geminiに聞いたら、
「この概念の根底には、「一連のプロセスのうち、どこか一つの輪（段階）を断ち切る（破壊・妨害する）ことができれば、敵の攻撃全体を無力化できる」という考え方があります。逆に言えば、自軍の攻撃を成功させるためには、この鎖を素早く、かつ途切れることなく最後まで完遂する必要があります。」
「キルチェーンは「敵のプロセスをどこで断ち切るか」「自軍のプロセスをいかに高速で回すか」を考えるための基本となるフレームワークです。」
と言っていた。
つまり、F2T2EAの6つの工程のいずれかを断ち切ると、後続の工程に進めなくなり、ターゲットを撲滅できなくなる。
一方、F2T2EAの6つの工程を高速に回すほど、攻撃力が増して、相手側の攻撃を防御しやすくなるだろう。

このキルチェーンと、アジャイル開発に出てくるOODAは非常に相性が良い。
OODAの4つのステップがキルチェーンの6つの工程に対応付けられるからだ。

Geminiに聞いたら、
アジャイル開発において「市場の変化に素早く適応する」ことが目的であるように、キルチェーンにおけるOODAの目的は「相対的なスピードで優位に立つこと」です。
自軍が敵よりも速くOODAループを回し続けると、敵の「Observe」と「Orient」は常に古い情報に基づいたものになります。結果として敵は混乱し、誤った「Decide」を下すか、意思決定そのものが麻痺します。これにより、物理的に敵を完全に破壊しなくても、敵のキルチェーンを機能不全に陥らせることが可能になります。
と言っていた。

つまり、アジャイル開発はスピードを重視するが、OODAの概念に即することにより、分析と学習が加速されるわけだ。

「More Effective Agile ソフトウェアリーダーになるための28の道標」にOODAの解説があるのだが、僕は今まで腑に落ちなかった。
なぜOODAがアジャイル開発と密接に関係するのか分からなかった。
しかし、キルチェーンの観点で考えれば、OODAは非常に理解できる。
OODAはまさに、相手国を攻撃し殲滅させるための設計思想なわけだ。

【5】自動車の「ECUアーキテクチャ」、半導体の「専門家されたサプライチェーン」、防衛産業の「キルチェーンとOODA」はまさにその業界を制するアーキテクチャの設計思想だろう。
これらの概念を元に考えることで、より詳細な機能要件や性能要件も理解できるようになるだろう。

これらの概念をさらに深堀りしてみたい。

PMOはスクラムマスターである

PMOの役割とは一体何だろうか。長年PMOとして働く中で、その役割は環境や案件により大きく変わると感じてきた。単なる進捗管理の事務局から、全社の品質を担保する絶大な権力を持つ立場まで、その姿は様々だ。

しかし、ルールという法律を作り、管理と統制でチームを縛ることは、本当にプロジェクトを成功へ導くのだろうか。本記事では、PMOが陥りやすい「権力による支配」の構造を振り返りつつ、本来あるべき「スクラムマスター」としての支援的役割の重要性について紐解いていく。マイクロマネジメントを捨て、チームを信じて自律を促す「真のPMOの姿」をともに探求しよう。

【参考】
ＰＭＯ導入フレームワーク　～プロジェクトを成功に導く、人・組織・プロセス・ツール～ | 高橋 信也, 峯本 展夫 |本 | 通販 | Amazon

図解まるわかり PMO・PMのきほん | 西村 泰洋, 相川 正昭 |本 | 通販 | Amazon

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

【1】そもそも、PMOとはどんな役割を持つ人なのか？

PMOという職種の仕事についてもう8年くらいになる。
PMOになって仕事すると不思議な感覚になる。
PMOの役割が、会社によって、環境によって、案件によって、変わってくるからだ。

【2】当初は、PMOはある一つの大規模案件にて、プロマネの代わりに進捗管理や課題管理をしたり、経営層向け月次報告を作ったりする事務局的だった。
あくまでの、管理作業のお手伝いであり、開発チームに指示する権限はない。
リーダーやメンバーは自分の作業で忙しいのに、管理作業に必要な情報を作る事務作業はやりたがらない。
しかし、プロマネから委託されている立場により、開発チームのリーダーやメンバーに、必要な情報を出せと強制する権力を持っている。
当然、嫌がられやすい。

【3】次に、PMOとは、社内の全案件のゲートレビューに関する事務局だった。
だから、PMOは所詮、ゲートレビューのファシリテーションと議事録の作成、展開をやるに過ぎない。
大した仕事では無さそうに見える。
しかし、PMOは強力な権限を持つ。

ゲートレビューであるからには、PMOが、この案件は品質が悪いので次工程に進められない、特にリリース判定会議ではリリースに必要な品質を担保されていないのでリリース不可だ、と言えば、案件はストップさせられる。
案件のプロマネからすれば、顧客の契約を守れないからありえない事態だ。
しかし、プロマネはPMOと喧嘩しても、PMOからネチネチと突っ込まれる指摘に説明責任があるから、立場は弱い。
よって、プロマネは、PMOの言いなりにならざるを得ない。
1億円以上の案件であれば、プロマネは中間管理職相当なのに、PMO事務局というヒラの社員にペコペコするしかないのだ。

【4】さらに、PMOはゲートレビュー事務局がベースなので、全社の品質管理、さらには標準化推進する事務局を担当する役割を持つ。
大手のSIerであっても大規模案件のQCD管理に手こずっているので、ソフトウェア開発の品質保証の役割で、社内の全案件に対し、品質を担保せよと号令をかける。
号令だけでは弱いので、標準化という名のもとに、PMOは自ら社内案件を縛る法律を作り、自ら作った法律を社内案件全てのリーダーやメンバーに対し、強制させる。
PMOはそれだけの強い力を持つ。
リーダーやメンバーが反発しても、PMOは経営陣のお墨付きを得ているというバックを元に、彼らを従わせる権力を持っている。

【5】しかし、本来のPMOの役割は、スクラムマスターであるべきだと考える。

なぜならば、チームが自律的に動いているならば、PMOはマイクロマネジメントなど不要であり、スクラムマスターのように彼らが抱える組織的課題を解決し、支援する役割になるからだ。

たとえば、チーム自身が日々の進捗・課題管理を自ら運営して解決できて、納期を守り、品質を担保できる状態を維持できるならば、PMOがわざわざマイクロマネジメントする必要すらない。
そもそも、PMOが自ら法律を作ってマイクロマネジメントをチームに課すことは、チームを方任ずれば野放図に動くので、チームを信頼できない、という結果を招くだろう。

よって、PMOのあるべき姿は、当初はチームを指導したりコーチングして彼らの能力を引き出したり、動機付けたりするだろうが、最終的には、彼らの能力を信頼して委任する状態になるだろう。
その姿はまさにスクラムマスターと同じだ。