全Webサービスプロデューサーに告ぐ! 新機能はこうやってリリースしろ!

今回はWebサービスを成長させるには必須のアクション

新機能のリリースについて

実際新機能はどのような手順を踏んでリリースされているのでしょうか。

それを考えて行きたいと思います。

※具体例には一貫性を持たせておりませんのでややこしい部分があるかもしれません。

目標設定

ここで行うのはKPIツリーの確認と現状の数値です。これができないのであればそもそも新機能はリリースすべきではないでしょう。何のためにその機能をリリースするのか。本当にその機能は必要か?その機能を追加したら何がどれだけ伸びるのか。そしてどれだけ伸びたら良いのか。それをはっきりさせてから新機能のリリースに入りましょう。
そしてその目標設定方法の手順は次のようになります。

KPIツリー

KPIツリーを利用します。KPIツリーの説明は今更不要かもしれません。
ようは売上がトップにありそれから枝のように売上を構成する要素がつながります。
そこで最も重要な指標をKPIとし、それを構成する木構造の図がKPIツリーといいます。
一般的には
売上
= ユーザー数 x ARPU
などのようになることでしょう。ただし、はじめから売上を伸ばそうとしても意味がありませんし無理です。なので伸ばせるとこから伸ばしていく。それがKPIツリーの本質です。
さらにKPIはフェーズによっても違います。現状のKPIを伸ばしたい。そのために新機能をリリースする。
まずはこういう思考を持ちましょう。

現状の数値

それではそのKPIを伸ばすことに決めました。しかし、現状その数値はどれくらいなのでしょうか?
それを分析しなければ、
「新機能をリリースしたぞ! 伸びたぞ! やった!」
とりあえず、伸びたがどの程度伸びたかが完全に抜けてしまいます。これにより、同様にKPIを伸ばそうと思っても同じ手法が使えません。なぜならそれにかけた時間と効果が見合っているかどうかわからないからです。
「3人月使ってやっとリリースした機能のおかげでCVRが1%伸びたぞ! 1%伸びたことによって今後売上が + 10,000円になるぞ!」
これじゃダメですよね。
そのリリースする機能にかかるコストとそれにより得られる効果を天秤にかけ、しっかりと時間を投資しましょう。そのために
1. 現状ある数値の割合・絶対値を出す
2. 伸ばしたい数値の1つ上のツリーの葉の数値を出す
3. 同階層にある葉の数値を固定した時、伸ばしたい数値がどう変化すれば、1つ上の葉の数値が変わるかを考える
4. 1つ上の葉の基準からどれくらいかかるかと比較し目標値を出す
このような流れで目標値を算出しましょう。

効果測定方法の検討

これは現状の数値を出した方法と同じで良いでしょう。
大抵はGoogle Analytics、もしくはデータベースの値かどちらかでしょう。
こういう本がためになりますね。

ウェブ分析レポーティング講座

というわけで目標設定編はこのような形です。

設計

ではその新機能の設計をします。
設計をする目的は
1. 実装速度を上げるため
2. 後にドキュメントとして残すため
3. 途中でブレないようにするため
...などなどありますが、概ね上記3つでしょう。
以外と3番目が重要だったりするんですよね。時間をかけるリリースほどそうなりがちです。
そこで設計の手順についてもお話します。
これは正直私個人の話なのでそれぞれにあったやり方を探しましょう。

ユースケース図の作成

誰がどうしたかを表す図です。
今回伸ばしたい数値があったとして、それは誰が何をしたらその数値が伸びるのか。
その「誰が」と「何を」を視覚化した図がユースケース図です。
以下はランキング機能の例です。

シーケンス図の作成

ユースケースで示した行動に関わる処理を時系列で表現した図となります。
どちらかというと実装よりになってきました。
引き続きランキング機能の例を示します。

ワイヤーフレームの作成

これはデザイナーに渡す前に行う設計です。
基本的にはレイアウトのみを示すデザインのラフ画と思っていただけるとイメージしやすいでしょう。
ワイヤーフレームでググればいくらでも出てくるので具体例はいらないですね。

場合によってはER図の作成

もちろん新機能の中はデータベースを使う可能性もあります。その際にはER図を書くことをおすすめします。これも実装寄りの設計ですが、何と何が関連しているかが可視化されるのに加え、データベースは巨大化していくため、少しづつドキュメントを残すという意味でも作成したほうがよりでしょう。

個人的にする必要はないと思っておりますが、クラス図の作成とかもありますね。

設計は一冊くらいUMLに関する本を読んでおくとよいでしょう。

ゼロからわかる UML超入門

実装

設計が終わりいよいよ実装に入ります。
皆さんの大好きなプログラミングのフェーズです。

テストコードの実装

ガリガリプログラミングしていく! と、その前にテストコードを書くべきです。
まぁいろんなところで言及されているので今更説明は不要ですが、ユースケースとも紐づくのでエンジニア以外も見てなんとなく意味を理解できるようになりましょう。
あとテストコードを書くことで後にリファクタリングができるようになります。

テスト駆動開発入門

ちょっと難しいですがこの本を。

新機能の実装

さくさくっと作っていきましょう。わからないところがあれば5分調べてそれでもわからなければ聞く!

リリース

というわけで完成しました!
そこでリリースです。このリリースの手順を間違えると
「うわぁぁ真白い画面が本番にぃぃ！」
となってしまうので慎重に行いましょう。

ローカル環境でのリリース

これはまず作業ブランチそのものをリポジトリにpushします。
そして作業者と確認者(プロデューサーやディレクター)全員がpullします。
そこで画面上でひと通り確認します。
その際、データベースを扱うのであればテスト用のシードデータを渡すとスムーズでしょう。

development環境でのリリース

次に本番環境とはデータベースが違うdevelopment環境にリリースします。
developmentブランチにマージし、デプロイするのが一般的でしょう。
ローカルでマージし、pushした瞬間jenkinsのジョブが走り、そのままデプロイさせるのが一般的ですかね。
もしくは作業ブランチをdevelopmentブランチにpull requestした段階でjenkinsのジョブを走らせる手法もありかと。
それで dev.~.com とでも設定したドメインにアクセスして確認します。
コードレビューはこの時の段階で行うと良いかもしれませんね。

staging環境でのリリース

development環境でもオッケーならば、次はstaging環境にリリースします。
development環境と違う点はデータベースは本番環境と同じという点です。
本番と全く同じ環境でチェックができます。
同じく作業ブランチをマージするか、もしくはdevelopmentブランチをマージさせてもよいかもしれません。

本番環境へのリリース

staging環境でもオッケーならばいよいよ本番にリリースします。

jenkinsやgitの本などが良いかと

入門Jenkins―実践「継続的インテグレーション」

この本はかなり実践的でよかったなと。

開発ツール徹底攻略 (WEB+DB PRESS plus)

トータルで学ぶならこちら!

番外 : インフラの強化

仮にこのリリースがユーザー数を増やすというようなものであれば、確実にインフラの強化もリリースの工程に入ってくるでしょう。
インフラの強化は大抵、瞬間最大風速に耐えるためのものです。
仮にサーバー1台の秒間処理スレッドの数が最大1,000とした場合、それ以上の同時アクセスがあれば落ちてしまいます。
最初に設定した目標が
サーバー台数 x 1台の秒間最大処理数 x 80%
を上回るようならばもう1台追加するべきでしょう。80%をかけているのは予想以上に多かった場合の対処です。
もちろん他にもメモリやCPUのリソースやデータベースI/Oのことも考慮しなければなりませんね。
前回の記事でも紹介しましたが

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)

こちらが良いでしょう。

効果測定

というわけでリリースが完了しユーザーの反応を見ていきます。

監視・監視&監視

ここでは

• CPU, メモリ等リソースの監視
• 同時アクセス数の監視
• ログの監視

などがメインでしょう。

各種結果の確認

こちらはリリース後しばらく反応を見た後の話ですね。
実際にどのように数値が推移していったのかなど。
先に検討した測定方法で算出します。
無事目標値に達していたでしょうか?

有意差検定

ここが以外と忘れがちなのですが、
「その結果、本当にその新機能のおかげ?」
というのを調べます。
調べ方は至って簡単で、仮に偶然だとした場合それが起きる確率は5%以下だった時に有意性がある。つまり新機能は効果的だった!ということを実証します。
偶然、その数値が伸びているという場合ももちろん考えられますよね。
ただ、本当に偶然だとした場合、5%以下の確率で起きる場合はそれはもう偶然とはいえないでしょう。必然的にその機能が伸ばしたといえます。
この時設定している5%は有意水準と呼ばれ、これを1%にするとよりシビアに新機能の効果測定ができます。
普段からエラーバーをとったり、変動の分散を取っていかないとこれを分析することができないので注意しましょう。
この記事がとても参考になります。何度読んでも良い記事です。
R - ABテストのための有意性検定 - Qiita [キータ]

振り返りと反省

ここまでで一連の流れは終了です。
終了してどうだったか反省回をしてよかったところも悪かったところもひっくるめて次に生かしましょう。

スケジュールはどうだったか

これは最初に引いたスケジュールと比較しどうだったか。
もちろん開発って100%スムーズに、想定したようにいくことは100%ありえません。
では遅らせた原因はどこだったのか、今後遅らせないようにするにはどうするか。
一人ひとりの能力はどうか。
これを考えて管理することにより、次回はスケジュールの遅れを減らせることができるでしょう。

効果はどうだったか

有意差検定が終わって結果どうだったかを話し合いましょう。
仮に新機能が連続的なものであれば、微分によって最適解が求まることでしょう。
また、予測もしやすいでしょう。
例としては仮にニュース系アプリであれば、
見出しの文字数やファーストビューでの閲覧数などが連続的なものでしょうか。
次回のリリース時にはそれを材料に目標値を設定することができ、仮説の精度を上げることができますね。

仮設は正しかったか

というわけで新機能がトータルで成果を出していたかどうかを検討しましょう。
シビアに定量的に検討することが重要です。

まとめ

というようにここまでしっかりやるのが理想ですね。
ただ現実問題うまくはいかないものです。
一つひとつできていないところをできるようにしていく。
これこそがGrowth hackへの近道ではないでしょうか。

ちなみにこれを1週間間隔で回していくことができれば最高ですね。
スタートアップならば3日とか。
あんまり短すぎても効果測定はできないでしょうが。。。

というわけで新機能を無闇矢鱈にリリースすることはやめましょう!