Scrum Slavesになってはいけない、という話【翻訳】


これは何?

アジャイル(と言われるもの)がなぜ嫌われているのかを書いた記事の日本語訳
日本(のSI)ではウォーターフォールが主流だけれども、欧米ではアジャイル(イテレーション開発)が前提となっていて素晴らしい!というような風潮は日本の中で聞こえてくることがありますが、実態としてアジャイルの名の元にひどい開発管理体制になってしまっている側面もあるようです。
そういった状況に対する記事。

元ネタはこちら
In a nutshell, why do a lot of developers dislike Agile?

日本語として読みやすいよう意訳しています。
文意として誤りがあれば編集リクエストにて随時ご指摘ください。

こいつ日本語下手くそだな、と思ったらごめんなさい。
原文読んでください。

本文

端的に言って、なぜ多くの開発者がアジャイルを嫌っているのか(より良い代替案があるのか?)

アジャイルマニフェストの作成に携わった一人として、「アジャイル使ってますか?」と質問した際のエンジニアの反応に失望している。
彼は肩を落としていて、アジャイルは怖いと言う。
なぜと聞くと以下のような回答がある。

-マイクロマネジメントされている
-品質を犠牲にしたまま2週ごとに成果物を出し続けるプレッシャーが常にある
-彼らは日程を気にしている

不幸にも彼らの活動は全くアジャイルではない。しかしどうしてこうなってしまったかはわかった。
始まりは不信だ。
もしエンジニアが2日間のトレーニングを受けスクラムマスターを取得すれば、2週間の成果物のプレッシャーというのはつまりスクラムの奴隷になってしまっていることを理解できる。
(訳注:手法の押し付けはScrum Slavesと言われ、望ましくないことです)


彼らは写真に写っている奴隷ほど幸せそうではない

もう少し掘り下げて聞いてみよう。
なぜマイクロマネジメントと感じるのか。
「私たちは1週間に一度ではなく毎日ボスに情報を届ける必要がある」

なぜ2週間のイテレーション中に大きなプレッシャーをかけられるのか。
「私たちが伝えようとしているストーリーはとても大きく、品質を問わず作業を完了させる方法はない。PO(訳者注:Product Owner, プロダクトオーナー)が最優先事項だと言ったならば私たちはそれをやらなければならない。そうでしょう?
ドキュメントはいらない、考えるな、すぐにやれ!これがアジャイルなんでしょう?」

いいえ、それらはアジャイルではなく反道徳的な仕事環境だ。
エクストリームプログラミングのトレーニング・コーチングの初期の頃にあるマネージャーが言ったように。
「これは素晴らしく聞こえるかもしれないが、6ヶ月ごとに打ちのめされる代わりに2週間ごとに打ちのめされている!」(このマネージャーのVP(Vice President)がアジャイルの実態や価値に賛同しているとは明らかに言えなかった)

このようなアジャイル屋は、以下のようなシンプルな従来型のスクラムについてさえ本当にたくさんの見落としをしている

-仕事を選択する
-イテレーション中に完成させる量をコミットする
-マネージャーによってではなく、お互いが高め合う
-設計と技術的決定の責任について話し合う
-継続的改善を推進するために問題を識別する

マネージャー、スクラムマスター、POs(プロダクトオーナー)、なんであっても、あなた方の開発チームは高品質な動くソフトウェアを毎イテレーションで届けるためにエクストリームプログラミングの技術的実践をしているのではないか?

今私が言っていることがアンチマネジメント志向に聞こえるかもしれないが、そうではない。
私はこの10年をフォーチュン500の企業でのマネジメントとリーダーシップに費やしてきた。
私はこの仕事に関してほんの少し理解しており、問題とプレッシャーの関連を見つけることができる。
問題はすべてがマネジメントにあるとは限らない。

エンジニアよ!
デリバリーサイクルはアジャイルによって根本的に変化した。

あなた自身はソフトウェア開発のように変化したか?
シニアディヴェロッパーのあなたは新卒1年目と同じようにプログラミングしている?
10年間、同じようにデバッグを後回しにしている?
イテレーション開発、テスト駆動開発、エクストリームプログラミング、設計に関する本を読んだ?
ソフトウェア開発に関する本を全く読んでいない?
悲しいことに、ほんの少し手が上がってしまった。残念だ。
(この記事を読んでいるあなたはおそらく大丈夫)

デリバリーのテンポはすでに変化した。
だからあなたのやり方も変えなければならない。
ケントベックが以前私に言った「すべてを事前に理解することはできない。決定済み要件定義書であってもそれが変更されることを止められない。打ち負かすことができないなら従え。変更に対して交渉し、良い結果を勝ち取れ」

Agile 2016
結論から言うと、2016年において実践されているアジャイルはマネジメントに支配されている。
アジャイルマニフェストに関わった多くの人々はプログラマーで、彼らは今もプログラマーとプログラムを必要とする人々にとってより良い世界をつくるべく働いている。

プログラマーへ
あなたたちはプロとして自身の働き方を改善する責任がある。
私たち(プログラマー)はきちんと行動していかなければ。
私たちは社内に法律家や政府(訳注:監査や内部統制部門のこと?)がいるため、ソフトウェアが引き起こした問題からほんの少し離れている。
私たちはプロになる方法を学ばなければ。そうでなければ法律家が私たちにプロとは何かを教えにくるだろう。
アジャイルは唯一の答えではないかもしれない。
しかしアジャイルが教えてくれた2週間サイクルによって、私たちは継続的改善や本質的な技術的改善に時間を割くことができる。

マネージャー、スクラムマスター、PO(プロダクトオーナー)へ
あなたたちはチームがアジャイルの実践方法を学んでいくよう背中を押しているか?
あなたたちは彼らが何を大事にしているか、それはなぜか理解しているか?

Agile 2017は?
それはあなた次第。

訳者コメント

この記事を読むと、日本はちゃんとアジャイル(イテレーション開発)の考え方のもと導入ができているように感じますし、適切な苦労をしているのではないかな、というように私は理解しました。

とはいえスクラムについて言えば「スクラムと言えば朝会だよね、2週間のイテレーションだよね」というScrum Slavesな考えはよく聞きますし、Scrum Slavesの結果「継続できなくてスクラムやめた」と言う話も聞きます。
そういう話を聞くたびに、手法なんて気にせずやれることからやっていったら良いんじゃないかなと感じています。
「お互いがハッピーになれる開発環境、労働環境をみんなでつくろう」というのは比較的合意にたどり着きやすい目標だと思うのでまずはこのあたりから始めてみてはいかがでしょうか。
なんにせよ、良いアジャイル開発ライフを!