知るべきことは何だったのか？

PDCAは1950年代以降、日本の製造業の品質管理で磨かれました。対象とする工程では、仕様や望ましい品質を比較的明確に定義できる。期限までに、不良品を出さずに作る。計測可能な基準へ向けて改善を積み重ねるほど、成果が出ました。

一方、新規事業やデジタルサービスでは、正解を先に定義できません。競合はグローバルに増え、AppleやGoogleのような異業種がある日突然ライバルになる。スタートアップはクラウドファンディングで、企画から数か月で発売までこぎつける。発売の前も後も、ネットの反響ひとつで売れたり、売れなくなったりする。何が正解かは、世に問うまで分からない。計画を正確に実行する能力より先に、「そもそも何を作るべきか」が揺らぐ仕事です。

BML（Build–Measure–Learn）は、この不確実性のためのサイクルです。仮説を小さく試し、観測し、次の判断に使える学びを得る。計画した仕事を改善するPDCAに対し、BMLが問うのは「そもそも、この前提は正しいのか」です。

CX版BMLサイクル：顧客体験のモデルを起点に顧客体験を提供し（BUILD）、顧客体験を計測して顧客データを集め（MEASURE）、顧客を理解してモデルを更新する（LEARN）。中心のカスタマーアナリティクスが三つをつなぐ

この記事では、BMLを製品中心のサイクルから、顧客理解と体験の更新を中心にしたサイクルへ組み替えます。

PDCAが古いのではない

PDCAとBMLは、新旧でも優劣でもありません。扱う不確実性が違います。

PDCA BML
向いている状況 目的や業務がある程度分かっている 顧客の課題や価値がまだ分からない
中心となる問い 定めた目的へどう近づくか どの前提を学び直すべきか
進歩の単位 品質、効率、達成率 検証された学び
データの役割 実績と改善度を確認する 仮説を支持・棄却し、次を決める
代表的な判断 継続して改善する 続ける、変える、やめる

決まった商品を安定して届ける。既知の不具合を減らす。定型業務の時間を短くする。こうした仕事にはPDCAが役立ちます。

一方で、新しいサービスを考える、顧客が選ばない理由を探る、まだ存在しない体験を形にする、といった仕事では、最初の計画そのものが仮説です。計画どおりに作れたとしても、必要とされなければ成功ではありません。

なお、Demingが重視したのはCheckではなくStudyを置くPDSAであり、結果から理論を見直す学習サイクルです。BMLと単純な対立概念ではありません。Deming Instituteも、PDSAでは予測と結果を比較し、必要なら理論そのものを修正すると説明しています。

ここで問題にしているのは、PDCAそのものではありません。Checkが計画比の確認、Actが未達の挽回策へ縮み、前提を疑わなくなった運用です。Eric Riesが2011年の著書『The Lean Startup』で広く知らしめたBMLは、計画の実行度ではなく「検証された学び」を進歩の単位に置きました。何を作るべきかすら分からない仕事では、計画の完成度を磨く前に、前提を学び直す必要があります。

予定どおり進み、予定どおり数字が動き、予定どおり「次も継続」と結論づける。そんな予定調和のPDCAは、仕事を正当化しているだけかもしれません。

BMLを顧客中心へ組み替える

このサイクルの目的には賛同しつつ、原典のままでは使っていません。Eric RiesのBuild–Measure–Learnループは、Ideas→Build→Product→Measure→Data→Learnと、企業の製品と事業仮説を中心に回ります。これを否定するのではなく、顧客の視点まで範囲を広げました。

原典のループ CX版BMLでの読み替え 広げた視点
Ideas 顧客体験のモデル 顧客の状態と、起きると考えている心理・行動の変化を仮説にする
Product 顧客体験 製品だけでなく、広告、店頭、UI、サポートなどの接点全体をBuildとする
Data 顧客理解のための証拠 業績に加え、同意のもと観測できる行動、本人の声、必要な背景情報を組み合わせる
Learn 顧客理解の更新 事業仮説の判定だけで終わらず、顧客体験のモデルを書き換える

冒頭の図が、このアレンジ版です。Buildで顧客体験を提供し、Measureで証拠を集め、Learnで顧客理解を更新する。三つをつなぐ中心に、カスタマーアナリティクスを置いています。

Measureが、レポートに戻っていませんか

若い頃、時間をかけてレポートを作り、会議で説明しても、返ってくるのは「なるほど」だけでした。数字は共有されるのに、アクションも意思決定も変わらない。翌月また同じレポートを作る。これでは精神論の反省会と同じです。せっかく作ったのに手応えがなく、レポートの作成に意味を感じられなくなっていきました。

では、何がわかればレポートは役に立つのか。会議で下したい判断から逆引きし、その判断を変えるために必要な情報を考えるようになりました。そこで気づいたのは、理解すべき対象は成果ではなく、人間だということでした。訪れた人は何をしようとしていたのか。どこで迷い、何に納得し、どう変わったのか。売上やコンバージョンは、その変化の結果にすぎません。

この模索は、2011年からASCII.jpで連載した「清水誠の『その指標がデザインを決める』」で、具体的な分析方法として形にしていきました。たとえば、ゴールのないサイトでもコンバージョンを測る方法では「どうなってもらいたいか」から指標を考え、エラーページのUXをGoogle Analytics+jQueryで解析では404の件数ではなく訪問目的を回復できたかを捉え、ログインボタンって本当に必要？ UIの常識を検証するでは訪問者の状態ごとに改善へつながる計測を設計しています。どれも、取れるデータを見るのではなく、何を知れば体験を変えられるかを先に考えた試みです。

2019年、電通アイソバーでCAOを務めていたときに、データ活用を「事業の効果・効率」から「顧客の理解と体験」へ移し、PDCAからBMLへ転換する必要があると話しました。当時の講演は、電通デジタルの記事に残っています。

あれからツールは進化し、データ処理は速くなりました。それでも、多くのMeasureは定例レポートのままです。

  • 先月よりPVが増えた
  • CV率が0.2ポイント上がった
  • 新しい機能が予定どおり公開された
  • AIでレポート作成時間を半分にできた

これらは事実ですが、何を学んだのでしょうか。

顧客が何に困っていたのか。提案した体験は役に立ったのか。迷いは減ったのか。理解や選択はどう変わったのか。次も同じ方向へ進むべきなのか。そこまで答えられなければ、Measureは活動報告で終わっています。

Lean Startupでいう進歩の単位は、作った量でもサイクルを回した回数でもなく、validated learning（検証された学び）です。実験を増やすだけでは、新しい洞察が生まれるとは限りません。Lean Startup Co.も、サイクル数の多さと学習は同じではないと説明しています。

実行はBuildから。設計はLearnから

BMLの実行順は、名前のとおりBuild → Measure → Learnです。しかし、設計までBuildから始めると、作ったものを後から正当化する計測になりがちです。

BMLの実行順はBuild、Measure、Learnだが、設計はLearn、Measure、Buildの順で逆算する

設計するときは逆から考えます。

1. Learn：何を学べば、判断が変わるか

最初に決めるのは、作る機能ではありません。確かめたい前提です。

比較情報が足りないから選べないのか。

自分に合う選択肢が分からないから不安なのか。

そもそも解決したい問題を、企業側が誤解していないか。

結果がどうなっても次の判断が変わらないなら、それは検証する価値の低い仮説です。

2. Measure：何を観測すれば、判断できるか

一つの数字で人の気持ちを断定しません。行動データ、本人の声、問い合わせ内容、継続利用、選ばなかった理由などを組み合わせます。

計測の前に、判断条件も決めておきます。

  • どんな結果なら仮説を支持するのか
  • どんな結果なら方向を変えるのか
  • 何が分からなければ追加調査するのか
  • 誰かへ負担や不利益が生じたら中止するのか

数字を見てから都合よく解釈を変えないためです。

3. Build：その証拠を得る最小の体験は何か

Buildは、完成した製品を作ることではありません。MVPも「機能が少ない製品」という意味ではなく、最小の労力で顧客についての学びを得るためのものです。Eric RiesによるMVPの説明でも、目的は検証された学びを最大化することに置かれています。

例えば、次のような小さなBuildで十分な場合があります。

  • 一つのLPに比較表を追加する
  • 紙やFigmaで体験を見せる
  • 自動化する前に、人が手作業でサービスを提供する
  • 既存データを異なる単位で集計し直す
  • 数人に試してもらい、迷った箇所を観察する
  • コンセプトダイアグラム上の一つの矢印だけを試す

大きく作ってから評価するのでは遅い。知りたいことに答えられる、最小の体験を作ります。

AIで速く回すほど、問いの悪さが増幅する

AIはBuildとMeasureを劇的に安くしました。プロトタイプ、SQL、分類、集計、可視化、仮説候補まで短時間で作れます。

だからこそ危険です。

問いが曖昧なままなら、意味のない機能と実験を高速に量産する。企業都合の指標しか見ていなければ、人を効率よく操作する方法を最適化する。AIがもっともらしい説明を返せば、学んだ気になってしまう。

AIでBMLを速く回すことを目的にしてはいけません。

AIには、探索、実装、集計、仮説候補の生成を任せる。人間は、何を学ぶべきか、その学びで誰の判断と体験をどう変えるのか、どこまで観測してよいのかを決める。

効率UPではなく、学びの質を上げよう。

コンセプトダイアグラムを、検証可能な仮説にする

コンセプトダイアグラムは、顧客の状態変化と、企業との接点を俯瞰するための図です。完成した正解を描くものではありません。

BMLと組み合わせると、図の要素を次のように扱えます。

コンセプトダイアグラム BMLでの役割
顧客の状態 現在理解している顧客像
状態を結ぶ矢印 起こると考えている変化の仮説
コンテンツやサービス 仮説を試すBuild
行動データと本人の声 Measureで集める証拠
図の修正 Learnによる理解の更新

例えば「比較している人へ機能一覧を見せれば、選べるようになる」という矢印を描いたとします。本当に足りないのは機能情報でしょうか。自分の状況に合う判断基準かもしれないし、選んだ後に失敗しないという安心かもしれません。

機能一覧を全面改修する前に、少数の人へ比較表と判断基準の二案を見せ、どこで迷いが減るかを観察する。結果から顧客状態と矢印を書き直す。図をきれいに完成させることより、理解を更新することが大切です。

一枚で始めるBML学習設計

次の八項目を一枚に書けば、形式的なサイクルから抜け出しやすくなります。

項目 書くこと
実現したい変化 顧客や関係者に、どんな望ましい変化が起きるか
現在の理解 その人が今どんな状況にいると考えているか
最も危険な前提 間違っていたら計画全体を変える仮説は何か
学びたいこと 次の判断のために、何を明らかにするか
必要な証拠 行動、発言、継続、失敗など、何を観測するか
最小のBuild 証拠を得るために、最低限何を作るか
判断条件 続ける、変える、やめる条件は何か
守る条件 同意、プライバシー、負担、不利益をどう扱うか

この順番なら、ツールが取れるデータから分析を始めずに済みます。実験の成功を、CVが上がったことだけにも限定しません。

サイクルを回した数ではなく、判断が変わった数を増やせ

PDCAという言葉をBMLへ置き換えても、Buildが施策、Measureがレポート、Learnが次回も継続、では何も変わりません。

計画どおり作る前に、最も危険な前提を見つける。数字を集める前に、何が分かれば判断を変えるのかを決める。AIで作業を速くする前に、その速さを誰のどんな体験へ使うのかを問う。

予定調和の効率UPでは足りない。仕事をこなすサイクルから、顧客について学び、企業の判断を変えるサイクルへ進もう。