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

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

DX戦略はDX成熟度を考慮して戦略策定すべき

DXとはそもそも何なのか？
DX戦略の考え方は何なのか？
いまこそ知りたいDX戦略 自社のコアを再定義し、デジタル化するを読んで考えたことをメモ。

【参考】
いまこそ知りたいDX戦略 自社のコアを再定義し、デジタル化する | 石角 友愛 |本 | 通販 | Amazon

【1】DX、デジタルフォーメーションという言葉はよく聞くが、その定義を聞くと、人によってバラバラだ。
たとえば、デジタル化の回答もあれば、ITによる業務プロセス改善という意見もあれば、ITを使った新しいビジネスモデル構築という意見もある。
どれが正しいのだろうか？

デジタルフォーメーションという言葉を聞くと、僕は、デジタルに変身！と叫ぶウルトラマンに変身するイメージを思い浮かべてしまう。
実際の日本企業は、そう簡単に変身できないだろうが。

【2】いまこそ知りたいDX戦略 自社のコアを再定義し、デジタル化するでは、DXには3つの段階があると解説している。
DX成熟度というべき段階レベルがある。

【2-1】Digitization

アナログ→デジタルへ移行
例：
ペーパーレス化
図面の電子化
CADによる設計
承認フローの電子化

【2-2】Digitalization

・デジタル化したデータを利用して、
ビジネスプロセスを変革する
・作業の進め方を変えて、
顧客や企業の関与と相互作用の方法を変革し
新しいデジタル収益源を生み出す
例：
ERPによる経営資源共有
見積・設計・製造プロセスの改善
3D設計＋CAEによる設計品質向上
PDMツールによる技術情報の部門内共有

【2-3】Digital Transformation

新しいビジネスモデル、コアビジネスのデジタル変革
人や組織に関する変革
例：
自社以外に、顧客やサプライヤ、ステークホルダーを
巻き込んだ変革
グローバルPLM
ライフサイクルを通じたBOM再構築

dx-maturity-in-digital-transformation-strategiesfrom akipii ogaoga

【3】僕が現場で見る限り、日本の製造業は、Digitizationの段階で留まっているケースが多い。
特に、職人芸の気質が強い中小企業がそうだ。

たとえば、ノウハウは職人、経理や現場担当者にくっついていて、なかなか周囲にナレッジ共有できない。
OJTで学ばせるだけ。
日本人は現場で優秀なので、トラブル対応や火消しをいつも頑張ることで乗り切っている。
よって、組織として習熟しているとは言えないといつも思っている。
なぜならば、業務プロセスを誰も明文化していないし、明文化したとしても例外フローが多すぎて標準化もできていないからだ。
つまり、いくらERPなどのITシステムを導入しても、帳票出力システムに過ぎず、現場担当者の優秀さに頼り切っている。

【4】さすがにそんな状況はまずいと考える経営者も多い。
そこでDX戦略を作るわけだが、一朝一夕には行かない。
まずは、職人芸のノウハウを形式知化し、現場担当者の優秀さに依存しない業務プロセスの確立が必要になってくる。

その段階が、Digitization。
まずはノウハウをデジタル化して、見える化すべき。
実際にやってみると、相当な量になる。
特に製造業は会社の歴史も長いケースが多いし、職人芸のノウハウもたくさんあるので、書き起こすだけでも大変だ。
しかし、その価値は十分にあると僕は考える。

なぜならば、昨今は人手不足や若者不足が当たり前なので、現場の優秀なベテランに頼り切るやり方はもう通用しないからだ。
技術継承するためにも、Digitizationは必須だ。

【5】Digitizationが進んでくると、業務プロセスも見えてくるので、Digitalizationによって、業務プロセス改善、さらにはプロセス改革まで進める。
だが、業務プロセスの改善程度ならまだしも、プロセス改革は相当難しいと感じる。
なぜならば、人の再配置、部署の改廃、ひいては子会社化やM&Aなどの組織構造の変化にも関わってくるからだ。

ITコーディネータ勉強会で聞いた事例では、ERP導入を通じて業務プロセス改革をやった時、ITコーディネータである部長の部下である総務部の女性3人が結局退職した、と話されていた。
業務プロセス改革により仕事がなくなり、彼女らの存在意義が無くなったからだ。
リスキリングや別の能力開発を行ったのだろうが、人間はそう簡単に変わらない。
ましてや40代、50代にもなれば、新しい知識や技術の習得は難しくなる。
しかし、そんな人間関係の軋轢も覚悟の上でやらなければならないだろう。

【6】そういう業務プロセス改革を突き進めると、最終的には、組織構造の変革を通じて、組織文化の変革、社員のマインド改革まで行き着く。
そうすると、組織変革を通じて、会社のコアコンピタンスも再定義されて、新しいビジネスモデルや新規事業創造に向かうだろう。

そういう流れがDX化であるが、実際は10年以上かけて体質変化させる流れになるだろうと思う。
人間はそう簡単に変わらないからだ。
人間はそもそも保守的な存在である。
人間は、環境変化に即座に順応できるわけではない。
人間は自らの価値観を持ち、プライドを持つからだ。

会社には、若者もいれば、ベテランもいるし、最近では女性がたくさんいる職場も当たり前だ。
女性にも若い独身女性もいれば、既婚女性もいるし、子育てしている女性もいる。
また、中国人やインド人、ベトナム人などの外国人のSEや作業員も多いはずだ。
つまり、以前に比べると、日本の製造業も多様な人材が職場に溢れている。
よって、彼らの価値観を会社の価値観に合わせるのは至難の業だ。

そんな状況を踏まえて、DX戦略を考えるべきだろう。

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倍以上の速さで標準化を進めている間、日本は「どの資格が自社に合うか」の検討に時間をかけすぎて、スピードが遅すぎる。

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

SAFeはScrumと全く異なるアジャイル開発プロセスだ

SAFe経験者の話を聞いて、SAFeはScrumと全く異なるアジャイル開発プロセスだと初めて認識できた。
ラフなメモ書き。

【参考】
SAFe 5.0のエッセンス: スケールド・アジャイル・フレームワークによりビジネスアジリティーを達成する (00) | リチャード ナスター, D レフィングウェル |本 | 通販 | Amazon

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法 | 榎本 明仁, 木村 卓央, 高江洲 睦, 榎本 明仁, 荒瀬 中人, 水野 正隆, 守田 憲司 |本 | 通販 | Amazon

SAFeRアジャイルな企業への変わり方　現場から経営まで貫く価値創造のためのフレームワーク入門 | 張嵐, 横田和彦 |本 | 通販 | Amazon

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

Amazon.co.jp: アジャイルソフトウェア要求 (Object Oriented SELECTION Classics) : Dean Leffingwell, オージス総研: 本

【1】SAFe勉強会に議論してすごく参考になった。SAFeはスクラムと全く異なるフレームワークと見たほうがいい感じだ。

僕がSAFeで一番知りたいことは、アジャイル開発における計画・実行・検査・適応のそれぞれのプロセスでは、誰が責任を持って意思決定しているのか、ということだ。
大規模アジャイルだからといっても、大規模プロジェクトと同じ構造を持つわけだから、メンバー全員が一同に集まることは時間的にも物理的にも難しくなる。
責任の分担と責任範囲、権限範囲の設計が必要になる。

誰がプログラムバックログ、スプリントバックログの優先順位、イテレーションの範囲を決めるのか？
誰がプログラムバックログのメンテナンス、リファインメントを担当するのか？
誰が、各チームが開発したモジュールを統合ビルド、デプロイ、デリバリーの責任を持つのか？
誰が、リリース計画の方向性を決めるのか？

僕は、誰が責任や意思決定を持つのか、が知りたかった。
実際、大規模プロジェクトになれば、どうしても階層的な組織構造が発生し、そこに意思決定や指揮命令系統の順序が決まる。
だからこそ、組織の4原則に基づき、統制範囲の原則、命令統一化の原則が組織構造に必要になり、指示命令する人と指示に従う人に分かれる。
その組織構造が大規模アジャイル組織では、どのように設定すべきなのか？

※大規模プロジェクトなので、プロダクトバックログと呼ばず、プログラムバックログとも呼ぶらしい。

【2】SAFeの肝は、2つあると思う。
1つ目は、アジャイルリリーストレインで複数のアジャイルチームのリリースを同期させること。
大規模アジャイルなので、複数のアジャイルチームで構成されるプロジェクトになる。
すると、複数のアジャイルチームが開発したコンポーネント複数個を統合ビルドする必要がある。
その統合ビルドを合わせるために、電車の発着時刻にたとえて、アジャイルリリーストレインと言うわけだ。

2つ目は、複数のアジャイルチーム同士でプロダクトオーナーだけのPOSync、スクラムマスターだけの打合せ、全メンバーが集まる打合せ、など数多くの打合せを設計すること。
確かに官僚的なアジャイルな印象を持った。

アジャイルリリーストレインを全チームに同期させるために、事前に全チームで計画を立てて、定期的にリリースする。3ヶ月後にふりかえりする、というプロセスみたいだ。
興味深いことは、統合ビルドしたモジュールのスプリントレビュー、スプリントデモ・スプリントレトロスペクティブというイベントは正式に作られていないらしい。
もちろん、アジャイルチーム内ではスプリントプラニング・レビュー・デモ・レトロスペクティブは行われる。
とはいえ、大規模プロジェクトであっても、全チームメンバー全員が集まることはできないので、各チームのリーダークラスが集まった打合せで、モジュールのデモ・レビュー・レトロスペクティブは行われているのだろう。

【3】小さなチームによる小さな開発が現代では主流であっても、LLMとかSaaSとか大規模なシステム開発は必ずある。
GAFAのように、ソフトウェア専門企業も数万人の従業員を抱える大規模な組織を形成している。

だからこそ、SAFeのように、既存の大規模かつ複雑な組織にアジャイル開発を導入する時に無意味な摩擦をできるだけ避けて、導入できるプロセス手法が欲しくなる。
その辺りを考えてみたい。

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

第29回東京Redmine勉強会に参加してきた。
今話題になっているテーマは、いわゆるJTCの中でRedmineをどのように運用しているのか、とAIによるプロマネ作業支援だった。
とてもホットな内容で興奮が翌朝も残っている。
感想をラフなメモ。

【参考】
第29回勉強会 - redmine.tokyo

2025/11/9 第29回勉強会 - redmine.tokyo #redminet - posfie

Jira ユーザー向け 入門ガイドブック | リックソフト株式会社

Jira と Confluence の活用: シームレスなコラボレーションの実現: Jira と Confluence をプロジェクト管理フレームワークに統合するための効果的な戦略 (プロジェクト管理, IT・テクノロジー) | R. Parvin

【1】いわゆるJTCがRedmineを運用している事例では、東芝や三菱電機の事例が発表された。
典型的な日本の大手SIがRedmineをどのように使っているのか、どんな目的で使おうとしているのか、そして、どんな効果や苦労があったのか、具体的な話が多くて面白かった。

発表 #1683: 第29回 講演: 2万人が利用するソフトウェア開発管理支援サービスのご紹介 - redmine.tokyo

発表 #1674: 第29回 LT: JTCでRedmine利用者2700人を実現した手法 - redmine.tokyo

Redmineは、日本ではよく使われているプロジェクト管理ツールと言っていいだろう。
なぜ、日本企業や日本人開発者はRedmineを好むのか？
その理由は以前たくさん考えてた。

僕が持つ仮説は、現場に直結した困りごとを自分たちが手作りでツールを作り込み、自分たち自身で改善していくというスタイルは日本人がとても好きだから、と思っている。
いわゆる現状に即したプロセス改善は、日本人の得意芸と思っている。
日本の製造業で出てくるQCサークル、QC７つ道具、デミングサイクルは、日本のソフトウェア開発にも根付いていると思う。

そこで、中小SI企業だけでなく、JTCのような大手SIの現場でもRedmineを使いたくなってくる。
では、JTCでRedmineを運用し始めると、どのような問題が出てくるのだろうか？

JTCになれば、案件の数は格段に多くなるので、単一のRedmineで全ての案件を管理し統制させるのは難しくなってくる。
なぜならば、案件の種類はスクラッチ、エンハンスメント、パッケージ製品導入、リプレース、PoCなど多岐にわたるために、１種類の標準プロセスでコントロールするのは正直無理があるからだ。

そこで、東芝のように、研究開発部門や品質保証部門がRedmineやGitlab、Jenkinsなどの開発支援ツールを仮想環境で作り、各案件に社内ホスティングサービスとして仮想環境を提供し、自由に使ってもらうような運用が多くなるだろう。
この運用のメリットは、社内案件で使われるプロジェクト管理ツールや開発支援ツールを社内標準として提供できるため、ある程度統制を効かせられること。
また、ツール類が共通なのでノウハウも蓄積しやすい。
実際、東芝の事例では、社内ユーザ会を年数回定期的に開いて、社内で事例を発表して共有したら、社内関係者にすごく評判が良かった、という説明があった。
つまり、ノウハウ蓄積により、社内の組織活性化、生産性向上にも繋げられる効果があるだろう。

一方、各案件ごとにRedmineインスタンスが乱立するために、Redmineのバージョンが古くなりがちで、最新版への移行が難しくなることだ。
東芝の事例では、200個以上のインスタンスがあり、Redmineの主なバージョンは4.2が多い説明があった。

本来は、AIヘルパープラグインやいいねリアクション機能が使えるバージョン6.1へ移行したいだろうが、大量のRedmineインスタンスをVerUpする一括移行は非常に大変だろう。
東芝の事例では、移行作業のためにスクリプトなどで自動化するなど運用上の工夫をされていたが、それでも各メンバーがそれぞれ各案件のRedmine移行作業を担当し、手作業でカバーしていると説明されていた。
おそらく実際は、Redmineのような年2,3回程度のVerUpに追随するように移行作業を実施することは、大量のインスタンスがあるために実現困難なのだろう。

つまり、社内ホスティングサービスでは、運用当初は良くても、その後のVerUp追随が難しく、次第に統制が効きづらくなるデメリットが増えてくる。
たぶんどこかで、損益分岐点が逆転するタイミングが発生するかもしれない。

他方、島津製作所のRedmine運用事例のように、単一Redmineで統制を効かせて、ナレッジ蓄積に効果を上げている事例もあった。
JTCでRedmineを社内展開するときの運用方法の選択基準、スコープ設定で違いがあると、どのような効果や問題点が発生するのか、考えてみたい。

Xユーザーのakipiiさん: 「JTC事例では、 @akahane92のような単一インスタンスによるナレッジDBで全般統制と、なおまえさんの所のような社内ホスティングによる乱立インスタンスによる標準プロセス適用の諸問題の対比が興味深い。この辺りは一度議論を聞いてみたい　 #redminet」 / X

【2】Redmine AI Helper の講演では、AIを使ってRedmine上のプロマネ作業支援できる具体例や、AIヘルパーの内部構造の説明が非常に興味深かった。
興味深い点は2つある。

Redmine AI Helper とそのしくみ 第29回redmine.tokyo勉強会

1つは、チケットの要約機能は、もっと発展させれば、課題一覧から更新分の内容を要約させて、進捗報告書の一つの元ネタに割り当てる事ができること。
この機能を発展させて、健全性レポートという機能がAIヘルパーで提供されていた。
つまり、測定時点のプロジェクトのQCD、いわゆる進捗率の変化、テスト密度やバグ密度、課題件数の推移や優先度の割合、などを進捗報告書として自動生成してくれる。
したがって、経営層向けのプロジェクト進捗報告書作成という管理作業をプロマネはAIに委託できるメリットがある。

他にも、親チケットから子チケットへタスクを自動的にバラしたり、類似チケットを自動検索したり、チケットコメントの自動生成、チケットやWikiで文章を予測して自動補完、誤字脱字チェック機能などがある。
こういうAIヘルパー機能を使えば、顧客相手にチケットでやり取りするときの誤字脱字防止、チケットで即返答、類似バグ調査などにも役立てられるだろう。

Xユーザーのakipiiさん: 「AIヘルパーで健全性レポートを保存できる。さらに差分チェックもできてAIが比較報告してくれる。cronを使えば報告書作成も自動生成できる。プロマネの作業工数削減に繋がる。　 #redmineT」 / X

2つ目は、AIヘルパーを実現する内部構造の解説だ。

Redmine に蓄積されたタスク、システム開発のナレッジを元に、AIがチケットの要約だけでなく、ストーリーチケットからタスクチケット分割を自動生成できたり、診断時点のプロジェクトの品質、進捗、テスト、レビュー状況を報告書としてまとめたりできる。プロマネの管理作業をAIが支援できる。

実際の仕組みはAIエージェントをロール毎に作ってプロンプトを渡して実行してるだけ。
具体的には、Redmine の背後に、AIエージェントが複数立ち上がり、リーダー役エージェントが仮想チャットルームを作り、そこにチケット作成エージェントやRedmineの機能に特化したエージェントを呼び込んで自然言語でやり取りして実行する仕組みだった。

Xユーザーのakipiiさん: 「AIヘルパー内部では、リーダーエージェントが仮想チャットルームを作り、チケットエージェントやリポジトリエージェント、ユーザエージェントなど必要なエージェントを仮想チャットルームに召喚して自然言語で会話しながら、要約したり子チケットばらしとかしてる。普通の開発チームみたい　 #redmineT」 / X

この話を聞いて、別ニュースで、AIエージェントを集めて仮想スクラムチームを作ってシミュレーションした話と似てるなと思った。
つまり、スクラムマスター、プロダクトオーナー、チームメンバーという仮想AIエージェントを作り、仮想スクラムチームを形成して、プロダクトを出していくシミュレーションができるわけだ。

仮想スクラムチームとAIヘルパーのマルチエージェントモデルの違いは、対等なエージェントでチームを作ると人数が増える毎にコミュニケーションパスが増えて無駄があるので、リーダー役エージェントが一括管理する方が仕組み的に良い点になる。
AIエージェントでチーム形成する時、アジャイル観点と違ってマイクロマネジメントの方が優れているのだろうか？

現代ではソフトウェア開発だけでなく、あらゆるプロジェクトでもマイクロマネジメントではなくサーバントリーダーシップによるチームビルディングが推奨されている。
つまり、コマンダーのようなリーダーではなく、チームメンバー自身がリーダーの役割を持ち、自己組織化していく傾向が良いはずだという流れになっている。
しかし、マルチAIエージェントモデルでは、コマンダーが指示するマイクロマネジメントの方が処理性能が良く優れているという設計になっている。

現代のアジャイル開発の流れと従来のマイクロマネジメントスタイルを持つマルチAIエージェントモデルが違う点は何なのか、今一度整理したい。

僕の仮説では、ソフトウェア開発のように、深い専門性を持つメンバーから成り立つ案件では、人間であるリーダーが全ての専門知識をカバーできないため、サーバントリーダーシップを発揮して、意思決定権限をチームに移譲するやり方にならざるを得ない。
一方、単純な作業指示のような案件では、マイクロマネジメント方式の方が簡単で効率もいい。
さらに、AIの場合、リーダー役のAIエージェントは全ての専門知識を知っている前提にすれば、実際の作業実行ロールのエージェントに作業分担させた方が、遥かに効率がいい。

よって、AIがプロジェクト管理に浸透するほど、サーバントリーダーシップよりもマイクロマネジメント方式が優勢になるかもしれない。
サーバントリーダーシップは、情報整理力が劣る人間の集団で必要なリーダーシップに過ぎないのかもしれない。

また、AIヘルパーの内部構造では、
Rails MVC　＞　エージェント抽象化レイヤ　＞　各エージェント　＞　MCP抽象化レイヤ、LLM抽象化レイヤ　＞LLM、MCPサーバ
で設計されていた。
これを見て、エージェントの追加変更やモデルの追加が非常にやりやすいアーキテクチャだな、と感心した。
むしろ、LLMモデルを使った設計はこのような仕組みにならざるを得ないのではないか。

【3】僕は、JIRAによるチケット駆動開発の運用事例を紹介してきた。
久しぶりの講演で実は緊張していたが、話しているとテンションが上って、いい感じで話せた。

How We Operated Ticket-Driven Development in JIRA

たぶん、世界的にはRedmineよりもJIRAの方がよく使われているだろう。
僕は、JIRAは複雑すぎて使いづらく、Redmineの方が好きだ。

僕は、組み込みシステム開発では、タスク管理が複雑な階層化のために運用が難しく、それをJIRAにフィッティングさせて運用するのも難しい、という話をした。

一方、懇親会では、JIRAにアドバンスドロードマップやスキーマ機能を使うとさらに便利になる話を聞いて興味を持った。

Xユーザーのakipiiさん: 「懇親会でJira機能を話し込んだ。アドバンストロードマップがプログラム管理に使えること、スキーマ機能が標準プロセス適用に使える事が分かって収穫があった。JiraはRedmineと異なる機能がまた面白い。　　 #redminet」 / X

Jira Advanced Roadmapsは、製品企画のような計画作成で使う機能と思っていた。
どうやら、複数プロジェクトを横断したプログラム管理で使えるらしい。
JIRAのプロジェクトは階層化する機能がないため、Redmineに比べると不便だった。
おそらくその機能を補完するような機能かなと推測する。

Jira Advanced Roadmaps を使った計画策定を習得する | Atlassian

ChatGPTで聞いたら
「複数プロジェクトの計画・スケジュールを俯瞰的に可視化・調整できる上位プランニングツール です。
Scrum や Kanban チームのバックログをまとめて管理するのに最適です。」
とのことだった。

また、JIRAにおけるスキーマ（Schema）とは、ワークフローや権限、画面構成などをテンプレート化し、複数プロジェクト間で共通化する機能だ。
この機能はRedmineにはない。
アジャイルウェアのプロジェクトテンプレート、チケットテンプレートプラグインに似ているだろう。

JIRAのSchema機能を使いたい場面は、社内の標準プロセスを全案件に展開して統制できることだ。
JTCならば、社内標準の開発プロセスがあり、工程・手順・成果物が明確に定義されたV字モデルを持っているだろう。
すると、社内の全案件は、社内標準プロセスに従わせて、ドキュメントの標準化や作業効率化を目指したい。
そんな時にJIRAのSchemaで社内標準プロセスをテンプレートで実装すれば、各案件に展開すればいい。

運用プロセスに対して、こういうチケット管理ツールの機能フィッティングは面白いので、今後も色々探ってみたい。

RedmineJapan vol.4の感想part1～Redmine AI HeplerプラグインはRedmineのナレッジ活用を強化してくれる #RedmineJapan

RedmineJapan vol.4で紹介されたRedmine AI Heplerプラグインが素晴らしかったのでメモ。

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

逆引きでわかる！ Redmineハンドブック バージョン5.0対応

2025/7/25 Redmine Japan Vol.4 #RedmineJapan - posfie

Redmine Japan Vol.4

Redmine AI Helperプラグイン更新

Redmine AI Helperプラグインを公開しました

【1】Redmine AI Heplerプラグインは、RedmineからAI機能をコールして、チケットやWikiの要約などをしてくれるプラグインだ。
今年5月のredmine.tokyoでも講演されていて、参加者の多数がすごく興味を持っていた。

実際はOpenAIやGeminiなど外部のAIへトークンを発行してコールしている仕組みだけだが、AIがさらにRedmineを使いやすくしてくれる可能性を秘めている。

Redmineを長年使い込んでいくと、チケットに過去の作業、障害修正、課題対応などのノウハウがナレッジとして蓄積されていく。
しかし、そのノウハウはそのまま使えるわけではない。
内容が何なのか、ポイントを抽出したり、過去のコンテキストを元に現状の環境ではこういうナレッジになる、という仕掛けがほしい。

要約はAIが得意とする機能なので、要約機能を使えば、現場で使う詳細な進捗報告書を経営層などトップ層へサマリ化、要約して報告書を生成することもできるはず。
たとえば、詳細な障害一覧や課題一覧を見せられても彼らは分からない。
むしろ、どこにリスクがあるのか、現状はどんな評価なのか、を知りたい。
そんな時に、AIの要約機能は使えるはず。

つまり、Redmineにプロジェクト報告書を追加する機能がより具体化できるだろう。

【2】RedmineJapan vol.4ではさらに、edmine AI Heplerプラグインが進化していた。
Redmine AI Helperプラグイン更新の記事の通り、チケットの回答案生成、子チケット作成、プロジェクト報告も機能追加されていた。

チケットの回答案作成は、カスタマーサポートのような定型的な文章を書く場面で有効だろう。
主張したいことを箇条書きで提示すればAIが上手く文章を作ってくれる。

子チケット作成は、プロジェクトリーダーの管理作業を代行してくれるような機能だ。
デモでは、不具合チケットを元に、調査、原因分析、障害対応、検証、リグレッションテスト、デプロイ、リリースなどの子チケットをワンクリックで自動生成してくれていた。
つまり、障害修正のような定型作業では、手順は標準化されているので、その手順に沿ってタスクを詳細化して作成し、それぞれのタスクに担当者を割り振ればいい。
よって、プロジェクトリーダーの管理作業をかなり楽にしてくれるはずだ。

プロジェクト報告では、該当プロジェクトのチケット群をベースに、その時点のプロジェクトの進捗・品質・コストを自動で報告文を生成してくれる。
プロジェクト報告のQCDを数値で評価する機能もあり、たぶん、占いエージェントを作った経験から作られたのだろうか。
また、おれおれ報告というカテゴリもあり、AIが勝手にプロジェクトを診断して、良いか悪いかバッサリ評価した文章を生成してくれる。
遊び心があっていいと思った。

今後、プロジェクト報告機能では、定期的なタイミングでプロジェクト報告の履歴を残す機能も作りたい、と話されていた。
確かに、報告は履歴が重要で、推移を元に比較評価したい。
だから、プロジェクト報告機能の強化は、Redmineがさらにプロジェクト管理ツールとして進化する可能性を大いに秘めていると思う。

【3】RedmineにAIの機能が追加されることによって、何が大きく変わるのか？

やはり、Redmineに蓄積された作業、障害、課題、問い合わせのナレッジを元に、より精度の高いノウハウを蒸留し、抽出してくれることで、プロジェクトリーダーの管理作業や意思決定を支援する仕組みを提供することだろう。

従来のチケット管理システムでは、チケットの更新情報や活動履歴を元に、進捗・品質・コストをリアルタイムに集計できることによって、プロジェクトリーダーの意思決定を支援できる点がメリットだった。
つまり、強力なチケット集計機能がチケット管理システムの主なウリだった。

一方、チケット管理システムには案件や組織特有の情報がチケットとして蓄積されるので、ナレッジシステムにもなりうる。
ナレッジシステムであるからには、いつでも簡単にデータが検索できて、欲しい情報がすぐに得られるようにしたい。
だから、チケット管理システムでは、強力な全文検索機能も重要な要件になりうる。

しかし、全文検索機能はあくまでも文言にヒットするだけであり、本当に欲しい情報を得るには、検索結果から取捨選択する手間もかかる。
そこが弱点だった。

そこで、チケット管理システムにAI機能が追加されることにより、本当に欲しい情報が蓄積されたチケットから蒸留されてサマリ化された情報を取得できるようになる。

つまり、AI機能は、チケット管理システムがナレッジシステムでもある特徴を効果的に利用可能にするはずだ。

しかし、AI機能を単純に機能追加すればすべてが解決できるわけではない。

講演者の@haru_iidaさんが話されていたが、ある案件で担当者をアサインする時、その人の予定表をOutlookで見れば確保できる工数は限られていれば、そう簡単に意思決定できるわけではない。
つまり、Redmineだけでは、本来のリソース管理を意思決定できない。
そこで、Outlookの予定表データをAI機能でアクセスして予定情報を取り込んだり、社内システムや人事システムも取り込んで、より多角的に判断できる仕組みも必要になるだろう。

すなわち、Redmineを情報系基幹系システムとみなすことで、案件管理を強化し、プロジェクトリーダーのチーム運営や意思決定を強化する方向へ進化できるはずだ。

その辺りも今後の発展が楽しみだと思う。

Jiraの機能はTracに似ている気がする #redmine

最近、Jiraを触り始めた。
Jiraの感想は一言で言えば、昔のTracにすごく似ている気がする。

Redmineユーザの観点では、Jiraは非常に使いにくい。
Jiraのどこが使いにくいのか？

使いにくい原因は、Jiraがアジャイル開発機能に特化していること、Tracのような古い機能が残っていることだと思う。

Tracのワークフロー: プログラマの思索

RedmineとTracの機能比較: プログラマの思索

Jira Cloud ユーザー向け 入門ガイドブック第２版 : リックソフト株式会社

Confluence ユーザー向け 入門ガイドブック | リックソフト株式会社

【1】一般に、JiraはScrumのようなアジャイル開発、カスタマーサポートのようなサービスデスクなどのユースケースに特化している。
Jiraには、アジャイル開発の機能がすでに盛り込まれている。
チケットと呼ばず課題（Issue）と呼ばれている。
課題には、エピック、ストーリー、タスクが既に存在していて、ストーリーポイントのような見積もり項目もある。
課題のビューには、バックログとスプリントバックログが既に存在している。

しかし、一般の日本企業では、WF型開発が主流であり、ExcelのWBSとかガントチャートを使いたい。
結局、リックソフト社のガントチャートプラグインを入れて、Scrumの機能は全く使わず、ガントチャート上でタスク管理している事例がすごく多い。
つまり、日本企業の現場では、実際のタスク管理とJiraのアジャイル開発機能にギャップが発生している。

しかも、日本企業の現場では、Jiraのスプリント機能を使っていない。
スプリントをなぜ使わないのか？

Jiraではプロジェクトを階層化できないため、１個のプロジェクトで１つの大規模案件をアサインする。
すると、１個のプロジェクトに複数チームのタスク管理に使うため、複数チームのタスクが混在してしまう。
だから、複数チームのタスクを区別するために、WBSのトップ階層を各チームに割り当てて、タスクを階層化して使っている。
非常に使いにくいこと極まりない。
Redmineならプロジェクトを階層化できるので、子プロジェクトをチームごとに割り当てることで、タスクを分別できるし、親プロジェクトで横串で横断して管理もできるのに。

しかも、JiraのスプリントはRedmineのバージョンと同様に、１プロジェクトに依存するために、複数チームのタスクに１つのスプリントがアサインされる。
しかし、現場では、チームごとにチーム特有のスプリントを決めたいケースは多い。
大規模案件ではリリースバージョンというメインターゲットが決まっていても、各チームのタスク管理では、各チームごとにこまめにリリースしたいバージョンがあって、それをスプリントにアサインしたいが、スプリントはPJ固有であるために、チームごとにスプリントをアサインできない。

Redmineならば、親子プロジェクトができるから、子プロジェクトでチーム独自のバージョンをアサインできる。
つまり、全チームはアジャイルリリーストレインのごとく、最終ターゲットであるリリースバージョンに向けて作業していく。
ただし、チームごとにリリースバージョンに向けて細かなバージョンを作成してマイルストーンを決定したいし、各チームごとにロードマップを詳細化すればいい。
そういう作業計画がJiraでは非常にやりにくいと感じる。

【2】Jiraのチケット項目には、解決状況というバグ管理システムの遺産みたいな項目がまだ残っている。

たとえば、TracやMantisでも解決状況の項目があったし、解決状況＝解決済みor取り下げを設定しなければ、チケットを完全にCloseできなかったり、ロードマップの画面に取り消し線でCloseされた意図が表示されない機能があった。

Jiraでも同様に、解決状況＝解決済みor取り下げを設定しなければ、チケットを完全にCloseできない。
チケット駆動の初心者にとって、チケット完了させるためにはステータスを完了にするだけでは不十分なのはなぜ？　解決状況って何なの？と思うだろう。
Redmineのようにシンプルに、解決状況はステータスと同一視して、無くしてしまえばいいのにと思う。

RedmineとTracの機能比較: プログラマの思索

また、チケット管理ツールで最重要な機能であるワークフロー管理機能は、JiraではUIエディタ上で設定する仕組みになっている。
UIエディタ画面上で、ステータスに先行後続の関係を線で引っ張るのが鬱陶しい。
Redmineならば、状態遷移表のようにステータスの先行後続はチェックボックスをつけるだけなので、状態遷移図をイメージできれば記入しやすいし、事前にチェックリストのように作っておけば間違えにくい。

たぶん、TracのワークフローはINIファイルにPlantUMLみたいに記述するやり方だったが、Jiraもそのやり方を踏襲しているが初心者でも使えるようにUIエディタ上で見た目は分かりやすく表現しているのだろうと想像する。
正直使いにくくて鬱陶しい。

Tracのワークフロー: プログラマの思索

さらに、Tracのチケット集計ビューはSQLで直接書くことができたように、JiraでもJQLというSQLに似た構文を使って、ダッシュボードというビューを自由自在に作れるメリットがある。
Jiraを使う場合、Confluenceとセットで使う場合が多いので、Confluenceにダッシュボードを埋め込んで、Wordみたいにきれいに文書化できる。
この点はRedmineよりも優れている点だろうが、解決状況やワークフロー機能の使いにくさを思い出すと、改めてTracにすごく似ているように思える。

【3】とは言え、たぶん僕がまだJiraを使いこなせていないだけなのかもしれない。
自分がやりたいのは、Jiraでスプリント機能を使って、複数チームのタスク管理をイテレーション単位に管理して、アジャイル開発のペースを実現したいことだ。
その観点でさらに試してみたいと思う。

チームトポロジーにおける4チームのインタラクションをUMLで整理してみた

「チームトポロジー」を理解するために、4チームのインタラクションをastahで整理してみた。

【参考】
チームトポロジーの感想～大規模アジャイル開発でも組織構造は大きく変化する: プログラマの思索

チームトポロジーから組織の現時点を知る #チーム開発 - Qiita

SalesNowの開発組織を支えるチームトポロジー

30分で分かった気になるチームトポロジー

【1】チームタイプｘチームインタラクションモードをアクティビティ図を流用して表形式で整理してみた。
典型的なインタラクションのみ記載してみた。

やはり基本は、他チームにAPIを公開して利用してもらうIFだろう。
CollaborationやFacilitationでいつもチーム間でコミュニケーションを取るのはコストがかかりすぎると思う。
チーム間のIFが軽いケースが増えれば、結局、自身のチームで作成したAPIを社内の他チームに使ってもらうケースになるだろうと思う。

【2】チームトポロジーにおける4チームのインタラクションをクラス図で書いてみた。
典型的なインタラクションのみ記載してみた。

中心には、サービスを開発するStream-aligned teamがある。
Platform team、Complicated Subsystem teamがStream-aligned teamにリソース（API）を提供する。
Enabling teamがStream-aligned teamをコーチングしたり支援したりする。

もちろん、Stream-aligned team同士でCollaborationしたり、APIを提供する場合もある。

そういうチーム間の構造を見ると、チームの種類数はこれだけしかないのか、という疑問も湧いてくる。
おそらく、「チームトポロジー」の著者が色んな会社で大規模アジャイル開発を見てきて、これらのチームタイプに収斂されたのではないかと想像する。

【3】こういう内容を理解してくると、チームトポロジーを実際に使いこなして、試してみたくなる。

しかし、チームトポロジーの感想～大規模アジャイル開発でも組織構造は大きく変化する: プログラマの思索でも書いたが、社内にあるたくさんのアジャイル開発チームを組織編成できる人たちのレベルは、CTOや事業部長クラスの人たちであり、普通のスクラムマスターのレベルの人達では難しいのではないだろうか。
一人の開発者をチーム間でやり取りするだけでなく、アジャイルチームそのものを切り出したり、吸収したり、統廃合する権限が必要になってくるからだ。

事例をあまり良く知らないので他にも探したり聞いてみたいと思う。

チームトポロジー [ マシュー・スケルトン ] 楽天で購入

チームトポロジーの感想～大規模アジャイル開発でも組織構造は大きく変化する

「チームトポロジー」を読んでみた。
ざっくり読んだだけなので理解が浅いと思うが、理解したこと、疑問に思ったこと、感じたことを書き残しておく。
ラフなメモ書き。

【1】「チームトポロジー」を読む前に、疑問を持っていた。

【1-1】1つ目は、「チームトポロジー」は大規模アジャイル開発の文脈で、どんな意義があるのか？
大規模アジャイル開発の書籍は、「SAFe 5.0のエッセンス スケールド・アジャイル・フレームワークによりビジネスアジリティーを達成する [ リチャード ナスター ]」「大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法 [ Craig Larman ]」などがあり、SAFeやLeSS、Scrum@Scaleなどの考え方もすでにある。
SAFeは官僚主義的だが実践的、LeSSはScrumをスケール化したものと理解している。
それらを踏まえて、「チームトポロジーは、大規模アジャイルの考え方の中でどのように位置づけられるのか？
従来の考え方を整理しただけに過ぎないのか、それとも、どんな新しい考え方をもたらしたのか、理解したいと思った。

【1-2】2つ目は、「チームトポロジー」はアジャイル開発にどんな新しい考え方をもたらしたのか？　
昔のアジャイル開発の考え方とどこが異なるのか？　
今の時代に即した開発チームや組織のあり方は何か？　
その時代に応じたアジャイル開発の文脈があると思っているので、若い人達がどんな考え方を持って感じているのか、理解したいと思った。

【2】チームトポロジーのテーマは、ソフトウェア組織はどのように進化させるべきか？と理解している。
事業を取り巻く外部環境はコロコロ変わる。
事業を支えるシステムも、コロコロ変わる外部環境や事業の発展速度、事業規模に振り回される。
そのような変化の激しい外部環境や事業環境では、従来のWF型開発ではついていけない。

コンウェイの法則は誰もが知っているが、実際に適用できる企業は非常に少ないと思う。
従来のWF型開発では、技術重視で層別に組織化されて、チームが分断されている。
インフラチーム、DBチーム、アプリチーム、UIチームとか。
1つのシステムをデリバリするのに複数チームが連携しないとデリバリできない、とか。

しかし、コンウェイの法則を適用できたとしても適用して成功できた期間は短いケースも多いと思う。
アジャイル開発を実践するチームが増えたとしても、事業が発展し事業規模が大きくなれば、業務が複雑化し、開発チームの増加やシステムの複雑性によって、じきに上手くいかなくなる。
本質的な複雑性をシステムもチームも抱え込む。

そこで、組織は、然るべきタイミングを見つけて、チームタイプを変えたり、チーム間IF（コミュニケーションスタイル）を変えていくべき。
「チームトポロジー」はそういうストーリーと理解した。

【3】「チームトポロジー」で重要な概念は2つ。
チームタイプとチームインタラクションモード。

【4】チープタイプは４種類ある。
バリューチェーンを構成する主要業務は、Stream-aligned teamが担当する。基本は一般的なアジャイル開発チームと思う。
チームトポロジーでは、Stream-aligned teamが6～9割は占めるだろうと言っている。
やはり、Stream-aligned teamが事業を動かすエンジン。

Stream-aligned teamを支える補助チームが3種類ある。Enabling teamは、特定の技術領域やプロダクト領域の専門家集団。能力ギャップを埋める役割を果たす。Azure専門家チームとか、火消しプロジェクトに入ったPMOチームみたいなイメージだろうか？

Platform teamは、Stream-aligned teamが相当な自律性のもとでデリバリーを可能にするチーム。インフラ基盤を提供したり、APIを提供するチームと理解した。クラウド基盤チーム、IoT基盤チームみたいなイメージだろうか。

Complicated Subsystem teamは、特別な知識に大きく依存しているシステムを構築維持する責任を持つチーム。長年維持した既存の基幹系システムを担当するチームのイメージだろうか。他に、機械学習チーム、AIチーム、音声処理チームなどの特殊技術だけの開発チームもあるだろうか。

【5】チーム間のコミュニケーションをシステム間のIF設計と同様に扱う。
それがチームインタラクションモード。

チームインタラクションモードは3種類ある。
チーム間のコミュニケーションをシステム間のIF設計と同様に扱うイメージと理解した。会話スタイルをAPIやプロトコルで例えると理解しやすいと思う。

コラボレーションは異なるスキルを持つ２チームが一緒に取り組む。探索して学習できるが、認知負荷が大きすぎる。コラボレーション税と本では書いている。新規事業ではどうしても複数チームが共同で開発してデリバリーするケースも多いだろう。アジャイル開発なら一般的なケースと思う。

X-as-a-Serviceはシステム部品がサービスとして提供される。提供チームと利用チームに分かれる。利用チームは、提供された部品や技術を信頼できるのでその分デリバリーが速くなる。前提は、サービス境界が正しく実装されていること。API提供チームの責務が大きい。
Platform teamの主な職務遂行モード。AWSやAzureが普及しているし、マイクロサービス設計されていれば、APIから部品を組み立てる感じですぐにデリバリーできるはず。

一方、ファシリテーションは、他チームに支援と能力を提供する。プラクティスや新技術の導入とか。Enabling teamの主な職務遂行モード。他チームが学習すること、
問題や障害を発見して取り除くことに対応する。
コーチするチームとコートされるチームに分かれるだろう。プロセス導入と普及、品質向上活動、新技術導入とか色々ケースはあると思う。

【6】チームタイプｘチームインタラクションモードのマトリクスで、チーム間のコミュニケーションスタイルを切り替える。たぶん製品ライフサイクル（PLC）で考えれば、チームタイプが変化するタイミングに気づきやすくなると思う。

たとえば、PLCの導入期は、単純な1チームのStream-aligned teamだけでいい。まだ新規事業を1個立ち上げたばかりだから、少人数のアジャイル開発チームで十分。
しかし、PLCの成長期に入ると、事業規模が拡大し、開発者も増えて管理職が管理監督するようになり、組織も複雑化してくる。

Stream-aligned teamの数が増えてチーム間IFが取れなくなる。例えば、Enabling teamが機械学習やAzureの技術やアジャイル開発のプラクティスをコーチングしたり、Platform teamがAPIやサービスを提供して、Stream-aligned teamが早期にデリバリーしやすくする仕組みが必要になってくる。
事業規模に応じて、チームを増やしていくが、チーム横断で支援する専門チームをアサインする必要があるわけだ。

そして、PLCの成熟期に入ると、複雑化した既存システムに対しComplicated Subsystem teamが専任してサービスを社内に提供し、他チームのデリバリーへの影響を避ける、とか。あるいは、機械学習、ロボティクス等の専門チームをComplicated Subsystem teamに割り当てて他チームにサービス提供するとか。

事業の主要業務に特化したStream-aligned teamだけではじきに対応できなくなる。最低限の共通基盤を抽出し、開発基盤やAPIを提供して素早いデリバリを支える専門家チームとしてPlatform teamが必要になる。

あるいは、業務が複雑化すれば、チーム間で能力のばらつきも出てくる。そこでコーチングして能力ギャップを解消するために、支援だけの専門チームとしてEnabling teamも必要になる。

【7】チームトポロジーは、大規模アジャイル開発で組織編成する時に、一つの指針になる。
いくら、リーン、スクラム、DevOpsが適用されてもまだ問題は残る、

安定して速くデリバリーするアジャイル開発チームを側面から支援したりコーチングしたりする専門家チームがやはり必要なのだ。
ただし、それは従来のWF型開発における層別に分けられた共通基盤チームと同義ではない。

【8】チームトポロジーを真に実践できる人のレベルは誰か？
CTOや事業部長クラスの人ではないかなと思う。
事業部制組織のトップが、担当するソフトウェア事業を成長させるために、どのタイミングでどのような組織構造に変えるべきか。

なぜなら、チームのメンバーもプロジェクトリーダーも、複数のチームを編成する権限を持っていない。
プロジェクトマネージャもせいぜい、大規模開発チームの傘下にある複数のサブチームを編成するぐらいの権限しか持っていない。
幅広く横断的にチームを統合したり、分割したり、新たな役割を割り当てることができるのは、CTOや事業部長レベルになるのではと勝手に推測する。

その意味では、チームトポロジーを習得する難易度は高いだろうと思う。
まず1つのチームでアジャイル開発を実践して成功できたうえで、大規模アジャイル開発も実践して、さらに複数のアジャイルチームをコントロールするノウハウが必要になるからだ。

【9】チームトポロジーを読む前では、大規模アジャイル開発の書籍では、コミュニケーションやモチベーションに関する組織文化に特化した話題が多い気がしていて、何か欠落している気がしていた。
たぶん組織構造の話題がなかったからだと思う。
チームトポロジーでは、組織構造のテーマを真正面に捉えている。その点は非常に有用だと思う。

チームの役割やチーム間のIFを種類分けし、「組織センシング」によって然るべきタイミングにチームタイプやチーム間のインタラクションモードを変えていくべき、という主張は非常に役立つ。
組織がしかるべき自覚を持って、チーム構造を進化させるタイミングに気づくべきなのだ。
組織構造を事業の変化やアーキテクチャの変化に合わせて変えていく手法として、有用な内容だと感じた。

モデリングの論点は、ソフトウェアをどんな観点で分割して整理すべきか。チームトポロジーのような組織論の論点は、デリバリーを安定して速くするためにどんな組織構造を割り当てるべきか。
結局、ソフトウェアの本質的な複雑性をいかにコントロールするか、その根本問題を巡って、その時代に応じた文脈で問題解決の方法が提唱されて、少しずつ変化していると感じた。

【10】
「チームトポロジー」は大規模アジャイル開発の文脈で、どんな意義があるのか？
チームトポロジーの意義は、組織文化よりも組織構造に焦点を当てて、状況に即したチームタイプやチーム間IFを取るべきと主張している。

「チームトポロジー」はアジャイル開発にどんな新しい考え方をもたらしたのか？
チームトポロジーがもたらした考え方は、Scrum、リーン、DevOpsなど、過去のアジャイル開発の発展を踏まえて、アジャイル開発チームの特性やチーム間IFのあるべき姿を提示した点にある。

チームトポロジー [ マシュー・スケルトン ] 楽天で購入