はじめまして。クラスター株式会社でEngineering Manager (EM) をしている倉井です。今回は cluster が開発フローとして採用している epic という仕組みを紹介します。
多くの開発組織と同じ様に、cluster も様々な開発フローを試してきた歴史があります。Trello によるタスク管理、ホワイトボードに付箋を貼ったカンバンなどなど... そうした歴史を重ねてきた結果、現在はepic とよばれる開発フローが安定して機能するようになってきました。epic には1サイクルごとの振り返りによってepicという開発フロー自体を改善していく能力が含まれており、現在も日々改善が続けられています。定期的な振り返りによって開発フローや組織そのものを改善していくという試みは、2015年の創業期から続く cluster の大事な文化です。
epic という名前は JIRA の課題タイプにある epic に由来していますが、ここで説明する epic は完全に社内用語になっています。アジャイル開発で一般的に使われる epic という単語とも意味合いが異なるのでご注意ください。
epic について社内のドキュメントにはこう書かれています。
clusterにおける開発の基本単位
- ひとつのepicは、できるだけ早く終わらせる一つの単位
- プロダクトとしての整合性がそれぞれのepic完了後に保たれている必要がある
- 開発単位としてのepic : JIRAの"epic" = 1 : 1
ちょっとコレだけでは伝わらなさそうですね。まずは1つの機能開発の流れを紹介して epic と呼ばれる開発フローを説明したいと思います。
それでは開発の順序にそってそれぞれの項目を説明していきましょう。
開発ロードマップ
開発を始めるには、まず何を開発するのか決める必要があります。cluster には全社の開発ロードマップがあり、これから開発したい機能とそのリリース目標時期を書いたリストになっています。ロードマップではProduct Manager (PdM)と経営陣が優先順位を決定していますが、社内にはプロダクトの感想や提案を話す Slack チャンネルがあるほか、プロダクトの改善提案と承認を行う開発フローも存在します。ですので、プロダクトの方向性については、社内の意見を集約してPdMと経営陣がロードマップに落とし込むようになっています。そうして出来たロードマップの中から次に開発する機能が選ばれ、次の項目で説明するPRDが作成されます。
Product Requirement Document (PRD) の作成と PRD Review
日本語で言うならば製品要求仕様書ですが、社内ではもっぱらPRD(ぴーあーるでぃー)と呼ばれています。
現在 cluster で運用している PRD はこんな感じのドキュメントで google docs で書かれています。
PRDは開発したい機能が、何を目的としていて、どんなものであるかという要求を簡潔にまとめた文章で、PdMが作成する責任を負っています。機能の説明に加えて画面のワイヤーフレームまで PRD に記載されて、コンセプトが説明出来る状況になると、PdMがこのPRDに基づいた開発を経営陣に提示し承認を受けます(PRD Review)。
epic kick-off 準備
経営陣によってPRDに基づいた開発が承認されると、開発チームの出番です。PRD に書いてある機能を実現するために、EMが実装が可能なエンジニアを集めます。集められるエンジニアはモバイルアプリ、Unity、サーバーサイドといった職能を超えて集められます。機能を実現するために必要な人員がそろっているので、epic メンバーのミーティングだけで API の調整などのコミュニケーションを完結することが出来ます。1人で開発が可能な規模の機能でも必ず2人以上のエンジニアがアサインされ、相談役として epic に参加します。そして、集められたエンジニアの中から1名が epic owner に指名され、以後 epic の進行はこの epic owner に任されます。 指名された epic owner は epic を始めるための meeting である epic kick-off の開催を準備します。epic owner は、開発を始める前に必要な調整や調査をこの準備期間に行います。具体的には PRD に不足している情報を PdM にヒアリングしたり、epic document と呼ばれる準備すべき項目を網羅したテンプレートを埋めていきます。また、前回のblogで紹介した design doc もこのkick-off 準備期間に担当エンジニアが執筆します。こうした準備を進めながら、owner は大雑把な実装時間の見積もりもします。
epic kick-off
kick-off では、epic に関わるエンジニア全員と、UIを設計するデザイナー、Quality Assurance (QA) があつめられます。epic owner から、 この epic で開発する機能の概要、目標としている大まかなスケジュール、各エンジニアの担当範囲、対応する JIRA の epic、毎日の進捗や相談事項をまとめる meeting note の URL の共有などが行われます。こういった共有すべきツールの準備も 前段の kick-off 準備で行われています。この時点で集まったエンジニアで大まかな開発時間の見積もりを再度出します。もし想定される開発時間が、1ヶ月を超えるような大きいものであった場合は、epic の分割も検討します。開発する機能を分割して、段階的なリリースが出来ないか考えるのです。この kick-off 自体は 30 分から 60 分で終了します。
開発開始
いよいよ開発が始まると、各エンジニアはタスクを分解し JIRA へチケットの登録、タスクの開発期間について見積もりを行います。タスクを分解したことで、kick-off 時の見積もりに差があれば、epic 自体のスケジュールに反映されます。このようなスケジュールの管理も epic owner の仕事です。epic owner は、QAと連絡をとり、いつテストが開始できそうか、またテスト項目はどのようなものにするか QA と調整します。こういった相談内容は meeting note に記録されているので、いつでも振り返ることができます。
開発中
開発中の進捗管理は、epic owner に任されており、1つの型にはまとまっていません。バーンダウンチャートのようなチャートを引いて管理する場合もありますし、デイリーミーティングで進捗確認をするだけで済むような場合もあります。epic の規模や難易度によって自由な形で進められます。
開発の途中で PRD の記載と実装がずれそうになることもあります。実装が難しかったり、PRDの考慮にない事象から実現が難しかったりと理由はいろいろあります。その様な時は PdM と epic owner が調整を行い、仕様のほうを実装しやすいものに変えていきます。PdMや epic owner には最初の仕様で求めていた価値を損なわずに、ユーザーへ早くその価値を届ける事が求められています。
バグバッシュ
cluster では毎週金曜日にバグバッシュの時間があります。エンジニア, デザイナー, PdMなど開発職が集まりQAがテストに入る前に開発中の機能をみんなで触る会になっています。epic owner が開発中の機能の簡単な説明をした後、epic に関係する開発職も、関係しない開発職も一緒に機能を試します。この時点で、致命的なバグが発見された場合は、テスト やリリースのスケジュールを後ろ倒しして改善の時間を作ります。とくに問題がない、あるいは軽微な修正で済むと判断した場合は、翌週の月曜でコードがフリーズされ、火曜日から QAのテストが始まります。
QAによるテスト
火曜日から木曜日にかけて、QAが実装された機能をテストします。新しいテストケースによる新機能のテストの他、cluster 全体への影響をチェックするためのリグレッションテストも行われます。テストが行われている間、epic owner は報告されてくるバグの対応方針をPdM, QA を交えて検討し、必要であればepic memberにバグ修正を依頼します。なおテストの期間は対象の機能によっては更に延長されることがあります。
QA sign-off
QA から指摘されたバグが修正され、修正を確認するテストも完了すると QAがテスト完了を宣言します(QA sign-off)。 cluster のリリースは週次で行われており、当然テストのフローも毎週あります。もし開発中の epic が修正を完了出来なかった場合は、その週のQA sign-off ではリリースが許可されず、翌週以降に改めてテストを通過する必要があります。
リリース
QA sign-off されたコードから、リリース用ビルドが作成されます。そしてiOS や Android については各アプリストアの審査プロセスへ提出します。すべての審査が通ると晴れてアプリがリリースされます。ちなみに、サーバーサイドのリリースサイクルはここで紹介したクライアントアプリのリリースとは別のもっと短いサイクルで実施しています。別の機会にこちらも紹介できればと思います。
epic 振り返り
リリースが終わって epic owner はホッとしているところですが、リリースされ次第、epic owner は振り返り会を招集します。参加するのは epic に参加したエンジニアとデザイナーです。この振り返りにはいわゆる Keep Problem Try (KPT) 形式によるテンプレートが用意されていて、テンプレートに従って議論が行われます。議論を踏まえて miro に課題がまとめられ次回のよりよい epic 運用やプロダクト開発に備えます。miro にまとめた振り返りの結果は slack で社内に共有され、epicに参加していない開発職もその知見を得ることができるようになっています。
version振り返り
1回のアプリリリースには、いくつかの epic による開発が含まれていることが多いので、それぞれの epic を担当した owner を集めての振り返りも行われます。ここでは、epic 振り返りで出た KPT を owner が持ち寄り、ほかの epic owner や, PdM, QA, EM, デザイナーと共有します。この会を行うことでエンジニアだけでは解決できない課題を、他の職種のチームに協力してもらったり、より上位の職位のスタッフにエスカレーションすることで解決を図ります。この会では問題解決のためのアクションも決定され、その進捗がJIRAで管理されるようになっています。
epic の完了
version振り返りへの実施で、1つの epic はやっと完了です。JIRA にある epic もステータスが DONE に書き換わりTODOの一覧から消えていることでしょう。もちろん、epic で開発された機能がちゃんと利用されているのか数値で追うなど、epic 完了後に続く仕事もあります。とはいえ開発フローとしてはここで一旦終わりを迎え、epic の member は解散し次の epic が組成されるのを待ちます。また筆者のチームでは epic と epic の間の時間にリファクタリングの期間を設ける事で、簡潔なコードが維持されるように努めています。
epic による開発の良さ
ここで紹介した epic という開発フローで筆者が気に入っている点としては、次の3つがあります。
- 開発の型として機能していること
- ドキュメントが残ること
- 振り返りの仕組みがあること
まず、型として機能していること。これは、epic 実施中の各段階において必要なドキュメントやツールがテンプレートとして決まっていて、epic owner や member がやるべきことがハッキリしているということです。テンプレートに沿って開発を行うことで集まったメンバーのスキルに依存せずにドキュメントや開発工程の管理について、ある程度の水準が維持できています。
ドキュメントが残ること。型として残すべきドキュメントが決まっているので、epic に関連するドキュメントが必ず残されます。決まった場所にドキュメントがあることで、非同期でのコミュニケーションでも円滑に開発をすすめることができます。たとえば、epic に参加するエンジニアが全員集まれなくても、可能な範囲でミーティングを行い、その経緯と結果を meeting note に記録しておくことで、他のメンバーと状況を共有することができます。epic 開始後から新たにエンジニアが参加することになっても、また epic 終了後に機能の詳細を追う必要が出たときにも、なぜその機能が、その様に作られたのか議論を追うことができるのです。
そして、振り返りの仕組みがあることです。これは epic に限らず cluster に根付いている強力な文化で、ひとつのプロジェクトが完了したときに必ず振り返りが行われ次回への改善が残されます。ここで紹介した epic のプロセス自体も振り返りを通して改善されてきたもので、最近ですとバグバッシュは途中から曜日が固定されて epicに参加していないエンジニアも参加が奨励されるようになりました。開発の型があることは重要ですが、それ以上にその型が継続的に改善されていることが cluster の開発チームの大きな強みであると私は考えています。
さて、今回は駆け足ではありますが、cluster が採用している epic という開発フローについて紹介しました。この開発フローに興味をもったあなた、一度カジュアル面談でお話してみませんか? cluster ではエンジニア倍増を目標に積極採用中です。一緒に epic を進めるメンバーをお待ちしています!
