みなさん、こんにちは！🐥
SmartHRのコミュニケーションデザイングループ（通称：コムデ）でデザイナーをしているmasaです。
普段は、サービスデザインユニットというところに所属していて、サービスサイトやイベント周りのデザイン・アートディレクションなどを担当しています。
（👇 詳しいコムデの体制については、マネージャーのbebeさんがまとめているので見てみてね〜）
実は、2022年の8月から、サービスサイトの運用に「スクラム」を取り入れてみています。
1週間を1スプリントとして、やるべきことの可視化・日々のすり合わせと共有・振り返りをくり返す、というサイクルを回しています。
「スクラム」というと、プロダクト開発で使用される開発手法のイメージが強いですが、SmartHRではインサイドセールスチームもスクラムを取り入れています。
これまで、わたし自身スクラム未経験 & なんとなく上記のようなイメージを持っていたのですが、他チームの導入体験談を通して、スクラムが「さまざまなチームやプロジェクトで活用できる開発手法」であることを知りました。
ちょうどその頃、サービスサイトのチームでも体制拡大に伴う課題がぽつぽつと増えてきており、解決策が必要なタイミングに差し掛かっていました。
そこで「まさしく今抱えている課題を解決できそう！」と思い取り組んだのが、今回のサービスサイトでのスクラム運用です。
サービスサイトでは、プロジェクト内で企画する施策に加え、日頃から制作チームだけでなくありとあらゆるチームから日々依頼や相談を受けています。
持ち込まれるフェーズもまちまちで、まずはふんわりとした相談からという場合もありますし、すでに具体的なアイデアがある場合も。
1年前は4名だったチームのメンバーも、増えていく施策や依頼に伴い拡大し、今では倍の8名ほどでサービスサイトを運用しています。
（不定期にサポートいただいている社外のパートナーさんも含めると、メンバーは約14名ほどにもなります）
サービスや組織の成長に合わせてだんだんと依頼や施策が増え、それに伴いチームメンバーも増え、サービスサイト運用には以下のような課題が出てきていました。
■ 人が増え、情報共有や連携のハードルが上がってきた １. 一年間でメンバー数が倍に増え、スムーズな情報共有や連携が難しくなってきた ２. 契約形態によってSlackやDrive上で触れられる情報に差があり、認識のズレや動きづらさが生まれていた
■ タスクが増え、計画や調節のハードルが上がってきた ３. 同時進行するタスクの数が増えてきた上、タスクの優先度が明確になっていないこともあり、稼働量を安定させるのが難しくなってきた ４. 1〜3が組み合わさり、メンバーが全体的にオーバーワーク気味になっていた
例えば、これまでの定例ミーティングは、ずらりと並べたタスクを見ながら進捗確認などをしていました。
タスクもメンバーも少ないころは、この方法でも大きな認識のズレもなくスムーズに進行できていたのですが、だんだん「どれが特に優先度の高いタスクなのか判断しづらいなあ」とか「すべての施策の背景や動きを追うのは難しいかも…」という状況が生まれつつありました。
詳細は定例やSlack、都度のコミュニケーションでカバーしていました。
これまで起こっていた、共通認識化の難しさやオーバーワーク気味の状況を変えるために試しているのが今回のスクラムの運用です。
SmartHR内でスクラムに詳しいメンバーにも入ってもらい、以下のような準備・進め方をしました。
- スクラムの概念を直感的に理解してもらうためのオンボーディング
- 既存の進め方と並行しつつ、徐々にスクラム化していく
- タスクの優先度、工程、工数を可視化する
- メンバーがプロジェクトに割けるリソースの可視化と計画
（わたし自身を含めて）プロジェクト内にはスクラムに慣れていないメンバーがほとんどだったので、まずは「スクラムってどういうものなの？」を理解するための、オンボーディングからスタートしました。
そもそも、スクラムって専門用語も多いし、それぞれを理解して覚えること自体がハードル高そうだなあ…と感じていたので、それをどうにか分かりやすくできないか工夫するところから始めました。
そこで発明したのが、「肉じゃが・サラダ・みそ汁を作る」という架空のタスクです。 これらのタスクをモチーフに、1スプリント（1週間）の流れをオンボーディングしていきました。
スクラムで使われる、「リファインメント」や「スプリントプランニング」といったスクラムの専門用語も、
- リファインメント
- 私たちが作るべき料理はどんな料理だろう？（肉じゃがなら、しらたき入れる？仕上がり時のじゃがいもの硬さは？など具体的な設計まで）を決める
- そのために必要な工程＝レシピを話し合う
- スプリントプランニング（スクラムイベント内で実施）
- その週に作る料理を決める それぞれの調理工程の担当者と、工数を決める
- 毎日の朝会＝デイリースクラム
- レシピの進捗確認や相談、必要に応じて再度計画を立てる
といったように、ちょっと極端ですが、より身近でイメージの湧くモチーフを使いながら、チームのメンバーがスクラムをより理解できるようにしました。
（※この図では、振り返りにあたる「スプリントレビュー」「レトロスペクティブ」は省略しています）
準備段階で作成していたAsanaのカンバンボードにも「肉じゃが」の話を当てはめて、概念を紹介することにしました。 ボードのパターンも、より分かりやすい形を探るためセクションの区切り方違いで2種類用意しています。
まず１つめは、比較的ベーシックな構成のボード。
・一番左の「肉じゃがを作りたい」＝ 親タスク（固定で配置しておく） ・各セクションにある「野菜を切る」「具材を炒める 」= サブタスク（進捗が変わったら左右のセクションを移動させる） として考えることで、スクラムを直感的に理解しやすいようにしてみました。
そしてもう１パターン、ヨコ軸をステータスではなく、親タスク（作りたい料理）ごとに区切ったボードが以下です。
スクラムをやったことないメンバーにとっては、親タスクごとに一覧できるようにした方がわかりやすいかも？と思い、レイアウトを工夫したものです。
たくさんの既存タスクを一気にスクラムに移行するのは難しそうだったので、まずは1週目は全体のおよそ1割ぐらいのタスクからスクラムで運用してみることにしました。
まずは「これから企画や構成を詰めるフェーズのタスク」「制作フェーズに入ったばかりのタスク」など、密な連携が必要かつ、フェーズ的にキリがいいタスクをチョイスしています。
最初は優先度の整理やタスク分解自体にも時間がかかるので、慣れてきたら徐々に他のタスクもスクラムに移行していきました。
まずは、既存タスクの優先度を少しずつ整理しながら、これまで使っていたAsanaのプロジェクトボードをバックログとして使いやすいようアレンジしていきました。
そこから実際のスプリント計画を立てるまでの具体的な流れとしては、
1. バックログ用のボード内で、タスクの「優先度」や「工程」を可視化 2. その週に進行するタスクをスクラム用のボードに移して、「担当者」や「工数」を可視化
というように、移行のしやすさも踏まえて２つのボードを使い分けています。
ちなみに２つ目のスクラム用のボードは、先ほどの「肉じゃが」の例でご紹介したカンバンボードを指しています。
プロジェクトボードは、もともと使っていたボードをバックログ用にアレンジして活用しています。
細かな工程だけでなく、工数なども可視化しています。
また、チーム外のメンバーがボールを持っている場合も状況がわかりやすいように「関係者確認中」などのステータスのタグもつくっています。
あると便利そうなステータス表示は適宜増やしていくなど、取り組みながらより使いやすいボードになるようアップデートしていく予定です。
タスクやその優先度の可視化はもちろん、オーバーワークを避けるために、各メンバーが稼働できる時間も可視化するようにしました。
メンバーのGoogleカレンダーから会議の予定などを除いた時間を計算し、スプレッドシートに反映しています。
ここの数字を参考にしつつ、他プロジェクトで稼働が必要な分はさらに差し引いたりして、自分の動ける時間を毎スプリント可視化しています。
ちなみに、リソース計算機は、インサイドセールスのチームが使っていたものをベースにしています。ありがとう〜🤝
さらにSlackと連携して、毎朝その日のメンバー全員の作業可能時間が通知されるように設定。
メンバーがその日に動ける時間を把握するためだけでなく、諸連絡用のスレッドとしても活用することで、コミュニケーションのハードルを下げる工夫も兼ねています。
先日ちょうど実際に5週（5スプリント）分を終え、まだ細かな課題はあるものの、結論としては「今後も継続してスクラムに取り組む」ことになりました 🙌
初回は全体の1割ほどのタスクからはじめたスクラム運用でしたが、順調に移行が進み今では7割ほどのタスクをスクラムで運用しています。
そんな中で、よかった点も今後の課題もそれぞれクリアになってきました。
当初の大きな課題であった、共通認識化の難しさやオーバーワーク気味の状況が改善しつつあります。 やったー。
🎉 認識のズレが減り、制作進行がスムーズに タスクの分解や計画・進捗共有を全員でやることで認識が合うようになり、連携や進行がスムーズになりました。
「心理的にも動きやすくなった・負担が軽減された」という声も多く上がっていたのも嬉しい点でした。
🎉 オーバーワーク状態が解消されつつある 優先度・工程・工数が可視化されたことで、限られたリソースで自分たちが「やるべきこと」「できること」が明確になりました。 リソース内で収まる計画を立てることはもちろん、状況が変わった場合には朝会などですぐに相談・調節できる環境ができています。
とはいえ細かな課題も色々あり、最近は以下のような課題に直面しています。
🤔 細かいタスクも多く、タスクの分解や担当者決めに時間がかかる → トライすること：事前準備として、手分けしてタスクを細かく分解しておく。リファインメントでは、それを眺めながらみんなで議論する。
🤔 期限付きのタスクが思いのほか多く、重なるとつらい → トライすること：期限を意識した上で優先度付けをして、そもそも重ならない運用をする。重なっている場合はボリュームを調節する。動けるものは早めに動く。
🤔 そして、期限付きのタスク分解が甘いと結果オーバーワークになる → トライすること：リファインメントでのタスク分解は念入りに。他チームに重要な関係者がいる場合は、その人にもリファインメントに参加してもらい一緒にタスク分解をする。
ちなみに、スクラムのいいところの1つは、フレームワーク内に振り返りの機会（レトロスペクティブ）が組み込まれているところだな〜と思います。
現在もそれぞれの課題に具体的な解決策を打ち、実際にトライしていっているところです。
各自が特に共感した内容に絵文字🍻をスタンプとして配置しました。
ちなみに、絵文字の内容は毎回変えたりして、ちょっとしたことを楽しみつつみんなでワイワイ進めています。
取り組みはじめたばかりの頃は、スクラムに不慣れなメンバーがほとんどだけど大丈夫かな？とか、サービスサイトという媒体向けにどこまでアレンジできるのかな？などの心配もあり、ドキドキしながら進めていました。
しかし、今では少しずつスムーズに回るようになり「スクラムに取り組んでみてよかった〜」と手応えを感じられるようになってきています。
チームの皆さんにとってもドキドキな部分があったかと思いますが、前向きに一緒に試行錯誤しながら取り組んでくれて大感謝です。 そしてサポートしてくださったチーム外のメンバーの皆さんにも大感謝です。
サービスや組織の成長に伴った変化はこれからも続くと思いますが、その時々に合った方法にフレキシブルに取り組むことは、とても有意義なことだなと思いました。
これからも、より効率的で持続的な運用体制をみんなで作っていきたいです。 （いまある課題の解消についても、引き続きやっていくよ🏋️♀️）
最後まで読んでくださりありがとうございました。
またね〜👋