株式会社エイチームライフデザイン所属 デザイナーの @AreUtoo と申します。
Ateam LifeDesign Advent Calendar 2023 シリーズ3の17日目を担当します！
本記事の概要
主に以下のような内容が記載されています。
- デザイナー兼企画者としてスクラム開発体制を採用したプロジェクトにどのように参加していたか
- スクラムイベントや業務で生じた課題と、それに対する解決アプローチとして実行したこと・考えていたこと
- 今後スクラムチームに参画する場合、どのような取り組みやチャレンジをしたいか
今回はデザイナー兼企画者としての視点からスクラムへの参加を振り返っています。エンジニアやプロダクトオーナー（以下、POと表記）の視点とは異なる見方も含まれているかもしれません。その点、ご了承ください。
この記事で取り扱う内容・取り扱わない内容
取り扱う内容
- 自身が参加したスクラムチームでの課題とその解決アプローチの事例
- 経験に基づく個人的な見解
取り扱わないこと
- スクラムの基本的な知識や用語（各種スクラムイベントや役割等）の説明
- スクラムについての一般的な理論や普遍的なアドバイス
参加したスクラムチームの体制
私が参加していたプロジェクトでは、前半と後半でチーム規模やデザイナーとしての関わり方が異なっていたので、それぞれについて説明します。
前半
チーム体制
- スクラムチーム
- PO: 1名
- スクラムマスター（以下、SMと表記）: 1名
- 企画者: 1名
- エンジニア: 約10名
- ステークホルダー
- UIデザイナー（👈 ここに参加！ ）
- UXリサーチャー
- 営業
- マーケ
- カスタマー
デザイナーとしての関わり方
- デザイナーとエンジニアは別々のスプリントバックログを使用
- デザイナーはスクラムチームのメンバーではなく、ステークホルダーとして位置付けられていた
- スクラムイベントは、基本的にスプリントレビューにのみ参加
- 必要に応じてリファインメントに参加
- デイリースクラム、スプリントプランニング、レトロスペクティブには参加しなかった
後半
チーム体制
- スクラムチーム
- PO: 1名
- SM: 1名
- UIデザイナー兼企画者: 1名（👈 ここに参加！ ）
- エンジニア: 5名
- ステークホルダー
- UXリサーチャー
- 営業
- マーケ
- カスタマー
デザイナーとしての関わり方
- デザイナーとエンジニアは同じスプリントバックログを使用
- デザイナーはスクラムチームメンバーの一員として参加
- スクラムイベントはデザイナーも全て参加
- スプリントプランニングにおけるプランニングポーカーはエンジニアのみで実施
後半ではチームが小規模になり、私は企画者を兼任しながら、デザイナーとして各種スクラムイベントに参加するようになりました。
スクラム開発における課題と解決アプローチ
「最終的にはこのように運用していた」という内容を書くよりも、「このような課題があり、それをこのように解決した」というアプローチを記述する方が、同じ課題に直面している方々の参考になると考えました。
したがって、各課題を個別に取り上げ、それぞれに対する解決策を逆引き形式で記述します。
▼ デザイナーとエンジニア間でタスク状況が見えづらい
▼ 要件の整理が不十分で仕様漏れが起きやすい
▼ スクラムイベントが多く作業時間を確保しづらい
▼ 職能間で使う言葉がバラバラでコミュニケーションコストが高く、誤解が生じやすい
▼ 1施策の規模が大きすぎて、1スプリント内で成果を出しづらい
▼ スプリントレビューでステークホルダーからプロダクトに対するフィードバックが得られない
▼ エンジニアとビジネスサイドの間でのストーリーポイントの理解の違い
▼ デザインがない状態での開発は、仕様の確認漏れやコミュニケーションコストが大きい
デザイナーとエンジニア間でタスク状況が見えづらい
📝 課題
前半期では、デザイナーはスクラムチームに参加せず、エンジニアとは別のスプリントバックログを使用してタスク管理を行っていました。
この状況は、デザイナーとエンジニアの作業工程がずれており、共通のスプリントゴールを設定することが難しかったためです。
エンジニアがAの施策の実装を進めている一方で、デザイナーは次に控えているBの施策のデザインを行っているという状況がよくあります。
エンジニアはAの施策の開発完了を目指し、デザイナーはBのデザイン制作完了を目指すため、1スプリント内で共通の成果物をゴールとすることが難しかったのです。
しかし、タスク管理を別々に行うと、デザイナーとエンジニアの進捗状況が見えづらくなり、結果として足並みが揃わなかったり、相談や確認などのコミュニケーションコストが増えてしまいます。
💡 解決アプローチ
1. デザイナーもスクラムチームに参加し、各種イベントに出席する
デイリースクラムやレトロスペクティブなどのイベントにデザイナーも参加することで、タスクの進捗状況の把握や開発連携のPDCAがスムーズに行えるようになりました。
2. 同じプロジェクトでバックログアイテムを管理する
デザイナーとエンジニアが別々に管理していたバックログを一元化することで、そのスプリントで互いがどのようなタスクを行っているかが明確になり、適切なタイミングと頻度で相談や確認が行えるようになりました。
3. スプリントゴールとして複数の目標を設定する
共通のゴールを設定することが難しい場合、複数の小さなゴールをスプリントゴールとして設定することにしました。
例）〇〇の施策の開発完了、〇〇のデザイン仕様fix、〇〇のQA完了など
ゴールを小さく分けることで、1スプリント内での成果が明確になり、各メンバーがどのゴールに向かって何を行うべきかがはっきりと理解できるようになりました。
要件の整理が不十分で仕様漏れが起きやすい
📝 課題
企画書やデザインを作成する段階で、要件が完全に網羅されていることは稀です。
そのため、リファインメントというプロセスを通じてこれらの要件を補完します。
しかし、前半期では、POとエンジニアが企画概要に基づいて質疑応答を行うというリファインメントのフローは実施していましたが、ドキュメンテーションの文化が浸透しておらず、口頭での情報共有が主流でした。
また、当時はデザイナーや集計分析を担当する企画者がリファインメントに参加していなかったため、QA段階で新たな仕様が必要だと判明することもありました。（特に、弊チームではABテストの集計周りの仕様が漏れがちでした…）
💡 解決アプローチ
企画者とデザイナーが同時に編集可能なドキュメントに事前に内容を書き出し、リファインメントですり合わせる
弊チームでは後半期からScrapboxというドキュメンテーションツールを導入し、そこに施策ごとの企画概要、エピック、デザインデータのリンクなどをまとめる運用を開始しました。
書き出した内容を基に、リファインメントで企画者、デザイナー、エンジニアが集まり、不足している仕様、懸念点、解決策などを議論し、その結果をドキュメントに整理します。 Scrapboxは複数人が同時に編集できるため、リファインメント中に全員が自由に追記や修正を行うことができ、この解決アプローチの実施に非常に役立ちました。
また、POは常に忙しく、リファインメントに参加するのが難しいことが多かったのですが、 そのような場合でも、後日Scrapboxのドキュメントを共有することで、どのような議論過程を経てその仕様に至ったのかを把握しやすく、非同期で仕様の調整を行うことも容易になりました。ドキュメンテーションの効果は非常に大きかったです。
スクラムイベントが多く作業時間を確保しづらい
📝 課題
デザイナー兼企画者としてスクラムチームに参加することで多くの改善を達成できましたが、一方で、多くのMTGが開催されるため、作業時間が削られるという課題がありました。
💡 解決アプローチ
各種イベントの頻度や参加方法を最適化する
私のチームでは、後半期にはリファインメントを毎週開催するのではなく、必要に応じて開催するようにしました。 半端な要件の企画書をもとに議論を急ぐよりも、きちんとした企画書が完成してから議論を行う方が効率的であり、要件や仕様の漏れも少なくなります。
また、スプリントレビューも毎週開催するのではなく、プロジェクト全体のMTGに組み込む形式に変更しました。
さらに、プランニングポーカーは開発者だけで実施するなど、各イベントに必要な参加者だけを集めるという工夫も行いました。
それぞれのイベントで削減できる時間は少ないかもしれませんが、積み重ねることで一定の最適化が達成できたと感じています。
職能間で使う言葉がバラバラでコミュニケーションコストが高く、誤解が生じやすい
📝 課題
これはスクラム開発に限らず一般的な課題かもしれませんが、 職能間での共通言語が不足しているため、機能の仕様やデザイン・実装の設計について相談する際に、話が噛み合わなかったり、議論の進行が遅くなるといった課題が生じていました。
例）
企画者「hoge施策をリリースしたときに実装していたfuga機能についてですが......」
エンジニアA（hoge施策ってver1.0のことかな......？）
エンジニアB（hoge施策のときに追加したのはX機能とY機能があるけどfuga機能ってどっちの機能ことだ...？）
💡 解決アプローチ
ユビキタス言語を策定し、日常のコミュニケーションで使用する
「ユビキタス言語」とは、エンジニアやドメインエキスパートを含むチーム全体で使用される共通言語のことです。
ドメイン駆動設計(DDD)との格闘 - ユビキタス言語には不屈の闘志が不可欠より引用
ドメイン駆動設計(DDD)では、ユビキタス言語を使おうというのは、ubiquitous ： いつでもどこでも偏在する というこの単語から想像されるように、『みんなで』同じ言葉を使いましょうねということです。みんなで同じ言葉を使って、読み、書き、話しを、すれば、意思疎通しやすいよね。というとても簡単な話です。
私の参加したプロジェクトでは、私がデザイナー兼企画者だったため、まずは私とエンジニアの皆さんで共通言語を決定するという取り組みを開始しました。
そして、ここでもScrapboxが大活躍しました。
取り組みは以下のように行いました。
- 日々のMTGやドキュメンテーションの中で、ユビキタス言語として定義すべき言葉を見つける
- デイリースクラムで、新しくユビキタス言語として定義したい言葉とその定義を共有する
a. 定義や使用する言葉をもう少し検討すべき場合は、別途MTGや非同期で議論を行う - 最終的に使用する言葉と定義が決まったら、その内容でScrapboxに新しいユビキタス言語としてページを作成する
- エンジニアやデザイナーは、ここで定めたユビキタス言語を開発時のコミュニケーションとコードの中で使用する
a. 英語名も追加し、開発時にはそれを使用する - 誤用を見つけたら指摘し、修正する
Scrapboxでは任意の語句をブラケティングすることでその語句のページを作成・各ページにリンクさせることができるため、ユビキタス言語策定の取り組みにおいて非常に便利なツールでした。
1施策の規模が大きすぎて、1スプリント内で成果を出しづらい
📝 課題
前半期では1スプリントを1週間として運用していましたが、 実施したい施策はどれも1週間の開発で終わるようなものではなかったため、スプリントを超えて続くストーリーが多く、1スプリント内での成果をスプリントレビューで共有するというフローが困難でした。
また、1つの施策の規模が大きいため、PDCAのサイクルが重くなり、結果としてプロダクトの成長も鈍化してしまうという課題もありました。
💡 解決アプローチ
1. チーム全員で、できるだけ小さい仕様で小さく検証できるように考える
後半期のチームでは、いわゆるMVP開発のような考え方を導入しました。
リファインメントでは、企画者が検証したい内容をメンバーに伝え、全員でその検証をできるだけミニマムに実現できる実装方法を考えます。
企画者自身が考えもしなかったようなアイデアをエンジニアが提案してくれることもあり、この方法を取ることで、チーム全体が一丸となってプロダクトについて深く考えるきっかけになったと感じています。
2. 1スプリントを2週間に変更する
1スプリントを2週間に変更したことで、スプリントを超えて続くストーリーが減りました。
同じプロダクトでも、初期リリース直後とグロース期では施策の規模感が変わるので、プロダクトのライフサイクルに応じてスプリントの期間は柔軟に変更できると良いかもしれません。
また、1スプリントを2週間に変更したことで、週あたりのイベントの数が減り、「スクラムイベントが多く作業時間を確保しづらい」という課題の解消にもつながりました。
3. 施策をエピックで作成し、1スプリント内で完了できるボリュームにストーリー・タスクを分割する
前半期までは1つの施策をエピックではなくストーリーとして作成し、その中に小課題を作って運用していましたが、これをエピックとして作成する運用に変更しました。
エピックを実現するために必要な対応を複数のストーリー・タスクに分割することで、1スプリント内でストーリーが完了しやすくなり、繰り越しが減りました。また、施策のリリースまでの残タスクの内容がスプリントバックログ上でわかりやすくなりました。
スプリントレビューでステークホルダーからプロダクトに対するフィードバックが得られない
📝 課題
前半期ではスプリントレビューは以下のような体制で行っていました。
- 参加者はスクラムチーム（開発者・SM・PO・企画者）とステークホルダーの各職能から代表1名ずつ
- 成果物の概要を開発者から共有し、QAテストを依頼する
- 参加者から質問があればその場で回答、それ以外の時間は黙々とテストを行う
この形式では、レビューというよりは開発者からの一方的な発信になってしまい、 フィードバック（以下、FB）もQAテストに関する内容が中心となり、「プロダクトとして、もっとこうあるべきではないか？」という意見があまり出てきませんでした。
また、参加者がステークホルダーの代表者数名であったため、プロジェクトに参画しているメンバー全員がリリースされたプロダクトの機能を把握できていなかったり、リリース後のKPI変化について関心が薄いという課題もありました。
💡 解決アプローチ
1. 「QAを依頼する場」から「プロダクトのお披露目会」というコンセプトに変更
QAテストは必要なタイミングで随時依頼を行う運用に変更し、スプリントレビューは「プロダクトのお披露目をする場」として実施することにしました。
これにより、QAではなくプロダクト自体への感想や質問が中心となり、FBが活性化しました。
2. 実施する場をプロジェクト全体のMTGに組み込み、全メンバーに見てもらうように変更
当初は代表者のみをMTGに呼んでいましたが、実施の場をプロジェクト全体のMTGに組み込むことで、プロジェクト関係者全員からFBをもらえるようになりました。
ただ、参加人数が多い場では口頭での感想共有や質問はしづらい傾向があるので、Slackのスレッドで「お披露目会 感想用スレッド」を作り、そこに感想や質問を書き込んでもらうという仕組みも設けました。
さらに、リリース後のKPI変化について共有するコーナーも設け、プロジェクトに関わる全メンバーがプロダクトの成長を一緒に追いかけやすくなりました。
ここから先は、解決アプローチとして検討されていたが、まだ試行中または実践前だったものを記載します。
エンジニアとビジネスサイドの間でのストーリーポイントの理解の違い
📝 課題
スクラム開発ではプランニングポーカーでタスクの見積もりを行いますが、この見積もりが企画者やステークホルダーに伝わる際に、「見積もり時間」として解釈されてしまう課題がありました。
ストーリーポイントが見積もり時間として解釈されると何が問題かについては、同じチームの@junseinagaoさんが書いた記事が非常にわかりやすいので、ぜひ参照してみてください。
💡 解決アプローチ
1. ストーリーポイントはリリーススケジュールを見積もるものではないという共通認識を持つ
ビジネスサイドは「いつリリースできるか」に関心があるため、ついストーリーポイントを時間換算した内容を知りたくなる傾向がありますが、ストーリーポイントは開発者がストーリーの規模を相対的に見積もるための概念であり、実際の時間的見積もりとはズレが生じる可能性があるということを、企画者を含むステークホルダーと共有することが重要だと考えています。
余談ですが、私たちのプロジェクトのSMが「ストーリーポイントはベロシティを測るためのもので、ベロシティは開発チームの総合戦闘力のようなもの」と表現していたことがあり、それは非常に理解しやすいと感じました。
2. リリーススケジュールは別途管理する
しかし、リリース時期の見積もりも必要です。そのため、ストーリーポイントとは別に「エピックタイムライン」でスケジュール管理をするのが良いという提案がありました。
エピックタイムラインは、デイリースクラムやプランニングで進捗を確認しながら、都度調整する運用を想定しています。
デザインがない状態での開発は、仕様の確認漏れやコミュニケーションコストが大きい
📝 課題
リリースのスピードを優先するために、デザインが完全にFixする前にロジック部分の開発を開始するという状況が生じていました。
このアプローチは問題ない場合もありますが、デザインが完成して初めて気づく要件の漏れや追加が必要な仕様も存在します。
💡 解決アプローチ
デザインが一定程度完成した状態でリファインメントを行う
デザインがあると、追加や変更が必要な要素、実際の動作などをイメージしやすくなり、議論やすり合わせの質が向上します。 デザインが完全にFixしている状態が最善ですが、70%程度完成した状態でも、何もない状態よりは良いと考えています。
今回参加したプロジェクトでは、自分がデザイナー兼企画者として参加していたため、デザインを準備してからリファインメントを行うという進行方法がスムーズに行えました。
しかし、企画者とデザイナーが別の場合、また異なったアプローチが最適となることもあるかもしれません。
今後スクラム開発を行う際に取り組んでみたいこと
ユビキタス言語をはじめとするドメインモデリングの導入
今回、ユビキタス言語の策定に取り組んだ結果、職能間で共通の言語があると「話が早い」という効果を実感しました。
それだけでも十分価値があると思いますが、さらに職能間で連携を深めるためには、ドメインモデリングの導入も考慮に入れたいと思っています。
上記記事から引用です
そもそもドメインモデリングをして何が嬉しいの？
ドメインモデリングをすることによって、「作ろうとしているシステムについて、ビジネスサイドとエンジニアが、共通認識を持ち、意思疎通する」ことが可能になります。具体的にドメインモデリングを実施する利点としては、下記のようなものが挙げられます。
- ビジネスサイドとエンジニアの共通言語である、ユビキタス言語が決まる。
- 設計に、ビジネスサイド(ドメインエキスパート)の持つ業務知識を反映することができる。
- ビジネスサイドがドメインモデルを通して、プロダクトの技術面を理解することができる。
これらのメリットを聞いただけでも、ワクワクしませんか？私はとても実践してみたいなと思いました。
ドメインモデリングについてはまだまだ私も理解が浅いので、以下の本を読んで勉強中です。
DESIGNING CONNECTED CONTENT デジタルプロダクトの長期的な成長を支える構造化コンテンツ
ドメインモデルを作成する過程は、ユーザーモデリングや体験価値のモデリングなどのUX改善にも活用できそうです。
また、オブジェクト指向に基づいた情報設計を意識したUI作成にも役立つと思います。
最後に
初めてスクラム開発を経験した振り返りとして、多くのことを書きましたが、最適な運用方法はプロダクトの状況や組織によって変わるはずです。
何か困ったらチームで議論して、改善していくプロセスこそが一番大切なことなのかもしれないと感じました。
今回、私がデザイナー兼企画者として参加したプロジェクトのスクラムチームでは、レトロスペクティブでの振り返りが毎回非常に充実しており、日々新しいTRYと取り組みが実践されていました。本当に最高のチームだったと思っています！
ここまで読んでいただき、ありがとうございました！
明日のAteam LifeDesign Advent Calendar 2023 シリーズ3の18日目を担当するのは @y_mey さんです！お楽しみに