Forkwell Press

SHARE

leanux-top
Event report

Lean UX でまわす、まわるプロダクト開発 坂田 一倫

エンジニアに役立つ情報を定期的にお届けします。

── 「つぎの一歩が見つかる、気づきと学びの場」 Forkwell Library シリーズ 第6回は、2022年8月29日に出版された最新版 Lean UX 第3版 を取り上げます。

坂田 一倫

株式会社Mentally CPO / Lean UX監訳者

ブラジル生まれアメリカ育ち、二児の父。 慶應義塾大学SFCを卒業後、2008年に楽天株式会社に入社。UIデザイナーとしてキャリアをスタート。ウェブサービスのリニューアルや事業戦略に基づくUX改善施策の立案から実務の遂行を担当。2016年Pivotal Labs Tokyo(現:VMware Tazu Labs)に入社後はPMとしてLeanXPの開発手法を用いながら企業のDXを支援。その後Chatwork株式会社のUXディレクターとしてUX戦略策定と施策立案をリード。2022年より株式会社Mentallyの創業に加わり CPO(Chief Product Officer)に就任。フリーランスとしても活動中。CliftonStrengthsの資質は「戦略的思考力」

Lean UX とは何か?

下記の3つを統合させた プロダクト開発手法です。

  1. デザイン思考:ユーザーの課題を特定し、 解決する糸口を探る
  2. アジャイル開発:いち早くユーザーに価値のあるものを届ける
  3. リーンスタートアップ:需要のないプロダクト開発などのリスクを回避し成功確率を高める

とくに重要な「リーンスタートアップ」 3つの特徴

1. 無駄をなくす

価値のない開発や価値の提供に直結しないドキュメンテーションを作成する時間を極力排除する

ドキュメント = 悪ではなく、ドキュメントの位置づけを変えようというのが本質です。例えばナレッジの属人化を避けるために新メンバーのオンボーディングの一環としてドキュメントを作成するなど、目的は何かを問うべきです。

2. 継続的に会話する

デザイナー、エンジニア、PMなどプロダクトにかかわるメンバーから新鮮で多角的な情報を集約する

余談ですが、最近注目されている ある目的や目標を達成するために、社内に散らばるノウハウを1ヶ所に集約するセンターオブエクセレンス(CoE)を編成する組織が増えてきています。。これにより組織内のあらゆる問題解決や効率化を図ることができるのですが、まさしくCoEの概念を取り入れるきっかけとなるのが「継続的に会話する」という部分です。

3. 学習量を増やす

プロトタイプによる検証期間を短縮、不確実性の高い要素を優先的に明らかにする

ペーパープロトタイプやノーコードツールに代表されるように、ローコストで短時間に成果を出せるツールを駆使しながら学習を増やしていこうという取り組みです。

leanux-002

Lean UX のプロセス

Lean UX 第3版 は、「Lean UXキャンバス」にウェイトを置き解説しています。Lean UX プロセスの詳細を知るには Lean UX 第2版 がおすすめです。 *ここでは簡単にご紹介します。

leanux-005

<思い込みや仮説>

  1. ビジネスの成果……プロダクトの成功を判断する基準
  2. ペルソナ……プロトペルソナ
  3. ユーザーの成果……ユーザーの課題は? 解決方法は?解決で得られるベネフィットは?
  4. 機能アイデア……ビジネスの成果、ユーザーの成果を成し遂げるためには必要な機能は?

<デザイン>

ワイヤーフレームのような忠実度が低いもの、ノーコードのような忠実度が高いもの、デザイン手法は多岐に渡りますが、ポイントは仮説の解像度にあわせて手法を選択することです。もし仮説の解像度が高ければ忠実度の高い手法でも構いませんが、解像度が低いにも関わらず、いきなり忠実度の高いデザイン手法を選択し、検証に踏み切ることはリスクであることを念頭に置いておきましょう。

<MVPの構築>

仮説の検証を通じてチームの学習量を最大化するために、低コストで用意できるモノ

<リサーチと学習>

  1. 小さな単位で繰り返し調査する継続的なリサーチ
  2. コラボレーティブなリサーチ

Lean UXキャンバスを用いた変化の捉え方 

Lean UXキャンバスは、何を、何のために、誰のために構築しているのかといった全体像を示すことができます。製品の潜在的に弱い部分を迅速に特定 / 修正し、ビジネス並びにユーザーの課題を解決することで、顧客中心の製品を作ることができます。

引用元:Lean UXキャンバスを用いた変化の捉え方
leanux-003

Lean UXキャンバスの仕組み

8つの主要な要素を含むブロックで構成されています。下記のように、ぜひ点ではなく面で捉えてみてください。この番号の振り方やブロックの位置には意味があります。グルーピングを意識することで、よりよいファシリテーションができると思います。

leanux-004

Lean UX キャンバスをうまく活用する方法

私なりに活用方法をまとめてみました。ぜひ参考にしてみてください。

leanux-014

<Lean UX がアップデートされた背景>

Lean UX 初版から7年、第2版から5年が経過しましたが、その間にアジャイル開発やOKRなどの目標設定フレームが深く浸透してきたことで、組織は顧客中心主義をこれまで以上に強く意識するようになりました。ただ、市場や顧客を取り巻く環境の変化に合わせて柔軟に対応していくことは未だに困難です。そのためにはサービスやプロダクトの不確実な要素を迅速に特定・修正し、問題の解決に向けたプロダクト開発を繰り返しまわしていく必要があります。 

<最新版 Lean UX 第3版 で追加されたこと>

leanux-001

Lean UX を基軸としたプロダクト開発のまわし方

ここからは事例を交えながら Lean UX の活用方法をご紹介します。

Lean UX 事例紹介 JR東日本アプリ「GO! by Train」

こちらは以前、JR東日本チームと共同で開発した「GO! by Train」というアプリです。

端的にいうと乗り換えアプリなのですが、ビジネスパーソン向けにA地点からB地点への最短ルートや遅延情報をパッと見で理解できるようにしたものです。他の乗り換えアプリは最短ルートが必ずしも上位に表示されなかったり、遅延原因がわからないものが多かったんです。遅延の原因がわかれば「遅れてはいるけど、すぐに通常運営に戻るな」といった判断ができますよね。このような取り組みがきちんと世に評価され、現在はJR東日本の公式アプリに取り入れられています。

プロジェクト全体の流れ

leanux-006

キックオフの流れとポイント

leanux-007

キックオフのポイントの1つは、翌日からアクションができるよう、プロトペルソナを補強するためのユーザーリサーチプランを立てることです。一斉に自身の頭に思い浮かべているユーザー像を書いていき、自信がなかったり、思い込みの可能性がある部分を議論の中で特定します。そうしたユーザーリサーチからプロダクトディスカバリーフェーズに入っていきます。

プロダクトディスカバリー

キックオフのアクティビティを踏まえ、プロダクトディスカバリーで実施していることを紹介します。

代表的なものは、Lean UXでも紹介されているプロトペルソナの作成です。プロトペルソナをもとに、最小限の力で検証できるアイディアを拡散して、ユーザーリサーチ結果からペルソナを修正・肉付けしていきます。わかったことや間違っていることを上書きし、チーム全員がこの事実に向き合う作業をします。

leanux-008

あとはリスクを回避するための優先度付けを、マトリックス図を用いて整理します。例えば、ビジネスインパクトやユーザーインパクトが大きい右上にあるものから早期に検証していくべきだ、というような検証プランを立てます。

leanux-009

リスクの優先度付けで「これは解決に値するニーズだ」と特定したものは、検証方法の洗い出しをします。例えばペーパープロトタイプの場合、一つの部屋にみんなで集まり「ユーザーはこういったことに困っています」「この案なら解決できます」といったアイデアを出し合い、それをデザイナーが形にします。これを繰り返し、確度の高いソリューションができたら、MVPという形で世に出します。

この段階で確実にわかっていることは「開発してもOK」というサインでもあるので、効率的に開発に取り組むことができました。

Lean UX 4つのメリット

Lean UXでは、定期的にユーザーとのタッチポイントが発生し、情報共有されることが特徴的だと思っています。自分のアイデアを出すことで課題を ”自分ごと化” できるので、自発的に動いてくれる人が増えました。

leanux-010また ”分かっているものから作る” アジャイル開発ができるので、エンジニアからは安心したという声を多く聞きました。いきなり大きな機能を作るのではなく、少しずつ開発が続けられることで自信にも繋がるようです。

Lean UX 最重要ポイント「アウトプットからアウトカム思考へ」

Lean UX 第3版 に書かれている最も大切なメッセージは「アウトプットからアウトカム思考へ」という部分です。

アウトカム思考とは?

プロダクトやビジネスのビジョンを実現するために、エンドユーザーの行動がどう変わっていくのが望ましいかを考えることです。あまり機能にフォーカスせず、どのように変わっていくのかを徹底的に考えます。

Lean UX著者 Jeff Gothelf のメッセージ

今回の Forkwell イベントにあたり、Jeff からメッセージをもらいました。私の方で意訳します。

leanux-011

現在のソフトウェア開発は継続的な変更が可能であり、それが求められています。何を作るべきか、安全にデザインすべきか、そしてユーザーはどういう反応を見せるのか。日々、発表される新しいツールによって小さなアイディアでもすぐに形にすることができますし、ユーザーの手元にいち早く届けることで、そのアイディアはユーザーのニーズに応えることができるのか評価しやすくなりました。評価だけでなく、改善に向けた学びやインサイトもを得ることができます。Lean UX はどうすればそれが可能になるのか、そしてあなたのソフトウェアかつプロセスにどのように適用すればいいのかを教えてくれます。

Q:組織に Lean UX を導入する良い方法は?

Jeff が来日した際にディスカッションしたことがあります。前提として4つのポイントを理解する必要があります。

  1. 自分自身が Lean UX の価値を正しく理解する
  2. 最大限に発揮される状況を理解する
  3. 組織における自分自身の役割を理解する
  4. プロジェクト・プロダクトのあり方を理解する

次に導入する際に参考になる普遍的な「UX 成熟度モデル」というフレームワークを紹介します。

leanux-012

あなたの組織は、この中のどこに当てはまるでしょうか。ここでは「1.認知されていない」を例にあげます。認知されていない場合は  Lean UX 第3版 やイベント参加などを通じ、周りに認知させ同志を集めることが大切です。組織の中で最もユーザー視点を持っているのはカスタマーサクセスだったりするので、部署を超えて共通課題を持たせ、コミニュケーションしていきましょう。Lean UX 著者が語るように、有識者をボードメンバーに入れることができれば究極ですよね。

— 「2.興味がある」 と「3.投資はしている」の間に大きなギャップがあり、ここの突破はなかなか難しいのではないでしょうか。

「この機能は良い!」と思っても、実際に全く使用されていない機能ならば、そのギャップは企業にとってリスクですよね。そのリスクを掲示しつつ、回避方法として Lean UX がありますよ、と必要性を促していくことはできると思います。一般的に機能の8割は使われないという話もありますから、そのあたりを理論武装しながら話すと良いと思います。

—日々の振り返りや課題意識から自分自身で進言していくのは、大事な一歩なのですね。

Q:チームのマインドセットが揃っていないと Lean UX で成果を出すのは難しい?

仰るとおりですね。ここでも「UX成熟度モデル」を活用できます。組織の成熟度を測ってみましょう。例えば、質問者様の組織が「1.認知されていない」「2.興味がある」に該当する場合、プロトペルソナを作ってみる、Lean UXキャンバスを埋めてみる、空白を補完する活動を始めてみるなど「学び」の機会を提供することで、次にやるべきことを促し「3.投資はしている」に移行できると思います。ぜひトライしてみてくださいね!

Q:Lean UX において、PMとデザイナーの役割はどう違う?

—「Lean UXの考え方で価値を作っていく場合、デザイナーは何をすればいいのか?」という似た質問もありました。

あまりパキっとわけず、フェーズにあわせて少しずつグラデーションになっていくようなイメージで考えています。

<PM>

ビジネス課題の解決に向けて意思決定する人(課題の洗い出しや優先度付け、ビジネスリスク検証、プラン立案)

<デザイナー>

ユーザー視点でインターフェイスを設計する人(デザインスタジオの実施、ファシリテーション、プロトタイプ作成)

<エンジニア>

アウトカムを最大化するための機能開発する人(実現難易度の検証、技術的リスクの特定)

このようにそれぞれの視点を持った3者がひとつのテーブルに座り意思決定されたアイデアって、やっぱりベストですよね。僕はその場をファシリテーションするのが、ユーザーの一次情報を持っていることが多いデザイナーなのかなと思っています。

—完全に分断して、PM、デザイナー、エンジニアと各タスクを渡していくのではなく「一つのテーブルに座って」の部分が重要なのですね。

そうですね。一つのテーブルの観点は持ちつつも、役割は明確化しておくべきだと思います。新規プロジェクトを立ち上げるときに明確に「ここはあなたの役割です」と決めておくといいですね。

—役割をはっきり決めておくのと、役割をはっきり決めずグラデーションで考えるという観点は相反する気もしますが、そのあたりはどう分けて考えると良いでしょうか?

何を作るか、アウトプットをベースに考えるといいかも知れません。ここは確かに難しいですよね。その人のスタイルにも寄りますよね。

—「デザイナーやPMが境界を超えて仕事をする場合、お見合いになったり誰の責任か不明瞭にならないでしょうか。」といった質問もあります。

共創機会の多さから、そのように感じる方々は多いです。アジャイル開発を取り入れているチームの「ワーキングアグリーメント」のような場を設け、メンバーの役割や責任範囲、特に何に対して意思決定権があるのかを言語化しておきましょう。

例)プロダクトマネージャーの場合

  • 開発する機能の優先度を決める
  • どのアウトカムをどの順番で達成するのかを決める

例)デザイナーの場合

  • 検証方法を決める
  • 具体的なインターフェース など

Q:Lean UX では探索的なリサーチを実施しないのですか?

—デザイン思考では、アイデア出しの前に探索的なリサーチをし、顧客ニーズを理解することが一般的なようですが、いかがでしょうか。

いいポイントですね。結論から言いますと、探索的なリサーチを行うケースはほとんどありません。

Lean UX の本質は仮説思考にあると思っています。『イシューから始めよ』(英治出版)という書籍でも言及されている「イシュードリブン」な考え方に近く、解決すべきユーザーの課題を素早く正確に見つけることを最優先としています。正解を見極めるために仮説は存在し、間違っていたら素早くピボットするというリーンスタートアップの要素がここで取り入れられています。

Q:良いユーザーストーリーの書き方とは?

—書籍では「単なる機能リストを羅列するのではなく、ユーザーの価値を書く」とありましたが、いかがでしょうか。

よくありますよね。Backlog なんかだとユーザーストーリーが機能の使い方になってしまったり。

例えば「検索機能 → ◯◯を探す」といったように、一歩下がって機能を動詞に直してみると良いかも知れません。ユーザーはこういう理由で、こういう行動をしたいから、という文脈を併せて記載するとわかりやすいですよね。

Q:Lean UX キャンバス を更新し続けるのは大変です。コツはありますか?

更新が難しい理由はいくつかあると思います。

  • 更新する内容がない
  • 十分な学びが出ていない
  • 情報が自分に届いていない
  • 単純に作業が間に合わない

更新する内容がない場合、検証スピードの見直しや情報共有の体制を見直すと良いでしょう。反対に情報量が多く、更新作業が間に合わないということであれば、常に見えるところに貼っておくなど見える化しておくことがポイントです。

Q:ワイヤーフレームのまま実装に進んでしまうことが多いです。

JR東日本アプリ「GO! by Train」開発時はデザインが最後でした。全く世に出せないようなデザインならともかく、十分にバリューが伝わるデザインであれば、先に進むことはむしろ良いことだと思います。機能がかたまっていて自信があるもの、確実なものを少しずつ進めていくのがベストなので、デザイナーとエンジニアがその共通認識を持っていれば問題ないのではないでしょうか。

Q:すでにアジャイルに取り組んでいるプロダクトの場合、どのように Lean UX を取り入れると良いですか?

アジャイルの捉え方によりますが、まずプロダクトディスカバリー(課題の発見・特定)にウェイトを置いてやってみるのはいかがでしょうか。

—エンジニアの世界ではプロダクトデリバリーの方に話が偏ることが多いかも知れません。チーム全員でプロダクトディスカバリーに集中するのは面白いですね。

Q:リモートワークで LeanUX を実践するコツは?

私の経験をお話します。まずチームメンバーがユーザーリサーチに同席するきっかけが減りました。オフラインなら別の部屋で観察してもらうような工夫ができますが、リモートでは同じルームに招待することになり、結果として被験者にバイアスをかけてしまうリスクを感じました。あとで録画したビデオを共有しても見てもらえない可能性が高いので、その点は非常に苦労しましたね。これらが全て解決できるわけではないですが、チームを少人数(5-6人)に留めることでリスクが軽減された実感があります。

Q:「自分達がユーザーでは無いこと」を理解させるコツは?

とてもいい質問ですね。2つあります。1つはペルソナを作成するプロセスに必ず関与してもらうことです。2つ目はどの意思決定においても、ペルソナ(ユーザー)ならどうするか?という問いを必ず投げかけることです。ユーザーの解像度が上がっていない場合は、ユーザーの声を直接フィードバックをすることも効果的です。

イベント動画の視聴はこちら

ForlkwellPress ロゴ画像

編集部

Follow

エンジニアに役立つ情報を定期的にお届けします。

エンジニアに役立つ情報を定期的にお届けします。

SHARE

目次

目次