見出し画像

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

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

▶︎ 開発フローの全体像

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

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

開発フローの全体像

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

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

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

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

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

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

Scrum works not because it has three roles, five events, and three artifacts but because it adheres to the underlying Agile principles of iterative, value-based incremental delivery by frequently gathering customer feedback and embracing change. This results in faster time to market, better delivery predictability, increased customer responsiveness, ability to change direction by managing changing priorities, enhanced software quality, and improved risk management.

https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum

(以下 Deeple 翻訳)
スクラムがうまくいくのは、3つの役割、5つのイベント、3つの成果物を持っているからではなく、頻繁に顧客からのフィードバックを集め、変化を受け入れることによって、反復的で価値ベースの漸進的なデリバリーというアジャイルの基本原則に忠実であるからです。その結果、市場投入までの時間の短縮、納期の予測可能性の向上、顧客対応力の強化、変化する優先順位の管理による方向転換の能力、ソフトウェア品質の向上、リスク管理の改善などがもたらされます。

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

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

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

▶︎ 最後に

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

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

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

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

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


この記事が気に入ったらサポートをしてみませんか?