この記事は Goodpatch Advent Calendar 2021 9日目の記事です。
iOSエンジニアの 加藤 です。 とある案件で、デザイナーを含めたチームでスクラム開発しました。 エンジニア以外の職種を巻き込んだスクラム開発について、エンジニア目線から事例として紹介します。
前提
スクラムとは
エンジニアのための開発フレームワークで、スクラムのロールとしてデザイナーは出てきません。 決まったものを素早く作り切るフェーズ（Deliver）を得意とし、不確実性の高いフェーズ（Discover）は苦手とします。
体制
- 1スプリント2週間
登場人物
- PO 1人（クライアント）
- PM 1人（スクラムマスター兼任）
- デザイナー 3人
- エンジニア 4人 （時期によって変動あり）
なぜスクラムするのか？
スクラムすることは手段であり、目的ではありません。 チームの課題を洗い出し、スクラムをベースにしてチームに合わせた開発体制を整えました。
デュアルトラックスプリント
DiscoverトラックとDeliverトラックに分けて、2つのトラックが存在するアジャイル手法らしいです。 この記事を書くにあたり調査し、この言葉の存在を知りました。 最初から意図していたわけではありませんが、デュアルトラックスプリントに近いスクラム開発になっていると思います。
なにをしたのか
実際にどのようなスクラムをしたのか、実例ベースで紹介します。
Discoverトラック
作るものが決まっていないフェーズです。 課題をもとに、何を開発するかを決めます。
戦略・ビジネス設計スプリント
主な参加職種： PO, PM, UX デザイナー, BX デザイナー アウトプット：企画書
KPI・インタビュー等の課題・要望から、企画書を作成します。 企画書には、ビジネス的な要件を書きます。 すべての職種が企画書を書くことができますが、優先度はPOがつけます。
企画・デザインスプリント
主な参加職種：PO, PM, BX デザイナー, UI デザイナー, エンジニア インプット：企画書 アウトプット：仕様書
企画書の課題を解決できるアイデアを出し、デザインし、仕様書まで落とし込みます。 PO, デザイナー, エンジニアが参加し、ビジネス, クリエイティブ, テクノロジーそれぞれの観点で意見を出し、アイデアの妥当性を判断します。
スプリント計画
主な参加職種：PO, PM, デザイナー, エンジニア
- 企画書の優先度付け
- 企画書の読み合わせ
- 工数見積
デイリースクラム
主な参加職種：PM, デザイナー, エンジニア
- タスクの確認
- ひとことコーナー
Deliver トラック
作るものが決まっており、エンジニアが手を動かしてプロダクトを作るフェーズです。 アプリのアップデートをリリースすることを目的とします。 作るものは決まっているのですが、実装中により良いUIを提案することもありますし、実装都合でデザインを変更してもらうこともあります。 仕様書はコミュニケーション手段の1つとして捉えており、仕様書が正ではありません。 クオリティにこだわるため、スクラム内に入る規模の修正は積極的に取り入れます。
開発スプリント
主な参加職種：PM, デザイナー, エンジニア, テスター インプット：仕様書 アウトプット：アプリのアップデート
スプリント計画
主な参加職種：PO, PM, エンジニア, テスター
- 仕様書の優先度付け
- 仕様書の読み合わせ
- 工数見積
デイリースクラム
主な参加職種：PM, エンジニア
- タスクの確認
- ひとことコーナー
スプリントレビュー
主な参加職種：PO, PM, デザイナー, エンジニア, テスター
- 触り心地の確認
- 認識ズレがないか確認
- 仕様書通りかどうかは重要ではなく、違和感がないかを優先する。仕様書を正としない
スプリント振り返り
主な参加職種：PO, PM, デザイナー, エンジニア
- KPTにとらわれず、個々のパーソナリティが見えるような手法をもちいる
スクラム設計時に意識したポイント
職種間の壁を作らない
例えば、Discoverをデザイナー、Deliverをエンジニアと区切ってしまうと、Deliverトラックに入ってからの手戻りが増えてしまいます。Discoverにもエンジニアが参加していっしょにデザイン・仕様を作り上げることによって、結果的にアウトプットのクオリティも上がり、手戻りも少なくなります。 また、タスク管理を一つの場所でおこない、お互いの忙しさを可視化するのも有効的です。
Discoverトラックでのエンジニアの関わり方を定義する
Discoverトラックにエンジニアは必要？と言われることも多いと思います。 エンジニアが参加する意味を共有し、正しく参加できる環境を整えることも重要です。
- 発散フェーズではなるべく制約を伝えず、エンジニアならではのアイデアを出す
- テクニカルプロトタイプで、アイデアを高速に検証する
- アイデアを技術調査し、実現可能性を検討する
- 収束フェーズでは保守性を考えつつ、デザインの意図に沿った修正案を出す
- 仕様書のエンジニアリング部分を作成する
人に合わせて仕組みをアップデートし続ける
毎スプリントごとの振り返りには、全職種参加するようにしています。 ここより下に書かれている2項目は、振り返りから出た案によりアップデートされた内容です。
インセンティブ設計をする
各スプリントのインプットとアウトプットを明確に定義することで、スプリントの開始条件を決めました。 例えば仕様書をFIXさせないと開発スプリントを開始できないため、仕様書をFIXさせることにインセンティブが働くようになり、モチベーションの低いタスクにも前向きに取り組むことができました。
ウォーターフォールを併用する
Discoverトラックでは QCD の Quality を重視し、Delivery の優先度を下げることが多々あり、その中で、営業要望等でリリース日が決まっている機能へのコミットが難しいという課題がありました。 リリース日が決まっているものはスクラムとは別軸で、リリース日にコミットしたウォーターフォール開発を併用することで解決しました。
結果
Good
チームとして動ける
企画からリリースまで全職種がかかわるため、チーム内の情報分断が起きにくく、ビジネス, クリエイティブ, テクノロジーすべての観点からアウトプットのクオリティを上げることができました。他職種の観点もインプットされ、各個人の成長にも繋がります。
デザイナーが仕様を考えながらデザインできる
紹介した事例では、デザイナーとエンジニアが一緒に仕様書を書き上げます。 デザイナーが書いた仕様書をエンジニアがレビュー・追記することでデザイナーがエンジニアリング観点を学ぶことができますし、エンジニアがデザイナーへ要望を出したときの反応から、デザイナーが重視しているデザイン観点を学ぶこともできます。
小さく合意しながら進められる
デザインFIX・仕様書FIX・スプリントレビューと成果物を短期間で段階的に合意するため、認識ズレが起きにくいです。手戻りが少なく、短期間でのリリースに繋がります。
エンジニアリング力で課題解決できる
エンジニアがDiscoverトラックから参加することで、テクニカルプロトタイプ等を使った課題解決が可能になり、アイデアの精度が上がります。
More
飛んだアイデアが出にくい
企画書ベースの課題解決がメインとなり、小さく合意を繰り返すため、飛んだアイデアが出にくいという課題があります。不定期でアイデアソンを開催することでスプリントでは出にくいアイデアを出す機会を作っていますが、日常的な改善には至っていません。
割り込みタスクが多い
一般的なスクラムでは割り込みタスクはNGとされますが、今回の事例では割り込みタスクが多く発生します。（スクラムマスターは機能しています。） 実装中にデザイン漏れをデザイナーに確認する、ユーザーからの問い合わせをエンジニアが調査するなど、どうしても優先度の高いタスクが発生してしまい、割り込み対応になります。 あらかじめ割り込み用の工数を見積もることで対応していますが、割り込みタスクが多いと作業時間の確保が難しくなります。
実装時間の確保が難しい
エンジニアもDiscoverトラックに参加するため、Deliverトラックに使える時間が少なくなります。 テクニカルプロトタイプや技術調査が発生すると、さらに実装時間が減ってしまいます。 エンジニアの負荷を調整しながら、無理のない範囲で参加することが求められます。
工数の見積が難しい
Discoverトラックでは作るものが決まっていないため不確実性が高く、工数の見積もりが難しいです。そのためスケジュール期限があるときにスケジュールに間に合うか判断するのが難しく、一部ウォーターフォールを取り入れることで解決しました。
改善サイクルが少し遅い
今回の事例では企画からリリースまで最低でも1ヶ月かかってしまい、それからユーザー操作を待ってからデータ収集し分析するため、改善までに時間がかかります。Quality を重視すると合意した上でのことなので問題ではないのですが、改善サイクルを素早く回すことができないため、少しだけスクラム開発のメリットが薄れていると感じます。
まとめ
デザイナーを含めたスクラム開発事例について紹介しました。
スクラムは銀の弾丸ではありません。 チームで話し、Tryし、改善を続けることで、自分たちに適した開発フレームワークを見つけることが、チーム開発の難しいところでもあり、楽しいところでもあると考えています。
あくまで事例の一つとして、参考になれば幸いです。
「偉大なプロダクトは偉大なチームから生まれる」
Goodpatchではデザイン好きなエンジニアの仲間を募集しています。 少しでもご興味を持たれた方は、ぜひ一度カジュアルにお話ししましょう！
