蠍は留守です考

蠍の輪郭を見つめてふける思惟の痕跡

20170509013806

サービスデザインスプリント再考 ――「問い」の観点より

この記事はこまどりさん主宰の Service Design Advent Calendar 2017 22日目のエントリーです。

ここまでサービスデザインスプリントのことを書く人がいない感じだったので、テーマとして選んでみた。また、最近ずっと考えているフレームワークと問いの関係を切り口に、そのあたりの観点で書いてみたかった、というのもある。

考えながらちまちまと書き足していたら長くなってしまったけど、別記事に分割しちゃうよりひとつの記事にまとめておきたい内容なので、長くてもこのまま出しちゃう。長くてごめんなさい。各セクションの見出しは以下の通りなので、つまみ読みしていただくのもよいかと。

  • サービスデザインのためのスプリントとは
    • Service Design SprintとGoogle Ventures Sprintの共通点
    • Service Design SprintとGoogle Ventures Sprintの違い
    • 問いの観点でデザインスプリントを見る
  • サービスデザインとは、問いながら前に進むこと
    • サービスデザイナーの役割はアブダクション

サービスデザインのためのスプリントとは

デザインスプリントとは、いかに短期間でできるだけ能動的にプロダクトやサービスに関する学びを得るかを追求したフレームワークである、と言って差し支えないだろう。

f:id:hitoyam:20171222191038j:image

今回取り上げたいのは、Service Design SprintHivelabが事業展開(日本ではニューロマジックさんが提供)しているが、フレームワークとしてはオープンソースで展開されている。日本でも時々認定マスター育成のためのワークショップが開かれていて、私も末席ながら認定証を持っていたりする。

Service Design Sprintは、ビジネス上のサービスエクスペリエンスを進歩させるため、デザインシンキング、サービスデザイン、リーンスタートアップのメソッドをミックスして生まれたもの。カスタマー、従業員、マネージャー、デザイナーが共に奮闘して成果を上げるための共創の枠組を提供しているとも言える。

Service Design Sprintでは、以下のフレームでスプリントのサイクルを回してゆく。

  • Projection:調査(歴史的なコンテキストとユーザープロファイルを知る)
  • Perspectives:ユーザー定義(ユーザーのメンタルモデルやふるまいを知る)
  • Playground:発想と実験(共創でアイディアを考え、プロトタイプを作る)
  • Polish off:仕上げ(ユーザーテストを行い、実装の優先順位を決める)

よく比較されるのは、Google Ventures が提供する Design Sprint。GVのデザインスプリントでは、以下の5つのプロセスを経る。

  • Unpack:共有と発見(全員が共通認識を持つ)
  • Sketch:スケッチ(具体的な解決案を作成する)
  • Decide:決断(アイディアを選別する)
  • Prototype:プロトタイプ作成(テストできる試作品を作る)
  • Test:テスト(実際にユーザーテストをする)

デザインスプリントにしても、その背景にあるリーンスタートアップにしても、成功への近道を保証するメソッドという捉え方ではなく「急がば回れ」的に捉えておくとちょうどよさそうに思っている。

それぞれのデザインスプリントのイメージ図

Service Design SprintとGoogleのDesign Sprintの共通点

ざっくり言うと、どちらもリーンスタートアップのサイクルの中から、アイディア発想と検証のみに特化した形でプロセスを凝縮したもの。大きく以下の3つの要素が共通しているのではないかな。

  • 実装と測定をショートカットして、ラピッドにプロトタイピングを行う点
  • やるべきことの優先順位を決めて実装までつなげる点
  • 多様なステークホルダーとスキルセットを同じ場所に集めて、協働する点

Service Design SprintとGoogleのDesign Sprintの違い

これについてはいろいろな見方があると思いつつ、以下の2点は必ず挙がるポイントと言えそう。

  • フォーカスがプロダクトにあるのか/サービスなのか
  • HCD的アプローチの強弱(ユーザー像を起点にしているかどうか)

もうひとつ自分の中で考えている違いは、Service Design Sprintにはシナリオ・プランニングやフューチャーランゲージのエッセンスが(ダイレクトにではないが)入ってくる点。最近ではもっぱら、それが2つのデザインスプリントの最大の違いになり得るなんじゃないかな、という見解に立って見るようにしている(個人の見解です)。

問いの観点でデザインスプリントを見る

Service Design Sprint(長いので以下SDS)とGoogleのDesign Sprint(長いので以下GVDS)も、よくよく実践していくと、肝は「問い」にこそあるとしか思えなくなってくる。知ることと問いを立てることは背中合わせだ。

わかりやすい例として、GVDSには「How Might We?」という問いの形が埋め込まれている。HMWでは、自問自答型で課題のポイントを記述し、発想につなげていく。スプリントマスターにとって、サポートしがいのある部分でもあるだろう。

HMWは実はとても難しいプロセスで、何度やっても問いの粒度コントロールに苦労する。問いのデザインスキルにおいて、非常に高いレベルが要求されると言い換えてもいい。問いを適切な粒度に分解する必要があり、切り口の自由度が高い代わりにクリティカルな着眼点が必要なのだ。

一方、SDSの場合、「HUMANIZE」と呼ばれる調査フェーズがすべて問いで構成されている。ワークシートは問いの詰め合わせのようなもので、問いのバリエーションでいえばGVDSよりSDSのほうが多い。問いの分解、問いの逆算、問いの視座移動、そういった切り口すべてが詰め合わされている。全部入りであるがゆえに、パッケージとしてフレームワークを見たときには重く感じる、というデメリットもあるかもしれない。

先ほど2つのデザインスプリントの共通点について触れたが、問いかたを間違えるだけですべてが無駄になるという点も追加できるだろう。逆に共通点から対策を考えるとするならば、

  • ショートカットのために問いの絶対数を増やす
  • 優先順位を決めるために必要な問いを活用する
  • 多様なバックグラインドの人が答えることができる形の問いを用意する

などが挙げられるのではないだろうか。

サービスデザインとは、問いながら前に進むこと

デザインスプリントについて整理しながら、そんなこんなを考えている昨今、サービスデザインとは「問いながら前に進むこと」でしか実践できないのではないかという気持ちになっている。

もともと予定にはなかったのだけれど、せっかくアドベントカレンダーに参加しているのだから、他の参加者の内容に乗っかってみるのもおもしろいかなと思い、18日目の中村さんの記事2日目の井登さんの記事からそれぞれすこしだけ引用する。

この本を読んでると、この人はリーンスタートアップは大嫌いなんだろうなあというのがひしひしと感じられる。そうははっきりと言ってないんだけど。ユーザーが「片付けるべき仕事」さえちゃんと明確になればあてずっぽうにMVPなど作らんでよろしい。失敗などたくさんする必要ないというのが彼の主張です。

書評|ジョブ理論のオリジナル『Jobs To Be Done』by Anthony W. Ulwick

つまり「今最も片付けるべき仕事は何か?」という問いが重要ということではないだろうか。

クリステンセン教授がいう、この「片付けるべき仕事」こそが、前述したサービスデザインにおいての「ニーズにすらまだなっていない状態の“本当に解決したいこと”」と同じことを指しているのではないしょうか。「誰が、何を、解決したいのか?」ではなく、「なぜ、解決したいのか?」こそが重要なことである、ともいっています。

イノベーションを生み出すための面倒だけど数少ない確実なやりかた(サービスデザインとジョブ理論との交差点)

問いの深度でいえば、最も深いところを問われている。誰もがすぐに完璧な答えを出せるわけではない問いでもある。それが重要なことは理解できるけれど、じゃあ具体的な一歩目、取っかかりの問いをどう見つけるのか、という疑問が出てくるはずだ。

それはHMWの粒度を砕くプロセスにも似ているし、デザインリサーチ手法である上位下位関係分析法の逆のはしごを降りるプロセスにも似ている。問いの粒度をコントロールすることは非常に難しいプロセスだし、結局はそれが難しいから「すばやくたくさん失敗しよう」という話に戻ってくるのではないだろうか。

サービスデザイナーの役割はアブダクション

ここまでスプリントについて取り上げておいて、まるではしごを外すような持論になるが、私はサービスデザイナーの仕事はフレームワークに含まれない部分にこそあると考えている。

サービスデザインスプリントは、あくまで共創や協働のために有効なしくみであって、答えを出してくれるしくみではない。その中での「デザイナー」の役割は何か。「デザイナー」は何をすべきか。それがフレームワークをなぞることでないというのは明白だ。もちろんただ漠然とファシリテートすればいいということでもない。

フレームワークの中で、サービスデザイナーが職能として発揮するべきスキルのひとつは、しくみ内のどこにも明示されないアブダクションの領域だと思う。たくさんのインサイトの中から、何を見つけてどこに飛ぶのか。飛ぶ方向がプロジェクトの在りかたそのものになる。サービスの改善なのか、いわゆるイノベーションってやつなのか、飛びたい方向に向かって飛べばいい。

問うこと。アブダクションを導き出すこと。今のところは、自分の中でそれが「サービスデザイナー」の重要な役割および職能だと定義付けておきたい気持ち。

この記事はこまどりさん主宰の Service Design Advent Calendar 2017 22日目のエントリーでした。


参考リンク

Copyright © Hitoyam.