アジャイル開発でのリリース計画の立て方 - エムティーアイエンジニアリングブログ

一般的なアジャイルのリリース計画（複数スプリント分をまとめてリリースするケース）

はじめに

テクノロジー本部プロジェクト推進部の深澤です。私は３年間、Fintech事業のプロジェクトでPOやPMを担当してきました。アジャイルに関しては独学での知識でずっと業務を行っていたため、基礎を体系的に学び直したいと考え、社内アジャイルトレーニングに参加しました。過去の現場での経験が体系的な知識のアップデートと結びつき、とても有意義な学びとなりました。
本記事では、アジャイル開発プロジェクトにおけるリリース計画についての考え方と、関係者で共通理解を持つポイントについて書きたいと思います。基本的なことではありますが、様々な関係者とプロジェクトを進めていく中で、意外と難しいと私自身が感じた部分でもあります。
結論を先にお話ししますと、以下を関係者（顧客含む）としっかりと共通理解を築くことが重要だと考えます。（ここでは”計画”にフォーカスした共通理解に絞ります。）

アジャイル開発を行う目的を理解する
先々の見通しを常にアップデートして共有する
初期見積を確度の高いものだと思わせてはいけない
リリース日を固定し、スコープに柔軟性を持たせる
バッファマネジメントを計画に取り入れる

※アジャイルマインドセットの理解・共感は大前提となりますが本記事では省略します。

アジャイル開発の特徴と目的

アジャイル開発とウォーターフォール開発の特徴がこちらの記事で紹介されていますのでまずはご確認ください。

tech.mti.co.jp

アジャイル開発は、要求の変更に対応しやすい”柔軟さ”が強力なメリットである一方、”要求に対する納期のコミットメントが難しい”というデメリットがあると言われています。
不確実性の高い現在のビジネス環境の中で、変化するビジネスゴールや要求に常に適応して、顧客や事業の競争力を高めるために、私たちはアジャイル開発を行うのです。

見通しの立て方

アジャイル開発にはいくつかの手法がありますが、ここからは代表的な手法であるスクラムの用語・ルールを前提として話を続けていきます。

アジャイルでは、１スプリント内でどれだけの開発が行えるかという視点で先々の見通しを立てます。スプリントというのはタイムボックス化された開発期間のことです。
プロダクトバックログ（実装すべき要求の一覧）があって、要求ひとつひとつにあたるプロダクトバックログアイテム（以下、PBI）を開発チームが見積もり、スプリントでどのPBIを実装するのかを決めます。
見積には相対見積という方法が使われることが多いです。相対見積では時間ではなく”サイズ”で考えます。基準になる要求を定義して、それと比べてどれくらい大きいか小さいかという視点で見積をします。最終的にはストーリーポイントという単位に落としこみます。

tech.mti.co.jp

では、時間ベースで見積をしていないのに、チームがスプリントで扱えるPBIの量をどのように予測するのでしょうか？
それは、ベロシティを使います。ベロシティとは、チームが1スプリントで完成させたPBIの見積りの合計を表す数字で、チームの開発速度を表します。スプリント毎に多少増減することもあるため、直近の数スプリント分を平均して算出します。例えば、現在スプリント3が終わったとします。それまでのスプリントで完成したPBIの合計がそれぞれ、スプリント1＝20ポイント、スプリント2＝17ポイント、スプリント3＝23ポイント　の場合は平均値の20ポイントをベロシティとします。
リリースに必要なPBIがあと60ポイントの場合、60÷20＝3スプリントが必要という計算になります。

必要なスプリント数 = リリースに必要なPBIの見積りの合計 ÷ ベロシティ

そして、認識しておかなければならないのは、プロダクトバックログは常に変化していきます。スプリントレビューでのフィードバック、新たなアイデア、要求の変化等によって増減します。それらを踏まえて、スプリント毎に見通しをアップデートして関係者に共有するのです。

生じる疑問

いま私たちは、とあるプロジェクトの開発を着手する前だとします。

ベロシティはわからない（数スプリント回してみて見えてくるもの）
変化していくプロダクトバックログを予測することはできない（そもそも最初に全ての要求を集められない）

これらの事実がある中で、プロジェクトの初期段階（または受注前）に私たちが提示する見積やリリース計画（スケジュール）は一体何を意味しているのでしょうか？

初期見積には誤差がある

「（まだ曖昧な要求で、まだどんなテクノロジーを使うかも見えないのですが）見積もってください！」初期見積のシーンとして、ありえる話です。
「初期段階の見積には最大で４倍の誤差が発生する可能性がある」と言われています。プロジェクトが進行するにあたって不確実さも徐々に減りその誤差は減少していきます。よって、初期段階では見積が確度の高いものだと約束することはできません。また、明示的に約束しなくても、そう思わせてしまってはいけません。

不確実性コーン：縦軸は見積の誤差、横軸はプロジェクトの進行状況を表しており、誤差は進行するにつれて縮小していく。

リリース計画（スケジュール）提示の際のポイント

1. 大前提の理解

まず大前提として、アジャイルは不確実性への対処を主な目的としたものであり、「決められたものすべてを決められた時期までにやりきる」ためのものではないです。最初に要求を全て集めることはできない、状況はどんどん変化する、ビジネスゴールと要求も変わっていく、そんな不確実な環境下で顧客の競争力を引きあげるために、変化に適応していく手法なのです。
よって、まずはこの前提を関係者が理解する必要があります。

2. スコープに柔軟性を持たせる

先々の見通しが何も約束できないと、顧客は意思決定ができません。では、どうするのか？「決められた時期」は約束して、「決められたもの」に柔軟性を持たせるのです。
プロジェクト管理に影響を及ぼす品質、コスト、納期、スコープの４つの要素の中で、アジャイルではスコープに柔軟性を持たせるのが原則です。品質は犠牲にせず一定基準を満たし、限られた予算と時間のなかでスコープを調整しながら価値を最大化します。タイムボックス化したスプリント単位で開発していくのは、時間を有効に使って期日を守ることにも相性がよいのです。
スコープの調整を合意するための便利なツールとしてインセプションデッキを使います。

tech.mti.co.jp 「やらないことリスト」でマストのスコープを明確にします。「何を諦めるのか？（トレードオフスライダー）」で、スコープがトレードオフとなることを確認します。
これらを用いて、スコープに柔軟性を持たせることを関係者で合意するのです。

3. バッファマネジメント

そして、適切なバッファマネジメントをすることも必要です。
不確実な状況やリスクに対応するために、誤差を吸収するためのバッファを加えます。要求はどんどん変わっていき新たなタスクが生まれ、たいていの計画は上振れするのが当たり前なので、スコープに柔軟性を持たせる＋バッファマネジメントの二本立てでリスクを極力抑えるのです。

CCPM（Critical Chain Project Management）という考え方があります。各タスク（アジャイルの文脈ではPBI）には個別のバッファを持たずに見積をして、全体としての"期間バッファ"を積んでプロジェクトを管理する方法です。個々のタスクが遅れた場合、この全体バッファから消費していくという考え方です。
CCPMのメリットとしては、個別のタスクにはバッファが存在しないため、個別のタスクごとに作業を先延ばししてしまう等の現象を回避でき、その結果無駄なバッファの消費を削減できるのです。

そもそも、アジャイルでは一般的に相対見積を使うこと、また、透明性の観点からも個別バッファは適さないと私は考えております。個別バッファは使わずに、スプリント内で作業が完成できなかった場合は、その原因を振り返り、次に活かしていくのです。
私の過去のプロジェクト体験を踏まえたおすすめはCCPMの考え方で、その時点での要求のレベル感からどの位の全体バッファを持つのかを関係者で議論して決めることです。例えば、五分五分の確率だと皆が思うのであれば、全体の見積の50%を全体バッファとして計画（スケジュール）に積めるとよいのではないでしょうか。