http://martinfowler.com/bliki/FlaccidScrum.html

2009/1/29

多くのプロジェクトで混乱が起こっているようだ。次のようなことになっているらしい。

  • アジャイルプロセスを使ってみたいと思ってScrumを選ぶ。
  • Scrumのプラクティス、そして原則を採用する。
  • しばらくすると動きが悪くなる。コードはぐちゃぐちゃ。

これはソフトウェアの内部品質に彼らが気を配っていなかったことが原因だ。思うように新しい機能が追加できず、生産性がガタ落ちしたことにすぐに気づくはずだ。ズルズルと技術的負債に陥り、Scrumがヘロヘロになってしまったわけだ。（本当のスクラムだったら、これが最悪なことだって分かるだろう）

ここでScrumに言及したのは、この問題に気づいたときによく使われていた代表的なプロセスがScrumであったからだ。こうした状況はScrumによって悪化させられたものだ。 Scrumはプロジェクト管理の技術をその中心に据えたプロセスである。技術的プラクティスを意図的に追いやってしまっている。これは（例えば）エクストリームプログラミングとは対照的である。

Scrumを擁護しておくと、技術的アクティビティをそのスコープに入れていないというだけで、それを重要だと考えなくてもいい、ということにはなっていない。有名なScrummerに話を聞くと、Scrumプロジェクトを成功させるには技術的プラクティスが不可欠だといつも強調している。 Scrumが技術的プラクティスを規定していないだけで、実際には必要なのである。それを規定していないから内部品質が貧弱となり、いつもいつもプロジェクトが火を噴いている。 Scrumの旗の下に多くの問題が出てきたことは、Scrumが現在最もポピュラーな存在だからであり、Scrumだからということではないのかもしれない。ポピュラーなことと意味の希薄化は関係しているのである。

では、どうすればよいのだろうか？

Scrumコミュニティはもっと技術的プラクティスの重要性を理解してもらうことに努めるべきだろう。プロジェクト審査では、どんな技術的プラクティスが存在しているかを必ず調査すべきである。もしあなたがそうしたプロジェクトに関わるときに技術的側面が無視されているようだったら、きちんと騒ぎ立てよう。

Scrumが導入されるときは、技術的プラクティスに十分に注意を払おう。我々はエクストリームプログラミングからうまく適合するプラクティスを持ってきて適用している。 XPerはよくこんなジョークを言う。「Scrumって技術的プラクティスのないXPでしょ」閑話休題。手始めにXPのプラクティスに手をつけてみるとよいだろう。なにもやらないよりは、確実にうまくいくはずだ。

私がいつも指摘することだが、成功するか失敗するかは方法論の問題ではない。プロセスによって成功しやすくなるかもしれないが、結局、重要なのはチームだし、何がチームにとってうまくいくかの責任を担うのもチームである。多くのヘロヘロScrumプロジェクトはScrumの名声を蝕んでいると思う。そしておそらくは、広い意味でアジャイルの名声をも蝕んでいることだろう。ただ、意味の希薄化は不可避なので、過度に警告はしない。失敗するチームはどんな方法論でも適用をミスるだろう。成功するチームはうまい考えを元に自分たちのプラクティスを構築するだろう。そしてScrumコミュニティの役割は、そのうまい考えを広めることにある。

多くの人たちは次のアジャイル方法論（Next Big Agile Thing）である「リーン」に目を向けている。しかし、リーンが有名になれば、Scrumが現在直面している問題と同じ種類の問題に直面するだろう。だからといってリーン（あるいはScrum）に価値がないというわけではない。ただ、プロセスやツールよりも人や人との相互作用のほうが価値があるということが、改めて思い出されるのである。