mikanの開発項目の決め方とリリースまでのフロー

f:id:mizonit:20210208232453p:plain

はじめまして。株式会社mikanの @aviciida です。

主に 英単語アプリmikan の iOS開発をやっています。

詳しい自己紹介は 最近 noteにまとめたので お時間が許せば是非ご覧ください。


はじめに

実は今回が初めてのTechブログです。

前回の記事が過去最高に読まれたこともあり、少し緊張しています。

mikan-tech.hatenablog.jp


さて、今回の記事では 面談でよくエンジニアの方に聞かれる質問を書いていきます。 内容としてはテック寄りのテーマではないのですが、mikan社のプロダクトチームに興味がある方は是非ご覧ください。

採用候補者の方に よりそえるよう、Q&A方式で書いていきたいと思います。


今回は 下記の2つにお答えしていきます。

「開発Issue の決まり方は?🤔」

「リリースまでの流れは?🤔」




開発Issue の決まり方は?🤔

開発issueは大きく2つに分けられます。

「クオーターのテーマから決めるもの」と

「突発的に発生するもの」

開発スプリントは1週間です。

毎週金曜のSprint Planningにて、どんなIssueをどれくらいやるかを決めています。

mikanでは大体8:2くらいの割合です。



1. クオーターのテーマから決めるもの

mikanではクオーター制(四半期 制)を採用しており、毎年1, 4, 7, 10月の最初の週に、経営方針を踏まえてテーマを決めるようにしています。

設定するテーマは、細かい部分ではそれぞれ違えど、大きな部分では「改善サイクル回す系」と「開発基盤整える系」の2つに分類されます。


改善サイクル回す系

「7日後継続率をN%に!」や

「サブスクへのCVRをN%に!」

といった、いわゆるグロースらしいテーマはこちらに入ります。

前述のタイプとは違い、目標達成までの道のりがクオーター初めで見えていることは基本なく、むしろクオーターを通して施策の実行しながら解像度がどんどん上がっていくため、やることは週次で変わってくる、という特徴があります。

その名の通り、週次で改善サイクルを回していきます。

各週のissueの決め方としては、その週までにやった施策の分析結果、および検証したい仮説を元にissueを作っていきます。デザイン・要件定義が必要な施策も多いので、issueを決めてから、実際に開発着手までは1~2週間必要な場合がほとんどです。


開発基盤整える系

ここ最近取り組んでいる「アプリのデータベース刷新」はこちらに入ります。

iOSSQLiteを、AndroidはRealmを使っているのですが、それをFirestoreに統一していくために、 それぞれのDBに依存しているロジックをFirestoreへ移行していくプロジェクトです。

ユーザーに直接価値を届けていく施策、というよりかは、今後届ける価値の大きさ・早さを向上させていくためのものですね。

こういうプロジェクトは「各ロジックをリプレイス(+リファクタ)していけばDONE」というふうに、完了までの道筋は比較的立てやすいという特徴があります。

各週のissueの決め方としては、前週までの進捗、および全体のマイルストーンを見ながら、次の週にやるべき、かつ他のissueとのバランスも見てできる範囲のissueを取っていく、という方式でやっています。


2. 突発的に発生するもの

ユーザーの皆さんからの要望や不具合をもとにした開発項目、およびクオーターのテーマとは別文脈だけど開発が必要なもの、がここに分類されます。

特に不具合や要望に関しては、大小含めて100以上存在するので、CSチームと毎週話す時間を設けて、優先順位の整理を行なっています。

その優先順位をもとに、次の週に取り組むissueを決めるようにしています。



リリースされるまでの流れは?🤔

issueが決まってから開発に着手するまでに、まず「仕様」と「デザイン」においてのすり合わせが必要です。

mikanには専任のPMを置いていません。ですので、

「開発基盤系」は デザインが不要な場合が多いのでエンジニアが仕様を決めてレビューしてもらい、実装。

「改善サイクル回す系」はデザイナーが仕様・デザインを作り、実装担当のエンジニアに共有。

という形を取っています。


後者に関しては、「デザイナーが決めたものをエンジニアが実装」という流れを想像するかもしれませんが、mikanでは、持ってきてもらった仕様とデザインに関して、エンジニアが(特に仕様に関して)修正提案をすることも多いです。

バリューにも"Why" DrivenとWith Userがある通り、全員が「ユーザーに価値を届ける」という目的のために動いているため、それを考慮して、改善した方がいい部分は、開発する前にディスカッションするようにしています。

各開発が完了し、次バージョンのTestFlightへのアップロードができたら、開発担当者が作ったテストケースを、QA担当のアルバイトのメンバーにやってもらいます。

それに加えて、プロダクトに関わるメンバー全員でそのTestFlightのバージョンを触ってもらって、両方とも問題なければ無事リリース、という流れになります。


ちなみに、現状の大きな問題として、安定したアップデートをユーザーへ届けるフローが確立できていないことがあります。 これは、開発レイヤーとQAレイヤーの2種類あるのですが、我こそは!と言う方からのご連絡をお待ちしております。

https://herp.careers/v1/mikan/KPi1w5fIMQW7herp.careers


おわりに

以上、普段のテックチームが取り組んでいる内容の一部をご紹介しました。

載っていない内容についてはこれから本ブログで随時紹介していきたいと思っているので、引き続き見ていただけると嬉しいです。


最後に

弊社では一緒に働く仲間を募集中です。

iOS開発に興味のある方、教育事業へ興味のある方、少しでも興味ある方はぜひご連絡ください!

mikan.link


また、僕の入社自体は1年半ほど前なのですが、最近入社エントリを書いてみたので よければこちらもご覧ください。

note.com