この記事はSchoo Advent Calendar 2024の16日目の記事です!
こんにちは!株式会社Schooデザイン部門責任者の井上です。
デザイン部門責任者がなぜスクラム??とお思いになるかもしれませんが、これは完全に趣味というか得技です。普段は真面目にデザイナーとして働いていますが、実は僕、スクラムが大好きなんです。
前職でScrum Inc.認定プロダクトオーナーを取得して以来、スクラム思想のとりこになりました。
チームメンバーの輝きを仕組みで生み出し成果につなげる、そんな夢のような話がスクラムでは可能です。
今回は、マーケティングプロジェクトのチームにスクラムを導入した結果、すごく良い成果が出たという話をシェアします。
マーケプロジェクトがてんやわんやしてた
弊社には「ゼミ」というサービスがあります。いわゆるコホート学習型の研修サービスで、マーケチーム、ゼミ企画チーム、そしてデザイン部門が連携しながら集客用LPを制作していました。
しかし、この「ゼミ」という商品は当時まだ生まれたばかりで、試行錯誤が繰り返されるフェーズにありました。サービス内容が定まらない中、以下のような課題が発生していました。
- 事業的なリリース目標が決まっているが、LP制作を進めるための価値定義が固まらない
- デザイン部門主導で価値定義を進めるも、方針が二転三転
- リリースしても別の文脈でピボットの話が出て、また同じ課題を繰り返す
SchooはフルリモートOKということもあり、部門間連携には特に気をつけていますが、ステークホルダーが多い新規サービスの立ち上げは、情報連携が追いつかない場面が多々ありました。
この状況が3回ほど繰り返されたとき、ふとあるアイデアが浮かびました。
そうだ、スクラムしよう
これまでの課題を整理すると、デザイン部門、マーケ部門、ゼミ企画部門の3部署間の連携が、事業展開のスピードに追いついていないことが原因でした。
そのとき、「変化に順応する」というスクラムの強みを活かせば、この課題を解決できるのではないかと気づいたのです。
そうと分かった瞬間、「これ、僕なら3ヶ月で解消してみせます」と人生で一度は言ってみたいセリフベスト3に入るであろう発言をしちゃってました。
そのくらい、うまくいくビジョンが見えちゃったんですよね。
3ヶ月で後任に引き継ぐことを前提に、自分が暫定スクラムマスター(SM)としてチームを組成。翌週にはスプリントを開始しました。
具体的に何をしたのか
もともとの担当者をチームメンバーとして集め、説明会を実施しました。この場では、これまでの課題を共有し、それをスクラムでどのように解決できるか、そしてこれまでと何が変わるのかを説明しました。
その際に特に意識したのは、以下のポイントです:
過度に変化を強調しないこと
- 変化にはストレスが伴うため、変化にフォーカスしすぎるとアレルギー反応を示す方が出る可能性があります。そのため、「ちょっとミーティングが増えます」「タスクを少し細かく分解します」といったように、変化を小さく見せる伝え方を心がけました
誰かを責める伝わり方をしないこと
- 課題を共有する際も、問題を個人に帰するような伝え方は避け、建設的な議論が進むよう配慮しました
「スクラム」という単語をあまり使わないこと
- 手法が目的化しないよう、「スクラム」という言葉自体はあえて多用せず、課題解決と価値のリリースという本来の目的にフォーカスしました。手法にこだわりすぎると、理論やあるべき論を重視しすぎる人が現れる可能性があるためです
最終的に、目的は「スクラムをやること」ではなく、部門間連携の課題を解消し、「価値を迅速にリリースすること」だという点をチーム全体で共有しました。
メンバーもこれまでの課題は身にしみていたため、「まずはやってみよう」という空気感で始められました。
以降は通常のスクラムと同様、デイリーやプランニング、レビューなどの基本的なスクラムイベントをこなしていきました。
ただし、自分なりのスクラム成功哲学を徹底的にインストールしました。
それは「 見通しを良くすること 」です。
見通しを良くするためにやったこと
以下に挙げる施策は、通常の開発スクラムでも抜群に効果があります。
経験上、うまくいかないスクラムチームは、これらができていないケースが多いです。
逆に言えば、これを実践するだけで、価値を創出できるチームになれる可能性が高いので、ぜひ試してみてください!
作業見通しを良くする
-
今週やること、次週やること、まだやらなくていいことを明確化
- 待ちを発生させないことがスクラムにおいては重要。そのために直近数週間でやることは明確にしておく
- やらなくていいこと(優先度が低いこと)を明示しないと、「心配事」として脳内リソースを消耗し、パフォーマンスが低下する
- 「何をやらないか」を決めるのはメンバーにとって難しいため、スクラムマスター(SM)が率先してプロダクトオーナー(PO)に判断を仰ぐ
-
ストーリー内の子タスクを可能な限り細かく洗い出す
- 大きな粒度のタスクは、担当者の作業がブラックボックス化・属人化しやすく、進捗が追えなくなる。結果として、タスクが長期間未完了になる可能性が高い
- 「誰々と調整する」「何々の承認を取る」といったアウトプットを伴わないタスクも細かく洗い出し、スタックポイントを可視化することで、チームとして支援がしやすくなる
準備タスクの見通しを良くする
-
着手可能なストーリー(Ready)と、そのために必要な準備タスク(Spike)を明確化
- 準備タスクは調査や調整、承認が必要な場合が多く、1スプリントでは終わらないこともある。時間がかかる作業をチーム全体で認識しておくことが重要
-
準備が終わっていないストーリーは絶対に着手しない
- 準備が不足した状態で作業を始めると、手が止まってスケジュールに影響が出る。事前に必要な準備タスクを洗い出し、完了させておくことが必須
もやもやの見通しを良くする
-
分からないことをチーム全体で把握
- 毎日のデイリースクラムやレトロスペクティブで、疑問点を自由に発言できる雰囲気を作る
-
もやもやを個人に紐づけず、タスクに紐づける
- 問題を個人に帰属させると、「スキルが足りない」「理解力がない」といった他責的な議論になりやすい
- 「助けてやるよ」という精神ではなく、タスクの遂行に向けてチーム全体で課題に取り組む文化を育てる
- あくまで「タスク遂行のブロッカー」として課題を捉え、メンバー全員で「コトに向かう」姿勢を大切にする
これらの施策により、「今すべきこと」「事前に準備すべきこと」「今わからないこと」がチーム全体で共有され、業務の見通しが大幅に向上、チーム全体でコトに向かう空気ができました。
2〜3スプリント回した段階で、当初抱えていた課題は次々と解消。3ヶ月後には後任に引き継ぐことができました。
マーケチームだからこその工夫
これまで多くのスクラムチームを見てきましたが、アンチパターンとしてよく見られるのが「スクラムのお作法に囚われすぎる」ことです。
もちろん、抑えたほうがうまくいく勘所はあるのですが、あくまでケースバイケースです。
チームに合っていない「あるべき論」に振り回されワークしないケースは山のようにあるのが現状です。
スクラムガイドにも「スクラムフレームワークは意図的に不完全」とあるように、チームや業務内容に応じた柔軟な対応が必要ですし、チームのやり方をチームで決めることが自己組織化の第一歩です。
今回のマーケチームには以下のような改変を加えました。
見積もりの廃止
- LP制作はSTUDIOを使っており、実装作業における不確実性が少ないため、形式的な見積もりはやめて作業に集中しました。(※通常の開発スクラムでは見積もりは重要です!)
兼務の容認
- スクラムのベストプラクティスではPO以外は兼務しない方が良いとされていますが、マーケターやデザイナーなど組織横断で活躍するメンバーが多かったため、兼務を容認しました。チーム内でタスクと進捗が明確であれば問題ないと判断しました。
やってみて分かったこと
想像以上に、マーケプロジェクトとスクラムの相性が良いことが最大の発見でした。
マーケティングは、広告費を無駄にしないために超高速でPDCAを回す必要があります。修正回数も多く、納期も短い。その中で「長く愛されるもの」を作りたいデザイナーが担当になるとしばしば対立が生じます。
スクラムのフレームワークでは、変化を前提とした「共創」が可能です。同じチームメンバーとして「同じ釜の飯を食う」ことで、相互理解が深まりました。
まとめ
共創文化を育てるための土壌となるのが、スクラムというフレームワークです。
Schooでは「他者を尊重する・他者から尊重される人になる」を行動指針としてとても大切にしており、今回のプロジェクトが短期間で成果に繋げられたのも、「尊重姿勢をチームメンバー全員が持っていたこと」はとても大きいと感じています。
マーケプロジェクトでの実践を通じて、改めてSchooの尊重文化のありがたみと、それを活かしきる手段としてスクラムが最適であることを認識できた3ヶ月間でした!
We're Hiring!
Schooでは一緒に働く仲間を募集しています!
https://corp.schoo.jp/careers/graduates
https://corp.schoo.jp/careers