TL;DR
き23D 仕事しないz です！
2019年9月22日にある技術書典7にでます！ スクラムアンチパターン体験談集です！
前置き
もう、5、6年前だったか、もっと前だったか……。よくid:TOKOROTEN が「スクラムってクソだよね本出そう」みたいな話をしていて、当時は僕もまだ会社でバリバリスクラムをやっていて、当時の感覚だと「スクラムはうまくいく部分もあればうまくいかない部分もある。『クソだよね！』って言うほどクソでもないけど、まぁ不満はあるなぁ……」というような印象をもっていました。当時所属していた会社は分割したり売られたり、社名変更されたり吸収されたりで今はもうないんですけど、その会社で実践されていたスクラムは、スクラムガイドという教科書にわりとガッツリ沿ったやり方ですごくうまく回っていて(正確にはうまく回っているように見えていて)、実際開発陣も楽しそうに仕事をしていて悪いものではなかった。何より会社がちゃんとお金を出して、相当な数の開発者を認定スクラムマスター研修や認定スクラムプロダクトオーナー研修に行かせてくれていたし(2011年とかの話である)、そこでスクラムを経験した開発陣が今でもスクラムで開発を進めているという話を聞いたりする。当時から変わらない印象としては「スクラムはスキルの高い人の生産性を下げ、スキルの低い人の生産性を上げて、チームとしての生産性をそこそこにキープするやりかた」というものだ(個人の感想です)。
さてさて、僕が認定スクラムマスターをとったのが2011年らしい。それから8年経って、はっ？ 8年もってるん？？ ってなるんだけど、8年経ってスクラムという言葉がかなりエンジニアに浸透してきて、web開発界隈だと「スクラム」という言葉は説明なしに通じるようになってきた。 ま、このように言葉が人口に膾炙すると、その言葉や超ざっくりした140文字くらいの説明を読んだだけでわかったような気になり「お前達明日からスクラムで開発しろ」とか「スクラムで開発して今までの倍の速度だします！」とか、まぁ、そういうことを言い出す偉い人とか意識高い人とかが大量に発生し、そういう人は本質を理解せずに言葉だけで実装を開発者に丸投げするので開発者たちにはツラミが溜まってくる。と。
mohikanzというエンジニアの雑談コミュニティがあるのだけれども、そこの #scrum チャンネルではそういう様々なscrumに関する質問や悩み相談が多くみられた。そこでのみんなの話を聞いていて思ったのが「幸せな家族はどれもみな同じようにみえるが、不幸な家族にはそれぞれの不幸の形がある」ということ。それぞれの現場でそれぞれの形でスクラムが運用されていて、それぞれのツラミが、それぞれ深そうと感じた。
「折角だからここでの話、本にして技術書典で頒布しよぜー。とりあえず申し込んでおくわーー(ぽちーーー」
としたら、受かってしまったので技術書典7で本を出すことになりました(ここまで前置き
どんな内容？？
最初は「お前のスクラムは間違っている！」くらいの気持ちで書こうと思っていたのですが、冷静に考えたら「俺達のスクラムは間違っている!?」という内容になりました。6人の開発者がそれぞれの現場で体験したスクラムについて書いています。うまくいっていた例もありますが、全体としてアンチパターンが多めです。それぞれの章でそれぞれのスクラムについての辛みが紹介されており、それにどのように立ち向かっていったのかという内容が多いです。
さて、僕は「スクラム導入のアンチパターンと処方箋」という章を書きました。いろんな人のスクラム辛い話を聞いていると、そのスクラムが辛い理由は、スクラムの運営自体が拙い場合は少なく、むしろ上司や組織といった開発チームよりも大きな枠組みがスクラムをただの「なんかいい感じに開発が進むやり方」くらいにしか思っていないという無理解が原因にあるように見えました。そこで、いろいろな人に聞いたスクラムの辛い話をいくつか例に挙げ、何が良くないのか、どうすればいいのかという内容について論じました。
他の執筆者の章は開発者目線で現場でどうやって戦っていったのかという話がメインですが、開発者の努力だけだとどうしようもない場合どうするべきか。どういう層にどうやってアプローチしていくべきかという点について論じている点がユニークかもしれません。詳しい内容は是非本書を読んでみてください。電子書籍版もboothあたりで販売する予定です。
How to 執筆
技術書界隈ではGitHubで原稿を管理して、Re:Viewで書いて〜〜みたいなのが流行っています。確かに大規模な執筆であればそういったやり方が適切でしょう。しかし私達は、執筆者の半分以上が同人誌を書くのが初めてであり、さらに技術書を書くのはみんなずぶの素人です。
今回とったやり方はGoogle Docsにそれぞれがそれぞれの章を書き、執筆者と有志のレビュワーでクロスレビューをするというやり方でした。
Google Docsのいいところは、スマホからレビューをしてスマホからコメントを書ける点です。忙しいソフトウェアエンジニアでも通勤電車の中で執筆、校正作業ができて効率がいいね！ タスク管理はTrelloを活用しました。
執筆が終わると、編集担当がInDesignで編集をし、pdfを出力して再度チェック。
と、まぁ、こうした、手作業は多いけれども確実に書き上げることができるというプロセスを採用しました。
振り返り会
「スクラムの本を書くんだから、あとがきは振り返りをやってその結果を書こう！」
という超ナイスアイディアが、執筆のキックオフをしたときに出たので、あらかた執筆が終わったタイミングで渋谷のルノアールの貸し会議室にあつまりFun Done Learn による振り返りを行いました。
や、みんなで集まってわいわいやるのは楽しいですね。ちなみに僕が着てるTシャツはこれです
https://www.amazon.co.jp/dp/B077MBF8R7/ref=cm_sw_r_tw_dp_U_x_TJpGDbX2KKZ7N
そして、みんなでやったFunDoneLearnの結果はこちら。
高解像度版へのリンクは本に載っていますのでよければそちらをご参照ください。
まとめ
今まで同人文芸書はいろいろ作ってきましたが、技術書を書いたのは初めてでした。書いていくなかで自分の考えが徐々に整理されていき、また、他の人の文章を読むことであらたな発見と学びがたくさんありました。Fun Done Learnという形での振り返りも、初めてやったけど大変に楽しかった。
文芸同人畑の人間なので綴じ方向逆にして表紙をつくってしまうという大ぽかもやらかしたりしましたｗ
ふぁぁぁぁあああ！ この表紙右綴じやんけ！ 横書き技術書だから左綴じで作らんとあかんやんけ！！ 作り直しや！！
— hidesuke (@hidesuke) September 5, 2019
いろいろと、学びの詰まった本です。最初は50ページ弱の予定でしたが、気づいたら88ページにもなってしまいました。
なかなか世に出てこない話が詰まったいい本になったと自負しています。
9月22日はき23D 仕事しないzで「ぼくらのスクラムウォーズ」を1冊1000円で頒布します。電子版も用意してあります。皆様、是々非々おいでください！
チーズカフェ 2
