22日目のエントリーです。ここまでサービスデザインスプリントのことを書く人がいない感じだったので、テーマとして選んでみた。最近ずっと考えているフレームワークと問いの関係を切り口に、そのあたりの観点で書いてみたかった、というのもある。考えながらちまちまと書き足していたら長くなってしまったけど、別記事に分割しちゃうよりひとつの記事にまとめておきたい内容なので、長くてもこのまま出しちゃう。各セクションの見出しは以下の通りなので、つまみ読みしていただくのもよいかと。Sprintの違い問いの観点でデザインスプリントを見るサービスデザインとは、問いながら前に進むことサービスデザイナーの役割はアブダクションサービスデザインのためのスプリントとはデザインスプリントとは、いかに短期間でできるだけ能動的にプロダクトやサービスに関する学びを得るかを追求したフレームワークである、と言って差し支えないだろう。Hivelabが事業展開(日本ではニューロマジックさんが提供)しているが、フレームワークとしてはオープンソースで展開されている。日本でも時々認定マスター育成のためのワークショップが開かれていて、私も末席ながら認定証を持っていたりする。Sprintは、ビジネス上のサービスエクスペリエンスを進歩させるため、デザインシンキング、サービスデザイン、リーンスタートアップのメソッドをミックスして生まれたもの。カスタマー、従業員、マネージャー、デザイナーが共に奮闘して成果を上げるための共創の枠組を提供しているとも言える。Sprintでは、以下のフレームでスプリントのサイクルを回してゆく。GVのデザインスプリントでは、以下の5つのプロセスを経る。Unpack:共有と発見(全員が共通認識を持つ)Sketch:スケッチ(具体的な解決案を作成する)Decide:決断(アイディアを選別する)Prototype:プロトタイプ作成(テストできる試作品を作る)Test:テスト(実際にユーザーテストをする)デザインスプリントにしても、その背景にあるリーンスタートアップにしても、成功への近道を保証するメソッドという捉え方ではなく「急がば回れ」的に捉えておくとちょうどよさそうに思っている。Sprintの共通点ざっくり言うと、どちらもリーンスタートアップのサイクルの中から、アイディア発想と検証のみに特化した形でプロセスを凝縮したもの。大きく以下の3つの要素が共通しているのではないかな。Sprintの違いこれについてはいろいろな見方があると思いつつ、以下の2点は必ず挙がるポイントと言えそう。Sprintにはシナリオ・プランニングやフューチャーランゲージのエッセンスが(ダイレクトにではないが)入ってくる点。最近ではもっぱら、それが2つのデザインスプリントの最大の違いになり得るなんじゃないかな、という見解に立って見るようにしている(個人の見解です)。Sprint(長いので以下GVDS)も、よくよく実践していくと、肝は「問い」にこそあるとしか思えなくなってくる。知ることと問いを立てることは背中合わせだ。We?」という問いの形が埋め込まれている。HMWでは、自問自答型で課題のポイントを記述し、発想につなげていく。スプリントマスターにとって、サポートしがいのある部分でもあるだろう。HMWは実はとても難しいプロセスで、何度やっても問いの粒度コントロールに苦労する。問いのデザインスキルにおいて、非常に高いレベルが要求されると言い換えてもいい。問いを適切な粒度に分解する必要があり、切り口の自由度が高い代わりにクリティカルな着眼点が必要なのだ。SDSの場合、「HUMANIZE」と呼ばれる調査フェーズがすべて問いで構成されている。ワークシートは問いの詰め合わせのようなもので、問いのバリエーションでいえばGVDSよりSDSのほうが多い。問いの分解、問いの逆算、問いの視座移動、そういった切り口すべてが詰め合わされている。全部入りであるがゆえに、パッケージとしてフレームワークを見たときには重く感じる、というデメリットもあるかもしれない。先ほど2つのデザインスプリントの共通点について触れたが、問いかたを間違えるだけですべてが無駄になるという点も追加できるだろう。逆に共通点から対策を考えるとするならば、ショートカットのために問いの絶対数を増やす優先順位を決めるために必要な問いを活用する多様なバックグラインドの人が答えることができる形の問いを用意するなどが挙げられるのではないだろうか。サービスデザインとは、問いながら前に進むことデザインスプリントについて整理しながら、そんなこんなを考えている昨今、サービスデザインとは「問いながら前に進むこと」でしか実践できないのではないかという気持ちになっている。予定にはなかったのだけれど、せっかくアドベントカレンダーに参加しているのだから、他の参加者の内容に乗っかってみるのもおもしろいかなと思い、18日目の中村さんの記事、2日目の井登さんの記事からそれぞれすこしだけ引用する。この本を読んでると、この人はリーンスタートアップは大嫌いなんだろうなあというのがひしひしと感じられる。ユーザーが「片付けるべき仕事」さえちゃんと明確になればあてずっぽうにMVPなど作らんでよろしい。失敗などたくさんする必要ないというのが彼の主張です。Ulwickつまり「今最も片付けるべき仕事は何か?」という問いが重要ということではないだろうか。クリステンセン教授がいう、この「片付けるべき仕事」こそが、前述したサービスデザインにおいての「ニーズにすらまだなっていない状態の“本当に解決したいこと”」と同じことを指しているのではないしょうか。「誰が、何を、解決したいのか?」ではなく、「なぜ、解決したいのか?」こそが重要なことである、ともいっています。イノベーションを生み出すための面倒だけど数少ない確実なやりかた(サービスデザインとジョブ理論との交差点)問いの深度でいえば、最も深いところを問われている。誰もがすぐに完璧な答えを出せるわけではない問いでもある。それが重要なことは理解できるけれど、じゃあ具体的な一歩目、取っかかりの問いをどう見つけるのか、という疑問が出てくるはずだ。逆のはしごを降りるプロセスにも似ている。問いの粒度をコントロールすることは非常に難しいプロセスだし、結局はそれが難しいから「すばやくたくさん失敗しよう」という話に戻ってくるのではないだろうか。サービスデザイナーの役割はアブダクションここまでスプリントについて取り上げておいて、まるではしごを外すような持論になるが、私はサービスデザイナーの仕事はフレームワークに含まれない部分にこそあると考えている。サービスデザインスプリントは、あくまで共創や協働のために有効なしくみであって、答えを出してくれるしくみではない。その中での「デザイナー」の役割は何か。「デザイナー」は何をすべきか。それがフレームワークをなぞることでないというのは明白だ。漠然とファシリテートすればいいということでもない。フレームワークの中で、サービスデザイナーが職能として発揮するべきスキルのひとつは、しくみ内のどこにも明示されないアブダクションの領域だと思う。たくさんのインサイトの中から、何を見つけてどこに飛ぶのか。飛ぶ方向がプロジェクトの在りかたそのものになる。サービスの改善なのか、いわゆるイノベーションってやつなのか、飛びたい方向に向かって飛べばいい。アブダクションを導き出すこと。今のところは、自分の中でそれが「サービスデザイナー」の重要な役割および職能だと定義付けておきたい気持ち。22日目のエントリーでした。滅せぬもののあるべきか。日々はなうたを歌いながら、最期を迎えるその日まで、うぬらと共に楽しく暮らす。Yamagishiひとことメモ最近とても消極的な理由ではてなブログに引っ越してきました。Hitoyam.スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。