MVPを作るときは、更地に家を建てていました。誰も住んでいないので、基礎を新しく打ち直しても、構造をまるごと変えても問題はありませんでした。二周目からは状況が違います。育てるのでも作り直すのでも、今手を入れているコードの上にはすでに人が住んでいます。更地に家を建てる作業と、人が住む家を直す作業とでは、やり方自体が異なります。
先の第4部で扱った並行運用は作り直し特有の状況でしたが、これから扱う五つは、育てると作り直すを問わず二周目から同じように直面する課題です。
ライブ変更の統制
稼働中のシステムの上でコードを変える作業は、空の画面にコードを載せる作業とはリスクの大きさが違います。デプロイ一つが、今この瞬間に決済を進めているユーザーや、文章を書いている最中のユーザーをそのまま巻き込みます。だから二周目からは、デプロイそのものを一つの作業として設計する必要があります。
- 戻せるデプロイ: 全ユーザーに一度に出しません。一部のユーザーに先に開き、問題が見えたらその場で切り戻し、問題がなければ範囲を段階的に広げます。
- 戻す基準を事前に決めておく: エラー率がどれだけを超えて何分続けば戻すのか、応答時間がどの線まで遅くなれば戻すのかを、デプロイ前に数字で決めておきます。デプロイの最中に基準を新しく決めると判断が遅れます。
- デプロイ時点の選択: ユーザーが最も少ない時間帯を選び、問題が起きたときすぐ対応する人がその時間帯に実際に控えているかまで確認します。深夜にデプロイしても戻す人が眠っていれば、時間帯を選んだ意味がありません。
決済サービスでこうした状況は珍しくありません。新しいデプロイを全ユーザーに一度に開いたところ、特定のカード会社との連携だけでエラーが出ます。戻す基準を事前に決めていなかったため、チームはログを見守りながらも判断を先延ばしにし、その間に決済の失敗が積み上がります。基準をあらかじめ数字で決めておけば、五分で切り戻して終わっていた状況です。
この三つを備えないまま二周目に入ると、デプロイは毎回賭けになります。運がよければ通り過ぎ、運が悪ければ数時間サービスが止まったまま原因を探すことになります。
フィードバックのスクリーニング
育てるのでも作り直すのでも、サービスの運用を始めると要望が途切れることなく入ってきます。問題は要望の量ではなく、そのうち何が本当の課題かを見分ける基準がないことです。
まず要望を一か所に集めます。誰が要望したか、いつ要望したか、同じ要望が何回繰り返されたかが一つの画面で見える必要があります。メールとメッセンジャー、通話メモに散らばっていると、同じ要望が三回入ってきたことにすら気づけません。
集めた後はふるいにかける問いを立てます。この要望に応えると、弱いシグナルのうちどれが動くか。新しく入ったユーザーを中核行動まで連れていく到達なのか、離れたユーザーを呼び戻す反復なのか、決済につながる支払いなのか、答えが出ない要望は優先順位リストの一番下に下げます。
この問いを基準にしないと、声の大きい顧客や一番最近に入った要望が自然と前の順位を占めます。実際にサービスの役に立つ要望と、ただ先に声を上げた要望が混ざり合うのはまさにこの地点です。
二周目の工数見積もり
二周目の予算と期間は、MVPの見積もりをそのまま伸ばした値では測れません。
既存のものとの互換性、データ移行、運用の並行が工数の中に新たに入ります。MVPのときは何もない場所に最初から組みましたが、今回は今動いている画面とデータに触れずに新しいコードを載せる必要があります。同じ機能を一つ作るにしても、既存のロジックと衝突しないか確認する時間が別に付きます。移行対象のデータ量が多いほど、既存ユーザーが以前の方式で使っていた機能をそのまま維持しなければならない制約が重なるほど、この時間は比例して増えます。
MVPの見積もりを基準に今回の工数を測ると食い違う理由がここにあります。MVPの見積もりは何もない場所で組まれた費用で、今回の見積もりにはすでに動いているものを守る費用が一緒に入ります。同じ大きさの機能でも、後者の方が時間がかかる場合が珍しくありません。
改善を裏づける比較基準
新機能を入れたら「よくなった」という言葉をデータで裏づける必要があります。ここでよく見落とされるのが比較の基準です。
変える前に基準値を先に固定します。新機能を配布した後は、以前の状態を測り直す方法がありません。今の転換率がいくらか、今の離脱地点がどこかをデプロイの直前に記録しておかないと、後で「確実によくなった気がする」という感覚だけが残り、根拠は消えます。
指標一つに機能一つを原則とします。複数の機能を一サイクルに詰め込んで指標が一つだけ上がった場合、その指標を動かしたのがどの機能だったのか見分ける方法がありません。次のサイクルにも同じ機能を優先順位に上げるか判断するには、何が効果を出したのかを先に知る必要があります。
オンライン教育サービスでこうしたことがよく起きます。一サイクルで決済画面の改編と通知機能の追加を一緒に配布した後、転換率が上がったという結果だけを報告します。どちらが効果だったのかは誰も答えられず、次のサイクルにも二つを一度に入れて判断する習慣がそのまま繰り返されます。
障害対応の最低基準
二周目に入る前に、規模にかかわらず三つは備えて始めます。
| 最低基準 | 備えていないと起きること |
|---|---|
| エラー検知: ユーザーより先に気づく | 顧客からの問い合わせやクレームで障害を先に知ることになり、その時点ですでに数時間が経っています。 |
| 切り戻し体制: すぐに戻せる | デプロイ後に問題が起きても、原因を突き止めて修正するまでサービスが停止したまま放置されます。 |
| 担当者の指定: 誰が受けるか決まっている | 障害の通知が鳴っても誰かが見るだろうと見過ごし、貴重な初動対応の時間を失います。 |
この三つを超える運用体制全体、つまりバックアップの周期やセキュリティパッチのリズム、指標を確認する曜日については、リリースの翌日から始まること：サービス運用チェックリスト ですでに整理しています。ここでは二周目を始める前に必ず備えるべき最低限だけを取り上げました。
五つの課題を一つずつ越えると、残る問いはこの五つが全体の絵のどこに位置するかです。その全体像は、一枚の決定地図としてまとめる最終編、第6部で扱います。
インテグラビットが要望とデプロイ、指標を一画面で管理する理由
要望のリストとデプロイの記録、指標がそれぞれ別のツールに散らばっていると、「この機能を入れた後に指標がどうなったか」を振り返ること自体が難しくなります。デプロイの時点を確認するにはgitのログを掘り返す必要があり、その要望がそもそもどこから入ってきたのかはメッセンジャーの会話を探し直す必要がある、といった具合です。
インテグラビットは、要望の受付とデプロイの記録、指標の確認が同じ画面でつながるように管理します。ただし、どの要望を優先順位に上げるか、次のサイクルに何を入れるかは、この画面が代わりに決めてくれるわけではありません。その判断は依頼する組織のものであり続けます。
前の記事: 作り直すと決めたら：何を引き継ぎ、何を捨てるのか
次の記事: MVPの次を決める地図：この判断は一度で終わらない
二周目を控えて、デプロイとフィードバック、指標管理の体制が整っているか判断が付かない場合は、30分の無料相談で現状を一緒に確認できます。