スクラムを味方につけろ！ - SEA関西プロセス分科会 -

SEA関西プロセス分科会であったScrumワークショップに参加しました。アジャイル開発プロセスであるScrumには、以前から興味がありました。しかし、かつてのCMMブームのトラウマから少し不安がありました。それは

「スクラムは敵か味方か？」

ということです。アジャイルの目指すものは大いに賛同できるものですし、合理的であると考えていました。しかし、スクラムが普及し、組織的な導入が増えるにつれて、「本当に大丈夫なのか？」とおぼろげな不安を抱いていました。

しかし今回のワークショップに参加して、その疑問は氷解しました。

＜CMMブームのトラウマ＞

敵か味方かという不安は、1990年代半ばにCMMが普及しだした頃にも感じていたことです。それまでのソフトウェア工学の成果を集大成し、組織の成熟していく道を示したCMMについて、ソフトウェア工学を学んだ人間として、必ずしも反対するものではありませんでした。

しかし、プロセス改善と言いながらも、そのアプローチはトップダウン的でした。現場を見て改善をするのですが、現場には定められたプロセスに訓練によって慣れることが求められました。プロセス改善は現場を幸せにするものでしたが、与えられたプロセスを実践できるように現場が努力し、それが組織に利益をもたらすことをつうじて、みんなが幸せになるというストーリーでした。

CMMによる改善活動では、管理できるような組織づくりが必要とされ、作成するドキュメントが増えることがあっても、減ることは少なく、開発が安定するという幸せはあったものの、開発現場は必ずしも楽ではありませんでした。

私が理想とするプロセスは、レベルといったどこにでもあるヘビーウェイトな管理プロセスではなく、組織や業務に最適なプロセスだったのです。

CMMブームのトラウマは、知名度の向上に伴って営業に利用されるようになったことです。組織のプロセス改善が目的でなく、レベル達成という知名度の向上を目的とした企業が増えるようになりました。

そこではじまったのは、トップダウンによるプロセス改善の形骸化です。開発者の能力が発揮できるという幸せではなく、果たすべき義務の増加による重圧感が増大しました。当時、プロセス改善には経営層コミットメントが必要だと言われていましたが、現場での改善活動なしにプロセスを変更するだけでは、組織や業務に最適化されたプロセスなど望みようがありませんでした。

＜第2次アジャイルブームへの懸念＞

近年、第2次アジャイルブームと言われています。XPを中心とした2000年代前半の第1次アジャイルブームは現場の技術者主導の、どちらかというとゲリラ的なものでした。しかし、近年のアジャイルブームは、現場主導というよりは組織的なプロセス改善のようです。どちらかというと「アジャイルをやっておかないとまずいのではないか」という、トップダウン的な検討・導入も多いように聞いています。

この第2次アジャイルブームは、マネージメントが明確なスクラムをベースにされることが多いようです。私はCMMのトラウマから、アジャイル2次ブーム、とりわけスクラムにどのように接するべきかを見極めたいと思っていました。

閑話休題、このような懸念からも、現場の改善に基礎を置くチケット駆動開発に期待しています。そのあたりの話は、Ultimate Agile Storiesという本に記事と対談という形で載せていただきました。8/14開催（東京ビックサイト）での夏コミのほか、アジャイル関係のイベントで販売されますので、よかったら買ってください(利益は、全額、東日本大震災の被災地支援として寄付されます)。

＜スクラムワークショップ＞

ワークショップは実習中心でしたが、解説もありました。それによると、スクラムが野中先生らの論文がもとになっている一方で、オブジェクト指向の有名人やKent Beckらアジャイル宣言の関係者も大きくかかわっているとのことでした(まずは一安心)。

実習ではマルチタスク(仕事の掛け持ち)の大変さを実感する、全員で見積もりをするといったことが行われ、それらをベースにスクラムが語られました。これらを通して、スクラムが現場を大切にしていることを実感できました。

懇親会では、講師のおひとりである原田さんとお話しできました(もう一人は山根さん)。率直なお話が聞けたので、理解が深まったように思います。

＜感想＞

ワークショップで印象的だったのは

「スクラムは常に改善する」

という言葉です。これはCMMでも同じはずなのですが、常に最適化を目指すのではなく、ひとまずレベル3とかいう発想を抱きがちであったことと比べると、大きな違いです。

スクラムはゴールではありません。改善のスタートの標準的なリファレンスプロセスとして、大いに参考になるものです。スクラムを起点に継続的な改善をすれば良いのです。

スクラムのワークショップで語られることには、現場で遭遇する問題への対処のような内容もあるようです。しかし、今回のように初めてのワークショップでは、まず理想論から入られるようです。仕事を兼任せずにシングルタスクに集中することや、全員で見積もることも、ある種理想論であるということなのでしょう。プロセス改善の集まりなどで「守破離」が語られることと似ているように思います。

スクラムがCMMと違うのは、はるか先にあるゴールではないということです。遠い先に理想的なプロセスがあるのではなく、すぐそこに標準的なプロセスとしてスクラムがあり、そこから継続的な改善が始まるのです。

そこには、現場で考えてコミットメントする仕組みがあります。皆で見積もっているようでいて、その見積もりを開発者がコミットしているのです。そして、開発の速度(べロシティ)を見える化して改善していく仕組みがあるのです。

また、現場は開発作業に集中できます。複数の作業を兼務しないだけでなく、スプリント(イテレーション)の間は作業を変更しないことで、開発に集中できる仕組みがあるのです。

＜スクラムを味方につけろ！＞

このように、スクラムは現場を重視した改善活動の標準的なトレーニングと考えることができます。その基本を大切にすれば、現場のプロセスは改善するでしょう。

スクラムが組織的に導入される場合においても、基本が重視されるなら形骸化せずにプロセスを改善し続けることができるでしょう。しかし、基本を忘れれば、ただの繰り返し開発、ただの見積もりごっこになってしまう可能性はあります。要はプロセスを改善するのは、開発者の理解と努力次第ということなのだと思います。

CMMのブームの時、私は形骸化の危険性を感じてあまり賛成しませんでした。それは図らずも多くの事例で証明されてしまいました。その一方で、CMMを正しくプロセス改善の道具として活用した組織は、多くのメリットを得ることができたのも事実です。ブームに乗らないことは、成功でもあり、失敗でもあったのです。

スクラムはそのプロセスの中に、現場のプロセスを直接改善する仕組みが入っています。正しく導入することができれば、形骸化を避けることができます。むやみに恐れず、スクラムを味方につけることが、改善への第一歩なのだと思いました。