こんにちは！データフィードチームでプロダクトエンジニアをしている thiger7 です。
突然ですが、皆さんのチームでは「Lean UX（リーンUX）」を実践したことはありますか？
私たちのチームでは以前から、プロダクト開発を進める中で以下のような課題感を持っていました。
- ユーザーの本当の課題に対する解像度をもっと上げていきたい
- 「なぜこの機能を実装するのか（Why）」という目的の共通認識を揃えたい
- 優先して検証・実行すべき仮説の絞り込みが大変
これらの課題を解消するため、チーム全員で書籍『Lean UX』の読書会を開催しました。 また、読書会で得た知見を踏まえて、実際のプロダクト開発プロセスを改善していくことにしました。
本記事では【実践編】として、読書会を経て実際にチームでどのようなアクションを起こし、開発プロセスを改善していったかについてご紹介します。
（※読書会自体の進め方やチームでの学びについては、別途公開する【学び編】にてご紹介する予定です）
Lean UX とは
「Lean UX」とは、リーン思考に基づくユーザー体験設計（UXデザイン）のプロセスです。 リーン・スタートアップやアジャイル開発の原則をUXデザインに適用し、短期間のサイクルでユーザーにとって最適なデザインとプロダクトを導き出すアプローチを指します。
本書では、プロトタイプを使った仮説検証、MVP（Minimum Viable Product）の構築、ユーザーから効率的にフィードバックを得る方法などが詳しく解説されています。 また、ビジネス課題や成果などを視覚化する「Lean UX キャンバス」というフレームワークも紹介されており、さまざまな職種が関わるプロダクト開発において、ステークホルダー間の認識ギャップを埋め、変化に的確に対応するためのヒントが詰まっています。
Lean UX Canvas V2 by Jeff Gothelf
読書会のきっかけ・目的
当初、チーム内で「より機動力のある開発チームを目指そう」という目標を設定していました。 しかしチームのふりかえりの中で、「そもそも顧客視点で考え、動き出せる状態になっていないのではないか？」という意見が出ました。
そこで、チームとして以下の2つの目的を設定し、全部で6回の読書会を実施しました。
- メンバー全員で Lean UX に対する共通言語・共通認識を持つこと
- Lean UX の思考を取り入れ、既存のプロダクト開発プロセスを改善すること
読書会を経て実践したこと・チームに起こった変化
約3ヶ月間の読書会を通じて共通認識を作った後、実際に現場の実務やさまざまな取り組みの中で、読書会の学びをアウトプットへとつなげていきました。
その結果、実践を通じて、実際の開発プロセスにおいて大きく3つの変化がありました。
1. 「アウトカム」視点へのシフト
以前のチームでは「デリバリー（機能をリリースすること）して終わり」になってしまうことがあり、それが本当に成果につながったかを追跡する視点が若干不足していました。
今回の読書会を通じて、「アウトプット」だけでなく「アウトカム（顧客への価値提供）」の意識を強くする重要性を学び、機能をつくること自体が目的化してしまう、いわゆる「ビルドトラップ」を回避する意識が定着しました。 その結果、プロトタイプのフィードバックを得る際に、PdMをはじめ開発メンバー自らが積極的にユーザーインタビューを行うよう変化しました。
顧客の意見に耳を傾けながら「真の課題や成果は何か？」を日常的に問い直し、次の学習・改善サイクルへスピーディーにつなげられるようになってきています。
2. コラボレーションの強化
「クロスファンクショナル（多職種協働）」の重要性を再認識したことで、エンジニアも課題定義や仕様検討といった初期の議論から積極的に参加するようになりました。
私たちのチームはリモートワークで開発を進めているため、以前は他職種との細かな意図のすり合わせや目的（Why）のニュアンス共有に難しさを感じる場面もありました。
しかし今回、請求業務効率化のプロジェクトにおいて Lean UX キャンバスを作成・更新するワークをチーム全員で進めたことで、リモートワーク下でもエンジニア、デザイナー、プロダクトマネージャーそれぞれの視点や「なぜこの開発を行うのか」という目的や課題感を早期から共有し合うことができました。また、「他職種が何を考えているのか」の理解が深まったことで、タスクに取りかかる際の迷いや認識齟齬が減り、チーム全体の開発スピードやコラボレーションの質が大きく向上しました。
特にデザイナーからは「今後自分がチームでのディスカッションや合意形成のプロセスを組み立てる際の良いヒントになった」という声も上がり、ファシリテーション能力の底上げにもつながりました。
3. 「デザインシステム」の構築
Lean UX のプロトタイプ作成や仮説検証を高速化するために、フロントエンドエンジニアのメンバーがデザインシステム構築に着手しました。 これはAIと人の双方にメリットがある施策だと考えています。
- 提案力の向上
- 判断基準（デザイン原則）が整理されることで、非デザイナーやAIでも品質の揃った画面提案ができる
- チーム内やAIとの認識齟齬が減り、デザインの属人化を防ぐ
- プロトタイプの高速化
- UIパーツが集約されているため、ゼロから画面を起こす手間を削減できる
- アイデアを素早くプロトタイプにして、検証サイクルを高速で回せるようになる
チームの一体感と意識の変化
一連のプロセスを通じて生まれた一番の収穫は、チームの一体感と意識の変化でした。
「Lean UX を踏まえて成果の定義を考えられるようになってきた」「みんなで一丸となって前に進んでいる感じがする」といったポジティブな熱量や行動が増えました。 同じ本を読み、価値観を深掘りして共有したことで、チーム内に強い「共通認識・共通言語」ができたと思います。
結果としてチーム全体のレベルアップを感じられ、個人のアクションだけでなく「チームとして何をすべきか」を主体的に議論・実行できるチームへと成長できました。
まとめ
本記事では【実践編】として、書籍『Lean UX』の読書会をきっかけに、私たちがどのようにプロダクト開発プロセスやチームの動き方を改善していったかについてご紹介しました。
チーム全員で共通認識を持てたことで、当初掲げていた「機動力のある開発チーム」の土台を作りつつ、アウトカム視点へのシフト、デザイナーと非デザイナーのコラボレーション強化、デザインシステムの構築といった具体的な成果へとつなげることができました。
プロダクト開発は一度リリースして終わりではありません。これからも一度作った Lean UX キャンバスや仕組みをそのままにせず、運用や開発のサイクルに合わせて継続的に更新・活用し続けながら、チーム全体で仮説検証を続けていきたいと考えています。
本記事が皆さんのチームのプロダクト開発プロセス改善の参考になれば幸いです！
