実践！カンバン方式で週1リリースを可能にする超高速アプリ開発フロー

はじめまして、WantedlyのユーザグロースチームでAndroid開発をしている 吉岡といいます。

今年の4月に新卒入社しまして、インターンだった頃は ビジネスメッセンジャーのSync を、そして今は Wantedlyの会社訪問アプリ および 就活インターンアプリ を開発しております。

まれに勉強会などにも出没しますので、どうぞよろしくお願いします。

さて、Wantedlyのプロダクトづくりを象徴する「ディレクターの居ないチーム」。

トップダウン的に愚直にコードを書くのではなく、プロダクトに関わるエンジニア一人ひとりが 課題を見つけ、アプローチを考え、実装し、検証までを行うことが求められます。

グロースハックを成功させるため、Android版は 毎週1回リリース というとんでもなく早いサイクルを設定しています。そしてこのサイクルを実現するため、4月から 継続的に開発方式を見なおしています。

そこで今回は私たちの実践する ホワイトボードを使って施策を管理し、高速にリリースサイクルを回す方法 をご紹介します。

ところで 先日 住友が公開した記事 はお読みいただけましたでしょうか? 弊社Androidチームがいかにしてグロースハックをスタートしたのか、是非あわせてご覧ください。

高速リリースとタスク管理は水と油

チームメンバーが増えると避けられない課題のひとつが タスク管理 です。

グロースハックでは大規模な機能実装というよりも、ユーザが感じている課題を発見し、それを解決する手段を小さく実装します。よって必然的に全員が全く違う部分の実装を行うケースが多くなります。

1人, 2人程度で管理していた頃であれば、メンバー間の記憶を頼りに 優先順位も進捗状況も把握できるかもしれませんね。

しかし様々なタスクが4人, 5人といったメンバーで並行するとどうでしょう?

誰が何を実装しているのか、結果待ちのまま埋もれている施策は無いか、次に実装すべき手の付いてない施策はどれなのか。例え進捗管理だけをするマネージャーが居たとしても、このスピードを実現するのは難しいはずです。

「見える化」は いつの時代も強力

自発的に施策を考え、選び、実装するためには 様々なことを共有する必要があります。

- アイデア止まりで詰める必要のある施策

- 高速リリースに最適な、低コストで高いインパクトを与えられる施策

- 次に取り組むべき施策

- 今進行している施策

- リリースされ、結果を確認する施策

これらを全員が把握し次のタスクを選びやすくするため、私達は「カンバン方式」を採用しました。

これを私たちは「施策ボード」と呼んでいます。

カンバン方式のタスク管理ツールにはTrelloなどデジタルなものもあります。しかし今回は、タスクフローを厳格さよりもスピード重視にする、物理的な位置を変えて自由度の高いステータス管理をする、なんとなく眺めるだけでもプロジェクトの状況がわかる、 などの強みを取った方が適切なプロジェクトでした。そのためホワイトボードによる運用を選択しています。

理解を早めスピードを上げるフレームワーク

大まかなフローとしては

1. ゴールを設定する

2. ブレインストーミングで細分化されたアイデアを出す

3. 施策化し、優先順位を設定する

4. 各エンジニアが自分でタスクを選び、実装する

5. 効果を測定する

6. 2 - 5を繰り返す

となり、施策ボードはこのフローをチームで高速運用するための様々な工夫が施されています。

それではこのカンバンとボードがどのように運用されているのか、フレームワークを解説しましょう。

まずは設定されたKPIに貢献出来る施策を考えます。

既に機能面では完成されたアプリをグロースさせるので、アイデア1つひとつが重要です。思いもよらぬ課題が見つかったり、アイデア同士が相互作用的に成果を生み出す事があります。

例えば「検索で知ってる会社の名前入れたけど、他社の募集も出てくるのは不便だよね」というような意見が出たことがあります。これってこのままでは「なんとなく不便」というだけでアイデアにすらなっていませんよね。

しかしこの感覚が大切です。ちょっとした違和感や不便が重なると、最後には「不便なアプリだったな」という体験になりかねません。

そんなアイデアを拾うため、私たちのチームでは高い頻度でブレインストーミングを行っています。最初の頃は毎週1時間程度のミーティングでしたが、ブレインストーミングに関しては毎朝5分行うようになりました。週次ミーティングなど全メンバーが集まる時間は施策を精査する時間に充てるためです。

どんなに小さくてもまずは貼り出し、順々に施策として詰めながら書きなおしていきます。例えアイデア止まりでも、ここにあれば他のメンバーの目に付くためミーティングの際に詰められるためです。

ただし、貼りだす際は後述するマッピングを意識しましょう。これを怠ると施策の選定が困難になってしまいます。正確な数値を出すのは後でも構いません。最低限感覚的な位置で設定しましょう。

次にマッピングです。ボード左側のプールは コスト軸, インパクト軸 でマッピングしています。

グロースハックの成功率は10% 〜 20%程度と極端に低いです。だからこそ より良い施策を優先的に実装するため、視覚的に理解出来ることは重要です。

週1リリースを実現するため、ここで施策を適切な位置にマッピングすることで タスク選定の過程を助けています。長々としたミーティングをするよりも、素早く選んでデータ収集と実装の時間を多く取りたいですよね。

例えばさきほど挙げた会社名での検索について。ログから調査したところ、検索キーワードの上位ほとんどが会社名であることがわかりました。そのため多くのユーザは特定の会社の募集が見たい可能性があると仮説を立て、高いインパクトを期待し上部に置きました。

ここで効果を発揮するのが、前途のブレインストーミング頻度です。つまり低コストかつインパクトの高い施策が見つからない、というケースを避けるために行っているのです。最初は半日程度で実装できるタスクが低コストなものとして貼られるかもしれませんが、プロダクトの完成度が高まると 相対的に1日以上掛かるものが低コストなものとして貼られるようになるでしょう。

次に、右側には大きく Next Week, On Progress, Released があります。

これらのセクションは各施策の進捗を管理しています。私たちは毎朝このボードの前で5分程度のミーティングを取り、その際に軽く進捗を話したり、セクション間の移動をしています。

Next Weekは次に実装すべき施策のプールです。次に進める施策をここに溜めることで、メンバーが自分のタスクを選定する際の混乱を減らします。

Next Weekに設定する施策は左側マッピングで効果的だと判断したものです。数が減ってきたタイミングで朝のミーティングの際に追加しています。

リリース前の実装中施策はOn Progressに溜めましょう。他のメンバーが何を実装しているか把握し、施策の方向性がコンフリクトすることを避けています。

ただし、施策が数値に影響を出すのはリリースされてからだというのを忘れてはいけません。

もしマージされていてもリリースされていない場合はこのセクションから移動しません。

リリースされたタイミングでReleasedに移動します。グロースハックとしてどれだけの効果が出せたのか、数週間後に再度データを出して何%改善されたかを確認し、知見を得たらボードから外します。

毎週のリリースに追われて効果の測定を忘れがちですが、こうして残しておくことでミーティングの際に振り返れます。

課題を見つけたらまずは変えてみる

実はこのボード、4月の導入以降 すでに2回もレイアウトを変更しています。

5月末頃に利用していたボードです。

これは目標を達成するために改善したい部分を「少目的」の列とし、それのために利用出来る「チャネル」を行にしてあります。

例えば、「継続利用するユーザを**%増やす」というゴールを設定した場合。

継続して利用してもらうため、少目的として「アプリの使い方を教育する」「ユーザのモチベーションコントロール」「プロファイリング」「流入を増やす」などを挙げました。

そしてそれらを実現するチャネルとして、「Push通知」「お知らせバナー」「メッセージ機能」「登録フロー改善」「アプリ外」「既存コンテンツ活用」などを挙げています。

冒頭で紹介したボードでは「どの目的を解決する施策なのか」「どれだけ直接的に数値へ貢献できるのか」がわかりにくいという課題がありました。

施策アイデアが多岐に渡っているため、目標に直接貢献する施策を選びやすくしたい。これを解決するために導入された、というのが背景です。

結果として、注力すべきポイントを整理することには成功しています。

しかし貼り出せる施策アイデアの性質が偏りやすく、また実装まで落とし込めないままになりがちでほとんどワークしませんでした。施策が回らないのでは高速開発に利用出来ません。

そこで先日導入したのがこちら。

アイデアの幅は各メンバーに任せることにし、ある程度自由に考えられるように戻っています。

そして縦軸と横軸で、貢献度の見込みと工数を定量的にマッピングするようになりました。

一見すると初期のボードに戻っただけのように見えるかもしれませんが、定量的な数値を意識することで改善されている部分があります。

初期のボードでは具体的な数値が無かったために、「利用されそう」「効果がありそう」という感覚で貼ってしまう事が多々ありました。ここに具体的な数値を示すことで「ゴールに対しては何%貢献できるだろう?」と意識してから貼りだすようになっています。

施策のカテゴリが制限されていないため様々な視点から施策を考えられ、かつ数値へ直接貢献しやすいものが上位になるレイアウトとして期待しています。

失敗して当たり前、悩む時間を減らして手を動かそう

途中で述べたとおり、グロースハックは成功率がとんでもなく低いです。10% 〜 20%も成功すれば大成功と言われています。

もしも実装の過程で「もしかしたら仮説は間違っているかも?」と感じたら、一度手を休めて方向転換する事も多々あります。その方が少ないコストでより良い成果を出せるケースだってあるからです。

私たちが毎週1回リリースというサイクルを設定したのには「失敗を早く見つけることで、次に繋げやすくする」という目的があります。

それを実現するためのチーム開発は 施策ボードを使って最適化されています。そしてそのボード自体も失敗を繰り返し、徐々に改善されています。

まとめ

高速リリースを可能にするチーム運営とツールをご紹介しました。

私たちが開発フローの見直しで行ってきたことを、簡単におさらいします。

- 手戻りを減らし効果を最大化するため、タスク管理や施策共有を改善しよう

- スピードを上げるなら、厳格さよりも自由度が高く状況把握しやすいツールを使おう

- 「見える化」「高い自由度」ならホワイトボードが最適。デジタルにこだわるな

- 面倒だからこそ、優先度やステータスはその場で管理し混乱を避けよう

- もし課題を見つけたら、まずは試して早めに学びを得よう

いかがでしたか? もちろん、この運営やフローが全てのチームで最適であるとは限りません。

例えば厳格で確実なリリースをするためには、さらに工夫をして横軸が進捗状況となっていた方が良いかもしれませんね。あくまで一例であり、最適なカンバンと運営方法はチームやゴールによって異なるでしょう。

今のチーム運営では見通しが悪い、もっと高速に開発が出来るはず、など考えている方。まずはフローを見なおしてみてください! その時、この記事が少しでも参考になれば幸いです。

さいごに

Wantedlyには 「Wantedly Way」 と呼ばれるプロダクト開発の行動指針があります。

"Code Wins Arguments" -- 考え議論する時間より、実際に動くものを

"User First" -- ユーザの本質的な欲求に答え、体験を損なうようなことはしない

"Simple is Not Easy" -- 足すよりも引いて、その工数で最も有効な方法は無いか?

今回ご紹介した開発フローはWantedly Wayを色濃く反映しています。そしてこのWantedly Wayがあるからこそ、私たちは自信を持ってグロースに取り組むことができています。

もしあなたがグロースハックの現場に居るのなら、是非この指針を心がけてください。きっと上手くいくはずです。

グロースハックや私たちのチーム開発に興味を持って頂けましたか? チームの運用だけでなく実際の開発がどのように行われているか等は 先日販売された Wantedly Tech Book にて詳しく解説されています。電子版も販売されています。

もっと詳しく知りたい、Androidチームの具体的な試みについて話を聞いてみたい! と思った方、気軽にWantedlyへ遊びに来てください。もちろんTech Bookもありますよ。

仕事の後、大学が休みの日など、ぜひ意見交換しましょう。