こんにちは、デザインマネージャー / デザイナーのMoQです。

デザイン本部プロダクトデザイン室に所属し、新卒事業部 / キャリトレ事業部で、プロダクトのデザインや、デザインチームのマネジメント業務を行っています。

Visionalの多くの事業部では、価値の高いプロダクトを開発・提供・保守するため、複雑で変化の激しい課題に対応する開発手法「スクラム（Scrum）」を採用しています。スクラムは国内外の様々なプロダクト・サービス・組織の管理で使用されていますが、“スクラムにおけるデザイナーの働き方”について多くの議論や、明確な定義はされていません。また、組織や事業によって働き方も変わるため、正解と言えるものを導き出すのは難しいです。

今回は、若手デザイナーの理解を深め、彼らの活躍に繋がるようにと、私がVisionalの新卒事業部で設計した「Design Process in Scrum」について紹介します。

あくまでも一例ですので、参考までにご覧いただけると嬉しいです。

デザイナーの働き方の整理はなぜ必要？スクラム実践の課題感

「スクラムにおけるデザイナーの働き方」を改めて設計しようと思ったのは、1年ほど前に「ビズリーチ・キャンパス」を運営する新卒事業部に異動したことがきっかけでした。

新卒事業部に所属するデザイナーは若手が多く、サービス開発や運用をする上でどのような働きが必要なのか、デザイナーはスクラムの中でどのように動くことが効率的でインパクトがあるか、誰もそのプロセスを考えられていない状態でした。

スプリントを開始するときは、開発チーム全員で課題に対する打ち手の検討から始めます。その中で、デザイナーが自ら効率的に動かなければ、デザイン作業に遅れが生じ、最終的にチーム全体の動きに影響が出てしまいます。

また、スクラムを採用する以前の問題ですが、作業工程が明確ではないことが原因となって、UIデザイナーは要件やフローを定義していなかったり、定義する前にデザインに着手したり、ワイヤーフレームの段階でユーザーテストをしていなかったりと、いくつかミスが発生していました。ミスが重なると、手戻り作業が発生し、どんどん作業時間がずれて、プロダクトの品質担保もできなくなります。

また、スクラムそのものが開発スピードの変化に対応できない課題も感じていました。

スクラムの手法が誕生したのは、インターネットが浸透する少し前。当初はプロダクトの開発と管理のために生まれたアジャイル開発手法の一つでした。スクラムは銀行やロボットのような大きな管理システムのために、素早く価値を出す開発手法として利用されていました。

その時代は、前段階でしっかり検証した後にプロジェクトを進めていたのですが、インターネットが普及してからは、検証方法やプロセス、開発のスピード感が大きく変化して、短いスパンで検証やコラボレーション、品質担保をしないといけなくなったのです。

現在の開発スピードに対応しながら、スクラムの中でデザイナーはどのように働くべきか。本やWebなどでも多くは語られておらず、スクラム領域のコーチに聞いても、なかなか答えは出ません。デザイナーが自分で考え、行動し、正解を導き出さなければならないのです。

ですので、私が考えたプロセスが正解かどうか。他のサービスでそのまま実行して再現できるかはわかりません。しかし、少なくとも新卒事業部では、スクラムにおけるデザインプロセスを改めて設計したことで、品質担保や作業効率を含めたチーム全体でのパフォーマンスを上げることができました。

課題を解決するため、設計した「Design Process in Scrum」

新卒事業部に異動して、私が設計したのが、この「Design Process in Scrum」の図です。

この図はスクラムの中でデザインに関わる工程と、それらの工程の関係を図にしたものです。

図の一番上（黒の線）は「Sprint N-2」「Sprint N-1」「Sprint N」は3つの開発スパンを表していて、全体で3週間、それぞれ1週間の動きになります。

図の真ん中（グレーの背景）はスクラムに合わせて、インタラクションデザインやUIデザインなど、デザイナーが何をやらないといけないのか。作業工程とその内容を表しています。また、それぞれの工程で参加しなければならない他の開発メンバーも示しています。

図の下（山グラフ）はUXの五階層「Strategy」「Scope」「Structure」「Skeleton」「Surface」です。デザイナーの作業工程と重ねて、体験設計をどのようにマッピングするのかを表しています。

「Design Process in Scrum」を実際にどう活用するのか？

大きめの機能を実装する場合、最初の開発スパンの「Sprint N-2」は、どういった機能を開発するのか、スクラムを行うチーム内で共通認識を作るための時間です。ユーザーフローを定義して、その段階でプロダクトオーナーと認識を合わせて、チームにも共有します。

次の開発スパン「Sprint N-1」では、UIフローをの定義、プロトタイプ作成、チームを巻き込んだユーザー調査を行い、検証を繰り返します。検証が完了したら、精度が高いワイヤーフレームとプロトタイプを作成、プロダクトのUIやUIフローが確定している状態に持っていき、最後のスプリント開発に入ります。

最後の開発スパン「Sprint N」では、スタイルガイドも揃っていて、ワイヤーフレームさえあれば開発とビジュアルデザインが並行してできる状態になっています。チームと一緒に、具体的な挙動や余白の定義の確認、デザインを作りながら、QAやデザインレビューができる状態です。

このように作業工程などを具体的に「Design Process in Scrum」で可視化して、プロセスを整理し、スクラムの作業工程を理解しやすいものにしました。

スクラムでのデザイナーの働きを設計したことによる効果

経験も少ない若手のデザイナーたちは、どの段階で何をすべきか判断が出来ず、柔軟に動くことも難しい状態でした。この「Design Process in Scrum」を設計したことで、1個のプロダクトを完成させるまでのTODOリストが全て可視化されました。その結果、この1年でプロダクト開発の手戻りが減り、大きな手応えを感じています。

また、UXの五階層「Strategy」「Scope」「Structure」「Skeleton」「Surface」の構造と作業工程をマッピングしたことで、UXの五階層について、デザイナーたちが実体を伴って理解することができました。

理解が進んだことで、このアウトプットはどういったインタラクションを想定するのか、なぜこういうアウトプットが必要なのか……マネージャーやビジネスサイドの人たちへ積極的にコミュニケーション取りに行くようになり、連携もスムーズになってきています。

しかし、この「Design Process in Scrum」は、まだプロダクト開発の部分のみで、図の一番左にある「POC（プルーフオブコンセプト）」から以前のプロセスは定義されていません。

%3Cp%20style%3D%22font-size%3A%2012px%3B%20text-align%3Acenter%3B%20margin-top%3A%20-4px%3B%20line-height%3A1.4%3B%22%3E%E3%80%8CDesign%20Process%20in%20Scrum%E3%80%8D%E3%81%AE%E4%B8%80%E9%83%A8%E6%8A%9C%E7%B2%8B%3C%2Fp%3E

POC（プルーフオブコンセプト）以前の設計

「Design Process in Scrum」のようなプロセスを定義するには、POCをちゃんと検証していることが前提です。

例えば、「こういうソリューションやファンクションは絶対に売れる」「絶対にこういう機能をつけるべき」「絶対にお客様への価値を提供できる」など……検証が完了していれば、その後のプロダクト開発には意味があります。しかし、この検証が出来ていない状態でプロダクトを作っても、全てのプロセスが無駄になってしまいます。

まさに今、POCより前のフェーズを作成しようとしていますが、抽象度が高く、工程化するのがとても難しいです。市場やお客様は常に変化しますし、それらの要素が無数にあるためです。

こちらはまだ作成途中ですが、私が作成しているサービスデザインの全体像です。

「Design Process in Scrum」は、図の赤い枠の中にあたり、この全体像の一部でしかありません。

上記のように、市場やお客様などの変化は激しいため、POCも含め、この全体像を工程化することは難しいですが、このくらい全体のことを考えて設計して進めないといけない……ということを、伝えられればと思い形にしています。

おわりに：スクラムの中で目指すデザインチームの姿

スクラム開発を進める中でデザイナーにとって一番大切な仕事は、プロダクトオーナーと一緒にProduct Backlog Item（PBI）を作ることだと考えています。

PBIはスクラムのTODOリストのような役割で、どんな課題があるのか、何のためにやるのか、お客様がどういう機能を求めているのかを定義します。PBIを定義するためには、様々な観点から根拠を示さなければなりません。

例えば、販促用のLPであれば、10人にテスト用のLPを見せてインタビューを行い、8人に「すぐ購入したい」とおっしゃっていただく。デザインの根拠を示すには、そういった仮説検証が非常に大事です。

POCの定義を完成させる以前に、そういったPBI定義のため、それぞれのデザイナーが自ら動けるデザインチームになればと思っています。「Design Process in Scrum」の効果もあり、少しずつですが、チームのデザイナーたちは自らすべきことを可視化して、必要な工数の逆算や、すべきことの優先順位をたてられるようになってきました。

いろいろと書いてきましたが、説明することは簡単でも、それを実践することはとても難しいです。

今回ご紹介した「Design Process in Scrum」が対応しているのはプロダクト開発フェーズのみで、それ以外のプロセスは完成していません。不確かで変化する未来に合わせて、軌道修正を繰り返し、開発や検証を重ね、今後もデザイナーとしてスクラムのあり方を探っていきたいと考えています。