IT解雇祭りとアジャイル終了の相関性
日本国内では完全性を求める国民性から、ウォーターフォールモデルが現在も多くアジャイルはweb系などデザインの割合が多いライト開発で「ゆるく」実践されていると思いますが、日本でガチのDevOpsが広まる前に陳腐化し終了する雰囲気が濃厚になってきました。
なんといっても、本家の人まで自己否定をしてしまいましたので。。。
記事：アジャイルは失敗だった
私と私の友人全員が天才的な神託者であるか、アジャイルがそもそも本当に愚かなアイデアであったかのどちらかです。この愚かさの主要な伝道者であるクリフ・バーグ氏は、長年の苦しみの末、ついにアジャイルの失敗を認めました。
Tamás Polgár
アジャイルとその醜いろくでなしの子供であるスクラムのアイデアに、計り知れない数百万ドルとその他の通貨が浪費されてきました。無数の才能のない愚かな人々が大企業で安全な仕事を見つけ、そこでは単に流行語をオウム返しにし、意味のないカードやカラフルなチャートで一日中遊んでいた。
記事があまりに的確なので、記事を読んでニヤニヤしてしいました。しかし、発案者まで失敗を認めるって、javaScriptやPHPに通じる物があります。Web系にありがちな製造業の闇を感じます…。
アジャイルはやりがい搾取？
※日本だとまだアジャイルに夢を抱いていたり、商材にしている人が多そうなので、あえて見たくないものを見ないで済むように有料にしました。
返金は１００％受け付けますので、読みたい方はどうぞ。
社畜文化が強い日本では、そもそも個人が意見をあまり持っていないので広告や会社の都合に「寄り添う（≒奴属）」する傾向ですが、海外で検索するとうわーっと出てまいります。2018年くらいから話題となり傾向が強くなったのは２０２１年のコロナ終了あたりからでしょうか。
ワイワイやらされていたけど、実は嫌だった！という心の叫びが沢山記事になっています。（笑
アジャイル神話がコロナで崩壊？
個人的な私見ですが、海外では日本のように同調圧力で労働搾取がし辛い環境があり、アジャイル＆チームの責任！としてデスマーチ気味で作業をしていたチームが、コロナでリモートになりスプリント朝ミーティングなどで精神拘束が弱まる中で制御不能になったり、遅延の責任を作業者やリーダーに押し付けづらい状況がふえるなか、「アジャイル、嫌じゃね？」というムードが一気に（裏で）広がっていったように思います。
…とはいえ、そんなことになる前から海外ではかなり反対意見は動画などになっていましたが。↓
日本語字幕がありわかりやすい動画です。
技術は日々進歩するが、ソフトウェアの管理や人の進歩はそれに追いつけない、というもの。
アジャイルが広まった前提
前提として、アジャイルのムーブメントは
a) パッケージからオンライン販売と頻繁なアップデートになった
b) ノートパソコン、スマホの普及で利用者が急増、アプリ特需
があり、急激に熟練の開発者が足りなくなった背景があります。
人が居ない＝＞未熟な人に実戦で働かせる、というパッケージソフトでは禁止されていた（ちょっとやばい）ことが当たり前になります。無料で配る事が増え苦情の心配が少ないことや、アップデートの費用が安く企業がバグなど不良を以前より恐れなくなったからです。
要するに、アジャイルという名目で経験や知識がない人たちをチームにして（※）ワイワイやらせておけばOK,という企業のメリットと、就職したい働く人のメリットが合致して間違った方向で広がったのが真相です。簡単に言えば、アジャイルをうたったやりがい搾取。びっくりしますが「経験がなくてもアジャイル開発に参加できる！」などと、騙されてベトナムまで来て働く日本人がいるのも驚きます。知らないって恐ろしい。
※DevOpsなど開発手法の本を読むとわかりますが、本来は複数のスキルがあり管理者（上司）が必要がない「プロ」だけでチームを作るのが前提の手法です。
動画では、
スクラムのスプリントで毎朝のミーティングは良さそうに見えて生産性・効率性に貢献しない
チームへのデモは無駄な工程
スプリント、デイリースクラムに単に縛られているだけ
JIRAは最悪。表は作れるけどプロセスの管理や向上はできない
プロのスクラムマスターは労働構造でアイデアやパフォーマンスをもたらさない
チームが大きいと（官僚化して）無駄なプロセスを削除できない
要するに、ルールを増やしたらルールのための役職が増え、ルールと役職のために人は働き、本来のアイデアの実現という開発ではなくなっていく、ということでしょう。
当初から疑問視されていたが…。
日本では当初からかなり懐疑的な人も多かったですが海外でも欠点を補ったほうがいいよ？というのは話題になっていました。わたしが主にお世話になったゲーム業界は特に仕事の難易度が高すぎることもあり、そもそも見向きもしていませんでしたが…あくまで工業的なソフト開発の手法なので一点物の日本刀をつくるような匠のレベルとなるとズレが生じますし。
下の記事は多くの人がそろそろiPhoneとか使わないといけないの？って思っていた頃です。
アジャイル開発では、具体的な仕様を定義するなど、優れたプロジェクト管理のプラクティスが損なわれると指摘されることがある。また、スケジュールと予算の管理が難しくなるし、複雑なプロジェクトの場合、プロジェクトチームが簡単な機能コンポーネントから手を付けがちだ。その結果、80％の作業が完了しても、最も難しい機能が残り、この残された20％がプロジェクト全体の成否を左右する要素であることは大いにあり得る。
これ、簡単に言うと「誰でもできる手作業、UIとかデザインならいいけど、ガチの開発では無理」ということなんですよね。開発じゃなくて作業のための手法なのです。
※開発は失敗する可能性がある難易度、製造は出来て当たり前が保証できる難易度、という理解です。フレームワークで組むだけとかは開発じゃなくて製造とよんだほうが言いのかも。
なぜみんな騙されたのか
理由は広告をたくさん出したからですね（笑
実際に騙されたのはみんなではなく、開発に疎い人、乗っかることで金銭的な利益のあるひと、考えるのが苦手な人、の３種類というのがこれまでの経験で得た知見です。
底辺開発のベトナムオフショアの例で説明するとこれは非常にわかりやすくなります。
当事者は以下の３つ
A) 顧客
B) 開発会社（ベトナムオフショア開発）
C) 開発者（作業者）
当事者のメリット・デメリットは、こんな感じ。中学生信勝みたいになります（笑
発注側が仕様書を作り込んで、きちんと管理しないと成立しない準委任契約を選択したことに問題がありますが、都合の良いことを言って仕事を受けているオフショアは詐欺まがいではないの？と思うことがあります。
仕事を取りたいので、顧客がわ必要な作業などリスク面の説明はしませんし、なんなら仕様についてもよく聞かずに取ってから対応、という会社が普通にあります。
ちゃんとした会社もあるのですが
まともな会社さんももちろんあります。厳しくやっているので儲からないみたいですが、本業がありそちらのためにオフショアがアルので良いみたいです（汗
すごい真面目だなと思ったのは
1. アイエンターベトナム
2. エボラブルアジア（現ハイブリッドテクノロジー）
3. バタリフィベトナム
とかでしょうか。無理に受けない、予算とか諸々合わないとごめんなさいするところは日本国内の企業と同じ。１，３は技術者系の人が上にいていわゆる営業＆人貸しだけで稼ぐ無責任体質と文化が違います。２はできる人を高額報酬で集めて進めるアスタリスク社と似た欧米っぽいホワイト文化なので価格も高いです。（笑
ただ、全体としてベトナムの風習や社会のし本具合を考えた時に打率が凄く悪い＋準委任でアジャイル謳いがち、というのは確認事項として見ておくと良いと思います。
アジャイル向けなこと、苦手なこと
アジャイル、スクラムを行うとチームのメンバーが可能な（簡単な作業、目で見て若レベルのデザインなど）、一言でいうとUI作業が進み、APIとUIの結合のバグはぐるぐる手戻りし、アルゴリズム・構造を作る作業は放置される傾向があります。
逆に言えば、UI開発やモック・試作の試行錯誤とか、アルゴリズムは変わらないけど、ユーザーの反応を見てUIを変更するマーケティング施策のための変更作業などには向いているかもしれません。
これはアジャイルを礼賛した時代がGoogle やMetaなど広告業の時代な事と無縁ではないでしょう。彼らはテックと呼ばれても業態は広告屋です。（かっっこよくいうとマーケティングw）
苦手なのは難易度が高い作業、複雑なソフトウェアの開発。とくに「できるかわからないチャレンジ」を伴うことには向いていない気がします。
開発ではなく「作業」を新人や開発力が低いけどやる気はある！という人たちに（最初のちは）気分良く死後をとさせるための方便、と考えるとしっくりきそうです。
資料：
最近の「アジャイルは死である」という主張についての私の考え
オープンな考え方を持ちましょう。お気に入りのフレームワークや方法論に固執しないでください。組織のニーズが第一です。あなたのアプローチは常に二の次であるべきです。
偽アジャイルとは何ですか?そしてそれを回避する方法は何ですか?
関係者は責任をとらない
ユーザーとのコラボレーションがない
自動化よりも手動を好む
顧客は満足していません
アジャイルは死んだ (COBOL、XP、RAD、UML、SAFe なども同様)
アジャイルマニフェストの背後にある原則
1. 私たちの最優先事項は、価値のあるソフトウェアを早期かつ継続的に提供することでお客様に満足していただくことです。
2. 開発の後半であっても、要件の変化は歓迎されます。アジャイル プロセスは、顧客の競争力を高めるために変化を活用します。
3. 動作するソフトウェアを数週間から数か月の頻度で配信しますが、より短い期間を優先します。…
アジャイルを実践することによって、ほかの様々な有益な手法が必要なくなる（学んだり実践しないで良い）わけじゃないよ、というようなことも諭しています。
開発手法ではなく、実は営業手法の延長であることがよく分かる記事です。開発結果を担保したいのではなく、営業目的を達成したい、というのが本質にあります。
アジャイルはそんなんじゃない！
という方の意見も知りたいので、是非コメントをいただければ…!
関連記事:
https://xtech.nikkei.com/atcl/nxt/column/18/00001/09274/?n_cid=nbpnxt_mled_chm
この記事が気に入ったらサポートをしてみませんか？