こんにちは。minne事業部の @amacouです。
minneではスクラム開発をベースに、最近はプロジェクト型開発を併用しています。今回は、そんなminneで働くエンジニアの開発プロセスを簡単に紹介させていただこうと思います。
スクラム開発
minneでは2週間を1スプリントとして スプリント計画 → デイリースクラム → ふりかえり を繰り返すことで開発を進めています。
スクラムチーム
minneはWebとアプリのエンジニアを合わせると15人と大所帯になってしまうため、Web、iOS、Androidなどプラットフォーム毎にチームを分けてスクラム開発を行っています。
スプリント計画
スプリント計画ではminneとして取り組みたい施策一覧(プロダクトバックログ)から今回のスプリントで開発着手するものを施策一覧(スプリントバックログ)に移します。この時、それぞれのタスクについて、チームのみんなで、どのように実装するかを話し合い、どれ位時間がかかりそうかを見積もります。この見積もりをもとに、1スプリントで遂行できる量のタスクをスプリントバックログに移すため、あまり残業を行わないで日々を過ごしています。
デイリースクラム
毎日決まった時間にデイリースクラムを開催し、タスクの進行状況、その日困ったことやその他の相談などの共有を行います。毎日発生した問題をみんなで共有、解決していくことで、開発を円滑にすると同時に、タスクの属人化を防ぐ意味でもとても重要な意味を持っています。
ふりかえり
2週間かけてタスクをこなした後は、チーム毎にスプリントを振り返って
- Keep(良かったこと、続けたいこと)
- Problem(今スプリントで起きた問題、気になったこと、困ったこと)
- Try(Problemに対しての施策)
を話し合います。
基本的に毎日夕会で困ったことを話し合っているのですが、それ以外にも組織やチームとしての問題や、2週間という期間を通して見えた問題点を話し合って問題点をどうやって解決していくかを具体的に決めます。
また、施策のふりかえりも行われ、どれぐらい効果があったか、今後どうするかなどが話し合われます。
ふりかえり2次会
minneは複数チームに分かれてスクラム開発を行っているため、各チームのふりかえりの結果を持ち寄って共有を行う時間、通称ふりかえり2次会が存在します。 ここでは各チームでの問題点の共有と、チームの枠を超えた問題を話し合いを行います。これによって、小さなチームで動きつつも、改善プロセスは事業部全体に波及させることができています。
プロジェクト型開発
プロジェクト型開発は期間限定で(長くて2ヶ月ぐらい)チームから少人数を選出して行います。プロジェクトのメンバーは2週間のスプリントにとらわれずに開発を行い、基本的にプロジェクトのタスク以外を行いません。
プロジェクトの始め方
プロジェクトは短期間集中開発が多く、リリース日が(だいたい)決まっていることが多いです。そこで最初にタスクを洗い出して一覧化し、それらをガントチャートに起こします。
これによって、
- 並行作業できそうなところはどこか
- クリティカルパスはどこか
- タスクが間に合うか
- 削れるタスクは無いか
などを見えるようにしてプロジェクトを進めていきます。
プロジェクトの進め方
なるべく重いタスクやクリティカルパスのタスクを早く終わらせることで、早期に不確実性を排除したり、並列度を上げられるようにしています。スクラムと同じように毎日進み具合や困ったことなどを共有を行い、滞りない開発ができるようにしています。
また上で述べたように、基本的にプロジェクト外のタスクを行いません。具体的には日々の運用業務や機能改善、コードレビューのレビュアーなどは行わずにプロジェクトの早期開発完了に向けて全力を尽くします。
プロジェクトの終わり方
無事リリースを迎えられたらすぐふりかえりを行います。ふりかえりまで終わったらプロジェクトは解散してスクラム開発している元のチームに合流します。
スクラム開発の利点とプロジェクト型開発の利点
スクラム開発は改善プロセスが短く、短期間でエンジニアやチームの練度を上げることができるため、継続的な開発に優れた効果を発揮しています。一方プロジェクト型開発は一気に開発をすすめられる時間や環境が用意されるため、短期的に開発スピードを上げることができます。例えるならスクラム開発は長距離走で、プロジェクト開発は短距離走のようなもではないかと考えています。
また今までも例外的にプロジェクト型開発と同じようなことを行ってきたのですが、これを例外ではなく定期的に行えるチームになったことで、実施できる施策の幅が広がったように感じています。
まとめ
minneで最近取り入れている開発プロセスについて紹介でした。