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

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

「世界一流エンジニアの思考法」の感想

「世界一流エンジニアの思考法」を読んでみた。
気づきをラフなメモ書き。

【1】試行錯誤は悪であること。
本番障害の原因調査でも、手当たり次第、ログから調べて探すのは生産性が悪い。
事実から仮説を1つずつ立てて、その仮説を1つずつ検証して可能性を潰していく。

試行錯誤が良くない理由は、後で得られる経験知がないからだ。
やみくもにモグラ叩きのように潰して、ああ終わったというだけ。
障害解決した一つの経験が後で活用できない。

事実から推測して、起きそうな仮説を複数パターンで立ててみる。
そこから1つずつ潰していくことで、自分のロジックを検証していることにもなる。
どこに原因があったのか、後で振り返るときにも役立つ。

すぐに手を動かさない。まず仮説を立ててアプローチを選択して一つずつ動かす。
分かっていれば当たり前なのだろうが、納期に迫られて焦っているときほど忘れやすい気はする。

【2】コードリーディングのコツは極力コードを読まないこと。
すべての実装ロジックを理解しようとすると、脳みそのメモリが浪費されて余裕がなくなる。
空きメモリがなくなる。

動くものと仮定して、中身のロジックよりも、インターフェイスの役割やパラメータを調べて、関係性や動作を構造化することに注力する。
全体像を把握することと同じだろう。
この辺りは、コンポーネント図やシーケンス図、ステートマシン図、クラス図などを書きながら、構造を理解する方法もあるだろう。

コードリーディングは重要だが、いかに自分の脳みその負担を減らすか、に注力する。
自分にとって難しすぎると感じるときは、脳の使い方が間違っているというメッセージになる。

頑張る人、完璧主義の人、焦っている人ほど、脳みその空き容量がなく、脳みそを有効活用できていない。
そういうマインドセットを持つことも大事だと思う。

【3】日本独特の批判文化はソフトウェア開発と相性が悪いこと。
日本人は完璧主義すぎて、機能の網羅性や機能の品質を重視しすぎるために、ソフトウェアを漸進的に開発して品質を改善するやり方に馴染めていない。
最初に出したバージョンからソフトウェアに完璧を求める。

日本人は責任の所在や完璧を過剰に求めることで、開発者の心を砕いてしまう。
ソフトウェア開発者が先陣を切って何かにトライする行動に足かせを作らせる。
嫉妬、批判、冷笑、嘲笑が新しいことへのチャレンジ精神を阻害する。

人に何かを期待するのではなく、まず自分がどういう貢献ができるかという公共性をベースに考える。
これにより、互いにありがとうという感謝の精神が生まれる。

しかし、日本では理不尽なカスタマーハラスメントが起こりやすい潜在的な土壌が多い。
つまり、日本ではアジャイルなソフトウェア開発をやりにくい精神的土壌がたぶんあるのだろう。
従来からずっと言われているように、日本でソフトウェア開発がなかなか上手くいかない理由の一つは、国民性や文化的な側面もかなりあるのかもしれない。

また、日本の産業界ではハードウェア文化が強すぎて、ソフトウェアを甘く見てきている節もある。
どうしてもプログラマよりもマネージャ職の方が待遇面もキャリアも良いように制度も文化も作られてきた。
よって、アジャイル開発のように、現場の開発チームのメンバーが自分で実際に作って動かして、ソフトウェアを使って組織や世界を変えていくという方向性を実現しづらい。
現代のイノベーションは素人が集まっても作れるわけではなく、技術やクリエイティビティを持つ専門家集団がリードする必要があるだろう。

マイナンバーカードやデジタル庁、標準の公共システム開発にしても、色々頑張ろうとしているが、乗り越えるべきハードルは大きい。

【4】牛尾さんの本は過去にもたくさん読んできたが、「世界一流エンジニアの思考法」も同様に、文章は丁寧で読みやすく、内容は新たな価値に気づかせてくれる内容が多い。
アジャイル開発に慣れていれば当たり前の話だろうが、日本人がこれから乗り越えるべきハードルが書かれているので、非常に示唆に富む本ではないかと思う。

世界一流エンジニアの思考法 [ 牛尾 剛 ] 価格：1,760円（税込、送料無料) (2024/12/8時点) 楽天で購入

「システムアーキテクチャ構築の原理」の感想part2～非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する

「システムアーキテクチャ構築の原理」を読んでる。
平鍋さんの記事「『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita」を読み直して、理解が深まった。
平鍋さんの記事に触発されたので、理解できたことをラフなメモ。
間違っていたら後で直す。

【参考】
『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita

「システムアーキテクチャ構築の原理」の感想: プログラマの思索

【1】「システムアーキテクチャ構築の原理」を読んでいて分かりにくかったことは、ビュー、ビューポイント、パースペクティブという概念が出てきて混乱したこと。
これらの言葉は何を表しているのか、具体的に理解できていなかった。

平鍋さんの記事「『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita」では、概念モデルでまとめてくれているので理解しやすかった。

@hiranabe さん記事を理解したうえで「ビューとビューポイントの違いは何？」の意見に対する私なりの回答は以下の通り。 ・ビュー＝ステークホルダーの横断的関心事をシステム観点で記述した内容。 ・ビューポイント＝横断的関心事。ユーザ観点。 ・パースペクティブ＝主に非機能要求。システム観点。

— akipii (@akipii) May 6, 2024

【2】図4-3.コンテクストにおけるパースペクティブが「システムアーキテクチャ構築の原理」のメッセージを全て表している。
平鍋さんの解説が分かりやすい。

（引用抜粋　開始）
「非機能要件がシステムのアーキテクチャに影響を与える」という観点を本書は、この言説を徹底的に解説したもの。

非機能要件に限らず、横断的な視点を「パースペクティブ」として捉えている

実際にアーキテクチャを記述しようとすると、１つの文書ではとっても複雑で巨大な説明になる。「ステークホルダー」の「関心事」毎に分割するために、「ビュー」と「ビューポイント」を導入する

「パースペクティブ」は、従来の言葉で近いものとして「非機能要求」「横断的関心事」がある。本書ではこの「ビューポイント」と「パースペクティブ」のカタログを作っています。
（引用抜粋　開始）

【3】図15-1.ビュー間の関係では、ビューを開発や運用の観点で分解している。
この図は、システム開発とシステム保守で分割すれば理解しやすい。
今ならDevOpsだから、開発も運用も一体化しているだろう。

【4】図7-3.アーキテクチャ定義のプロセスは、「システムアーキテクチャ構築の原理」が提唱している、アーキテクチャを定義し評価するプロセス。
アーキテクチャ設計の中で、特に非機能要件を含めた横断的関心事をいかにアーキテクチャに盛り込むのか、を考えた一連のプロセスになる。
プロセスの流れは、アーキテクチャ要素や横断的関心事を段階的詳細化して組み立てたあとにアーキテクチャを評価するので、違和感はない。

【5】「システムアーキテクチャ構築の原理」では上記3つの図が本書のメッセージになると思う。
本書のやり方を各システム、各案件にテーラリングして設計、実装する必要があるから、本書は、アーキテクチャ設計のメタ概念、メタプロセスの解説書みたいな感触を持っている。

【6】「システムアーキテクチャ構築の原理」の副題「ITアーキテクトが持つべき3つの思考」が指す「3つ」とは、「ステークホルダー」「ビューポイント」「パースペクティブ」と最初に書かれている。

その意図は、ステークホルダーの横断的関心事、特に非機能要求をユーザ観点のビューポイント、システム観点のパースペクティブで分解して組み立てて、トレードオフを考慮したアーキテクチャを設計すること、を意味していると考える。

他にも気づいた他内容があれば書いていく。

「スクラムの拡張による組織づくり」の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が推奨されていたので参考にしている。