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

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

【参考】
アーキテクチャモダナイゼーション 組織とビジネスの未来を設計する | 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倍以上の速さで標準化を進めている間、日本は「どの資格が自社に合うか」の検討に時間をかけすぎて、スピードが遅すぎる。

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

製造業のDXを推進する部門をITコーポレート部門に割り当てるとなぜ失敗するのか

製造業のDXを推進する部門はどこに置くべきなのか？

【参考】

誰も教えてくれない「生産管理システム」の正しい使い方 | 本間 峰一 |本 | 通販 | Amazon

誰も教えてくれない 「工場の損益管理」の疑問 | 本間峰一 |本 | 通販 | Amazon

誰も教えてくれない ｢部品工場の納期遅れ｣の解決策 | 本間峰一 |本 | 通販 | Amazon

誰も教えてくれない「SCM計画立案・遵守」の疑問 あなたの会社の生販在（PSI）計画は機能していますか？ | 本間峰一 |本 | 通販 | Amazon

BOM/部品表入門: マテリアル・マネジメント改革の基本技術 (図解でわかる生産の実務) | 佐藤 知一, 山崎 誠 |本 | 通販 | Amazon

図解 DX時代のPLM/BOMプロセス改善入門 デジタル化 段階別課題解決のアイデア100 | 三河 進 |本 | 通販 | Amazon

【1】一般企業では、常識的には、IT情報システム部門やITコーポレート部門がDXを推進しているだろう。
しかし、製造業のDX推進部門にITコーポレート部門を割り当てると、事業部門から総スカンをくらったり、現場のサボタージュによって、たいてい上手く行かない。
製造業ではDX推進にITコーポレート部門に割り当てるとなぜ失敗するのだろうか？

製造業ではない業界、たとえば、小売業や金融業では、ITコーポレート部門がDX推進して上手くいくケースがある。
そのケースを見てみると、ECサイトに特化したり、QRコード決済やオンライン取引へ拡大したり、実際の事業活動を現場から離れてオンライン場へ展開したケースが多い気がする。
つまり、できるだけ、現場の作業から生み出される利益よりも、オンライン事業による利益を追求したケースだ。
最終的には、SaaSに近いビジネスモデルになるのではないか。

【2】一方、製造業では、製造設備や工場敷地を持つ現場に、設備投資して製品を生産し、付加価値を付けて製品を売り、利益を得る。
すなわち、実際の現場の作業こそが利益の源泉であり、現場から離れることは難しい。
いくらITで業務効率化したといっても、現場の手作業が効率化されるだけであって、現場の作業そのものがなくなるわけではない。
むしろ、現場の手作業にこそ差別化要因があるケースもあるだろう。
自動車、家電、医薬品、食品、石油精製、製鉄、造船などの製造業を見れば、どうしても現場の手作業から離れることは難しいように思える。

だから、製造業のDX推進部門は、ITコーポレート部門ではなく、事業部門そのものが推進すべきという考え方には一理あるように思う。

【3】しかし、AIの普及とロボットにAIを埋め込むことで、その考え方も変わるかもしれない。
製造業における工場の生産ラインをロボットでAI制御できる状態にしたり、生産ラインそのものをソフトウェアで簡単に入れ替えできる状態にできれば、全てをITで制御できることも可能だろう。
そうすれば、初めて、製造業のDX推進部門を事業部門からITコーポレート部門へ移すこともできるのではないか。

ビジネスモデルとIT戦略の関係、さらにはDX推進部門を含めた組織戦略については、再度考えてみたい。

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

プ譜でプロジェクトの目的を管理する

オープンソースカンファレンス大阪にてプ棋の話を聞きたくて参加してきた。
プロジェクト管理の一手法として、目的や課題の管理に使えないか、今実際に使っているが、まだ腑に落ちてない。
講演者に実際に質問をぶつけてみたら、将棋の棋譜みたいにプロジェクトの局面をストーリーや歴史みたいに鳥瞰できる感覚が掴めた。
ラフなメモ書き。

【参考】
紙1枚に書くだけでうまくいく プロジェクト進行の技術が身につく本 | 前田 考歩, 後藤 洋平 |本 | 通販 | Amazon

見通し不安なプロジェクトの切り拓き方 | 前田 考歩, 後藤 洋平 |本 | 通販 | Amazon

予定通り進まないプロジェクトの進め方 | 前田考歩, 後藤洋平 |本 | 通販 | Amazon

プ譜の書き方と書く“意味” ?あなたの成長を支える“構造と思考の地図”?｜前田考歩

1月31日(土) タイムテーブル - オープンソースカンファレンス2026 Osaka

【プ譜友の会】プロジェクトの「不確実性」を定量評価する挑戦！ - セミナープログラム - オープンソースカンファレンス2026 Osaka

【1】プロジェクトで仕事している時に一番問題に感じることは、目的を忘れて作業に没頭してしまい、見失ってしまうことだ。
もちろん、プロジェクト計画も作るし、プロジェクト憲章も作るし、WBSも課題管理表も作って管理する。
しかし、実際の仕事は、目的を考える時間よりも、たくさんの打合せや資料作成などの実作業にほぼ時間を取られてしまう。

なぜ、そんな計画を立てたのか？
そもそも今の作業は効果があるのか、正しい目的に沿っているのか？
課題に対する対策は、本当に効果が出ているのか？
その判断は正しいのか？

日本人の技術者も担当者も、実作業が与えられたら真面目にやる。
しかし、作業に没頭してしまい、その作業の目的、正統性、効果測定を忘れてしまう。

プロジェクトは、経営目標や経営戦略に沿って作られるものであり、経営目標に対してそのプロジェクトがどれだけ貢献したのか、成果や効果を評価すべきだ。

そこで、プ譜というツールを使ってみる。

プ譜は端的には、目的に対する施策とその評価結果をプロジェクトの各局面で履歴として残し、将棋の棋譜みたいに追跡できる仕組みだ。
つまり、プ譜はToBeとAsIsを端的に表した1枚の図だ。
実際のプ譜のPPTテンプレはすごく単純だ。

それはプロジェクトの各局面のスナップショットであり、プロジェクト完了時にふりかえれば面白い。
プロジェクトリーダーが課題を適切に管理できていたのか？
その判断は正しかったのか？
その意思決定を間違えていたら上手く元々の軌道に戻せたのか？

すなわち、プロジェクトリーダーの意思決定をふりかえり、自分自身の意思決定の質を上げていくための処方箋にもなりうる。

プ譜はプロジェクトリーダー向けのツールだと思う。

これから使いこなしてみたいと思ってる。

Redmine AI HelperプラグインはRedmineをAI駆動プロジェクト管理に変える可能性を秘めている #Redmine

Redmine AI Helperプラグインの講演資料を読んで改めてアーキテクチャ構造がよく考えられているなと思った。
Redmine AI Helperプラグインを知っている前提で、理解したことをラフなメモ書き。

【参考】
Redmine AI Helperとそのしくみ

第29回redmine.tokyo勉強会

2025年の年始に読み直したいAIエージェントの設計原則とか実装パターン集

Building Multi-Agent Systems with LangGraph and Ollama: Architectures, Concepts, and Code | by Diwakar Kumar | Medium

【1】Redmine AI Helperプラグインのマルチエージェントモデルは優れていると思った。

Redmine AI Helperプラグインのマルチエージェントモデルでは、Issueエージェント、Wikiエージェント、Userエージェントなどの機能に特化したエージェント群と、GitHubエージェント、Slackエージェント、メールエージェントのようなMCPエージェント群が協調して、互いに会話しながら動作する。

その時に、マルチエージェントモデルのアーキテクチャとして、@haru_iidaさんは、Networkではなく、Supervisorを選んだ。

第29回redmine.tokyo勉強会

2025年の年始に読み直したいAIエージェントの設計原則とか実装パターン集

Building Multi-Agent Systems with LangGraph and Ollama: Architectures, Concepts, and Code | by Diwakar Kumar | Medium

なぜ、Supervisorを選んだのか？
redmine.tokyo勉強会の講演で聞いたときは、NetworkよりもSupervisorの方がエージェント同士のレスポンスがいいと話していた。

理由は色々推測できる。
おそらく、複数のエージェント同士で処理を実行するために会話させたならば、誰かが全体の処理を監視してコントロールしなければ、変な方向に行ってしまう場合が多いのだろう。
エージェント同士のコミュニケーションパスが多くなるほど、統制が効かなくなるはずだ。
つまり、人間集団や組織と同様に、コミュニケーションパスを減らし、1人の管理者がコントロールできる範囲に収めるようにしなければ、本来実施して欲しい処理の品質が悪くなるのだろう。

では、Supervisor型のエージェントモデルでは、どんなコミュニケーション構造を取っているのか？
@haru_iidaさんの設計では、仮想チャットルームを作り、Supervisorが必要なエージェントのみをチャットルームに召喚して処理を実行させている。
仮想チャットルームは、まるで人間のSlackみたいな感じだ。

第29回redmine.tokyo勉強会

つまり、Slack上でエージェント同士が、チケットを更新する処理のために、Supervisorがまずエージェント達にゴールを共有した後、SupervisorがUserエージェントやIssueUpdateエージェントと会話してるイメージ。
エージェントは仮想プログラムに過ぎないのに、人間のように振る舞う点がすごく面白いと思った。

実際の仕組みは想像になるが、Supervisorやエージェント同士が会話するログのテキストファイルがあって、そのログテキストにあるプロンプトからファンクションコールされてエージェントがキックされるのだろうと思う。
つまり、会話ログというテキストファイルが仮想チャットルーム、すなわち、Slackみたいなイメージになるのだろう。

そのSlackにプロンプトが書かれると、処理すべき機能に対応するエージェントがファンクションコールで呼び出されてキックされて、プロンプト通りにエージェントが実行するわけだ。

そんな仕組みを考えると、処理を実行するプロンプトの背景、ゴールを明確に定義する必要があるだろう。
つまり、AIでよく言われるコンテキストが重要になってくるだろう。
なぜならば、背景や前提条件、制約条件というコンテキストが明確でなければ、期待した結果が出てこないからだ。
実際、ChatGPTでも前提条件を細かく書かないと、欲しい結果がなかなか出てこない。

こういうエージェントモデルでは、各エージェントのフォルダにコンテキストを事前設定するプロンプトを配置して、エージェントを制御する仕組みがあるらしいので、おそらく@haru_iidaさんは事前プロンプトにかなりのノウハウを組み込んでいるのではないかと想像する。

【2】Redmine AI Helperプラグインのアーキテクチャ構造も優れていると思った。

内部構造では、ユーザ要求処理、ビジネスロジック、外部サービスの3層構造に綺麗にレイヤ化されている。
具体的には、Webアプリ層、Agent層、MCPサーバやLLMの層の3層構造に綺麗に設計されている。
これはすごく綺麗だ。
アーキテクチャをちゃんと理解できる人しか組めないような綺麗なアーキテクチャだ。

第29回redmine.tokyo勉強会

わざわざ、マルチエージェントモデルを3層構造で分けたメリットは何なのか？
オブジェクト指向設計に慣れている人ならば効果はすぐに理解できるはずだ。

ユーザがMCP Agentや各機能に特化したドメインのAgentへ処理を実行させたい時、その処理は中身は違っても操作としては共通のインターフェイスを持つはずだ。
つまり、ユーザ要求処理とビジネスロジックの間に、Agent抽象化レイヤーを入れて、Agentへ指示する操作をインターフェイスで抽象化すれば、ポリモルフィズムを使って制御すればいい。

同様に、MCP AgentがGitHubやSlackに連携させたい時、MCP抽象化レイヤで操作をインターフェイスで抽象化しておけばいい。
あるいは、IssueAgentがOpenAIやAnthropicのLLMを使いたい時、LLM抽象化レイヤで操作をインターフェイスで抽象化すればいい。
そうすれば、LLMのバージョンが上がって追加したくなる場合、ビジネスロジック層のプログラムを変えることなく、簡単に追加したLLMを利用できるようになる。
つまり、抽象化レイヤがあるおかげで機能追加や機能修正のプログラミングが非常に楽になる。

僕は、この内部構造のアーキテクチャを見て、AIエージェントの仕組みを理解できた。
さらに、最近、AIの機能を入れました～とあらゆるWebサービスやパッケージ製品で広告を見かけるが、おそらくそれらシステムも@haru_iidaさんのようなアーキテクチャ構造に似た構造になっているに違いないと思った。
そうでなければ、大量の人員とお金を投資した案件なので、今後のシステム保守を考えれば元が取れないはずだ。

【3】Redmine AI Helperプラグインの根本テーマに「プロジェクト管理にもAIを」がある点がすごくいい。
AIが当たり前の現代では、ソフトウェア開発であれ、ホワイトカラーの仕事であれ、経営戦略をねったり、プロジェクト管理することも全てAI駆動になる。
AIを使うだけでなく、AIでいかに価値を出すか？

Redmine AI Helperプラグインによって、RedmineをAI駆動プロジェクト管理に変える可能性を秘めている。
従来は、Excelによるプロジェクト管理からの脱却がメインテーマだったが、現代では、AI駆動のプロジェクト管理により、プロジェクトリーダーやプロジェクトマネージャは本来の意思決定に専念できるようになる。
そんな機能が沢山盛り込まれているし、今後の機能追加により、さらに発展するだろう。

Redmine AI Helperプラグインは、そういう機能追加がやりやすいエージェントモデル、アーキテクチャ構造になっているので、今後の開発にすごく期待できる。
今後もウォッチしていきたいと思う。

第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で社内標準プロセスをテンプレートで実装すれば、各案件に展開すればいい。

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

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

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

【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のあるべき姿を提示した点にある。

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

「スクラムの拡張による組織づくり」のScrum@Scaleの感想

「スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する」をざっくり読んだ。
ラフな感想をメモ。

【参考】
大規模スクラムはLeSSとSAFeのどちらが良いのか: プログラマの思索

SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説: プログラマの思索

プロダクトマネジメントの感想～プロダクトオーナーはもっとチームの外のユーザに寄り添うべき: プログラマの思索

認定スクラムプロダクトオーナー研修の感想: プログラマの思索

スクラムは境界を生み出す: プログラマの思索

文化は組織構造に従う: プログラマの思索

More Effective Agileは良い本だ: プログラマの思索

【1】Scrum@Scaleというアジャイル開発の大規模開発プロセスがどんな内容であるのか、に興味があった。
詳細は「スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する」に書かれているのであえて記載する必要はないと思う。

むしろ、既存のLeSSやSAFeと比較して何が異なるのか、が重要だろうと思う。

LeSSは1人のプロダクトオーナー、1つのプロダクトバックログから成るので、1個の製品を複数チームで開発するスタイルみたいなイメージを持っている。
たぶん、この形のスクラムが一番スケールしやすいと思う。
一方、プロダクトオーナーに負荷がかかりやすい弱点があるから、エリアプロダクトオーナーを設けたり、プロダクトオーナーを支援する人やチームを別途作るケースが多いように思う。

SAFeはアジャイル開発の官僚的組織、官僚的プロセスに近いイメージを持っている。
3つのレベルを持ち、開発チーム、リーダー層、経営層でそれぞれ役割分担したアジャイル開発を進めるイメージ。
大規模なシステム開発では、組織やプロセスを整備する必要があるから、SAFeのような仕組みは必要になるだろうと思う。
一方、RUPのようにテーラリングが必要なので、戦略的にカスタマイズを実施しないと難しいだろうと思う。

Scrum@Scaleは、スクラムチームのスケールだけでなく、プロダクトオーナーもスケールも実現する。
つまり、最低限の官僚的組織は持つが、開発チームだけでなくプロダクトオーナーも複数あり、協調動作するスクラムチームごとにプロダクトバックログを持つから、複数のプロダクトバックログを扱うように動く。
この点が他の大規模スクラムと違って、より柔軟な仕組みを持っているように思った。
EATやSoSのような組織を見ると、複数の開発チームやプロダクトオーナーが協調動作するように役割分担しているのに気づく。
レポートラインも最低限の官僚的組織としてうまく整備されている印象を持った。

【2】チャットサービスの開発現場で組織構造が変遷される内容がとても興味深い。
ChatWorkの開発現場だと思うが、最初はUI/UXのチームが重視され、途中で統合認証のような共通基盤の開発チームが入ってきて、最後は統合認証基盤チームは退出し、データマイグレーションなどのTeamsだけが残る。
つまり、チャットツールのビジネス発展に応じて、開発する機能が変わるので、それに応じた開発組織が必要になる。
そうした開発チームはチャットツールという製品の開発フェーズに応じて、新規に入ったり、退出したりして入れ替わる。
そういう組織の入れ替えを意識的に行っているのが味噌と思う。

また、こういう組織の入れ替えは、逆コンウェイ戦略の良い事例になっている。
なぜならば、製品の開発フェーズに応じて、重視される機能やアーキテクチャが変わるので、それに応じた組織を当てはめるべきであり、そういう組織を入れ替えるべきだ、という考え方になるからだ。

では、一般のユーザ企業の基幹系システム開発でも、こういうやり方は通用するだろうか？
たとえば、基幹系システム開発でも、機能追加やリプレース、法規制対応などにより、システムのフェーズは変わる。
基幹系システム開発でアジャイル開発を実践できているならば、Scrum@Scaleのような大規模開発も取り入れることはできるだろう。
つまり、基幹系システムのフェーズごとに開発チームを入れ替えて、逆コンウェイ戦略を実現することは不可能ではない。

しかし、一般の基幹系システム開発では、WF型開発が主流であり、アーキテクチャもインフラ層、データベース層、アプリ層などのように分割されて、それに応じた開発チームから成り立つ組織が多いと思う。
だから、Scrum@Scaleのように開発チームを頻繁に入れ替えるような逆コンウェイ戦略を実現するのは難しい状況が多いのではないか。

また、基幹系システム開発でスクラムを実践できていても、複数のプロダクトバックログを協調動作するように運用するのは、マネジメント上やはり難易度が高いと思う。

【3】「スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する」は日本の現場の事例もあって良い本と思う。
LeSSやSAFeとの違いについてはもう少し考えてみたいと思う。

LeSSは「大規模スクラム Large-Scale Scrum」の本がお勧め。
SAFeは「SAFe 4.5のエッセンス」の本がお勧め。

「More Effective Agile ソフトウェアリーダーになるための28の道標」では、SAFeが推奨されていたので参考にしている。

ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2～プロセスのレイヤと達成目標のレイヤが異なる

ストラテジストとプロジェクトマネージャの役割の違いは何なのか？
ITコーディネータ研修を経験して、IPAが定義するストラテジストとプロジェクトマネージャの役割の違いを自分なりに理解したことをメモ。
ラフなメモ書き。

【参考】
IPA 独立行政法人 情報処理推進機構：制度の概要：ITストラテジスト試験

IPA 独立行政法人 情報処理推進機構：制度の概要：プロジェクトマネージャ試験

【1】ストラテジストとプロジェクトマネージャでは、担当するプロセスのレイヤが異なる。

プロジェクトマネージャの担当領域は、個別プロジェクトのキックオフからリリースまでが一般的だ。
たとえば、SIerのプロジェクトマネージャであれば、請負契約でシステム開発を請け負っているはずだ。

一方、ストラテジストの担当領域は、複数のプロジェクトの内容が固まってRFPやプロジェクト計画書が完成するまでの企画フェーズと、プロジェクトが完了してリリースしたシステムが稼働した後の効果検証フェーズの2つだ。

たとえば、ユーザ企業の事業戦略に基づき、その事業を成功するためのシステムを構築したり、事業を支える業務を支援するシステムが必要になったとする。
事業の規模や業務の規模が大きければ、複数のシステムを構築する必要があるから、複数プロジェクトを並行で走らせる計画を作る。
そういう複数のプロジェクトではそれぞれ、どんなシステムが必要なのか、いつまでにシステムをリリースする必要があるか、を決める。
一般に企画フェーズで、事業戦略に基づくシステム化構想が練られることになる。

さらに、そのシステムをリリースした後、当初想定していた投資対効果が得られているか検証し、さらに改善していく必要がある。
それがリリース後の効果検証フェーズになる。

すなわち、ストラテジストの役割は、プロジェクトマネージャにプロジェクト計画書をお膳立てすることと、プロジェクトマネージャがリリースしたシステムが経営戦略の目標に合致しているか検証することになる。

ストラテジストはシステム化計画とシステムの効果測定だけであり、プロジェクトの実行フェーズはプロジェクトマネージャに委ねる。
よって、ストラテジストとプロジェクトマネージャの担当領域は明確に異なる。

【2】ストラテジストとプロジェクトマネージャでは、彼らの評価指標が明確に異なる。

プロジェクトマネージャは既に決められたQCDを元にリリースする責務がある。
たとえば、SIerのプロジェクトマネージャならば、ユーザ企業と握ったRFPを元に、初期投資予算、マスタスケジュール、体制図、システム要件が基本は確定した範囲内で、それを具体化してシステムとしてリリースする責務がある。
つまり、プロジェクトマネージャの評価指標は、当初決められたプロジェクトのQCDとの差異分析で決まる。

一方、ストラテジストは事業戦略に基づくシステムを構想したからには、そのシステムが事業に貢献したという投資対効果、つまりROIがストラテジストの評価指標になる。

たとえば、ユーザ企業が新規顧客を開拓するような新規事業を実行しようと決めて、ECサイトが必要になったと検討したとする。
ストラテジストは、そのECサイトは5カ年計画でどれだけの売上と営業利益を確保できるか、初期投資で数千万円や数億円をかけて投資してどれだけ売上を確保できるか、売上と営業利益のシミュレーションを計画する。
その売上を確保するには、ECサイトにはどんなシステム要件、業務用券が必要なのか、洗い出して確定する。
そして、そのECサイトの構築をプロジェクトマネージャに委ねてリリースしてもらった後、数ヶ月や数年をかけて、ECサイトの売上や利益を計測していく。
当初の計画と5カ年の実績の差異分析、つまり投資対効果がストラテジストの評価指標になる。

プロジェクトマネージャの評価指標がプロジェクトのQCDである事実より、プロジェクトマネージャへのプレッシャーはとても大きい。
しかし、ストラテジストの評価指標がシステムの投資対効果である事実を考えると、ストラテジストへのプレッシャーの方がはるかに大きいと思う。
なぜならば、プロジェクトマネージャの担当範囲は所詮、個別プロジェクトだけだが、ストラテジストの担当範囲は事業目標を達成するために平行に走らせるように計画された複数プロジェクトなのでとても広いからだ。

【3】ストラテジストとプロジェクトマネージャでは、利用するモデルや管理手法が明確に異なる。

プロジェクトマネージャは当初定められたプロジェクトのQCDを守るために、WBSとガントチャートによる進捗管理と課題管理が必須だろう。
もちろんそれ以外にも変更管理、品質管理など色々あるが、PJ管理手法のベースにはWBSとガントチャートがある。

一方、ストラテジストは、事業目標よりブレイクダウンされたシステムの投資対効果を達成するために、CSFとKGI、KPIのPDCA管理が必要になる。
事業目標を達成するために、BSCのように財務・顧客・業務・組織と人材の観点での中間目標（CSF）に分解したり、事業部内の各部署に業務分掌となる達成目標（CSF）が定められることになるだろう。

このCSFの考え方は、WBSみたいなものだ。

ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1～CSFはWBSみたいなものと捉える: プログラマの思索

そして、CSFという中間目標を達成できたか否かを定量的に判断するために、KGI/KPIが必要になる。

たとえば、売上や利益の確保という財務レイヤの最終目標に対し、売上高や営業利益率というKGIが出てくる。
そのKGIを達成するには、顧客や市場の観点で、新規顧客獲得数や購買単価、顧客満足度などのKPIが出てくる。
たとえば、BtoCビジネスのECサイトで出てくるAARRRも該当するだろう。

それらを実現するためにさらに業務レイヤで、顧客訪問回数、受注獲得率、顧客提案回数、業務効率化につながる工数削減の度合い、作業時間の短縮度合いなどのKPIも出てくるだろう。
さらに、それらの業務を実行する人材や組織の観点で、有能な人材を示す専門資格者数、研修回数、社内教育、従業員エンゲージメント率などのKPIも出てくるだろう。

つまり、ストラテジストが計画した諸々のシステムは計画時点でそれらKGI/KPIの目標値が設定されて、リリースされたシステムが稼働している間、KGI/KPIをシステムで自動的に測定して、投資対効果を評価することになる。

【4】自分がJavaアプリ開発者だった頃、プロジェクトマネージャの仕事ぶりは実際に見ることができたから、彼らの役割や責務は想像することができた。
しかし、ストラテジストを実際に見かける機会はなかったから、彼の役割や責務を想像することは難しかった。

ストラテジストはユーザ企業の経営戦略や事業戦略をベースにシステム化構想を検討するので、MBAで出てくるような経営戦略ツールを使って、外部環境・内部環境分析を行い、経営課題やCSFを洗い出す技法が必要になる。
つまり、ストラテジストに求められるスキルには、経営課題を解決するためのシステムの骨格を生み出すためにシステムアーキテクトのスキルは必要な前提の上で、外部環境・内部環境分析と経営課題・CSFを確定するための経営戦略ツールも必要になってくる。

たとえば、外部環境分析なら5Fs, PEST分析、内部環境分析ならVRIO分析やバリューチェーンなどのフレームワークを使う。
たとえば、経営課題の抽出であれば、SWOT分析で各要素を洗い出した後、経営戦略の方向性や企業の制約条件を元にクロスSWOT分析から、あるべき姿という経営課題を洗い出す。
その経営課題をCSFへ置き換えたり因果関係にまとめてBSCに当てはめて、各レイヤや各部署のCSFとKGI/KPIに落とし込む。
そこから、どんなシステムが必要になるか、複数個のシステムを洗い出して、具体的なシステム化計画を策定していく。
たぶんそういう流れ。

よって、ストラテジストの所在はユーザ企業の経営層や経営企画部、事業企画部、情報システム部門の領域にある。
つまり、SIerの中の一人の開発者から見れば、ストラテジストははるか遠くのところに位置しているので、彼らの目に止まりにくい。

【5】しかし、アプリ開発の専門技術者とプロジェクトマネージャ、ストラテジストは役割が異なるだけであって、そこに優劣があるわけではない。

実際にシステムを構築するために、システムアーキテクト、ネットワークスペシャリスト、データベーススペシャリスト、エンベデッドスペシャリスト、セキュリティスペシャリストなどの各専門技術者も必要だ。
色んな専門スキルを持つ人達が集まって、彼らが一つのチームとして形成して初めて、一つのシステムのリリース、さらには事業目標が達成される。

現代のシステム開発は色んな領域の専門家集団が必要であり、彼らがチームとして成り立ち、協働することが必要になっているわけだ。