LIFULL Creators Blog

「株式会社LIFULL(ライフル)」の社員によるブログです。

3職種上流でスクラムを戦った話

LIFULLプロダクトエンジニアリング部の堀です。具体的にはLIFULL HOME'Sの開発を行っています。私はその中でも賃貸領域の開発を担当するグループに所属しています。

今回は、エンジニア・企画・デザイナー3職種混合チームで、少し今までとは違った形でスクラム開発に取り組んだのでその話をしたいと思います。テーマは「3職種上流」です。

前提

開発体制などはチームの構成や仕組みによって大きく変わるので、まず前提として私が所属しているチームの説明を行います。

我々の部門はLIFULL HOME'Sの賃貸開発を担当しており、今期は5つのチームに分かれています。その中でも私はプロダクトのグロースチームに所属しています。

チームのメンバーはエンジニア4人、企画2人、デザイナー1人という構成になっていて、エンジニアの1人がSM(スクラムマスター)を兼任しています。 プロダクトオーナーと呼ばれる存在はチーム内には存在せず、プロダクトの方向性やバックログ施策の妥当性は企画会議で判断されます。

グロースチームはとあるプロダクトに対してKPI目標を持っており、我々はその目標を期を通して達成することを使命として動いています。

また、各スプリントは2週間単位で設定されています。

本記事の立ち位置

本記事は私が所属している1チームの動き方にフォーカスを当てて書いておりますが、今期はチーム間の調整や全体でのバックログの運用などにも部門を上げて取り組んでいたので、そちらの内容は以下の記事を参考にしてみてください。

www.lifull.blog

また、ここではスクラム中の具体的な動き方を説明していますが、「他職種に期待していること」をチーム内で擦り合わせて職種間の連携を強める取り組みを別部門の方が最近記事にしていたので、そちらも是非ご覧ください。

www.lifull.blog

これまでの課題感

これまでのスクラム開発でも、メンバー構成や目標の持ち方はほぼ同じでした。

我々が感じていた課題感は、特に各施策の仕様調整に関してです。基本的にバックログに追加する施策は企画の方が施策案を出し、企画全体の会議で決定し、仕様作成後に優先順位付けを行った状態でバックログに追加していました。そして計画MTGで各エンジニアにアサインを行います。

開発を始めると、仕様に関して疑問を持ったりもっと良い方法を思いついたりすることが良くありました。また仕様決定後にデザインをデザイナーが行うのですが、その時に「伝わりにくさ」などUX観点での課題点を発見されることもあり、その度に仕様調整が生じていたので少し効率悪さを感じていました。

3職種上流で効率良い開発

3職種上流とは

これまでの課題を解決するために、施策立案から仕様決定までをエンジニア・企画・デザイナー3職種全員で行おうという取り組みを我々は3職種上流と呼んでいます。

半期の目標設定

従来はリーダー達が各チームの追う目標を設定し、メンバーはそれを自分の中に落とし込んで期の始まりを迎えていました。それに対して今期は3職種上流を実現するために、まずチームが結成された期初に、各チーム毎に半年で追うアウトカムの設定を行いました。目的としては

  • 同じ方向を向いて走り出すことができる状態にする
  • それぞれで自律して目標のために動ける状態にする

以上2点です。

今、期が終わろうとしているところですが振り返ってみると、この目標設定はとても大事だったなと改めて感じました。弊社はKPIマネジメントに取り組んでいるので、部として大きなKPIは持っているのですが、そのKPIを達成するための方法は各チームに委ねられています。これをメンバーで決めることで、期を通して3職種全員でしっかりと目標を見据えて動けたなと思います。

施策検討

施策ブレスト会

目標を達成するための施策検討は、これまで企画職がメインで行っていました。しかし上に挙げた課題感があったので、職種関係なく施策案出しから入るようにしました。大体、週1時間のペースで施策ブレスト会を開催し、次以降のスプリントで実施する施策の大まかな仕様決定まで行いました。

エンジニアが上流から入ることで、より工数の少ない方法や別の実現方法などアイデアの幅が広がったり、デザイナーが入ることで 施策そのものに対しユーザーの視点を反映させることができたりします。また仕様作成の時点でデザイナーがビュジュアル的に可視化できるので、他職種もより仕様を理解しやすくなり3職種上流を加速させることができます。

UT(ユーザーテスト)実施

UXプロダクトを作っていると数値分析は行っているので課題となっている部分は分かるのですが、「なぜユーザーは離脱するのか」「何が迷わせているのか」等の原因が作っている側の目線だと分からない事が多々あります。それでは3職種集まっても有意義な施策ブレストは行えません。

そこで我々のチームはUTをチーム内で行い、課題の原因を探るようにしました。UT分析から見えてきた原因をブレスト会に持ち込むことで施策の案出しの材料とする事ができました。

弊社にはUTを専門にしている部署もあるのですが、様々なプロダクトを見ているので実施回数に限界があります。そこをチーム内で行うことでPDCAを早く回せるようになりました。UTを行うことで課題感が見えるだけでなく、施策の効果も実際の動きを見ながら確認できるのでモチベーションにも繋がります。ただ、チーム内で実施するとメンバーの工数が嵩むので、UTチームと連携を取って臨機応変に担当範囲を決めたりなど工夫すると良いと思います。

チームで設計や分析の参考にした書籍を参考に置いておきます。

www.amazon.co.jp

デイリースクラム

施策ブレスト会で実施が決まった施策は、企画が細かい仕様決定を行い、デザイナーがデザインを作成します。途中で悩むポイントが出てきた場合や相談が必要な場合は、チームメンバーが揃っているデイリースクラムで相談を行います。

そこでの相談ではfigmaやXDなどのツールを使って可視化されたものをベースに全員で議論するので、視覚的にも想像しやすく深い議論が可能です。必要に応じてエンジニアがプロトタイプを作成し持ち込むこともあります。

開発効率の向上

従来は課題の発見から仕様に落とし込む部分までを企画職が行い、その後にデザイン・実装・リリースと続く形が取られていました。この場合だと上流工程はウォーターフォールのようになっており、結果が出るまでに時間がかかります。

しかし、上に述べたようなUT・施策ブレストを通して3職種全員で課題発見からアイデア出しまでを行い、全員の認識が揃った状態で仕様作成・実装・デザインなどを同時並行で行うことによって、リリースまでの工程が短くなり効率よく開発を進めることが可能になります。

また、全員の認識が揃っている状態なので、相談や議論が必要な際はそれぞれの職種の観点でスムーズに意見を言い合うことが可能です。

開発効率の向上
開発効率の向上

スプリントスケジュール

参考になるかも知れないので、スプリントのスケジュール例を記載します。

スプリントスケジュール
スプリントスケジュール
リリーススケジュールの関係で、木曜日がスプリント区切りになっていて、計画MTGと振り返りMTGを行います。 計画MTGでは主に施策アサインとストーリーポイントの設定を行います。

施策の優先順位付やバックログの整理は基本的にSMと企画職で水曜日のバックログリファイメントの時間に行います。 上で述べた施策ブレスト会は月曜日に行うようにしていました。

まとめ

今回、3職種上流でスクラムを戦ってみて、エンジニア目線で開発のやりやすさは勿論、目標にコミットしようと思う意欲や1つ1つの施策に対する思い入れも以前より増えたかなと思いました。

実際のユーザーの動きを見て、チーム内で打ち手を考えることでなぜその施策をやるのか、ユーザーにどうなって欲しいのかが自分の中にもチームの中にもしっかりと落とし込めたと思っています。

3職種上流はどの職種であっても、チームの目標や各施策によりコミットしていく動きの一つだと思っているので、今後もより良い開発体制を目指していきたいと思います。

LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。

hrmos.co

hrmos.co