だからお前のチームはスクラム導入で満足して、いつまでたっても生産性が上がらないんだよ

最初に

タイトルは煽りで釣りです。ごめんね。

この記事の結論を先に書くと

• タイトルは釣り
• スクラムチームは導入当初はスムーズに成功できるように感じる。しかし途中でどこに進むべきかの方角を見失い、迷走してスクラムバットに陥る
• スクラムに求める効能はベロシティの安定が必須なものが多いのに、ベロシティの安定を意識すらしないままスクラムをやるので、迷走に陥る

じゃあどうしてそうなってしまう？という話を個人の経験をもとに書いていこうと思います。

前提として

この記事を書いた人はWebサービスの内製開発をしているアプリケーションエンジニアだったので、基本的に内製開発のWebサービスでのスクラム導入について語ります

なぜこの記事を書いたか

やっとむさんのツイートを見て思いつきました。
スクラムの導入をしたいというチームは数多く見ますが、かなり中途半端なところでスクラムのレベルアップをやめて、小手先の「改善」だけ始める。あるいは変なカスタムを入れてスクラムもどきに改悪されていくチームを多々見ました。

それは守破離の...

いわゆる守破離の守の初級者〜中級者レベルであり、まだまだ基礎や型を学んでいかなければいけないレベルの人間がいきなり破や離を始めて「オレたち流のスクラムをやるんだ！」と言い始めるわけですから、私としては「なぜ？」という感じです。

全体の構成として

経験から振り返った

• なぜスクラム導入した場合、そこで満足してしまってそこから進めなくなるのか。
• あるいはなぜスクラムコーチはスクラム導入した瞬間、明らかにまだやるべきことが大量に残っているのに契約更新されないのか。
• 数ヶ月後にはスクラムのカイゼンがマンネリ化し、チームのスクラムは迷走を始めるのか

という話を書いていこうと思います。

経験から振り返る

自分の経験から、なぜそんなことを？と言うのを考えてみました

現場でのスクラム導入の経緯

だいたい「うおー！スクラムやりたい！」と言うマネージャーとかがいて始まります。
この人はアジャイルサムライを完全読破していればかなりマシな方です。
アジャイルサムライ＋さらに数冊のスクラム系の本を読んでいればもう優秀層です。
実際にはアジャイルサムライを半分だけ、とかネットで一通り調べたわ！みたいなレベルの方が多いです。

ここで大事なことは、その旗振り役の人事目標に「スクラムの導入」が書かれてしまうことが非常に多いことです。
これで「スクラムの導入がゴール」になることをだいたい決定づけられます。

なぜか研修には行かせてくれる

「認定スクラムマスター(CSM)」資格ですね。旗振り役はこの取得の研修に会社がいかせてくれるケースが多いです。
昔は自腹でCopeの研修を受けている人がそれなりにいたのに時代は変わったなと思います。
数日間研修をやって、最後に「ちゃんと研修を聞いていたかな？」というテストがあって、だいたいそれで資格が取れます。費用は数十万円かな。
名刺にもCSMの資格持ちです、って書けます。

なおこの資格を持っていても「スクラムの導入で満足させないこと」にはあまり役に立ちません。

さあチームの立ち上げだ！

往々にして「スクラムに熱意を持つ志願者で編成された新設チーム」ではなく「既存の開発チーム」に対してスクラムが適用されます。
私の経験の限りは100%そのタイプです。

基礎知識、大事ですよね？

基礎知識を学ぶためにアジャイルサムライなどの入門書の輪読会や読書課題が開かれることがあります。
輪読会は効果があるけど、読書課題で投げっぱなしにすると本を買って与えても半分は読まないイメージです。
そして大体のチームにおいて基礎知識を学ぶ機会は与えられません。

するとこうなります。
リーダー「スクラムでは！このバックログとカンバンというやつを使います！」
スクラムの知識があるメンバー「そうだね」
スクラムに詳しくないメンバー「ふーん(何の意味があるんだろ)」

このプラクティスやアイテムやイベントの導入にはメンバーの納得感がありません。
なんならリーダーすら納得感がありません。CSM研修でそう言われたからそうしているだけです。
今はこれでいいのですが、納得感がないのであとで平然とスクラムガイドで根幹となっているプラクティスやアイテムやイベントを 「これはもう廃止しよう」 と真顔で言い出すことが起き得ます。
（実は輪読会をして基礎知識を身に付けさせても、半年経ったら忘れるのでときおり平然と廃止しようとか言い出すんだけどここは割愛）

何より大事なことはリーダーが理由を説明せずにトップダウンで設定したアイテムやイベントは、リーダーがトップダウンで撤廃を言い出したとしてもそれが通ってしまうんです。
それがスクラムの本来のやり方から大きく外れるものだとしても。

プラクティスを導入

だいたいリーダーによってトップダウンでプラクティスが導入されます

• スプリント（だいたい無根拠に１週間にされること多数）
• イベント
  • デイリースクラム（朝会と呼称されること多数）
  • スプリントプランニング
  • スプリントレビュー（ただし開催されないことも多い)
  • スプリントレトロスペクティブ(いわゆるふりかえり)
• アイテム
  • カンバン
  • プロダクトバックログ
  • スプリントバックログ（プロダクトバックログと統合されることも多い）

ITSはもとからJIRAなどを使っていたチームが多いですね。
なので新規導入はされないイメージです。
※ チケットを自分で取るのかリーダーからアサインされるのかはここではスコープ外とします

よし、スプリント１だ！やってみよう！

さて初めてのスプリントです。
1週間教科書通りに、あるいは研修で習った通りに回してみました。

レトロスペクティブで出てくる感想

スクラム導入した最初のスプリント。そのレトロスペクティブで出てくる感想。
どういう感想が出てくるんでしょうねえ（ワクワク）
大体こうなります。

「会議、多すぎるし長すぎない？」
「そうだね、もっとクイックにやりたいね」
「もっと短くできるようオレたち流に"改善"していきましょう」

おっと残念

スクラム導入時にほぼ100%出てくる感想です (残酷な現実)

たとえ輪読会をきっちりやり切ったとしても、これは出てきます
話が逸れるので長々とは書きませんが、スクラムイベントの時間をケチるとその時点でそのチームのスクラムは早い段階で詰まります。

「導入してから2ヶ月経った。スクラム導入は成功だ！」

• とにかく楽しい！
  • 定期的な短い開発期間を繰り返す。なんか楽しい！
  • スプリントごとの計画と反省会。大変だけどやっている感はある！
  • スクラム開発っていうイケている開発スタイルを取り入れた！これで俺たちもクールでかっこいいユニコーンに肩を並べたぞ！
• 大変なこともある！
  • カンバンとITSの同期大変だよね！自動でやってくれるいい感じのアプリ探したいね！
  • 会議って時間かかるね！慣れていないうちは長引きがちらしいけど、これからはもっと短くなるといいな。「週に何時間会議やっているんだよ！　」って感じだからね！
  • レトロスペクティブがとりとめのない雑談タイムっぽくなっているよね。もうちょっと実のある話だけにしてくれないかな。時は金なりだよ！ただですら会議が長いのに！
• 未来はもっとよくなる！スクラム開発は漸進的にカイゼンしていく手法！
  • 生産性や生産スピードは今は上がっていないけどそのうち上がっていくぞ！やっていき！
  • 完了予定日とかもちゃんと根拠付きで分かるようになるといいね！ベロシティの平均から予測できるんでしょ！もっとカイゼンされれば分かるようになるよね！

リーダー「大成功じゃん！」

リーダー「スクラム導入という困難な仕事をやり遂げたってCTOから直々に褒められたよ！人事評価も最高ランクだ！」
リーダー「よーし、このままどんどんスクラムをカイゼンしていっちゃうぞー！お前らも気合い入れていけよな！」

「さらに半年経ったわけだけれど……」

• レトロスペクティブが完全にマンネリ化している
  • KPTからFun-Done-Learnなども試したが、「チームの開発レベルが上がった感」がない。
  • あとなんかみんな最近活発に発言してくれない。
  • TRYがなんか、チョロく達成できるもの選びすぎじゃない？ちゃんとTRYしている？
• 会議はまだ長いね
  • なんか会議の時間、全然減らないね。開発スピードを上げるためにもっと大胆に見直していきたい。
  • マンネリ感でみんなやる気がない。やる意味が感じられない。大勢いる意味ある？
  • 一部をプロダクトオーナーとスクラムマスターと代表者だけにしようかな
• 生産性向上が見られない。
  • ベロシティ、全然上がってなくない？というか大きい数字が出たり小さい数字になったり、乱高下しすぎだよ。完了の定義が厳しすぎるのかな？（スプリント期間？１週間だけどそれがなに？）
  • あるいは生産性（ベロシティ）は順調に右肩上がりだが、同時にバーンダウンチャートも際限なくゴールが逃げていくので開発期間の短縮が感じられない。
• 「このプロジェクトはいつまでに開発が終わるのか？」 という終了見込みが全くわからない
  • そのためスクラム導入前の「偉い人だけで、密室で、勘と経験と度胸で終了予定日を見積もる」体制がいまだに続いている 。
  • 同様に「終了予定日＝締切が近づくと残業や休出でメンバーの尻をぶっ叩く」プロジェクト管理は全く変わっていない。
  • QCDSの調整はどうやればいいんだ？というか納期を動かすには合理的理由が必要だよね？合理的理由なんてなくない？
  • プロジェクト着手前にプロジェクト完了予定日が予測できるというイメージが全然湧かない。他の会社はどうやっているんだろう。
• 中期的な開発計画が立てられない。
  • ベロシティが安定しない。
  • 終了しなかったユーザーストーリーの進捗はノーカンというやり方が誤りでは？

そして迷走へ

こういう意見が出てきます

• 「オレたちはスクラムをちゃんとやっている」
• 「なのに最近進歩している感がない。行き詰まっている」
• 「スクラムというやり方は、思ったよりレベルが低いのかもしれない。オレたちはオレたちなりに、もっと正しいやり方を考えていこう」

だいたいこういう思考に陥ってスクラムを「カスタム」し始めます。
そしてスクラムバットに陥り、そしてスクラムゾンビになる……

解説編

さてなんでこうなるかという話です。

初期の頃は実際にワークしているプラクティスは

• スプリントとしての切れ目と定期的なイベントの実行
• 質は低いにしてもレトロスペクティブで反省と改善の提案ができている

この２つだけです。ただしスクラムの形はある程度できており、導入自体は成功したと言い張れる状態にあります。
ここまで簡単に来れたことからの将来の楽観。
そして改善を重ねていけばレベルが上がってもっとやれることが増えるはずという将来への解像度の低い漠然とした希望感があいまって、将来に対して過度の期待を持ってしまいます。

ところがただ無闇に歩き回っても目的地につかないように、どこを目指して進むべきなのか。
何をできるようになりたいのか。そのためには何をできるようになればいいのか。あるいは何をしてはいけないのか。というゴールやプロセスの設定ができないために、迷走が始まるわけです。

• 実際には迷走しているにもかかわらず、迷走していることを自覚する手段がない
  • そもそも正しい姿を知らないので、やるべきことをやらず、見当はずれのことをしている自覚がない
• 知識がなければ何年スプリントを回しても絶対に辿り着けない「ベロシティの安定」 のような概念があることを知覚すらできない
  • しかし「あれができない」「これをやりたい」 という課題意識だけがあるので見当違いの"民間療法"を試し出す
• 最初の導入が数週間でスムーズに終わった成功体験に固執し、正しい次の一手を知るための知識取得を軽視してしまう
  • 「本とか読まなくてもスクラムってできるじゃん！」「俺たちの現場力ってスゲー！」という悪いプライドができてしまう
  • そしてこのプライドや成功体験は、メンバーが抱える「本を読みたくない」「聞きたい意見しか聞きたくない」「自分は知るべきことを知らないと認めたくない」という考えと親和性が高い

このあたりが迷走の要因になるかなと思っています。

ポンチ絵で示すスクラムの進化の道

これは山登りに例えた図なんですけど、
実際にはスムーズなスクラム導入の時期はほんの入り口の部分で、そのあとは地道で苦しいスクラムのレベルを上げていくフェーズが始まります。
特に「ベロシティの安定」は

• これを突破しないと多くの恩恵が受けることができない
• それにもかかわらず、多くの「自称：スクラム実践者」が必要なことだと理解していない

というスクラムのレベルアップにおける最大の関門になっているよう感じます。

このために「ベロシティの安定」を経ないままに生産性の向上や完了見通しを得ようとしてもがいて、そして変なカスタムを入れておかしくなっていく、というスクラムチームが多い、と僕は感じています。

「さらに半年経ったわけだけれど……」 で挙げた課題は、レトロスペクティブのマンネリ以外は「ベロシティの安定」を達成しないと、解決できない課題です。
火薬や蒸気機関の発明のような、現代の発明の基礎になっているキー技術に相当するのが「ベロシティの安定」であり
多くの中級未満のスクラムチームでは、火薬や蒸気機関を発明せずに戦車や戦艦を作ろうとして、おかしくなってしまう、みたいに考えています。

このあたりは有識者の見解も聞いてみたいですね。

私が「ベロシティの安定」で躓く、と主張するのはなぜか

ベロシティの安定は

• スクラムの技術ツリーの中でかなり重要なHub、あるいはブロッカーになっている
• 一方で知識や正しい経験のない人間がどれほど経験ベースでレトロスペクティブを繰り返しても課題として認識されない

という問題があります。
なのでこれが初中級チームが半人前を越える上での大きな壁、すなわち崖となると私は考えています。

「ベロシティの安定」ってそんなに大事なの？

超大事。
これが達成できない限り

• 壁の向こうから「マネージャーたちが密室で決めた 勘と経験と度胸ベース の締切や完了目標日」はいつまでも降ってき続けるし
• 経営陣から見てスクラムチームは子供扱いしかされず信用のできない存在でしかない。
• 身内でキャッキャしながらスクラム開発をすることがどれだけ楽しくても、チーム外からはリスペクトされづらい

なぜならベロシティが安定できないと、スクラム開発によってある程度以上の精度のある計画を立てることは絶対に不可能だからです。

安定させないまま計画を立てたふりはできますが、いざ実行に移してみるとダラダラ完了予定が伸びたりします。
それは信頼できないし、チーム外からも意味のある計画とは見做されません。

• 「完了の予定」はもっとも重要なものなのに、開発チームの能力が低くて信頼できる日付を提示できない。
• 「完了の予定」なしに開発を含めた全体の計画を決めることはできない
• だから壁の向こうからマネージャーたちが決めた「完了の予定」が降ってくる。

そういう話です。

もう一回結論

• タイトルは釣り
• スクラムチームは導入当初はスムーズに成功できるように感じる。しかし途中でどこに進むべきかの方角を見失い、迷走してスクラムバットに陥る
• スクラムに求める効能はベロシティの安定が必須なものが多いのに、ベロシティの安定を意識すらしないままスクラムをやるので、迷走に陥る

いかがでしたでしょうか
ご笑覧いただければ幸いです。

追記

この記事への人々の反応

"過去の嫌な思い出を思い出して、後半を読めなかった"

よう元同じ現場の人
私がこの記事を書く上で想定していたのあなたのいたチームなので、そりゃ思い出すでしょうね

"ベロシティが安定しないって、具体的にはどういう感じなんだろう？割り込みタスクを防げてないとか、スキル不足とか、ではないんですよね？見積もりが上手くいってないのかな？"

このセリフ言ってみてぇ……