Zenn
🐕

お前のスクラムはすでに死んでいる

に公開
スクラム
idea

お前のスクラムはすでに死んでいる

この記事の対象読者

  • Webサービス事業会社の内製開発をしている開発チームの人
  • すでにチームでスクラムを開始している人
  • 最初はスクラムがうまくいっていると感じていたが今はそうでない人

この記事が必要になる状況の例

1.はじまり
偉い人がいいます。
「これからはスクラム！ということで全社スクラムを開始します！開発部の全チームは今日からスクラムです！」
あるいはチーム単位で「ぼくたちのチームもスクラムを始めるぞ！」くらいのスモールスタートかもしれません。
とにかくチームは今までの開発スタイルをとめてスクラムを始めます

2.学習期
スクラムとはなにをするのでしょうか？
誰かが調べて皆に共有します。
どうやらスクラムというものはこういうことらしいです

  • スプリントと呼ばれる1週間or2週間の期間に区切って開発を進める
  • プロダクトバックログとタスクリストを作る
  • 5つの会議体を導入する。デイリースクラム、スプリントプランニング、スプリントレビュー、スプリントレトロスペクティブ、バックログリファインメント

だいたい分かりました。早速始めていくことにしましょう。
おや、スクラムに詳しいとかいう同僚のAさんが何か言いたそうな顔をしています。
え？もっと他にもやることがある？憲章？インセプションデッキ？
……なんか時間かかりそうですね。そういうのは後でやりましょう。今進めているプロジェクトも締切タイトですしね。
学習と最初のバックログ作りだけですでに３日使ってしまっているのでさすがに焦りを感じてきましたよ。
それではスクラムを開始します！

3.早熟期
スクラムを開始した四半期が終わろうとしています。すでに５スプリントが終わりました。
月日が経つのって早いですね！
最初はすべての会議体が手探りで時間がかかりましたが今は順調に回っています。
輪番制のスクラムマスターによるファシリテータ（司会）業もうまく回っています。会議の議論が沈黙で停滞することもなくなりました。
スプリントレトロスペクティブのKPTでも活発に意見が出ています。
どんどんアクションにしていきましょう。
チームが自分たちの手で改善されていく感覚って楽しいですね！
それと四半期末の評価フィードバックが楽しみです。きっと高評価ですよ！

4.停滞期
スクラムを始めて１０スプリント以上が過ぎました。
月日が経つのって早いですね……
直近の３スプリント、なんだか改善されている気がしません
ベロシティは伸びないし、プロジェクトの納期スリップも未だ発生しています
輪番制のスクラムマスターによるファシリテータ（司会）業も続けていますがマンネリ感が漂ってきました。
議論が停滞することはありませんが流れ作業感があります。
スクラムマスターは障害を除去して開発を早くするんですよね？　障害ってなんでしょう？　それがなんなのか分かりません。
チームリーダーも苛立っているのが分かります。
4keysの数値やベロシティもスプリントごとに取っているし、差し込みの保守運用タスクもチケット管理しているのですがなにをどうしたら開発スピードが爆上げするんでしょうか？
とりあえず会議を効率化して短縮したり、会議体の参加者を絞って会議に割く時間を効率化してみましょう。

5.終焉期
スクラムは生産性が上がらないですね。
スクラムはオワコンみたいな記事もこの前読みました。
一応全社スクラムということになっているのでスクラムは表向きは続けますが、他のチームのように大きくカスタムを入れたりスクラムを入れる前のやり方とのハイブリッドで開発スピードをあげようと思います。

おや、スクラムが終わってしまいましたね
実はこのスクラムは始まった時点ですでに死んでいます。
なぜ死ぬのでしょうか？
ここから見ていきましょう。

なぜこうなるのか

簡単にいうと
「理想の状態(Object)はなにで、現状だとなにが問題(Problem)で、その問題が発生する理由（Question)はなにか」をはっきりさせずにソリューションとしてスクラムをぶち込んだから
だと思っています。

ゴールもスタートも問題もはっきりさせないままに、全てをいい感じに解決するソリューションなんてありません。
ましてやメンバーの向きさえ揃っていないんです。
そんな状態でなにかが解決するわけがありません。
このチームのスクラムは生まれる前に死んでいたわけです

仮に各人の現状認識とゴール意識とスクラムに求めるものをインタビューしてみたらこんな感じでしょうか？

  • チームリーダーはプロジェクトの納期スリップが頻発することが問題であり、理想は納期スリップがゼロになることで、理由を開発スピードの遅さに求めています。
    • チームリーダーはスクラムには開発スピードの向上を求めています
  • スクラムに詳しい同僚Aはプロジェクト完了後にユーザーから「これは使い物にならない」「この機能がどうしてないのか」という大量のフィードバックが来ることで「進行中の次のプロジェクト」に使うリソースが食われることが問題であり、理由を開発スコープとユーザーの要求のズレに求めています
    • 同僚Aはスクラムに探索的な要求開発と開発中の頻繁なフィードバックを求めています
  • スクラムに興味のない同僚Bは同棲中の彼女から「家に帰るのが遅い」と文句を言われることが問題であり、理由を従来型開発がもたらす残業の多さに求めています
    • 同僚Bはスクラムに締切を定めないゆるさと残業の少なさと「ベストエフォート（納期までにプロジェクト完了したらラッキー）」を求めています

同僚Aはユーザーに頻繁に動くプロダクトを見せてフィードバックを取りたいと考えてスプリントレトロスペクティブで提案をしますが、チームリーダーは「プロダクトマネージャー了承済みのスコープを勝手に変えて現場を引っ掻き回すんじゃねえ。すでに計画のガントチャートより遅れてんだぞ」と無情に却下します。
その激論でスプリントレトロスペクティブが長引くと同僚Bは（そろそろ定時なんだがなあ）と渋い顔をします。
こんな状態でスプリントレトロスペクティブで集合知が発揮されてなにかが改善されるのでしょうか？
全員見ている場所も目指す場所も「よくする方向性」も違うというのに。
それに同僚Aさんとチームリーダーは相反する思想を持ってますね。正しいのはどちらでしょう？
（いやどっちが正しいかという正解なんてないですよ。チームが自分で決めるものなので）

しかしスクラム導入初期はうまくいってましたよ？

最初はうまくいっていた(だから生まれる前にスクラムが死んでいたわけではない)
なるほど。主観的にはそう感じるかもしれません。
しかしそれは「チーム外からも分かるスクラムの成功」でしょうか？

  • 初期はlow-hanging fruitをいっぱい食べられたから
    • low-hanging fruitはすぐ食べ尽くされてしまいます
    • でもそれは短い感覚で計画とふりかえりだけをすれば達成できたものではありませんか？　スクラムがなくても達成できましたよね？
  • チームマネジメントの一般論として各メンバーの士気の向上は出力の向上をもたらします
    • それはチーム外から見た時、成果につながるかもしれませんね
    • 士気を高く保ち続ける要素はありましたか？数ヶ月経った頃には士気低下していたようですが？
  • うまく回らなかった会議体がスムーズに回ることを「成果」として認識してしまうから
    • それはチーム外から見た時、本当に成果ですか？
  • スクラムという「イケてる開発スタイル」をチームで団結して使いこなせるようになったとき人の脳はドーパミンを出します。これは非常に大きな達成感と幸福感をもたらします。
    • つまり「おれたちはうまくやっている！」感が強く感じれらます
    • それはチーム外から見た時、本当に成果ですか？

経営陣は開発チームがスクラムを導入した後も外から見える成果が見えないことも「スクラム導入初期の「産みの苦しみ」だろう。時間が経てば生産性は爆上がりするはず」と見守る気持ちで見ているかもしれません。
経営陣から見て本当に導入初期は「うまくいっていた」んでしょうか？
開発チームがひとりよがりな満足感に浸っていただけではありませんか？

では何が問題なのか。どうすればよかったのか

一番最初の段階で「全社スクラムを始めたいからスクラムを始める」と手段を目的化させたのが良くなかったですね。

経営側としては何かしらの目的と課題意識があってスクラムを始めるという意思決定をしているわけですね
それ自体がコストや一時的な開発スピードの低下を伴うことを理解していたはずですがそのコストを受けれ入れています
（もしかしたらそれに加えて多額の費用を払って認定スクラムマスター研修を何人かに受けさせているかもしれません）
その目的はなんでしょう？　コストに対するリターンとして何を期待しているのでしょう？
開発チームへの要求を最初に明確化すべきでした。

開発チームは経営陣からの要求を踏まえた上で自分たちの現状はどうなのか。なにが不足なのか。なぜそうなってしまうのかをスクラムを始める前に考えるべきでした。
そして目的達成への手段としてスクラムは本当に正しいのでしょうか？

あるいはここも疑問に思うべきでしたね。
今のやり方と今のチームでスクラムを導入することで目的を達成したいのですよね？
「今のやり方」と「今のチーム」にスクラムを入れたら目的は達成できるのでしょうか？
チームのインプットとアウトプットはそのままでいいのですか？
プロダクトマネージャーからプロダクトバックログアイテムのかたまりをプロジェクトの形で「発注」を受けて納期までにプロジェクトを「納品」する形で本当にスクラムによる目的の達成はできますか？

走りながら考えることを非難しているわけではありません

何を目的として、現状に何が足りなくて、その原因は何で……というスタートとゴールの部分を全員で共有しないまま、スクラムという手段だけ渡すことを「走りながら考える」とはいいません。
何をすべきか分からないけど、ゴールも分からないけど、それどころか自分がどこにいるかも分かってないけど、走っているうちになんかいい考えが浮かんでくるやろ！
というやり方を走りながら考えるとはいいません。
ふらふらと考えなしが一生懸命走ってるだけです。

そもそも最初の仮説の時点で間違っているケース

よくある間違いがこれですね。
最後の一節がズレてるケースです。
プロジェクトの納期スリップが多発しているから納期スリップをなくしたい。開発スピードの遅さが原因なのでスクラムで開発スピードを上げたい
開発スピードを上げたいなら開発要員を増員すればいい話です。なぜしないのでしょう？
スクラムは開発生産性向上には不適です。中間成果物を大量に作り出すスタイルではないからです。なぜわざわざスクラムを選んだのでしょう？

もしあなたがチームリーダーで経営陣が「全社スクラムを始めたい」と言い出したら

最初に経営陣が開発チームに何を要求したくて「全社スクラム」と言い出したかを聞き出してください。
全社スクラムの後ろに真の要求が隠れているはずです。
開発生産性向上ではないでしょう。なぜならスクラムは開発生産性向上には不適だからです。安易な決めつけは禁物です。

もし経営陣から「スクラム導入で開発生産性を上げたい。知り合いの経営者からスクラムなら開発生産性が上がると聞いた」と言われたら

ずいぶんほっこりする理由ですね。

まず無理だと伝えましょう。それでも経営陣が考えを曲げないなら転職準備を始めましょう。
YOUTRUSTやFindyはどうでしょうか。
赤いペンで直線を２本だけ引いて、黄色い猫の絵を描けと言われているようなものです。

経営陣「しかし開発チームにそんな難しいことを考えられるわけがない」

何を目的として、現状に何が足りなくて、その原因は何で……という部分を開発チームが自分で考えられないわけですか。
開発チームにそんな能力がないとおっしゃられる。
ではスクラムはやめた方がいいでしょう。
子供に限度額の大きいクレジットカードを持たせるようなものです。

スクラムはある程度自律的で目標の達成方法について仮説ベースで考えられる能力を持ち、柔軟さがもたらす不安さへの耐性があるチームでないと使いこなすのは難しいです。
締切とFIXされた実装すべき機能一覧を提示されないと何をすべきか迷ってしまうチームには早すぎるかもしれません。
なにより経営陣が信頼していないのです。スクラムでは「まずは信頼せよ」と言うでしょう。最初からまったく信頼できないチームに使わせても意味がありません。

スクラムは「信頼できない子供」を、自律性と柔軟性を持ち経営陣の望む方向にプロダクトを成長させる状態まで成長させてくれる魔法のメソドロジーではありません。
部分的に自律や権限移譲が機能していない会社において開発チームに自律性と権限移譲をしやすくする矯正ギブスにすぎません。

ああ代替策の提示が必要ですか。
かわりにガントチャートをびっちり引いて、タスクを細かくちぎって、締切でケツをぶっ叩くスタイルの方が確実です。
つまり従来型開発で十分ですね。

Discussion