エンタープライズアジャイルは袋小路に陥っているのではないか
最近のアジャイル開発の事情を書いた記事があったのでメモ。
ラフなメモ書き。
【元ネタ】
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は必ず失敗する: プログラマの思索
そういう観点があるから、プログラミング技術一辺倒よりも、利用部門の人達を巻き込むためのファシリテーション力や業務改革を推進するエバンジェリストのような能力の方が重要視されるだろうと思う。
したがって、アジャイル開発が生み出した「開発プロセスを支える技術」を深く掘り下げるよりも、人を巻き込むためのファシリテーションやリーダーシップ、エバンジェリストなどの能力が必要とされる。
それは最終的には、社内政治のようなスキルに近いだろう。
そんなことを思うと、エンタープライズアジャイルは袋小路に入っていると思う。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「プロジェクトファシリテーション」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 「世界を動かすプロジェクトマネジメントの教科書」の概念図(2022.01.16)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- 昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと(2021.12.31)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
「Agile」カテゴリの記事
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
「経済学・ERP・財務会計」カテゴリの記事
- ビジネス書の名著はどれ?(2023.09.18)
- 第85回IT勉強宴会の感想~概念データモデルからビジネスモデルを構築すべきという考え方(2023.05.13)
- 令和4年度春期試験のITストラテジスト試験第4問をastahでモデル化してみた(2023.04.15)
- 経営戦略とIT戦略をつなぐ鍵は何なのか(2023.01.04)
- 計量政治学と計量経済学の考え方の違い(2022.10.02)
コメント