アジャイル・スクラムのイマイチポイントを調べた
個人的には、アジャイルもスクラムもバズワードでしかなく、見限った手法なんだが、世間的にはどんな感じなんだろうと思って、今一度調べてみた。
目次
- ほとんどココで論破されてる
- プロダクトバックログにインフラ構築や非機能要件、運用設計などが可視化されない
- ストーリーポイントってまともに見積もれる見積手法じゃないだろ
- 運用のことを考えず勢いで開発しがち
- ドキュメントが軽視されて属人化する
- 対面で開催する会議が多い
- 管理をしたいマネージャのための手法である
- 「スクラム」って言葉からして現代人の働き方に則さない
- アジャイルをツール・選択肢の一つとして捉えていない奴が失敗する
- まとめ
ほとんどココで論破されてる
自分が引っかかったポイントは、以下の2つのページでほぼ言及し尽くされていた。
ココで挙がっているような指摘に対して、アジャイル・スクラムを重宝している人達から満足な回答をもらえたことがないので、俺の観測範囲で運用されるアジャイルはウンコだと断定する。形式的なスクラムごっこに終止し、俊敏性も柔軟性も欠いていて、自分の能力の低さをこの手法で誤魔化せると思い込んでいる人達のための、言い訳の手段だと解釈する。
以降、これらのページと、その他のサイトからの引用を交えて、自分の引っかかりポイントに関係する所見をまとめていく。
プロダクトバックログにインフラ構築や非機能要件、運用設計などが可視化されない
実際にシステムをリリースするにはインフラ構築や非機能要件、運用設計などが必要になるが、「ユーザストーリー」など、顧客目線でリリースされる機能を示すことが求められるアジャイルでは、そうした項目が表現されにくいように思う。根本は「プロダクトバックログ」と呼ぶモノのフォーマットや、何をどう書くかというルールごとが標準化されておらず、「ぼくのかんがえたさいきょうのプロダクトバックログ」が各自で作られるからおかしくなるんだろう。
- Backlogカンバンボードを開発してプロジェクトで使ってみたら“すごく良かった”話 | Backlogブログ
- 「プロダクトバックログ」を機能一覧ではなくプロジェクト全体計画の資料と据える
- プロダクトバックログの配下に「ユーザストーリー一覧」と「ストーリー外のタスク一覧」を書けるようにする
- 「ユーザストーリー以外のタスク」をプロダクトバックログに書け、が答え
- プロダクトバックログについて海外の例も踏まえ考えたこと | Ryuzee.com
-
ユーザストーリーは提供するフィーチャの説明であって、こなすべきタスクではない
- フィーチャ = 機能の特徴説明
- ストーリー = 機能に対する顧客目線でのあらすじ説明
- シナリオ = ストーリーを詳細化したもの、受け入れテストの基準
-
- スプリント1を始める前にどんな準備をするか | Ryuzee.com
-
開発を始める前に行うのが非機能要件の明確化
-
完成の定義を満たしていない（非機能要求が未対応）もの、プロダクトオーナーが受け入れない（機能要求が実現されていない）ものは、スプリントでの成果と見なされません。
-
そもそも、アジャイルソフトウェア開発宣言 って「ソフトウェア開発」のための宣言であって、インフラ構築に適用する前提じゃないよね。
↑ この記事は、9割が内製でしか適用できない話。受託開発についても「納品のない形式なら運用しやすいんじゃね？」と言っているだけ。この程度の考察じゃ、アジャイルがどこにでも適用できる代物とは言えないんだよな。ましてやウォーターフォールなど他の手法を否定する材料にもなってない。お前の視野でしかねえな、勘違いしてんのはてめぇだろという。
色んな文献はあるけど、「インフラ構築や非機能要件定義のタスクを具体的にどう扱うつもりで話しているのか」という話題は全く出てこない。「インフラも IaC で段階的に開発していける」とか抜かすけど、仮想ネットワークやサブネットの構成、そこに既にデプロイされてるリソース群含めて、本ッ気で後からホイホイ変えられると思ってる？お前は Terraform や CloudFormation 書いて運用したことある？CIDR 設計したことある？CI/CD 基盤を作ってスムーズな運用まで辿り着いたことある？経験があってプラクティスを持ってる上でそういうこと言えよ？
後述するけどアジャイルやスクラムって手法は開発者目線の頭がない手法だからだろうな。実際にモノを作る能力のない人間用の言い訳なんだよやっぱさ。コレだけ時間があって、普及した具体的なプラクティスがないってことは劣った手法なんだよ。
Agile done wrong (and almost everyone does it wrong) is just a mess when applied to critical infrastructure projects. Waterfall is much better in situations like this, but of course no one is allowed to say that anymore.
ストーリーポイントってまともに見積もれる見積手法じゃないだろ
「見積は相対的なストーリーポイントでやるんだー」って言い張ってる。でも、「1つのスプリントでどれだけのストーリーポイントが完了できるか」という見積はスプリントプランニングでやっていて、コレはつまり、「決まった時間内に、決まった人員でどんなタスクが出来るか」という絶対時間の見積をしてるよね。
ということはコレって、「ストーリーポイントで見積もれば絶対時間で正確な見積が出せる」って言ってるのに等しい。
でも、実際のところ、上手くいく見積なんてない。それなのに「ストーリーポイント」だとかいう要らん複雑さで隠蔽して巧妙に誤魔化してる。
「1つ完了した作業を基準ストーリーポイントにして、以降のタスクの見積をしてみようか」とか言う。前回とは異なる機能を作るというのに、なぜ過去実績を当てはめられると思うのか。
プランニングポーカーというのも、「チーム内で合意を得る」ことを重視しているのは分かるが、自分の専門分野外のタスクまで見積もれる前提の仕組みなワケで、その見積精度ってクソほど役に立たないでしょ。そもそもスクラムとかって、属人的なタスク組みをせず、タスクを取替可能みたいに見積もろうとするけど、それってチームメンバ全員が同等のスキルを有するフルスタックエンジニアじゃないと成り立たないでしょ。それって現実的にありえなくね？
[serious]what is a good methodology for an incompetent software development team?
スキルレベルが伴っていない人間ばかりで構成されているチームも、現実的にはある。そういうチームに対して、現実的に素早く動く方法として「じっくり考える前にとりあえず作り始める」っていうやり方は失敗するよ。なぜなら作業スピードは持ち合わせているスキルレベルによってもたらされるからだ。技術力のない人間は「とりあえず動き始める」なんて出来ないんだって。何したらいいか分かってないワケだから。
こういうチームに対する現実解は、ウォーターフォールを選択した方がマシだろ常考、である。よく分かっていないモノがたくさんある状態だろうから、課題分析を後回しにせず、先に出来るだけ問題を炙り出し、計画に組み込んでおく。「今のスキルでココまでなら行けます」って宣言をして、理解が得られてから初めて仕事をする。そうすれば、自分達が予め調査して宣言したところまでは、なんとか辿り着けるだろう。それがスクラムだと、スプリントごとに新たな課題に気付いて、想定タスクがどんどん膨れて、全体量が最初の想像の10倍近くになったりする。計画を後回しにすることは物凄く負荷を高めるので、どんなトラブルが起きたとしても迅速に捌けるスキルがないなら、計画どおりに粛々と仕事するスタイルを選んだ方が安全だし成果が出せる。
I'd love for there to be a middle ground between "we only have one plan" and "we have no plans" but IT/dev doesn't do middle ground well. We'll be on "we have no plans" for at least the next 10 years.
チーム全体での合意を重視するがため、見積やプランニングといった会議にバカほど時間を割くが、その見積結果の精度はクソほど悪いやり方だと思う。程度の差はあれど、絶対そうなる仕組みだから悪手だと思う。
For real, “Agile,” as far as I can tell, is a fairly transparent attempt to justify thoughtlessness as a method.
運用のことを考えず勢いで開発しがち
スプリント内にタスクを完了させることを最重視するため、運用やその先を見据えた設計をしようとか、保守性の高いコードを書こうとかいう考慮がサボられがちに思う。
- 高梨陣平さんはTwitterを使っています 「大切な事実があって、SWはHWよりもずっと長生きする。データはある一面でSWに依存し、SW互換性がかなりの面で重要視され、かつ、HWが朽ちてもSWはエミュレータなりで動けるから。 後、SWを書き換える(≒ 書き直す)コストはでかい。SWは偶然で動いている部分もあるので実装依存の仕様が存在」 / Twitter
-
SWを書き換える(≒ 書き直す)コストはでかい
-
「リファクタリングのタスクをどう扱うべきか」が議論になっちゃう程度の手法なんだよなぁ。もっと考え尽くされた汎用性のある手法になってから出直してくれない？
- 技術的負債のユーザストーリーを作るべきか
-
ソフトウエアのユーザではなく開発側の誰かが登場人物になるユーザストーリーに対して批評的に接することを薦める。このようなユーザストーリーを機能的な振る舞いや品質の問題として再解釈し、もしそれが不可能だったらタスクとして捉えるのだ。
- 無理して顧客目線に変換するからよく分かんないモノになるんだと思うが。
-
氏の方法では、顧客のユーザストーリーの一部のタスクにしろ、技術的タスクに特化したユーザストーリーにしろ、すべての技術的タスクをバックログのユーザストーリーで覆うことになる。
-
機能単位にコードを書いていくのは、後にアーキテクチャ変更が必要になった場合に死ぬ。簡単にいえば「スパゲッティコードでいいからリリースしろ」って半強制され、「リファクタリングは顧客に価値を提供しないから後回しだ！」と言いがちな手法だから嫌いなんだわ。
some changes could potentially require HUGE amounts of rework - since the whole architecture was planned on it working a certain way.
ドキュメントが軽視されて属人化する
上述のとおり、スプリント内でエイヤで作りがちだし、アジャイルソフトウェア開発宣言を勘違いしてドキュメントを軽視して良いと考えるバカがいるせいで、実際のところメンバはクソ迷惑している。
文書化 (= 言語化) すべき人間が文書化しない (= そいつはたとえ口頭でもまともに言語化できない) ので、皆が手探りになってしまう。ドキュメントがない状態で、皆が同じ知識を持っていることを望むワケで、属人化を促進する手法だ。
受託開発なら設計根拠や作業記録など、そうした必要な納品物は結構ある。また、リリースしたシステムの運用や問合せ対応にあたっては、自分たちチーム外の協力を仰ぐことも多いので、そういう協力部門への手順書提供が必要だったりする。
よく「資料はシステムを全部作り終わってから作る」とか、「求められたタイミングで作ることで無駄なく作業する」とか言うんだけど、そんなの無理だって。考えて、手を動かして、出来上がってしばらくしてから、それらを全て思い出して文書化するなんて非現実的。それよりも考えた瞬間にタイプして文書を残しておきゃいいのに、そういうこと絶対やらないよね。それってお前がタイプ速度遅いから避けてるの？文書作成が苦手だから嫌がってるの？でもお前の苦手意識でやることやらないこと決めるのって、アジャイルソフトウェア開発宣言における「顧客との協調」や「変化への対応」に反してるよね？その選択って顧客に何の価値も提供してないけどそれがお前のいうスクラムってことでいいの？
結局無能が自分の目先の負担を避けたいだけで、その言い訳にアジャイルとかスクラムとか持ち出すから矛盾すんだべや。お前はアジャイルソフトウェア開発宣言じゃなくて「顧客のことなんか考えず自分の生理的感覚に従って開発します」って宣言しろ。
Stick post-it notes everywhere and deliver that 3month project in a week. Who cares if it's broken there's no documentation to prove it
対面で開催する会議が多い
会議してる最中って仕事は何も進まないんだけど、スクラムはとにかく会議ごとのイベントが多い。各会議で要件や状況が引っ掻き回されて、スプリントプランニングどおりに回った試しがない。
コレはつまり、スクラムとして一般に提唱される手法を原理主義的に運用すると、思慮の浅い見積に対して、案の定指摘が入り予定が膨れ上がるが、それでもプランニング時のタスクを強引に完了させるため、負債を未来に丸投げして見かけ上出来上がったかのように見せる、っていう繰り返しになるってことなんだよね。見積も甘いし、計画も甘い。でもそれでいい手法なんだって言い張る。そうやって作る羽目になった成果物がウンコ同然なんだけどどうしてくれるの？
スプリント後半になって課題やトラブルが出てきた、どうしようか、つってまた会議開くでしょ。繰り返すけど会議は何時間やっても成果物が生まれないんだ。実際に何かをやる時間は奪われるばかりなんだけど、会議を開きたいと思ってる連中は自分の頭の中でそれっぽい解法がイメージできるのが気持ち良いから、会議自体が害悪だとは思わずに、ただただ会議をやりたがる。会議なんて一番士気が下がるイベントなんだけど。
もっと単純に開発者目線で言えば、会議が馬鹿みたいに多いと、開発に集中できる時間が奪われまくって、コンテキストスイッチのコストが高くて生産性上がらんべ。
特にリモート勤務が増えた2020年以降の環境で、対面会議を重視するアジャイルの手法をそのまま採用して意味があるのか考え直すべきだ。
各所で何度も書いてきているが、対面の会話を重視する人間って、単純に文書作成能力がないだけで、その言い訳として「口頭伝達」に逃げているだけだ。伝達手段問わず、ハナから言語能力が低く、人に伝わるアウトプットが出せないのに、自分の感覚だけで「口頭伝達の方が楽だし伝わるはずだ」と思い込んでる。お前の話も文書も全く伝わってないぞ。迷惑だからそのお前の主観だけで生きるの止めろ。意味不明なアウトプットをなんとか理解するには、揮発性の高い「口頭伝達」よりは、受信側が何度でも読み返せる「文書化」の方が幾分マシなのだから、お前が苦労して書け。
そうすればリモート勤務のメリットを最大限享受できる。会議とかいう超非効率でデメリットしかない手法を捨てろ。
管理をしたいマネージャのための手法である
スクラムは、実際に開発を行うメンバのためになる仕組みが全くない。開発者視点に欠けた見積手法、開発者の生産性を無視した会議イベントの量。むりくり期限内にそれらしいモノを開発させて、じっくり考慮したかった問題点を隠蔽させる。
スクラムマスターは本来、その役割をチームメンバが自発的に担えるようにスキトラして消えていくべき立ち位置なはずだが、「スクラムマスター」なんて資格をこしらえて収益化しちゃったもんだから、資格を取る側も自分の存在を誇示したくなっちゃうよな。自分がそこにいて、マイクロマネジメントしまくることがスクラムマスターなんだって勘違いする。そして開発メンバの現場が見えなくなり、テストやリファクタリングをサボらせたり、非機能要件やセキュリティ対策を疎かにさせたりする。
将来への投資的な時間を取らせない仕組みばかりなので、あらゆる作業は属人化し、ドキュメントが残されづらく、誰も引き継げなくなり、チームメンバはそこに骨を埋めることになる。組織としてスケールしない仕組みだし、メンバの観測範囲が変わらないからより効率的に素早く作業が出来るようになることもないでしょ。
Agile is literally just a trick to allow middle managers to put deadlines on tech people. What is worse is that some tech people drink the cool-aid and go around talking about how wonderful it is.
it doesn't even always make sense for larger software projects (especially if it isn't split into smaller sub-projects)
ダイエットの流行みたいなもんだろっていうのは言い得て妙。
My perspective is that different styles of organizing and tracking effort are a lot like diets. Each can work with the right mentality, but none are a substitute for just trying hard, communicating well and having genuine interest in the success of the endeavor. Often mgmt adopts some new methodology like a fad diet that will solve all their problems, but they never did anything about the culture that would make everyone want success, so it just becomes a bureaucratic nightmare.
「スクラム」って言葉からして現代人の働き方に則さない
スクラムの語源って、ラグビーの組み合うヤツでしょ？組み合って計画立てて、素早く作業して戻ってきて、を繰り返すという。実際にスプリント内ではプランニングどおりの結果を出すために全力で走り抜けることを求めるでしょ。そのしわ寄せとしてあらゆる負債を誤魔化しながら会議に戻ってくるワケだけど。
ラグビーの試合って全体で80分間とかだよね。スクラム組んでワーッとやっての繰り返しが体力的に耐えられるのって、全力を尽くすのが80分間という短時間だからでしょ？
でもスクラム開発って、数ヶ月・半年・1年という単位でそれを繰り返そうとするワケじゃん。全力で頭使って慣れない分野でのプランニングやって、スキルが見合ってなくとも突貫工事でとにかくフィーチャ作り上げてリリースしてみて、負債に対する言い訳を考えてスプリントレビューにこぎつけるってのを、体力的に何ヶ月も回せるワケないじゃん。
現代人って、20歳頃に会社務めを始めて、60歳とか65歳とかでようやく定年でしょ？少なくとも40年間は働くんだよ？それなのにそんな全力で走り抜けないといけないような仕事のスタイルを長期間続けようとするのって、手法自体が間違ってるでしょ。自分の限界に達する前に調整される、長く走れる手法で人材を管理する手法こそが、優秀な手法だと思うよ。
アジャイルをツール・選択肢の一つとして捉えていない奴が失敗する
I personally believe that technology leaders should be using agile methodologies for the planning and selection of their IT projects. I believe this because business value & priorities change so its really hard to create a 1-5 year plan and then stick to it.
If you know what needs to be done and how to do it use waterfall. If you dont know what needs to be done or how it will get done, consider using agile approaches. In all cases you should start with why.
この案件、この状況に対して、アジャイル・スクラムが適した手法なのか、他により適切な方法はないだろうか、という比較検討をしない・できないヤツが、諸悪の根源だよな。
一応言っとくと、アジャイルが全ての局面で使えないとも思っていない。例えば、内製か、期日と納品物が Fix されていない案件なら、アジャイルやスクラムといった手法が有効な場合はあると思う。
- 内製の場合、自分たちで機能を考え、自分たちが出来る最善のペースでリリースすることもできる。自分たちのリリースがそのまま会社の利益に繋がるし、負債をどこまで持ち越すかのハンドリングもしやすい。そういうつもりで動くプロジェクトなんです、ってことが社内で理解されていれば問題なかろう
- PoC のように、期日と納品物がセットで Fix されていない案件も、先が見えない中で何かやりましょうっていう案件特性だから、スクラムのように素早くイテレーションを回す効果があると思う
でも、日本の大抵の受託開発案件って、リリースすべき機能と期日は Fix されちゃうんだよ。その会社やシステムの特性からして、イテレーションごとのリリースなんか要らなくて、全部できあがってから決まった日付にリリースしてほしいって思ってる場合がほとんどなんだよ。会社には経営計画や予算もあるし、1年先ぐらいのことは見据えたうえで、案件の進捗をコントロールしたいもんなんだよ。そう思っている会社や社員に対して、アジャイルやスクラムの手法はメリットを一つも感じないんだ。口先では「デジタルトランスフォーメーションでユビキタスでインフォメーションハイウェイですねぇ〜」みたいなこと言ってアジャイルに乗り気な素振りを見せるが、実際やってみようとすると「慣れないやり方なんでそういうの嫌です」ってすぐ言うんだ。そんな相手に無理にアジャイルを適用しようとする方が間違っている。客が欲しいのはウォーターフォール開発による安心感なんだって。
まぁまず、アジャイル・スクラムのデメリットを適切に挙げられないようなクールエイドを飲んでるヤツって、どんな手法選んでもダメなんだよね。
まとめ
ただのバズワード。結局のところ、目先のことしか考えてない人間のための、計画性のない手法だから、将来的な展望も対策もなくて失敗するんでしょ。
みんな安心したいから、予想・予測を立てて行動したいの。不確定要素には本能的に不安を覚えてストレスになるから、先を見たいの。でもスクラムはあえて将来を無視する手法だから、バカげているの。
開発者の生産性を考慮した手法でもないし、開発者の疲労度や長期的な雇用を考慮してもいない。特にスクラムは「プロセス」が多すぎて「アジャイルソフトウェア開発宣言」と矛盾してるの。
なんでこうなったかっていうと、そもそも「アジャイル」が精神でしかなく、「スクラム」が儀式でしかないので、ほとんど宗教論争なんだよな。「方法」と「方法論」の区別がついていないというか。
さらに、「スクラムマスター」っていう収益化が捻じ曲げた部分もが多いと思うんだけど、何が捻じ曲げられているか分からない程度の人達が重宝する手法だよねコレ。ちゃんと開発する能力を持っている人間は闇雲に重宝しないよね。
