2012年に書いた自分の理解のためのメモを恥を惜しんで公開する。すでに5年近く経過し情報も古いが、メッセージとしては色あせていないと思う。スクラムについて学びたいなら スクラムガイドからダウンロードできるし、様々な書籍や研修があるので、そちらを参照してほしい。
はじめに
スクラムを理解すべくジム・コプリエンさんによる認定スクラムマスター研修に参加した。私は、スクラムの名前を知ったときから、スクラムに対して感じていた違和感があった。その違和感は研修に参加している最中も解消せず、混乱していた。研修終了後も、本レポートを書くためにスターバックスで真っ白い画面を見つめながら数時間に渡って熟考していた。すると、突然、コプリエンさんが話していたことの地平が垣間見え、彼の発言が一貫性を持って見えてきた。
この記事で、その違和感が解消した理解がどのようなものであるかを紹介したい。スタート地点に立った当時のスナップショットであり、勘違いや思い違いもあるだろうが、私の主観や問いを通じて記述した多様性のひとつだとお許しいただきたい。スクラムの本質のひとつとして理解している 「失敗し、まなぶ」ことについて気づいたメモを共有させていただく。
当初感じていたスクラムの違和感
スクラムについての話を聞くたびに違和感を感じていた。最初、違和感は何であるか、わからなかった。スクラムの話を聞くと違和感を感じ、しばしば何を言っているのかわからなかった。たとえば、スクラムの理論を支える柱のひとつは透明性である。この透明性は、プロセスの「用語の共有」と「完了の定義」だけであるとはいえ、スクラムの最新版において、プロダクトオーナーと言われるプロダクトの責任者は、日々の打ち合わせに参加しないそうである。これは不透明な状況を引き起こさないのであろうか。透明さを論拠とするのであれば、みんなでチームであるからプロダクトオーナーも参加すべきでないのか。むろん忙しさや他の理由でプロダクトオーナーの参加がオプションとしているのは理解できる。しかし、日々の開発で質問がたくさん出るし、状況を把握する必要があるだろう。そのほかのプラクティスや状況を聞いてみて、うがってみると組織を分断させて、失敗を引き起こさせている、導入を難しくしているようにさえ見える。むろん原則は「透明性ではなくカプセルにして見えなくすることです」と主張しているのであれば納得できる。しかし、透明性を原則に据えるのであれば、その原則に従ってほしいと思ってしまうのである。なぜ原則とプラクティスがずれているのかがわからなかった。
そのような矛盾と感じられる例は挙げるときりがない。「平等／フラットであるべき」といいながら、スクラムのフレームワークが不平等さや格差を産み出している。対話といいながら、組織的な分断や対立を起こす。ビジネスが変わって「今すぐ」なおす必要があったとしてもスプリントと言われる時まで待つなど迅速さ（アジャイル）を感じられない。むろんスクラムでは良く話題にあがるウォーターフォールが引き起こす悪い状況よりもマシなのであることは理解できる。じっくり考えても質問して話を聞いても、そのような矛盾が解消しないと感じるのである。スクラムの原則は矛盾であるとさえ感じられるような気さえする。おそらくは何らかの理解が私から欠落しているのだろうと実感していた。
そのような違和感を感じながら、今回はジム・コプリエン認定スクラムマスター研修を受けた。コプリエンさんは、スクラムの創始者のひとりである。その前には、ソフトウェア開発に関係するパタンコミュニティの創始者である。コプリエンさんは、合気道を学び、さまざまな方面に造詣が深い。このようなスクラムという枠組みを作った人から、スクラムについて学ぶ機会は貴重であった。
レッドピルかブルーピルか
認定スクラムマスター研修において、コプリエンさんからの最初の質問は、「ブルーピル（青い薬）か、レッドピル（赤い薬）か、どちらを飲みたいか」である。映画のマトリックスでネオという別名を持つトーマス・アンダーソンは、今いる世界ははっきりとはしないが何かが間違っていると感じていた。救世主を探していた人物モーフィアスに質問される。ブルーピルを飲むと今までいた世界で普通に目が覚め生活する、それは不思議の国にとどまる、奴隷であるままでいる。しかし、レッドピルを飲むと、真実の世界を知ることができる。我々は、どちらを選ぶのかを質問されたのである。ブルーピルは幸せな無知な幻想を表し、レッドピルは痛みある真実を示している。それが夢なのか現実なのか。
我々はレッドピルを選んだ。真実を知ることを選んだのだ。
コプリエンさんの研修は、このレッドピルを飲んで、現実の世界を知る。そして、幻想世界の奴隷から抜け出し自由に飛び回ることができるようになるのである。
幻想（ブルーピル）のスクラム
スクラムは、みっつの役割、みっつのミーティング、みっつのリストからできている。
- ３つの役割
- プロダクトオーナー
- スクラムマスター
- 開発チーム
- ３つのミーティング
- 計画(release/sprint)
- デイリースクラム
- スプリントレビュー
- ３つのリスト
- プロダクトバックログ
- スプリントバックログ
- 障害リスト
みっつのリストは、プロダクトバックログ、スプリントバックログ、障害リストである。プロダクトに責任を持つプロダクトオーナーは、プロダクトバックログを用意し、重要度(ROI)順になおす。スプリント計画で、その重要度が高いものから順番にスプリントバックログに回す。開発者は、日々デイリースクラムをしながら、その一定期間であるスプリントバックログを実装する。スプリントが終わるとスプリントレビューでふりかえり、次のスプリントに向けた準備を行う。
しかし、コプリエンさんはこれらをブルーピル（青い薬）、つまり幻想であると主張する。ミーティングは儀式（セレモニー）、プロダクトバックログも幻想である、と講義中に述べている。
なぜ、コプリエンさんの言う幻想であるのか、もしくは、どのような状況を招くのかの例をいくつか挙げたい。
ほつれ1:原則とのズレがある
コプリエンさんは、リーンやトヨタ生産方式を良く例を出す。例えば、一般的なリーンソフトウェア開発の原則は、このようになっている。
- 無駄を排除する
- 品質を組み込む
- 知識を身に付ける
- コミットメントを遅らせる
- 迅速に引き渡す
- 人を尊重する
- 全体を最適化する
このような原則の中で、コプリエンさんは、価値のフローに回すためにムダを排除することを考えなさい、と特に話している。しかし、「レッドピルかブルーピルか」や「罰則はダンスである」というルールのコミットメントを求めている。そのほかのスクラムの熟練者（コーチ）も、コミットメントを早期に求める人が多い。そのような傾向から、最大の情報があるときまでコミットメントを遅らせるなどの リーンの原則に従っているわけではない。 そもそも原則に従っていないのだ。
もしスクラムはアジャイルであるとするならば、アジャイル開発宣言とも矛盾しているようにみえる：
- プロダクトオーナーと開発チームを分けたように個人の対話を分断し、スプリントなどのプロセスに価値を置く
- 変化に対応することより、スプリントやリリースの計画に従うことに価値を置く
アジャイル開発宣言にも、従っていないのだ。
ほつれ2: 多様性を排除する
研修中のゲームで、性差や価値観などの違いを認める多様性を大切にするとパフォーマンスを上げられたことを学んだ。一方で、スゴい人に頼ってしまうためその人をチームから外したところ、全体のパフォーマンスを上げられた事例が紹介された。そのほかにも、場にそぐわない人も辞めさせた、という話を何度か聞いている。
それは、「場」で調整するためには、ある程度の考え方や価値観の近さがないと個を引き寄せ、「場」を構成することができないからであろう。ある程度の近さがあると引き込みを起こして、その「場」が強化される。しかし、そのチームからある程度以上、離れている人は協調が難しいからであろう。
スクラムでは、多様性が大切と主張しながら、実態としてスゴい人やチームから外れている人は辞めさせる事例が紹介される。つまり、多様な人材を受け入れ涵養させられない（なじませられない）未熟さがある。多様性を前提としたフレームワークを採用もしくは構成できるにも関わらず、それをあらかじめ採用していない。
ほつれ3:対立を引き起こすような組織構造である
本研修で行われたゲームのひとつに、仕様を書く人と実現する人のコミュニケーションの難しさを実感するものがあった。ある絵を写すゲームで、仕様作成と実装を別々の人が行う。仕様を書く人は仕様を言葉だけで伝え、その言葉だけで伝えることの難しさを実感することが目的であった。しかし、踏み込んで考えてみると、仕様を考える人と実装する人の「場」が分離していることがそもそものコミュニケーションの難しさを作り出していることに気づく。実装する人はヒマであり、決めてくれないのなら「ビーチに行くぞ」という脅し文句を言うことすら学習するのである。
さらには、最後に行われたゲームにおいては、開発チームが一体にとなりベロシティ（開発スピード）を上げ、価値を産み出すゲームが行われた。その際、開発チームが一体となる一方プロダクトオーナーと対立し、ねんざする者まで出してしまった。これは、対立や衝突を引き起こす組織的な構造による 当たり前の結果だ。むろん適切に価値を流通させるために様々なテクニックが使われるし、そのような運用がなされているだろう。そもそも対立や衝突を引き起こすような組織構造が作られている以上、共に協調して調和するように実施することは原理的に困難なのである。
現実（レッドピル）のスクラム
幻想の中ではなく、現実のスクラムはどのようにするのであろうか。
失敗、それが情報である
ホワイトボードに多数の線を引き、エンジニアであるかと確かめた上で、これはどれだけの情報があるのかを質問された。16本の線があったので2の16乗になるのかとの答えについて、こちらの情報はゼロである。つまり、同じものが続いているデータから得られる情報はゼロ。成功しているものから得られる情報はゼロである、とのことである。つまり、失敗して情報を得なくてはならない。失敗が重要になってくる。
スクラムにおける平均的なバグに対する対応時間の割合は20%とのことである。コンパイルエラーもバグと換算され、お客様に影響を及ぼしたもとは違うとのことではある。しかしながら、バグ対応率が20%と聞いたときに、私自身は多いな、と感じてしまった。少なくともムダではなかろうか。しかし、それをフレームワークに組み込むことはしていない。つまり、エラーを瞬時に発見する仕組みが欠如している、もしくは、あえてバグや問題を発生するような組織やプロセスデザインがされているのである。
なぜなのであろうか。それは、失敗させて学び・改善することを目的にデザインされているからである。もしくは、結果として最大化させることになった。それが、今回の気づいたことである。
「守破離（しゅはり）」は、日本における茶道や武道などにおける考え方のひとつである。守破離とは、守（しゅ）、破（は）、離（り）のみっつの段階をつなげた言葉である。
- 「守」とは、何らかのものを学ぶとき師匠や先生に徹底的に従いなさいという意味である。師匠が掃除せよ、床を磨け、と指示を受けたなら、疑問を持たずに、その指示を徹底するのである。それにより、体にしみ込ませることができる。
- 「破」とは、従っているうちに全体が見通せてきた状態である。全体が見通せてきているので、師匠や流儀に従いながらも自分の判断で行動できるようになっている。
- 「破」とは、全体を見通した後、自分ならではのやり方を作り出す段階である。この段階では、一通りやり方を知っている上で、変化した状態にあわせる。
コプリエンさんは、この「守破離」をよく言葉にしていた。青い薬を選んだ幻想のスクラムも三回のスプリント程度は実施し、学ぶように伝えている。つまり、目的は失敗から学び改善することであり、その結果、価値の流れを作ることである。スクラムのプラクティスは、そのツールのひとつでしかない。そう、その視点こそが、青い薬なのである。
自分で考えなさい
スクラムは、ウォーターフォールよりマシなのかもしれないけれども、微妙に問題を発生させ、領域を分断し、局所的な最適が進むように、あえてデザインされているように見える。その結果、３回という少ないイテレーションで全体を把握した後は、それを離れる必要がある。つまり、スクラムというフレームワークに従うのではなく、そのフレームワークを実践したら、離れてしまいなさいと問いかけているように注意深くデザインされている。強力な「まなび」を引き起こすように手ぐすねを引いて待っているのだ。「具体的に何をすればいいのか？」や「代替え策は何であるのか」に対して「自分で考えなさい」と答えているのだ。
「場」の領域
当初感じていた違和感のひとつの考え方に「場」があった。スクラムにおいて、「場」もしくはシステム（系、つながり）領域の分断が分析される。チーム内部ではフラットであったとしても価値の流れから考えると、プロダクトオーナーと開発チームの間には「場」が分断されている。守破離の「守」では開発チームが領域になっている。つまり、仮想敵を作り、チームを仲良くするかのように見えるのだ。
コプリエンさんに確認したところ、こちらも守破離で、領域を拡大するとのことだ。最初は「守」の限られた領域で安心して開発を行うことを学ぴ、次には、この見通せるようになった「破」を迎える。その後、「離」の段階で、その領域を拡大するのだ。この領域は拡大していくことによって、価値の流れをスムースにしていくのである。つまり、普通に学んでいるスクラムは、「守」のスクラムに過ぎない幻想のスクラムで述べたロールやプロセスなどから離れ、自らの状況にあわせデザインしなければならない。
自分で考えたものの、それだけでは単なる制約のない状態になってしまい、カオスの状態になる傾向がある。その学びを調整するために「場」に影響を与え、その場からの影響を受けながら適応していく。その結果、協調を引き起こし、「場」が活性化していく。
究極スクラム (Scrum The Ultimate)
バグを減らすこと、または品質を作り込むことを、なぜ取り込まないのか。対立や衝突を起こさず協調するようなデザインにしていないのか。なぜスゴい人をも巻き込んで全体のパフォーマンスを上げる構造にしていないのか（歴史的および私の経験から、そのようなフレームワークは存在する）。それらをフレームワークとしてデザインしないことは「失敗させ自分で考えること」を強制させ気づくためである、というコト以外、現時点では思いつかない。
スクラムの伝道者や実践者は、スクラムを実践する上であなたは考えていますか、と突きつけられているのである。まさしくそれは困難な修行のような道筋であろう。それを抜け出す方法が、コプリエンさんのメッセージである「自分で考えなさい」ということである。そのような構造がスクラムの本質であるととらえた。つまりスクラムは、スクラム自身が提唱する構造やプロセスさえも自分で考え、場合によっては否定して作り直しなさい、と語りかけているのである。
スクラム自身を否定するスクラム、まるで「空（くう）」のような構造を持っているかのようだ。それをスクラムと言うべきなのか、私にはわからない。たしかに、コプリエンさんの「何がスクラムであるとは言えない」の言葉を改めて思い出した。
レッドピルを飲んだ我々は、真実を見つめ、奴隷から抜け出し、そして空を自由に飛ぶのである。
これは、あくまで 執筆時点において理解したスクラムについてのメモである。間違いや不適切な理解が含まれているだろうし、5年間のうちに私自身の中でもアップデートされている。ただ、もし言わんとするメッセージについて興味を持っていただけたら、うれしく思う。こっそり公開してみる。
