「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ

「アジャイルがダメだと思う7つの理由」という刺激的なタイトルのエントリを、先週木曜日、3月21日にグロースエクスパートナーズの鈴木雄介氏が公開してから、アジャイル開発に関する議論の波紋が広がっています。

おそらく、これだけさまざまなブログを通じてアジャイル開発の議論が活発化したことはこれまで国内ではなかったのではないでしょうか？ ここでは現時点での議論をまとめますが、興味のある方はぜひここを起点にそれぞれのエントリを読んでみていただきたいと思います。

アジャイルがダメだと思う7つの理由

発端は鈴木雄介氏（id:arclamp）のブログarclampにポストされた「アジャイルがダメだと思う7つの理由」というエントリ。以下がその7つの理由として挙げられたものです。

1.全体スケジュールにコミットできない
2.アーキテクチャ上の無駄が生じる
3.コーチって何だよ
4.変化ヲ抱擁スルために固定化している
5.実証主義的な説明に過ぎない
6.手段が目的になっている
7.アジリティはアジャイルだけのものではない

その中身は、例えば1の「全体スケジュールにコミットできない」について。

「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。

3の「コーチって何だよ」では。

アジャイルコーチって何だよ。コーチって。コーチはチームの持つ解決能力を引き出すために存在する？何を言っているんだね。成果を生み出さない人員なんか不要なんだよ。

と、アジャイルをばっさりと切るエントリになっていますが、補足で次のように書いて、議論を促しています。

というような現実を受け入れつつ、どうやって行くのかということなんですよ。アジャイルが本格化して10年。そろそろ、次の議論に行ってもいいと思うんだ。

アジャイルがそんなにダメだと思わない7つの理由

これにいち早く反応したのが、id:haradakiro氏のエントリ「アジャイルがそんなにダメだと思わない7つの理由」です。冒頭に「がんばって返答を書いてみる。どこかでディスカッションできるといいなぁ。」と書きつつ、鈴木氏の主張への反論と同意を示しています。

例えば1の「全体スケジュールにコミットできない」については、次のように反論。

全体を見えずに計画したところでうまくいくはずはない。アジャイルがタイムボックスで計画、実施を行うからといって、全体を計画しないわけではない。むしろ積極的にやるべきである。

3の「コーチって何だよ」では同調しつつも、第三者は必要ではないかとの主張。

これは痛い。かといって、成果に連携した契約にする気もない。（略）そこを見える第三者がプロジェクトの近くにいるのは、必要なことだと考えている。

5の「実証主義的な説明に過ぎない」では同意。

その通り。すべてのベストプラクティスは過去のプラクティスである。次にうまくいく保証はない。

6の「手段が目的になっている」でも同意。

まあ、その通り。それでビジネスにはならないし、すべきでもない。

アジャイルがダメなようでダメじゃないちょっとだけダメだと思う7つの理由

鈴木氏がポストした翌日に、id:ledsun氏が自身のブログにポストしたのが「アジャイルがダメなようでダメじゃないちょっとだけダメだと思う7つの理由」というエントリ。

こちらも7つの理由について1つずつご自身の主張を記していますが、いくつかピックアップしましょう。

5の「実証主義的な説明に過ぎない」では。同意しつつ、コーチの必要性を説きます。

「優れたチームのプラクティスを実践しても優れたチームになるわけではない。」に同意。

（略）

アジャイルでは自分たちが何をするかは自分たちで選ばないといけない。誰かが決めてくれたプロセスを守ってればいいわけではありません。ホント アジャイル開発は地獄だぜ？

はじめてアジャイルやるなら、まずKPTから。ファシリテーションできないなら、そういうときにアジャイルコーチを呼べばいい。

6の「手段が目的になっている」では、アジャイルの始め方としてはアリではないかと。

「よくわかんねーけど、かっこいい」で始めるのもアリだと思います。

7の「アジリティはアジャイルだけのものではない」については以下のように同意。

まさしく！開発プロセス変えて開発者のアジリティが上がるとボトルネックが発注者に移動するんだ・・・

“アジャイルがダメだと思う7つの理由”になんと答えれば良いか

鈴木氏の元部下だというid:yusukefも、「上司からの"アジャイルがダメだと思う7つの理由"になんと答えれば良いか」というエントリで議論に参加してきました（ちなみに、ここまで紹介した4つのブログは全部はてなブログですね）。まず、次のようなスタンスを最初に表明。

現場のいろんなステークホルダーに今回の７つの”ダメ”を言われ場合に、どう切り返すか？という形で意見を述べたいと思います。

1の「全体スケジュールにコミットできない」については、

スケジュールはチームで決めてチームでコミットしましょうよ。

と、前向きな解決を提案。

3の「コーチって何だよ」については、

チームの自己組織化が閾値を超えるまでは、チームの外から「君の仕事の目的は何かね？」って聞く役割は必要だと思うんですよ。

と、一定の役割があると主張。4の「変化ヲ抱擁スルために固定化している」については、

せめて要員数は同じにするのはお勧めですよ。だって、要員数固定してしまえば、コストは固定化されて、チームの生産性とチーム同士の生産性の違いがトラッキングできるようになるんですよ。

と、固定化の一面にはメリットもあることを指摘しています。このエントリは全体に元上司愛にあふれるものでした：-）

アジャイル開発を多角的に捉えられる

ここまで紹介してきたブログのエントリはどれも、それぞれの経験や知識に基づいてアジャイル開発の現状とそのよい面、悪い面、あるいは改善すべき点などを指摘したものとして読むことができます。

Publickeyもそうですが、アジャイル開発やDevOpsなど新しい手法や技術やムーブメントを紹介する場合には、どうしてもその優れている部分や特徴が紹介される一方、それが現場で実際に使われたときに何が起きたか、どう評価されているのか、といった部分は情報量の少なさや、（コンテキストの共有の難しさなどゆえに）文章として表現することの難しさなどなどがあってなかなか伝えられていません。

その意味で、さまざまな開発の現場に関わる人がそれぞれの立場で意見を表明した今回のケースは、アジャイル開発を多角的に捉えて考えを深めていくうえで参考になるものだと思います。

そのほか、今回の議論に関連したエントリを見つけた範囲でリンクしておきます。

• アジャイルがダメだと思う7つの理由 ... への脊髄反射 - kawaguti の日記　(id:wayaguchi)
• 作るシステムの特性と、開発プロセスの相性 - begirama's diary
• "アジャイル"開発の長短みたいなのか。 - Celaeno Fragments
• アジャイルがだめだと思うたった一つの理由 - 水まんじゅう
• 「アジャイルがダメだと思う7つの理由」が間違っている97の理由 — ちくわとチワワはよく似てる
• アジャイルコーチに関する考察 - 勘と経験と読経
• それはアジャイルの問題なのかな? -2- - Tommy Heartbeat 2nd

（2013//3/29追記）
鈴木雄介氏が、これらさまざまな反応に対してあらためてご自身の考えをまとめたエントリ「アジャイルをダメにしないためにすべきこと」を公開しています。