DevOps: Design Sprint? 流行っていますが、あなたのチームには効果があるでしょうか？

2020/8/19 - 読み終える時間: 3 分

Design Sprint? It's all the rage, but will it work for your team?

Design Sprint? 流行っていますが、あなたのチームには効果があるでしょうか？

2020年8月19日

著者: Ben Vance / UI Designer for HCL Software DevOps

バックストーリー(生い立ち、これまでのこと)。どのようにしてここまで来たのか？

率直に言います。

COVID-19 パンデミックとワーク・フロム・ホームの「ニューノーマル」の始まりに際し、私たちはかなり大きな設計プロセスの失敗をしました。設計に1ヶ月もかからないはずの新機能が、3ヶ月近くもかかってしまいました...最終設計はかなり最初の設計に近いものになってしまいました。全員がオフィスにいたとしても、非効率なことは起きていたでしょうが、リモートであることが問題をさらに悪化させ、そのうちのいくつかの問題が発生しました。

• プロジェクトの開始時に明確な要件がなかったこと
• 最初のミーティングにキーパーソンがいないこと
• プロセスを通して新しい人を連れてくる
• 会議の間隔が長い

では、それぞれの問題を詳しく見ていきましょう

• 私たちが始めたとき、「成功」とは何を意味するのか、明確な考えがありませんでした。さらに悪いことに、誰もが「成功」の意味するところが違っていました。だからデザイナーとして、私たちは動き続ける的中率の矢を暗闇の中で撃っていました。私たちは、ある用語が実際に何を意味するのかを定義し、再定義することに何時間も費やしました。
• 私たちは、ビジネスの "上の方 "にいる数人の主要なステークホルダーからプロセスを始めました。私たちは、彼らの考えと賛同を得ることで、デザイナーがまとめたソリューションを実装するために開発者を引き入れることができると考えました。問題は、開発者がそれぞれの考えを持っていたこと、さらに重要なことは、以前に設計された製品からの洞察を含めて、製品がどのように機能するべきかについての異なる洞察を持っていたことでした。
• 開発者を引っ張っていくと、追加の質問やポイントが出てきて、それを主要な利害関係者のところに持ち帰らなければならないことがわかりました。私たちは、各段階で追加の開発者を入れ続けることで、この問題をさらに悪化させてしまいました。これは結局、一連の循環型の議論を生み出し、タイムラインをさらに悪化させ続けました。
• 最終的には、会議やデザインレビューの間に時間がかかりすぎてしまいました。デザインの更新は1日で終わるのに、チームでレビューするのに1週間も待たされていました。これがリモートワークの一番の弊害だと思います。オフィスでは、即興のフィードバックを得るために人の肩を叩いていました。リモートで仕事をしていると、会議のスケジュールを組んだり、かなり忙しいスケジュールの中で仕事をしたりしなければなりませんでした。

だから、解決策は？全く逆のことをして、次のデザイン機能を1週間以内に完成させよう。何がいけないのでしょうか？

Design Sprint。それはまさにプロセスなり

私たちはリモートで仕事をしていたので、在宅勤務の方針に合わせて Design Sprint の方法論を少し修正しなければなりませんでした。

• すべての会議は、会議室で個人的に行うのではなく、GoToMeeting を介して行われます。
• このデザインを素早く把握するために部屋に入る必要があるキープレイヤーを把握する。私たちは、デザイナー、開発者リード、開発者のミックスに着地しました。我々はまた、日進月歩のレビューを与えるために、"上の人 "とのいくつかのフォローアップミーティングを持つことを決めました。
• チームメンバーを選ぶことで、その人たちがチームの残りの部分を代表して話すことを明確にしました。会社全体をまとめて100%の合意を得ることは不可能でしょう。ある時点では、チームのリーダーは他の人にコントロールを委譲しなければならないでしょう。
• 公式の」 Design Sprint の方法論に従って、チームはこのプロセスに40時間を費やす必要があります。現在進行中の作業と、これが「ベータ版」の取り組みであるという事実を考えると、この機能を完成させるためには1日90分という時間が必要になります。
• デザインチームは、毎日達成したいことを網羅したアウトラインをまとめました（※脚注やスケジュールのスクリーンショットを追加してください）。
• 公式な方法論を確認しましたが、私たちのためにプロセスをかなり自由にしました。

結果はどうだったか

手短に言うと...本当によくできました。

• 開発者は、設計プロセスにもっと参加したいという希望を表明しています。 Design Sprint では、初日から自分たちの考えを表現することができました。また、このプロセスでは、彼らが考えていた解決策をスケッチし、デザインする機会を与えてくれました...それがペンと紙であっても、シンプルなパワーポイントであっても。

• 私たちは、バーチャルホワイトボードとして壁画ソフトを利用することにしました。これは、ブレインストーミング中に全員が自分の考えをタイプしたり、さらに発展したものを見たいと思った項目を「スターリング」したりすることができるようにするための素晴らしい決断であったと思います。一週間を通して、グループは初日のメモやスケッチを参照し続けました。

• 1日目は予定より遅れてしまいました。1日90分というのは、このプロセスを始めるにあたり、私が一番恐れていたことでした。私は、会議がどれだけすぐに逸脱してしまうかを知っているので、簡単に1時間を失ってしまうことになります。私たちは、このような議論をできるだけ早く終わらせるように心がけていましたが、実際にはそうなってしまいました。

次回は何をするか

Design Sprint は成功しましたが、プロセスを改善するために変更できることがいくつかあります。

• 毎日、より多くの時間を割くこと。1日90分だけでは、全員の考えを完全に具現化するには十分な時間ではありませんでした。
• 理想的には、ホワイトボードやポストイット、目と目が合うような形で、直接会って行うのが良いでしょう。電話でできる限りのことはしましたが、やはり対面でのフィードバックが理想です。
• プロトタイプのフィードバックをしてくれる時間を割いてくれる顧客の具体的なグループを持っている。

まとめ

これはあなたのチームでも当てはまることなのでしょうか？私はそう思います。

HCL Software DevOps では、非常に意見の多いチームがあり、彼らの声を聞きたいと思っています。このプロセスは、それを可能にしてくれました。全員が自分たちが取り組んでいることに興奮し、エンドツーエンドのプロセスに手を貸したと感じたとき、製品は恩恵を受けることができます。それを実現するためには、日々の仕事に追われていると感じないように、時間を割き、チームに必要なリソースを与えなければなりません。しかし、最終的には、テスト可能な具体的な成果物プロトタイプができあがります...1週間の作業も悪くありません。

HCL Accelerate は、チームが世界中に分散している場合でも、オフィスで一緒に作業している場合でも、スプリントを成功させるためのお手伝いをします。チームメンバーごとに作業を整理するスイムレーンのような機能や、すでに使用しているツールと統合する機能を備えた HCL Accelerateは、DevOps パイプラインの測定、トラッキング、最適化をこれまで以上に容易にします。ここから無料でダウンロードしてください。