[もく読会]ゾンビスクラムサバイバルガイド: 健全なスクラムへの道
はじめに
有志で週末に集まり、タイムボックスを切って作業や読書を行う会をしています。
私はゾンビスクラムサバイバルガイドを読みました
読んだ範囲
最初〜６割くらい。まだ未読了
ということで今回はここまでの感想（後で追記するかも）
最初に結論
この本はスクラム開発している人は全員読んだ方がいい
それでは感想
そもそもゾンビスクラムとはなにか
- 一見スクラムガイドに沿って動いているように見えるが、実際には機能不全になり恩恵を得られなくなったスクラムのこと
- スクラム導入当初の不完全な状態。あるいはスクラムの「守」を実践せずに即「破」や「離」をおこなってしまい本来の形から離れたスクラム
- 一般にはカーゴカルトスクラムとかダークスクラムとかメカニカルスクラムとか呼ばれる
- 作者がゾンビスクラムと呼ぶのは作者がゾンビものが好きだから
ゾンビスクラムの「あるある」
- 顧客の言うことに従い、毎スプリントごとに最初に計画を、最後にふりかえりを、そして開発をおこなっている
- ただし顧客というのは実際の顧客ではなく、社内にいる「顧客の代弁者/仲介者」である
- 本物の課金者にここ数年会ったことがないメンバーが大半
- デイリースクラムやプランニング、ふりかえりなどのスクラムイベントはスクラム参加者全員で実施されている(されないケースもある)
- デイリースクラムが進捗報告会になったり、ふりかえりにあまり意味がない感が漂っていたり、スプリントゴールは「これとこれとこれを完了させるぞ！進捗出すぞ！」以上のものではなかったりするけれども
- 常に忙しく働いている
- 士気は高いとは限らない。むしろ低かったりする
- メンバーの目が死んでたりもする
- 「やってる感」はたっぷりある
しかし一方で顧客から見ると、実際に必要としている機能は実装されず、サービス提供者側が「提供したい機能」の方がより優先して実装されます。
また深刻なバグや利用を阻害する不具合、耐えかねるレベルの使いづらさなどは何度フィードバックしても特に対応されません。
スクラムにあってゾンビスクラムで失われているもの
- 高速なリリースと顧客からのフィードバックの高速サイクル
- ユーザーにとって最も価値があるものに限られたリソースを注力すること
- 社内のリソースをある方向にフォーカスすること
- 分断されていない「ビジネス」と「IT」
ユーザーが喜びもしないガラクタを一生懸命実装することに開発チームが熱中し、無力感に溺れ、やがて疲弊していく
到底そんなものはスクラムとは呼べないはずなのですがゾンビスクラムではそのような事態が起きがちです。
ゾンビスクラムは「よくあるスクラム」
作中ではゾンビたちで溢れる社内でスクラムを真の姿に取り戻そうとする有志たちを「ゾンビスクラムレジスタンス」と呼称しています。
（私は彼岸島の黒子軍団を思い出す）
またゾンビスクラムに邁進するメンバーのことをゾンビと呼びます。
ゾンビたちは自分のことをゾンビだと思っていません。人間だと思っています。
同様にゾンビスクラムについても「我々の会社のやり方に合わせて改善したスクラムではあるが、スクラムの一種」という理解をしています。
機能不全についてはそもそも彼らがスクラムとはどういう効能や恩恵があるべきかについて知らないか、あるいはそもそも興味がないので機能不全が起きていることを理解していません。
「毎日コードは書いているし、給料は出るし、会社からの評価も悪くない。じゃあそれでいいでしょ？」
そんな感じです。
つまりはどの職場でもよく見る「スクラム（自称）」です。
違和感や改善したいという意志を抱いている「軽症」のゾンビもいます。
そういう人を人間に戻し、ゾンビスクラムレジスタンスに加えていくのが良い、と本書では書かれています。
ここから感想
注目すべきは開発チームが社内で顧客と隔たれた存在となり、コードを書くことに集中させるというものすごくどこかで見たような話が頻出します
本書の中ではスクラム開発が「ゾンビ化している兆候」をタイプ別に書かれ、またその事態をどう解決していくか？の処方箋が書かれています。
本書の中で象徴的な言葉は「ゾンビを人間に戻せるように、ゾンビスクラムも生きたスクラム開発に戻せる」です
ゾンビスクラム開発じゃないよ。ゾンビスクラムだよ
本書において、スクラム開発とは顧客と距離を置いてはならない
置いたら簡単にゾンビスクラムになると言っています
- 「企業の組織がスクラム開発に対応していないと簡単にゾンビスクラムになるよ」
- 「だって顧客との間に何重にも壁や仲介者を作って伝言ゲームしているでしょ？」
- 「その壁を逆流して何かしようとした時のリードタイムどれくらいかかるの？月単位でしょ？高速なフィードバックなんてできるわけがない」
つまりはそういう話です
高速なリリースと高速なフィードバックは両輪
本書においては開発チームも金を払ったユーザーと直接愛、複数の方法でユーザーからフィードバックを受けることを推奨しています。
正直これは今まで私が所属した組織ではなかった話です。
しかし高速なリリースを行ってもフィードバックを得られなければ意味がありません。
高速で使われないガラクタを作ることになるからです。
これはスクラムの原型のトヨタ生産方式でも最も重要視されていた点です。
あなたは今まで高速に開発/リリースすることにだけ熱中していませんでしたか？
（頭に深々と刺さるブーメラン）
これ進研ゼミで見たやつだ
スクラムコーチ界隈で最近よく見る「形骸化したスクラムをどうすべきか」という難題に対する処方箋に思えます。
「「守」の前に「離」を始めてしまったチームをどう正しい方向に戻すか？」に対する処方箋ですね。
体感で言うと、日本のスクラムを謳うチームの９０％以上はゾンビスクラムです。
彼らはまるでスクラム開発のように動き、それなりの進捗とコードを吐き出しながらITの世界を彷徨っています。
しかし彼らはゾンビなので、ユーザーが喜ぶ機能を高速に提供しフィードバックを受け取ることはできません。
当然ユーザーにサービスを提供する会社も爆速で成長することもできないわけです。
まとめとして
ゾンビスクラムの兆候を察知する方法とそれぞれの症状に対する現実的な処方箋が載っている良書に思えます。
（タイトルがネタに走っている割には）
ただし実施するには権限が必要で、今までのやり方も大きく変える必要があるでしょう。
これを大きな組織で実施するには困難が伴うように思われます。
経営トップがこれを見て「こいつはどげんかせんといかん」と思わないとそこまで強い改革はできないでしょう。
ゾンビスクラムを改革し、ゾンビを人間に戻そうとする社内メンバーを本書の中ではゾンビスクラムレジスタンスと呼んでいます。
（逆にゾンビスクラムの問題に気づかず「別にこのままで良くね？」と考えているメンバーはゾンビのように表現されています）
レジスタンスが社内で力を発揮するか、あるいは諦めて転職してしまうかは偉い人の度量だと思います。
最後に
今まで俺が所属した組織のスクラムチームのメンバー全員これ読んで我が身を振り返ってどうぞ
Discussion