Lean UX輪読会 1 ~ 3章: 成果ドリブンなソフトウェア開発

社内のLean UX(第三版)輪読書の資料です。

Transcript

1. Lean UX輪読会 1 ~ 3章: 成果ドリブンなソフトウェア開発 SUSTEN
2. Lean UXとは何か 2
3. This is Lean UX • Lean UXとは、コラボレーティブ、部門横断的、ユーザー中心の方法によっ て、プロダクトの本質を素早く明らかにするためのデザインアプローチであ る。 • Lean UXの手法は、ユーザー、ユーザーのニーズ、ソリューション案、成功 の定義についてはチームの共通理解を構築する。 • Lean UXは、チームの意思決定に求められる根拠を築き、プロダクトやサー ビス、価値の提供を絶えず向上させるために、継続的な学習を優先させる。 3
4. なぜLean UXは必要か 4
5. これまでのソフトウェア開発 • 「モノ」としてのアウトプットが求められる分野(自動車製造など)では何を 作るかを先に定義する必要がある。 • 製造コストが莫大 • 製品に欠陥があると損失コストが莫大 • その手法を踏襲してソフトウェア開発でもウォーターフォール型の開発が行 われてきた。 5
6. 現代のソフトウェア開発 • ソフトウェアは継続的にリリースされるようになった。 • アジャイルソフトウェア開発や継続的インテグレーション、継続的デプロイ などの技法を用いてリリースサイクルタイムを大幅に短縮している競合他社 との厳しい競争に晒されている。 → Amazonは毎秒毎に本番環境に新たなコードを追加している。 • リリースを早期かつ頻繁に行い、マーケットからのフィードバックを得て、 学習したことに基づいてイテレーションを繰り返し、ユーザーとの継続的な 対話を実現している 6
7. リリースサイクルを頻繁に繰り返すことの優位性 • プロダクトやサービスがユーザーのニーズをどの程度満たしているかを継続 的かつ迅速に学習できること • プロダクトやサービスの質、懸念事項やフィードバック対応の面でユーザー の期待値を上げられること 7
8. Lean UXで最善のプロダクト開発を • Lean UXが示す理想のソフトウェア開発は、チームはプロダクトやサービス の成功のために最大限に学習し、常に最善最短のコースを見極めユーザーの 声に耳を傾けることができる。 • 横断的なチームのコラボレーションによって情報伝達のために膨大な資料を作成する時間が不 要になる。 • メンバー全員が継続的にプロダクトに関わるため意思決定が早くなる • エンジニアは他のメンバーの作業を待つ必要はなく継続的にプロジェクトにコミットできる。 8
9. What’s not Lean? • 今の開発体制で”Lean”ではない、と思う点をあげてみよう！ • E.g. 他の部署の人とのコミュニケーションにコストを感じる、など 9
10. Lean UX 3つの基盤 10
11. 1. ユーザーエクスペリエンス・デザイン • ユーザーエクスペリエンス・デザインは「人間中心デザイン」というアイデ ィアに基づく。 • ユーザーのニーズを分析することでアプローチする。 • デザイナーだけではなくチーム全体でUXについて考える必要がある。 11
12. 2. アジャイルソフトウェア開発 1. プロセスやツールよりも個人との対話を →中間生成物や厳格なプロセスよりもコラボレーションや対話を優先 2. 包括的なドキュメントより動くソフトウェアを →早い段階でユーザーの手に触れさせることでチームはそのソリューションの市場適合性や実現可 能性を判断できる 3. 契約交渉よりも顧客との協調を →意思決定プロセスに全員が関わることで分厚い仕様書を用いた開発や説明のプロセスを削減でき る。 4. 計画に従うよりも変化への対応を →初期のプロダクトデザインには欠陥があることが前提、できるだけ早く問題点を軌道修正。 12
13. 3. リーンスタートアップ 13 • 「構築、計測、学習」のフィードバックループを用いてプロジェクトのリス クを最小化し開発と学習を迅速化する。 • チームはできるだけ早く開発プロセスを回すために「MVP(Minimum Viable Product：実用最小限の製品)」を短期間で開発し、リリースする。
14. MVP(Minimum Viable Product：実用最小限の製品) 14 https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
15. MVPテスト方法 15 • コンシェルジュ型 ◦ 製品を開発する前に人力で、製品、サービスに需要があるかを検証する方法 • プロトタイプ ◦ プロトタイプの製品を作成 • オズの魔法使い ◦ システムを構築する前に人間がそのシステムの働きをマニュアルで行い、ユーザーのニーズを確かめる方法 • スモークテスト ◦ ユーザーが製品・サービスに興味を示すかを検証するため動画やLPを作成する https://repro.io/contents/mvp/
16. Lean UX の原則 16
17. チームビルディングに関する原則 17 • 部門横断的 • 小規模、専念、同一環境で作業する • 自己充足的で権限を持つ • 課題焦点型
18. 「チームや組織文化の指針」となる原則 18 • 疑問から確信へ • 結果ではなく成果を重視する • 無駄を省く • 共通理解を生み出す • ユニコーン、エバンジェリストやヒーローは不要 • 失敗を許容する
19. 「プロセスの指針」となる原則 19 • 「これまでと同じことを速くやる」のではなく、仕事の進め方を見直す • プロダクト開発のフェーズに注意する • アジリティの鍵はイテレーション • バッチサイズを小さくしてリスクを減らす • 継続的な発見を活用する • 建物から出る • 仕事を外面化する • 分析よりも形にすることを優先する • 中間生成物中心の仕事の進め方から脱却する
20. 今のチームでは 幾つのLeanUXの原則が 守れているか？ 20
21. 成果(Outcome) 21
22. 私たちがしている仕事とは何か？ 22 • Lean UXとは「成果物主体のビジネスからの脱却」 • 成果物ではなく成果を生み出すためにビジネスをしている • 成果とは「行動の変化による価値の創造」 • 成果を定義するには「その行動から価値を得ているのは誰か？」という問題 を考える必要がある。
23. 開発している プロダクトは どのような変化を 創造したいか？ 23