リーンスタートアップのリフレーミング：Frame-Build-Measure-Learn（構成-構築-計測-学習）
まえがき
当記事はアメリカに拠点を置くアジャイル開発を支援するエージェンシー Ralley Software のチーフテクノロジストである Zach Nies氏の記事を許可の元、翻訳・再編した文章です*1。
日本でもソフトウェア業界をはじめ、関心が集まっている Lean Startup（リーン・スタートアップ）。無駄を徹底的に省くことに目が奪われがちですが、語源となったと言われている Lean Body（リーン・ボディ：引き締まった身体）を目指すためのダイエットに同じく、無駄がなくなることは結果であり、成果ではありません。リーン・スタートアップは正しいモノが生み出されることを成果とする、または正しいモノが生み出されるまでを支援する手法体系であり、正しくモノをつくるための方法論ではないと考えます。
"A company following the lean methodology is like a well-trained body - almost nothing but muscle. It can be large, like a bodybuilder, but only because it needs all those resources (muscles) to build the product customers want & need." ー The Lean Startup Circle Wiki / Misconceptions about Lean Startup
そんな中、原稿の記事を拝見し、リーン・スタートアップを主題としたものづくりにおける様々な現象の Framing（構成）と Unframing（分解）を繰り返し、意味性を追加する彼のメタ的視点に感銘を受け、翻訳を通じて読者のみなさまにご紹介をしようと思い立ちました。Product-Solution Fit という表現がありますが、その実現と効果的な検証のためには当記事も紹介されている Testing-Modeling Fit が必要不可欠だと確信しました。
その真髄は、結果の判断のみで「失敗した」と思考停止する状態を避けるための継続を促すフレームワークです。目先の利益や結果に捕らわれてしまい、失敗したから次の方法論へ…という悪循環に陥りやすい状態から脱却するためには、繰り返し実験をする、繰り返し努力をすることが重要だと考えます。
失敗するであろうと世間から言われてきたミドリムシ事業を発展させ、成功を収めている株式会社ユーグレナ― 代表取締役 出雲 充氏の言葉がそれを物語っています。
『例えば、「１回目の挑戦での成功確率が1パーセント」という状況があったとします。つまり99％は失敗する状況です。ではその状況であきらめずに２回挑戦した時の確率はどうなるか。２回とも失敗する確率は99％×99％＝98.01％です。つまり、成功確率は約２％（1.99%）となり、１％成功確率が上がります。３回、４回、５回と続ければ4.9%。100回やれば63%。そして、459回やれば、最初と数字が逆になります。「一度やってうまくいく可能性が１%の出来事は459回繰り返せば、失敗する可能性が１%」になるんです。』
これまで当ブログでご紹介してきた CPS仮説検証モデルを基軸に、繰り返しの実験をより生産的に実施するための「Frame-Build-Measure-Learn（構成-構築-計測-学習）」、ぜひご参考ください。
はじめに
著書『リーン・スタートアップ』で Eric Ries氏は Build-Measure-Learn（構築-計測-学習）のフィードバックループを提唱し、不確実性が高い状況下におけるものづくりの指針をアップデートしました。このフィードバックループの目的は前提となる思い込みやリスク、未開拓領域を知識に変え、不確実性が高い状況下でもチームやメンバーが効率的に前に進むためのイノベーティブな方法論として紹介されています。フィードバックループにおける最も大切な要因は学び（学習）や発見です。つまり、仮説となる思い込みや前提が実証あるいは検証されるまでの期間をどれだけ短縮しかつ無駄を省き、次に繋げるために有効活用できるのか、ということです。
言うのは易く行うは難し、という言葉があるようにこのような説明にはジレンマが生じます。 Build-Measure-Learn（構築-計測-学習）のフィードバックループを順番通りに着手し、学習の手前である実証や検証を目的とした実験の段階に突入すると多くの人がどのように実験をすればいいのかわからず、得られた結果が例え想定外であったとしても何を学びとすればいいのか確信が持てず、不確かな状況が続くことがあります。
但し、これは良い傾向にあると考えています。想定外の事情に直面することは正に実験の醍醐味であり、想定内の事情が起こった現象の背景や意図が理解できない状態よりも発見や収穫は多いはずです。設計や構築により多くの時間を費やすことに慣れている環境下では、学習期間に多くを費やすことに意味性を見出すことは難しいかもしれませんが、不確実性が高ければ高いほど、言葉を変えれば実証されていない要素が多ければ多いほど、このフィードバックループは有効だと考えています。
現時点で「フィードバックループの重要性は理解した、または理解している。では具体的にどのように実験や実証を通じて学びや知識を得れば良いのだろうか？」という疑問を抱いている方がいらっしゃると思います。ここで私が提案したいのは、フィードバックループのBuild-Measure-Learn（構築-計測-学習）には最も大事なステップである Frame（構成）が抜けているということです。私が提案する、「Frame-Build-Measure-Learn（構成-構築-計測-学習）」によって、今後実施される実験や実証をより効果的に消化することができると考えています。
Frame（構成）
新しく提唱したステップである Frame（構成）には2つの側面があります。課題の構成と実験の構成です。この2つのアプローチによって、以降の Build-Measure-Learn（構築-計測-学習）はより活きていきます。
課題の構成
実証や検証のためにモノをつくる前に、先ずはどのような学びを得たいのか、あるいはどのような課題を解決したいのか、という構成から始める必要があります。Build-Measure-Learn（構築-計測-学習）こそ Build（構築）からプロセスはスタートしていますが、思考順序は逆を進みます。 Learn-Measure-Build（学習-計測-構築）となり、仮説を軸とした学びや発見を得るためには、どのような実験を行えば、またはどのような計測をすれば対象の仮説が実証されるのかを先ずは考え、そのためのプロダクトやサービスを構築する、という手順です。
この構想そのものが Frame（構成）です。先ず始めに対象のユーザーに対して共感力を強め、顧客開発と共に顧客発見や理解を促進するような実験を検討していきます。昨今ではジャーニーマップなど優れた手法が紹介されているので、仮説ベースで可視化をし、ユーザーへの共感を強めていく準備を事前に進めることができます。アプローチすべき正しい課題や仮説を設定するためには、ユーザーへの共感こそが全てです。
実験の構成
では次に実験を構成するための手順をご紹介します。
- 背景：なぜそのような実験を試みようと思いましたか？なにを学び、そしてなぜ学びたいと思いましたか？これらの質問に対する回答を記載してみましょう。慣れない作業かもしれませんが、書くことによって学びや発見の可能性が更に広がります。
- 仮説：簡単にでも良いので、これから実施する実験への期待を考えてみてください。この場合の仮説とは、実験の想定結果です。科学実験と同じく、仮説が不在では実験後の結果の善し悪しの判断がつきづらくなってしまいます。
- 実験方法：考えられる実験方法や要素を洗い出してみてください。手順も詳細に書いてみましょう。これが最も重要です。後に言及する「Experiement Report（実験シート）」に従って各要素を書き出してみましょう。あわせて、実験の妨げや影響要因となるような可変要素も同時に把握することで、仮説の設定が容易になります。
- 期待する計測結果：定性及び定量の側面から実験を通じて仮説が実証・検証されたことを判断するための指標を書き出してみましょう。定量情報は「WHO（誰が）・ WHAT（なにを、なにが）・WHEN（いつ）」を明確にすることができ、定性情報はその背景にある「HOW（どのように）・WHY（なぜ）」を理解することができるため、双方の実験を推奨しています。
上記に記載の手順に従って各要素の洗い出しを進めることで、実験の最中に直面する想定外の現象に対しても冷静に検証を進めることが可能になります。人間の脳は検証の場において、目の前で発生する現象に対して疑いもなく期待していた結果だったと都合良く解釈してしまう癖があるようです。実験終了後にも必ず当シートを参考に確実に実験を振り返るように心掛け、失われかけた学びを取り戻すようにしましょう。課題と実験の Frame（構成）によって、その後の学びの質は決まります。
Build（構築）
仮説を軸とした学びや発見を得るためには、どのような実験を実行すれば対象の仮説が実証されるのかを先ずは考える…と前述しましたが、構築の対象となるプロダクトやサービスの目的は学習や発見の達成のためとして位置付けることができると思います。そのためには以下の3つのポイントを抑えておくと良いかもしれません。
1. 実験方法を考える
実験の構成が終わったら、次はデザインを施し、構築し、実際に運用するステージへと移っていきます。実験は細かければアジャイル開発に習って実験を細分化し、頻度を上げて実施してみましょう。但し、忘れてはならないのはすべての実験はひとつのプロダクトやサービスに紐付いていることです。得られた結果や学びを前に、正しい情報や必要とするデータに目が行くようにしましょう。実験終了後には次にすべきことが自然と明確になっている必要があります。もし不明確なのであれば実験方法から、ないしは仮説の設定から再考することを推奨します。
2. 実験の場をつくる
実験が大掛かりに、かつ複雑にならないように気をつけましょう。MVP という言葉があるように、可能な限り小さな単位で実験を計画・実行することで仮説が実証・検証しやすい環境をつくりだし、学びや発見を見失わないように心掛けます。対象となるプロダクトやサービスも同様に、小さくする必要があります。著者の推奨は、ペーパープロトタイプやランディングページです。どちらかで大半の仮説を実証・検証することができると思います。
3. 実験を行う
対象が整い、開始する準備ができたらいよいよ実験です。実験という言葉からはある程度の労力や準備が必要のように思えてしまうかもしれませんが、実際はユーザーインタビュー程度の負荷で実施できるサイズにまで最小化することを推奨しています。言わずもがな、一番の理想は最小の実験で最大の成果（学びや発見）を得ることです。
Measure（計測）
実験を行い、十分なデータや情報は揃いましたでしょうか？ここからは結果を計測するステージに入っていきます。実験の方法を考え、実験する際に事前にまとめた実験そのものの背景や仮説に立ち戻り、仮説を実証・検証する際に重要となる要素を事前に整理しておきましょう。
実験の場では実際にどのようなことが置きましたか？結果からはどのように仮説を評価することができますか？得られた結果は仮説を実証・検証するにあたって十分でしたか？ここでのポイントは、先ほどの実験シートにまとめた事前に期待していた結果と事後に発生した結果の差分を、可能であれば定量・定性の双方の側面から比較することです。
最後に、定量・定性データを整理し、最終的にどのような現象が発生したのかをチームメンバーに理解していただくために、ストーリーテリングの要領でストーリーにまとめて学びや発見を形式知化できるように工夫しましょう。もちろん、すべての結果を参照し、レポート形式にする必要はありません。サービスとして、ないしはプロダクトとして最も大きな収穫に関するデータや情報のみに絞り、やがてチーム全体の学びへと発展し、次のステップへ自然につながるような流れを生み出すようにしましょう。
Learn（学習）
Frame-Build-Measure-Learn（構成-構築-計測-学習）の最後のステップで期待される効果は、更なる実験の構想が浮かび上がること、ないしは次のステップに進むためのアクションが自然と明確になることです。実験の前にまとめた仮説と期待していた結果を実際の結果と照らし合わせてみましょう。なにが起こりましたか？時間やリソースを学びや発見のために費やしたのですから、得られた学びや発見は何でしたか？その学びや発見は、次に向けてどのように活かされるべきですか？次のステップはなにからはじめますか？
Experiment Sheet（実験シート）に戻り、上記内容と結果をまとめてチームメンバーに共有しましょう。これは、次のステップ、学びを得るために費やされたコスト、結果から得られた洞察などを含みます。実際の実験結果よりも、記載した洞察や学びのほうが価値がある場合が多いためです。
最後に、学んだことや得られたことを透明性を維持してチームに浸透させるかのように振る舞うように心掛けてください。オフィス内のワークスペース周辺に関連資料や写真などを貼ってみましょう。難しければ共有スペースにでも配置し、他者がいつでも閲覧できるように工夫してアクセシビリティを担保してみてください。結果としてそれぞれの立場から得られた学びや発見を独自で解釈し、自信の業務に活かすことができますし、予想もしていない第三者からの助言や追加の学びを共有してくれる空気を創りだすことができます。学びが多ければ多いほど、良いプロダクトやサービスは生まれます。
もちろん、チームメンバーと共同で実験を進めることが理想です。もし、実験から得られた学びや発見をサービスやプロダクトに最大限活かしたいのであれば、構築や計測をする前に実験と課題の構成をしましょう。そのための、Frame-Build-Measure-Learn（構成-構築-計測-学習）です。スピードも去ることながら、不確実性が更に高まりつつある昨今、我々のこの先の未来はこの思考回路に委ねられているのではないでしょうか。
関連記事：
*1:This article is copyrighted by Rally Software Development Corp. Used with permission.
ExperienceFellow - カスタマージャーニーマップの自動生成ツール
ExperienceFellow（エクスペリエンスフェロー）というオンライン・ツールをご存知でしょうか？
THIS IS SERVICE DESIGN THINKING の著者 Marc Stickdorn氏と Jakob Schneider氏が共同で立ち上げたサービスで、一言で言えば「カスタマージャーニーマップの自動生成を可能にしてくれるツール」です（カスタマージャーニーマップとは？については「ユーザーエクスペリエンス・ジャーニーマップ」をご参考ください）。
ExperienceFellow とは？
ExperienceFellow が掲げているコンセプト「Research customer experience」が示す通り、被験者のエクスペリエンス（体験）を記録し、ジャーニーマップとして可視化するだけではなくチーム内でジャーニーマップを起点にコメントや洞察を登録・評価することができるサービスデザインのためのツールです。
ExperienceFellow の使い方
ExperienceFellow の使い方を説明します。
- 依頼者側がデスクトップのサイト上にプロジェクトを登録する。
- 被験者側がモバイル・アプリケーション上でプロジェクトに参加する。
- 被験者側がモバイル・アプリケーション上でエクスペリエンス（体験）を登録する。
- 依頼者側がデスクトップのサイト上でプロジェクトを終了する。
- 依頼者側のデスクトップのサイト上に反映された被験者の入力データを評価・考察する。
- 依頼者側が登録されたデータをジャーニーマップとして出力する。
ステップ1：依頼者側がデスクトップのサイト上にプロジェクトを登録する
先ず、依頼者側がプロジェクトと関係するメンバーをデスクトップのサイト上に登録します。
尚、当サービスが未だβ版ということもあり2014年12月度の利用料は無料となっています。今回は、僕のプライベート旅行で試験的に使用したデータを元に再現しています。
ステップ2：被験者側がモバイル・アプリケーション上でプロジェクトに参加する
プロジェクトが登録されると、今度は調査の対象となる被験者に情報を入力してもらうためのアクセスコードを QR コード形式で提供します。被験者は事前にインストールが必要な ExperienceFellow のモバイル・アプリケーション経由（2014.12.19時点では iOS のみ）で QR コードを読み取り、プロジェクトに参加します。
ExperienceFellow のアプリケーション内、被験者のモバイルデバイスにプロジェクトが登録されました。上記のキャプチャは既に使用済みのデータであるため幾つのデータが登録済みか、プロジェクトごとに表示されます。
ステップ3：被験者側がモバイル・アプリケーション上で体験を登録する。
プロジェクト登録後よりすぐに体験の入力を開始することができます。ここでは「NEW TOUCHPOINT」としていますが、「NEW EXPERIENCE」とラベルを編集することができ、被験者に取って自身の体験またはジャーニーの入力しやすさを考慮して依頼者側で選択できるようになっています。
タッチポイントごとの登録（＝NEW TOUCHPOINT）は被験者にとってサービス提供者側とのインタラクションを意識させなければいけないため、よりニュートラルな情報を得たいのであれば日記のような感覚で入力を促すことができる体験ごとの登録（＝NEW EXPERIENCE）が良いかもしれません。
入力画面は至ってシンプルです。体験した出来事を一行で記入し、5段階評価でその時の感情を選択します。
加えて、メモやその時の体験を記録するための写真やビデオなどのメディアファイルを添付することもできます。LOCATION（位置）機能はモバイル・アプリケーションのGPS機能がアクティベートされている場合のみ、位置情報が付与されます。
登録後には定期的に登録データを依頼者側のデスクトップサイト上に送るために同期する必要があります。
ステップ4：依頼者側がデスクトップのサイト上でプロジェクトを終了する。
プロジェクトの終了は依頼者側がデスクトップサイト上のダッシュボードで宣言することができます。
入力されたデータがダッシュボードに集約され、被験者ごとにデータを閲覧することができます。ダッシュボードでは総データ数、感情の平均スコア、簡易ジャーニーマップがサムネイルとして表示されます。
ステップ5：依頼者側のデスクトップのサイト上に反映された被験者の入力データを評価・考察する。
被験者ごとのデータを選択すると、入力したデータが時間軸で表示されます。
当画面では登録されたデータ（画像・ビデオ含む）を閲覧することができると共に、各データごとにタグやコメントを付与することができます。
例えばこの場合は感情の平均スコアがマイナスポイントとなっている時間帯は空港という場所に依存している可能性が高かったため、「Airport」というタグを付与しています。また、考えられる原因や改善点もあわせてコメントとして登録しています。
ステップ6：依頼者側が登録されたデータをジャーニーマップとして出力する。
以上の考察と評価は必要であれば行います。ExperienceFellow には常時 PDF へのエキスポート機能が搭載されており、被験者の入力データを基に可視化されたジャーニーマップを自動的に生成し、被験者ごとの出力やプロジェクトごとの出力が可能となっています。
まとめ
前述しましたが、ExperienceFellow は被験者のエクスペリエンス（体験）を記録し、ジャーニーマップとして可視化するだけではなくチーム内でジャーニーマップを起点にコメントや洞察を登録・評価することができるサービスデザインツールです。
なぜ、僕が ExperienceFellow に目を向けたのか？ExperienceFellow は以下の点で優れています。
- 時間的・物理的制限から開放される、リモート・エスノグラフィーが可能
- ユーザー（被験者）の生データを直接ジャーニーマップに反映することが可能
- ユーザーに負荷をかけず、コンテキストを破壊することなく日記感覚で入力を促すことが可能
- リモート環境下でも複数のプロジェクトメンバー間のコラボレーションが可能
尚、今回はセルフ・エスノグラフィの要領で自身の旅行体験を軸に依頼者側・被験者側の当サービスにおける検証を行ってきましたが、改めて、ユーザーセントリックに普段から行っているサービスデザイン業務における調査の信憑性や妥当性を証明することの大切さを学びました。
最後に、2014年12月一杯までは利用が無料です。試験的に、依頼者側としての参加となりますが ExperienceFellow を体験してみたいという方がいらっしゃれば、ぜひ下記「通勤体験の改善」プロジェクトにお気軽にご参加ください。
モバイル・アプリケーションは下記よりダウンロードが可能です。前述しましたが、現時点では iOS のみの提供となっています。
関連記事：
User Experience Journey Map - ユーザーエクスペリエンス・ジャーニーマップ - UXploration
サービスデザイン―無形をデザインする - UXploration
RE: UXの本質について
UI/UXという並列表記は基本的に信用しない。これは、長谷川さんと話していると良く話題に上がります。
UI/UXの並列表記問題
某中途採用の求人検索サイトで "UI/UX" と入力して検索してみたところ、900件以上の UI/UXデザイナーの求人が掲載されていました。職域や必要なスキルは実に様々で同一の枠を争っている様子があまり見られないことが特徴です。"UI/UX" という旬なキーワードを盛り込み、場合によってはすべてをお任せしたい、そんなミーハー感が漂っているようにも思えます。長谷川さんのブログでも「UXの本質」と題して言及されていますが、UI/UXという誤用の弊害のひとつに、課題意識を狭めてしまうことがあります。
UIについては、担当部門が責任を持つ、ということは可能だが、UXについては問題意識を持つ部門があることは必要だが、その解決には複数部門を巻き込んだアプローチが必要であり、少なくとも画面設計のパートだけでは解決は難しい。
すぐれたUXの実現のためには、プロジェクト全体で取り組む必要があり、グローバルに見てもその傾向は強まっている。
それが、UI/UXという表現によって課題意識を狭めてしまうのだ。
求人検索サイトに限らず自社の採用サイトでも、"UI/UX" の並列表記によって対象の企業が課題と認識している領域が明確になっていないことを自然と明示してしまっているのです。もちろん、900件以上の掲載の1部には的確な意思表示をされている企業もいましたが、丸投げとも言える姿勢を見せている企業は少なくありません。
もし、優れた UX の実現に主軸を置いているのであれば、特定の「UI/UX デザイナー」等という職種のみが取り組むべき内容ではありません。前述の課題意識が組織全体に行き渡っていなければ、例え UI/UX デザイナーの採用に成功したとしても様々な弊害によって価値が発揮しづらく長続きはしません。
ユーザーに中長期的な WOW（Long-Term Wow）を提供し、期待に応け続けるためには、組織も変革させていかなければなりません。そのための第一歩として、組織全員がユーザーと向き合うことからはじまります。
素晴らしい体験は、素晴らしい組織から
以前のブログでも論じましたがビジョン（戦略）からプランニング（構想）、ビルド（実行）に移すための組織内での立ち振る舞がなされない限り、戦略含む UX の構想は絵に描いた餅に終始してしまいます。"UI/UX" という並列表記に見る両者の溝は更に深まるばかりです。
いくらアイディアが素晴らしくても、それが実行されなければそのアイディアも無価値に終わってしまいます。エクスペリエンスの設計価値は、実践を通じなければ永遠に証明されません。自身の足元である組織上の課題には触れずに「表向き（UI）」の改善施策のみに留まってしまっているケースを多く見てきましたが、結果として優れた UX が実現されることとは必ずしもイコールではありません。
デザインとは、想いを単なる想いに留めてしまうのではなく、そのままカタチにすることなのではないでしょうか。ウェブサイトなどユーザーとの特定のタッチポイントに絞ってしまうのではなく、文字通り体験全体にまで視野を拡げる必要があります。組織そのものの最適化やオペレーションの見直しなど、組織全体の取り組みとして推進されるべきなのです。
ユーザエクスペリエンスと事業戦略
ユーザーに提供すべきモノやコトを組織の事業戦略の骨格として取り入れていく UX Strategy（UX戦略）の重要性が高まってきています。
ユーザエクスペリエンス・デザインないしは人間中心設計の前段となる事業戦略及び提供価値が不明瞭では企業またはサービスの差別化は図れません。ユーザーから考えていくことが常識になりつつも、Donald Norman も反論しているとおり、どの組織も同様のアプローチを展開してしまうと似たような製品がマーケットに出回ってしまい、工業化時代の再来とも言うべき、個々の提供価値がエンドユーザーに伝わりづらい状況下に陥ってしまいます。
[...] first, the focus upon humans detracts from support for the activities themselves; second, too much attention to the needs of the users can lead to a lack of cohesion and added complexity in the design.
優れた UX の実現には戦略をも含めた全体最適が不可欠です。UI/UX から連想される、個別最適による効果の最大化は小手先のみに終わってしまい、以降の改善に向けた原因の追求は足止めとなってしまいます。
ユーザーの体験は、対モノとの関係性によって成立するものではなく、ヒト対ヒトのコミュニケーションの連鎖によって成立するものだということを念頭に置くべきだと考えます。
まとめ
ほかにも長谷川さんが取り上げた、グッズ・ドミナント・ロジック（モノ主体）からサービス・ドミナント・ロジック（コト主体）へのパラダイム・シフトの背景が合い重なり、優れた UX の実現には組織を横断してビジネスに変革をもたらす必要があることを考えると、UX は単に UI と同列に扱われるべきではないことがお分かりいただけると思います。
当ブログではサービスデザインやユーザエクスペリエンス・デザイン、LeanUX、そして今回は UX戦略について言及してきましたが、UX を突き詰めると最終的には組織論に行きつきます。
入り口はそれぞれ違うかもしれませんが、ぼくは単なるバズワードとして終わってしまっても構わないと思っています。同じような取り組みが実際多くの企業または人たちの間で行われたはずで、目新しさがないかもしれません。ただし問題は、似たようなことが行われていても、必ずしも体系的ではないために途中で挫折してしまったり、実践者の我流で行われていたために、他の人には理解できずに社内では広がらなくなっていたと思います。
そういう意味では "UI/UX" という並列表記問題は結果として課題意識を再確認する良い問いかけだったのではないでしょうか。加えて、これまで取り上げた多くのコンセプトや手法体系が世に誕生しなければ、当記事で取り上げた問題の核心に近づくことはできず、ここまで拡張性のある話題は展開できなかったはずです。
最後に、UX の本質と題して話題を提供してくださった長谷川さんに感謝します。
関連書籍：
THIS IS SERVICE DESIGN THINKING. Basics - Tools - Cases ー 領域横断的アプローチによるビジネスモデルの設計
- 作者: マーク・スティックドーン,ヤコブ・シュナイダー,長谷川敦士,武山政直,渡邉康太郎,郷司陽子
- 出版社/メーカー: ビー・エヌ・エヌ新社
- 発売日: 2013/07/25
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
サービスデザイン ユーザーエクスペリエンスから事業戦略をデザインする
- 作者: Andy Polaine,Lavrans Løvlie,Ben Reason,長谷川敦士
- 出版社/メーカー: 丸善出版
- 発売日: 2014/05/01
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
