Aipoの開発はスクラム開発でおこなっていて、1週間のスプリントで開発を進めています。プロジェクト管理にはBacklogを使っています。

ウォーターフォール開発の課題

スクラム開発になる前はウォーターフォール型の開発体制でした。ウォーターフォール型の開発にはいくつかの課題がありました。

実行力/進捗/ゴールの把握が難しい

• チーム全体で、どのくらいの力があって、どこまで達成できて、どこに進んでいるかを把握しづらい

変化への対応に弱い

• 学びまでのリードタイムが長い
• 小回りしづらく限られた時間で成果を出しづらい

タスクの目的共有を忘れがち

• タスクの目的を共有せずに、タスクをこなすだけになりやすい
• 使われないものを作ってしまう可能性がある

ウォーターフォール型の頃は機能をリリースするまでの期間が半年や1年かかることも多く、いざリリースしても市場のニーズに対応できていないことがありました。また、いつ頃リリースできそうか把握することが難しく、開発をペンディングする判断もしづらい状況になっていました。

「チームワーク」と「コミュニケーション」を重視し、チームで仕事を進めるための枠組みとしてスクラム開発を取り入れました。

スクラム開発のメリット

短い期間で最大限の成果をあげる

• 定期的な振り返りで、優先順位の高い機能から順に開発できるので、限られた時間で成果を出せる

早めに軌道修正ができる

• 短期間でリリースすることで、プロダクトがマーケットにフィットしているかを最短で検証できる

自立的なチーム作りができる

• 目標をチームで共有しながらタスクを進められる

スクラム開発になってからリリースサイクルが早くなり、年間90回以上のアップデートを行っています。市場の動向を見て開発の優先順位を入れ替える判断も素早くできるようになりました。スプリントごとの成果がわかることで、誰のどういった課題を解決しようとしているのか意識しやすくなり、チームメンバーにも顧客中心文化が浸透しています。

スプリントの進め方

ここからは実際にどうやってスプリントを進めているかご紹介します。

朝会
毎朝決まった時間に10分ほど行います。それぞれのタスクの進捗や今日やることの確認を行います。

ふりかえり
Trelloをつかってスプリントの中でのKPTAの洗い出しを行っています。

もともとKPTで運用をしていましたが、課題やアイディアを出した後の行動が不明確になることが多かったため、KPTAにしてその後のアクションを明確に決めるようにしました。

ふりかえりは次のスプリントでのActionを決める場として、この会議の前までに各自でKPTをTrelloにリストアップするようにしています。

スプリント計画会議
スプリントの最後に次のスプリントでやることの詳細を決めます。
会議が始まるまでにリストアップしてある課題の中から来週やるものを選び出しておきます。Backlogのガントチャートを見ながら、今スプリントでの進捗と次のスプリントで行うことの確認をしています。
この会議の中でKPIの確認やビジネス全体の動向についても共有をしています。

ふりかえりとスプリント計画会議は毎週金曜日に実施しています。

Backlogの運用方法

プロダクトバックログ、スプリントバックログにはBacklogを使っています。

当初はTrelloを使っていました。運用するなかでプロダクトバックログとスプリントバックログの関係性が見えづらくなってしまったため、Jiraに移行しました。

Jiraでしばらく運用していましたが、シンプルな運用を保ちたい、というニーズとマッチしなくなってきたこともありBacklogに移行して今に至ります。Jiraを選んだ当時はBacklogにカンバンボードの機能がありませんでしたが、Backlogでもカンバンが使えるようになったのも乗り換えた理由の一つです。

具体的なBacklogの運用方法はこんな感じです。

１．顧客の課題をあつめる

顧客から寄せられた課題や要望は「顧客ニーズ」というプロジェクトを用意して、カスタマーサクセス、カスタマーサポートのメンバーがチケットを起票します。

２．顧客の課題を取りまとめる

「顧客ニーズ」とは別に「開発」というプロジェクトを用意して、プロダクトマネージャーが課題を取りまとめて「エピック」として起票をします。エピックには

• 課題
• 実現したいこと・ユーザーストーリー
• 実装方針
• ブランチ名
• リリースフロー
• リリースゴール
• 要望を寄せてくれた顧客

の情報をまとめておきます。

リリースフロー
Aipoでは大きく3つのリリースフローがあります。

• ユーザー毎リリース：ユーザーをグルーピングして段階的に適用する
• フェーズ毎リリース：機能をフェーズ分けして段階的にリリースする
• 一括リリース：全ユーザーに一回で機能をまるごとリリースする

このリリースフローのうちどれにするかを決めておきます。リリースフローについての詳細はまた別の機会に触れたいと思います。

リリースゴール
機能はリリースして終わりではなく、ユーザーに使ってもらうことで初めて価値を生みます。

そのため事前にリリース後のゴールを設定しておき、リリース後に目標を達成しているか計測してPMFを目指します。

要望を寄せてくれた顧客
「顧客ニーズ」のプロジェクトに作成した要望のチケットへのリンクを列挙します。

３．プロダクトバックログをつくる

「エピック」のリストに優先順位をつけたものがプロダクトバックログに該当します。基本的なルールとして顧客からの要望の数をベースに優先順位をつけています。優先順位のつけかたについては他の機会に詳しく紹介したいと思います。

４．タスクを洗い出す

プロダクトバックログのなかで開発に着手するものが決まったら、「エピック」の子課題として「タスク」を作成します。開発ボリュームを見積もるためにも、作業内容をすべて洗い出して「タスク」化しておきます。
タスクの予定時間にはストーリーポイントとして1,3,5のいずれかを入れておくようにします。

ストーリーポイント
Backlogカンバンボードを開発してプロジェクトで使ってみたら“すごく良かった”話で紹介されているように予定時間にストーリーポイントを入れています。

数時間で終わるタスクを「1」、1日で終わるタスクを「3」、2日以内に終わるタスクを「5」と定義しています。
2日以上かかるタスクは、タスクの細分化が足りていないため、さらにタスクを分割するようにしています。

ストーリーポイント「3」の基準としてはCRUDのいずれかのサーバーサイド実装完了相当と定義しています。

このように最大でも1タスクが2日以内に完了するようにしておくことで、スプリントが終わる間際になって実は全然進んでいなかったということが避けられます。
マネジメントをする上でも同じ作業が2日続いても終わっていない時にその作業を止めるなどの判断を早くできます。

スクラムを導入する以前はこのあたりの概念がなく、毎週確実に成果を上げることが難しかったのですが、この制度を導入してから成果を積み上げやすくなりました。Aipoではエンジニアのインターンとして50人以上の学生を受け入れてきました。週数時間しかコミットできないメンバーでも成果を積み上げられるようにするためにうまれたしくみです。
最小最速でユーザーに価値を提供するためにも非常によいしくみだと考えています。

５．スプリントバックログをつくる

Backlogの「マイルストーン」を使ってスプリントを設定しています。

洗い出したタスクのなかでそのスプリントにやるタスクをピックアップして、マイルストーンをセットします。

日々の業務の中ではBacklogの「ボード」でそれぞれのタスクを確認して作業を進めています。

1つのエピックに対して数スプリントをかけて開発をしていくことになりますが、タスクを細分化することで翌週にタスクを持ち越さない運用ルールになります。1週間ごとにタスクを棚卸しすることになるので進捗が管理しやすくなります。