スクラム開発を2年やって得た学びとか

導入

会社のスクラム状況とサークルの話

弊社では6,7年ほど前まではウォーターフォール開発が主流とでした。
その後、スクラムマスターの資格を持つ方などの啓蒙活動を経て徐々にアジャイル/スクラム開発が浸透していき、今では社内の至るところでスクラム開発を見かけるようになりました。

また、多くのチームで似たようなことを経験していたり、プロジェクト特有のトラブルに見舞われたときにスクラムではどう改善していくべきか？という話をするスクラムサークルというものが存在します。
普段はSlack上で「こんなときはどうしていますか？」といった感じで相談をしていますが、月1の飲みながらのコミュニケーションではスクラムに限らず業務全般のお悩み相談をしたり和やかな雰囲気で進行しています。
弊社のサークル制度について簡単にではありますが公式noteに記載されていますので、そちらをご参照ください。

およそ2年間のスクラムマスター経験の話

こうした環境のなかで私も2020年の4月の組織編成のタイミングから急遽スクラムマスター（SM）に任命され、スクラム開発に身を投じる事となりました。
と、こう書くとスクラム開発を強制されたように思われるかもしれませんが決してそうではありません。
私達プロジェクトメンバーの担当する領域に対し知見のある人が少なく、不確実性の高い状態にあったためウォーターフォール開発を採用しにくい状態にあったことからアジャイルでやるのがベターであると判断しました。
また幸いなことにプロダクトオーナー（PO）がスクラム開発経験があったのでSM未経験の私を「SMとはこういうものだ」とサポートしながらやっていこう、と声をかけてくれたのもあってスクラムを採用するに至りました。

私はそこでサポートを受けつつ SCRUM BOOT CAMP THE BOOK や SCRUMMASTER THE BOOK を読んだりしながらSMとして学んでいきました。

しかし、本を読んだだけでは分からない問題なども起きました。それをどう解決しようとしたのか、その結果はどうだったのか、という話をしようと思います。
前置きが長いですね！

起きた問題とその対策

途中で先にやらねばいけないボトルネックが見つかる/差し込み案件

起きた問題

バックログリファインメントをし、計画ミーティングもやった。さぁスプリントを回していこう、と進めてみたら実はA機能よりも先にB機能のことをやっておかなければいけなかった！
特に知見がない領域で開発をしているとこんなことがよくありました。

他にもあるあるなことだと思いますが、メインで進めたいプロジェクトとは別に急遽やらなければいけない差し込み案件というのが存在します。
一番わかりやすい例だと「既存のアプリケーションにバグが見つかった。原因の特定、影響範囲の調査、バグフィックスリリースをする必要がある。これは5人日¹くらいかかりそうでベロシティに影響が出そうだぞ」というときですね。

対策

該当のタスクのストーリーポイント（SP）を見積もり、優先度に応じて同等のSPのタスクを次のスプリントに送ることにしました。

同等のSPのタスクを先送りしなかった場合、そのスプリント内で消化すべきSPが純増することになります。
ベロシティはチームの生産性が急上昇したりメンバーに変化がない限りそんなに変化するものでもありません。
また急に増えたSP分メンバーにただしわ寄せが行くのはメンバーに負担を強いるだけになります。

例えばリリーススプリントなどでそういう事が起きた場合には、やむを得ず残業などでカバーすることもありえますが、SMとPOがその差し込みやボトルネックの優先度が高いと理解している以上、基本的には組み替えるべきでしょう。

オフショア開発でできることが限られる問題

LIFULLでは子会社である LIFULL Tech Vietnamというオフショア先を有します。

私のプロジェクトでも一時期オフショア開発として利用していました。
その際に起きた問題の話です。

起きた問題

スクラムというのは（個人的な考えですが）属人性がなく誰もがどんなタスクもこなせる自立、自走できるチームであるのが理想だと思います。
ただしオフショアという一種の業務委託を採用することでこの理想の状態に遠のいてしまうことがあります。
具体的にはオフショア先に開発をしてもらった成果物は社内の人間がレビューという形で検品をする必要があります。
また、開発をしてもらう際にはオフショア先の手を余らせないようにこちらで調査をし、仕様書を書き起こしておく必要がありました（過去形）。

また、これは弊社特有の事情だと思いますが、オフショア先で十分にテストを行う環境がなかったため、テストは日本側でおこなう必要がありました。

そのため、日本側のエンジニアは調査・設計、そしてレビューとテストというタスクをひたすらこなし、オフショア先はひたすら開発をする体制になってしまいました。
そして開発が終わってレビュー待ちになったオフショア先の手を止めるわけにも行かず、設計も不要なくらい簡単なバグ修正や雑多な開発タスクをお願いする…という自転車操業のような状態に陥りました。

これがスクラムにどう影響するかと言うと、そのバグ修正や雑多な開発タスクというのは計画ミーティングをした際にはスプリントの中には存在せず、スプリントの最中に追加されるものです。つまりリファインメントや計画ミーティングにはなかったタスクが都度追加され、ベロシティも乱高下することがある、という状態です。
これではスクラムではなく単なる場当たり的なプロジェクト進行となってしまいます。

対策

当初オフショア先には開発しかやってもらっていませんでしたが、その状態を解消すべく、やれることを増やすようにしました。
例えば調査。オフショア先の皆さんは非常に優秀で、仕事をお願いしてから返ってくるまでのスピード感は日本人に引けを取らない、あるいは勝っている部分もありました。
その調査結果が最初は的外れだったことも0ではありませんでしたが、それでも日本のメンバーが調査も掛け持ちしているときよりは負担は大きくなかったです。

続いてこちらのレビューの負担を減らすためにオフショア先で社内レビューをしてもらうようにしました。そして日本側がピアレビューという形で最終確認をするようにしました。
また、（元々やっていたことではありますが）日本側のレビュー結果を少しずつ向こうのコーディング規約や気をつけるポイントとして採用・蓄積をすることでオフショア先のレビューの精度が上がっていき日本側がピアレビューする負担も徐々に減っていきました。

さらにテスト仕様書の作成も…と、このようにオフショア先ができることを少しずつ増やすことで、オフショア先の手を止めないための「都度チケットを追加する」ということは減りました。
単純にベロシティが増加していく、日本側も少し負担が軽くなると良い傾向にありました。
もちろん、始めた当初は教育コストというところで日本側の負荷は上がりましたが…必要なコストですね。

JIRAでストーリーを使うべきか、使わないべきか

弊社ではプロジェクト管理ツールとしてJIRAを採用しています。
JIRAはなんとなく「便利だなー」くらいの感覚で使っていましたが、ここ3ヶ月くらいでレポート機能の優秀さに気付いたりバージョン機能の活用方法を模索したりと、噛めば噛むほど味がある、みたいな気付きがありました。単に私が使い込んでなかっただけという話でもあります。

起きた問題

JIRAでは「課題タイプ」という項目があり、それによりチケットの種別を決めることができます。
スクラムではストーリーポイントというように「ストーリー」に対して見積もりをおこなうのを是としています。
しかし、もしそのストーリーの中でやるべきゴールもやり方も明確でストーリーの必要性がなかったら？
あるいは逆にやるべきゴールもやり方も不明瞭で見積もりができなかったら？

私のチームではそんな理由から長い間ストーリーは使わずに「タスク」という課題タイプのみを使っていました。

ただ、案の定という感じではありますがタスクごとにSPを振るため、SPを振るという行為が非常に時間のかかる作業となりました。
Slack上でSPを投票できるようにしたり、投票結果がぶれた場合に意見をすり合わせる際のルールを作って簡素化するなどの工夫をしたりもしましたが、場当たり的な対応だったな、と今となっては思います… :sad

対策

当たり前のことですがストーリーを使うようにしました。やることが明確でもストーリー化します。
一方で不明瞭な場合ですが、不明瞭だからこそストーリー作る必要がある、という結論にたどり着きました。

例えば「最終的にやりたいことはこれ」だが、手段が何も分からないというのであれば「ゴールを実現できるための手段がメンバー間で共有される」というストーリーを作るなどしてゴールから少しずつ細分化したストーリーを作っていくのです。

「手段がメンバー間で共有される」のSPが見積もれないというのであれば、さらにこれを細分化します。
例えば「手段がいくつあるのか把握している」「その手段の中から最善のものを選択できている」などです。
前者は思いつく実現手段をアイデアを出す、後者はメリデメを勘案して意思決定をする、というものです。
後者は決めの問題なのでそんなにSPは大きくならないでしょう。
前者はどこまでやるか次第ですが、そこは完了条件とかをすり合わせることで過剰すぎないポイントに落ち着いてくれて、全く見積もれないという状態になることもないでしょう。

スクラムマスター兼任問題

SCRUMMASTER THE BOOKを読んだりすると、SMに求められるスキル、やるべきことは非常に多岐にわたり専門性が求められることが分かります。また、同書では兼任するのではなくSMとして専任するのが良いとされています。

起きた問題

私の場合は開発者と兼任しています。そのためスクラムマスター業務が疎かになってしまうことも珍しくありません。実際スプリントの半分はSM業務をせずに開発に専念していたりすることも。
それにより半期などを見据えたような長期的なスクラムの改善をできていないという問題があります。
SMはスクラムをうまく回すためにチームの改善、無駄を減らすといったメタ的な振る舞いも求められますが、そこに手が回っていません。

対策

メインのSMは私ですが、サブとして2人のSMを立てています。
SMとしての全ての業務を1人でこなすのではなく、必要に応じて分担したり、1人で抱え込むのではなくみんなで改善を図ろうというスタンスです。
これにより、スプリント内で起きた問題はメンバーに改善をしてもらい、自分はもう少し先を見据えた動きをする、などの対応ができています。

ただ、別にこれはサブSMを立てたことで解決できたという話ではなく、SMの補助をお願いしたことでメンバーにもメタ的な視点が求められ、結果として自己組織化に近づいたのだと今になって思います。
SMだからといって一人で抱え込む必要はないんだな、という気づきを得られました。

俺たちのスクラムはまだまだ続くよ

まだ他にもここに書ききれないほどの問題や社外の方に話すには難しい文脈の話などもあります。
それでも少しでも良くしようと少しつづ改善をしてきています。
時には本来のスクラムの解決方法ではない選択肢を取ってしまうこともあるかもしれませんが、フレームワークから外れ過ぎない程度に最適化を図って、今後もスクラム開発を続けていこうと思います。

1. 人日なんて単位を使うんじゃない、という話もあるかと思いますが、ああ、それくらい工数に影響しちゃうのねというざっくりの指標として使いました。 ↩