先日The Registerを見ていたらアジャイル開発の失敗率は268%も高い Study finds 268% higher failure rates for Agile software projectsという記事が目に入りました。
The RegisterはITニュースサイトで、日本で言うところのITmediaやWIRED、GIGAZINEみたいなところですかね。
その記事は元記事を紹介しているもので、『元記事はImpact Engineeringの宣伝ではあるが、アジャイル開発は期待ほどうまくいかないという疑念を抱かせるのにも十分である』というようなまとめになっていました。
ではImpact Engineeringってなんなんだよと元記事268% Higher Failure Rates for Agile Software Projects, Study Findsを最後まで読んでみたのですが全然なにも書かれていませんでした。
これでは紹介のしようもないなーと思っていたのですが、なんと書籍を買って読んだ人が現れたので、具体的にどんなだったかというのはそちらの記事を読んでみてください。
まあリンク先でも突っ込まれているようにImpact Engineering自体はあんまりどうでもいいような内容だったみたいですが、それはそれとしてThe Registerの記事のコメント欄がコメント200件以上が集まる大盛況であり、正直本文より面白かったので軽く紹介してみます。
COMMENTS
Richard 12
「アジャイルに失敗した」という人が現れるたびに、必ず「あなたは真のアジャイルを実践していなかった」という人が現れます。
「適切に」という接頭辞がつくこともあります。
つまり、真のアジャイルとは、真のスコットランド人です。
Zippy´s Sausage Factory
クライアントは誰もスプリントレビューなんか望んでいません。
クライアントが望んでいるのは、「金曜日にxを完了してデモンストレーションします。yは一週間後、zは一か月後に完了して、これで完成です。」です。
クライアントはアジャイルなんて理解していないし、そして理解する必要もありません。
家を建てるときに毎朝6時に大工と会議を行いますか？
いいえ。
大抵の人は専門家に任せて、成果を待つでしょう。
picturethis
『家を建てるときに毎朝6時に大工と会議を行いますか？』
これはそんなに悪いことですか？
昨日の作業内容と今日の予定を確認することで、潜在的な小さな問題を大きくなる前に発見することができる可能性があります。
cantankerous swineherd
そうですね。
専門の検査官に来てもらって、仕様どおりに進んでいることを確認してもらいます。
Anonymous Coward
毎朝確認してもらうのはよいことですが、それをやるのはクライアントではなく監督者の仕事です。
Zippy´s Sausage Factory
検査官や監督者はそのような会議を行うかもしれません。
しかし、クライアントはどうでしょうか。
ドリルの右巻きと左巻きがわかる程度の知識しかない素人が大工の会議に入ってきて何を？
私が思うに、アジャイル開発者は、経済学者と同じ思い上がりに囚われています。
即ち、参加者全員が情報に精通したアクターであると想定するのです。
当然ながら、これは実体とはかけ離れています。
Dagg
『家を建てるときに毎朝6時に大工と会議を行いますか？』
家を建てるときに、まずコンクリートの基礎を敷きます。
次に壁を貼ります。
おっと、バスルームの配管を忘れていました。
キッチンの基礎の位置を間違えてました。
よし、壁を崩して基礎を掘り起こしてもう一度作ろう。
私は、アジャイルプロジェクトで何度もこれを見てきました。
要件を正しく定義する前に中途半端な状態で走り始め、その後迷走します。
TheMeerkat
アジャイルでは、アナリストやプロジェクトマネージャが顧客と話し合って仕様を決める作業が廃止されます。
かわりに、プログラマが開発を進めながら顧客と話し合って仕様を決めていきます。
これは、無能なプロジェクトマネージャにとって非常に都合のいいシステムです。
StewartWhite
アジャイルは、他の全ての方法論と同じくカーゴカルトです。
まだ特許を取得していない、私の"非"方法論を教えましょう。
1.システムに求められる機能を、A4用紙1枚に記述します。
2.質の高い開発者を作業に必要最低限の人数と、システムに求められる機能を知っていて時間のある人を揃えて開発を始めます。
3.「アジャイル」「DevOps」「ステークホルダー」「ウォーターフォール」等の言葉を口走った者には、最期の一服を吸う時間が与えられます。
私の経験では、この手順に従うかぎり期限内予算内できちんと機能する成果物が生まれます。
ComputerSays_noAbsolutelyNo
プロジェクトがアジャイルであるということは、プロジェクトがうまくいかなかったときにプロジェクトマネージャーが責任を回避するビジネスアジリティを持っている、ということです。
Anonymous Coward
アジャイル原子炉：将来の誰かが廃棄物を処理します。
アジャイル月着陸船：打ち上げ時に爆発。
アジャイルITプロジェクト：わからないところをStackoverflowで調べます。
wolfetone
来週から始まる新しいプロジェクトは水没していることが判明。
Hawkeye Pierce
開発者を集めて、彼らにソフトウェア開発の何が嫌いなのかを訪ね、それらすべてを行わない方法論を作ったら、それがアジャイルになるでしょう。
ドキュメント化するのは面倒なので後回しにします。
仕様に従って作業はしません。
綿密なスケジュールを見積もる？いや、とりあえず直近の2週間だけに集中しましょう。
アジャイルは開発者が開発者のために作った方法論です。
残念ながら開発者は、ソフトウェアが全てなのではなく、ソフトウェアの利用法、ソフトウェアの目的、ソフトウェアの利点に注力すべきであるという事実を忘れがちです。
つまり、ソフトウェアがどのように作られたかではなく、ソフトウェアが何をするかが重要です。
大声でアジャイルと叫ぶ人たちは、アジャイルが適しているプロジェクトしか経験していないのに、それを全てに当てはめることができると考えています。
壁を作れる人が必ずしも家を建てられるとは限らないように、家を建てられる人が必ずしも高層ビルを建てられるとは限らないように、ある場所で適切だったものが他の場所でも適切であるとは限りません。
私はコンピュータサイエンスの学位を持ち、40年以上ソフトウェア開発にかかわってきました。
その間様々な方法論が現れ、そのほとんどは以前の方法論の欠点を補うものでした。
アジャイルは他の方法論よりは長持ちしたかもしれませんが、また別の方法論がそのうち現れるでしょう。
captain veg
『アジャイルは開発者が開発者のために作った方法論です。』
これは、開発歴30年以上の私の経験とはまったく一致しません。
ただし、『開発者』を『プロジェクトマネージャ』に置き換えれば、完全に一致します。
Dagg
『アジャイルは開発者が開発者のために作った方法論です。』
これは、開発歴45年以上の私の経験とはまったく一致しません。
ただし、『開発者』を『ビジネスアナリスト』に置き換えれば、完全に一致します。
I could be a dog really
ドキュメントを書くのが好きな開発者に会ったことはほとんどありません。
ごく小規模なプロジェクト以外では、開発者がドキュメントを書くべきではないと思います。
ユーザにとってわかりやすいドキュメントを書くスキルと、コードを書くスキルは全く異なるスキルです。
従って、適切なスキルを持つ者が書くべきです。
ドキュメントを書くためにはシステムについて深く理解している必要があるので、両スキルは似ているところはありますが、それでもコードを書くこととドキュメントを書くことは全く異なることです。
AMBxx
我々はみな、プロジェクトに適した適切な方法論を選択する必要があります。
Plest
おいおい、そんなこと言っていいのか？
皆が流行りに飛びつくのではなく、常識と適切な計画に沿ってプロジェクトに適した方法で物事を進め始めたら、どんな混乱が起こるかわかっているのかい？
なんてこった、「明日の御飯代だけでプロジェクト管理します」の看板を掲げるプロマネがそこらの路上に溢れているぞ。
2倍の時間と4倍の予算がかかるコンサルを雇用する会社はなくなり、プロジェクトは予定通りに完了するようになるだろう。
Anonymous Coward
「$x方法論を使おう！」はもういいよ…
goldcd
本当に優秀なPMと出会って意見が180度変わったよ。
たしかに最初は延々と資料を整えたり余計な要求をされたりとにかく面倒だった。
しかしあるとき歯車が噛み合ったかのように全てが動き出し、あらゆる物事がうまく進んでいたことに気が付いたよ。
だから次のプロジェクトではもっと信頼を寄せ、プロジェクトもさらに簡単になった。
そして頭の固い上層部が彼を首にしたよ。
なぜなら、良いPMは鎮火が必要になるような炎上をそもそもしないから、PMはもう必要ないと思われたんだ。
some_random_coder
全く逆の経験をしたよ。
2007年にスクラムが始まって以来、無駄な会議だけが延々続くようになった。
毎日のスタンドアップミーティングはマイクロマネジメントの目的だったし、スプリントは実際の進捗とは全く無関係に決められた人工的な締切だった。
誰も適切にストーリーポイントを見積もる見当がつかず(私はいつも3か5に適当に入れていた)、PMはバーンチャートとにらめっこしているばかりだった。
それ以来の17年、経験した全てのスクラムはあらゆる理由で失敗してきたよ。
忌まわしい経験のせいで、かつては楽しかったキャリアが、一刻も早く引退したい苦役でしかなくなってしまった。
Anonymous Coward
製薬業界にいます。
ソフトウェアでは許されるかもしれない、『素早く行動し破壊せよ』は、患者の生死に直結します。
アジャイルは、この業界では禁忌であり、今後もそうであり続けるでしょう。
Justthefacts
それが真実だったらよかったんだけどね。
昨年起きたAbbott Freestyle Libreアプリの惨劇について触れておきましょう。
これは糖尿病患者が、血糖値を測定するウェアラブルセンサに接続するアプリです。
このアプリはある日自動更新のあとセンサに接続できなくなり、ロールバックもできなくなりました。
これにより、約10万人が自身の血糖値とインスリンを管理できなくなりました。
Jonathon Green
プロジェクトの成否は、方法論ではなく、モラルとモチベーションによって決まることを皆もそろそろ理解すべき。
WhoKnowsWhoCares
方法論はガイドラインとするべきであって、厳格なルールとして使用するべきではない。
AndyJF
アジャイルは今やバイブルです。
それがプロジェクトを成功に導く唯一の方法です。
PMを毎日崇拝しなければなりません。
スプリントレトロスペクティブの完遂こそがプロジェクトを救う道なのです。
alfmel
コメント欄を見るかぎり、ほとんどの人がアジャイルについて誤解しています。
Martin FowlerによるState of Agile Softwareの講演をすぐにみることです。
要するに、アジャイルプロジェクトが失敗した場合、あなたはアジャイルではありません。
doublelayer
alfmel、アジャイルを嫌わせようとしているのであれば、とてもよい発言ですね。
感想
『海外では既にアジャイルしかない。ウォーターフォールなんてどこもやってない。』『海外ではカスタマーも要件定義から参加して云々』みたいな海外万能論をわりとよく見かけますが、べつに必ずしもそうとは限らないようです。
少なくともここのコメント欄を眺めるかぎりでは、半数以上はアジャイルに反対、そして残りの半分もアジャイルとウォーターフォールをほどほどに混ぜて使うといい、くらいの温度感でした。
数少ないアジャイル至上主義者の意見は、upvoteも少ない感じでした。
どうしてでしょう。
長文が多くて面倒くさそうだと思われたからでしょうか。
総じてウエメセで気に入らないからでしょうか、
それともその両方？
さらには反対どころかアジャイルを敵視している発言も多々あり、しかもそういう意見にupvoteが集まっていました。
コメントやupvote数を見るかぎりでは、海外はアジャイル！は、Web開発者はみんなReactを使っている、jQueryなんぞ誰も使ってないという意見と同じくノイジーマイノリティの幻でしかないというように見受けられます。
アジャイルで成功して名の知れている海外の企業は、そもそもが海外まで進出できるような上澄みなわけで、つまりは高い技術力を持った技術者の集団です。
アジャイルは、そのような連中が集まってこそ極めて高い生産力を発揮できる方法論であり、一般人にはとても扱いきれない技術なのかもしれません。
なにしろ、失敗したら「お前のアジャイルは真のアジャイルじゃない」ですからね。
同じものを見て、聞くことのできる真の仲間にしか真のアジャイルは使いこなせないのでしょう。
要するに、私のアジャイルは真のアジャイルではなく、似非アジャイルです。