SSTエンジニアブログ

SSTのエンジニアによるWebセキュリティの技術を中心としたエンジニアブログです。

チームにスクラムを導入した話

はじめに

ポケモンスリープに結構ハマって、仕事は忙しいけど前より健康的になって仕事のやる気が起きない岩間です。8時間寝なくちゃ
今回は、参画しているEASMプロジェクトでスクラム開発(以下、スクラム)を導入した話について紹介します。

現在弊社で開発しているEASMサービスのβ版についての詳細は以下をご参照ください。

www.securesky-tech.com

※本記事における意見は、筆者の個人的な意見であり、所属団体や関与するプロジェクト等の意見を代表するものではありません。

スクラムをはじめるキッカケ

当初からEASMはSaaS提供を前提で検討していたため、継続的な開発にマッチした開発手法を選ぶ必要がありました。また、いくつかの開発手法に関する書籍や記事を読んでみて、以下の理由からスクラム開発が適していると感じたため採用しました。

スモールスタートで始めやすい

少人数・小規模の開発を想定していたため、スクラムが軽量で始めやすいことが採用ポイントでした。
逆に大規模向け開発や、設計段階で仕様をがっちり固める開発手法は不向きだと感じていました。

(E)ASM市場のビジネス状況が不安定

今年5月頃に経産省からASMの導入ガイドラインが発表されたことをキッカケに国内でもよく耳にするようになりました。

www.meti.go.jp

今は非常に注目度が高いですが、今後どうなるかは分かりません。個人的には(E)ASMは、バズワードの感覚を持っており、ニーズも一過性のものではないかと思っています。また、中長期で見ると、プロダクトのニーズやビジネス状況が変化する可能性が高いため、柔軟性のある開発手法が求められていました。

知見獲得

スクラムを始める前に社内の他チームにヒアリングしたところ、アジャイル開発を部分的に取り入れているチームはいましたが、スクラムを導入しているチームはいませんでした。 スクラムは、IT業界では最早モダンな開発手法ではありませんが、社内では知見のない手法だったため、これを機に知見を得ようという挑戦の機会と捉えました。

チームとしての成長

スクラムガイドの中でスクラムとは「⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワーク」と説明されています。 SST Mindでもある「チームの未来のため、自ら決断、実行する」に通ずるところがあるのと、私自身もチーム一丸となって作りたいという気持ちが強かったため、スクラムガイドの内容に共感しました。

スクラムの推進と試行錯誤

最初は「なんとかなるだろう」という軽い気持ちで始めた結果、案の定色々な苦難がありました。 試行錯誤を経て今はある程度安定していますが、悩んだポイントをいくつか紹介します。

プロダクトオーナーがスクラムマスターをやる

「プロダクトオーナーがスクラムマスターをやってはいけない」という事は、スクラムのアンチパターンとして書籍や記事で度々書かれていることです。
しかしながら、開発メンバーが少なく、そもそもスクラムを推進していたのは自分一人だけだったため、自分がプロダクトオーナーとスクラムマスターを兼務するしかありませんでした。
私たちのチームでは、開発当初は開発リーダーが不在だったため、開発リーダーが入るまでの間の一時的な条件付きで多少強引でしたが兼務状態で進めました。
後から見ても、兼務以外の進め方は難しかったなと感じていますが、タスク量的に長期的な兼務は厳しいと思うので、基本的に兼務は避けたほうがいいと思います。

相対見積りが分からない

正直今でもよくわかってないです。最初のうちは基準とするPBIが少なく、なんとなくの感覚でポイントを設定していました。
個人的には、なんとなくでも良いのでストーリーポイントを決めて、次のスプリントの基準として使うことを繰り返せば、チームのベロシティが安定すると考えていました。
ですが、「なんとなく決める」が曲者で、根拠がない見積りに馴染めず、「時間見積りにしたほうがいいのではないか?」という意見は何回かありました。
レトロスペクティブでも何度も見直しをしています。「とりあえずやり続けてみよう!」と半ば強引に進めた節は否めませんが、とにかく続けてベロシティが安定したあたりで、この問題は落ち着きました。

デイリースクラムが進捗共有会になる

スクラムを実践して数スプリントを経験してから、この問題は発生しました。
私たちのチームでは、お昼時の15分で毎日実施しています。当初はスプリントゴールに対する意識も薄く、自分たちの作業報告だけで終わっていることが多かったです。 時折、相談の場としても使っていましたが、対象のメンバー以外はただ聞かされているだけという状況だったので、「進捗共有はSlackで報告し、相談はハドルやMeetsなどで個別実施すれば、デイリースクラムは無くても良いのではないか?」という意見がありました。
数スプリントだけでデイリースクラムを廃止するのは早計だと感じたので、デイリースクラムの内容を見直しました。
スプリントゴールの達成状況を意識するようにしたこと、デイリースクラムのファシリテーションをメンバーで回すようにしたこと、相談は頭出しだけにすることというような運用に変える、といったポイントがデイリースクラムの意識改変に繋がったかと思います。

ちなみにプロダクトオーナーはデイリースクラムへの参加は任意のところが多いようですが、私たちのチームでは原則参加にしています。

スクラムを導入して良かったこと

ここからは、スクラムを導入したことで私たちのチームや会社に与えた良い影響について書いてみます。

スプリントサイクルで機能をリリースできるようになった

スクラムなので当たり前ですが、スプリントの間隔で機能をリリースすることが出来るようになりました。
スクラムを導入していなかった別のプロダクト開発と比較すると、機能単位で実装することが当たり前だったので、複雑な機能だとその分だけ時間を要していました。大きすぎるPBIは、スプリント期間内で完成できる単位に分割することを意識出来るようになったのは大きかったです。

スプリントのベロシティが安定し、機能の見積りがしやすくなった

当初の見積りは不安だらけでしたが、14スプリント以降からは、ベロシティが安定するようになりました。
スプリント内で設定できるストーリーポイント数をベロシティ基準にすることで、取り掛かるPBIの量を調整しやすくなりました。
ベロシティは、6スプリント以降で安定し始めるというのを記事で見ましたが、私たちのチームは倍以上の時間がかかっています。この理由には、開発リーダーが不在だったことと、私が兼務だったことで見積りに関する振り返りが十分に出来て無かったことが原因かなぁと反省しています。

リリースされる機能の共有タイムラグが減った

スプリントレビューに営業や社長に参加してもらうことで、利用可能な機能や開発途中のもの、ロードマップが非常に共有しやすくなりました。
これまでにも定例会議を通して進捗共有を行うことはありましたが、完成の定義を曖昧にしていたり、完成しても機能の説明を口頭説明で済ませていることがありました。
動くものを必ず見せることで開発の進捗状況を体感しやすく、フィードバックも貰いやすくなったと思います。

参考になった書籍

スクラムを始めるにあたって、私自身知識がゼロだったので様々な書籍や記事を参考にしました。 ここでは、自分が参考になった書籍を紹介します。

スクラムガイド

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

書籍ではなく、公式が出しているスクラムガイドのPDFです。2020年版になってコンパクトになったため、スクラムをやり始めたいと思った人は、まずは読むべきだと思います。 注意すべき点として、スクラムガイドにはスクラムの目的や流れしか書いておらず、「どのように実践するのか」といったHowは記載されていないため、Howについては他の書籍や記事を参考にしたほうが良いです。

SCRUM BOOT CAMP THE BOOK スクラムチームではじめるアジャイル開発

www.amazon.co.jp

スクラムをこれから始めるなら手元に置いておきたい一冊です。注意すべき点として、本書はスクラムガイド2017年版をもとにしており、2020年版のスクラムガイドと細かいところで異なる点があります。例えば、スプリントプランニングは本書では2トピック(「なに」と「どのように」)だが、2020年モデルでは「なぜ」のトピックが追加されています。 とはいえ、それほど大きい変更点ではないので、本書をまず読んでから2017年と2020年の変更点を押さえておくでも良さそうです。 私たちのチームでは、メンバーに一冊配っています。

アジャイルな見積りと計画づくり

www.amazon.co.jp

本書はスクラムではなくアジャイル開発における見積りやプランニングについて記載された本です。ですが、スクラムでも参考になる部分が多いです。アジャイルの原理や具体的な計画方法、ストーリーポイントや相対見積について知りたいなら、この本をお勧めしたいです。 ただ、ページ量が多く、翻訳本なので多少の読みづらさがあるため、最初に読むよりWeb記事やSCRUM BOOT CAMPのような優しめの内容から入り、アジャイルを何となく知った後に読んだ方が良いと思います。 作業の見積りについて理論的に解説されており、「なぜそれをする事に意味があるのか」といったそもそも論で迷った時には、本書が解決の糸口を見つけてくれるかもしれません。

実践スクラム

www.amazon.co.jp

主に受託開発においてスクラムを実践する方法が記載された書籍ですが、Howの部分が非常に具体的なので自社開発においても参考になる部分は多いです。他のスクラム関連の書籍は、スクラムのコンセプトや方針といった抽象的な所までを扱うことが多く、本書のような具体的なHowにまでフォーカスした本は多くありません。理論は分かったけど、具体的なHowも知りたいという方にお勧めです。

まとめ

ゼロからの導入ということもあって、時間はかかりましたが現在は安定してきたと感じます。 最初のうちは相対見積りや、機能単位ではなくユーザーストーリー単位で分けるなどが馴染めず、不安が大きかったですがレトロスペクティブなどを通して、スクラム体制を見直すことを繰り返すことで良くなったと思います。
まだまだ課題はありますが、トライアンドエラーを繰り返して洗練していこうと思います。