こんにちは、エンジニアのちぎら @_naru_jpn です。ミラティブでは開発プロセス改善の一環として、スクラムフレームワークを試験的にひとつの開発チームに導入し、開発を行っています。該当する開発チームでは1週間のタイムボックスでスプリントをきり、導入開始から12スプリント(3ヶ月弱)をこなしてきました。チームのスクラム開発にも慣れが見えはじめ、当初想定していた開発プロセスの改善も実感が湧くようになってきました。今回は、スクラム導入の背景や内容、今後の展望などをご紹介します。
スクラム導入前の開発体制とモチベーション
スクラム導入前の開発の流れは上図のようです。仕様書と工数の概算をもとにしてガントチャートにスケジュールがひかれ、フェーズごとに開発を進めていきます。もちろんすべて天下り式に開発を進めている訳ではなく、デザインがある程度できた時点でエンジニアも含めてチームで確認をする、PdMと仕様の相談をしながら柔軟に進めるなど、アジャイルに開発をしています。
今までこの体制でスピード感を持って開発を進めてきましたし、ノウハウを持った少数のエンジニアから構成されるチームであればむしろ最適化されたフローであるとも言えます。
しかし、この体制には以下のような、チームやメンバーの数が増えた際に顕在化する弱点もあります。
- ガントチャート上で各フローにつき1人のエンジニアがアサインされる為、実装や知見が属人化しやすい。
- 前段階のフローに遅れが生じると後続のフローの着手が遅れ、全体のスケジュールに遅れや無理が生じる。
- 「仕様書の粒度＝ガントチャート上の粒度」となり、分割リリースなどの議論がしづらい。
- 問題が分割されていないことによって、QAの検証項目数が掛け算で増えてしまう危険性がある。
これからも開発チームの規模は大きくなっていきますし、人数が増えてもそれぞれが協力して力をフルに発揮できる体制を考えていく必要があります。
スクラムにおいて、施策の内容は PBI (Product Backlog Item) に分割して表現されます*1。現状の開発工程を踏まえ、PBI への分割をする時点でデザインの概要はプロダクトオーナーとの擦り合わせが完了している状態を想定してます。QA は 以前の記事 でも触れていますが、社外の QA チームによって行っているので、チーム外部の工程として捉えています。
スクラムの適用によって、前述のような弱点は下記のように克服されるはずだと考えました。
- 詳細な作業内容や背景をチームで共有するので、作業の分担もしやすく属人化しづらい。
- 作業の滞りを早い段階で検知でき、チームで障害の除去のための議論ができる。
- 独立した PBI は単体で先にリリースすることができる。
- 独立した PBI は単体で検証することができる。規模によってはチーム内で検証が完結する。
導入をはじめてから12週間が過ぎ、スクラムのアクティビティも一通り導入した現時点で、日々の作業の中で上のような改善点が実感できる程度にはなってきました。自己管理されているチームによってプロセスを改善していくことで他にもたくさんの利益が得られると思いますが、現状のチームを観察して具体的な改善点をあらかじめ想定しておくことは、スクラムの適用を正当化する上で大切だと考えています。スクラムの導入をしていくにあたって、事前の勉強会なども行っていません。これは座学としてスクラムの方法論に納得してもらうのではなく、実際に業務がうまく回っているかという観点でチームに是非を判断して欲しいからです。
管理ツールの選定
前述したガントチャートの管理ツールには Backlog が使用されていました。管理ツール、既存の開発タスクの移行コストも考慮して、3通りほどの選択肢を挙げました。
- Backlog を使い続ける（カンバン機能を活用する）
- Google スプレッドシートなどで独自に管理をする
- 他の管理ツールを探す
結論としては、3つ目の選択肢である Jira のスクラム テンプレート を採用しました。Jira のスクラム テンプレートではプロダクトバックログ、スプリント、ストーリーポイントなど、スクラムを運用する為のツールが一通り揃っています。使用するツールは必要最小限の機能も持っていればよいとも考えていたのですが、ツールによってスクラムの概念がサポートされる環境は有用でありフレームワークとしてのスクラムも理解されやすいだろうと考え、これを採用しました。*2
既存のタスクの移行については、想定していたほどの負担はありませんでした。というのも、これまでの Backlog による管理では主に施策開発のスケジュールのみを並べており、チームが担当すべき問い合わせ対応など細かいタスクは管理される場所がありませんでした。なので、移行する際は新規施策から Jira のスクラムテンプレート上で開発を進め、細かいタスクは新たに PBI としてバックログに積んでいくといった形式に無理なく移行できました。
日々のスクラムのアクティビティでは、カンバンを画面共有で映しながらチームで確認をしています。使いはじめは慣れない部分もありましたが、数週間経てば違和感もなくなり、使いやすいツールであると感じています。
スプリントの内容
ミラティブでは iOS, Android 共にアプリを1週間ごとにリリースしています。ミラティブでは比較的短い期間でも実施したい施策が変わることもあり、これに対処できる体制である必要があるため、スプリントの期間は1週間としました。また、多くの組織で同じような問題はあると思いますが、プロダクトオーナーを務める PM はすでに多くのミーティングで自由な稼働時間が限られています。強権的に多くの時間を確保することもできますが、限られた時間でできる限りの効果が出せればそれに越したことはありません。
1週間の中では下図のようにスクラムのアクティビティを開催しています。
スプリント計画
スプリント計画では、そのスプリント内で完了したい PBI の確認、PBI のタスク分解、理想日による見積もり*3を行っています。60分という時間は一般的には短いような気もしますが、Atlassian による記述によると「たとえば、2週間のスプリントにおけるスプリント計画ミーティングは4時間以下にとどめるべきです」とされています。アクティビティ外に事前にプロダクトオーナーとバックロググルーミングをすることで、チームのミーティングにかける時間を節約することも考えるべきだと思います。
企画の仕様書からユーザーストーリーの形式に書き出す作業は、スプリント計画ではなく、キックオフミーティングと呼ばれるエンジニアへの仕様の共有の場で行っています。依存している作業はないか、リリースが分割できないか、などもキックオフミーティング内で話しています。*4
デイリースクラム
デイリースクラムは業務の前半に15分で行っています。各メンバーが順番に話をしますが、質問の項目などは定めていません。着手中の PBI について、動作確認の方法など、各自必要と思われることを話しており、今のところ上手く機能しています。
スクラムの適用前は30分の夕会が日次で設定されていましたが、早い時間に障害や相談事項を共有することでよりスムーズに作業に移れるようになりました。夕方のミーティングが必要なくなるだけでも作業に集中できる時間が増えて嬉しいとの声もありました。
スプリントレビュー
スプリントレビューはレトロスペクティブの冒頭の5分で行っています。ここでやっていることは、カンバン上で完了にできる PBI が残っていないか確認する、スプリントを完了して喜ぶことです。
ミラティブは自社サービスなので、進捗をデモしないといけないステークホルダーはいません。従ってスプリントレビューの時間はかなり短くしているのですが、理想的には完了した PBI の成果物をチームで確認したりできると、プラットフォームを横断した知見の共有がチームでより促進されると考えています。金曜日はただでさえミーティングが多くなりがちなので仕方がないのですが、メンバーの成果物を互いに知るというのはチームを強くするためにもあった方がいいとは思うので機会があればどうにかした方がいいのかもしれません。
スプリントレトロスペクティブ
レトロスペクティブはスプリントレビューを行なった残りの25分で実施しています。内容は非常にシンプルなやり方をとっていて、「よかったこと」と「こまったこと/気になること」を各自書いてもらい、順に見て話していくという、いわゆる KPT をやっています。
「よかったこと」には私的なこと*5を書いても構わないとしています。スプリントで得た学びなども共有され、知見の共有に一役買っています。「こまったこと/気になること」は、これも私的なことを書いても構わない*6のですが、チームの内外に関わる関心ごとがたくさん書かれるので、非常に活用のしがいがあります。レトロスペクティブでは、個人的な感想をチームの関心ごとに昇華させて、とれるアクションを考えています。いつもの2倍速で話してはいるのですが、25分ではどうしても時間が足りない場合があります。そういった場合には、レトロスペクティブ自体は時間内に収め、話しておくべき話題について枠外の時間を確保して議論の場を設けるなどしています。*7
課題と展望
チームの外部に依存する作業の扱い
ミラティブではメンバーがスプリント内で介入できない作業が存在します。代表的なものは QA で、QA はスプリントのタイムボックスとは関係のないタイミングで行われ、メンバーは不具合の修正対応は行いますが、QA 作業自体に介入はできません。しかし、チームがユーザーに価値を届けるまでに必要な作業として、時間的な依存関係は正確に把握できるようになっている必要があります。
例えば、QA については Jira のスクラムテンプレートのロードマップ上で依存関係のある課題として通常の施策と色を分けて管理することで、スプリントのタイムボックスと関係がない作業としての QA 工程を可視化する方法を探っています。必要に応じて「未検証の機能」「検証済みの機能」など各段階での成果物を表す共通言語を定義して、スプリント内で混乱が生じないようにしてもよいのではないかと考えています。
QA の他にもチームの外部に依存する工程は存在します。これらは日頃の業務を観察して切り分ける必要性を都度考えていく必要がありますし、別のチームには違った依存関係があるとだろうと想像しています。
他チームへの展開やスケーリングフレームワークの適用
ひとつめのチームへのスクラムの適用で得た学びを活用して、さらに他のチームにもスクラムを適用していきたいと考えています。現在、次にスクラムを導入予定のチームの作業内容をヒヤリングしたり、PdMにスクラムのアクティビティを見学してもらったりして準備を進めているところです。ミラティブではプロダクトの開発と同時に、定期的なイベントやキャンペーンの運用などを担っているチームもあります。そういったチームにそのままスクラムを適用しても、スクラムのタイムボックスと日々の業務との相性が良いとは限りません。スクラムを適用すべき領域とそうでない領域を見極めて、適用すべきでない領域には別の方策を考える必要があります。
複数のチームへスクラムを適用すると同時に、スクラムのスケーリングについて考えていく必要があります。ミラティブには様々なドメインに関するチームがあるので、単にチーム間でバックログを共有すると混乱を生じますが、同じドメインに複数チームが稼働することも想定する必要があります。具体的には LeSS や LeSS Huge などのスケーリングフレームワークを候補に検討をしていますが、他の選択肢も視野に入れて策定中です。
そしてなにより、開発体制の変革をしていくにあたって議論をして一緒に邁進していける方の力が欲しい！
We are hiring!
ミラティブではユーザーにより価値を届けるためにチームを巻き込んで共に成長していける方を募集中です！
*1:ミラティブでは施策を構成する PBI をユーザーストーリーの形式で表現しています。
*2:ミラティブでは従来から Jira を採用しており、ドキュメント管理（Confluence）やバグチケットの管理などに使用していました。とっつきづらいツールという印象もありますが、ちゃんと考えて作られていて、利用シーンがマッチすれば非常に有用なツールです。
*3:「理想日」の考え方は書籍 アジャイルな見積りと計画づくり の中で紹介されています。
*4:ユーザーストーリーへの分割については個人的に書籍 ユーザーストーリーマッピング をおすすめしています。
*5:アーマードコアの新作が出るので嬉しい、など。
*6:ギックリ腰になった、など。
*7:レトロスペクティブのバリエーションについて書かれている書籍は アジャイルレトロスペクティブズ が有名です。アジャイルレトロスペクティブズの巻末でも紹介されていますが、Project Retrospectives はプロジェクトの振り返りについて書かれた書籍ですが、現代にも通じる振り返りのエッセンスが含まれていておすすめです。
*8:実装スケジュールより QA スケジュールの末尾が前にありますが、これは分割されたPBIによってエピック内に複数の QA が発生したからです。
