スクラムとかんばんの議論、対立か両立か？

ソフトウェア開発において、スクラムとかんばんとは、対立するものなのか、それとも両立するものなのか。同じ日に異なる意見がブログで表明されていると、平鍋健児氏のブログ「An Agile Way」のエントリ「かんばん、と、スクラム。現時点での最新議論。」で紹介されています。

かんばんで削ぎ落とすムダとは創造性だ

平鍋氏は、スクラムの創始者であるKen Schwaberが6月10日にポストしたエントリ「Waterfall, Lean/Kanban, and Scrum」について、自身のブログで次のように紹介しています。

Kenは、「スクラムは難しい問題を人間の創造性を使って解くためのもの。かんばんを使っても、ウォーターフォールに隠れていた無駄（ゆとり）をなくしてしまい、かえって安定したデスマーチを引き起こす。」と。

該当部分（と思われるところ）をKen Schwaber氏のブログから引用しましょう。

Lean is more productive than waterfall. Its transparencies and metrics allow frequent adjustments to optimize productivity. However, that optimized productivity is creativity when people are used to solve complex problems. People are worked like cogs in a machine, and their work is optimized at the bit level, rather than being aggregated into the value level.

リーンはウォーターフォールよりも生産的だ。その透明性と指標が、生産性を最適化するための調整に頻繁に適用される。 しかし、その生産性の最適化とは、複雑な問題を解決するために用いられるクリエイティビティのことだ。（その結果）、人々はむしろ価値のための集まりと言うよりも、機械の歯車のようになり、作業はビットのレベルまで調整される。

ちょっとぎこちない訳になってしまったので、もしもよい訳を思いつかれた方は教えていただきたいのですが、かんばんを用いてムダを省く「リーン」では、削ぎ落としているムダは実は創造性のために必要なものであり、ムダを削ぎ落とすことは、ゆっくりしたデスマーチへの道だと指摘しています。

一方でSchwaber氏はスクラムについては次のように表して、その違いを明確にしています。

Scrum is intended to be a place where enthusiastic people can work closely with their customers to derive the most valuable, creative products possible.

スクラムが意図しているのは、顧客に近いところで真剣に働く場所を作ろうとしていること。それにより、より価値がありクリエティブな製品を引き出そうとしている。

かんばんとスクラムはアプローチが違う

一方で、かんばんについてのもっとも熱心な情報発信源として活躍しているDavid Andersonのエントリが「Thoughts on how Kanban differs from Scrum」。

平鍋氏はこのエントリを次のように紹介しています。

この中で、「かんばん、はプロセスではなく、プロセスを変化させるツールだ。ウォーターフォールであってもアジャイルであっても、まずはかんばん、で可視化することによってプロセス改善の出発点にできる。全員参加で現状を把握し、WIPを制限することで無理なく仕事をできる環境を作り出す。」と主張している。

Andersonu氏のエントリのポイントを引用してみましょう。

Kanban is not a project management or software development lifecycle method. It is an approach to change management - a framework for catalyzing change in an organization. So it differs from Scrum in that it cannot be used as a process to get work done. It needs to be applied to an existing process. That existing process can be Scrum, or equally any other lifecycle method with which you are familiar, or something that has no name - an ad hoc process.

かんばんはプロジェクトマネジメントやソフトウェア開発サイクルの方法論ではない。それはマネジメントを変えるためのアプローチ ～ 組織の中で変化を引き起こすためのフレームワークだ。そこがスクラムとは違うところであり、仕事を完成させるためのプロセスとして使うものではない。既存のプロセスに適用するべきものだ。それ（既存のプロセス）がスクラムであることもあり得るし、そのほかの（開発）ライフサイクル方法論やその場限りのアドホックな方法論でもいい。

Anderson氏はこのように、スクラムとかんばんは位置づけが違うものであると、それぞれの役割をまず説明しています。そして、スクラムとかんばんのそれぞれの特徴を次のように表しています。

Kanban uses the WIP limit as its control mechanism to provoke conversations about change.

かんばんは、管理方法としてWIP（work in progress、仕掛かり）を制限することで、変化のための対話を引き起こす。

（略）

Scrum uses commitment as its control mechanism for provoking changes.

スクラムは、管理方法としてコミットメントを用いることで、変化を引き起こす。

だからこの2つは根本的に違うアプローチなのだと。

So Kanban uses a WIP limit as a change agent and Scrum uses commitments. This is a fundamental difference in approach.

スクラムとかんばんは両立する

さて、平鍋氏はかんばんとスクラムについてどのように考えているのでしょうか？ ブログでは次のよう書かれています。

ぼくは、日本のソフトウェア開発の状況を見たときに、どちらも重要なコンセプトになると思っている。製品開発のように、創造性を必要とし、不明確な問題領域を探索していくときには、やっぱりスクラムのようなやり方がいいだろう。逆に、保守に入ったソフトウェア開発、ウォーターフォール型でも、かんばん、はうまく機能する。まずは見える化し、問題を解きながら、改善しながら、進むチームを作れる。

そして、現在のかんばんのムーブメントが、平鍋氏が提唱するプロジェクトファシリテーションに近くなっていると。

プロジェクトファシリテーションとは、「個人の能力を100％以上発揮するチームの場作り」を目指して行うテクニック、ツール、方法論をまとめたもの、と考えればよいでしょうか。平鍋氏のプロジェクトファシリテーションに関するプレゼンテーション。

アジャイルの識者の多くは、「答えは現場にある」とよく発言します。スクラムとかんばんも、このような議論を深めつつ、実際に現場をよくする道具として使われていく中で、その使い方や位置づけのノウハウが固まっていくことでしょう。