本当に僕はスクラムが嫌いでした。
念のため言っておくと、いまはもっと解像度が上がりましたし、嫌いという感情は特に持っていません。
ただ、話の流れ上、まずはスクラムが嫌いだった頃の話から始めさせてください。
スクラムというのがあるらしい
もともと私はXPの本を読んだりしていて、アジャイル開発に関心がありました。というのも私はこれまでずっとウォーターフォール型の開発しか経験していなかったので、漠然とした憧れのようなものがありました。XP祭りなど、アジャイル系のイベントにも参加したことがありました。XPはとても好きで、エッセンスだけでも取り入れたいとよく思っていました。
しかしスクラムというのが何なのかは知りませんでした。どうやらスクラムガイドというものがあるようです。入門書もいくつかありましたが、正直ピンときませんでした。
スクラムガイドを読んでみると、そこには「こうしよう」「ああしよう」みたいな、やり方の話がたくさん書いてあります。なるほど、なんとなくこれを読んだらやることはわかります。
でも、肝心の「なぜスクラムをやるのか？」が、よくわかりませんでした。
スクラムガイドを読むと、「⼈々、チーム、組織が価値を⽣み出すため」みたいなことが書いてありました。正直よくわかりません。チームは価値を生み出すために存在しているのだから、何を当たり前のことを言ってるんだろう？と思いました。
XPはわかります。なぜやるのか、何がいいのかも、本を読んだらすぐにわかりました。
でもスクラムはわかりませんでした。「なぜスクラムでそれをやるの？」「スクラムじゃない、別のなにかで同じことができないのはなぜなの？」という問いが、いっこうに解決しませんでした。
スクラム祭りに参加してみた
私はスクラム祭りというイベントに参加しました。そこで、スクラムを実践している色々な人のセッションを聞き、自分もふりかえりをテーマに発表をしてみました。
それでもわかりませんでした。（私も例に漏れませんでしたが）当時の私には発表の多くが「スクラム」という枠組みを使いながらも、実際には「いい仕事のやり方」や「いいチームの作り方」について語っているというように見えました。
そのため、実際にスクラムというフレームワークを採用していても、そうでなくても、参考になる部分はとても多かったです。少なくとも、ウォーターフォールしか経験していない私でもとても勉強になる話をたくさん聞けました。
一方で、「じゃあなんで、この人たちはわざわざスクラムの枠組みを使ってこれらのことを語ろうとするんだろうか？」という疑問は引き続き残りました。
ますますスクラムがわからなくなる
そこから先も私は色々自分なりに勉強をしました。そうすると「スクラムは、ただやるだけじゃダメだ。やり方をなぞるだけでは意味がない」「スクラムは、実践してみてわかることもある」「まずはやってみるべきだ」など色々な意見を見ました。
でも、実践しないと良さがわからないというのは、普通に考えたらおかしな話です。
スクラムに限らず、何かしらのフレームワークや方法論を採用するとしたら、学習や普及させるためのコストが発生します。大変なこともたくさんあるでしょう。
それなのに、やってみるまでメリットすらわからないというのでは導入やトライアルの判断などできないと思います。
スクラムとは何なのかも、よくわからない
さらに私が混乱を極めたのは、結局「スクラムとは何なのか」というのすらよくわからないということでした。
スクラムガイドには「フレームワークだ」と書いてありますが実践者の話を聞く限りどうもフレームワークとは到底思えません。
なんだか哲学みたいな何かが根底にあるような感じもします。でも哲学というわりに「スクラムの哲学」として語っているような人はほとんど見かけません。
周りの人に「スクラムってなんですか？」と聞いても、一人ひとり違う答えが返ってきます。認定スクラムマスターみたいな資格もあるというのに、これは一体どういうことなのでしょうか？
スクラムが嫌いになっていく
僕はスクラムのルーツを調べていきました。
もとは日本の製造業であったことがわかりました。
それを、アメリカのソフトウェア開発の文脈で再編したもの、みたいな理解をしています。
もともとの思想はとてもいいと思いました。
- 多分野のチームメンバーが、最初から最後まで一緒に仕事をすることで、製品開発のプロセスが作られる
- 製品開発のプロセスは、チームメンバーの相互作用から生まれる
これは確かにそうだろうと感じます。個人的実感とも整合がとれています。
ただこれは、こうとも取れます
- 寄せ集めでスクラムを組んだところで、特にうまくいかない
しかし、どうもスクラムの入門資料、それこそスクラムガイドのような資料には特にこういうことが書いてありません。スクラム祭りの発表やブログなどでは、このような内容は確かに何度か目にしました。
でも、おかしいと思います。だってフレームワークなのですよね。フレームワークというのは、何かの枠組みにおいて何らかの効率化なり効果なりを発揮することを期待して取り入れるものですよね。
では、どうして「こういう組織にスクラムは向かない」と、はっきりと書かなかったのでしょうか？スクラムガイドを読むと、まるでスクラムはチームの作業をするならば誰にでも適用できるように読み取れます。
方法論、フレームワークとして流通させるなら、それが上手く機能する条件についても明らかにしておくのが普通ではないでしょうか？
なので私は「スクラムは方法論として破綻している」と思いました。
そもそもが「成功したチームを観察したらスクラムだった」というところから出発しているのであって、それは「スクラムをやったらチームとして成功する」ということには必ずしもならないと思います。
なんでスクラムガイドみたいなものを作ってしまったんだろう？と私は思いました。
スクラムガイドには、やり方しか書いてありません。しかも、「まずは試してほしい」みたいなことすら書いてあります。でも「なぜスクラムを試すべきなのか」という根本の問いに全く答えていません。
しかも、発表を聞いていても「スクラムをやったらうまくいった」みたいな話って少ないんですよね。
だから再現性なんてないんじゃないかと思いました。
この疑問を投稿すると、「誰もスクラムで成功するとは言ってない」「再現性は特にない」という回答が返ってきました。
再現性がない…？フレームワークなのに？
じゃあなんでやるんですか？
スクラムやって、うまくいかなかったらどうするんです？
その検証の時間使って、XPやればよかったねとかそういう話になってくるんじゃないですか？
意味がわからないです。
「スクラムをやったら、チームとしての力を測ることができる」これはわかります。確かにそうだと思うし、実践の中でチームの情報はたくさん得られると思います。
でもだったら最初から「チームの成熟度を測定する技術」として広めてほしかったですし、しかもその目的だったら別にCMMIとかでよくないですか？なんでスクラムで測るのか、結局わからないです。
なんで方法論とかフレームワークですって顔して、実際は別物なんですか。それで、それを誰も説明しないのは一体どういうことなんですか？
あまりに説明が不誠実に思えて、非常に腹が立ちました。
僕はスクラムが嫌いになりました。
RSGT2026 2日目のセッションで気づきを得る
引き続きスクラムの謎を解きたいと思っていた私はRSGT2026にオンライン参加しました。
2日目のDave Snowdenさんのセッションで衝撃を受けました。
私の感じていた疑問に、そのまま答えるようなセッションだったのです。（意訳です。発言としての正しさは保証しません）
- 方法論としての「手順」に従うだけの人は多いが、状況に応じて判断できる専門家は少ない
- 導入を楽にするための構造が、かえって理解を阻害する構造になってしまった
- 本来学習の証明である資格認定制度が、思考停止を招いてしまった
- 成功事例を出発点にしてしまうという、因果関係の取り違え
私が感じていた疑問や不安は、特に私だけが持っていたものではなく、皆が共通して持っていたものだったのだとわかりました。
なぜスクラムが生まれたのか？
ソフトウェア開発は非常に複雑です。様々な入出力や要素が複雑に関連し、完全に成功するソフトウェア開発を体験として再現することは不可能に近いです。
しかし、複雑だから上手くできなくてもあきらめよう、としてしまっては発展もありません。
全く予測も管理もできないブラックボックスとするのではなく、複雑性と上手く付き合って開発をしていきたい。
そのために必要とされたのが「相互作用」なのだと、今の私は理解しています。
そして、ソフトウェア開発の成功は再現できなかったとしても、「相互作用が比較的発生しやすい状態」は、再現することができます。
これがスクラムなのだと、私はセッションを聞いて理解しました。
私がずっと悩んでいた「何のためにスクラムは生まれたのか」というところに一定の回答が得られ、私の理解はここで大きく進みました。
これまでの私の誤解を、一つずつ解いていく
まず、スクラムはフレームワークでも方法論でもないと思っていましたが、実際には確かにフレームワークであり方法論なのです。
ただその意味合いが当初私が想像していたものとは異なっていて、スクラムは、成功の手順を提供するフレームワークではなく、失敗を早く共有するためのフレームワークなのです。
スクラムがやろうとしていることは、失敗したこと、うまくいかなかったことをいかに早く、簡単に共有するかということであって、どうやったらうまくいくかという話はそもそもしていないのです。
そして、「失敗したこと、うまくいかなかったことを早く、簡単に共有する」という点においては、確かに一定の効果を得ており、有効で、効果が検証されたものでもあるのです。
だから、「やってみたらわかる」になる
スクラムでやろうとしているのは「相互作用が無理なく発生する空間をつくること」なので、こんなのやってみないとわからないに決まっています。だから「まずは試してほしい」なのです。
つまり私が誤解し続けていたスクラムガイドは、ずっと正しかったのです。
今の私の理解における、スクラムとは
スクラムは、高い複雑性を持ち予測不可能なソフトウェア開発において、それでも予測できるようにしたいという願いのもと生まれた取り組み、考え方のセットのことだと、私は理解しています。
高い複雑性の中では、予測ができません。
予測ができないのであれば、学習して適応していくしかありません。
学習による適応がうまく機能するには、多様な役割をもつメンバーが相互作用的に頻繁に関わる環境を用意するのが効果的です。
その環境を作るには、チームの多様性を保ち、経験主義を採用し、共通のゴールを頻繁に確認しながら対話することがとても大切です。
これらをプラクティス群として定義したのが、スクラムだと私は思っています。
以上が、スクラム嫌いだった僕がRSGT2026に参加してスクラムがちょっとわかるようになった話です。
