スクラムにおける前提知識と業務分析＆設計（後編）

アジャイル開発センターです。

アジャイル開発における代表的なフレームワークであるスクラムについて、業務分析と設計の進め方の一例を前後編でお届けしています。後編では、Sprint 1以降で行うことについて解説します。

Sprint 1で行う設計

Sprint 1では、最初のプロダクトバックログから優先順位の高いPBIに対して機能設計と詳細設計を行います。そして、インクリメント^※1として実際に動くシステムを開発します。

※1 スプリントの成果物のこと。これまでのスプリントの成果物全ての累積となる。
開発においては通常、リリース可能なプロダクトとなる。

システムを開発していくには、機能設計・詳細設計を順に実施するのがスクラムでも定石となります。設計書はスクラムチーム^※2およびステークホルダー^※3が共通理解を得られれば作成は必須ではなく、作成するとしてもWikiシステムを利用などして作成のコストを下げる工夫も1つの手段です。

※2 開発者・プロダクトオーナー・スクラムマスターの3つの責任を定義されたメンバーで構成されたチームのこと。
開発者の役目は、専門家としてスプリントバックログとインクリメントを作成すること。
プロダクトオーナーは、プロダクトの機能や構築の優先順位の最終決定権を持ち、プロダクトの価値を最大化することの結果に責任を持つ。スクラムマスターは、チームメンバーがスクラムの価値を理解しプロセスを正しく実践することに責任を持つ。通常、開発者・スクラムマスターとなるメンバーは、プロダクトオーナーの役割を持つことはない。

※3 スクラムチームに所属してはいないが、プロダクトに対して利害関係を持つスクラムチーム以外の人。
主にプロダクトの利用者やスポンサー、社内の上司・他部門などが該当する。利害関係を持つ登場人物ではあるが、開発者に機能の構築や要件変更の指示を直接行うことはできない（しない）。機能の構築や要件変更の要望はプロダクトオーナーに対してのみ行う。

アジャイル開発センターでスクラムを採用してアジャイル開発を進めていった印象としては、Sprint 1においてシステム全体の設計も実施し、システム方針を決定しておかないと、後続のSprintのどこかでシステム方針と合わずにインクリメントとして作成した成果物の価値が評価しづらくなる、というものがありました。また、MVPよりも小さい単位で、まずは最低限の動作を行う環境（トップ画面を表示するのみなど）を作ることを目的とするということも必要と感じました。

最初のインクリメントとして、「どの範囲をどの程度まで含めるのか」という判断を注意深く行う必要があります。最終的にはチームでどのくらいまで開発できるか検討し、Sprint 1で設計する範囲を決めなければなりません。

Sprint Nで行う設計

Sprintの最初に行うスプリントプランニングで、前Sprintまでのインクリメントとプロダクトバックログを基に、今Sprintで対応するPBIを選択します。スプリントプランニング^※4で選択したPBIは機能設計を行い、今Sprintで完了するよう詳細設計、実装、テストを行います。

※4 Sprint開始時に行うスクラムチームだけで行うミーティング。
今Sprintのゴールを話し合い、ゴールを達成するために必要な作業を計画する。
設定したSprintの期間にもよるが、1週間Sprintでは2時間以内で終わらせる。

スプリントプランニングの結果、単に機能を追加するだけであればその機能にだけ注力すればよいですが、既存機能に影響がある場合は既存機能の変更も含めて設計を行います。アジャイル開発では常に変更が発生する可能性があることを念頭に開発を進めるので、いかにメンテナンス性が良い状態を保つかが重要になります。変更しやすくメンテナンス性が良い状態を保つために、シンプルな設計を行うことが最も重要なポイントです。

さらに、開発と並行してプロダクトバックログリファインメントと呼ばれる作業も行います。開発にかかわる全員が参加する必要はありませんが、前Sprintまでのインクリメントとスプリントレビューの結果を基に、プロダクトバックログの整理を行います。

まずは、前Sprintまでに気づかなかった新たな価値を提供する必要がないかを確認します。新たな価値を提供する必要があると確認できた場合は、当然のことながらプロダクトバックログへPBIを追加します。また、前Sprintのレビュー結果とインクリメントのリリース後における価値評価のフィードバックもプロダクトバックログへ反映します。その上で、次のSprintの準備を行います。

ここまでに整理されたPBIの優先順位と価値を明確にし、より高い価値を提供できる順でPBIを並べ替えます。ここで、設定したSprintの期間内に完成できないと判断されたPBIがある場合、該当のPBIを分割する、もしくはPBIの内容を縮小するなど見直してSprintの期間内に収まるよう該当のPBIを調整します。

これによりSprint 0で決めたMVPを決定しなおすこともありますが、その場合でもMVPを小さく保てるように注意を払う必要があります。MVPへ新たなPBIを追加することは簡単ですが、価値が低いことに気づいたPBIについては優先順位を下げたりPBI自体を削除したりすることが必要となります。優先順位が上位となっているPBIについてはスプリントプランニングが行える程度の機能設計を行います。この時、必要であれば基本設計についても検討します。

おわりに

スクラムを大きく3つのフェーズに分け、各フェーズで行う業務分析と設計についてお届けしました。ウォーターフォールと異なる部分もあります。共通する部分もあると感じられると思います。

前編でも少し触れましたが、アジャイル開発センターのメンバーで、あるプロジェクトを前編・後編で説明した指針／内容に沿って進めていったのですが、当初は失敗ばかり繰り返していました。失敗の内容は、予定しているSprintで完了しない（＝フィードバックを受けられない）、PBIが完了しない（＝延々と同じPBIを複数Sprintで続けている）、など様々でした。失敗してばかりいましたが、失敗してもいいから進めていく、ふりかえりで気づきを得て少しずつ修正していく、ということを続けた結果、業務分析とは関係ない内容ではありますが、わかった内容があります。

1つ目は、タスクを止めるという提案を開発者ができることが重要であるということです。タスクが止まる、だったり、止まってしまった、ではなく、開発者の意見としてタスクを止めるようデイリースクラム^※5で情報を共有し、スクラムチームとしてタスクを止めるか検討・判断をする、ということです。タスクを止めるという提案を開発者のレベルで行っても問題ない、と認識することが重要です。

※5 スクラムチームだけで毎日行うミーティングとなる。
今後の作業を調整しながら、ゴールに対する進捗を確認し、必要に応じてスプリントバックログを適応させる。
毎日、同じ時間・同じ場所で開催し、15分で終わらせることが必須である。

2つ目は、ものを作るだけが価値ではない、という認識を持つことです。スプリントレビュー^※6のタイミングで、失敗したインクリメント（＝動作しないプロダクト）と判断されたものは失敗したという価値を持ちます。

※6 Sprintの最後、スクラムチームのメンバーとステークホルダーが参加し、インクリメントの評価ができる段階で行うミーティング。
Sprintの成果（＝インクリメント）を検査し、今後の適応を決定することを行う。
設定したSprintの期間にもよるが、1週間Sprintでは1時間以内で終わらせる。

1回のスプリントで作成されるインクリメントは影響度が極めて小さいため、失敗したインクリメントだとしても、次Sprintで修正が可能です。失敗したことに対してリカバリー（ときには非難だけ）して終わりではなく、失敗した原因をスプリントレトロスペクティブ^※7などにおいてスクラムメンバー全員で共有し、最適な解決方法をスクラムメンバー全員で模索し、解決方法を共有することが重要です。

※7 Sprint終了時にスクラムチームだけで行うミーティング。このミーティングを持ってSprintが終了する。
Sprintの成果以外（相互作用、プロセス、ツール、完成の定義 etc...）に対して検査する。スプリントレビューがSprintの成果に対するレビューであることに対し、こちらは主にSprintで発生した問題や良かった点についてのレビューを行う。
設定したSprintの期間にもよるが、1週間Sprintでは45分以内で終わらせる。

3つ目は、情報はスクラムメンバー全員で共有することです。どんな小さな内容であっても、スクラムメンバー全員がその内容の認識がないと、インクリメントにどんな影響が出てくるかわかりません。短い期間で価値の高いインクリメントを作成し続けるためにも、どんな小さな情報であってもスクラムメンバー全員で共有することが重要です。

Sprintの期間を短くとっていれば、小さな影響で素早く対応できることがアジャイル開発の最大のメリットであるかもしれません。

今まで経験してきた内容と異なる部分をいかに理解し、メンバーが共通認識を持って進めるかということが、アジャイル開発の第一歩です。