LAPRASでProductOwner（以下PO）をやっている那須（@nasum360）です。少し前までLAPRASではWebアプリケーションエンジニアをやっておりまして、POになってからはまだ1ヶ月程度しか立っていない新人です。慣れないバックログ管理や、その他調整のためのMTGなど最初は慌ただしかったですが最近はようやく慣れてきました。

そんなWebエンジニアからPOへのジョブチェンジも出来るLAPRASですが、採用要件も公開していますので、よければご覧ください！（唐突
採用要件: Webエンジニア - 2019秋

今回はLAPRASの開発プロセスについて紹介していきたいと思います。LAPRASにおけるissueの作成から実装されリリースするまでの流れをお伝えできればと思います。

LAPRASの開発プロセス

LAPRASの主な開発プロセスは大まかに次のように行われます。

1. issue作成と分類
2. 優先順位付け
3. スプリント準備
4. リファインメント
5. 計画MTG
6. 実装
7. リリース

issueの管理とスプリントの管理はGitHubとZenHubを利用して行います。ZenHubのマイルストーンとパイプラインの機能を使用し、スプリントとそのスプリントで実装するissueの管理を行っています。

それぞれのプロセスについて細かく見ていきます。

1. issue作成と分類

issue作成は任意のタイミングで行われます。誰かがバグを発見したとき、機能改善を要望したいとき、突如としてLAPRASを最高にクールにする機能を思いついたとき。issue作成者や作成されるタイミングは様々です。

作成されたらnew issueというパイプラインに溜まっていきます。溜まったissueは分類されし各パイプラインに配置されます。主にその作業の役割はPOが担います。

分類はissueにラベルをつけることと、他のパイプラインに移すことで行われます。ラベルを付けられたissueはLAPRAS SCOUTやLAPRASの機能に関連するものはPMが一度優先順位をつけるため専用のパイプラインに移動され、それ以外のバグ修正や改善タスクなどはPOが管理するパイプラインに移動されます。

issueによっては何を解決したいか不明瞭な場合があります。そういう場合はissue作成者宛てにコメントをします、何度かやりとりを行い明瞭化を行います。例えばissueにバグトラッキングサービスのURLを貼り付けるだけのものは明瞭化の対象になります。

無事分類や明瞭化が行われたissue達は優先順位付けに進みます。

2. 優先順位付け

分類され各パイプラインに移動されたissue達はそれぞれのパイプライン内で優先順位付けされます。LAPRAS SCOUTのパイプラインはLAPRAS SCOUTのProductManager（以下PdM）、LAPRASのパイプラインはLAPRASのPdMにより優先順位がつけられ、それ以外のバグ修正や改善タスク等のパイプラインはPOが優先順位をつけます。

各プロダクトがもつissueの優先順位とバグ修正のissueの優先順位が決まったら次はスプリント準備に入ります。

3. スプリント準備

優先順位付けされたissue達はいよいよ実装を待つべくスタンバイ状態に入ります。LAPRASではあらかじめスタンバイ状態のissue達を2スプリント分作成します。N+1とN+2というパイプラインがあり、次のスプリントで実装したいissue達をN+1に配置し、それ以外で優先度が高いものをN+2に配置します。

N+1にissueを配置するとき、POとして気をつけることは必ずインパクトのある機能issueを1つは入れるということです。ここで言うインパクトのある機能とは外部にメールやSNSでの告知が必要な機能のことを指します。毎スプリント何かしらユーザに伝えるべき機能が実装されるように調整しています。

次のスプリントで実装するissue達が決定したら、詳細な見積もりをすべくチームでのリファインメントを行っていきます。

4. リファインメント

リファインメントでは開発者が実際のissueを見て開発する機能の詳細化と見積もりを行います。この作業はスプリント終了日の二日前の午前中に行っており、それぞれのissueの内容で近いところを実装したことのある詳しい開発者がアサインされます。

アサインされた開発者はissueを読み誰でも実装できるように手順をコメントし、暫定的なポイントを振ってN+1のパイプラインからReadyのパイプラインに移します。Readyは次のスプリントで実装されるリファインメントを行ったissueが配置されるパイプラインです。

理想的にはスプリント計画MTGまでにN+1のissueが全てReadyに移っていることが期待されます。

5. 計画MTG

計画MTGではReadyのパイプライン上にあるissue達の中から最終的にどのissueを実装するかを計画します。

Readyにあるissue達はリファインメントされているのでポイントを見積もることが出来ます。ポイントの見積もりはプランニングポーカーにて行われます。各開発者の実装の認識のずれをここで合わせポイントを調整し、次のスプリントで実装するissueを決定していきます。

5. 実装 〜 6.リリース

スプリントの計画を終えた翌日から次のスプリントがスタートし、issueの実装がはじまります。

実装されたissueはmasterにマージされまずはstaging環境にリリースされます。staging環境での確認を終えたのち、releaseブランチにmasterがマージされることにより本番環境へのリリースが行われます。

また実装している最中に開発者が気づいたことがあればissueを新たに作ります。開発者だけでなく新たな施策を考えついたPdMや、バグ報告をうけたCustomerSuccessの皆さんもissueを作成します。作成されたissueは吟味され、POやPdMは次のスプリントに何をやるかを決定すべくissueの分類や明瞭化をすすめていき、各パイプラインにissueを移動していきます。

基本的にはこれを繰り返しスプリントを実行していきます。

プロセスは常に改善を続ける

以上がLAPRASでの開発プロセスでした。現在はこのようになっていますが、不都合があれば常に改善の手を加えています。直近だと優先順位にPdMが最初は加わっていなかったのが加わるようになり、PMがプロダクトの機能について優先順位が決められるようにパイプラインが追加されました。このことによりPMが優先度が高いと思っていた者がいつまで経ってもリリースされない問題が解決されました。

まだまだ改善の余地のある開発プロセスだとは思いますが、プロセスを変えることを恐れず柔軟に対応することで良い機能を正しくリリース出来る体制を整えていければ良いと考えています。