何をつくるか決める。出したあと伸ばす

プロダクトが詰まる場所は3つあります。どこで詰まっているかによって入口が変わります。

• 何をつくるか決まっていない 4週間で決める
• 出したが、数字が伸びていない 定型の工程で伸ばす
• 運用しているうちに質が落ちてきた 毎週見る

3つとも工程と成果物が決まっています。金額は範囲を決めてから出しますが、何が出てくるかは先に決まっています。

何をつくるか決まっていない — 4週間で決める

新規事業の相談で最初に困るのは、作るものが決まらないことではなく、決めるための材料が揃わないまま時間が過ぎることです。調査を外注して2か月、報告書は分厚いが結局どうするかは決まっていない。よくあります。

次の6つを4週間で順に通します。期間を固定しているので、範囲の方を調整して必ず終わらせます。

1. 調査市場、競合、既存の利用データ。すでにある情報を集めて整理します。ここはAIで圧縮できる部分が大きい。人が読むと数日かかる量を、要点の抽出まで短時間で持っていけます。
2. インタビュー実際に使う人、使っていない人に話を聞きます。誰に何を聞くかの設計は人がやります。 ここを機械に任せると、答えやすい質問ばかりになって、聞くべきことが抜けます。発言録の書き起こしと分類はAIで速くなります。
3. 課題整理集めた情報を、解くべき課題の形にします。ここが山です。事実の羅列から「何が問題か」を立ち上げる工程で、人の判断が最も効きます。
4. コンセプト課題に対する解き方を決めます。複数案を出して、どれを試すかを選びます。やらないと決めたものも記録に残します。 半年後に同じ議論を繰り返さないためです。
5. プロトタイプコンセプトを触れる形にします。画面が通るだけで足りることもあれば、実データで動かさないと判断できないこともあります。作り直しのコストが下がったぶん、案を捨てやすくなりました。
6. ユーザーテスト実際に触ってもらいます。得たいのは「良いですね」ではなく、どこで詰まったかです。詰まった箇所は、そのまま次に直すべき場所になります。

なぜ4週間で回るのか

工程を減らしているわけではありません。1工程あたりの待ち時間を削っています。

従来のリサーチは、調べる人、まとめる人、作る人が分かれていて、受け渡しのたびに数日待ちが発生していました。リサーチの整理とプロトタイプの生成が速くなったので、少人数が通しで担当できるようになった。工程間の待ちが消えたぶんが、そのまま短縮になっています。

ただし設計と解釈にかかる時間は変わりません。 ここを圧縮しようとすると、それらしいが的外れな結論が出ます。速くなったのは、案を試す回数を増やせるところです。

4週間で残るもの

課題の整理、コンセプト、プロトタイプ、ユーザーテストの結果。加えて「やらないと決めたこと」とその理由を残します。次の意思決定で同じ議論を繰り返さないためです。

作ると決まれば、そのまま形にします。作らないと決まることもあります。 それも4週間の成果です。決まらないまま半年を使うより、はるかに安い。

この入口が向いているのは、次のような状態です。

• 新規事業のテーマは決まったが、具体的に何を作るかが決まらない
• 社内で意見が割れていて、判断する材料が足りない
• 調査を外注したことはあるが、報告書で終わって次に進めなかった
• 作る前に、ユーザーの反応を一度見ておきたい

リリースしたが伸びていない — 定型の工程で伸ばす

数字が伸びないときに困るのは、何から手をつけるかが決まらないことです。社内で意見を集めると改善案は山ほど出ます。優先順位がつかないまま、着手の順番が決まらずに止まります。

ここを5つの工程で処理します。

1. データ分析行動ログを見て、どこで人が落ちているかを特定します。ここが起点です。数字を見ずに始めるUX診断は、主観の言い合いになります。 計測が整っていない場合は、ここの設計から始めます。飛ばせません。
2. UX診断落ちている箇所を、実際に触って原因を特定します。分かりにくいのか、不安なのか、そもそも見つかっていないのか。同じ「離脱」でも原因が違えば打ち手が変わります。
3. 改善案原因に対する案を出します。1箇所につき複数案を出して、コストと効きそうな度合いで並べます。全部やる前提では作りません。
4. UI選んだ案を画面にします。既存のデザインシステムがあればそれに合わせます。
5. ABテスト案何をどう比べれば判断できるかを設計します。改善案は仮説なので、検証して初めて分かります。 何をもって成功とするかを、実装の前に決めます。

人を貸すのではなく、工程で出す

人を月ぎめで貸す形だと、成果の判断が月ごとの報告に寄ります。何が出てくるかは、その月に何を頼んだかで変わります。

こちらは工程と成果物が決まっています。診断、改善案、UI、ABテスト案。何が出てくるかが最初から分かっているので、頼む側も判断しやすい。

当たらないこともあります

改善案は仮説です。ABテストで負けることもあります。負けたことも記録に残します。「この方向は効かなかった」は、次の判断を速くする材料になります。当たった施策だけを並べた報告は、次に何をすべきかを教えてくれません。

この入口が向いているのは、次のような状態です。

• リリース済みだが、数字が想定より伸びていない
• 改善案は社内に山ほどあるが、優先順位がつかない
• デザイナーはいるが、何を直すべきかの判断で止まっている
• 計測はしているが、見方が分からない

運用中で、質が落ちてきた — 毎週見る

プロダクトは、放っておくと質が落ちます。悪意ではなく、リリースを重ねるうちに少しずつ外れていく。ボタンの余白が揃わなくなる。文言の言い回しが画面ごとにばらつく。フォーカスが見えない要素が増える。それぞれは小さく、誰も気づかないまま積み上がります。

毎週クロールして、6つの観点でレビューします。

• UX — 導線が詰まっているところ、迷いが生まれるところ
• UI品質 — 余白、揃え、状態表現の崩れ
• デザインシステムからの逸脱 — 定義されたルールから外れた実装
• アクセシビリティ — コントラスト、フォーカス、キーボード操作、代替テキスト
• コピー — 表記の揺れ、画面ごとの言い回しの不整合
• コンバージョンの阻害要因 — 入力の摩擦、不安を生む表示、押せると思えないボタン

毎週であることに意味があります

半年に一度の監査でも、問題は見つかります。ただしいつ入り込んだかが分かりません。 見つかった時点で原因のリリースは何十回も前になっていて、直すコストが上がっています。毎週見ていると、直前のリリースまで原因を絞れます。

もう1つ、見られていることが分かっている状態そのものが効きます。毎週レポートが出ると、作る側の基準が上がります。

いまは人力とAIの併用です

クロールと、機械的に判定できる項目は自動化しています。コントラスト比、代替テキストの有無、デザイントークンからの逸脱。ここは機械の方が正確で、見落としません。

一方で、UXの判断は人が見ています。 「この導線は分かりにくい」は、いまの機械には難しい。何を見るべきかの観点も、プロダクトごとに違います。ソフトウェアの比率は上げていく方針です。

社内のQAとの違いと、直す人

機能が動くかどうかではありません。バグではないが体験を損なっているものが対象です。テストは通る。エラーも出ない。それでもユーザーが離脱する。そういう領域は既存のQAの網から漏れがちで、担当も曖昧になります。

指摘したものは、原則そちらで直していただきます。こちらは検知と、直し方の提案、優先順位づけまでです。全部は直せません。 影響の大きさと直すコストで並べて、その週に実行できる件数まで絞って渡します。

この入口が向いているのは、次のような状態です。

• リリースの頻度が上がって、品質の担保が追いついていない
• デザインシステムを作ったが、守られているか分からない
• アクセシビリティ対応を始めたが、維持できていない
• デザイナーが少なく、全画面を見る余力がない

向いていない状態

作るものが既に決まっていて、あとは作るだけなら、この3つはどれも要りません。AI受託開発 の方が合います。

業務そのものに生成AIを入れたい、という相談なら 生成AI導入支援 です。プロダクトの体験ではなく、社内の作業を対象にする話になります。