3/05/2015

[&] Design Sprint Night / DeNA & Cyber Agent



Design Sprint Night / DeNA & Cyber Agent
-------------------------------------
デザインスプリントを採用した方が良い5つの理由
DeNA デザイン戦略室 坪田さん

だいたいはブログに書いたので...
デザイン戦略室というところで、クリエーター全員が所属しているところです。
けっこうフェーズや案件によって、人が活用できる状況があるので、
横断組織で、一番パフォーマンスが発揮できるためにこういう構造で、
パワフルに動けるようにこういう組織になっています。

方法論、手法を大事にしていて、
スクラムも、アジャイルも、リーンUXも試しました。
これぞ!というのが見つからなかったのですが、
いいな〜と思ったのは、一連のサイクルとして設計されている。
かなり高速に回します。きちんとやりきった、前進している感があるので、
結構オススメかなら〜と

過去の問題
ビジョンは良くわかったけど、多くの場合、具現化フェーズでだいたい詰まる。
UI = サービスなので、チーム全員で指向する必要があるが、特定の人に負荷が集中しがち。
思考フェーズが長すぎると、スケジュールが押して、やり残しがある状態でリリースされる。

デザインスプリントが流行はじめ、うちでもやってみよう!と連絡したのがきっかけです。
一番いいな〜と思ったのは、モノづくり一番大事なのは、
作って壊して評価してを超高速で回転させたい。
半強制的にやっていけるのがいい。

1. アイデアの具現化からユーザーテストまでが一連の流れになっていてゴールが現実的
論理破綻が起きない。アイデアは良いが、実装を考えると論理が破綻するので、
つじつまを合わせる人が居る。目的の物が出来なくなる。現実的なゴールが設定され進むことができる。

2. 短い時間で可能性を出すよう設計されているので、全てのプロセスが高速に進む。
相当体力を使うが、早いのがいい。

3. 複数人でのブレストより、一人で考えた案を持ち寄る方が室の高いアイディアが多い

4. Silent Critique という手法で議決するので、声の大きい人に引っ張られない

5. 意思決定者を中心にベストなデザインを決定する手法もルール化されているので、
意思決定に納得感を持たせられる
意思決定の納得感が欲しい。

まずはやってみよう。
めっちゃ疲れます。
半日とかやってみると、やりきった感があるので、前進しているのでいいです。
特にエンジニアや、企画の人を巻き込んで、デザインをチーム全員で考えるようになればいいな〜

-----------------------------------------------------------------------------------------------
■ サイバーエージェント 大塚さん

HCD-net 専門家です。
現在はモックテックラボに所属、ラボ活動、新規ビジネス支援。

なぜ、デザインスプリント?にとびづいたのか?

ブレストで意見がまとまらず、延々と決まらない。
若いプロデューサー、意見の強いエンジニア、個性的なクリエーター
ブレスト後、結局限られた人数を集めて決める。
それ自身は一つの課程だとは思うが、二度手間、プロセスが見えない。

そもそも集まってくるメンバーが、それぞれ違う人種。
エンジニアは、早くつくって早く解決したい。
デザイナーはこだわりぬきたい。
数値的成果を求めるプロデューサー

ユーザーのことを考えて作る?
違う時間の使い方、違う考え方、違うユーザー像、認識がずれる。
みんな譲り合って、曖昧になる。自分のアイデアが捨てきれずモヤモヤ。

確認できるのは、ユーザーにぶつけた時。
ユーザーテストはたいがい、開発の終盤。
終盤だとおおきな問題が解決できない。
動的プロトを作ってテストしたいが、
どのタイミングで?作るのも結構大変。

デザインスプリントで解決できるかも?
社内で勉強会を開いて頂いて、僕自身もプロジェクトの中でやってみました。

-----------------------------------------------------------------------------------------------
Q. ファシリテーターは必要だと思いますか?
A. 必要だと思いますが、チームメンバーの誰かでいいかな?と
何回かやって経験した方がうまくいくと感じたので、
そういう役職が必要なわけではないが、そういう経験者が居た方がスムーズにすすむ。
タイムキープとかが大事、場を持たせる意味でも誰かが音頭をとってやるのがいい。

Q. どのへんが難しい?
A. 一番難しいのは理解してもらう。
エンジニアがデザイナーと一緒にやるとき「下手だし」と、
手を動かすのが大事なので、上手じゃなくてもいいという雰囲気作りが大事。
難しかったところは、時間の調整をコントロールするのが大事。
新規のプロジェクトだと全メンバーがフルコミットですが、
通常のプロジェクトだと運用があるので難しい。

専門性があるのはうまくいかない。
集まったメンバーの情報の知識度によってスプリントが変わってくる。
Day1 の理解を吸収できるぐらいじゃないとうまくいかない。

Q. 5日版?短縮版?
最初は 5日間、最初は 5日間でしたが、次は 2週間で1回などに調整しました。
新規は5日間、運用案件は全員は難しい、
フレームワークの途中途中では人が抜けてやるのが現実的

Q. ファシリテーターはどの立場の人がやるのが望ましい?
A. これは難しい。チームによって違う。
意思決定者がファシリテーターにやるのではない。
場を和ませる人がやっていく。
中立的な人の方がやりやすい印象がある。
デザイナーは意見を出したりするところに集中するべき、
責任者がやってしまうと、その人の意見になってしまう。

Q. ファシリテーターになれる人?なれない人がいる?
A. 全員が慣れる、やる文化があるといい
しゃべっていて明るいタイプでないのに出来ているので、全員できる

Q. 大手企業で、採用してもらうには一苦労?
A. 採用してもらうには一苦労?声の強い人、意思を持ってやるのは難易度が高い。
デザインスプリントと名前がついているのでデザイナーのようなものにみえるが、
サービスデザインは全員を巻き込んで、プロセスを共有するのが大事、
それをまず理解してもらう。
それはチーム、人にもよるのですが、プロデューサーが意思決定権をもちがち、
一回でも巻き込めば、印象とか意思決定が変わってくるので、まずそれがハードル

やる意味あるの?で説得するのが辛い。
なんとも言えない。切り口は、5日間のスピード間は、
他の手法よりも切り口としては、入りやすい。
ユーザーを巻き込んだフローは面倒、振り回されそう、
5日間と言い切ってしまうと、踏ん切りがついてします。
そういうのを切り口にやっていく。

Q. 実際にやってみて、オリジナルに忠実にやっていますか?改造していますか?
A. デザイン、プロトタイプのプロセスは全員でやるのはハードルが高いので、
デザイナーとか、多少できそうなメンツに絞ってやっています。
いったんフレームワークにそってやりつつも、
抜ける人も居るので、すこしづつオリジナルでやっていっています。

Q. デザインスプリントをやったあとで post-デザインスプリント、レビューとかやっていますか?
A. いまのところ無いです。考える暇も無く作り続けるのが良いです。
評価が反省になっていると思いますが、企画が合ってなかったからかえようとかも
評価の段階でやっています。
KPT を一週間単位でやっているのでその時に一緒に。
デザインスプリントを続けるものではないので、固まってきたら、
デザインをリファインしたり、実装しはじめたり、そこが難しい。

Q. お互いに質問したいことがあれば。

社内の反響は?
そんな浸透しきっていないのですが、ブログ書いたりして、
外堀から埋めていく。外から評価されるものをやってみたいとなる。
外堀を固めて、それを武器として。
最近は興味のある人が増えてきた。

まったく同じです。
外でデザインスプリントの話題が増えたら。

どうやって偉い人に理解をもらっていますか?
ある程度社歴が長いので、会話から。説得するのはあんまりしていない。

エンジニアの人も抵抗感無く?コードを書くのに集中したい。
新規の案件で、最新の手法でやろうよ!というのは受け入れられる。
動いているプロジェクトはいつまでもやってられないとなる。

手法をチームとして合意しても、工数を見積もるとリリースに間に合わないとか。
結局妥協案..... どうやって解決してくのか。

プロジェクトによる、クオリティを求めているのはスケジュールをずらす判断。
たいていは調整しないと、厳しい。
逆にプロセスをやり続けてしまうと、後で軋轢がでてしまって問題になってしまう。
臨機応変にやるといいのかな。

Q. エンジニアの人に抵抗がある。
やられた後の感想は?
実際メッチャいいです。
なんでこういうデザインにしたいのか?背景が最終グラフィックスだけであれば
伝えきらない。
UI設計プロセスは他職種には見えにくい。最終物が全てなのですが、
大変さが伝わって、考え方が変わったり、
UIの動きとかも考えられる意識がついた。

エンジニアの反応が良くて、
プロセス自体が面白い、UIが一緒に考えられるのがいい。
オーナーとデザイナーとシンクロできるのが大きい。
UIのプロセスはエンジニアから見るとわからない。
なんでこうなっている?最初の段階から吐き出せて
皆が考えていることが吸収できるのが良いところ。