Lovegraphのアジャイル開発について
前置きとして
ラブグラフに転職して半年、「エモいサービス」のプロダクト改善の土台作りから改善サイクルの回し方までテコ入れしてきた業務をまとめてみる。
前置きとしてプロダクトマネージャーとして入社した時に、会社には「均衡」のメジャーイシューがいくつかあった。
・プロダクトの意思決定者(PO)がいなかったことでのプロダクト作りにおける意思決定の「均衡」⇒部署間のパワーバランス
・ゲスト(顧客のことを弊社ではゲストと呼んでいる)とカメラマンの「均衡」⇒PPM
・Branding&Marketing DrivenでGrothしてきた拝見を前提とした、全社KPI達成のためのやることの「均衡」⇒プロダクト改善の優先順位が下がっていた
・ユーザーの写真を掲載するサービスとしての性質と、予約サービスへの「均衡」⇒サービス改善の基軸、PMFの定義と転換点の見定め
etc.
ラブグラフPMの役割
プロダクトマネージャーがいることで、部署間のお話やプロダクト改善の意思決定は解決された、そのメソッドとして改善をしていくための土台作りについて、話したいと思う。
PMの役割は箇条書きで以下な感じ。
・カメラマンもゲストも大切にするプロダクト作り
・常にチームの中心にいる
・自分の仕事は、「それ以外全部」
・True North(正しい方向性)を指す羅針盤
・チームで最大のスピードを出すことがミッション
・チームを「インペディメント」（障害物）から遠ざける
・Backlogの宿主
・常に大きな問の模索と分解可能なレベルへのイシューへの落とし込み
・モットー：「作らずに解決が最も良い手段」「やることよりもやらないことに集中」
僕らはサービスの利用価値体験を大事にしている。アウトプットの写真のクオリティーを上げるためのカメラマン採用・教育にも力を入れているが、ゲスト側にとっては、たった2時間されど2時間の、撮影時間中の体験がいかに非日常的であるか？カップルや家族として在ることのありがたみや大切さに気づく時間にできるか？を大切にしている。
そのサービス体験を作っていく導線としてのサービス(Online)と、カメラマンがアサインされてから当日までのフロー、撮影当日の細かいディレクションや体験を演出するための仕掛け(Offline)などの、両方をハックしていくミッションがプロダクトチームにはある。
**(オフラインとオン・ラインの図仕掛中)**
大きなプロダクトとして支えていくために、プロダクトチームには開発チーム、デザインチームと、カメラマンチームが所属している。
そして、どうやってプロダクトチームのメンバー一人一人が顧客体験を最大化できるProducerになれるか？均衡を崩すことなくプロダクト改善をしていけるルーチンを作れるか？を考えた挙げ句、アジャイルにたどり着いた。※アジャイル開発に関わる単語や流れなどについては触れません。そもそもAgileとは？という方には王道ですが「アジャイルサムライ――達人開発者への道」をおすすめしています。
導入目的
- サービスの性質上、Couple, Friends, Family, Weddingなどブランドが多岐にわたる中、誰が、どの、いつまでになにをするのかをより透明化し、ロードマップを組んでプロダクト開発をしていく体制を整えて行きたい。
- 「実現されることの価値や必要性を明確にし、チーム全員が認識すること」を入り口に、開発・デザインリソースが限られている中で、意思決定レイヤー + 企画・開発・デザインすべてのパートが、常に背景や優先順位を理解し、チームでIterationを回していくことを目指す。
ツール
①Github
②JIRA + Confluence
前職のLINEでも使っていたからそのまま社内にインストール。ただ自分でビルトしたのでかなり導入コストはかかったし多機能なのでビギナーには難しい。ZenHub(リポジトリを簡単に切り替えられるのは便利、あとシームレス)などがあるが、社内のエンジニアと話して結局JIRAを使っている。どちらかというと拡張性、使いやすさを取った。Github projectsはあんまり使ってないけどSPとかつけられないので検討していない)社内キャンペーンは必要かも。
③Todoist(PM個人)
※10個くらいTodo系サービスを使ってみた結果Todoistに落ち着いた、サクッとInboxに起票できる、生産性をトラッキングし(一時期はTogglでトラッキングしてた)、Karmaを貯められる、利用し始めた当時はGoogle Calendarと同期できたのがユニークだった→が最近Trelloに移管したという話はまた別で。
④Slack bot / Plug-in系
KPIはGoogle App Scriptでbot作ったりしているが、JIRAとのインテグレーションは通知を受け取るくらいしかしていない。Plug-InもGantt-Chart for Jiraとかテンプレート系のは導入している。ちなみにPMはhamlとかGASやSQLくらいだったら書く(笑)
JIRAについて
・課題 & プロジェクト追跡ソフトウェア
・(余談)Atlassian社のバリューが個人的に好き
Open Company, No Bullshit――オープンカンパニー、デタラメはなし
Build with Heart and Balance――心を込めてバランスを考えて作る
Don’t #@!% the Customer――顧客をないがしろにしない
Play, as a Team――チームとして動く
Be the Change You Seek――自分自身が変化の原動力になる
・BoardとPJTでticketの管理を分けている
Project
イシューを管理する場所(Backlogのメンテ)。以下で分けている。
・LPM(ディレクター、カメラマンチームのIssue管理)
・LDEV(開発チームのIssue管理：リードエンジニアがオーナー)
・LDSN(デザインチームのIssue管理：リードデザイナーがオーナー)
Board
管理しているイシューを確認する場所(Backlog, Active Sprint)。
・Product Board(LPM-LDEV-LDSN共通ボード、Active SprintはこのBoardで管理：PMがオーナー)
・LPM / LDEV / LDSN Board(それぞれのIssuesの確認・管理など：PJTと同じくそれぞれのリードがオーナー)
・Product BoardはBlurかけていますが、このような感じ。上がActive Sprint、下がBacklogになっている(実際の画面が見たい方はぜひオフィスに遊びにいらしてください)。
Issuesの課題タイプ・ステータス
・Epic：PJT単位、ページやフローごとに解決したいゲストの課題、基盤/環境整備系、Creative、Allienceくらいの粒度
・Story / Task：Epicに分類されるタスク、StoryかTaskかは特に分けて運用していない
・Bug：文字通り、開発チームにそのまま伝達(差し込み許容)
・Subtask：Story / Taskが基本的には個人で1日以内でDONEに移行できるレベルだが、Epic以下Story / Task以上くらいのイシューはSubtaskで運用。
Sprint運用フロー(A⇒Z)
・Backlog：Iceboxとビュー上はわけていない。起票は自由、PMが常に優先度順位に基づいたメンテナンスを朝晩夜行う(各5−10分くらい)。次のスプリントで進行したい・Due Dateが決まっているIssuesがある場合はlabelで管理。アジャイル会議の前までにアジャイル会議のwikiを作成し、常にどの案件が、どの優先順位に則って、進行しているのか(ステータス)を管理し、社内の誰でもアクセスできるようにしている。
・Chart：Burndown Chartのみアジャイル会議で共有・確認。
・Dairy Scrum：10分間x朝晩2回開発チームとPMで、今日やるタスクと今日完了したタスクをボードで確認(JIRAのボードとUI統一、インターン生も多いため、その場で開発の悩みやIssueの優先順位などを確認)。晩のDairy Scrumでは、Good or Badをポストイットに書き込み共有。
・Development：Active Sprintに含まれるIssuesを優先度順に実装する。
・Effect Measurement：事前に仮説検証シートを作成。リリース後にデータとユーザビリティーテストをもとに検証を行い、フィードバックとIssuesの作成。
・Filter：JSQL(JIRA Sctructured Query Language / 基本的な構文はMySQLと同じ)はPMが書いて適宜必要なFilter作成。
・Gant-Chart：PJT単位で任意で作成。
・ KPT：アジャイル会議日に振り返り。Keep or Problem(Tryも必須)をKPT Sheetに書き込む
・Priority：Highest, High, Middle, Low, Lowestの5段階で管理。
・Regular Maintenance：BacklogにあるLow以下のIssuesを月1で管理し、ステイかPostpone or Wont DoでClose。
・Regular Lunch：開発・デザイン・カメラマンチームで2wに一回ランチしている。チームビルディング目的。楽しく和気あいあいとやっています。
・Release：月曜日と木曜日。Hotfix対応は随時PMとリードエンジニアが判断。
・Requirement Definition(要件定義・仕様検討)：次回Sprint開始日までには、進行すべきIssuesの仕様・要件は確定しているものとする。仕様に関してはDirector並びにPMと、Designersがそれぞれ確定してすり合わせながら確定する(別でプロダクト定例会議があるのでそこでメインですり合わせる)。
・Story Point：規模の大きさの単位。作業内容、難しさ、リスクなど一体化したもの。他の作業と比べて相対的に表す。フィボナッチ数列(1,2,3,5,8,13,21..)でつける。ベロシティーは毎Sprintごとに計測。
・Sprint：2週間(試験運用の結果結局2wが一番フィットした)。水曜日から火曜日、火曜日には3h-4hのアジャイル会議を開催。
QA：QAは基本的にPM・エンジニア・デザイナーがリリース後に随時行う。大きめのEpicリリースの場合はリリース前日に実装完了し、リリース日当日の朝までにQA完了、対応優先度をつけてCrtical Issuesが対応可能であれば、それ以外は置いておきリリース優先。
全職種採用中です!
ラブグラフは、ゲストの体験を作り届けるサービスです。一番に価値があることは、アジャイルを完璧に回すことでも、完成度の高いプロダクトを作ることでもなく、そのプロダクトを通して人々を幸せにする、世の中を前に推し進める、ことだと思っています。人々を幸せにするプロダクトを発明し、世界を一緒に変えていけるメンバーを絶賛募集中です。FacebookかTwitter DMでいつでもご連絡ください！
