はじめに

こんにちは！株式会社スタメンでBtoBサービス「TUNAG」のプロダクトデザイナーをしているmonacaです。

突然ですが今年の2月に、 TUNAGのプロダクト開発組織に大きな変化が起きました。プロダクト開発体制が大規模スクラム(LeSS)に移行したのです。 

スクラムは、アジャイル開発(ユーザーにプロダクトの価値をより速く届けるため、短いスパンで機能開発を行い、フィードバックを受けて開発サイクルを回し、プロダクトを改善していく開発手法)の思想をベースにしたフレームワークの1つです。

スクラムに関する詳細な説明は割愛しますが、 スクラム開発体制に移行したことで、企画〜開発〜リリースまでのサイクルが速く、よりスピード感のある開発体制になりました。それにより、デザイナーの動き方(立ち回り方)も大きく変わります。 プロダクト品質を保ちつつ、より速さや変化への対応力が求められるようになったのです。

スクラムにおいて「デザイナーはこう動くと良い」という絶対的な正解はなく、国内にもまだ事例が少ないので、スクラムに慣れるまでかなり苦戦しました…！

色々と模索した結果、

この2つに気付きました。

今回のnoteでは、

について書いていきます。

これからスクラム開発に関わるかもしれないデザイナーや、職種に関係なくスクラムとデザイナーの関わり方に悩まれている方々の参考になれば嬉しいです！🌷

どういう経緯でスクラムチームに入ったのか

スクラム開発が始まった当初は、デザイナーは基本スクラムチームの外にいて、主な動きとしてこの2つを行なっていました。

スクラムチームとの関わり方を図にすると、こんな感じです。

スクラムチームが持っているアイテムでUIデザインが必要な場合は、実装を行う前にアサインされ、都度コミュニケーションを取ってデザインを共有していました。

スクラムイベントに関しても、スプリントレビューは毎回出席しますが、レトロスペクティブやスプリントプランニングなど、その他のイベントは必要であれば出るという形をとっていました。

ですが、このやり方だと上手くいかない部分が多々出てしまいました。

具体的には、主に下記の3点です。

どれもつらいですが、一番上が痛みが大きいです。🥶
UIデザインのアサインが必要なタイミングでデザイナーが別のタスクを抱えていた場合、開発が一時的にストップしてしまうためです。

そこで、規模が大きい機能開発が始まるタイミングで「試しにスクラムチーム専属のデザイナーとして動いてみよう」となりました。

スクラムではエンジニア、デザイナーなど職種に関わりなくチームメンバーは「開発者」として扱うため、私も開発者の一員になったのです！🌷

スクラムイベントに関しても、以前は必要であれば出るスタイルでしたが、基本全て参加して情報を拾えるよう変えました。明らかにエンジニアリング寄りの議題の場合は、不参加or耳だけ参加という形をとるようにしました。

これでスクラムチームにより深く関われる環境になり、(慣れるまで相当苦戦しましたが)紆余曲折を経て、スクラムでなめらかに立ち回れるようになりました！

スクラムチーム内でデザイナーは何をするのか

スクラムチーム内で実際に何をしているかというと、主にこの3点を状況に応じて行っています。

1.リファインメントの精度を高める

スクラムチームの開発者はアイテムに着手する前に、リファインメントと呼ばれる工数の見積もり作業を行います。

状況にもよりますが、自分がスクラムチームのデザイナーとして入っている場合、リファインメント前のタイミングで大枠のUI画面のレイアウトを固めることを優先的に行います。

なぜなら、UIのビジュアルが存在していると、ドキュメントだけと比べてチームメンバーの議論の認識を揃えやすく、リファインメントの精度を上げられるためです。

ちなみにここでの作業は、UI画面のレイアウトだけではありません。
よいプロダクトにするための「How？」を沢山考えます。

良いアイデアを思いついても、実装方針が確定した後だと、実現するのが難しくなってしまうこともあります。そのため、リファインメントの段階で早めに考慮すべき点を検討します。
より良い機能を届ける上で、仕様自体を見直したほうが良いと判断した場合は、適宜仕様の変更もこのフェーズで提案し、チームで議論します。

議論だけでは判断に迷う場面では、状況に応じてプロトタイピングや簡易ユーザビリティテストなども行います。

このペーパープロトを使った際は、社内メンバーに“ユーザーの代弁者”となってもらい、UIアイデアを見せてヒアリングしました。そのヒアリングでのFBを判断材料の1つとして、「どういうUIであるべきか？」をチームメンバーと議論し、最終的な意思決定を行いました。

このように、様々な検討を重ねた上で、チームメンバーと議論しながら仕様〜UIに至る意思決定をしています！

2.さまざまな状況、状態を考慮してUIをデザインする

機能の方向性や仕様が固まりました。
いよいよユーザーがプロダクトに触れてからその目的を達成するまでの一連のフローを、実際にUIに落とし込んでいきます！

ここでのポイントは、ユーザーの目的達成までの理想的なフローだけデザインすればいいわけではない、ということです👀
なぜなら、実際にプロダクト開発を行う場合、

などにより、UI上にさまざまな状態変化があるためです。

UIデザインを行う上で目指したいのは「ユーザーがどのような状況、状態でも使いやすいインターフェース」です。そのために、実際にユーザーがプロダクトを利用するときに起こるさまざまなケースを事前に検証し、最適な見せ方を検討します。

実際に検討する要素の例は、こんな感じです。↓

一例として、最近リリースしたTUNAGのカレンダー機能の一部をお見せし、UIの検討事例を1つご紹介します。

まず最初に、こちらのカレンダーのUIをご覧ください。
実はこのUIには落とし穴があります。一体どこでしょうか？🤯

次に、こちらの画面をご覧ください。

画像のUIの右下に着目していただくと、＋アイコンのボタンが同じ色の予定ラベルとかぶってしまっているのが、お分かりいただけますでしょうか。
この状態だと、予定がかぶって表示されている場合にボタンが見えづらいですよね。😢

カレンダー機能の目的は「予定を管理すること」なので、予定はたくさん入ることが想定できます。なので高頻度でこの状態が起きてしまうと考えられます。

このような状態変化を考慮し、ボタンの色を白色にして、どの色の予定が入ってもボタンに気付けるようにしています。
もちろん予定が空の状態でもボタンに気付けるよう、あえてボタンの影(ドロップシャドウ)を少し濃くする工夫を行っています。

このように、プロダクトデザインでは理想的なフローをデザインするだけではなく、さまざまな利用状況、利用する環境を踏まえたUIの意思決定を行う場面がたくさんあります。

これらのUIの要素の検証は、デザインする時点で最大限行います。ですが実装を進めるうちに別の懸念点が見つかったり、実装の実現可能性の観点から、別のアイデアを検討しなければならない状況も発生することもあります。
その際にチーム内にデザイナーが存在していれば(近い距離にいれば)、懸念すべき事柄が見つかった際にすぐに議論し、意思決定を速く行うことができます。

3.デザインシステムを推進する

機能開発と並行して、二歩三歩先を見たデザイン実装における仕組みづくり(デザインシステムの一環)も同時に進めています。

デザインシステムに関して個人的に重要だと感じるのは、「なぜデザインシステムが必要かをよく考え、今の段階で大切なことを小さく切り出すこと」です。

今のTUNAGの開発組織のフェーズでは、以下の2点が重要だと考えています。

たとえ細かな要素でも「このボタンの文言に『する』をつけるかつけないかどうする？」と判断に迷う状況が発生すると、その度議論が発生してしまします。

そこで、ボタンの文言のあるべき形を考えた上で、ガイドラインを策定しました。

ガイドラインを決め、意思決定の判断軸を明確にすることで、繰り返される要素についての議論を省けるようにします。これで、より良い体験をユーザーに届けるためのもっと重要な議論や開発に時間を割けるようになります。

そのほかの取り組みの一つとして、「共通コンポーネント化」があります。TUNAGの共通コンポーネント化については、エンジニアの神尾さんが記事を書いてくれているので、ぜひご覧ください！

デザイナーがスクラムチームに入るとなにが良い？

冒頭で書いたように、デザイナーがスクラムチームに入ると、良いプロダクトを作る上で、プロダクト開発組織とデザイナー個人にとってメリットがあると感じます。

プロダクト開発組織へのメリット

チーム専属のデザイナーとして動く1つ目のメリットは、開発における意思決定のスピードを速くできることです。チーム内で距離も近いのでお互いの進捗状況を密に把握できます。仕様面やUI、機能の体験に関して気になることはお互いにすぐに声をかけて話すことができます。

2つ目は、職種をまたぐ課題を一緒に解決できるという点です。

プロダクト開発する上で、デザイン実装は文字通りデザインとエンジニアリングの領域をまたぎます。

エンジニアがデザインを実装する際にどんなことで困っているか？については、スクラムで議論を重ねることで(まだ部分的ですが)理解できるようになりました。以前は「デザインシステム＝プロダクトデザインの一貫性を担保する仕組み」という認識でいたのですが、デザイン実装の開発体験向上という観点でも、デザインシステムは重要なのだと学べました。

他にもデザインレビューや仕様議論の進め方など、職種をまたぐ課題も一緒に話し合い、解決策を考えることができています。(TUNAGのエンジニアのみなさん、いつもありがとうございます…！🌿)

デザイナー個人へのメリット

スクラムチームに開発者として入ってみて、デザイナー個人にもメリットがありました。

1つ目は、プロダクト開発の全体感を以前より掴めるようになったことです。

これまで企画〜デザイン〜実装〜リリースまでの一連の流れを経験し、チームメンバーと議論を沢山重ねてきました。

それらを通じ、「今作っている機能の目的は何で、どういう戦略に基づいているのか」「機能の目的を実現するためには、UIはどういった振る舞いをすべきか」など、プロダクト戦略からUIへの落とし込みをする上で抽象と具体を行き来する癖がつきました。

さらに機能の価値、ユーザビリティ、実装の実現可能性など複数の観点からメリット・デメリットを整理し、優先度に応じて適切な判断やコミュニケーションをとることが以前よりできるようになりました。

2つ目は、実装を知ることの重要性を理解できることです。

デザイナーが実装のことを理解していた方が、コミュニケーションコストを減らせますし、よりデザインの提案の幅を広げられると実体験を通じて学びました。

また、スクラムを通じてエンジニアと距離がより近くなったことも、個人的に嬉しかったです。

お互いエンジニアリングとデザインについて教え合ったり、ユーザー体験を上げるための新しい取り組みを試したりする動きが増えました。「スクラムチームに入る」という、デザインから少しはみ出てエンジニアリングに越境する経験ができて本当に良かったです！

まとめ

これまで「デザイナーがスクラムチームに開発者として入ることの価値」を書いてきました。

スクラム開発が始まったばかりの頃はプロダクト開発の不確実性・めまぐるしく変わる状況に対応するのに必死で、正直不安だらけでした。
ですがスクラムチームに深く入り、自分が知らなかった領域に触れて全体感を把握することは、その漠然とした怖さを乗り越える強力な武器になりました。✨

補足ですが、実際にスクラム開発で1年弱やってみて、

これらのアイテムをスクラムチームが持つ場合、専属でデザイナーが入るとエンジニアと上手く連携して開発を進められそうだと感じました。

また、「スクラムチームにデザイナーが入る」はあくまでも一つの手段であり、組織規模や状況によって最適な立ち回り方は変わります。

良いプロダクトを作る、そのために意思決定を速く、精度を高めるための工夫を模索することを続けていけば、スピードと変化が大きいスクラム開発の環境でも、デザイナーは価値を作っていけると信じています。

ここまでお読みいただき、ありがとうございました！

☕️

スタメン デザイナーマガジンでは、他にもデザイナーさんに向けた記事を書いています。ぜひご覧になってください。

もしスタメンにご興味を持っていただけた方は、下記のWantedly募集ページからお気軽にご連絡ください。

www.wantedly.com 東京・名古屋 | 急成長する自社SaaSプロダクトのデザイナー募集！ by 株式会社スタメン

株式会社スタメン

募集要項をみる