はじめに
こんにちは。d-nishikawaです。
先日、7ヶ月という短期間ではありましたが、スクラム開発のプロジェクトを無事に終えました。
本記事では私たちが「立ち上げ時に行ったこと」と、プロジェクトを終えて見えた「気づき」を共有します。
立ち上げでやったこと
私たちがプロジェクト初期に行った立ち上げの工夫を簡単にご紹介します。
以下のステップでチームとプロダクトオーナー（PO）の認識を揃えました。
-
仮説キャンバスの作成
市谷聡啓さんの「仮説キャンバス」を参考に、チーム全員で「目的 → ビジョン → 詳細 → 解決手段」の順で議論しました。
これにより、POの課題感がチームに浸透し、その後の優先順位の判断やシステム提案の根拠となりました。 -
ユーザーストーリーマッピング（USM）でのMVP定義
ユーザーの行動を時系列に並べたあと、どこをシステム化すべきか議論しました。
これにより、業務イメージがチームに伝わるとともに、MVPを設定することができました。 -
概算見積もりによる期待値ギャップの検知
洗い出したMVPに対し、数スプリント開発した実績をもとに相対見積もりを出した結果、
「POが想定していたスケジュール感」と「現実的な見積もり」の間に大きなギャップがあることが発覚。
開発前に気づき早期に軌道修正することができました。
プロジェクトのふりかえりより抜粋
- 「仮説キャンバスとUSMの作成で、業務イメージや課題感がかなり伝わりました！」
- 「ミニマムPBIの摺り合わせは迫られた面もあったが、やって良かった」
このようなことを行い、開発を進めるための共通認識や方針を固めることができました。
仮説キャンバス
USMと概算見積もり
プロジェクトを終えて見えた気づき
プロジェクト全体のふりかえりを通じて見えてきた、3つの気づきをご紹介します。
実ユーザーの巻き込みは「仮説」の段階からやる
仮説キャンバスやUSMの作成は、主に開発チームとPO間で行い、実際のユーザーにはスプリントレビューのデモ等でフィードバックをもらう形をとっていました。
作ってからレビューしてもらうのも大事ですが、そもそも「何を課題とし、何を解決するか」を定義する仮説の段階から現場の実務担当者を巻き込むべきでした。
そうすることで、大きく2つのメリットがあったと考えます。
1つ目は、スプリントレビューの質向上です。
仮説の段階で実ユーザーの課題が反映されていれば、「どのスプリントで、誰に、何を検証してもらうか」がおのずと決まり、スプリントレビューでより的確なフィードバックを得られる場になったはずです。
2つ目は、優先順位判断のブレをなくすことです。
POはふりかえりの中で「ユーザーからの要望はどうしても各自の業務にフォーカスしたものになるため、優先順位はずっと悩んだ」とコメントしていました。
仮説段階で実ユーザーのリアルな課題を組み込むことができていれば、POの意思決定の材料にできたと思います。
初期のドキュメントは「作って終わり」にせず継続的に見直す
仮説キャンバスやUSMは、プロジェクト初期にチームの認識を揃えるツールとしてとても有効でした。
しかし、プロジェクトが進むにつれて状況は変化していくものです。
初期の成果物としてそのまま放置するのではなく、節目ごとにチームで立ち返り、状況に合わせてアップデートしていくことがチームの認識を合わせ続けるために重要だと感じました。
顧客の決裁者をアジャイルのプロセスに巻き込む
プロジェクトの後半、「この期日までに、ここまでの機能をすべて作ってほしい」と言われ、スコープの柔軟性が失われてスクラムが「形だけ」になりかねない場面がありました。
このような状況になったのは、自分たちが「POに伝わっていればOK」と無意識に考えていたからだと思います。
POとの期待値調整はできていた認識でしたが、その内容を「予算や進行を判断する決裁者」にまで届ける必要がありました。
スプリントレビューに「システムを使う人」を呼ぶだけではなく、「プロジェクトの継続を判断する人」もスクラムに巻き込むことが重要だと感じました。
おわりに
振り返ってみると、ステークホルダー調整の場面には、チームとしてさらに貢献できるチャンスがありました。
決裁者など重要なステークホルダーを巻き込むために、POに何が必要かをヒアリングし、相対見積もりなどの情報を先回りして提供することで、よりスムーズなプロジェクト運営が実現できると思います。
次のプロジェクトでは、POと密に連携しながら情報提供を積極的に行っていきます。
同じようにスクラムに取り組んでいる皆さんにとって、今回の私たちの学びが少しでもヒントになれば嬉しいです。
簡単30秒