アジャイル開発における、デザイナーの"やるべきこと"の見極め方

こんにちは、Monoxerのデザイナーmoyoです。今回はアジャイル開発(notスクラム)におけるデザイナーについての学びを書き記します🙌

こんな人におすすめなnote
・アジャイル開発(notスクラム)チームでデザイナーをしている
・デザインするものが多く、1つひとつの質が落ちている
・デザインすべきものがデザインチームで積み上がり、エンジニアが手持ち無沙汰になっている
・デザイナーの仕事のスピードが開発チームのリリース頻度に直結している
・やるべきことを絞るのが苦手

おそらく上記のような問題を解決する一つの手段として、多くの開発チームでスクラム開発が採用されているかと思います。このnoteではスクラムではないアジャイル開発でデザイナーがどのようにやるべきことを見極めているかを書いていきます😌

アジャイル開発における初期の苦悩

弊社は現在エンジニアが5名とデザイナーが1名おり、アジャイル開発で日々機能や改善をリリースしています。正直ジョインした当初は、デザインしにくすぎ！！と毎日思っていました。

リリース回数が多いことはユーザーにとって良いことなので大賛成なのですが...。弊社は開発チーム1人ひとりの裁量が大きく、個々人の判断で新機能の開発や改善が進んでいくので、デザイナー目線から見ると「どの機能や改善の実装がいつ誰によって始まるのか」が全く分からないんですね😇　

デザイン！！いつ始めたら！！！いいの！！！😇😇😇😇😇😇　

苦悩を分解すると見えてきた固定観念

もちろん開発チームに共有し、何度か解決策を話し合いました。しかしウォーターフォールは性に合いませんし、弊社のエンジニア陣は1人ひとりがフロント〜バックエンドまで一貫して取り組むためスクラム開発も合いません...。良い解決策が出てこないということは、課題設定の筋が悪いのでは...？そこで、改めて自分の苦悩を分解してみました😳

するとやりにくさの根底に「全ての新機能、改善のデザインを行うことがあるべき姿」と信じている自分がいました。私はこの考え方を捨て、本当にデザイナーが"やるべきこと"を見極め、そこに全力を尽くす道を進むことに決めました💪

本当に"やるべきこと"は実は一部だった

結論からいうと、なんと本当に"やるべきこと"は黄色の部分のみでした。一段階ずつ簡単に説明していきます。

Monoxerでは全ての職種が新機能案や改善案、不具合をJiraに記載できます。1日2件以上は追加されるので、過去のものとの重複を除いてもそれなりのペースでチケットが増えます。当初はこの総数=デザインすべきものと思っていたわけです😇　

そしてついに昨年OKRの運用が全社で始まったことをきっかけに、直近3ヶ月で取り組むものを決める全職種参加のミーティングが新設されました🎉 この会で「直近3ヶ月で取り組むもの」「次期以降に取り組むもの」「取り組まないもの(削除)」が決まります。この仕分けに関しては、いつか別noteで。

「直近3ヶ月で取り組むもの」だけでも100以上あるので、更に絞り込みが必要です。主に2つの視点でチケットを分類していきます。

1️⃣一秒でも早く解決or存在すべきもの
・ユーザーに影響の大きい不具合(バグ)
・ある職種の工数を明らかに圧迫している課題の解決策
・新しい問題形式のデモ

2️⃣時間をかけて取り組めるもの
一秒でも早く解決or存在すべきもの以外

1に属するチケットは基本的にデザイナーは関わらず、エンジニアが直接実装に入ります。工数を圧迫している課題の解決策は場合によってユーザーが使うものもありますが、ある程度使いづらくても機能として存在すること自体がユーザーのメリットになるケースがあるのです。体験・UIの設計は割り切って次の期に取り組みます。新しい問題形式のデモもセールスがクライアントに見せるためのものなので、エンジニア陣にお任せです。

「時間をかけて取り組めるもの」が80程度として、更に絞り込ますね！ここでも主に2つの視点でチケットを分類していきます。

3️⃣社外の人間が使うもの
・先生、管理者が使うもの
・生徒、学習者が使うもの

4️⃣社内の人間が使うもの
・CS、Sales、SWEが使うもの

4はどんなに体験がいまいちで使いづらくても、身内なのでどうにかなります。そのためこちらもデザイナーは関わらず、エンジニアが直接実装コースです👍 なおエンジニア陣にUIの相談をされた場合は、手書きのワイヤーを渡し議論することもあります。

ここまでくると、大分チケットの数が減ってきます。時期やエンジニアの人数増加の具合にもよりますが50程度です。100→50と考えると半分になりましたね！前述した「社外の人間が使うもの」がデザイナーが積極的に関わるものになるわけですが、更に分類し優先度と力配分を検討していきます。

5️⃣目的も手段も明確
・課題が明確で、ピンポイントな解決策が決まっている
・改善したい数値と目標値が明確で、取り組む解決策が決まっている
・解決策が具体的で、画面が想像できる
・既にデモが出来ている新しい問題形式

6️⃣目的のみが明確
・課題は明確だが、解決策が未定
・改善したい数値と目標値は明確だが、解決策がアイデアレベル
・解決策がふわっとしており、画面が想像できない

言うまでもなく、6の方が難易度が高く時間がかかります。エンジニアはもちろん、必要に応じてCS、Salesの協力やクライアントへのヒアリングも必要です。数としては10〜20つ程度ありますが、よりOKRとの関連性が高いものだけを選ぶと3〜5になります。デザイナーないし、私が最も力を割くべきは「目的のみが明確」かつ「OKRとの関連性が特に高い」ものと言えるでしょう。

"やるべきこと"をやり遂げるために

"やるべきこと"が絞り込めたので、あとはやり遂げるだけです😃 やり遂げる気持ちが強い順に並べると、以下のようになります。

1. 「目的のみが明確」×「OKRとの関連性が特に高い」
2. 「目的も手段も明確」×「OKRとの関連性が特に高い」
3. 「目的のみが明確」×「OKRとの関連性はそこそこ」
4. 「目的も手段も明確」×「OKRとの関連性はそこそこ」

まずは、1を中心にざっくりスケジュールを組みます。この時に他職種とのスケジュール調整も行っておくと、協力を得やすいです。2は1を進めつつ息抜きに取り組んでいきます。

3.4は取り組まずに次の期に回すことが多いです。ただ4はエンジニア陣が実装する雰囲気を醸し出すことがあるので、その際は優先度を上げてUI設計をすることもあります😎

今はデザインしやすいか？

初期の苦悩を思っても、今はかなりデザインしやすいです！リリースのスピード感やエンジニアの動きやすさをそのままに、デザイナーのデザインしやすさを確立できたと思っています👏 何より自分の作ったものがすぐ世の中に出るので嬉しいです。

大分リズムが出来てきたので、2人目以降のデザイナーにも浸透させられるかが次のチャレンジポイントになると思われます。とはいえ人数が増えればチームのあるべき姿も変わると思うので、あまり今の形に固執しすぎる気もありません。柔軟に変えていけるのもまた楽しさですね🙌

さいごに

デザイナーさんの採用を頑張っているので、少しでも興味がある方は是非Twitterにご連絡ください😀 カジュアルにランチかお話しましょ〜。