サービス開発のDailyTopic

サービスで価値を届けたい

【Design+】ブレストにおいて、短時間で精度の高いアイデアを選択するコツ

Lean UX監訳した坂田さんの主催する

「Design+」に参加して得た学びを紹介するコーナーです。 

designplus.amebaownd.com

 

ブレスト会うまくいってる?

ブレスト会を企画した時、

かなり時間がかかる上に、ふんわりした結論しか出ないときって多くないですか?

自分はそうでした。

 

自分では気づいてなかったのですが、

そういった時って、何一つアイデアを「捨てなかった」事が多いです。

全員のアイデアマッピング・グルーピングする所まではうまく行くのですが、

最後に「これをやろう!」という選択をする際に、残り時間の関係でトップダウンな決定になってしまうことが多かったです。

 

またアイデアの出す量や質にも、個々人で濃淡があり、

どうしても慣れてない方や、前段の知識量に差がある方が置いて行かれてしまい、実際は「想いのある人」だけのブレスト会になってしまうことが多かったです。 

そんなブレストの課題に役立ちそうなプラスをいただけたので、以下にコツを記載してみます。

 

ブレストにおいて、短時間で精度の高いアイデアを選択するコツ

  1. 発散:なんでもいいからたくさん出す

  2. 選択:思い切って捨てる

 

発散:なんでもいいからたくさん出す

ポストイットを用意して、アイデアを一個ずつ書き出してみる ときのコツです。

 

コツ1
  • とにかく手を止めない、なんでもいいからアイデアを出してみる
  • 8秒でポストイット1枚くらいのペースをイメージ
  • 精度は気にせず、とにかく数を出すことが大事。

 

コツ2 
  • 手が止まったら、なんでもいいから関係ない言葉を書く
  • イデアが出るまで同じ言葉を書き続ける
  • BANANAとかWASABIとかなんでもいいらしい

   

コツ3
  •  本番のブレストを始める前に上記の練習を皆でやってみる
  • 「犬の名前」や「ダイエットの方法」とかなんでもいい。
  • 関係ない話題で、考えずに書く練習をすることで、本番で手が止まりにくくなる。

 

 

まとめ

例えば、10分間ひとつのことを考えて出したアイデアより

10分間に30個のアイデアを考えた中のひとつのほうがクールなアイデアになることが多いらしいです。

自身も実際にやってみて、最後の2~3枚は自分でも思いついてなかった上に、クールだなと感じることが出来ました。

 

 

選択:思い切って捨てる

全体で議論を始める前に、自分のなかで選択と集中をすることで、議論の濃度が高まります。

 

コツ1
  • 自分が書いたポストイットを並べて、「良いもの」「そうでもないもの」を同数ずつ半分に分けてみる。
  • 半分に分け終わったら、「そうでもないもの」方のポストイット破って捨てる

 

コツ2
  • もう一度、自分が書いたポストイットを並べて、「良いもの」「そうでもないもの」を同数ずつ半分に分けてみる。
  • 今度は結構苦しくなるが、それでも分ける、そして「そうでもないもの」をまた破って捨てる。

 

コツ3

 

まとめ

半分に分けて捨てる、という行為を2回やるとかなりアイデアの精度が上がりました。

1度めは簡単に捨てられるけれど、2度めは優先順位をしっかりつけないと捨てられなです、

なので、自分の中で優先順位をつけることができ、皆に伝えるときには、何故オススメなのかがハッキリしていました

 

LEANに素早く意思決定して試すことが大切

ポストイット片手にブレストをするときは、上記のコツを思い出してやってみてはいかがでしょうか?

すごく短時間で、それなりの結論を出すことが出来ます。

その結論が合っているかは難しいですが、「試すことが出来るところまで、仮説を固められた」ということが大事で、

試してみてダメだったら、素早くもう一度同じプロセスを繰り返してみればいいのだと思います。

それがLEANな考え方なのだと感じます。

 

"禅"に学ぼうと思ったら、何も学べないことを学んだ

最近、自分の周囲で「禅」が流行っています。

 

困難なミッション、過度なプレッシャー、重視される人間関係、、、

コミュニケーションは日々複雑さを増し、

そこに必要なのは、まず自己を律する力、、、、、

 

きっと"禅"を学んだら、そういった自己を律する力が湧いて、そういった困難によりうまく付き合えると思っていました。

自分のレベルアップのために、”禅”を学びたいと考えていました。

 

しかしそんな時、同僚の禅Master(勝手に呼んでいる)の言葉がすごく胸に刺さりました、、、、

 

曰く「禅をやってみた、そしたらそこには何も無かった」

 

 

 

僕らは上記のような困難に立ち向かう時、

どうしても、本来の心の形を捻じ曲げたがります。

「苛立ってはいけない」

「言葉に気をつけなければいけない」

「相応しい立ち振舞をしなければならない」

 

見せかけの態度を変え続けていると

「本来の自分の心の形」と「目指す自分のあり方」

に差分が生まれて、

その”ねじれ”がストレスとなって自分の心に押しかかってくるんだと思います。

 

困難にぶつかったときは、

「自分を変えようと無理をする」のではなく

まず自分の「本来の心のあり方」を見据えてみたいです。

(きっとそこには何もなくて、ただ今の自分があるだけなのでしょうが)

 

 

世界を変えるには、まずは自分を変えなきゃいけない

自分を変えるには、まずは自分を知らなきゃいけない

 

ユーザーやチームや課題のことで日々悩むのもいいけど、

まずは、自分自身に向き合うところから始めようと思いました。

ゆっくりと頑張ります。

 

まぁいっか、とりあえず今日はビール飲もう🍺

【DESIGN+】信頼関係の3ステップが生む価値

DESIGN+という場でディスカッションした内容をまとめています!

f:id:tsuyoshi-osiire:20170304132957j:plain

f:id:tsuyoshi-osiire:20170304132959j:plain

f:id:tsuyoshi-osiire:20170304133001j:plain

f:id:tsuyoshi-osiire:20170304133003j:plain

f:id:tsuyoshi-osiire:20170304133005j:plain

f:id:tsuyoshi-osiire:20170304133007j:plain

 

デザイナーとしてだけではなく、サービスを作るチームのひとりとして

メンバーの課題から、世の中の課題まで、まるごと解決していきたいです。

「ユーザー調査」ってもっとカジュアルにならないかな?

ユーザー調査ってやったほうがいいの?

■ユーザー調査のないUXは、UXではない
非常によく考えられているデザインですら、実際のユーザーでテストするまでは仮説だ。様々な調査をすることで様々な疑問に対する答えは得られる。そうしたツールを理解し、使いこなそう。ユーザーを考慮しないことは選択肢に入らない。
 
■「ユーザーの声」を聞くと道を間違える理由
 
 
意識高い記事を読みながら、「ユーザー調査するべきだろうか」なんて話をしていると、
つい頭でっかちになってしまって、ユーザー調査はかくあるべき、とか、ユーザービリティとは、とかとか、、、
色々議論が発散して結局やらない。。ってこと多くないですか?
自分は多かったです、、、
 
そして、良く「UXを理解してくれない組織のせい」 みたいにしてしまっていました(;ω;)ダメダメや、、、
 
 

とりあえずやってみよう

自分みたいな駆け出しのUXデザイナーの皆様は、

「ユーザーの声聞いてみよう!」っと内なる声を聞いた時、

四の五の言うよりは、まずやってみたほうがいい!と最近の自分は思ってます!

 

この記事をみた後に、

メモ帳にでっかく「調査してみたい仮説」を書き出して、駅前に立ってみましょう。駅前がキツければ友達でもオカンでもいいです。

そして、声に出して質問してみましょう

使う時間は最短で30分くらいです。(やってみると、何だこんなものか?ッとなると思います。)

 

 

ユーザー調査を「カジュアル」な道具にしよう

これは自分の反省なのですが、
始めにユーザー調査の話をするときに、
考える時間が多くなりすぎ => 話が大きくなりすぎ => 結局やらない、、、
という負けルート入ってることが多かったです。
(インタビュールーム借りて?とか、サーベイを業者に依頼して?とか、予算はどうやって作って?、、、とか)
 

、、とは言え、いきなりそこら辺の話を始めるのって、「プロカメラマンになろう!」っと思って、いきなり露出補正とかホワイトバランスとかの、素人には難しい議論を始める感じに似てると思うのです。

もちろん実績のないカメラマンに高級な一眼レフを買い与えてくれる組織もないです(;ω;)

 

プロカメラマンになるためには、まず安いカメラを買ってイジって遊んで見て、

それでうまく行かなかったところを勉強してみる!ってのが良いんじゃないかなっと思う派です。

 

最終的には、「いい作品(サービス価値)作りたい!!!」ってことだと思うので、

もしかしたら、自分が作りたい作品(サービス価値)は、カメラ(インタビュー)じゃなくて筆(他の何か)で作ったほうがいい!ってなるかもしれませんが。。。

 

 

日常的に、ユーザーに耳を傾ける習慣をつける

近ごろ、多くの現場でユーザー調査が特別なものになりすぎている気がします。

実際は、良く人が「三年前の自分のデザイン(コード)ひでぇなー」、と思いながら成長していくように、日々使うことでより洗練されていくものだと思います。

 

予算がないとできない、上司の理解がないとできない、チームに必要とされてない正しい調査の仕方がわからない、、、

もちろん、プロフェショナルで大規模なユーザー調査も必要かもしれませんが、

考える→作る→学ぶ

の「学ぶ」の部分で、もっとデザイナーがカジュアルに使える道具になればなぁ、と思う今日この頃です。

批評(レビュー)で相手の120%を引き出すための3つの"プラス"

 以前、DESIGN+という勉強会に参加させていただき、ちょっと心に刺さった言葉があったので、その場での議論を元に自分なりにまとめてみました。

DESIGN+(デザインプラス) は、我々が普段扱う DESIGN にもう1つ発想をプラスする、ポジティブな創造活動に転換するなどと言った様々な「プラス」の要素を加えることで、DESIGN への新たな向き合い方を模索することを目的とした、 <人 / 声 / 知> が集まる「集合体」です。

  

誤った批評文化は「かけ算」を生まない

例えば、新しい企画を確認するとき、デザインモックを見たとき、コードレビューをする時、

誰かと一緒にモノづくりをする時に、必ず批評をすると思います。

その「批評をし合う」という文化は、非常に大切なもので、互いに批評し合える組織というのは、全てのベースになるものです。

 

しかし、

自分が正しいと思ったことをただ”そのまま”相手に伝えてしまっていませんか?

それでは、批評したの相手の能力を50%も引き出すことが出来ない、と自分は考えています。

(だからと言って、もちろん「本当に伝えるべきこと」を伝えないことは良くないことです。)

 

相手の力を120%に引き出しつつ、伝えるべきことを伝えたい。

そんなときは少しだけ以下のテクニックをプラスしてみませんか?

 

批評に3つの「プラス」をしよう

 

+思考にプラスする+

 相手を尊敬する

ここでの尊敬とは、"スキルの高低" や "出来の良し悪し" だけではありません。

相手とそのアウトプットは、必ず自分には無い素晴らしい魅力を持っているはずです。

まずはそこを見定めて、キチンと相手への尊敬の気持ちを持ちましょう。

 

尊敬の念には、相手と自分の関係をフラットにする力があります。

 

+言語にプラスする+

 「いいね!」でサンドイッチする

まず最初にそのアウトプットの一番いいところを探して、「いいね!」しましょう。

自分ならこうしたい!という気持ちぐっと我慢して、渾身のいいね!を贈ります。

その後ゆっくり自分の意見を述べます。

 

批評の最後も、「いいね!」でしめましょう

相手はあなたの意見を、ポジティブな気持ちでアウトプットに反映できるはずです。

 

+行動にプラスする+

相手の意見に傾聴する

批評をする上で、まず相手の意見をとっくりと聞く(傾聴する)ことが大切です。

 

その上でキチンと貴方の意見を「聞いているよ」と伝わるような行動をしてあげることは、意外に忘れがちです。(実はよーく聞いてる時ほど、ありがちです)

 

傾聴を伝える方法には「暗示的傾聴」と「明示的傾聴」の二種類があり、

暗示的傾聴とは、キチンと相手が話し終わって一拍置くまで待つ、など。

明示的傾聴とは、相手の言葉に頷く、オウム返しする、などです。

 

人は「自分が聞いてあげた量」より多くの言葉を聞いてくれない、、、と思っておいた方がいいでしょう。

  

批評の本質とはポジティブを生むこと

プロダクトづくりは、全てを自分では作れないが故にチームを組んで一つのミッションにあたります。

コラボレーションがあるから、一人では作れない大きな課題を解決できるのだと思います。

アウトプットの批評は、そのコラボレーションのひとつひとつの歯車です。

 

もしも貴方の批評がアウトプットそのものだけに向いてしまっているのだとしたら、

今回の「思想・言語・行動」を、少しだけプラスしてみましょう。

 

指摘内容を伝える + 相手の心をポジティブにする

そのことで、貴方と相手は「足し算の関係」ではなく「かけ算の関係」になれるはずです。

 

 

※補足

このプラスは、決して「いい人」になる方法ではありません。

前提として、必ず自分の意見は持ちましょう。

そしてむしろ、エゴイスティクに良いプロダクトを作ろうとするのであれば、仲間の力を200パーセント引き出して、共に新しい価値を届けましょう。

 

コラボレーションデザインについて、興味のある皆様にオススメの本はこちらです。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

デザインの伝え方

 

十二支に学ぶ、共通言語デザインの大切さ

今年もあと数時間で終わりですね。

鳥好きの自分は酉年の到来を心まちにしております🐣

そんな年の瀬にUXな小話をひとつ。

 

 

十二支に学ぶ共通言語の大切さ

皆さん、十二支って何のために生まれたかご存知ですか?

古くは中国の日付を表す記号だったそうです。

十二支は古く殷の甲骨文では十干と組み合わされて日付を記録するのに利用されている。 ~Wikipedia

それがなぜ12の動物たちに割り振られたかというと、、、、

単純に「庶民にも覚えやすいから

だったそうです。(諸説あります)

 

なんだ、つまらない理由だなっと思ったかもしれません、、、

そこで、この庶民にも覚えやすい共通言語、がいかに大切かという話をしようとおもいます。

 

 

もし時間を表す言葉が無かったら

「時間を共通の言語で理解しコミュニケーションをとる」という文化は、今や当たり前かもしれませんが、

今、身近な所だと、出社や退社、駅などの交通機関、電子機器のタイマーからデートの待ち合わせまで自然と幅広く利用されています。

 

これらの共通の言語が世界から無くなった時を想像してみてください。

現在の文化や利益は、この時間という共通言語に支えられていることに気づくのでは無いでしょうか?

 

サービス開発で必須な共通言語

一気に話のスコープをサービス開発に移しますと、

これはEric Evansの『ドメイン駆動設計』にあるユビキタス言語の例でも例えることができます。

 

つまりは、

「世界」という新規サービスを開発している最中、「日本」というドメインモデルの中にある「時間」という概念を「十二支」という共通のユビキタス言語とすることで、

「じゃ、酉の刻にローンチな!」という厳密な約束をエンジニアと企画職とが結ぶことができる。

ようになったわけです。

 

 

十二支という共通言語のデザイン

ここで、最初の話に戻るのですが、

ユビキタス言語は定義よりも、浸透させることの方が難しい

という事実は、つい忘れられがちな現実です。

 

これらの時間の概念に、身近な動物という分かりやすいアイコンをセットすることで、数百万人というリテラシーの低いユーザーに、共通言語として認知させることができた十二支は、

ある意味で、デザインの大きな成功事例だと感じます。

 

識字率も高く無かったであろう当時のユーザーにとってもユーザビリティの高い、十二支という新しいデザインは、相当にイノベーティブだったのでは無いでしょうか?

f:id:tsuyoshi-osiire:20161231143904j:image

十二支に猫がいないのも、当時の干支を設計したデザイナー(広義)達が、『猫は認知がまだ一般的でない』と検討した結果かも??

 

 

未来の理想に名前をつけよう

ぼくらの開発チームは、これから3年間で作り上げたいサービスの理想像を「蝶」というユビキタス言語で定義し、浸透させました。

 

これはチームが大きくなり、長期計画が複雑すぎて現場に浸透しにくい、という課題に対する、自分なりのアンサーでした。

(詳しくはいえませんが、蝶という言葉には、美しい姿になるにはサナギという耐える時期も大切だ、という比喩など。サービスに沿った様々な意味が込められています。)

 

つぎの1年はこの「蝶」という共通言語がサービス開発の中で、現実のものとして羽ばたいてくれることを夢見ています。

 

 

サービスをデザインをするために今年読んだ本【ベスト5】

今年も暮れになります。

自分にとって今年は”ただのデザイナー”→"UXデザイナー 兼 プロダクマネージャー”に成長しようと七転八倒した年でした。

まだまだ力不足ではありますが、今年サービスを作る上で「この本役に立った!」と思える本をご紹介します。

 

Team Geek

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

 

 自分はとてもギークとは呼べない人種ですが、それでも”モノづくりをする組織”として大切なエッセンスがギュギュギュ!っと詰まった本でした。

そのまま組織カルチャーの教科書としていいくらい、こういう組織を作りたい、こういう働き方で成果を出したい!。そう思える本です。必読。

 

UX戦略

UX戦略 ―ユーザー体験から考えるプロダクト作り

UX戦略 ―ユーザー体験から考えるプロダクト作り

 

サービスのUXについて、根底の哲学から実践的ハウツーまで広く通しで解説してくれています。

サービス作りを真剣に考えたとき、どなたでもまず読んでいただきたいです。

 UXデザイナーになりたい!そう思い立ち、この本を読んで中に書いてあることはだいたい全部試しました。結果、UXデザイナーの端くれを名乗ってもいいかな?というくらいには自信をつけることが出来ました。

 

デザインの伝え方

デザインの伝え方

デザインの伝え方

 

デザインとありますが、デザイナー以外にもおすすめです。

なぜなら、この本で語られているデザインは「デザイン=設計」であり、

"設計の意図を伝える"、"様々な意見を調整しアウトプットに落とす"、という文脈は、全ての職種に共通していると思います。

会議室に入る前の心構えの項は身につまされました。。。

 

 

今すぐ現場で使えるコンテンツストラテジー

今すぐ現場で使える コンテンツ ストラテジー ―ビジネスを成功に導くWebコンテンツ制作 フレームワーク+ツールキット

今すぐ現場で使える コンテンツ ストラテジー ―ビジネスを成功に導くWebコンテンツ制作 フレームワーク+ツールキット

  • 作者: ミーガン・キャシー,長谷川敦士,高崎拓哉
  • 出版社/メーカー: ビー・エヌ・エヌ新社
  • 発売日: 2016/04/21
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (1件) を見る
 

 正直、企画職用の初級者向けの本だと思いますが、

ただ「上流に携わりたいデザイナー」の中でも、実のところ上流の仕事をきちんと勉強したことのある人は少ないのではないでしょうか?

理解は共創の最初の一歩です、また読んでみると上記の「デザインの伝え方」とほぼ近しいことが書いてあることに気づけました。

 

 

ドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

 

デザイナーが食わず嫌いしそうな本ですが、読んでみるとデザイナーこそ読みたい良書でした。 

リーン等を勉強したデザイナーは、「あれ、聞いたことあるぞ」「共感できる」っとなる部分が多いのではないでしょうか?

また読んでみた結果、現場のエンジニアと共通言語で開発について語れることがこんなに有意義だとは思ってもいませんでした。

ただし、実装系の部分は読み込むと疲弊するのでお近くのエンジニアに「どこ読んだらいいかな?」っと聞いてみてください。

 

 

まとめ

サービスデザインといいつつ、デザイナー向け以外の本が多くなりました。

サービスデザインの本質とは、「如何にメンバーと共創していいプロダクトを生み出すか」だと感じます。

そういった意味で、他職種の言葉を知る他職種と同じ土台で会話するメンバーの掛け算を最大化する、ことが大事になるんだと感じた1年でした。

 

これからも、より広い目で、よりい大きなプロダクトを、より良いメンバーで作れるように日々精進していきます。