アジャイル開発の２種類のスケジュールとそれぞれの作成ステップを解説

「アジャイル開発のスケジュールってなんなんだろう？うちはアジャイルのはずなんだけど、スケジュール作ってみたら、やることは山盛りだし、納期はギリギリだし、開発リソースもカツカツだから結局ウォーターフォールでやってた時との違いがわからない」

こんな悩みはないだろうか。

筆者は、エンジニア・開発PMの両方の立場で、複数のアジャイル開発プロジェクトを経験してきた。そして、同じ様な悩みに苛まれたことがあった。

「アジャイルとはいっても、やることと期日が固定化されててつらい」「スケジュールがどんどん遅延し始めているけど、気合いで乗り切る雰囲気になっててまた土日出勤しないといけないか」

この記事ではそんな読者の方に向けて、アジャイル開発におけるスケジュールの立て方、管理の仕方について以下のポイントに沿って説明する。

それではさっそく見ていこう。

アジャイルのスケジュールには２種類ある

アジャイルのスケジュールには以下の２種類ある。それぞれについてその役割や何をするべきかを説明していく。
・リリーススケジュール
・イテレーションスケジュール

リリーススケジュール

リリーススケジュールとは、具体的に言うと、直近の半年程度で実現したいユーザーストーリーとそのリリース日から構成される。

リリーススケジュールを作るのが重要なのは、以下の３つの理由からだ。

例えば、以前企業のサステナビリティレポート作成システムの開発プロジェクトでの話だ。

そのシステムは、さまざまな社内のデータを一元管理し、レポート作成の際にそれらを活用できることを売りにしていた。それによって、データのやり取りをするためのコミュニケーションの煩雑さを取り除こうとしていた。例えば、複数の工場を持つ企業が、各工場の電力使用量のデータとその証拠となる画像データなどを管理できたりする。

そこでは、リリースを以下の２つに分けた。
・各種のデータを登録・管理できる
・各種のデータを使ってレポートを作成できる

これによって、それぞれのリリースで必要になるストーリーを取捨選択することができた。

また、開発完了時期の目安が予めわかっていることで潜在顧客に対してヒアリングやお試し利用のお願いもリリース前から仕込むことができた。

さらに、開発チームとしてもリリースという明確な目標に向かって走ることができた。特に、期限が決まっていることで何の要件をいつ詰めるかなどに共通認識を持って進めたのでチームのコミュニケーションが洗練された。例えば「第１リリーススケジュールの途中でまだ余裕がない段階で、第２リリースの案件の詳細は詰めない」などの共通認識があった。そのおかげで、ビジネスサイドの担当者としては「いつ」、「どの案件の」相談をすれば良いのか分かりやすくなったという声があった。

イテレーションスケジュール

ある特定のイテレーションで対応するユーザーストーリーのための開発タスク群とその対応スケジュールだ。

イテレーションスケジュールでは、以下のアウトプットが作成される。

例えば以下のような具合だ。これはオンライン英会話サービスの中の一つのストーリーをタスクに分解し、工数を時間で見積もった例だ。タスクの付箋についている赤丸の数字が工数だ。

リリーススケジュールを立てる６ステップ

ここでは、プロジェクト全体のスケジュールであるリリーススケジュールの作り方について解説する。前提として、プロジェクトで必要なユーザーストーリーは全て特定された後を想定している。

具体的には以下の６ステップを行う。
・見積もりを立てる
・プロジェクトで行うことの優先順位をつける
・ベロシティを推測する
・全ての見積もりの完了予測を立てる
・ベロシティを計測する
・全ての見積もりの完了予測を更新する

１：プロジェクト全体のストーリーポイントを見積もりを立てる

全てのユーザーストーリーに対して見積もりを行い、プロジェクト全体のストーリーポイントを算出する。

この時見積もりは、プランニングポーカーを使ってやるのが良いだろう。これをすることで、チーム全体がプロジェクトの内容をしっかりと把握する機会になるし、見積もりの精度も向上する。

プランニングポーカーの詳細は以下の記事に解説しているので、ぜひ参考にしてほしい。
無謀な締め切りに追われたくない人のためのアジャイル開発の見積もり

例えば、以下の様に見積もりを行う。この例では、このプロジェクト全体のストーリーポイントは３０ポイントであることが判明した。

２：プロジェクトで行うことの優先順位をつける

次に、プロジェクトでの開発の優先順位をつけていく。全ストーリーの開発工数のサイズ感が把握できたので、ビジネス的に優先度の高いものから着手していく様に優先度をつける。

このビジネス的な優先度と言った時、プロジェクトが解決するべき課題としての重要度と、開発観点でリスクの高いものが挙げられる。

それらの視点で発注者と受注者であるエンジニアが協議して優先順位を決めていく。

３：チームのベロシティを推測する

次に、チームの一定期間内でのストーリーポイントの消化力であるベロシティを推測する。まだ開発が始まっていないので、一定期間でのストーリーポイント消化力がわからないから仮決めをする感覚だ。

例えば、最初のイテレーション（２週間などの固定された開発期間）では、どれくらいのストーリーポイントを解消できそうかという開発メンバーの肌感覚をもとに決定される。

例えば、最初のイテレーションでは企業と求職者の登録処理が完了できると推測したとしよう。この場合はベロシティを６ポイントと推測したことになる。

４：全ての見積もりの完了予測を立てる

ここでは、仮のベロシティとプロジェクト全体のストーリーポイントをもとに完了予測を仮で立てる。

ここまでの章で算出されている数字を使うと、このプロジェクト全体が完了するまでに５回のイテレーションが必要であることがわかる。

プロジェクト全体のストーリーポイント	３０
仮のベロシティ	６
プロジェクト完了までのイテレーション	５

これは以下の様な数式で表すことができる。

５：ベロシティを計測する

次に行うのは、より正確な、事実に基づいたベロシティを求めることだ。これによって、プロジェクト完了までのイテレーションがより正確に把握できる。

今までは仮決めの推測によるベロシティを利用していた。それは、まだ開発がスタートしていなかったので、そうするしかなかったためだ。

しかし、イテレーションを２〜３回経験すると、実際の開発のベロシティが算出できる。例えば、２回目のイテレーションが終わったタイミングで「企業が求めている求職者を見つけられる」まで開発が終わっていたとしよう。

この場合このチームのこの時点でのベロシティは7.5になる。なぜなら、２回のイテレーションで１５ポイントを完了させているからだ。

６：全ての見積もりの完了予測を更新する

前の章で、ベロシティの認識を更新した。それに伴って、ここではプロジェクトの完了見込みに対する認識も更新する。

ベロシティが想定より高い数字だったため、完了までのイテレーション数も短くなる。以下の数字をもとに計算した結果プロジェクト完了までには４回のイテレーションが必要だということがわかった。

プロジェクト全体のストーリーポイント	３０
更新されたベロシティ	７.５
プロジェクト完了までのイテレーション	４

この場合は、プロジェクト完了までが前倒しされたが、逆の場合も当然あり得る。

イテレーションスケジュールを立てる５ステップ

イテレーションスケジュールを作る際には以下の５つのステップを踏むことになる。

1 各ユーザーストーリーの優先度を調整する
2 ユーザーストーリーを一つ選ぶ
3 タスクに分解する
4 工数を見積もる
5 上記２〜４を、該当するユーザーストーリーのリリースを確約できない量の見積もりが完了するまで続ける

それぞれ詳しく説明していく。

１：各ユーザーストーリーの優先度を調整する

まずは各ユーザーストーリーの優先度を調整する。

このステップの目的は、次のイテレーションで行う作業がしっかりと正しい優先順位に基づいて行われるようにするための下準備をすることだ。

そのため、未着手のユーザーストーリーの優先度を付け直す。

２：ユーザーストーリーを一つ選ぶ

ここでは、優先度の高い順にユーザーストーリーを一つ選ぶ。

３：タスクに分解する

ここでは前のステップで選んだユーザーストーリーを実際にタスクベースに分解していく。

実際に何をすると該当のユーザーストーリーが完成するのかを見通すことで、詳細な工数の見積もりが出せるようになる。

また、この際にチームメンバーで闊達な意見交換をすることで開発が始まる前から、ハマりどころや効率良く開発をするための知見をチーム全体で共有することができる。

例えば、以下のようにユーザーストーリーを分解することができる。

４：工数を見積もる

このステップでは、前のステップで出したタスクリストをもとにストーリーの工数を見積もる。

この時はストーリーポイントではなく、時間で見積もる。そうしないと該当のユーザーストーリーを次のイテレーションで終わらせられるかが判断できないからだ。

５：イテレーションでリリースできる上限まで上記２〜４を繰り返す

ここまでで、一つのユーザーストーリーのタスクの洗い出しと工数がわかった。

ここでは、具体的なタスクと工数が判明したユーザーストーリーを次のイテレーションでリリースまで持っていくことにコミットできるか確認する。

コミットできなければここでイテレーションスケジュールは完成だ。コミットできて、さらに余裕があるのであれば２〜４の手順を繰り返しさらに多くのユーザーストーリーの開発を進めることになる。

アジャイル開発でスケジュールを立てるために知っておくべき２つの大前提

この章では、そもそもアジャイル開発のスケジュールがうまくいくための大前提となる２つのポイントを説明する。それが以下の２つだ。

開発の優先順位を明確に判断する

まず重要なのが、開発の優先順位を明確にするということだ。

そもそも開発プロジェクトは何かのビジネス的な目的を達成するために始まる。加えて、プロジェクトで使える資金も期間も限られていることが普通だ。無限にお金を使えるし、開発完了が１年後でも５年後でも１０年後でも良い開発プロジェクトはないはずだ。

つまり、限られた時間とお金（開発リソース）の中で、ビジネス的な目的を達成できるシステムを開発するのがプロジェクトのゴールだ。そのため、開発したい機能の優先順位が明確になっている必要がある。

逆に、そもそも優先づけがされていない場合の問題点は、やるべきタスクがプロジェクトの期間内で開発可能な量以上になりがちなことだ。あったら良さそうな機能はいくらでも思いつくことができるので、要件は膨らみやすくなる。

その結果として、プロジェジェクトはいつまで経っても終了しないか、終了した際にビジネス的な目的が達成できないシステムが完成していることになりかねない。

スケジュールを常に現実に即した状態にしておく

次に重要なのが、スケジュールを常に現実に即した状態にしておくという点だ。

これがなぜ重要なのかというと、そもそもプロジェクトにおけるスケジュールは信頼できることが重要だからだ。そのスケジュールが信頼できるから、それに基づいたさまざまな意思決定をしていけることにつながる。

例えば、新築マンションを買いたい人通りたい人のマッチングサービスを開発する場合を考えてみよう。この場合、サービスが完了した段階でプレスリリースやマーケティングの一環として広告を出稿したりすることが考えられる。また、そもそもマンションを売りたい人として不動産のデベロッパーなどに営業をかける可能性も考えられる。

そこで、以下の２つのスケジュールがあったとする。この場合、前者のスケジュールよりも、確度の高い後者のスケジュールの方が嬉しいはずだ。

なぜなら、他社に営業をかけたりするということを考えると、万が一（というか７０％の確率）で発生する工数遅延の際のコミュニケーションコストなどが発生しないからだ。それに、そもそも「３０％で３ヶ月で完了する」ということ自体に信頼感が持てないと思う方が多いのではないだろうか。

「開発の優先順位を明確に判断する」ために必要な基準３つ

開発の優先順位をつけるためには、明確な基準が必要だ。そして、その基準には以下の３つがある。
・金銭価値
・開発コスト
・新しい知識

金銭価値

金銭価値は一番一般的なものだ。単純に、その機能によってどれだけの金銭価値が発生するかというものだ。

例えば、ECサイトにおいて定期購入機能の開発を検討していたとしよう。その場合は、その機能を使ってくれる人がどれくらいいて、それぞれが月にどれくらいの金額の購入をしてくれるのかで算出することができる。

開発コスト

開発コストも一般的な指標であり、単純に工数見積もりの数字をもとに判断することになる。

新しい知識

その機能を開発することによって得られる知識量とその意義についての判断基準だ。

この新しい知識を得ることで、不確実性をどれくらい下げられるかというのがポイントだ。そして、その不確実性は「何を作るか」と「どう作るか」の二つに大きく分けられる。言い換えれば、プロダクト的な不確実性かプロジェクト的な不確実性かの違いだ。

プロダクトの不確実性は、本当にこの機能に価値があるのかを検証できる案件はポイントが高いことになる。

オンライン英会話のサービスを開発しているとしよう。このサイトの売りは「英語圏以外の国の先生と話ができて、さまざまな国の訛りに対応できる英会話スキルを身につけられる」ことだとする。その場合は、「課金の仕組み」を作るよりも先に、まず「ビデオ通話の機能」が必要だと判断できる。

プロジェクトの不確実性は、どうやってプロジェクトを進めていくかや、どうやって開発をするかについて検証できるとポイントが高い。

例えば、初めてAWSを使う開発チームの場合に「AWSの技術検証で一通りのインフラを作る」と言う案件は、今後のサービス開発をAWSで行っていけるのかを検証できるためとても重要だ。

もしくは、例えばブログサービスを運営していたとする。その際に、初めて広告を出稿してくれる企業が見つかり、自社の営業担当者と広告出稿企業の担当者、そしてシステム開発者の３者がコミュニケーションを取る必要が出てきたとする。この場合、この案件自体は金銭価値もあるが、それに加えて複数のステークホルダーが関わる案件の進め方についての知識を得られるという価値もあることになる。