作り直すと決めた後、最初に開かれる会議ではほぼ同じ質問が出ます。「では、最初から企画し直すのでしょうか」。この質問には不安が混じっています。これまで積み上げてきたものを全部消して、白紙の状態からやり直さなければならないという不安です。
先の第3部で扱った停止シグナルに行き当たり、育てる路線を切り上げるケースが、作り直しに入る最も多い入り口です。
幸い、作り直しは白紙からやり直す作業ではありません。これまで積み上げたものの多くは、そのまま次のバージョンに引き継がれます。何を引き継ぎ、何を捨ててよいのか、その基準から立てる必要があります。
引き継ぐものと捨てるもの
「作り直し」と聞くと、多くの場合コードのリポジトリを消して最初から書き直す場面を思い浮かべます。しかし実際に捨ててよい対象は、コードと画面、そして両者を結ぶ構造だけです。残りは次のバージョンにもそのまま引き継げます。
- ユーザー: アカウントとこれまで積み重ねた関係です。ログイン情報、所属、権限など、誰がこのサービスを使っているかを規定する値です。
- データ: 行動記録と取引履歴です。ユーザーが残した過去は、構造が変わっても有効な資産であり続けます。
- 学んだこと: 検証済みの流れ、外した機能のリスト、要望のログです。どの順序で案内すれば離脱が少ないか、どの機能を試して取り下げたか、何を繰り返し求められたかの記録です。
この中で最も見落としやすいのが学んだこと、その中でも検証済みの流れです。検証されたのは画面ではなく順序です。画面を新しく描き直しても、その順序だけは守る必要があります。
定期購読サービスでこうした状況は珍しくありません。決済直前の最終確認画面一つが離脱を減らしていたことがデータですでに確認されていたのに、作り直しの過程でデザインチームがその画面をまるごと外します。新しい画面はすっきりしましたが、確認の段階が消えたことで決済キャンセルの問い合わせが再び増えます。画面は変わってよくても、その画面が担っていた順序は次のバージョンでも守る必要があります。
よくある失敗二つ
作り直しの過程で繰り返される失敗は、大きく二つです。
一つ目は、検証済みの部分まで変えてしまう失敗です。作り直しを始めると、チーム全体が久しぶりに白紙の状態で仕事をする機会を得ます。この機会をリブランディングのきっかけにしたい誘惑が強くなります。ロゴを変え、サービス名を整える程度を超えて、すでに反応がよかった流れにまでこの機会に手を加えます。問題は、何が検証済みで何がそうでないかを区別しないまま手を加えると、新しいバージョンの成果が悪化したときに原因を追えなくなることです。構造を変えたせいなのか、検証済みの流れに触れたせいなのか、切り分ける基準がなくなります。
二つ目は、MVPのときに外した機能を今回すべて入れてしまう失敗です。最初にMVPを作ったときは、決められた予算と期間に合わせて機能を削りました。作り直しは、そのリストを再び取り出して一つずつ復活させる口実のように見えます。しかし2.0を完成品として扱った瞬間、MVPのときに抱えた問題がそのまま繰り返されます。外していた機能のうち今回復活させる項目は、作り直しのきっかけとなった三つの問い、つまり中核データとユーザー種別、中核フローのうち最も大きくずれていた点に関わる機能から選びます。残りは次のサイクルに回してかまいません。二番目のバージョンも範囲を決める判断であることに変わりはありません。
並行運用
作り直した新バージョンを出したからといって、既存バージョンをその場ですぐに下げるわけではありません。両方をしばらく一緒に動かす期間が必要です。
- 既存バージョンをいつまで残すか: 新バージョンが既存バージョンの中核フローを全て置き換えるまでです。一つでも新バージョンでまだ検証されていない流れがあれば、その流れを使うユーザーには既存バージョンを開いたままにする必要があります。
- 新バージョンを誰から乗せるか: 新規ユーザーから新バージョンへ案内します。既存の流れへの期待がない人たちなので摩擦が少なくなります。安定性が確認できたら既存ユーザーを招待の形で移し、最後に全体を切り替えます。
- データ移行: 一度に移しません。正本をどちらか一方に決め、流れを一方向に保ちます。既存バージョンと新バージョンが同じデータを両方から書き換え始めると、どちらが最新か誰にも判断できない状態になります。
移行のコミュニケーション
並行運用の期間中、既存ユーザーに何をいつ伝えるかも別に整理しておく必要があります。
最初に伝えるべきは変わるものの一覧ではなく、変わらないものの一覧です。ログイン情報がそのまま維持されるか、これまで積み上がったデータが残るか、料金プランが変わらないかから案内します。ユーザーが作り直しの知らせを聞いたとき、最初に心配するのがこの点だからです。何が変わるかはその次です。
伝えるタイミングにも順序があります。配布の前に前もって知らせ、切り替え対象になったユーザーには個別に改めて案内し、切り替えが終わった後は問題が起きたときに戻る経路があることまで伝えます。告知を一度で終えると、並行運用の期間中ずっと同じ問い合わせが繰り返し入ってきます。
期間と予算
作り直しにかかる期間と予算は、MVPのときと同じものさしでは測れません。
短くなることもあります。MVP段階で検証すべきだった仮説はすでに検証が済んでいるため、何を作るかを悩む時間が大きく減ります。
逆に、移行と並行運用によって伸びる区間もあります。二、三サイクルほどで並行運用を終えるチームが多いものの、移行対象のデータ量と流れの複雑さによってこの期間は大きく変わります。
見積もりを見るときに確認すべき点は、移行と並行が開発項目のどこかにまとめて含まれているか、それとも別項目として切り分けられているかです。まとめて含まれていると、その作業に実際どれだけの時間と費用がかかったかを後から確認するのが難しくなります。
育てる道でも作り直す道でも、製品を世に出して運用する二周目からは、これまでとはまったく違う種類の課題にぶつかります。第5部では、稼働状態での配布統制やフィードバックの選別、予算の再見積もりなど、二周目の共通課題を扱います。
インテグラビットが作り直しの見積もりで移行と並行を別立てにする理由
インテグラビットは作り直しの見積もりで、データ移行と並行運用を開発項目とは別立ての項目として算定します。どちらも画面に表れる新機能ではないため、まとめて入れると見積もり段階では見えず、プロジェクトの中盤になって「こんな工数がかかるとは思わなかった」という話に戻ってきます。
移行対象のデータ規模、並行運用を続ける想定期間、既存バージョンから新バージョンへユーザーを移す切り替え方式まで見積もり段階で先に押さえておけば、実際の進行中に項目が増えても、最初の予算とどれだけ差があるかをすぐに確認できます。この情報を見て並行期間をどれだけ長く取るか、どこまで今回の作り直しに含めるかは、依頼する組織が判断することです。
前の記事: 育てると決めたら：どこまで伸ばし、いつ止めるのか
次の記事: どちらを選んでも直面すること：二周目の共通課題
作り直しを控えて、何を引き継ぎ何を捨てるべきか判断が付かない場合は、30分の無料相談で現状を一緒に確認できます。