この記事は、 Mercari Bold Challenge Month の4日目の記事です。
はじめに
こんにちは。新卒iOSエンジニアの @kokoheiaです。今はLister Growthと言う出品に関する施策を担当するチームで働いています。私たちのチームでは、お客様にさらに多くの出品をしていただけるよう様々な施策を考案・実践しています。それに伴い開発チームも新機能の実装を担当することが比較的多いです。本日は、そんな私たちのチームが効率的、かつ継続的にリリースをするために実践してきたアジャイルのTipsについてご紹介します。
メルカリが進めるアジャイル
メルカリでは今 アジャイル体制 を推進しています。全社的にはJIRAをチケット管理に使っていますが、それ以外に厳格に定められた基準はなく、それぞれのチームで違うツールや手法を選択しています。私たちのチームもアジャイルの導入に様々な苦労をしましたが、様々なトライアンドエラーを経て今の形が定着しつつあり、かなり効率化されてきていると感じます。この記事では、私たちが実際に試してきた中でお勧めしたい 2つの手法 をご紹介したいと思います。
1. JIRAを使った進捗管理
ここでは、私たちがトライアンドエラーを繰り返してきた様々なタスクの進捗管理の方法と、紆余曲折を経て現在採用している方法についてご紹介します。
当初の問題
当初私たちはJIRAのスクラムボード / カンバンボードを使って進捗を管理していました。しかし、JIRAでのチケット管理は、どのタスクがどのストーリーに紐づいているのか を可視化するのが難しく、どのストーリーがどの程度終わっているかを管理するのが困難でした。
Trello
上記の問題を解決するためTrelloを試してみました。Trelloの各列をストーリーとして、それに紐づくタスクを下に配置して、構造を管理しました。また、スタンプを使って進捗状況を可視化しました。しかし、この方法には どのタスクが終わっていない/開発中/終わっているかを確認しづらい と言うデメリットがありました。
ボード
Trelloへの反省から、次に私たちは大きな紙のボードを用意して、その中で Gridの構造 を採用しました。つまり、列を進捗状況、行をストーリーとして、各タスクをポストイットでを貼り付けて管理します。これによって 行毎にタスクを細かく分けることができるだけでなく、そのタスク毎の各進捗を列で示すことができるようになりました。 しかしネックとなったのが、チケット情報の管理・共有とベロシティの測定 です。全社的にチケットは以前としてJIRAで管理しているため、最終的にはJIRAとsyncさせなくてはいけないため手間がかかったのと、各タスクの見積もりに対してどのくらい終わったかを示すベロシティの測定を手動でする必要があり、非常に大変でした。
JIRAにGridを導入、現在に至る
ここで、「Gridでタスクを管理する」 というアイディアを得た後でJIRAのカスタム機能をみていると、そこに スイムレーン と言う機能があることを知りました。 スイムレーン使うことで課題をグループ別に分けることができます。スイムレーンでグループ分けをする項目に ストーリー を設定して、それにクエリで指定したいフィルターをかけることによってストーリーごとにタスクを分けることができます。これとカンバンボードを組み合わせることにより、JIRA内でGridのような形でタスクを管理できるようになりました。これが現在チームで採用している方法です。 これによって、JIRAで全てが管理できるようになると同時に、ベロシティの計測に関してもJIRAでそのまま管理することが可能になり、グッと効率が上がりました。
今後の改善に関して
現在作業工程を上記のように改善することができましたが、実は未だにベロシティの測定の部分がうまくできていません。というのも、現在ベロシティの消費はストーリーポイントの消費に紐づいているため、サブタスクをいくら消費してもその親となるストーリーが終わっていなければ消費したことにならないからです。ですから、Sprint途中にあるストーリーにタスクを追加して、そのストーリー全体を終えることができなかった場合、スプリント開始前よりもタスクが増えているというような状況もあり得てしまいます。今回のスプリントではそれを踏まえ、今Sprintではストーリーの粒度をもう少し小さくして、作業がすぐに反映されるような工夫をしています。
2. Dog Fooding
チームとしての効率的かつ安全なリリースに大きく貢献している取り組みのもう一つ目が、Dog Fooding です。このDog Foodingによって、「リリース前日に徹夜で作業しなきゃいけない。。。」といった事態や、QAの方が大量のバグ報告をしなくてはいけない、という事態を避けることができます
Dog Foodingとは？
Dog Fooding とは、別名 "Eating your own dog food" (訳: 犬の餌を食べる) と言われている取り組みで、開発者が自分のプロダクトを自分で触ってみて、バグやユーザビリティなどを確認する取り組みの元です。名前の由来には諸説ありますが、一説にはAlpo dog foodというドッグフードの会社のセールスマンが、自分の犬に会社の商品のドッグフードを食べさせていたことから取られたと言われています。ソフトウェアカンパニーの界隈で特に使われている用語のようです。
私たちの取り組み
私たちのチームではテックリードの推薦により、この機能の開発で初めてDog Foodingを実践してみました。タイミングとしては、ビューのレイアウトや遷移の設計などのUIの作成が終わった時点で1回、UIにロジックをつなぎ込み8割型仕様通りに動くようになった後に1回の計2回 実施しました。
こちらでは、以前開発した機能の際に行ったDog Foodingを例にご紹介していきます。開発の規模としては、新規ビューの構築や細かなアニメーションの実装などを含む比較的大きな案件でした。
プロセスとしては以下のような形で、スプレッドシートに不具合や検討点を上げていきました
- 用意したもの: PC、スプレッドシート、iOS端末(この際にiPadやSEなどの大小デバイスを揃えるとよい) - 所要時間: 30分 ~ 1時間 - 主な参加者: PM、デザイナー、エンジニア(対象機能の開発者を含む)
Dog Fooding終了後、優先度ごとにストーリーを作成し、その中でサブタスクとして具体的なタスクを切り分けました。優先度ごとにバグをグループ化することによって、柔軟に開発プロセスにバグ修正タスクを混ぜ込むことができたと思っています。
効果
結果としては 実施して大正解 で、以下のようなメリットがあったと思っています。
開発工程の途中でバグを発見したため、変更に適応しやすかった
ウォーターフォール式の開発プロセスだと、リリース直前にバグやデグレのチェックをして、大量のバグが発見されて、直しきれずにリリース延期、ということが発生し得ます。これに対して、開発工程の中で Dog foodingのプロセスを効率的に入れていくことにより、後から大規模なリファクタリングを行うことなく、細かく軌道修正をすることができました。 特にこれは新機能の追加など、比較的大きな案件の中で行う ことで効果を発揮するものだと感じました。
QAの方の負担が減った
今回の機能で実施したDog Foodingでは、多くのバグが発見されました。メルカリのiOSチームでは1 ApproveでPRをMergeすることが可能になります。私たちのチームでもお互いにレビューをし合い、チェックを重ねていましたが、Dog Foodingを行ったところ 各約30点 ほどの不具合・検討点が洗い出されました。
その結果、最終的にQAチェックの後に変更のリクエストを受けたのは 18点 でした。最終的にQAチェックの後の変更のリクエストをゼロにすることはできませんでしたが、それでもDog Foodingで見つけた数の不具合報告をQAの方にしていただいたら、ということを想像すると、とても当時のリリースには間に合っていなかったのではないかと思います。
スケジュール管理が効率的になった
開発プロセスの中で必要なバグ修正の工数を把握することができたので、効率的にタスクを見積もることができました。開発プロセスと並行してバグを把握しておくことで、タスク量の不確実性 を減らすことができるというのがメリットだと思いました。
終わりに
今回は弊チームのアジャイルのプロセスについて紹介しました。メルカリではまだまだアジャイル導入の過程ですので、これからさらに改善を繰り返し、また機会があれば知見を共有させていただきたいと思っています。最後まで読んでくださり、誠にありがとうございました。
明日の記事は、@fujimon による「NFC決済のデータ整合性について」です。お楽しみに！
