【ユニラボ】 爆速で価値を提供したい！アイミツプロダクト開発フローを紹介します！

アイミツ開発チームでエンジニアリングをしている deliku です！アイミツサービスは今年の4月下旬にリプレイスプロジェクトを完遂し、プロダクト開発を推進していける状態になりましたので、今どんなフローで開発しているのか？を説明していこうと思います。

▶︎ 開発フローの全体像

アイミツプロダクトのエンジニアチームは、お客様の要望や各部署からの要望、プロダクトロードマップで策定した施策の開発などを行います。

そのため、チーム外から知りたい情報（主に、この開発要項はいつ実装されるのか / 優先度の意思決定はどうなっているのか）は、オープンな情報で知りたいときに知れる状況にあるほうが良い ので、フローとイシューリストは オープン する運用となっています。なお、下記黄色のオブジェクトが会議を表しています。

▶︎ 開発タスク着手になるまでのフロー

イシューリスト追加 > 優先度の決定会議 > 改善施策共有会 > 企画会議 と段階を踏む運用をとっており、各方面から発生する開発チームへの依頼を集約、組織として意思決定をしていくフローにしています。
（もちろん、緊急度や重要度に応じて差し込みの対応はします）

最終決定者はプロダクトオーナーになりますが、事前に各部署の要望は、イシューリスト > 優先度決定 > 施策共有会を経由し、重要度や緊急度が整備されている状態を目指しています。これによりプロダクトオーナーの状況把握コストを軽減することにつながります。

▶︎ スクラムとの向き合い方

アイミツプロダクト開発では、1スプリント1週間のスクラムを導入しています。スクラムを導入するにあたり意識していることとして、スクラムイベントを行うことは大事ですが、それらをこなすことがゴールになってはいけません。

大事なことはチームの開発が最速で行われ、ユーザへの価値提供を行えていること と思います。スクラムは 手段 であり 目的 ではない のです。

▶︎ プロダクトバックログ と 開発タスクの管理方法

全体タスクは、Notionで一元管理しています。タスク化されたカードは、左から右に流れていき、タスクの状況は、カードが設置されたレーンで把握できます。仮説 / 検証のタスクはリリース後、効果検証中レーンに移動されます。効果検証結果は、スプリントレビュー で振り返りを行います。

開発タスクの管理は  Github Project を利用し、
開発着手タイミングでGithub Issue化する運用にしています。

▶︎ 最後に

約1ヶ月ほどこの開発フローをまわしてみましたが、下記の意図がワークできているかなと実感しています。少なくともこの機能はなぜ作らないといけないのか？この機能なんで開発優先度高いの？などの疑問をもつような状況には陥っていないので順調なスタートが切れていると感じています。

企画会議で  "Why / What" を理解する
設計会議で "What / How" を具体化し、作りたいもの / 作るもの の認識齟齬をなくす

リリースしたものは大小あわせて60個ほどありましたが、ビルドトラップ（機能の開発とリリースに集中したことで、顧客の本当の課題、プロダクトの本当の価値がおざなりになってしまう状況）にならないよう気を引き締めて、引き続きプロダクト開発を推進していきます！

▶ 【PR】ユニラボ に興味がある方へ

今回の記事を読んでユニラボに興味を持っていただけた方は、まずはカジュアル面談でざっくりお話させていただければと思います！

herp.careers 【エンジニア職】カジュアル面談応募フォーム

PRONI株式会社

募集要項をみる