「なんとなくスクラム」を見直して改善に取り組んだらチームの意識が変わった

はじめに

はじめまして、アンドパッドSWEの小川です。
アンドパッドの開発組織では、アジャイル開発の手法を取り入れたチームづくりや開発プロセス改善に関する取り組みが盛んに行われています。
今回は、私が所属する施工案件管理チームで最近行った取り組みについて紹介したいと思います。

背景

これまでも、チームの開発プロセスにはアジャイル開発のフレームワークであるスクラムの手法を取り入れていました。たとえば、開発タスクはカンバン上で管理し、会議体としては毎日の朝会、週ごとのスプリントプランニングとレトロスペクティブを行っていました。

しかしながら、実際にはスクラムガイド記載の内容に従っておらず、「なんとなくスクラム」をやっているだけという面がありました。
たとえば、スクラムガイドが定義するスプリントプランニングはスプリントに実施するタスクを決定するための会ですが、我々の実施していた会では仕様や機能についての議論に重きが置かれた結果、スプリントで何が達成されるべきかが不明確なまま終わることもありました。
開発の流れとしては、PdMが固めた仕様を受けて開発者が設計・見積もりを行い、ガントチャートで進捗を管理していました。これも、スプリント単位で進捗を管理するスクラムとはやや異なる考え方です。
アンドパッドは急成長中であるがゆえにメンバーの加入やチームの再編も頻繁で、開発プロセスの改善が追いついていない面があり、結果として我々のチームでは自己流の手法を続けているという状態でした。

この手法で開発を行っていると、あるプロジェクトでは、仕様の固まっている部分を実装し終えると、そこで立ち往生してしまうことがありました。また、後々必要性が明らかになった仕様変更に対して後手で対応するという状態になっていたがゆえに、開発に手戻りが発生したり、重要なことが後回しになってしまうという問題もありました。

上記の問題についてメンバーから問題提起があったのをきっかけに、チーム内で改善策についての議論が行われました。
原因としては、仕様策定の業務がPdMにほぼ任せきりになっているために仕様の全体像に意識を割けておらず、結果として決まっていることからとりあえず進めてしまっている点にありそうでした。仕様策定の段階から開発者がより積極的に関わることで、開発もよりスムーズに進むのではないかと考えられました。
そこで、開発者として仕様策定の段階からよりオーナーシップを持ちつつスピード感を持って開発できるようにするため、より本格的なスクラム開発の手法にトライすることにしました。

実施したこと

具体的に実施したこととしては、以下の2点です。

  • 計画立ての見直し - ユーザーストーリーマッピングとプランニングポーカーの実施

  • 役割と会議体の見直し - スクラムガイドに則ったスクラムチームとスクラムイベントへの変更

最近、とある新機能の開発に着手しましたので、そのとき実際に行った流れに沿って説明します。

計画立ての見直し

機能の概要はPdMが検討し、要件定義書の形で共有されます。まずはこの要件定義書をもとに、ユーザーストーリーマッピングを行いました。
ユーザーストーリーとは、実現する機能をユーザーの視点から記述したものです。また、機能の全体を細かいユーザーストーリーに分解し、時系列順に並べることをユーザーストーリーマッピングと呼びます。
ホワイトボードツールのMiroを使い、今回の新機能でユーザーが行う操作を1つずつ付箋に書き、操作の流れに沿って並べていきました。

ユーザーストーリーマッピング

一部、内部でやや複雑な処理を行う必要のあるユーザーストーリーについては、別途処理の流れをタスクとして付箋に書いて整理していきました。

ユーザーストーリーからさらに分解したタスク

続いて、プランニングポーカーを用いた見積りを行いました。
プランニングポーカーとは、チーム全員で見積りを行う手法のひとつです。対象となるユーザーストーリー・タスクについて、各メンバーがその大きさをポイントで相対評価して投票します。このポイントをストーリーポイントと呼びます。ストーリーポイントの数値にはフィボナッチ数列(1, 2, 3, 5, 8, ...)がよく用いられ、今回はこれを採用しました。フィボナッチ数列を使う理由は、ポイントが大きくなるほど精緻な見積りが難しくなるため、大まかな値で決めてしまうためです。ポイントが大きくなりすぎないよう、タスクを分解することが推奨されます。
付箋に書きだしたユーザーストーリー・タスクの1つ1つに対して、Miroのプランニングポーカーツールを用いて見積りを行いました。

プランニングポーカーの様子(この付箋はサンプルです)

投票の結果ポイントが割れたときには、その理由について議論し、必要であれば再度投票・議論を行って意見を一致させたうえでポイントを決定しました。
すべてのユーザーストーリー・タスクについて見積りが終わったら、ポイントの合計値をもとに開発期間を見積もりました。

見積もりを行ったタスクは、カンバンのバックログに積みました。これで開発の準備は完了です。

役割と会議体の見直し

同時に、メンバーの役割と定例の会議体を見直し、スクラムガイドに則ったスクラムチームとスクラムイベントへの変更を行いました。
従来の開発チーム内に、スクラムガイドの定めるプロダクトオーナーとスクラムマスターを設置しました。今回の改善の取り組み自体を推進し、PdMとの連携強化を進めるためです。
そのメンバーが中心となって検討し、1スプリントを1週間とした、以下のようなスクラムイベントを設定しました。

  • 朝会(毎日) - 各メンバーのタスク状況を確認し、生じている問題について議論する

  • スプリントプランニング(水曜) - スプリントで着手するタスクを決定し、カンバンのSprint TODOレーンに移す

  • リファインメント (金曜) - 未確定の仕様についてPdMやデザイナーを交えて議論し、必要であればカンバンに積まれたタスクを更新する

  • スプリントレビュー(火曜) - スプリントに実施したタスクについてデモを行い、完了したものをカンバンのDONEレーンに移す。また、完了したストーリーポイントを集計して進捗状況の確認を行う

  • スプリントレトロスペクティブ(火曜) - スプリントを振り返り、良かったこと・良くなかったことなどを議論し、改善のアクションを定める

意識したこととしては、スクラムガイドに則った形で各イベントを設定し、カンバン上のタスク状況の管理にフォーカスする形で各イベントの役割を見直したことです。
たとえば、これまでのスプリントプランニングでは仕様についての議論も行われていましたが、着手するタスクの決定のみを行うものと再定義しました。朝会も、タスクの進捗状況確認の時間とその他の相談の時間を明確に分けるように意識しました。スプリントレビューは行っていませんでしたが、スクラムガイドに則り設置し、タスクの完了確認とポイントの集計を行うようにしました。
リファインメントの会を定期で設けている点は、スクラムガイドにはない我々独自の工夫です。これまでも仕様についての議論には多くの時間を費やしていたので、そのための会を定期的に用意すべきだと判断しました。

カンバン

以上、機能開発の計画立てから開発を進めていく流れを説明しました。

ここまでの振り返り

この取り組みは始まったばかりで、最終的な評価を行うにはまだ早いですが、現時点でもある程度の成果を感じています。

主な成果としては、現在やるべきことが明確化し、開発のペースが掴みやすくなった点です。
開発する機能を細かいユーザーストーリーに分解してマッピングすることで、PdM目線だけでなく開発者目線でも機能のコアとなる価値が把握しやすくなり、仕様の疑問点や改善案についての議論も行いやすくなりました。これにより、優先すべきタスクが分かりやすくなり、スプリントプランニングで着手するタスクを決定する際もある程度自信を持って行うことができるようになりました。
また、スプリントレビューにおいてスプリントで達成したストーリーポイントを集計することで、開発のペースが掴みやすくなり、安心して開発を進めることができるようになっています。
もちろん、実際に着手すると想定外の難易度だったというタスクもありますし、それによってタスクが増減するといったことも発生します。ただ、その状況も含めてチーム全体で認識して対処しやすい状態になっていますし、そのように不確実性が高くかつ重要なタスクは早めに着手することでリスクを最小化するという戦略も立てやすくなりました。

ここまでの取り組みを振り返ると、改善のアクションをスピード感を持って行えた点が良かったと思っています。カレンダーを見返して驚いたのですが、問題提起があってから課題の認識と解決策の検討を行い、スクラムガイドに則ったスクラムチームとスクラムイベントへの変更を実施し、ユーザーストーリーマッピングに着手するまでに1週間ちょっとしかかかっていませんでした。
チーム全体の意識としても、少しずつ変わってきているように思います。これまではPdMが検討した仕様を受けてそれをどう作るかということだけに意識が向きがちでしたが、開発者として仕様検討の段階からよりオーナーシップを持ち、ユーザーが必要とするものを自ら考えて作ろうという意識が出てきていると思います。よりチーム一丸となって着実に前に進んでいることが感じられています。

おわりに

以上、「なんとなくスクラム」を見直して改善した取り組みを紹介しました。プロセスの改善を行った結果、早速効果が表れてきて、チームの意識としても以前よりオーナーシップを持って開発に取り組めるようになったという話でした。チームの様子や雰囲気が少しでも伝わっていれば幸いです。
また、今回の取り組みに際しては、弊社顧問の角谷信太郎さんにも助言をいただきました。角谷さん、ありがとうございました!

アンドパッドでは、「幸せを築く人を、幸せに。」というミッションの実現のため、一緒に働く仲間を大募集しています。
チーム一丸となって良いプロダクトを作りたい!と思われる方はぜひぜひご応募ください!

engineer.andpad.co.jp

hrmos.co