エンタープライズアジャイルは袋小路に陥っているのではないか
最近のアジャイル開発の事情を書いた記事があったのでメモ。
ラフなメモ書き。
【元ネタ】
Agile2014に参加してみて分かった昨今の世界のアジャイル事情 - THE HIRO Says
もはやウォーターフォールだけでは通用しない:エンタープライズアジャイルが難しい理由と、実践の「現実解」 - @IT
動き出した エンタープライズアジャイル - 導入効果を「最大化」する5箇条:ITpro
(引用開始)
一方で今年参加してみて、下記の図にあるような傾向が見えるようになってきました。
Agile/Scrum/Lean/XP 自体は既に当たり前になっており、それらをどうよりうまく活用するかに焦点が移ってきている。
アメリカのコンサルを中心に「Enterprise Agile」が流行っているが、一方でこれに嫌悪感を持つ勢力も増えつつある。
BDD/ATDD を中心に、Testing のセッションに改善がみられる。
Metrics のセッションが増えてきた。
(引用終了)
(引用開始)
1. Enterprise Agile
「Enterprise Agile」とは、簡潔に言うと、企業全体レベルでのアジャイルを実現しようという考え方・方法論のことです。
(一部で「大規模アジャイル」と表記されていることもありますが、この表現だと「大規模プロジェクトでのアジャイル」だと誤解されやすい/そのような意味で使う人もいるので、「企業全体レベルでのアジャイル」とした方が妥当だと私は考えています。)
なのですが…技術面などの実現基盤については一切語らず、「メンバー全員が幸せになれるモチベーションを作るべきだ」のように空虚な「精神論」だけを言っている人が非常に多いのが気になりました。
こういうことを言う人は、アメリカでコンサルをやっている人に多かったです。
こうした発表は、アメリカ人参加者には非常に受けが良いのですが、他の国の人(カナダ含む)はしらけていました。
弊社のアメリカ人の多くが「アジャイル」と耳にすると「いい加減なこといいやがって!」と反応するのが不思議だったのですが、今年カンファレンスに参加してようやく理解できました。
例えば、コチラの動画を観ていただきたいです。ダンスをして楽しくなっても、良いプロダクトは作れないと思うのですよ。
そうした一方で、昨年一部で物議を醸していたSAFe(Scaled Agile Framework) が着々と勢力を広げつつあり、特に今年は SAFe をテーマにしたセッションが5つほどありました。
(引用終了)
エンタープライズアジャイルの定義は色々あるだろうが、僕は「企業向けの基幹系業務システム開発にアジャイル開発を取り入れた手法」と理解している。
日本のSIでも、B2Bの業務システムの受託開発案件が非常に多いだろう。
しかしながら、上記の記事では、エンタープライズアジャイルを標榜する人達が、技術面の話よりもチーム運営や精神論に走っているという指摘をしているが、非常に興味深い。
僕もアジャイル開発に興味を持った理由は、従来にない技術を持っていたことや、スピーディな開発を支える技術を揃えて開発プロセスをIT化する点だったから、この手の話はイマイチのりにくい。
基幹系業務システム開発にアジャイル開発を取り入れた場合、我々がよく知っているアジャイル開発プロセスは実現しづらいと思う。
基幹システムだから大規模にならざるを得ず、最初に開発スコープのブレを抑えつけないと、その後の開発が迷走しがち。
だから、仕様凍結に近い手法を取らざるを得ず、ウォータースクラムフォールまたはハイブリッドアジャイル開発のように、下流工程のみアジャイル開発のような手法を取らざるをえない。
また、業務システム開発の場合、CIOの観点では、システムを開発するだけでなく、システムをいかに利用してもらうか、という点の方が重要だ。
情報システム部門の役割は社内にシステムを導入して、利用者を増やして、業務を効率化することにあるので、いかに社員を巻き込むか、という点が重要になる。
つまり、「プロフェッショナルCIOの教科書」に書かれた内容のように、社員の意識改革に注力するようになる。
すると、オペマミやら運用ガイドラインなど、たくさんのドキュメントを作らざるを得ず、アジャイル開発の良さである「動くソース重視主義」が取りづらい。
また、情報システム部門のメンバーは、プログラミングよりも、利用部門にシステムの良さやシステムの使い方を説明する方に力を注ぐから、技術一辺倒とはなりにくい。
「プロフェッショナルCIOの教科書」の感想~調整型CIOは必ず失敗する: プログラマの思索
そういう観点があるから、プログラミング技術一辺倒よりも、利用部門の人達を巻き込むためのファシリテーション力や業務改革を推進するエバンジェリストのような能力の方が重要視されるだろうと思う。
したがって、アジャイル開発が生み出した「開発プロセスを支える技術」を深く掘り下げるよりも、人を巻き込むためのファシリテーションやリーダーシップ、エバンジェリストなどの能力が必要とされる。
それは最終的には、社内政治のようなスキルに近いだろう。
そんなことを思うと、エンタープライズアジャイルは袋小路に入っていると思う。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 掃き溜めの鶴を活かすマネジメント、それは強みSと環境Oを組み合わせたクロスSWOT分析と同じだ(2026.10.01)
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
- 製造業でアジャイルが定着しない理由~スプリント不在とチケット二重管理の壁 #Redmine(2026.07.18)
- Redmine利用成熟度モデルによる運用戦略(2026.07.12)
「プロジェクトファシリテーション」カテゴリの記事
- ふりかえり手法にジョハリの窓を使って自己開示と他者フィードバックを得る(2026.09.27)
- 組織変革の鍵を「聞く」体験から探る(2026.06.14)
- PM理論で読み解く日本人リーダーの弱点(2026.05.12)
- astahでPJ管理もプロセス設計もアイデア発想も全て表現したい(2025.10.25)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「Agile」カテゴリの記事
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- AI時代の「コードと人間の関係」を問い直す—デブサミ関西2026で考えた、アーキテクチャの未来とコミュニティの価値 #devsumi(2026.08.22)
- チケット駆動でAIを制御する仕組みのアイデア(2026.08.13)
- アジャイル開発を強化するキルチェーン進化の歴史~VUCA時代におけるモノづくりの新アーキテクチャ(2026.08.11)
- 脱PDCA!DXを加速する超高速戦略「KillChain」(2026.08.10)
「経済学・ERP・財務会計」カテゴリの記事
- すり合わせの優位性は健在か?日本の製造業が直面するPLM活用とMBSEソフトウェア運用の理想と現実(2026.03.29)
- DX戦略はDX成熟度を考慮して戦略策定すべき(2026.03.20)
- データモデリングではシステムが宿命的に負う複雑性をどのように解決しようとしているのか(2026.02.14)
- データモデリングの手法をあなたは持ってますか? at 関西IT勉強宴会(2026.02.11)
- E-BOMとM-BOMの違いは何か?(2026.02.08)


コメント