Zenn
🗂

スクラム開発、結局みんなどうやってるの。(Sprint0 編)

2024/02/28に公開
#
scrum
tech

概要

某超有名企業にスクラム開発のコンサルをがっつり受けながら開発した経験をもとに、できる限り具体的な開発事例をお伝えします。
スクラム開発に関しては様々な名著がありますので、心構えや基本的な考え方に関してはまずそちらをご覧いただくのが良いと思います。ただしそれのみでは、いざトライしようとした際に具体的にどう動けば良いのかわからず、二の足を踏んでしまう方も多いのではないでしょうか。
そこで、そんな方々の一歩を後押しできるよう、ここではスクラム開発を実現する上でのより具体的な方法論、考え方のイメージを掴んでいただくための具体的事例を書いていきたいと思います。
まずは本記事で、スクラム開発を始める上で極めて重要な準備期間であるSprint0 の動き方について記載し、スムーズに Sprint を開始できるようにするためにご参考にいただければ幸いです。

対象読者

スクラム開発に関して以下のように思われている方

  • これからやってみたいけど結局どうやればいいんだろう
  • すでに導入されているけど他社はどうやってるの？

Sprint0

プロジェクト成功に大きな命運を握るといっても過言ではない、「開発準備」のための期間です。
ここでこれだけはやっておいた方がいい！と身をもって体験したことから、具体的な動き方や考え方、及びその実施タイミングなどをお伝えします。

インセプションデッキ

目的： チームの目線合わせ
みんなのバイブル「アジャイルサムライ」で取り上げられている目線合わせのための手法です。
インセプションデッキを通してプロジェクトの方向性、リスク等、根本的な認識を合わせることができます。
また、この時点で「書けない=考えなきゃいけない」項目をあぶり出すという側面でも非常に重要です。
プロジェクトが始まったらまずインセプションデッキを作ってみることを強くお勧めします。
ここでは詳細な説明は割愛しますが、紹介されているサイトが多くありますのでご参考ください。
https://do-scrum.com/inception-deck/
https://www.agile-studio.jp/post/apm-inception-deck

お勧めの方法
認識を合わせることが目的ですので、できる限り全ての項目を全員で議論し合いながら出していく形が良いと思います。
ただし、中々議論が進まない等、難しさを感じられるようでしたら、まずは各項目に対して一番詳しい人が叩き台を作るとスムーズに進むかと思います。大体以下のような割り当てになるのではないかと思います。

  • 我々はなぜここにいるのか？: PO
  • エレベーターピッチ: PO
  • パッケージデザイン: PO & デザイナー
  • やらないことリスト: PO
  • ご近所さんを探せ: PO
  • 解決策を描く: 開発者 (これはワイヤーフレーム & ユーザーストーリーの後でもいいと思います。)
  • 夜も眠れない問題: みんなで一緒に。
  • 期間を見極める: PO
  • トレードオフスライダー: PO
  • 何がどれだけ必要なのか: PO

上記担当のみで考えることが難しい場合は適宜スクラムマスターが支援 or チームで集まってカバーしながらやりましょう。

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

ユーザー目線に立って、作るものを通じて「ユーザーが何をするのか」を書きます。
リアルでもデジタルでもいいので、付箋をペタペタ貼りながらどんどん貼っていきましょう。
顧客と共に密に会話しながら作成していく必要があります。
まずは我々の想定で叩き台として作成し、会話の土台として作成するという流れもお勧めです。

リモートワークのスタイルが主である場合は、いつでもどこでも閲覧&改変できるという面で Miro 等ホワイトボードツールがおすすめです。

ユーザーストーリーとして一般的に推奨されている形式には以下のようなものがあります。

  • 誰（想定ユーザー）として
  • 何 (機能/ユースケース) をしたい
  • なぜなら〜〜 (目的/価値) だからだ

ただ上記形にこだわらず、まずはもっと簡潔にどんどんブレストしていく形で出していく方が意見が出しやすい場合も多いと思います。
背景・目的等が見えづらくなってきたら上記形式にする形で一度考え直してみると良いかもしれません。
いずれにせよポイントとしては、この時点ではなるべく簡潔に書き、広く出していくこと、詳細に入りすぎないことが重要です。
まずは 深さよりも幅、質よりも量 です。

一通りユーザーストーリーが出揃ったら、縦軸を重要度として付箋をマッピングします。
上に来ており、かつ後述のプロダクトバックログ作成時に開発できる状態まで具体化できたものから優先的に開発していくことになります。

お絵描き (ワイヤーフレーム等)

兎にも角にもメンバーでイメージを 「絵」 で共有することが極めて大事です。
まずは最低限、ラフなワイヤーフレームのような形があればいいと思います。
ユーザーストーリーマッピングをしながら並行で進めることをお勧めします。
ユーザーストーリーにせよ後述のプロダクトバックログにせよ、言葉だけでは思いの外伝わらず
また書いた本人でも、後から付箋を見返しても必ずと言っていいほど「なんだっけこれ？」ってなります。
上記のユーザーストーリーを実現するとこんな感じかなぁという形で描いていきます。
これがあるとないとではこの後の作業の捗り方が全く違うので、このタイミングで必ずやった方がいいです。
また、絵を描きながら、ユーザーストーリーではない TODO 事項もどんどん上げていくと良いです。非機能要求/ 環境構築/ その他社内手続き等など、「ユーザーの価値に直結しないけどやるべきもの」も含めてどんどん出していきましょう。
（付箋の色を区別しておくといいです。）

さらにポイントとして、本作業は可能な限りスクラムメンバー全員が集って作業することを強くお勧めします。
開発者が入る利点は多岐に渡りますが、最も重要と考えるポイントは最終結果だけでなく意図・目的を理解できることです。
ここでの絵はあくまでイメージの共有です。最終的な結果のみではなく、これによって成し遂げたいこと、すなわち「目的を」を共有することがゴールです。
スクラム開発では一般的に、How の大部分は開発者に委ねられます（逆に PO が How を詳細に定義してしまうことは望ましくありません）。したがって、この時点で意図・目的まで理解しておくことが極めて重要になります。

初期全体概要設計

スクラム開発では各 Sprint 内で実施すると決めたタスク（Sprint Backlog）にフォーカスを当てて開発を実施しますが、初期のタイミングで全体感を見渡しておくことは重要です。
少なくとも以下は準備しておくことをお勧めします。

  • 全体データモデリング/ データフロー図作成

  • アーキテクチャ（概要）設計

  • API 構成概要設計

    • この時点である程度全体を俯瞰した上でリソースの構造等を整理し認識を合わせておくことで、Sprint 開始後の開発者間でのコミュニケーションがスムーズになります

  • バックエンド環境構築

    • クラウドシステムのアカウント発行やネットワーク構築、それに伴う社内申請が必要な場合はそれらも済ませておく

  • フロントエンド構成/開発フレームワーク策定および構築

    • SPA or SSR、それに伴う開発フレームワークの構築等

ただし、この時点では設計を詳細まで詰めすぎないことも重要です。以下のようなやめる基準をチームで決めると良いかもしれません。

  • データモデリング：NoSQL or SQL が判断できるまで
  • アーキテクチャ作成： サーバーレス or コンテナ等のコアとなる構成が策定できるまで
  • API 初期案設計: 概念データモデルのエンティティに対応するリソースの階層構造が把握できるまで

開発環境構築

スクラム開発では継続的に顧客に一定の価値を届け続けることが望ましいとされます。
ただし特に初期の Sprint では開発環境の準備等に追われ、顧客価値を届けられるまでに至らないといったことが
往々にして起こります。
そのため、初期 Sprint で顧客に価値を届けるためのタスクに着手できる レベルまで準備しておきましょう。
例えば以下のようなタスクはなるべく Sprint0 の間に開発者が準備しておくことをお勧めします。

  • バックエンド環境構築
    • クラウドシステムのアカウント発行ネットワーク構築、それに伴う社内申請が必要な場合はそれも済ませておく
  • フロントエンド構成/開発フレームワーク策定および構築
    • SPA or SSR、それに伴う開発フレームワークの構築
  • CI/CD 環境構築
  • IaC 環境構築
  • テストフレームワーク策定/設定
  • 静的コード解析ツールの設定
  • git ワークフロー策定/ 上記 commit 済みのリポジトリ作成

プロダクトバックログアイテム(PBI)作成

上記ユーザーストーリー及びお絵描き時に出てきた付箋等を元に、プロダクトバックログアイテム(PBI)をリストアップしていきます。
JIRA では以下のようなイメージでチケットが作られていきます。

また、各 PBI に詳細な説明文を記載していきます。
我々は説明の内容内容としては以下のような形を採用しています。

  • [Why] 概要・目的・ビジネス価値
  • [How] 受入条件 + テストシナリオ
    • ユーザー目線での操作を受け入れテストのシナリオのような形で書くことで、要件を具体化しつつ詳細すぎる表現を避けることができます。

この時点で（できればユーザーストーリーの時点で）意識しておきたいのが、INVEST の観点です。
ここではそのうち、我々が得に重要だと感じ、かつ捉え所が難しい N, S, T についてお話します。

S: Small（小さいこと）

「小ささ」の度合いとしてはチームでちょうど良さが変わるかもしれませんが、基本的には「ひとまとまりの価値」という形は意識しつつも、できる限り小さくした方がいいです。小さくすることのメリットは以下のようなものが挙げられます。

  • 予想外のサブタスクが生じにくい
  • 結果、見積もり精度が上がり予定通り完成できる
  • Sprint 完了時に途中まで進行している PBI が発生しにくい

途中まで進行している PBI は顧客に価値を提供できていないため、基本的には Velocity 0 として扱われます。スクラム開発では Velocity の測定は極めて重要ですが、このような状況が頻発しているとタスク進行の予測性が下がり進行に大きな影響が生じてしまいます。 各 PBI のサイズとしては、最大でも 1sprint で消化できるボリュームの半分以下 となる程度には小さく分割しましょう。

基本的に小さくして困ることは少ないですが、
「適度に」小さくするためには以下のような部分を意識すると良いと感じています。

  • 大きすぎを防ぐ：複数の機能を盛り込まない

    • NG 例: 〜〜の情報をリスト表示でき、ソート、削除、編集が可能
    • OK 例: リスト表示 / ソート / 削除 / 編集 個別 それぞれ PBI として分ける
      　 → その上で本当に必要か？をしっかり話し、重要でないものは積極的に優先度を落とすことを検討する

  • 小さすぎを防ぐ：それ単体を実装してシステムが破綻しないこと

    • NG 例: 動画を再生できる、ただし動画を再生したらどこにも遷移できなくなる
    • OK 例: 動画を再生でき、終了したら「終了ボタン」を押すことでホーム画面に戻ることができる

N: Negotiable（交渉可能であること）, T: Testable(テスト可能)

私としてはこの N の捉え方が正直かなり難しいと感じています。要は具体的すぎず、実現方法については適宜交渉可能である程度にしておくべきということを意識しています。
ただしここを拡大解釈しすぎると「曖昧すぎる」PBI が出来上がってしまい、開発不可能になってしまいます。
そこで歯止めになるのが T: Testable 　です。この N と T の両立が一つの鍵になります。
すなわち、「実現方法は柔軟で交渉可能である」けれども「受け入れ要件は明確になっている」という 2 者を両立することが重要です。
ここに関しては初めから完璧な PBI は出来上がらないので、コミュニケーションを密にとることが重要です。
ただ私が経験した中では、「曖昧すぎる」ことで困ることが多かったです。
まずは、PO は実装できる程度に「具体的」である表現を心がける、開発者はその 「意図」 を理解することを心がけ、
代替案やより簡易的な実現方法があれば積極的に意見を出す形でブラッシュアップするスタイルがお勧めです。

Product Backlog Refinement(PBR)

スクラム開発において PBR をうまく進められるかがプロジェクトの鍵を握っているのではないかと最近は感じております。
ただこのイベントは詳細に語られている記事も少なく、あまり経験のない方はどのようにしていいか最も迷うスクラムイベントだという方も多いのではないでしょうか。

本記事においては Sprint1 を開始するための作業にフォーカスしますが、基本的な方法はスクラムが始まっても大きく変わらないです。

本イベントで達成すべきことは以下の通りです。

  1. 直近の Sprint で開発する予定の PBI における、PO（主体）による詳細定義及び全チームメンバーの理解/認識合わせ
  2. 開発者による Sprint Backlog Item (SBI)の作成
  3. 開発者による見積もり

これらは次回 Sprint 分の PBI に関しては must、次々回 Sprint も可能であればやっておくことをお勧めします。
1 に関してはスクラムチーム全員で集い、PO にまず内容を説明してもらい、その場で他メンバーが質問をして適宜修正をしながら認識を合わせます。

ここで重要となるのは、PBI の内容でわからないことは開発者間であーだこーだ議論せず、遠慮せずどんどん PO に聞くことです。一生懸命想像して時間をかけて SBI を作って、全然見当違いでした、というのでは時間がどんどん無駄になります。従って、PO へのコミュニケーションのしやすさが極めて重要となります。忙しすぎる PO の場合はここが回らず必ずと言っていいほど苦労しますので、チームビルディング時に PO の時間は必ず確保できるようにしておきましょう。

とにかくしつこいくらい PBR で会話を繰り返すことが大切です。
開発者視点で、明確でなく開発に着手できなさそうな点を感じたらどんどん PO に質問すべきです。
スクラムマスターは以下の点を意識し支援する必要があります。

  • 開発者が遠慮なく PO に質問できるようにする
  • 議論が空中戦になっていることを感じたら適宜確認するための声掛けをする
  • 積極的に情報を可視化（文面化・文字化）し議論を整理する(あるいはそうするようにチームに促す)

PO はこの段階で質問攻めにあいがちになりますので、懇親会を開くなどチームの和を築くことも大切です！

2 に関して、各 PBI を実現するためのより詳細な子タスクを出し、これを Sprint Backlog Item (SBI)とします。我々は JIRA の PBI に対して子タスクを追加する形で抽出しています。

この作業を通してタスクを明確化すると同時に、開発者が深く PBI を理解することにつながります。
また SBI を出すにあたり PBI の説明内容が不十分である箇所が浮き彫りになってきますので、PO と密にコミュニケーションをとり、必要に応じて説明を明確化していきましょう。
開発者間であらかじめ疑問点を赤字で記述して整理しておき、PO と対面で擦り合わせる等の方法をとると効率的です。

また、各 PBI 毎に 確実に結合テスト（システムテスト,シナリオテスト等）等を完了させるようにします。そのためには上記例のようにテストケース作成&実施も子タスクに追加しておく等で管理しておくのも一つの方法です。
PBI は基本的に顧客価値単位で作成されますので、「価値を届けられる状態」すなわちテストも完了しいつでもリリースできる状態にしておくことで「完成」となります。
他にもプロジェクトによって作成が必要なドキュメント、あるいはレビュープロセスがあるかもしれません。
これらも全て完了させておくことがスクラム開発では基本的な方法となります。
別途 「完成の定義 Definition of Done (DoD)」 としてチーム内で定義し明記しておきましょう。

3 に関して、 SBI を出し切った PBI に関しては、開発者の間での作業の認識が概ね取れていることになります。
我々のチームでは PBI 毎に見積もりを実施し、以下のような方法で進めています。

  • 基準となる PBI のストーリーポイントを決める（以下のいずれかの方法）
    • どれか基準となる「中くらいの」規模の PBI に、あるポイント（例えば 5）を与える。
    • 現時点で 1 日かかるタスクを例えば 2 ストーリーポイントとしてつける（1 としない理由は、半日で終わるタスクに対しポイントが定義できなくなるためです。）
  • 他の PBI に対し、基準となる PBI に対する相対的な規模としてストーリーポイントを付与する
    さらに小さく PBI を定義する場合には、ここで 3 ポイント、5 ポイントなどとしましょう。
    ストーリーポイントはフィボナッチ数列がよく使われます。大きすぎる値ほどブレが大きくなることを表現するという意図があります。（13 か 14 かで悩んでも意味がない）

ここで、ストーリーポイントが大きすぎる PBI は細分化することを考えます。長くとも 1 スプリントの半分の期間で終わらなさそうな PBI に関しては、細分化することを強くお勧めします。
ストーリーポイントの決め方としては プランニングポーカー が有名です。こちらも有名な手法ですのでこちらでは割愛します。開発者「全員で」認識を合わせた上で見積もることが重要です。

直近 Sprint の未経験技術調査

PBR において、経験がなく SBI 作成や見積もりを進めることが難しい場合、優先度の高い PBI に関する内容から技術調査を着手しておきます。
時間やスキルセットによってどこまでやるべきかは変わりますが、やりすぎない ことも重要です。
ある程度作業規模を見積もれる程度でやめておくことが望ましいです。
完璧に見積もりを当てることは重要ではありません。早期に開発を実施し経験値を積むことでチームとして成長していくことの方が重要です。

Sprint Planning

Sprint 内に着手するバックログを決めます。
以下の形で進めます。

  • PO が各 Sprint で達成したい Sprint Goal を伝える
  • PO が SprintGoal を達成するために必要な PBI を選択し伝える
  • 開発者が Story Point をもとに Sprint 内で完了できそうかどうかを判断する。必要に応じてスコープを交渉する。
  • チームの合意のもとで上記を確定し、Sprint を開始する。

基本的には PBR をしっかり実施しておき、SprintPlanning は短時間で最終的な決定をする場にできるとスムーズです。

Sprint を開始すると、JIRA では PBI 毎に カンバンのようにタスク管理できるようになります。この点も非常に便利です。

上位の PBI から一つ一つの PBI 毎に着実に完了していくことが大切です。「完了」していない PBI は原則として velocity は 0 です。（顧客に価値を届けられていないため。）
ここからは力を合わせてガンガン倒していきましょう！

今後、Sprint1~ の動き方も同様に書いていくつもりですので、読んでいただければ幸いです。

Discussion