デザインスプリントを活かすチームの在り方
こんにちは。デザイナーのえんあかです！
先日、こちらのViViViTさんのイベントに登壇させていただいたので、その際にお話した内容をこちらで公開しようと思います。
デザインスプリントのブラッシュアップがテーマということで、、私からは、「デザインスプリントを活かすチームの在り方」というタイトルでお話いたしました。
デザインスプリントが上手くいかないと、真っ先にプログラム改善を考えがちですが、もしかすると、チームの体制や姿勢が要因になってるかも？。違う視点からデザインスプリントを捉えてみました。
デザインスプリントとは？
デザインスプリントは、プロダクトデザインのためのフレームワークです。
デザインスプリントには、以下のようなメリットがあります。
特に、「2. 検証まで行うことで、失敗を未然に防ぐという成功を得られること」。検証で期待した結果が得られないと、今回のデザインスプリントは失敗だった、を思いがちですが、リリース前に気づけた、コストやリソースを無駄にせずに済んだ、と考えるとそれだけで成功であると言えると思います。
ではデザインスプリントをどのように活用すればいいか？、プロジェクトのフェーズごとに分けると、以下のように用いるのが効果的です。
逆に、デザインスプリントに向いていないこと、それは革新的なアイデアを生むということです。そもそものプロダクトのコンセプトやコアバリューだったり、そのプロダクを利用するフックになるようなコア機能の検討など。
デザインスプリントはどちらかというと課題解決型のアプローチの側面が大きいので、0>1で新規事業のアイデアを考える、みたいなものは向いてないと感じてます
チームでどのようにデザインスプリントを導入してたの？
実施したプロダクト
次に、実際にどの様にデザインスプリントを導入していたのかについてお話します。いくつかのプロジェクトで実践してきたのですが、今回はmiattoというプロダクトで実践事例をお話します。（2024年1月にサービス提供終了しております。）
miattoは仲の良い友達ともっとつながろうをコンセプトにした、少人数SNSです。ターゲットは10代後半から20代前半の固定の仲良しグループがある学生。位置情報を使ってお互いの今いる場所をシェアしたり、トークルームなどでおしゃべりしたりできるサービスでした。
miattoでは3ヶ月から半年に1回の頻度でデザインスプリントを実施していました。
特徴としては、理解から〜決定までのプロセスを2日に短縮して実施、以降のプロトタイプから検証までは後日実施、という形を取っていたこと。
なぜこのようなプロセスになったのか、それは過去のプロジェクトでの反省が生かされた結果だったりします。
SNSの検証の難しさ
以前、別のSNSの新規プロジェクトでデザインスプリントを行ったときの話です。
SNSのプロトタイプを作ろう、短期間で動くプロトタイプ、というのは当時のチーム構成では難しかったため、私がFigmaで作成し、それをターゲットユーザーに触ってもらうことに。ユーザーの趣味嗜好に合わせていくつかのプロトタイプを用意しました。
それらのプロトタイプを初期ターゲットの学生、約30名に触ってもらうと、約70%ぐらいの学生が使ってみたいという良い評価をくれました。これは行けそう！と正式に実装し、リリース！
しかし、想定とは異なり、リリース後、思うように数字は伸びず…。
今回用意したプロトタイプでは、「実際に自分が使ったら」というところまで体験の解像度を上げられなかったのが課題だったと反省しました。
このことから、SNSの検証の確度を上げるためには以下の要素が重要だと学びました。
1つが、実際の自分の人間関係や趣味嗜好が反映されていること、自分としてその世界に入ることが重要です。
もう一つが自分の生活サイクルの中に取り入れてもらうこと。ある程度の期間使ってもらって、最終的に暇な時に無意識に開いてもらえるまでになっているか？が重要な判断基準になると思います。
これらを考慮すると、まずは既存ツールで条件を揃えて疑似体験できないかを検討し、難しそうであれば、最低限のMVPを実装して検証に回しちゃったほうが速いという結論に至りました。
SNSにおける理想のプロセス
以上の経験から、私がSNSにおけるデザインスプリントの理想のプロセスがこちらです。
２日間で理解から決定までを行い、2週間ぐらいでMVPを実装し、リリースして検証が最適解ではないかと思っています。
初期フェーズでまだユーザー数がいない状況であれば、リリースしてしまったほうが速いと思いますが、すでにユーザー数がいるプロダクトであれば、一部ユーザー向けにβ版として検証っていうのも良いと思います。
デザインスプリントでどんな問題が起こったの？
デザインスプリントのプロセスは分かりました、じゃあ実際導入してみて、どんな問題が起きたのか？チームがぶつかった壁、それがこちら。
ありきたりなアイデアに着地している気がする問題
みなさんもデザインスプリントに限らず、ワークショップなど実施して、こんな経験ないですか？時間かけて議論したけど、出たアイデアがそこまで目新しさがない。あれ？やった意味あったかな？
そうなると真っ先に思うのが、
デザインスプリントのプログラムを見直そう！
だと思うのですが、ちょっと待ってください。本当にそうなのでしょうか？実は他に要因があるかもしれないです。
miattoのチームで振り返ったとき、実はプログラムではなく、チームの在り方がデザインスプリントを活かせていない要因かもしれないと気づきました。
具体的にどんなチームの要因が影響していたのか、またどんな方法で解決したのかをお話します。
ありきたりなアイデア着地問題にはいくつかの要因がありました。
要因1：デザインスプリントに意思決定者が不在
チーム体制の問題
miattoのチーム体制はこんな感じでした。
プロジェクトの進め方ですが、意思決定者のPOが他プロジェクトと兼務のため多忙。なので、主にPOとPMがメインでコミュニケーションを取り、PO以外のメンバーでデザインスプリントを実施し、具体的な施策やMVPの要件を検討していました。
そもそも短時間で意見を収束させなければいけないという、デザインスプリントの難しさがあります。
時間を意識するあまり、意見の収束が優先になり、衝突を生むような尖ったイデアは言い出しにくくなる。結果、目新しいアイデアも生まれにくくなります。
なので、デザインスプリントの中で意思決定者が議論の方向性を示してくれることはかなり重要で、メンバーもそれがあるからこそ、自由に発言しやすくなります。デザインスプリントでも、意思決定者の参加はマスト要件として定義されています。では、どう解決するか？
解決策1：理解フェーズには参加してもらう
解決策1としては、デザインスプリントも全体参加が難しい場合は、冒頭の理解フェーズだけでも参加してもらうことです。
理解フェーズは今回のデザインスプリントの戦略や目的、今回のスコープをすり合わせる大事な部分なので、そこを意思決定者であるPOとメンバーですり合わせることで、以降のフェーズでも意思決定の指針にすることができます。
解決策2：権限を分割し、オーナーシップを取りやすくする
メンバー構成が20代後半がメインという若手メインのチームだったこともあり、全員の権限がフラットで、意思決定はみんなで決めよう、というスタイルでした。
全員で決める、言葉だけ聞くと良いようにも聞こえますが、裏返せば、それぞれの権限の範囲が決まっていないので、自分の意見をどこまで押していいのか迷う、結果オーナーシップが取りづらくなっていました。
そこで、機能ごとにユニットというチームに分け、それぞれでスプリントを回す、というスタイルに変更しました。
担当機能という範囲が決められたことで、意思決定もしやすくなり、またフレームワークもデザインスプリントに限らず、それぞれのユニットや機能にあったフレームワークを選ぶこともできるようになりました。
要因2：参加メンバーの多様性が欠けていた
ありきたりなアイデアに着地してそう問題、2つめの要因が、参加メンバーの多様性が欠けていた、という点です。
デザインスプリントを実施していたメンバーは、ディレクターやエンジニア、デザイナーと、一見、多様性があるメンバーに見えますよね。
実は、参加メンバーはみんなプロダクトを作る側の人たちだけだったのです。
作り手のメンバーは、どうしても作ることに集中するので、視野が狭くなりがち。また思考も似てくる傾向があり、アイデアの多様性も出にくいです
参加メンバーの多様性、どう解決するか？
解決策：チームに違う視点のメンバーを入れる
ポイントは違う職種ではなく、視点が違うメンバーを入れるということです。
進捗管理がメインのPMやデザイナー、エンジニアはプロダクトを作る人なので、制作者の視点で捉えています。一方で、POやアナリスト、マーケティングなど プロダクトを指揮する人は、市場やデータなどを見て、プロダクトを客観的な視点で捉えています。QAやカスタマーサポート、ターゲットユーザーに近い学生インターンは、ユーザーに近い視点でプロダクトを捉えていたりします。この視点の違いを意識することはデザインスプリントチーム編成では重要です。
そこで、先ほど話したユニット制を導入した際に、視点が作り手と異なる、QAや学生インターンもメンバーとて巻き込む様にしました。
初期プロダクトだったため、客観的視点で捉えるマーケの方などははいなかったので、 これまで以上にPOの視点をインプットする機会を日常的に増やすことを意識しました。
要因3：デザインスプリントをすれば上手くいくという過信
ありきたりなアイデアに着地してそう問題、最後3つめの要因、それがデザインスプリントをすれば上手くいくという過信、これが最も深刻な要因だと思っています。
プロダクトがリリースされると、メンバーのほとんどが新機能の開発や運用で頭がいっぱいに…。メンバー構成としても作り手が多いので、プロダクト作るということに集中してしまい、リリース前には頻繁にかわされていたプロダクト改善のアイデアなどの会話も次第に減少していきました。
プロダクトの課題に気付いても、デザインスプリントを定期的に実施していると、次回のデザインスプリントで考えればいいかという思考になりがちに…
全員がそうだったというわけではないと思いますが、少なくとも私はそう思ってしまった場面が何度かありました。
結果、その状態でデザインスプリントに挑むとどうなるか、
理解フェーズは、前提情報や課題感などのすり合わせからなので、それだけで時間がかかってしまいます。日頃から「あそこ課題だよね〜」などディスカッションが行われていれば、意見の集約にそこまで時間はかからないはず。
またアイデア発散フェーズでは、プロダクトの課題感を日頃から意識していないため、事前インプットも少なく、アイデア出しに苦労します。日頃から課題を意識していると、それだけでアンテナができ、意識して情報が集まりやすくなります。
結果、アイデアの幅や質が十分でない状態になりやすいと考えられます。
解決策1：考え方を変えよう！
まずは、「デザインスプリントは日頃考えていることをアウトプットする場」と考え方を変えましょう。
まずはこれをチーム内で共通認識にしましょう。
解決策2：ユニット制で当事者意識を強くする
ここでもユニット制の導入、権限の分割は効果的でした。機能ごとにユニットを分けることで、当事者意識が強くなり、日常的な議論が活発に。またユニット間でこっちも負けられない、という健全な競争意識も生まれ、より個々のアイデア提案が活発になったように感じました。
解決策3：アイデアを見える化する
また、アイデア提案を促進する施策として、アイデアの見える化も効果的でした。Githubのトピックを投稿、それに対してリアクションやコメントができる、Discussion機能というのがあるんですが、それを利用して、気軽にアイデアをそこに投稿できるようにしました。
投稿した内容はSlackのチャンネルにも流れるようにし、アイデアのストックはもちろん、目に触れることで、プロダクトについて考える、議論のきっかけを作ることができました。
まとめ
デザインスプリントでありきたりなアイデアから脱却するための解決策、プログラムだけでなく、チームの在り方も見直してみましょう。
最後に、デザインスプリントは魔法のツールではなく、あくまでも1つのツールにすぎません。実施するだけで上手くいくわけではないのです。
チームメンバー個々が日常からそのプロダクトに真摯に向き合い続ける姿勢が最も重要なのです。
そういった姿勢やチームの在り方が、デザインスプリントというツールを最大限活かすことができると思っています。
以上、長文読んでいただきありがとうございました！
当日の資料は、こちらから閲覧、ダウンロード可能です。
いいなと思ったら応援しよう！
