TL;DR

き23D 仕事しないz です！

2019年9月22日にある技術書典7にでます！　スクラムアンチパターン体験談集です！

前置き

もう、5、6年前だったか、もっと前だったか……。よくid:TOKOROTEN が「スクラムってクソだよね本出そう」みたいな話をしていて、当時は僕もまだ会社でバリバリスクラムをやっていて、当時の感覚だと「スクラムはうまくいく部分もあればうまくいかない部分もある。『クソだよね！』って言うほどクソでもないけど、まぁ不満はあるなぁ……」というような印象をもっていました。当時所属していた会社は分割したり売られたり、社名変更されたり吸収されたりで今はもうないんですけど、その会社で実践されていたスクラムは、スクラムガイドという教科書にわりとガッツリ沿ったやり方ですごくうまく回っていて(正確にはうまく回っているように見えていて)、実際開発陣も楽しそうに仕事をしていて悪いものではなかった。何より会社がちゃんとお金を出して、相当な数の開発者を認定スクラムマスター研修や認定スクラムプロダクトオーナー研修に行かせてくれていたし(2011年とかの話である)、そこでスクラムを経験した開発陣が今でもスクラムで開発を進めているという話を聞いたりする。当時から変わらない印象としては「スクラムはスキルの高い人の生産性を下げ、スキルの低い人の生産性を上げて、チームとしての生産性をそこそこにキープするやりかた」というものだ(個人の感想です)。

さてさて、僕が認定スクラムマスターをとったのが2011年らしい。それから8年経って、はっ？　8年もってるん？？　ってなるんだけど、8年経ってスクラムという言葉がかなりエンジニアに浸透してきて、web開発界隈だと「スクラム」という言葉は説明なしに通じるようになってきた。ま、このように言葉が人口に膾炙すると、その言葉や超ざっくりした140文字くらいの説明を読んだだけでわかったような気になり「お前達明日からスクラムで開発しろ」とか「スクラムで開発して今までの倍の速度だします！」とか、まぁ、そういうことを言い出す偉い人とか意識高い人とかが大量に発生し、そういう人は本質を理解せずに言葉だけで実装を開発者に丸投げするので開発者たちにはツラミが溜まってくる。と。

mohikanzというエンジニアの雑談コミュニティがあるのだけれども、そこの #scrum チャンネルではそういう様々なscrumに関する質問や悩み相談が多くみられた。そこでのみんなの話を聞いていて思ったのが「幸せな家族はどれもみな同じようにみえるが、不幸な家族にはそれぞれの不幸の形がある」ということ。それぞれの現場でそれぞれの形でスクラムが運用されていて、それぞれのツラミが、それぞれ深そうと感じた。

「折角だからここでの話、本にして技術書典で頒布しよぜー。とりあえず申し込んでおくわーー(ぽちーーー」

としたら、受かってしまったので技術書典7で本を出すことになりました(ここまで前置き

f:id:hidesuke:20190917032012p:plain — 「ぼくらのスクラムウォーズ」表紙

どんな内容？？

f:id:hidesuke:20190917235335p:plain — 「ぼくらのスクラムウォーズ」目次

最初は「お前のスクラムは間違っている！」くらいの気持ちで書こうと思っていたのですが、冷静に考えたら「俺達のスクラムは間違っている!?」という内容になりました。6人の開発者がそれぞれの現場で体験したスクラムについて書いています。うまくいっていた例もありますが、全体としてアンチパターンが多めです。それぞれの章でそれぞれのスクラムについての辛みが紹介されており、それにどのように立ち向かっていったのかという内容が多いです。

さて、僕は「スクラム導入のアンチパターンと処方箋」という章を書きました。いろんな人のスクラム辛い話を聞いていると、そのスクラムが辛い理由は、スクラムの運営自体が拙い場合は少なく、むしろ上司や組織といった開発チームよりも大きな枠組みがスクラムをただの「なんかいい感じに開発が進むやり方」くらいにしか思っていないという無理解が原因にあるように見えました。そこで、いろいろな人に聞いたスクラムの辛い話をいくつか例に挙げ、何が良くないのか、どうすればいいのかという内容について論じました。

他の執筆者の章は開発者目線で現場でどうやって戦っていったのかという話がメインですが、開発者の努力だけだとどうしようもない場合どうするべきか。どういう層にどうやってアプローチしていくべきかという点について論じている点がユニークかもしれません。詳しい内容は是非本書を読んでみてください。電子書籍版もboothあたりで販売する予定です。