こんにちは、買物情報事業部の前田 (@TakatoshiMaeda) です。
今回は、クックパッド特売情報のサービス企画、開発を行っているチームがどのようなプロセスで日々ユーザー価値の向上に取り組んでいるのかお話します。
チームでは様々な取り組みを行っていますが、今回は
- バックログ運用
- 計画のもととなる、サービスで実現したいストーリーリスト
- スプリント計画
- バックログから実際の行動計画に落としこむまでのプロセス
- ふりかえり
- スプリント計画の実施結果を振り返る仕組み
の3つについてご紹介します。各取り組みのより詳細な内容についてはスクラムガイドをご覧ください。
バックログ運用
特売情報の開発チームはディレクター/デザイナー/エンジニアで構成されていますが、全てのメンバーがサービスをどのように良くしていくべきか考え、日々活発に議論しています。
日々の何気ない会話や、業務の中で得られた知見から生まれたアイデアをチームで集積する場としてバックログを活用しています。(実際にはPivotalTrackerで運用しています)
3つのステータスがありますが、Icebox -> Backlog -> Currentの順に開発するストーリーや機能が移動していきます。
- Icebox
- 次々回以降のスプリントで取り組みたい項目
- チームメンバー全員編集可能
- Backlog
- 次回のスプリントで取り組む候補となる開発項目
- Currentに入りきるかどうかは気にせず、次のスプリントで取り組みたい項目を全て列挙する
- チームメンバーと相談しながら優先順に並べる
- チームメンバー全員編集可能
- Current
- 現在のスプリント(後述)で取り組んでいる開発項目
- スプリント計画MTG(後述)で作成、Fixする
チーム全員が考えている価値仮説を１つの場所に集約し、スプリント計画を立てる際の議論の中心とするのが狙いです。
また、次回のスプリントで取り組む開発項目を未確定事項が多い状態でもチームで共有し、未来に対しての認識をすり合わせる効果も感じています。
スプリント計画
さて、バックログを運用するだけでは前へは進めません。バックログを元に実際に計画をし、遂行するフェーズが必要です。
開発チームでは2週間を1単位としたスプリントを運用しています。
これから、ブログサービスを運営しているチームを仮想の例として、スプリント計画をチームで決定する為の「スプリント計画MTG」をどのように運用しているのかについてご紹介します。(例は実際のストーリー粒度とは大きく異なります。)
スプリント計画MTGは次の二部構成になっています。
- 2週間で何を実現するのかを議論する第一部
- 実現可能性を高めるために、実際のタスク計画に落としブラッシュアップしていく第二部
第一部
スプリント計画の第一部では、
- 今回のスプリントで実現したいことをディレクターから説明
- バックログの見直しと優先順位の再検討
- スプリントバックログの構築
の流れで進めていきます。
まず、1では今回のスプリントではどういった課題に取り組み、サービスをどのような状態にしたいのかをディレクター(オーナー)から話をしてもらいこれからの2週間をどのようにするかの目線をすり合わせます。
これから作成するスプリントバックログ*1の優先順位を検討していく為の判断軸をチームで作るためです。
※未整理のバックログ
ここでは、「記事との新しい出会いをもっと作りたい」というオーナーのイメージをメンバーに共有しました。
判断軸の共有ができた後は、実際にスプリントバックログを構築していきます。
- なぜ今その開発項目に取り組むのか
- 解決したい課題は何か
- 2週間の中で取り組める分量か
を議論し、取り組む意義を確認しながら開発項目を誰が推進して実現するかの決定(アサインの決定)を行い、2週間の計画を作成していきます。
※整理済みのバックログ
2週間の中でチームとして何に取り組むのかが定まりました。
この段階では詳細なタスクについては未確定です。このまま作業に取り掛かると、作業の溢れや依存関係から予期せぬ事態に見舞われるリスクは高いでしょう。
この計画が本当に実現可能なのか、リスクをはらんでいないかをチームで把握をするために、スプリントバックログを用いて第二部に進んでいきます。
第二部
第二部では、第一部で作成したスプリントバックログを元に
- 取り組む開発項目のタスク分解
- メンバーの作業の依存関係の整理
- マイルストーンの設定
- 今決定できない事項の整理と把握
- 不確実な事項の整理と把握
を定めます。
まずは、抽象度の高い開発項目を実際に各メンバーでタスクに分解していきます。
この段階ではやることは見えてきていますが、チームで開発している以上は相互の作業の依存関係が発生します。
「あれ、これ終わってないと次に進めない...」といったことがないように、タスクのマイルストーンを設定し作業の依存関係を整理していきます。
また、チーム外との連携作業も発生するため、まだ決定できない事項や、不確実な事項が発生します。
スプリント計画MTG前に出来るだけ整理をしておく努力はもちろんすべきですが、完全に取り除くことは不可能です。
そこで、不確実性が高い事柄は「いつまでに何を決めるか」をマイルストーンに組み込みます。
マイルストーンを作成していくと、明らかなオーバータスクや実現の可能性が低い事柄が明らかになってきます。
その場合にはメンバーで話し合い、スプリントバックログの見直しを行い、改めてタスク分解を行うことで無理のないよう計画を立てていきます。
ここまででスプリント計画MTGは終了です。
タスクマイルストーンが定まれば後は実際に開発を進めていくだけです。ここからは開発を進め、完成したものからリリースをし、検証して行きます。
実際に作業を進めていく中で想定外の事態が発生することは避けられないため、水金の段階でマイルストーンと照らしあわせてメンバーの進捗状況を確認しあい、必要であれば計画の見直しを都度都度行っています。
ふりかえり
2週間が立てばスプリントも終了です。
綺麗に作業が完了する清々しいスプリントもあれば、作業がなかなか進まず仕掛りが残ってしまうスプリントも発生します。*2
そこで、この2週間を振り返るために最終日に振り返りを行い、より良く作業をしより良いサービスを提供していくために次のスプリントにどう取り組むべきかを話し合います。
次回のスプリントに向けたバックログの見直し
ここでは、計画した内容で何が終わったのか、何が終わっていないのかをチーム全体で見直します。
見直しと同時に2週間の中で得られた知見から新たにIceboxに追加できる項目があれば議論をし、Iceboxや次週以降のバックログに新たなアイデアを反映していきながらバックログを整理しておきます。
次週のスプリント計画MTGをスムーズに行うためです。ただ、計画を立てるまでは行いません。
整理が終わったら、KPT*3の時間です。
感情カードを用いたKPT
発生した問題に対してどのように取り組むべきかをKPTで振り返りをしているのですが、一工夫して感情カードを用いたKPTを運用しています。
この2週間を振り返ってくださいと言われてもすぐには言葉は出てこないものです。
そこで、2週間どのような感情が沸き起こってきたのか、どのような思いで仕事をしていたのかを考えてもらい、カードを自由に選択してもらってチームメンバー全員で発表しあいます。
アイスブレイクとしてももちろんなのですが、メンバーが何を考えて日々仕事をしているのか、何が辛くて、何が楽しいのかを改めて深く知ることで相互理解を促進する役割も担っています。
この発言から、Keep/Problemを拾い出していき、より良く業務に取り組めるようチームで取り組むTryを決定していきます。
Tryが決まり、振り返りが終わるとスプリントは終了です！
次週からはまた新しいスプリントが始まります:-)
最後に
いかがでしたでしょうか。もちろん、この運用の精度を上げていくためにまだまだ日々悩んでいる最中ではあるのですが、現在の開発チームの取り組みについてご紹介しました。
今回ご紹介した取り組みは
より良いサービスを提供するために、より効果的なストーリーに取り組むにはどうするべきか
- プロダクトバックログの品質を向上させていくためにはどうするべきか
より中長期的なビジョンをどう定義し、スプリント計画に反映していくのか
等、プロセスの外側にある重要な視点についてはカバーできていません。
あくまでチームがより良いユーザー価値のために立ち向かう姿勢を持ちやすくし、自律的に行動するための仕組みです。
限られた資源の中で、提供できる価値を最大化するためにどうするべきかは今まさに試行錯誤の真っ只中です。
またの機会に、取り組みについてご紹介できればと思います。
この事例が皆さんの課題解決の一助となれば幸いです。
買物情報事業部では、共にユーザー価値を最大化してくれる仲間を積極募集中です！
もし会社に興味がない方でも、より良い開発プロセスとは？より良いサービスを生み出していくためには？といった悩みをぜひ議論できればと思っていますので、お話できる方がいらっしゃいましたら@TakatoshiMaedaまでお気軽にご連絡いただけると嬉しいです。