LEAN UX 課題ステートメントに使えるテンプレート
課題ステートメントを事前につくる
チーム単位で課題に取組ために、共通認識＆言語を整える必要があります。 チームで明確な目標と制約を事前に合わせることで、ぶれることなく課題に取り組むことがでます。
プレゼンテーションやGIthubのissueの冒頭に次のようなテンプレートを添えることで、どんな課題に取り組むのかステートメントを明らかにしましょう。
新規のプロダクトやサービス向け
- 現状、[ドメイン]は主に[ユーザーセグメント、ユーザーのペイン(不満点)など]を重視している - 既存のプロダクトやサービスは、[マーケットのギャップ]に対処できていない。 - 当社のプロダクトやサービスは、[ビジョン / 戦略]でこのギャップに対処する。 - 当社が第一に重視するのは、[ユーザーセグメント、ユーザーのペイン(不満点)など]
既存のプロダクトやサービス向け
[サービス/プロダクト名]は、[この目標]を達成することを目標にしている。 しかし、このサービス/プロダクトは。[その目標]を達成しておらず、私たちのビジネスに[このような悪影響]を生じさせている。 [測定可能な標準]に基づき、ユーザーの成功率を向上させるためには、どのように[サービス/プロダクト]を改善すれば良いか？
ビジネスの推測と仮定のエクササイズ
課題ステートメントと合わせて、プロダクト/サービスがどのようなものなのか認識を合わせるために、次のようなワークシートを共有するワークショップを開きましょう。
ビジネスに関する前提 1. ユーザーには_____のニーズがあると考えいている。 2. これらのニーズは、_____によって解決できる。 3. 最初のユーザー（予定を含む）は_____だ。 4. ユーザーが私たちのサービスから一番得たいと思っている価値は_____だ。 5. 多くのユーザーは、_____などのメリットも得られる。 6. 多くのユーザーを_____を通じて獲得する予定だ。 7. 収益は_____を通じて得る予定だ。 8. 想定しているマーケットでの最大の競合は_____になると予測される。 9. 競合には、_____によって優位になる予定だ。 10. 私たちのプロダクトやサービスの最大のリスクは_____だと予測される。 11 このリスクは_____を通じて解決する予定だ。 12. 他の推測や仮定のうち、偽であると証明された場合にビジネスやプロジェクトに悪影響を及ぼす要 因になるものとして、_____が挙げられる。 ユーザーに関する前提 1. ユーザーは誰か？ 2. 私たちのプロダクトやサービスはユーザーの仕事や生活のどの部分にフィットする？ 3. 私たちのプロダクトが解決する課題は何か？ 4. 私たちのプロダクトは、いつ、どのように使われるか？ 5. どの機能が重要か？ 6. 私たちのプロダクトの外観と振る舞いはどのようなものか？
価値あるものを正確につくる
「エンジニアにもビジネス貢献して欲しい」が伝わらない
私はよく「技術だけではなく、ビジネスも」という言葉を使うのですが、本当に伝えたいエンジニア＆セールスのプレイヤーに伝わりにくいと感じています。
「エンジニアにもビジネス貢献して欲しい」は経営・マネジメント側の主張になってしまい、現場では「ビジネス」というwordに拒否反応を示すのではないでしょうか。
特にエンジニアは技術職であるという思いがあり、本来ビジネスマンが根底にあることを忘れているため、「技術だけではなく、ビジネスも」という言葉に反発を示したりします。また、これは程度問題であるはずがあるなし問題ととらえ、必要か不要かの思考になってしまいます。
価値あるものを正確につくる
エンジニアの立場に戻り、ソフトウェアとして考えてみましょう。ソフトウェアではValidation （妥当性確認）とVerification（検証）の２つのチェックがあります。
Validationとは、製品・サービス（各プロセスの成果物）が、ユーザの期待する通りに作られているかどうかを確認します。確認結果は、valid / invalidで表す。
Verificationとは、各プロセスの成果物が、入力情報から正しく作られているかどうか 正しさがあるかどうかを検証します。検証結果はcorrect / incorectで表す。
「ユーザの期待する通りに作られている」がvalidであるとき、価値があると定義します。
「価値あるもの」がユーザの痛みを取り除きお金を払っても使いたい（マネタイズ）というサービスであれば、利益につながある状態であるといえます。ゆえに、ユーザの期待する価値あるものを作れば、利益につながります。経営・マネジメントの思考であれば、ビジネスに貢献していると考えます。
正確につくるためには、どうしたら良いのでしょうか。ソフトウェアエンジニアであれば、設計手法、テスト手法などの技術能力（スキル）を向上しましょう。
「価値があるかどうか」や「ユーザの期待する通り」とはなんだろう？と疑問があるかたは、リーンスタートアップの世界に踏み込みましょう。
Lean UXの基盤と原則
Lean UXとは
Lean UXはリーンスタートアップの原則をユーザーエクスペリエンス(UX)デザインに適用し、プロダクト開発そのものから無駄を省句ことにより短期間でユーザーにとって最適なデザイン、プロダクトを導きだす。
基本的な考え方は、つぎの３つから構成させる。
- デザイン思考
- アジャイルソフトウェア開発
- リーンスタートアップ
デザイン思考は「ビジネスにおけるすべての側面に対して、デザイン手法でアプローチすることができる」という立場をとり、デザイナーは従来の役割に制限されることなく、組織内の境界線を越えて仕事ができるようになる。
アジャイル開発の４つのコアバリューをプロダクトデザインに適応する。
- プロセスやツールよりも、対人のコミュニケーションを
- 包括的なドキュメントより動くソフトウェアを
- 交渉よりもユーザーとの強調を
- 計画に従うより、変化への対応を
リーンスタートアップは、「構築(Build)」「計測(Measure)」「学習(Lean)」のフィードバックループによりプロジェクトのリスクを減らし、学習サイクルを迅速にまわす。
Lean UXの原則
チームビルディングに関する原則
- 部門横断的なチーム
- 小規模で同一の場所にいるチーム
- 自己充足的で、権限を持つチーム
- 課題焦点型のチーム
チームや組織文化の指針となる原則
プロセスの指針となる原則
- バッチサイズを小さくしてリスクを減らす
- 継続的に発見する
- GOOB：新たなユーザー中心思考を用いる
- 仕事を外面化する
- 分析よりも形にする
- 中間生成物中心の仕事の進め方から脱却する
影響力の高いGrowth Teamのビルディングと採用とは
この記事は、つぎのブログエントリーを日本語翻訳にしたものです。原文を読みたい方は、リンクからどうぞ。
はじめに
企業ごとに最適な成長戦略は異なります。 そのため、各企業は戦略を見つけて実行するために、多様なGrowth Teamが必要です。 この記事では、Growth Teamをビルディングする際の、考慮すべきポイントについて説明します。 これは、企業にとって適切なGrowth Teamビルディングの再現性の基礎となります。
チーム構成と役割
PMは他のリードと連携して戦略とプロジェクトを決定し、実行者であるエンジニアとデザイナーに伝えます。 全エンジニアに高品質なアイデアを伝えつづけることは難しく、PMだけがアイデアを考えることはおすすめしません。PMはプロジェクトを停滞させてはいけません。
Growth Teamを運営してきた中で最も効果的な方法は、エンジニアとデザイナーがペアになりアイデアと実験プロセスを実行します。PMは複数のペアをまとめ、1つの一貫した戦略を形成することです。
トップダウンではなくボトムアップな構成にします。 エンジニアとデザイナーの複数のペアとPMがGrowth Teamを構成し、複数のGrowthTeamでより大きなGrowth Teamを構成します。
Growth Teamは、役割( = ロール)のオーナーが曖昧な状態だったりします。アイデアを考える役割のオーナーがその一つです。 これは、特定の個人ではなくチーム全員にアイデアを考える責任があり、利点があります。
- 少数の人々だけがアイデアを思いついている場合、チームの成長に合わせて拡張することができない
- チームの全員がオーナーであり、チームの目標に責任を持つように感じられる
- さまざまな人がさまざまな見方をしており、アイデアを思い付くのが少数だと、特定の機会に偏り、他の機会を逃す可能性が高くなる
実験データ分析もまた、Growth Teamのフレキシブルなオーナーとなります。実験データ分析はアナリストだけではなく、PMやエンジニアなどよって実行する。
Growth Teamのメンバーは通常複数の役割があります。 ここでは、各チームメンバーの共通の役割をリストアップしますが、各Growth Teamのニーズは異なるため、 チームの目的・状態によって役割を変更しましょう。
PM
- 他のチームリーダーと共に、プロセスを主導してチーム全体の戦略を策定する
- 実験のアイデアを考え出し、優先順位を付ける
- ブロッキング事項を排除する
- Growth Teamのプロジェクトをリードする
- 実験結果の分析をする
エンジニア
デザイナー
すべての役割が重要であり、各役割のスキルレベルが異なると、チームの成果に劇的な影響を与えることがわかりました。
採用：イニシアチブと柔軟性
初期段階のGrowth Teamでは、柔軟な初期メンバーを見つけることが重要です。 たとえば、PMまたはエンジニアは基本的な分析をすることができます。
なぜ重要かというと、ブロックされないことがGrowth Teamのベロシティを最適化するための鍵であるということです。
たとえば、チームに一時的にデザイナーがいない場合、実験デザインのターンアラウンドは遅くなる可能性があります。 優れたGrowthエンジニアは、洗練されたデザインを長時間待つのではなく、イニシアチブをとって、構築およびテストできるモックアップを考案することができます。
だからこそ、成長の初期段階で採用する場合、役割に関わらず、イニシアチブ、柔軟性の2つが重要な特性となります。
Growthエンジニアを採用するにはどうすればいいか？
これは、私がGrowth Teamを始めることに関してよくある質問の1つです。 短い回答としては、採用は非常に難しい。おそらく最初からトレーニングする必要があります。
Growthエンジニアリングは比較的新しい分野であり、Growthエンジニアリングを持つ企業は比較的少ない。これらのチームは新しく小規模であるため、優秀なGrowthエンジニアの人材プールは極小です。人材プールは非常に少ないため、トップのGrowth Teamでさえ、成長経験のない人を採用することになります。効果的なトレーニングをすることで回避します。
Growthエンジニアを採用する際に何を求めますか？ 1つのトピックはseniority(長年の経験)です。 新しいGrowth TeamのメンバーはGrowthの経験がないため、シニアエンジニアとジュニアエンジニアのインパクトの差は予想ほど大きくありません。 技術的課題が少ないが大きな成長機会がたくさんあるため、新しいソフトウェアエンジニアも成長機会がある。
seniority(長年の経験)と全体的な影響との間にほとんど相関関係がないように思われるので、イニシアチブや柔軟性など他の成長特性を持っていると思われるジュニアエンジニアを雇うことを恐れないでください。 肝心なのは、実行速度が速く適切な機会を追求することで、インパクトを追いかける能力です。技術力があるエンジニアではなく、大きな影響を与える可能性が高いエンジニアを雇います。
Growthエンジニアを採用する際に、重要なスキルはつぎの２つです。
- 実験を迅速に実行する技術的能力
- データから学習できる
つぎのようなエンジニアを欲しているのではないでしょうか。
- 技術的なガイダンスなしで週に複数の実験を開始できる
- 基本的なデータ分析を行って機会を見つけ、ユーザーを理解し、実験結果を正しく分析できる
もちろん、これらのスキルはトレーニングできますが、最初のGrowthエンジニアの採用は、これらを既に実行できるエンジニアが必要です。
3番目の重要なスキルは、優れた成長のアイデアを導きだし評価できることです。これは時間をかけて訓練し、学習しなければならないものです。
このスキルを開発するために、以前のブログ投稿で説明したHIPEフレームワークを使用して、新しいGrowthメンバーが一貫して練習する一種のトレーニングを開発しました。 結果は実に素晴らしいものでした。アイデアは、成長経験のないチームメンバーからわずか1、2か月で「成功の可能性が低い」から「まともな機会」に変わりました。この方法については、今後さらにデータが得られるので、おそらくこれについては後で詳しく説明します。これが、教育への投資が有能な人材を雇用するのと同じくらい重要である理由です。
Growth PMをどのように採用するか？
PM経験者はProduct戦略とチーム効率化を経験しているため、これはおそらく3つの役割の中で最も簡単に採用できます。 PMに求めるメインの特性は、メトリクスの専門知識です。 メトリクスは戦略を決定する重要な要素であるため、戦略的リーダーはメトリクスの専門家である必要があります。
優先順位付けもPMの責任に該当する傾向があるため、データを使用してレバレッジされた機会を選択できるPMが欲しいでしょう。テストに1か月かかるが勝利につながらない実験などの回避も必要です。
優秀なPMは、スコープを縮小させることができます。スタートアップの創業者は、一般的にこの役割を満たすのに適しています。何かを構築し、ユーザーを獲得するための苦労と成長の重要性を理解しているからです。
Growth デザイナーをどのように採用するか？
優秀なGrowthデザイナーは、採用するのが最も難しいです。Growthデザイナーは、市場にいません。
求めるスキルは具体的です。
- 迅速に実行でき、多くの小さなデザインプロジェクトで作業を楽しめる
- 最高のProductを提供するために、UXとメトリクスの両方のバランスが取れる
まとめ
完璧なGrowth Teamの構成は存在していません。企業ごとに独自の戦略を実行するためにさまざまな種類のチームが必要です。 そのため、率先して柔軟に多才な人材を雇うのは良いことです。
従来の採用評価方法は、Growthメンバーには適していません。 最高の技術的能力を持つエンジニアを採用しようとしているのではなく、最も影響力の大きいエンジニアを採用しようとしていることを覚えておくことが重要です。 主要な人材を採用したら、今度は実験を開始し、チームの構造とプロセスを繰り返します。
サービスのGrowthについて学ぶにはこちら
「Hacking Growth グロースハック完全読本」です。より詳細な内容を学ぶには、自身で読んでください。
- 作者: ショーン・エリス,モーガン・ブラウン,金山裕樹,,門脇弘典
- 出版社/メーカー: 日経BP
- 発売日: 2018/09/28
- メディア: 単行本
- この商品を含むブログを見る
Hacking Growth グロースハック チーム構成について
この記事は、「Hacking Growth グロースハック完全読本」を読んでポイントとなるところを個人的にメモしたものです。 もし、サービス開発に携わっている方で、もっと成長させたいと思っている方のヒントになれば幸いです。
グロースチームの構成
グロースハックは、プロダクトに関わるあらゆる職種が協業しサービスを成長させます。 次のような役割（ロール）があります。
- グロースリード
- プロダクトマネジャー
- ソフトウェアエンジニア
- マーケティングスペシャリスト
- データアナリスト
- プロダクトデザイナー
グロースリード
責務
チームをマネジメントし、アイデア生成と実験に積極的に関わる現場のリーダーとして立ちまわる。 実験の工程とリズムを定め、チーム目標の達成度を管理する。
マネージャー、プロダクトオーナー、データサイエンティストを合わせたような役割を担う。
- OKR、KPIの設定する
- 上記の目標から外れたアイデアなど、チームが脱線しないように監視する
日々すべきことは、プロダクトオーナーに近い内容です。 現在の指標を測定、モニタリングし指標の変化をいち早く察知する。スキルセットは、データ分析の素養、プロダクトマネジメント、実験の計画・運用の理解する。 メンタルセットは、強いリーダー湿布でチームの集中力を高め、失敗しても実験のリズムが落ちないようにメンバーのモチベーションを維持ができる。
プロダクトマネジャー
プロダクトのさまざまな要素を形にする過程を監督する
ソフトウェアエンジニア
機能実装をするソフトウェアエンジニア、新製品や新機能の検討プロセスから入りエンジニアリングの手法を持ち込む。
マーケティングスペシャリスト
グロース専属のマーケティングをする。必要なマーケティング知識は、グロースのスコープが獲得・維持・収益化などどの部分かで変わる。
データアナリスト
実験のアイデアへの洞察を得るために顧客データの収集・整理・分析を行う。
プロダクトデザイナー
製品を通じて、ユーザーが体験する価値を最大化させるデザイナー。
チーム規模
組織の規模、サービスの規模によりグロースチームの規模もさまざまな形をとる。上記のロールを兼任することもある。
私たちが明日からできること
この記事を読んでいる方なら、インセプションデッキは作成していると思います。 「俺たちの”Aチーム”（何がどれだけ必要なのか）」に能力・期待することと合わせて、次のように責務を書くようにすれば良いと思います。 できるだけ、専任の方が良いですが、限られたリソースで最大限のパフォーマンスを出せるようなチーム体制を組みましょう。
| ロール | 担当者 | 責務（現状の課題に合わせて、具体的に書く） |
|---|---|---|
| グロースリード | ||
| プロダクトマネジャー | ||
| ソフトウェアエンジニア | ||
| マーケティングスペシャリスト | ||
| データアナリスト | ||
| プロダクトデザイナー |
最後に
この記事の元ネタの書籍は、つぎの「Hacking Growth グロースハック完全読本」です。より詳細な内容を学ぶには、自身で読んでください。
- 作者: ショーン・エリス,モーガン・ブラウン,金山裕樹,,門脇弘典
- 出版社/メーカー: 日経BP
- 発売日: 2018/09/28
- メディア: 単行本
- この商品を含むブログを見る
『プロの力が身につく Androidプログラミングの教科書』が発売されました
執筆に参加
『プロの力が身につく Androidプログラミングの教科書』は6人のAndroiderによって、書かれています。
私も執筆に参加させていただきました。
こんな方へ
Androidをこれからはじめようとする方＆脱初心者を望んでいる方に、是非、手に取っていただきたい本です。
本書HPから熱い思いをお伝えします。
引用元：http://android-textbook.com/android-programming-textbook/
本書は、Android のことを「知る」「学ぶ」「考える」「使う」「守る」「試す」ための入門書になります。 Androidのことをより深く知ってもらうための書籍でもあり、Androidアプリケーションの開発をはじめたばかりの方でも、本書を順番に読み進めながら学べる学習スタイルを採用しています。初心者の方だけでなく、Androidアプリケーションを開発された経験がある方でも、Androidのことをより深く知ってもらうための要素を含んでいます。最終的にはオリジナルのアプリケーションを開発し、世の中に公開できるようになることを目標にしています。また本書は、Androidアプリケーションの開発方法のみならず、執筆者の経験から得たノウハウを詰め込んでいますので、すべての開発者が「Android」というものを深く知ることができます。
本書の目次が上記HPに公開されています。是非、ご覧ください。
プロの力が身につく Androidプログラミングの教科書
posted with amazlet at 13.07.26
