1 - Agile Japan

Agile Japan 2016
継続的ディスカバリー＆デリバリー
～顧客が欲しがるプロダクトを生み出すには？～
株式会社豆蔵
技術コンサルティング事業部チーフ・コンサルタント
杉山光治
https://www.flickr.com/photos/
1
会社紹介
株式会社豆蔵
• ITコンサルティングファーム
• 事業設立当初はオブジェクト指向の豆蔵として知ら
れ、UML、モデリング、RUPなどを啓蒙普及。
• 現在は豆蔵ホールディングスとしてグループ会社と
共に、アジャイル、ビックデータ、クラウド、ロボットな
ど、ビジネスを拡大中。
2000年 5月事業開始
2006年10月株式会社豆蔵ホールディングスの事業会社として新たに設立
2013年10月豆蔵ホールディングス東証一部上場
2016年現在連結従業員数2000名
2
自己紹介
杉山光治
• ITコンサルタントおよびアーキテクトとして、新製品の
開発案件やエンタープライズ系の大規模案件を担当。
システム基盤の構築、開発プロセスの整備、標準化、
モデリングなどに従事。
• 2008年より米国でのビジネスを経て、2011年より現職。
• CSPO
3
“市場（＝顧客）が最も重要だ。チームにスターを
揃えようが、製品が飛び切り素晴らしかろうが、
悪い市場（＝関心のない顧客）には勝てない。”
—マーク・アンドリーセン
（モザイクの発明者／ベンチャーキャピタリスト）
顧客が欲しがるプロダクトとは？
エンタープライズのシステム開発であれば…
• ユーザー企業やユーザー部門が要件を知って
いる。
• 要件定義を行い、その定義に沿って信頼性や
性能などの品質の高いシステムを開発すれば
良い。
• 枯れた技術要素を採用すれば安心。
昔のプロダクト開発であれば…
• リーダーが全てを把握し、決断すれば良かった。
ビジネスとITの関係は車の両輪
• ビジネスとITはそれぞれの役割を果たせば良い。
• IT企業（IT部門）はユーザ企業（ユーザー部門）
の御用聞きであれば良かった。
現在のプロダクト開発では…
• 不確実性の時代と言われる現在では、
誰も答えを知らない。
• 専門性を必要とする最新技術が重要。
• 多様性とその集合知が、解決策の発見を可能
にすると言われている。
ビジネスとITの一体化
• 車の両軸のような直線上の両端という関係では
なく、ビジネスとITの完全な一体化が必要と言え
るのかもしれない。
• 両者が一体となって、顧客が欲しがるプロダクト
を生み出す。
デザイン思考（Design Thinking）
“Design thinking is a human-centered approach to
innovation that draws from the designer's toolkit
to integrate the needs of people, the possibilities
of technology, and the requirements for business
success.”
—Tim Brown, president and CEO
3つのレンズ(THE THREE LENSES)
“This approach, which IDEO calls design thinking,
brings together what is desirable from a human point
of view with what is technologically feasible and
economically viable.”
INNOVATION
エンジニア
DESIRABILITY
(HUMAN)
UXデザイナー
FEASIBILITY
VIABILITY
(TECHNICAL)
(BUSINESS)
ビジネスサイド
ビジネスサイド、エンジニアおよびデザイナが、
プロダクトを共創するために必要なアイテム
1. マインドセット
2. フレームワーク
3. ツール
1.マインドセット
• ビジネスとITの一体化を目指す。
• システムの安定性や信頼性よりも、スピードを
重視する。
• “早く失敗せよ。（Fail Fast）”
• 自分たちのアイデアや直感が正しいという前提で製
品開発に着手するのではなく、積極的にアイデアの
死角を見つけ、自らの間違いを証明し、仮説を修正
する。
あなたが知っていることはすべて間違っている
• 人はだれでも認知バイアスを持っている。わた
したちの脳は世界をありのままではなく、自分
の都合のいいように解釈する。
• 確証バイアスとは、個人の先入観に基づいて他
者を観察し、自分に都合のいい情報だけを集め
て、それにより自己の先入観を補強するという
傾向。いったんある決断をおこなってしまうと、
その後に得られた情報を決断した内容に有利
に解釈する傾向をさす。
—Wikipedia(https://ja.wikipedia.org/wiki/)
2.フレームワーク
• “リーンスタートアップ”で
• “Lean UX”でジャニス・
エリック・リースが描いた
フレイザーが描いた
“Think-Make-Check”
“構築－計測－学習”
スタート地点が違う
アイ
デア
学習
する
構築
する
データ
製品
計測
する
Think
Make
Check
何も構築フェーズから開始する必要はない
• むしろ構築フェーズから開始すると、高価な代
償を支払う実験になることが多い。
• あなたがプロダクト開発とその保守に携わった
ことがあるなら、とりあえず作ってしまったため
に、ほんの一部のユーザにしか利用されていな
いプロダクトや機能をメンテし続けねばならない
辛さをご存知だろう。
3.ツール
• ツールは沢山ある…。
• 本日は、ツール自体の詳細な説明は割愛し、
実践するうえでのポイントを少しだけお話する。
継続的ディスカバリー＆デリバリーの全体図
①共感
②問題
定義
②スプリ
ント計画
4.
⑤テスト
5.
①リファ
インメン
ト
ﾌﾟﾛﾀﾞｸﾄ
ﾊﾞｯｸﾛｸﾞ
③創造
3.
④プロト
タイプ
2.
Ⅰ.学習
(Discovery)
6.
Ⅱ.構築
(Delivery)
1.アイデアの枠組みを理解する
1.
2.顧客とユーザーを理解する
3.ソリューションの全体像を描く
4.MVPを見極める
ﾌﾟﾛﾀﾞｸﾄ
7.
④スプリ
ントレ
ビュー
⑤ふり
かえり
5.プロダクトバックログ
6.プロダクト
インクリメンタル
7.プロダクト
Ⅲ.測定
(Measure)
9.
③スプリ
ント
8.
8.定性データ測定
9.定量データ測定
継続的ディスカバリー＆デリバリーの全体図
①共感
②問題
定義
②スプリ
ント計画
4.
⑤テスト
5.
④スプリ
ントレ
ビュー
①リファ
イメント
③創造
3.
④プロト
タイプ
2.
③スプリ
ント
Ⅰ.学習
(Discovery)
Ⅱ.構築
(Delivery)
6.
7.
1.アイデアの枠組みを理解する
1.
2.顧客とユーザーを理解する
3.ソリューションの全体像を描く
4.MVPを見極める
⑤ふり
かえり
5.プロダクトバックログ
6.プロダクト
インクリメンタル
7.プロダクト
Ⅲ.測定
(Measure)
9.
8.
8.定性データ測定
9.定量データ測定
継続的ディスカバリー＆デリバリーの全体図
①共感
②問題
定義
②スプリ
ント計画
4.
⑤テスト
5.
①リファ
インメン
ト
ﾌﾟﾛﾀﾞｸﾄ
ﾊﾞｯｸﾛｸﾞ
③創造
3.
④プロト
タイプ
2.
Ⅰ.学習
(Discovery)
6.
Ⅱ.構築
(Delivery)
1.アイデアの枠組みを理解する
1.
2.顧客とユーザーを理解する
3.ソリューションの全体像を描く
4.MVPを見極める
ﾌﾟﾛﾀﾞｸﾄ
7.
④スプリ
ントレ
ビュー
⑤ふり
かえり
5.プロダクトバックログ
6.プロダクト
インクリメンタル
7.プロダクト
Ⅲ.測定
(Measure)
9.
③スプリ
ント
8.
8.定性データ測定
9.定量データ測定
なぜデザイン思考にフレームワークが必要？
• “デザイン思考とは、デザイナーがデザインを行
う過程で用いる特有の認知的活動を指す言葉
である。”
－Wikipedia
• “デザイン思考における7つの心構え：
過程に注意：デザインプロセスのどの段階にい
るのか、その段階でどんな方法を使い、どんな
ゴールを目指すのかを意識します。”
－『デザイン思考家が知っておくべき39のメソッド』 the d.school
• デザイン思考の感性的な思考だけでは不足し
がちな論理的な思考をあわせもつことが、デザ
イン思考を使いこなすポイントである。
Ⅰ．ディスカバリー
（学習）
ディスカバリー
①共感
②問題
定義
②スプリ
ント計画
4.
⑤テスト
5.
①リファ
インメン
ト
ﾌﾟﾛﾀﾞｸﾄ
ﾊﾞｯｸﾛｸﾞ
③創造
3.
④プロト
タイプ
2.
Ⅰ.学習
(Discovery)
6.
Ⅱ.構築
(Delivery)
1.アイデアの枠組みを理解する
1.
2.顧客とユーザーを理解する
3.ソリューションの全体像を描く
4.MVPを見極める
ﾌﾟﾛﾀﾞｸﾄ
7.
④スプリ
ントレ
ビュー
⑤ふり
かえり
5.プロダクトバックログ
6.プロダクト
インクリメンタル
7.プロダクト
Ⅲ.測定
(Measure)
9.
③スプリ
ント
8.
8.定性データ測定
9.定量データ測定
ディスカバリーの基本4ステップ
4.MVPを見極める
3.ソリューションの全体像を描く
2.顧客とユーザーを理解する
1.アイデアの枠組みを理解する
1.アイデアの枠組みを理解する
• 戦略の階層
ミッション・
ビジョン
企業の理想像
全社レベル
経営資源の最適配分
事業レベル
割り当てられた
経営資源の事業配分
製品レベル
製品レベルの
マーケティング戦略
（R-STP-MM）
上位戦略との一貫性を保つ
• ステークホルダー全員（開発者含む）が、分厚
い事業企画書を読まなくても理解できる簡単な
図などで、上位戦略を共有すべき。
• 例えば、上位戦略レベルでは差別化で競争優位を
築こうとしているのに、製品レベルでは低価格路線
でいってしまえば、戦略の不整合が発生し、自社の
ブランドを傷つける恐れがある。
アンゾフの成長マトリクス
• イントレプレナーの場合：
既存製品
新製品
新
市
場
市場開拓戦略
多角化戦略
既
存
市
場
市場浸透戦略
新製品戦略
－『コトラー＆ケラーのマーケティング・マネジメント』フィリップ・コトラー／ケビン・レーン・ケラー
リーンキャンパス
－『RUNNING LEAN 実践リーンスタートアップ』シンディ・アルパレス
リーンキャンパス：
ソリューションから描かない
－『RUNNING LEAN 実践リーンスタートアップ』シンディ・アルパレス
2.顧客とユーザーを理解する
• デザイン思考の第1ステップである共感。
• デザイン思考を提唱したIDEOは当初、共感の
メソッドにより米国で高い評価を得た。
共感のメソッド一覧
初心者としての思考法
ボディーストーミング
ユーザーのカメラ
共感のためのインタビュー
類推共感
物語の共有と把握
共感マップ
デザイン原則
ユーザーとのテスト
ユーザー主導のテスト
ストーリーテリング
オブザベーション
スキット
ペルソナ
－『デザイン思考家が知っておくべき39のメソッド』 the d.school
インタビュー
“建物の外に出よ。”
－スティーブ・ブランク
（『アントレプレナーの教科書』著者）
インタビュー：
インタビュー結果をチームで共有する
• インタビュー結果の分類作業をチームで行う。
• 大きな壁にポストイットを張り付けて作業する。
• ポストイットに書き写すのに時間がかかるが、ポスト
イットを移動させながら話をすることで、議論が活性
化し、顧客の声がチームに浸透する。
• インタビューアーは「インタビューの議事メモ」のような
メールをチームメンバーへ送らないように。
• 顧客の背景をあわせて説明する。
• チームメンバーをローテーションで書記役にする。
ジャーニーマップ
•
•
•
•
ジャーニーマップは現在(ASIS)のストーリーマップ。
顧客（ユーザー）の1日を共感する。
取り組みやすい。
将来(TOBE)のストーリーマップの練習になる。
ジャーニーマップ×バリューマップ×メタファー
③メタファー（同様の目的や課題をもつ他のモノやコト）
WHY
ヒント
②バリューラダー（ユーザーの行動の目的や課題）
代替案
①アクティビティ（ユーザーの行動）
HOW
④ソリューション
⇒ユーザーストーリーマップ（TOBE）へ
右脳／左脳
収
束
（
論左
理
脳
的
）
（
感
右
性
脳的
）
発
散
3.ソリューションの全体像を描く
• ユーザーストーリーマッピングで全体像を描く。
• 全体像を描くことで、優先順位付けできる。
• スライスを切り、プロダクトバックログを作成し、
“イテレーティブにしてインクリメンタル”に
開発する。
ユーザーストーリーマッピング：
機能一覧になってはならない
• ユーザーストーリーの3W
• ユーザーストーリに詳細な仕様を書かない
ユーザーストーリーマッピング：
顧客とユーザーは違う
• 顧客
•
プロダクトを買う人
• ユーザー
• プロダクトを使う人
顧客とユーザーを混同すると、優先順位付けに失敗する。
顧客：おもちゃを買うパパ
ユーザー：おもちゃを使う（遊ぶ）子供
顧客とユーザーを混同しないために
• 1ストーリー： 1ターゲット（顧客／ユーザー）
• ユーザーストーリーは、WHATが一緒でもWHOが異
なれば別ストーリーとすべき。
• 顧客やユーザーからのフィードバックをイメージし、
ターゲット(WHO)の違いを理解すれば、機能(WHAT)
が変わってくることもある。
4.MVPを見極める
• MVPとは？
• MVP：Minimum Viable Product（実用最小限の製品）。
• MVPという用語は、その短い歴史の中で多くの混乱
を招いてきた。
• 問題は、それが2つの異なる方法で使われている点
である。
－『LEAN UX』ジェフ・ゴーセルフ・ジョシュ・セイデン
MVPの種類
• 最小限の価値を提供する
MVP
• できるだけ早く市場に価値
を届けるために、製品や機
能の小さなバージョンをつ
くる。
• フェーズ：デリバリー
• 学習のためのMVP
• 市場に価値を提供するこ
とを重視せず、市場が何
を求めているかを理解す
るためにつくる。
• フェーズ：ディスカバリー
フェーズに応じて、2種類のMVPを使い分ける
• 実用最小限のMVPを早く作ろうとするあまり、
リスクを軽減したり、ミスを特定したりする機会
を見逃してしまうことが多い。
• ディスカバリー・フェーズにあるときの方が、
はるかに短期間かつ低コストでアイデアの
エラーを見つけることができる。
狩野モデル
• 魅力品質
(Attractive)
• 性能品質
(One-dimensional)
• 基本品質
(Must-be)
－日本科学技術連盟
上記のような分類をしないと、優先順位付けに失敗する。
SUCCES
• AttractiveがSUCCESであるかを評価する。
＃キーワード
S Simple
U Unexpected
C Concrete
C Credible
E Emotional
S Story
単純明快である
意外性がある
具体的である
信頼性がある
感情に訴える
物語性がある
SUCCES:
トランジスタラジオの例
－SONY
デザイン思考
• Attractiveなストーリーにデザイン思考のプロセ
スを適用する。
• デザイン思考の5つのステップにより、発散と収
束を繰り返し、優れたアイデアを生み出していく。
Empathize
共感
Ideate
創造
Define
問題定義
Prototype
ﾌﾟﾛﾄﾀｲﾌﾟ
Test
テスト
Ⅱ．デリバリー
（構築）
デリバリー
①共感
②問題
定義
②スプリ
ント計画
4.
⑤テスト
5.
①リファ
インメン
ト
ﾌﾟﾛﾀﾞｸﾄ
ﾊﾞｯｸﾛｸﾞ
③創造
3.
④プロト
タイプ
2.
Ⅰ.学習
(Discovery)
6.
Ⅱ.構築
(Delivery)
1.アイデアの枠組みを理解する
1.
2.顧客とユーザーを理解する
3.ソリューションの全体像を描く
4.MVPを見極める
ﾌﾟﾛﾀﾞｸﾄ
7.
④スプリ
ントレ
ビュー
⑤ふり
かえり
5.プロダクトバックログ
6.プロダクト
インクリメンタル
7.プロダクト
Ⅲ.測定
(Measure)
9.
③スプリ
ント
8.
8.定性データ測定
9.定量データ測定
開発プロセスの比較
規約的
適応的
－『Kanban and Scrum making the most of both』 Henrik Kniberg and Mattias Skarin
スクラム×カンバン
スクラム
カンバン
共通点
•見える化により、プロセス改善を進める。
•作業を細かく分割することを求める。
•WIP（作業中）を制限する。
•自己組織的なチームに基づく。
•リリース計画のメトリクスを継続的に最適化。
相違点
•時間を区切ったイテレーションは必須。
•必須ではない。
•スプリント毎にボードをリセットする。
•リセットするタイミングはない。
•WIP（作業中）の制限が間接的
（スプリントに対する制限）。
•WIP（作業中）の制限が直接的。
•1スプリントで完了できる大きさのタスク。 •タスクの大きさに決まりはない。
•3つの役割を規定。
•役割は何も規定されていない。
•クロスファンクショナルチームを規定。
•専門家も許される。
•多能工（何でもできる人）で構成される。
•イテレーション中の計画変更は許さない。 •計画変更を許す。
スピード重視×しなやかな設計
• スピード重視だからと言って、変更に強い設計
を捨ててはならない。
• スピード重視
• 対象：UI、アプリケーションサービス
• メンテしきれなくなったらスクラップ＆ビルドでも良い。
• しなやかな設計
• 対象：コアドメイン
• 重複がなく変更に強い設計。継続的に改善すべき。
ドメイン駆動設計
（DDD：Domain Driven Design）
• いずれのアーキテクチャでもドメインを隔離する。
• レイヤー化アーキテクチャ
UIレイヤ
• ヘキサゴナルアーキテクチャ
外部インターフェース
アプリケーション
アプリケーションレイヤ
ドメイン
ドメインレイヤ
インフラストラクチャレイヤ
DDDの戦略的設計
• ドメインのコアドメインに注力する。
コアドメイン
サブドメイン
サブドメイン
汎用サブドメイン
DDDとアジャイルは相性がよい！
Ⅲ．メジャー
（測定）
メジャー
①共感
②問題
定義
②スプリ
ント計画
4.
⑤テスト
5.
①リファ
インメン
ト
ﾌﾟﾛﾀﾞｸﾄ
ﾊﾞｯｸﾛｸﾞ
③創造
3.
④プロト
タイプ
2.
Ⅰ.学習
(Discovery)
6.
Ⅱ.構築
(Delivery)
1.アイデアの枠組みを理解する
1.
2.顧客とユーザーを理解する
3.ソリューションの全体像を描く
4.MVPを見極める
ﾌﾟﾛﾀﾞｸﾄ
7.
④スプリ
ントレ
ビュー
⑤ふり
かえり
5.プロダクトバックログ
6.プロダクト
インクリメンタル
7.プロダクト
Ⅲ.測定
(Measure)
9.
③スプリ
ント
8.
8.定性データ測定
9.定量データ測定
AARRRモデル
• 定番とも言えるデイブ・マクルーアの“海賊指標”。
獲得（Acquisition）
Idea
アクティベーション（Activation）
Idea
Idea
定着（Retention）
収益（Revenue）
紹介（Referral）
ファンネル
AARRRモデル：
ファンネル×コホート分析
• 行動につながる指標を得ることができる。
• コホートとは、ある期間に共通の特性や経験を
もった人の集団のこと。
• 追跡したいユーザの属性がコホートとなる。
• 例：登録日、料金プラン、OS、性別
90(70%)
獲得
100(71%)
獲得
110(70%)
獲得
78(87%)
アクティベーション
86(85%)
アクティベーション
100(91%)
アクティベーション
15(19%)
収益
16(19%)
収益
20(20%)
収益
最初から課金する
• 安易なフリーミアム戦略をとらない（短期間の試
用期間は可）。
• 課金は、早期に仮説検証すべき大切な要素。
継続的な
ディスカバリー・デリバリー・メジャー
フィードバックループをまわす
①共感
②問題
定義
②スプリ
ント計画
4.
⑤テスト
5.
①リファ
インメン
ト
ﾌﾟﾛﾀﾞｸﾄ
ﾊﾞｯｸﾛｸﾞ
③創造
3.
④プロト
タイプ
2.
Ⅰ.学習
(Discovery)
6.
Ⅱ.構築
(Delivery)
1.アイデアの枠組みを理解する
1.
2.顧客とユーザーを理解する
3.ソリューションの全体像を描く
4.MVPを見極める
ﾌﾟﾛﾀﾞｸﾄ
7.
④スプリ
ントレ
ビュー
⑤ふり
かえり
5.プロダクトバックログ
6.プロダクト
インクリメンタル
7.プロダクト
Ⅲ.測定
(Measure)
9.
③スプリ
ント
8.
8.定性データ測定
9.定量データ測定
スタートアップの3つのステージ
重要なマイルストーン
第1ステージ：
第2ステージ：
第3ステージ：
課題／解決フィット
（Problem/Solution Fit）
製品／市場フィット
（Product/Market Fit）
拡大
(Scale)
解決に値する課題は？
誰かに必要とされる
成長を加速するには？
製品かどうか？
BPMF:
Before Product/Market Fit
検証による学習に集中する。
APMF:
After Product/Market Fit
成長に集中する。
サマリー
• ターゲット（顧客／ユーザー）の視点。
• ビジネスサイドとエンジニアの一体となった取組み。
• 継続的な《ディスカバリー》－《デリバリー》－
《メジャー》。
“If you want to go fast, Go alone,
If you want to go far, Go together.”
“早く行きたいなら、一人で行きなさい。
遠くへ行きたいなら、みんなで行きなさい“
－アフリカに古くから伝わる諺
ご清聴を誠にありがとうございました。

Download Report