デザイン品質を諦めないための挑戦：スクラムで見つけたリソースコントロールの形
概要
こんにちは！株式会社mikanでデザイナーをしているナガタキです🍊
これは、Spectrum Tokyo Festival 2024の発表資料です🙌
当日聞きに来てくださった方々、また参加できなかったけどもトピックが気になる方向けにアーカイブとして残したいと思います。
当日触れられなかった詳細も少し加筆しています。
登壇後や懇親会で前のめりに質問しにきてくださる方々もいらっしゃって、「みんなリソース管理、深刻に悩んでいるんだな🥺」と痛感させられました。いただいた質問と回答も最後に一部載せますので、困っている方のお役に立てたら幸いです。
ではでは、ここから発表内容スタートです👇
改めまして、株式会社mikanでデザイナーをしているナガタキです！
ヤフー、ギフティを経て、2021年の10月からmikanで働いています。
現在はtoC事業の「英語アプリmikan」のデザイン全般を担当しています。
さて、今回皆さんとシェアしたいのは、デザイナーのリソース管理についてです。
こんな流れで進めていきます。
まず、なぜこのトピックをここに持ってきたのかに繋がる、私の理想と現実の葛藤を先にお伝えさせてください。
理想に反して計画通りにいかない日々の葛藤
私は、デザイナーとして7年働く中で「デザイン品質に自信を持って世に出していきたい」という思いを持ってやってきました。"品質とは"っていうとまた別議論にはなると思うんですが、私は見た目も体験も、細部まで配慮が行き届いたものだと思っています。
ただ、現実は厳しいなと、常々感じています。
長いこと戦ってきましたが、わかりやすく2年前から変化を追っていきます。
もうですね、目の前のタスクで一杯一杯だったんです。
さっきの理想はどこへやら「まずは出すことが大事」が口癖でした。
色々やりたいこともありつつ、「いつか解決したいもの」として積み上がっていくばかりでした。これは今思うと、仕組み自体が構築できていないことも原因だったと思います。
当時のタスク管理は、1施策につき一人のデザイナーがアサインされていて、notionで個人個人が管理していました。
この時の課題として、この2点がありました。
🌀順調か不調かが施策担当者本人しか分からなかった
🌀溜まっている施策外のものは、「手が空いた時にやる」という立て付けになっていてほとんど機能していなかった
目の前のタスク以外に取り組む余力を持つためには、何か手を打たねばなりませんでした。
改善までの段階について改めて今回用にまとめたのですが、大体3ステップあったと思います。
まずは計画したものを計画通りに完了する、次に施策外のタスクも計画に組み込む、そして最後に、タスクの許容量を増やすという段階です。
当時はまず、計画したものを計画通りに完了するというところからスタートする必要がありました。
では次に、リソース管理に向き合うきっかけとなったタスク管理方法の変更に関して紹介していきます。
スクラムlikeなタスク管理への挑戦
1年後の2023年。
開発チームが先行して使っていた「Linear」というタスク管理ツールに、アプリ開発の合同チーム全体で移行する動きがありました。ここにデザインチームも入っていました。
私たちはここで、タスク管理をnotionからLinearに移すことになります。
Linearはアジャイル開発に特化したプロジェクト管理ツールでした。
開発チームはスクラムを導入しており、同じような流れの方が動きがわかりやすそうという狙いもあり、デザインチームもお試しでスクラムlikeな概念を導入してみることになりました。
元のnotionとlinearでの大きな差は完了期限、見積もり、調子の確認にありました。
完了期限は納期での管理から「サイクルと納期」になりました。
サイクルはmikanでは5営業日で定義していて、これを1つの区切りとしています。
次に見積もりですが、元は営業日でした。これが「ポイント」という新しい概念になっています。ポイントは「重み」ですね。これで工数の大きさを測るようにしています。
調子の確認に関しては今まで「完了したかどうか」でしかみていなかったところを、予定と実施にすることでプロセスまで見るようにしたというものになります。
具体的にどういうふうに可視化されるのかお見せすると、
こんな感じですね。何やら難しいグラフになりましたね。笑
このグラフは時系列になっていて、左がサイクルの始まり、右が終わりになっています。真ん中の点線が「理想の曲線」だと思ってください。
これは導入初期のグラフで分かる方にはわかるかなりお恥ずかしい内容なんですが、見方が難しいと思うので、具体的に問題点を解説してみます。
例えばここ、グレーが計画の線なんですが、サイクルが始まって序盤にすでに破綻してます。笑
さらに、理想の点線を境に黄色い線と青い線が大きく離れてますよね。これは「スタートはできているのになかなか完了できない」状態です。
これだと最後の最後まで完了するかわからず、不安になっちゃいますよね。
グラフはご覧の通り目も当てられない状態だったんですが、型にはめたことで問題が浮き彫りになってきました。
まだまだ「計画を計画通りに」の道のりは長いです。
ここからは、どう解決していったかを話していきます。
根本的な課題の特定と解決アプローチ
解決したのは、今年に入ってからです。なのでホットトピックですね。笑
まず現在の姿からお伝えしたいと思います。
これが、最近のグラフです。
かなり理想の点線のエリアに沿ってきたことがわかるかなと思います。
このグラフは１サイクルのみの結果ですが、
単発のサイクルだけでなく、平均してどのサイクルでも、90%~100%の完了率まで引き上げることに成功しています。元々は6割ぐらいだったので、大きな進歩です。
計画が計画通りに行くようになってきた、と言えると思います。
これによって、やりたかった次のステップの「施策外タスク」も計画対象に入れられるようになってきています🙆♀️
さて、この1年で何があったんでしょうか？
一番大きな転機は、うまくやっていそうなチームにSOSしたことでした。
スクラムをデザイナーがやっている事例を外部から探すのが難しかったのですが、うまくいっている社内の人に聞けばいいんだと気づきました。
我々の場合、バックエンドチームが毎回好調な様子を見ていたので、声をかけさせてもらいました。
バックエンドチームのメンバーに先ほどのようなデザインチームの悩みを伝えて、どんなふうに見積もりしているのかなどをヒアリングさせてもらいました。
この場で、３つのアドバイスをもらいます。若干想像しづらいと思うので１つずつ説明していきますね。
1. 基準ポイントをチーム内で持つといい
元々のデザインチームは、チーム内の個々人でタスクの重さの考え方が違いました。こうなっていると、その人にしか見積もりができないんですよね。
それを、共通の最小単位を定義してレビューし合えるようにしました。
この基準をどうやって定義したかというと、
WSを開催しました。先ほどアドバイスをくれたエンジニアさんにも参加してもらい、適宜聞ける状況を作って行いました。
WSでは、チームのタスクの重み付けのずれがどこにあって、どこは一緒なのかを探しました。
やってみて、かなり感覚にズレがあって面白かったので、このあたりにつまずいている方にはとてもおすすめです。
2. "暗黙的なタスク"もすべて登録した方が良い
当時は施策タスク以外は登録しないで個人で管理するような感じになっていました。これによって、不透明な何かが原因で他のタスクが遅れる…というような事象が発生しがちでした。
そこですべて登録して、どんなに些細なタスクでも工数を見積もるようにして原因が明確になるようにしました。
3. 平均稼動実績を計算して1週間のタスク量を決めるといい
これは結構具体的すぎて難しいかもしれないですが…
元々は「前のサイクルで消化したポイント」で見積もっていたんですね。ただ、施策や状況によってかなり振れ幅があるのでほとんど信用できないものだったんです。これが悩みの種でした。
解決策として、稼働日を基準に事実ベースで使えるリソースを計算するようにした、というのがざっくりとした改善内容になります。
（発表の兼ね合いで当日は割愛してしまったんですが）せっかくなので具体計算サンプルも載せておきます👇
祝日やお休みが決まっている場合は事前に稼働日を引いて計算（採用等でほとんどデザイン稼働ができない日も含む）。
また、急な体調不良があった際も、復帰した日に再調整して立て直すという作業をやっています。
そんなわけで、この3つのアドバイスを実施したことで、私たちデザインチームは少しずつ “ぶれない参照点”を作ることができていったんですね。
アドバイス実施後、ここまで改善されました👏
ただ、引いてみるとまだ完了率にばらつきがあり、60%~100%を行ったり来たりしていました。この揺らぎをもう少し減らしたい、と思っていました。
さて、この揺らぎは何によって発生するのでしょうか？
[+α改善] サイクルの完了率が揺らぎやすい原因を探す
分解してみると、だいたいこの2つの原因にぶつかることが多いとわかりました。
1つが前提を覆すような大きな方針の変更であったり、考慮漏れですね。
もう一つは差し込みの発生です。
両方、あるあるなんじゃないでしょうか。笑
私はこの解決策をデザインチーム内だけで解決するのは厳しいと判断しました。そこで、
PMとの連携を強固にすることで、解消できないかと考えました。
1.前提を覆すような大きな方針変更、考慮漏れ
元々は施策のキックオフの内容を受けて、デザイナーが画面数などで見積もりをしていました。ただ、実は気づいていない論点があったりして、途中で画面がいらなくなったり必要になったり、意思決定による依存性が高いもので見積もってしまっていました。これを、”不確実なもの”を洗い出す方に変えました。
依存関係をPMと一緒に整理し、論点を潰し切ることをタスクとしました。
これによって不確実性が減ったので、アクシデントを減らすことができました👏
2.差し込みの発生
元は開発に関連するものだけ、PMと優先度をつけるようにしていました。
ただ、デザイナーの仕事上開発に関わるもの以外も依頼をいただきます。
その際に全ての優先度が高くなるような状況が発生し、余力がなくなりやすくなっていました。
そこで、開発以外の依頼も含めて、PMと優先順位を相談するようにしました。
これによって、デザイナーからアラートを上げやすくなりました。
そして、！！！！
1サイクルのタスク完了率が9割を安定して推移するようになりました🎉
ここまででようやく「計画したものを計画通りにやる」のステップを、
クリア！！したわけですね。
そして、次の目標「施策外のタスクも計画に組み込む」に向けてやっていきます。
これに関してはやったことはかなりシンプルです。
施策外のタスクも計画に組み込む
1. 仕組みづくり
まず、施策外タスクに頻繁に目を通せる仕組みを作りました。
デザイナー向けの課題提案場所を用意して、デザインチーム朝会で確認するようにしています。
そしてもう１つ。
2. 比率決め
計画時の施策と施策外タスクの割合も決めました。
基本は施策8割、施策外2割の想定でリソース配分するようにしています。
これによって、意識的に施策外のタスクを入れるような体制になりました。
ここまできて、施策外で優先度の高そうなタスクを配慮した計画にできるようになりました。
少しあっさりしていましたが、施策外のタスクも計画に組み込むというミッションを…
達成！できました👏
やはり計画を計画通りにやる壁が厚すぎましたね。
そして3つ目、タスクの許容量を無理なく増やすという目標に向かっていきます。
これは現在も取り組んでいる最中なのでおまけ程度ですが、嬉しい効果が出ているので紹介します。
チームでタスクを消化できる量が、始めた頃から約2.5倍になりました👏
その分できることが増えているということなので、これは嬉しい！！
まとめ
長くなりましたが、こうしてリソース管理にしっかり向き合ったことで、日々のタスクに精一杯だった2年前から抜け出せて、+αでやることを考える余力を持つことができるようになりました。
さて、おさらいです。
元は、こんな階段がありますねーとお話ししていました。
一つ目の階段の登り方として、最初のステップは可視化でした。私たちは「スクラムlike」な手法でやっていきました。
さらに可視化して見えてきた問題の原因究明を行いました。
そして、ロールモデルを見つけて真似をさせてもらいました。私たちの場合は、社内のバックエンドチームです。
そして施策外のタスクを組み込むにあたっては、まず必ず目に触れるように仕組み化しました。
そして、
リソースの比率を決めました。
今日の成果としてはここまでですが、タスクの許容量を無理なく増やすことにも引き続き挑戦して、よりプロダクトの体験向上と品質改善に取り組んでいけるといいなと思っています🔥
同じように困っているデザイナーさんがいたら、ぜひ試してみてください！
ご清聴ありがとうございました！
いただいた質問抜粋
"不確実なもの"を洗い出すのが大事なことは分かりつつ、難しい。
何か工夫していることはありますか？
A. PM向けに事前に埋めてきてもらう施策チェックリストを作っています（ターゲットユーザーのシーン想定、メイン・イレギュラーユースケース、デザイナーと何を決めたいと思っているかなど）。キックオフの内容とそのチェックシートを参考に、考えきれていない部分がないかPMとディスカッションして見つけていきます。
※ここでは公開できないですが、気になる方はカジュアル面談しましょう。笑
ポイントの単位はどう定義してますか？
A. mikanでは1,2,3,5ptにしています。
1pt=やることが決まっていて作業量も少ないもの。
2pt=やることが決まっていて作業量はあるもの。
3pt=考えて作る必要があるもの。
5pt=（滅多にないが）3ptより難易度の高い、考えて作る必要があるもの。
正直5ptはほぼ使ってないですね。タスクが大きくなりすぎると「分解できていない」ということにもなるので、MAX3ptで考えていることが多いです。
ポイントの重さは時間で考えているんですが、単位の考え方が難しく..
A. 時間換算に関しては、mikanのデザインチームでは禁止にしています。タスクにどの程度時間がかかるかは、人に依存しやすいためです。
あとがき
今だから公に言いますが、実は今回、人生初の登壇でした…笑（震え）
自分の緊張を少しでも無くしておくために、社内でも全5回のデモプレゼンを実施。任意参加にも関わらず、毎回聞きに来てたくさんのフィードバックを書いてくれていたmikanメンバーには心から感謝しています🙏✨
そのおかげもあり、緊張しすぎずに本番に臨むことができました。
当日、想像以上にたくさんの方が聴きにきてくださって、胸が熱くなりました。AMAでも時間いっぱいまでたくさん質問いただけて、チャレンジしてみてよかったなと思えました🤝
素晴らしいデザイナーの皆さんと共にスピーカーに採択していただけて本当に光栄でした！
運営の皆さん、素敵な機会をありがとうございました🍺
＼🙌ご参加ありがとうございました🙌／
— Spectrum Tokyo (@spctrm_jp) December 9, 2024
Spectrum Tokyo Festival 2024大成功に終わりました！ スピーカー、スポンサー＆パートナーの皆さま、そして何よりご参加いただいた皆さま本当にありがとうございました❣️
イベントでの思い出をぜひタグ付けください👇#spectrumfest2024 pic.twitter.com/CYdrcGFrHt
We are Hiring!
mikanでは現在私たちと一緒にプロダクトを成長させてくれるデザインマネージャーを大募集しています！
お客様との接点の99%がプロダクトを通して行われていて、それで会社も成り立っているので手触り感を持って向き合える環境がある
デザインの影響度が非常に高い
事業のキードライバーになっている
と、デザイナーにとって非常にチャレンジングな環境です🔥
少しでも「いいな」と思ってくださった方は気軽に私のXアカウントやYOUTRUSTからお声がけください！（もちろん直接応募でも！笑）
mikan Advent Calendar 2024も開催中🎅🎄
いろんな職種のメンバーの思考が覗けるのでぜひ見てみてください🍊