スクラム拡張の “中断"

スクラム拡張 (Scrum Extensions) は現在 “中断　(suspended)” 状態にある。コミュニティによって提案されながらも異論の多い，スクラム方法論への新たな機能追加に関して，これは Scrum.org の伝える最新動向だ。InfoQ がスクラム拡張について最初に報告したのは，2011年の後半に Scrum.org が，Ken Schwaber，Jeff Sutherland 両氏の定義したオリジナルのスクラムプロセスに対して，コンテキスト対応の変更を許容すると発表した時のことだ。それ以来 InfoQ では，スクラム拡張の進展に関して四半期単位 (2011年第４四半期の最新情報, 2012年第１四半期の最新情報) で，定期的に最新情報を伝えてきた。

"新規にスクラムを導入する，あるいはアジャイルプラクティス適用に苦慮している組織にとって，より経験を積んだアジャイル実践者の知識や指導から得られる恩恵には，非常に大きなものがあります。スクラム拡張はそのようなガイダンスを，効果の保証されたプラクティスの形で，コミュニティの審議を受けたドキュメントを通じて提供するメカニズムとして提案されました。

私たち Scrum.org もそのようなガイダンスの必要性は認識しています。しかしながらそれを提供する手段として，スクラム拡張は望ましい手段ではないことが分かったのです。コミュニティへの提案には感謝しています。提案済みの拡張については，スクラムフレームワークへの推奨拡張ではなく技術資料として，今後も引き続きホスティングします。

スクラム拡張に対する Mark Levinson 氏の意見：

スクラムに対するこれらの提案すべてが，私にとっては悩みの種です。RUP (Rational Unified Process) の轍を踏んでいるように思えるのです。すなわち，ここにすばらしいプラクティスの一覧があります，自身のニーズに合うように調整してください，というようにです。問題は RUP 初学者たちが，それらプラクティスの多く，あるいは大部分を実践しようとすることにあります。本来ならば，実行するのは少数のプラクティスでなければなりません。私がスクラムを指導する時には，早い段階でこう伝えています – "スクラムはシンプルで，不完全なものである" と。それからもうひとつ，ユーザストーリと見積についても (Mike Cohn 氏らと同様に) 言及しておきたいと思います。ただし私は，たとえ拡張機能としても，それらを "スクラム" の範囲に含める必要があるとは考えていません。成功を収めたシンプルなシステムに，私たちは手を加え始めてしまったのかも知れません。とんでもないことになりそうです。

Mark の意見に対する Ron Jeffries 氏：

"スクラム拡張" に対しては強く反対しますが，理由は多少違います。私の理由は，

 

• 拡張という概念には，Scrum.org にそのコントロール権を与える，という明らかな意図があります。スクラムにとって，これは容認できることではありません。誰にとっても，Scrum.org 自身にさえも望ましい事ではないのです。

• 少なくとも今のところ，拡張機能はオリジナルの作者からも，長年実践を重ねてきた多くの人々からも信頼を得られていません。しかも拡張の中には，スクラムを使った経験のない人たちによって書かれたのではないか，と疑われる部分もしばしば見られます。これは礼儀知らずかつ無効果という，あり得ないコンビネーションです。

• チームがスクラムで成功を収めるためには，スクラムで定義されていないことも数多く実行しなければなりません。スクラムの基本的前提である自己組織化とは，自分たちにとって何がベストであるかの把握が必要であり，可能であり，なおかつそれを実行する，ということなのです。拡張という概念は，この自己組織化と真っ向から対立するもので，それ故にスクラムの概念と実践を棄損するものなのです。

• "拡張" のような特定のアクティビティを尊重することによって，それ以外のアクティビティは，少なくとも暗黙のうちに軽視されます。カード計画のようないい加減な概念よりもはるかに価値のある，重要なアクティビティは他にたくさんあります。拡張のようなアイデアは，チームに役立つというよりも，かえってチームをだめにする可能性の方が高いのです。

 

もし見積をする必要があるのならば，カードを使った計画や見積もよいでしょう。(現実のプラクティスにおいては，見積は一般的には悪い考え方と思っています。)　ですからスクラム拡張にトライしたり，ましてや成功を収める必要のある人がいるとは思いません。これまで提案されている拡張は，他の場所で説明されているアイデアの，出来の悪い焼き直しに過ぎないのです。

Ken Schwaber 氏：

Jeff と私が最初にスクラムを公開した時，多数のプラクティスをそこに含めました。リリース計画，スプリントバックログのフォーマット，スプリント計画ミーティングの最善の構成，などです。スクラムが人々に利用されるにつれて，同じように有効な代替案が，多くの人々によって作り出されました。このようなプラクティスが現れ，有効性が証明されていくに伴って，私たちは "最初" のプラクティスをスクラムから取り除いてきました。このようにしてプラクティスを実践する人たちが，自分自身の目的に対して最善のプラクティスを選択するようにしていったのです。ただし書籍やトレーニング，コーチングといった手段以外にガイダンスを残すことはありませんでした。

 

 

そこで私たちは，拡張機能と呼ぶプラクティスモデルを導入して，スクラム実践者を支援することにしました。プラクティスをスクラム拡張と呼んだのは， 私たちがスクラムを中心に考えているためです。実際にはこれらのプラクティスは，スクラムに特有のものではありません。スクラムチームが実践できないようなプラクティスがひとつでもあるならば，スクラムに問題のあることが明らかになります。これらのプラクティスを合理的に利用すれば，高品質かつ高価値のソフトウェアを，リスクと予測性を管理しながら開発する可能性を高めてくれるに違いありません。

 

 

 

これらのプラクティスは，確かに完璧ではないでしょう (完璧なものなどありますか？)。 それでもパワフルで便利，そして教育的な面でも有益なのです。プラクティスは時を越えて進化していきます。それらの中で作者が確認されたものについては，公開当初に提供されたものとは正しく区別しておきたいと思っています。例えばプランニングポーカ (Planning Poker) については，James Grenning 氏の功績であることは確実でしょう。フィボナッチ数列が直前の２つの数の和であることを理解させるのにも役立っています (1,2,3,5,8,13,21,34 ...)。

 

 

 

これらは私たちやスクラムコミュニティの人々がこれまで使ってきて，有効だと考えられるプラクティスなのです。編集とレビューのプロセスが完了したらスクラムコミュニティに対してこれらを公開し，推奨プラクティスとするつもりです。

 

 

もう一度言っておくべきだと思いますが，これらの拡張機能はスクラムの一部ではありません。スクラムがその必要性を明らかにした，ソフトウェア開発におけるベストプラクティス集なのです。塗料店に行けば，縁をきれいに仕上げたり，古いペンキを取り除いたり，穴を埋めたりするためのよい方法を紹介したパンフレットが用意してあります。それらがなくてもペンキは塗れますが，うまく行かないかも知れません。同じ関係が，スクラムとソフトウェア開発プラクティスとの間にもあるのです。

 

 

私たちが従事する知的職業では，あらゆる面で可能な限りの支援が必要なのです。この活動に対するみなさんの善意に感謝します。