創業20年超えの会社でデザインスプリントやってみた
こんにちは。株式会社レスキューナウでアプリエンジニアをしているコウです。僕は今年の２月に入社しまして、ちょうど４ヶ月経ったところです。さて、今回は、先日行ったデザインスプリント（以下、スプリント）について紹介していこうと思います。
経緯
レスキューナウでは今、新プロダクトの開発に取り組んでいます。
開発プロジェクトは進んでいるのですが、「これは誰の何を解決するものなのか」がふわっとしたまま進んでしまっているという課題がありました。
繰り返し議論して進めているのですが、なかなかバシッと決まらないという状態が続いていました。
この現状を打破する方法が何か無いかなーと探っていたところ、CTOから「スプリントって方法があるんですよ。まとまった時間作って合宿みたいにするんですけど」と、話が出てきました。
僕は前職でスプリントの経験があったので、「スプリントならやったことありますよ」と言ってみると、じゃあやってみよう！、となりました。
これ、スプリント開始２日前の出来事です。
内心、「え、ほんとに？準備とか、他の人にまだ説明もしてないし、スケジュール調整も出来ないんじゃ？」と思ってたんですが、あれよあれよ、と勢いで始めることになりました。
正直、創業20年超えていて、このスピード感はすごい！と思いました。
レスキューナウについて簡単に説明
レスキューナウの説明を簡単にしますと、設立2000年でＩＴ業界では老舗になると思います。今まではシステム開発をパートナー企業にお願いすることが多く、平たく言えば内製していませんでした。
その結果、自分たちがやりたいことがスピーディに実現できないという課題を抱えていました。改善サイクルがうまく回せていないんですね。これをなんとか内製化していくことで、解消できないかとチャレンジをしているところです。
いわゆるスタートアップとはちょっと毛色が違いますが、スタートアップの常識を適用することで、大きく改善できる部分がたくさんあると感じています。
スプリントとは
スプリントとは、課題抽出からプロトタイプ作成、ユーザーインタビューまでを５日間で行うというフレームワークです。
スプリントの書籍は何冊かありますが、僕が前回も使ったことがあるということで、今回はこの本を参考に行いました。
どんな風にやったか
まず、事前準備です。
１． メンバーを集める
２．スケジュールを空ける
３．場所を用意する
４．道具を用意する
５．役割を決める
６．スナックを用意する
メンバーを集める
今回は６人で行いました。
社長、CTO、エンジニア２名、CS２名
です。
スケジュールを空ける
スプリント一番の難関です。全員の時間を、８時間フルｘ５日間連続で空ける必要があります。先ほど書きましたが、やることが決まったのが2日前です。
普通、空かないですよね。
もちろんスケジュールが空っぽだったなんてことは無いので、なんとか調整して参加していただきました。
前職でスプリントやったときもここの調整がめっちゃ大変でした。その時はどうしても調整つかなかったので、３,４時間ずつにちぎって２週間にして取り組みました。（絶対まとまってた方が良いと思ったので今回言わなかったのは内緒です🤫）
場所を用意する
さて、次はどこでやるかです。レスキューナウは普段はフルリモートで業務を行っています。さすがにリモートでやるのは難易度が高すぎるので、オフラインでやることにしました。
場所は、本社と別にある不動前オフィスにしました。これは単純に大きなホワイトボードがある会議室があったからです。ちなみに不動前オフィスは住所非公開なので、なんだか秘密基地みたいです。（トップに貼った画像が不動前オフィスです）
オフラインでやるとなったのは良いのですが、人によっては１時間以上かけて通勤することになる人もいました。それでも「いや、ちょっと、、」みたいな話は全く出ず、全員快く引き受けていただきました。
ここの調整に手こずってしまうことって多いと思うのですが、みんながこうやって前向きに参加してくれるのはとっても良いな、と思いました。
道具を用意する
ホワイトボード、ふせん、コピー用紙、サインペン、など。本に書かれている文房具類を用意します。この辺一式、社長が率先して揃えてくださいました。
役割を決める
ファシリテーター
決定者
を決めます。
ファシリテーターは、スプリント経験のある僕が担当し、決定者は社長としました。
スナックを用意する
ちゃんと本に書いてあるんです（笑）。そして、結構大事です。本当に頭使うので、何かしらつまめるものが無いとエネルギー切れしてしまいます。
なるべくヘルシーなものが良いのですが、バナナが意外と良かったです🍌久しぶりに食べました。
実際のスプリント
さて、後は書籍を参考に突き進むだけです。
ガラスの壁、めっちゃいいですね。付箋が一枚も剥がれることがありませんでした。
初めてなので時間超過する場面もあるかなと思っていたのですが、決められたスケジュール通りに進めることが出来ました。全員がしっかり集中して取り組めた結果だと思います🙌
スプリントでとても大事なことの一つが、電子デバイスを持ち込まないことです（電子書籍見るためにiPadだけは持ち込んでいましたが、ネットは切ってました）。電子デバイスはそこにあるだけで気になってしまいます。また通知も同様です。こんなに長いこと通知が来ない時間はいつぶりだろうと思いました。
タイマー大事
スプリント中は細かくタイマーをセットしながらやっていきます。
写真を撮り忘れてしまったのですが、こんなタイマーを使ってやります。スプリント中は電子デバイス使わないので、物理タイマーが必要になります。また、物理であることで、時間に対する意識も強くなるのでおすすめです。（タイムタイマー、なぜかお高い）
時間は３分だったり、30分だったり、取り組むものによってさまざまです。ここで、ファシリテーターの僕としては、タイムキーピングの重要性を知ることになります。
スケッチを書くとかは良いのですが、これを選んだ理由を３分で話して下さい、みたいな時です。
みんなめっちゃ喋るー
話している本人も時間が過ぎていることは分かってるはずなんですが、言いたいことが溢れてくる、みたいな状態です。
あ、だから会議って終わらないんだ、と実感した瞬間でした😅
日々のスプリント終了後
スプリント中は、普段本当に仕事出来ていたんだろうか？ってくらい頭使いました。帰るとびっくりするくらいヘトヘトに…
タイムスケジュールとして10時〜17時でやっていたので、終わる時間は意外と早いんです。それでも、ウィルパワー（意思決定力）を全て使い切った状態になるので、時間はあるけど何も考えられない、みたいな毎日でした。
特にファシリテーターは最初に頑張りすぎないように注意が必要です。
プロトタイプ作成
１日でプロトタイプを作ります。当然コードを書いてる時間はありません。
スプリントの書籍では Keynote 推しでした。
Keynote には Magic Move というアニメーション機能と、ボタンクリックで別ページに遷移できるので、これでプロトタイプを組み立てられるとのことです。
ただ、今回はテストはリモートで行うことになっていたので Keynote は使えず。代わりに Google Slide を使ってやってみました。途中まで Keynote の代わりに使えるなと思っていたのですが、なんと、ボタン以外をクリックしても次の画面に進んでしまうことが発覚。これではテストになりません。
最終的には画面は Google Slide で作り、キャプチャして Figma に取り込み、遷移だけ Figma で作ることにしました。最初から Figma で作ればよいのでは？と思われるかもですが、 Figma だと必要以上に作り込みすぎてしまう恐れがあったので遷移だけにとどめました。
ターゲット顧客でテスト
いよいよ、ターゲット顧客でテストです。書籍通り、５名の方にインタビューを行いました。内訳は、社外３件、社内２件です。
特に、ご協力いただいた社外の皆さま、本当にありがとうございました！
Teamsでつなぎ、テスト実行者に Figma のプロトタイプを開いてもらいます。さらに、その画面を画面共有してもらい、操作してるところを見ることができるようにして進めました。
※レスキューナウでは全社でTeams、システム部はSlackと両方使っています。
やってみてどうだったか
反省点もありつつですが、全体的にとても良かったと思います。
いくつかの視点で良かったことがありました。
仕事の仕方
通知が来ない時間最高
アイデアを生み出すにはまとまった時間が必要、ということが実感できた
考える時は一人で考えたほうが深く考えられること
タイムキーピングと、決定して進めていくことの重要性
プロトタイプづくり
プロトタイプは１日で作れる、ということが分かった
ユーザーテスト
ユーザーインタビューは大事
プロトタイプがたとえハリボテでも、そこから得られるものは大きい
目的を達成できたか
肝心の、スプリントをやる目的を達成できたか、ですが、残念ながら今回のスプリントだけでは達成出来ませんでした。詳細はお話しできませんが、「今回のプロジェクトでやるべきコアは何なのか」みたいなことをを題材にやっていました。
やればいいよね、と分かっているものはテストするまでもないので、リスクは高いかもしれないが、当たれば大きな結果が出るものを選んだテストをしました。その結果、今回の内容では少し力不足なものになってしまいました。あったら良さそうとは思ってもらえたのですが、それが欲しかった！までにはなりませんでした。
改善点
最後に、全体と通してもっとこうしておけばよかったな、次回はこうしよう！と思った点をあげてみます。
紙の本を用意すればよかった
電子でいけるかなと思ったのですが、かなり見返すことが多いので、絶対紙媒体の方が良いです。
ファシリテーターは、事前にまとめたカンペを用意しておいたほうが、スムーズに進行できると思います。
一番最初に、全体と流れの説明をすればよかった
当日朝に当日の流れを説明していたのですが、全体をもう少し知ってもらった上で取り組んでもらえた方が、参加者もやりやすかったのではないかなと思いました。
やる目的と、本当にこれで良い？という要所要所での確認
ズレがあるかも知れない、と思うタイミングが正直なかったわけではありませんが、前に進めることを優先してしまったかも知れません。ここはもしかしたら少し立ち止まっても良かったかも知れません。
ファシリテーターはアイデア出しに参加しない、もしくは半分の力で参加する
単純にとっても疲れます。ファシリテーターがファシリできなくなると全体が止まってしまうので、最後まで体力を温存する意味でも、ファシリに集中できると良いと思います。
回数を重ねていくと参加者も流れが分かってくるので、そうなったらアイデア出しに参加する時間を増やすとかでも良いかも知れません。
今回のスプリントを通してわかったこと
今回参加したエンジニア陣は、自分を含めて全員社歴が浅いです。CTOは半年ですし、僕は４ヶ月。もうひとりのエンジニアに至っては入社１週間でした。
レスキューナウはスタートアップと言うには歴史がありすぎる会社です。正直、レガシーという言葉もちょくちょく聞こえてきていました。みなさんがそこから抱くイメージは、たぶん僕とそうそう変わらないと思います。
しかし、今回のスプリントを通して、良い意味でぶち壊されました。
今回関わった人、みんなプロダクト愛がある！
既存サービスは意外としっかり使われている！
この二点が揃っているなら、適切な改善サイクルさえ回すことができれば、めっちゃ良くなるんじゃないか、という感覚になりました。
終わりに
今回、レスキューナウとして初めてスプリントをやってみました。企画からプロトタイプ作成、顧客でのテストまでを一回経験できたことはとても大きいと思います。
さて、ここまで読んでいただいた方（特にプロダクト開発に携わる方）は、きっといろんな課題が見えたんじゃないかなと思います。
こういった課題を一緒に解決してくれる方、現在大募集中です！少しでもレスキューナウに興味を持ってもらえたら、ぜひお気軽にお問合せ下さい。
僕のtwitterでも大丈夫です！