スタディストのプロダクト開発組織で、機能開発における価値検証やユーザー体験の検証のための「UX検証プロセス」を型化する取り組みを始めてみました。
プロダクトの価値を検証するための選択肢は、社内リリース、ベータ版公開など、いくつものパターンがあると思います。
ただ、ここで一つ問題提起したいのが「特に意図なく、とりあえず社内リリース・ベータ版公開を選んでいませんか？」ということです。
社内のフィードバックをもらえれば本当に良いものになるのでしょうか？または、ベータ版として限定公開すれば、本当に今よりも価値検証が進むのでしょうか？顧客に正しく価値を届けるための近道なのでしょうか？
かく言うスタディストでも、社内リリースや、ベータ版公開のような、お客さまに直接価値が届きづらい形のリリースがよく見られるようになっていました。顧客の声を聞きながら開発を行う文化が根づいてきたことの現れというポジティブな評価もできますが、より早く顧客に価値を届けるためには改善すべき点があると思います。
今回のUX検証プロセスの型化は、「どういうタイミングでどのリリース手法を取ると良いか」という判断の再現性をつくり、お客さま全体に速く価値が届けられるようにすることを狙った仕組みです。
ここからはより具体的に、どのような背景で仕組みがつくられ、どう運用されているのかをまとめてみます。
スタディストでは、開発組織全体で「お客さまに速く価値を届ける」ことへのこだわりを持っています。例えば「機能開発が始まってから3ヶ月以内に価値になるかどうかを判断できるようにする」といった、素早くお客さまに価値を届けられる仕組みがこれまでも多く運用されてきていました。
この「速くリリースすること」と「確実に価値にすること」の両方を、対立構造にせず、両取りしていくのが開発組織として目指す像だと考えています。
一方で、開発組織内で「確実に価値にする」意識が高まるにつれて、リリース速度が意図せず遅くなってしまっているのでは？と感じるケースが出てきました。
例えば、プロダクト開発を経て機能リリースの直前になった段階で、CSメンバーから「本当にこのままお客さまに公開して良いの？」というフィードバックが投げかけられたりすることは、よくあると思います。
このような場面でも、開発メンバーが根拠とともに「大丈夫」と言い切れれば良いのですが、その根拠をチームや状況に合わせて用意しきれていないことに課題がありました。結果としては「たしかにまだ分からないから、一応社内リリースで様子を見よう。」といった “逃げ” のリリースに落ち着いてしまうようなケースも発生していました。
社内リリースが必ずしも悪いとは思いません。ただ、根本的には社内にリリースをしてもお客さまに価値は届かないので、本来は「早くお客さまに公開しよう」と考えるべきです。
このような、いわば "検証を盾にした逃げのリリース" が起こってしまう要因は、プロダクトの状況に合わせて適切に検証を進める方法が分かっていないことにあると私たちは考えました。
「どのようにプロダクトを検証し、リリースすると良いか？」という判断は各開発プロジェクトに委ねられており、この理解度は人それぞれ経験による差があったため、ベストな検証フローを取れていなかったのです。
なので、途中でプロジェクト外のメンバーから「なんでその検証方法を取るのか」と聞かれても、明確に答えを返すことができず、結果として「社内リリース」や「ベータ版公開」という特に意図がないまま価値提供を遅くしてしまう行動が起こっているのだと捉えました。
今回はその「検証方法の理解度が人によって異なる」という点に課題を置いて、開発組織全体のプロダクトの検証フローを、型化してみることにしました。
このような背景のもと、先日スタディストの開発組織向けに「UX検証プロセス」を型としてまとめた資料を公開、運用を開始しました。
前述の通り、資料の目的は「どういうタイミングでどのリリース手法を取ると良いか」という判断の再現性をつくり、お客さま全体に速く価値が届けられるようにすることです。
資料は、過去のスタディストの開発で学習できたパターンをもとに、以下のような情報構成で設計されています。
資料ではまず最初に、すべての検証パターンを網羅的にまとめ、それらがどのフェーズ、目的で利用すべきものかを整理しています。
ここでは「知らないことで選択肢を選べなくなる」ということが極力起こらないよう、具体度を高めるように記述しています。
例えば、「クローズドベータ版」の中にも、「検証」と「先行リリース」の2種類があること。それぞれ目的や、実施する条件、注意事項は異なることが分かるように整理しています。
合わせて、それぞれの検証パターンには、スタディストの中で有効だった事例も載せるようにしています。「あの事例みたいに進めよう」と共通言語にもなりますし、この検証手法を取ることでうまく進むことを示す根拠にすることもできます。
一つひとつの検証方法には、実施条件を明記しました。人によって判断がブレないように「どのようなことを明らかにしたいから、今はこの手法で検証する」という意思決定が行いやすいように心がけています。
さらに、過去の成功事例を参考にしながら、それぞれの検証方法ごとに、推奨スケジュールをまとめておきました。
この検証方法を使うならば、どのタイミングでどんなアクションが必要になるのか、が見通せることで、プロジェクトの進め方もよりクリアになっていくはずです。
今回、この資料を本事例の公開に合わせてSpeaker Deckに公開しました。
全部で8つの検証パターンの、目的や実施条件、推奨スケジュールがまとめられた、プロダクトの価値検証を進めるにあたっての拠り所のような資料となっています。
スタディストだけではなく、各社に適応できる考え方になっていると思うので、ぜひ参考にして活用していただければと思っています。
一部、公開用に実際の資料と変更している点があります。運用の工夫なども含め、詳しく聞きたい方はぜひご連絡ください。
スタディストでは、この資料を「プロジェクト進行時にプロジェクトメンバーでどの検証方法を取るべきか？」を議論するタイミングで活用しています。
すでに、この資料が有効活用された例がいくつか生まれています。
例えば、この資料をもとに、闇雲な社内リリースをストップすることができています。
本資料を作成したプロダクトデザイナーの武波も、これまでは「とりあえず社内リリース」をすることで、多くの人に使ってもらえるし、何か不備が見つかればラッキーなので、それで良いのではないかと思っていました。
しかし、実は社内でリリースすることにも、一定のコストがかかります。機能の公開範囲を指定するための設定や社内への説明資料の作成、正式版リリース時のデータ移行や後処理など、やるべきことがたくさん存在するためです。
今回定義した「UX検証プロセス」では、「社内リリースは、実データでの操作による検証が必要な場合にのみ実施」することとしています。
Figmaや検証環境でのユーザビリティテストで十分な場合は、社内リリース検証は不要であることを定義できたことで、検証済みの価値を無駄にコストをかけて追加で検証するようなことを防げるようになりました。
今回の資料があることで、プロジェクトを進めるメンバーで認識を揃え、目的にあった検証手法を選べるようになっています。
例えばプロダクトデザイナー原口のチームでは、本資料を見ながらプロジェクトメンバーで議論して、とある機能の公開方法を選ぶことができました。
プロジェクトとしては、すでに顧客価値や運用実現性についてはある程度明快になっていたのですが、正式に全顧客にリリースできるまではあと少し時間がかかりそうな状態となっていました。
一見、クローズドベータ版公開のメリットが無いように思いますが、今回の機能は「特定のお客さまから強い要望をいただいて始まったプロジェクト」だったため、クローズドベータ版の中でも「先行リリース」という形で先んじて公開しておく方が良いと判断しました。
もし一部のユーザーに強い要望があるならば、品質的にまだ磨き込みが必要な段階でも、その状況も伝えた上で一部ユーザーのみに提供することでビジネス的にメリットがある場合があります。
おそらくこれまで通りの進め方だと、、検証目的でベータ版をリリースし、顧客に使っていただきつつ、たくさんの時間的リソースを割いているにもかかわらずユーザビリティテストで得られるような検証しか出来ず、無駄の多いプロセスになっていたように思います。それは結果として顧客への価値提供が遅くなることに繋がります。
もっと言うと、そもそも原口自身は、ビジネス側やお客さまの心理として「機能や体験が不十分な状態でも、先行して使えることにビジネス価値を感じる」という視点があることに気づき、資料を活用したことで「検証の目的以外に、ベータ版公開」という選択肢の有効性を学ぶこともできました。
この “UX検証プロセス” の型化によって、すでにいくつもの場面でお客さまに速く価値を届ける意思決定が行えるようになっています。
何より、これをつくったプロダクトデザイナーの私たち自身が価値を感じているのが正直なところです。
そもそも「社内リリースを選ばない方が良い時がある」ということも、改めて考えると当たり前なのですが、今回気付くことができました。
また、これまでは社内で何度もプロジェクトを進めてきたリサーチ&デザイン室 室長の磯野さんにレビューをもらうことで検証方法を整理していましたが、この資料を使うことで開発プロジェクト内だけで適切な検証方法を議論できるようになっているのも組織の進歩だと思います。
繰り返しになりますが、今回の資料はSpeaker Deckに公開しているので、ぜひ自社のワークフローに合わせて編集・活用していただければと思います。
スタディストのリサーチ＆デザイン室では、これまでにも全職種がお客さまに価値を速く確実に届けられるような仕組みをつくってきました。
これは、私たちの言葉でいうと「デザインブースト」というデザイン成熟レベルを引き上げる活動です。
成熟したプロダクトデザイナーが入った案件だけ価値検証がうまく進むのではなく、どのような場合にも価値検証が進みやすくなるような「仕組みのデザイン」こそが、今スタディストのデザイン組織が取り組む注力領域となっています。
他にも、セールスやCSの活動支援、全社をまたぐ顧客理解の仕組みづくり、新規事業の推進など、いくつもの場面でデザインの力が活用できるように、属人性を超えた仕組みづくりに取り組んでいます。
リサーチ＆デザイン室からスタディストとしての「顧客目線」という競争優位をつくれるように、今後も目線を上げて活動していきます。