スクラム初心者が仮説検証で実践してわかった課題と対策
背景
こんにちは。Saas企業でフロントエンド・バックエンドエンジニアをしています。今回初めての投稿になります。
今年に入ってから新サービスの立ち上げのチームに入り、「このサービスは本当にユーザーに価値を提供できるのか」という仮説を検証する活動（以下、仮説検証）を行っているのですが、
チームではこの仮説検証のフェーズからスクラム（アジャイル開発の手法の一つ）を適用することになり、
スクラム未経験の自分がスクラムマスターを担当することになりました。
チームメンバーにもスクラム経験が豊富なメンバーが不在だったため、
これはイカンということで、アジャイル・スクラムの勉強も並行して進めました。
この記事では、仮説検証でスクラムを実践してみてうまくいかなかったこと、そこから得た知見をまとめていきます。
仮説検証でスクラムを実践してみてうまくいかなかったこと
前提
新サービスの立ち上げでは、まず世の中の課題を抽出し、それに対する仮説を考案しました。
その後、仮説が正しいかどうかを検証するためにユーザーインタビューを実施し、サービスが本当に価値を提供できるかを確認する活動を行なっていました。
仮説検証 × スクラムの情報が少なく適用に苦戦
私が参加したプロジェクトでは、会社として初めてスクラムを適用しました。
チームには、私を含めスクラム経験が豊富なメンバーが不在だったため書籍やインターネットから情報を収集してスクラムを実践していったのですが、
開発フェーズを前提としたスクラムの情報が多く、仮説検証フェーズでのスクラムの適用に苦戦しました（適用できていなかったと言っても過言ではありません）。
スクラムの作業リスト（バックログ）が仮説検証では過剰だった
スクラムでは「プロダクトバックログ」と「スプリントバックログ」という2種類の作業リストを使います。
プロダクトバックログは顧客に価値を提供するために必要な機能や修正を列挙したもの、
スプリントバックログはその中から選んだ項目を実現するための具体的なタスクを列挙したものです。
私たちはこれらの作業リストの目的をちゃんと理解しないまま仮説検証段階から作成していましたが、
今考えると仮説検証では単純なTODOリストくらいで十分に機能すると思います。
作業リストに記載する内容も仮説検証では不要な項目が多くなっていて、
そのせいで作業リストの運用が形骸化してしまいあまり機能していませんでした。
長期的な目標を決めておらず、チームメンバーの行動の指針となるものがなかった
アジャイル開発でもウォーターフォール開発でも、最終的なゴールを決めて、それを達成するためにはどういうタスクを実行すればよいかを考えることが重要です。
しかしアジャイルの経験が浅い我々は、「アジャイルはきちんとした計画を立てない」というような誤解がどこかにあり、
長期的な目標やマイルストーンをきちんと決めないままスクラムを回していました。
そのため、スプリントゴールが曖昧な状態となり、チームメンバーの行動の指針となるものがありませんでした。
意思決定者が不在で物事が決まらない、速度が出ない
スクラムでは以下の３つの役割があります。
- プロダクトオーナー
- スクラムマスター
- 開発チーム
仮説に関する事はプロダクトオーナーが責務を持つことになり、主要な意思決定も行うことになると思います。
しかし、各役割の責務を理解しないままスクラムを回していたとともに、会社全体に根付いていた「全員の合意を得てから進める」という文化がチームにも反映されていたこともあり、
打ち合わせでも何かを決めるまでにとても時間がかかることが多くなっていました。
結果として、仮説検証が進まないという状態になりました。
改善したこと
前提
７人いたチームメンバーを２〜３人で分割し、チームごとに仮説検証を進めることになりました。
私が所属するチームでは引き続きスクラムを適用していくことになったため、上記の反省点を踏まえ改善を行なっています。
改善したことを以下にまとめます。
バックログからTODOリストに変更
仮説検証フェーズでのバックログの運用をやめ、「仮説が有効かどうかを検証するためのタスク」をTODOリストとして簡素化し、
気軽に変更を加えられるようにしました。
なお、以前はGitHubのIssueをバックログとして運用していたのですが、
手軽さを優先してGoogleのスプレッドシートで運用することにしました。
１ヶ月先までの目標を決める
チームメンバーが共通の指針を持って仕事をできるように最終的なゴールの他に１ヶ月先までの目標を決め、
その目標をベースにしてプランニングを行うようにしました。
以前までの場当たり的なプランニングと比べると、明確な目標が存在するためスムーズにプランニングができるようになりました。
また、チームメンバーが共通の指針を持って仕事できるようになったため、その効果も今後に期待できます。
人数が減ったことで、意思決定が早くなった
人数が減ったことで、意思決定が早くなり、打ち合わせもスムーズに行えるようになりました。
今後の展望
上記の改善を行なったばかりなので、今後運用を継続してみて、
うまくいったこと、うまくいかなかったことをまとめていきたいと思います。
また、ふりかえり（スクラムのレトロスペクティブ）を必ず実施し、
プロセスの改善を継続していきたいです。
仮説検証フェーズでのスクラム適用はあまり情報がなく難しさがありますが、
チーム規模や目標設定の工夫次第で、
仮説検証の段階でもスクラムのメリットを活かすことができると感じています。
Discussion