本記事はGlobis Advent Calendar19日目の記事です。

はじめに

こんにちは、グロービスでアプリ開発チームのモバイルアプリエンジニアとスクラムマスターをしているmaKunugiです。今回は表題の通り、スクラムの運用にグロースハックのプロセスを組み込もうとした時の試行錯誤を記事にしました。本記事で紹介する運用方法は絶賛試行錯誤中のものであり、今後大きく方針を変えていく可能性もあります。しかし、１クォーター通して運用をしてみての様々な学びがありましたので、思い切ってまとめてみています。少しでもこの記事が参考になれば幸いです。これからさらに改善をしていきたいと考えていますので、FB等ありましたらお気軽にお寄せください。

開発しているサービス

グロービスでは、「グロービス学び放題」というビジネスを動画で学ぶことのできるサービスを、Webサービスやモバイルアプリとして運営しています。

iOS
Android
Web

本記事では、上記のiOS, Androidアプリを開発している「アプリ開発チーム」が取り組むスクラム運用についての内容になります。

対象読者

• スクラム開発を行っている方
• スクラム開発でサービスのグロースを行いたい方

スクラム開発で直面した問題

弊社では、多くの開発チームが「スクラム」を採用しています。私が所属するアプリチームも開発に「スクラム」を採用しており、以下のような構成で開発をしています。

• プロダクトオーナー
• デザイナー（2名）
• エンジニア(3名　※スクラムマスター含む)

今年のアプリ開発は、今まで行なっていた負債解消やフルスクラッチの開発等を乗り越え、サービス改善のための「グロース」に本腰を入れるフェーズでした。クォーターごとに伸ばすべき数値を定めてOKRとして掲げ、サービスがグロースするための「施策」の開発、つまり「グロースハック」に取り組んできました。

※本記事では以後、サービスがグロースするために行う施策を「グロース施策」と表記します。

長期のユーザ調査を踏まえた大きめな開発もあれば、特定の指標の向上を目掛けて短期的に細かな施策を数打つような開発もありました。本記事で取り上げたいのは、後者の「短期的に施策を打ち出していく」際に直面した問題です。

短期間に数多くの施策を生み出す上での課題

チームで抱えたく課題は、大きく分けて下記の4つでした。

1. グロース施策のリリース回数をなかなか増やせない

これはグロースに限った話ではありませんが、グロース施策は入念にアイデアを練ったとしても、それが本当に効果的かどうかは、リリースしてみないとわかりません。効果的な施策を見つけるには、数多くのリリースを行い回数をこなす必要があります。モバイルアプリの場合、ストアの審査があったり、最新版がユーザに浸透するのに時間を要したりと、特にユーザに届くまでに時間がかかりがちです。スクラムチームの開発の生産性を高めていく必要があるのはもちろんのことですが、単に生産性を上げるだけでは解決できません。チームが行う開発の対象は常にグロース施策だけとは限りません。他チームからの要望や事業上行わなければならない機能の開発、負債解消のためのリファクタリングなど様々です。グロース施策のアイデアを生み出せても、うまくスクラムのプロダクトバックログに絡めて優先度を明確にしていかなければ、スムーズに施策を打っていくことはできないのです。

2. プロダクトバックログにあるグロース施策が枯渇する

１の課題にあった「リリース回数」を増やすには、スクラムチームの生産性を上げることはもちろんですが、「グロース施策が枯渇しない」ことも非常に重要です。弊チームでは従来、基本的にプロダクトオーナーを中心に施策を起案し、チームでリファインメントをしながら施策を開発可能な状態にしていました。(そもそもプロダクトオーナーは本来「「施策」を出すこと自体に責任を持つロールではありませんが、弊チームの状況はそうでした。)　しかし、プロダクトオーナー1人で数多くの施策を短期間で出し切るのは負担が大きすぎるため、チーム全体で施策を生み出してプロダクトバックログにグロース施策が枯渇しない状態を作ることが必要でした。

3. グロース施策がコンフリクトする

徐々に開発がうまく回るようになり、複数のグロース施策を同時にリリースできるようになると生じてくるのが、グロース施策同士のコンフリクトです。複数の施策を走らせる場合、同時に走らせると施策の効果が正しく測定できなくなるケースがあります。例えば、同じ画面の近しい機能を同時にA/Bテストするなどです。いざ新しいグロース施策をリリースしようとしても、「xxの機能がまだ効果測定中だからまだ出せないね。」となり、せっかく開発してもしばらく寝かせておく必要が出てしまうのです。開発したらすぐにリリースをしてしまい、Feature Flag等を活用して施策をスムーズに切り替えることももちろんできますが、開発した施策を寝かしておかないといけないという点では同じです。グロース施策の実施順をうまく考えないとこのような問題に直面するため、上手くプロダクトバックログのアイテムを優先度付けし、調整をしていく必要があります。

4. 施策の結果の分析から学ぶことができない

スクラムでは「検査」と「適応」をスプリントごとに繰り返し、チームの生産性を高めていきます。ただし、通常のスクラム運用ではどうしても「スプリント」の単位にフォーカスが行きがちです。スプリントはインクリメントを出すところで一旦終わりますが、グロース施策はリリース後実際にユーザにある程度利用されてからようやく振り返ることができます。つまり、リリース後のグロース施策の進行はスプリントとは独立しており、リリース後にうまくスクラム運用との接点を作らなければ、グロース施策の結果をうまくチームに還元(スクラムでいうところの「適応」)することができないのです。

実施したこと

ここまで述べてきた問題を解消するため、Hacking Growthという、有名なグロースハック教本を中心に、グロースハック関連のインプットを行いました。そして、チームのスクラム運用にグロースハックのプロセスを組み込みました。下記はその運用の全体像です。

運用解説

上記の運用イメージについて説明をしていきます。

イメージ図の各要素について

まずは図の各要素についてです。

こちらの黄色の四角は、スプリントごとに行われる定常的なイベントを表します。実戦の枠線はスクラムチームのメンバー全員必須参加のイベントです。

尚、点線の枠線は、スクラムチームのメンバーが任意参加のイベントです。

赤の四角のイベントは不定期開催のイベントです。

青の四角は各イベントで生み出される成果物です。

端的に言うとどんな運用か

通常のスクラム運用に下記2つのポイントを盛り込んでいます。

1. グロース施策のアイデア起案とそのプロダクトバックログアイテム化までを行うプロセスを組み込む
2. グロース施策の実施結果をチームの開発プロセスに還元する

この２点を盛り込むことによって、上述した問題の解消を試みました。

この運用が問題の解消につながると思った根拠

スクラムにはスプリントごとに開発を行うためのプロセスがありますが、グロースハックにも必要なプロセスがあります。先ほど述べた課題の大半は、この２つのプロセスが噛み合わずに独立していることに原因があると考えました。

Hacking Growthでは、グロースハックに必要なプロセスをこの図で説明しています。

グロースハックでは上記のイメージの円にある４つの項目が鍵になるわけですが、今回チームが抱えていた問題をこのグロースハックプロセスをベースに整理してみました。

1. グロース施策をコンスタントにリリースできない 👉 優先順位の付け方の問題 (+ 生産性の問題 )
2. プロダクトバックログに積むグロース施策を枯渇させない 👉 アイデア生成の問題
3. 施策ごとのコンフリクトを考慮する必要がある　👉 優先順位の付け方の問題
4. 施策の結果を次に活かす必要がある　👉 分析の問題

問題は、上記のように分類ができ、まず取り組むべきなのは下記の３つの問題ということが見えてきました。

• 優先順位の付け方の問題
• アイデア生成の問題
• 分析の問題

この３つの問題を考えていくと、通常のスクラム運用では補うことのできないポイントがあったため、本記事で紹介している運用では、いくつかのイベントを追加しています。

※ 1の問題は「生産性の問題」も絡みますが、趣旨が少しずれるので割愛します。生産性はスクラムの運用事態にその向上のための仕組みが備わっています。

上記の3つの問題を１つ１つ見ていきます。

優先順位の付け方の問題

プロダクトバックログアイテムの優先度は、スクラムにおける「リファインメント」で解決するべきです。優先的に実施すべきグロース施策は、プロダクトバックログの上位にプロダクトバックログアイテムとして配置されることが望ましいです。ここで重要なことは、グロース施策がきちんとプロダクトバックログアイテム化されていることと、優先度を判断するための材料があることです。施策のアイデアだけあっても、プロダクトバックログアイテムにならないことには、開発は始められません。また、優先度をつけるための判断軸がなければ、既存のプロダクトバックログアイテムとの優先度を考えることに困難が生じてしまいます。そして、施策ごとのコンフリクトが起きないよう、実行順番もある程度考慮しながら優先度は考える必要があります。

アイデア生成の問題

この問題を解消する仕組みはスクラムには定義されていません。実施するグロース施策を起案し、プロダクトバックログアイテムに落とし込んでいく仕組みはスクラムのプロセスでは充足できないので、アイデア生成のための仕組みを追加する必要がありました。それが今回新たに追加した、「グロースハックミーティング」や「アイデアセッション」「HMWブレーンストーミング」といったイベントになります。

分析の問題

グロース施策の分析が終わったら、スクラムチームの開発プロセスにその内容を還元してあげる必要があります。グロース施策はリリースから結果が出るまでに一定期間を要することがほとんどなので、施策はリリース後にスクラムの周期である「スプリント」とは独立します。結果が出る頃にはスプリントが既に別のコンテキストで進行しており、施策の結果の還元が疎かになるといったことは避けねばなりません。しかし、普通に運用をしているとそういったことは往々にしてあります。本記事で紹介している運用では、「アイデアセッション」と「グロースハックミーティング」で、グロース施策の結果を開発プロセスに還元する役割を担わせています。

新たに追加した各イベントの説明

洗い出された３つの問題を解消するために、3つのイベントをスクラムのプロセスに追加しました。新しく追加したイベントを１つずつ見ていきます。

1. HMWブレーンストーミング

グロース施策を考える基準となる「How Might We?(HMW)」をチームで定義することにより、チームでのアイデア出しを行う上での指針を作ります。「How Might We?」とは「どうすれば私たちは〜できそうか？」という意味の質問文であり、アイデア出しの際の問題提起を行うものとして活用ができます。これは上述した「アイデア生成の問題」を解消するためのイベントです。

HMWの具体例としては以下のような内容です。

「どうすれば我々は従業員同士の人間関係をより深く発展できそうですか？」

弊チームが取り組んでいるのは、動画で学習ができるようなアプリなので、例えば下記のような内容になります。

「どうすれば我々はユーザーが仕事に役に立つコースにたどり着いてもらうことができそうか?」

HMWの参考資料
IDEO's secret to better brainstorming sessions lies in the phrase "How might we" — Quartz

クォーターごとにチームメンバー全員で必要なHMWを洗い出し、ストックしておきます。この際、サービスのペルソナやそのクォーターにおけるOKRの内容を参考にHMWを考えます。このHMWはそのクォーターで行うアイデアセッションで利用され、円滑にアイデアを出せるようになることを狙っています。

2. アイデアセッション

HMWをベースに、具体的な施策を考えるセッションです。このイベントも「HMWブレーンストーミング」と同様、「アイデア生成の問題」の問題を解決するためのイベントです。それと同時に、「分析の問題」を解消するためのイベントでもあります。

弊チームではデザイナーがこのセッションを毎週セッティングし、任意参加で集まったメンバーがアイデア出しを行なっています。アイデア出しの方法は様々な方法を試行錯誤中ですが、HMWの質問について集まったメンバーの中でペアを作ってブレーンストーミングするなどしながら、アイデアを出し合っています。チームのメンバーは誰でも参加ができますが、スプリントでアサインされたタスクの進捗状況に応じて、適宜参加を判断してもらっています。

また、リリース済みの施策の分析結果がある場合は、アイデアセッションの中で分析結果の振り返りを行います。振り返りを踏まえた上で次のアイデアを議論します。

3. グロースハックミーティング

グロースハックミーティングは、主に新たなグロース施策の評価を行います。このイベントは「アイデアセッション」と同様、「アイデア生成の問題」と「分析の問題」の問題を解消するためのイベントです。

グロースハックミーティングでは、アイデアセッションで出されたアイデアを下記のテンプレートに記載した上で発表し合い、チームで議論します。

（施策テンプレート)

# HMW
アイデアのもとになったHMWを記入。

# 価値仮設
この施策でどんな価値を提供できるか。

# 実現案
施策のhowを記入。必要に応じてUIデザイン案を添付。

# 対象となるKR
施策が寄与するKRを記入。(OKRを運用しているため)

# 懸念点
施策を実施するにあたって懸念事項があれば記入。

議論ではテンプレートで設定している各項目をチームで深掘ります。議論の中では過去のグロースで得られた知見や実際に得られたデータによるエビデンスを活用しながら、その施策の方向性を探っていきます。

議論の最後にはアイデアを評価するためにICEスコアを付けます。
評価に利用するICEスコアは、下記の3つの観点で施策にスコアを付与します。

ICEスコア = I(インパクト:Impact) C(確信度: Confidence) E(容易性: Ease)

(Hacking Growthより)

各スコアの要素ですが、Hacking Growthに記載されていた、各要素の説明を引用します。

I(インパクト:Impact)

これはチームの重要指標、スーパーのアプリで言えば「１ユーザーあたりの収益」がどれだけ改善されるかの見込みだ。提案する価値があるのは影響の大きなアイデアだけだと思うかもしれないが、影響度の高い実験は手間がかかりがちなので、もっと簡単に実施できて有意義な成果が見込める実験を混ぜるとよい。影響度の高い実験をできるだけ多くするのが理想だが、実施の準備に数週間以上かかるものばかりになってしまう場合には、簡単な実験をいくつか予定に入れるようにしよう。ＩＣＥスコアシステムに簡単度が組み込まれているのは、そのためだ

ショーン・エリス,モーガン・ブラウン. Hacking Growth　グロースハック完全読本 (Japanese Edition) (Kindle の位置No.2297-2303). Kindle 版.

C(確信度: Confidence)

期待されるインパクトの実現を提案者が信じている根拠が自信度に表れる。単なる憶測ではなく、データ分析や業界内でのベンチマーク、ケーススタディ、過去の実験などの経験的証拠に裏打ちされていなければならない。

ショーン・エリス,モーガン・ブラウン. Hacking Growth　グロースハック完全読本 (Japanese Edition) (Kindle の位置No.2303-2305). Kindle 版.

E(容易性: Ease)

これは実験にかかる時間と資源を測る尺度だ。新規ユーザー体験を抜本的にデザインし直すとか、ショッピングカートのチェックアウト過程を改良するといったアイデアは、大きな効果が期待できる反面、実施までに数週間から数カ月もかかる大仕事になる。そんな野心的なアイデアの実現性をチェックし、グロースハックのプロセスを回すたびに「目線の低い実験」を見分けやすくしてくれるのが簡単度だ。

ショーン・エリス,モーガン・ブラウン. Hacking Growth　グロースハック完全読本 (Japanese Edition) (Kindle の位置No.2312-2316). Kindle 版.

ざっくりと要約すると、

• (I)この施策は自分たちの達成したいGOALにどれだけの影響があるのか
• (C)その影響を及ぼすと言える自信はどれほどのものか
• (E)この施策を実装するにはどれだけ手間(工数)がかかるか

となります。各施策の議論の最後に、全員でI,C,Eそれぞれのスコアをプランニングポーカーのように出し合い、平均値を取ります。
(掛け算してスコアとする方法もありますが、掛け算すると良くも悪くもスコアが大きく揺れるため、一旦様子見として平均値を採用しました。)

このスコアによってプロダクトバックログに移すかどうかを判断し、プロダクトバックログ化された際も優先度を考える際、このスコアを利用します。
このプロセスを経ることによって、ただアイデアが増えるだけでなく、グロース施策の優先度付けが容易になります。

既存のスクラムイベントで考慮すること

ここまで、新たに追加したイベントを見てきました。通常のスクラムイベントに関しては大きな変更を加えていませんが、グロースハックプロセスを組み込んだことによって多少の影響があります。その部分について掻い摘んで説明をします。

プロダクトバックログリファインメント

プロダクトバックログリファインメントは通常のスクラム運用通り行います。このリファインメントには、先述した「グロースハックミーティング」で議論されたアイデアをプロダクトバックログアイテム化して持ち込みます。グロースハックミーティングで付与したICEスコアを考慮しながら、プロダクトバックログ内での優先度を決めていきます。同タイミングでリリースすると好ましくない施策があるかどうかも考慮し、プロダクトオーナーがプロダクトバックログアイテムの並び順を決定します。

プランニング

プランニングの通常のスクラム運用通りに行い、スプリントで達成するスプリントゴールを決定します。グロースハックミーティングで生まれた新たな施策をプロダクトバックログ化するために、特定のメンバーの調査などの作業が必要なケースがあります。こういったイレギュラーなタスクが発生する可能性があり、「ベロシティ」への影響が懸念されます。その場合、そういったタスクをどういった扱いにするかはチームで決めておく必要があります。

スプリントレビュー

スプリントレビューも通常のスクラム運用通りに行います。スプリントで生まれたインクリメントを確認すると同時に、グロース施策どのバージョンでリリースされるかの確認や整理を行います。リリースバージョンを整理することで、グロース施策の実施タイミングや分析のタイミングなどの目安をチーム全体で認識を揃えることができます。

レトロスペクティブ

レトロスペクティブも通常のスクラム運用通り行います。グロースハックミーティングやアイデアセッションなど追加したプロセスも含めた振り返りを行います。

1スプリントの流れ

ここまで、実施するイベントについて説明をしてきました。一旦時系列で全てのイベントを整理してみます。
１スプリントを時系列順にまとめるとこんな流れになります。

※弊チームは１スプリント=1週間なので、曜日を割り振っています。

月曜日

プランニングでスプリントゴールを決めて、スプリントを開始します。

火曜日

スプリントゴール達成を目指して開発を進めつつ、１時間のグロースハックミーティングを開催します。グロースハックミーティングで今後リファインメントする新たな施策を決定します。

水曜日

スプリントゴールを目指して開発を進めつつ、任意参加でアイデアセッションを実施します。このアイデアセッションは翌週のグロースハックミーティングで議論するアイデアを作成します。

木曜日

プロダクトバックログリファインメントを行い、プロダクトバックログの優先順位を最新の状態にします。優先度の高いグロース施策等を詳細化と見積もりを行い、開発READYな状態にします。最低でも翌週のプランニング時、スプリントバックログにベロシティ分のアイテムが詰めるよう開発READYなアイテムを用意できていることが理想です。

金曜日

スプリントレビューを行い、インクリメントの検査とプロダクトバックログへの適応を行います。インクリメントごとにリリースのバージョンを割り振り、リリース予定日を確認します。

以上で、各イベントの説明を終わります。

利用したサービス

上記のプロセスを実施するにあたって主に利用したサービスもまとめてみます。

miro

アイデアセッションでは、ブレーンストーミングをする際に主にmiroを利用しています。

Notion

アイデアを施策化しグロースハックミーティングで議論する際は、Notionを利用しています。Notionではテンプレートが作成できるため、グロースハック施策用のテンプレートを用意して使いまわしています。

Jira

スクラムのカンバンはJiraで管理しています。

Amplitude

分析にはAmplitudeを利用しています。短時間で高度な分析が行え、尚且つ分析に利用したチャートをダッシュボードやノートブック化して共有できます。グロースハックミーティングでアイデア議論をする際のエビデンスにしたり、施策の効果測定をまとめたりと、開発チームの軸になっているサービスです。

Firebase

リリース後のグロース施策のコントロールは主にFirebaseを利用しています。機能のON / OFFはFireabse Remote Configを、A/BテストにはFirebase A/B Testingを利用しています。

振り返り

このプロセスを通しで行なったのは１クォーターのみですが、実施してみての成果は下記の通りでした。

よかった点

• 目に見えてグロース施策のリリース回数が増えた
• グロース施策が枯渇しなくなった
• 施策同士の影響を考えながらリリース計画ができるようになった
• 施策を実施して得た知見が蓄積され次に活かしやすくなった
• チーム内でグロース施策に関する議論が活発化した

課題

• アイデアの施策化は内容によっては大きな労力がかかる (開発中のタスクに影響しかねない)
• コンテキストスイッチが増える
• 仕組みも大事だが最終的にはアイデアの質が重要

この仕組みの導入によって、解決したかった問題の多くは改善しました。実際にリリースの回数も向上しました。そして、グロース施策作成のプロセスを仕組みとして取り入れたことで、チーム全体で施策に向き合えるようになってきてました。引き続き、このプロセスを運用しながら最適化していこうと考えています。

一方で課題として挙げたように、改善しなければならない点もまだまだあります。新たにイベントを追加したり、アイデア起票の時間ができたことによって、どうしてもスプリント内でのコンテキストスイッチが増えてしまいます。また、グロースハックミーティングで議論して決まった施策をプロダクトバックログアイテムにするには、受け入れ条件の検討やUIデザインの作成、実現可能性の調査等、さまざまな作業が必要になります。それによって特定のメンバーがその作業に大きく時間を取られ、スプリントゴールに影響が出るといったことも実際にありました。アイデア作成系のタスクは時間見積もりの難しさもあるので、そこは大きな改善の余地があります。

そして、仕組みを導入したら上手くいくわけではなく、何よりもその中で生み出される施策の精度や質が重要です。どうしたら質の高いアイデアが生み出せるのか、良質な議論ができるのかはまさにチームで試行錯誤を重ねていきたいポイントです。

まとめ

試行錯誤中ではありますが、スクラムにグロースハックプロセスを組み込んでみた内容をまとめました。上述したような課題はありますが、スクラムでサービスのグロースのための開発をしている方々の参考に少しでもなれば幸いです。FBや改善のアドバイス等ございましたら、ぜひmaKunugiまでお寄せいただけますと幸いです。引き続き試行錯誤を続けていこうと思います。最後までお読みいただきありがとうございました。

次のGlobis Advent Calendarの記事は、QWYNGさんです。お楽しみに！