計画やマネジメントの観点
次に、計画やマネジメントの観点を見ていきましょう。
見積りに影響するパラメータ
これから新しいプロダクトを開発する際に、スケジュールや費用をどうやって見積もればよいでしょうか。
それを考える上で、まず、これらの見積りに影響するパラメーターを見てみましょう。
ビジネス上の都合（マーケティング、新製品発売、法令改正、売上確保など）
予算
開発チーム外への依存関係（QA、セキュリティ）
開発作業のボリューム（スコープ、完成の定義）
開発チームの能力（ベロシティ）
これらは相互に関連する要素で、同時にすべてを固定にすることはできません。 したがって、ビジネス上の都合を優先するのか、開発のスコープを優先するのか、など何を優先すべきか共通理解を形成することが重要です。
また初期の時点では、いかなる数字の精度も低いので、スプリントを繰り返しながら適宜見通しを更新していくと良いでしょう。 このとき、既に同じチームでほかのプロダクトの開発をしたことがある場合は、チームの能力や経験をそのまま生かせるので、新たなチームで始めるよりも見積り精度は高くなります。
チームのサイズが決まっている場合の費用の見積もり
チームのサイズが決まっている場合、1スプリントあたりのチームにかかるコストはほぼ確定できます。 例えば1ヶ月スプリントでPOとSM、開発チーム6人で、それぞれの人件費が1人100万円であれば、月間800万円の費用になり、1スプリントあたりのコストはスプリントの期間に応じて算出可能で、以下の式になります（機材など諸経費は簡単のため省略）。
一方でスコープ網羅を目指して、スプリント回数が可変である場合は、プロジェクト初期では、何回スプリントをまわすべきかは確定できません。 というのはチームが1スプリントあたりにどのくらいの量を作れるかの数値がないからで、その場合は、プロジェクト費用の見積もりはスプリントを経るごとに正確になっていくことになります。
期間を優先し、チームのサイズをあとから決める場合
アジャイルな開発手法の多くは、チームを継続的に維持することによって、チームの文化や規律や技術力を向上させることに価値を置いています。 したがって寄せ集めチームを作ったりあとから人をどんどん追加していく方法はあまりうまくいきません。 一方で既存のチームに対して文化が壊れない程度に人を追加する（もちろんScrumのチーム人数の範囲で）というアプローチはないわけではありません。
この場合も実は前項の話とあまり変わりません。 チームのサイズをいじったとしてもチームが1スプリントあたりに作れるモノの量は、プロジェクト開始時点では正確には分からないので見積り精度が向上するのは、スプリントを実行してからになります。
スプリントの長さを決める
実際にスプリントを開始する前には、スプリントの長さを決めておかなければいけません。 スプリントは4週間までの固定の期間です。
期間を決定する上で影響を及ぼすのは以下のような項目です。
想定の期間
変化の度合い
フィードバックの回数
プロダクトの規模
開発チームのキャパシティや場所
完成の定義
たとえば、プロダクト開発の想定期間が3か月だとすると、4週間スプリントではフィードバックサイクルが3周しか回らないことになるので、改善効果が出ません。 また不確実性が高くなればなるほど、長い期間のスプリントでは途中の変化に脆弱になってしまいます。 これらを踏まえて、小規模や短期間のものであれば1〜2週間とし、大規模であれば2〜4週間にすることが一般的です。 なお、直感に反するかもしれませんが、スプリント期間が長いほうが難易度は上がります。
スプリントは短いほうがよい
1チーム規模の開発であればスプリントの期間は1週間がお勧めです。 その理由を列挙すると以下のようなものがあります。
レトロスペクティブ（ふりかえり）が頻繁にあるので改善が進む
計画の精度が高くなる
例え失敗しても一週間で済むので実験しやすい
ベロシティの数字がすぐ出るのでやる気になる
中だるみする余裕がない・リズムがよい
一週間で収まるサイズのプロダクトバックログ項目にするので明確な完成を定義しやすい。従ってプロダクトオーナーの受け入れを取りやすい
スパイクが必要なプロダクトバックログ項目が明確になる
プロダクトオーナーが変更を我慢しやすい
ごまかしが効かない
順番に見ていきましょう。
レトロスペクティブ（ふりかえり）が頻繁にあるので改善が進む
大きな理由の1つがレトロスペクティブの回数です。 たとえば、スプリントに使える期間が3か月だとすると、4週間スプリントはスプリントが3回、2週間スプリントで6回、1週間スプリントで12回となります。 改善の基本的な考えとして、うまくいったかどうかを判断しうまくいかない場合は元に戻す、一度にたくさんのことを変えないという点が挙げられます。 つまり毎回劇的な変化を加えるのではなく緩やかに変化していくことになります。 このとき改善の機会が少なければ少ないほど、試行錯誤して改善する機会が減ってしまい、最初と最後での変化は少なくなってしまいます （言い換えると上手くなる前に期限が来てしまいます）。 したがって、慣れていないうちほど、改善の機会をたくさん用意した方がよく、短いスプリントの方がその機会は多くなります。
計画の精度が高くなる
計画づくりは難しいです。 もちろん見積りも難しいです。 そしてこれらは規模が大きければ大きいほど難易度が上がります。 また、始めたばかりの段階だと、スクラムチーム全体がやり方に慣れていない、過去にどれくらいの速度で開発できていたのかというデータがないといった要因も、影響を与えます。 したがって、特に慣れるまでは、なるべく小さい単位で計画をたてて、計画と実際の差がどのくらいなのかを見ながら微調整していくことが重要になります。 1週間の計画を立てられないのに4週間の計画を立てられるということはないので、まずは短い範囲でいいので確度の高い計画を立てられるようにしてください。 そうすることで、プロダクトオーナーはプロダクトの今後の見込みや予測をしやすくなります。 予測がしやすければしやすいほど、ビジネス面での計画も立てやすくなります。
例え失敗しても一週間で済むので実験しやすい
計画の精度が高くなる、というのと多少相反しますが、万が一そのスプリントが何らかの理由でうまくいかなかったり、成果が少なかった場合でも、スプリントの期間が短ければ短いほど影響は少なくなります。 あるプロダクトバックログ項目でいろいろハマってしまい、想定の時間以上をかけても完成しなかった場合のことを考えてみましょう。 この場合、スプリント期間が長いと延々とハマってしまい、長いタイムボックスを使いきってしまうリスクもあります。 一方で、1週間スプリントの場合は、すぐにスプリントが終了します。 そして着手中だろうがあとすこしで終わりそうだろうが強制的に当該プロダクトバックログの作業は停止されます。 仕掛中のプロダクトバックログ項目については、次のスプリントで継続して取り組むのか、それとも先送りにするのか、もうやめるのかを判断する機会もあります。 そう考えると短いスプリントの方がリスクが少ないことが分かります。
また、同様の理由で、プロダクトオーナー側の観点としても、挑戦的なプロダクトバックログ項目をスプリントに投入しやすくなります。
ベロシティの数字がすぐ出るのでやる気になる
これは大した理由ではないのですが、スプリントが短いとベロシティの数値がすぐに見える化されます。 過去のベロシティとすぐに比較できるので、成長を実感したり停滞に気づいたりするのが簡単になります。
中だるみする余裕がない・リズムがよい
1週間スプリントでは、例えば以下のような週間スケジュールになります。
水曜日午後にスプリントプランニングを2時間のタイムボックスで実施し、完了後に夕方からスプリント開始
金曜日か月曜日くらいにプロダクトバックログリファインメントを実施して次のスプリントを準備
火曜日の夕方に翌日の準備をして、水曜日の午前中にスプリントレビューを1時間、スプリントレトロスペクティブを1〜2時間実施
毎週同じ曜日の同じ時間にイベントが行われることになるので、スケジュールを考えたり調整したりする必要がなく、リズムが出やすくなります。 イベントをオープンスペースでできないような場合でも、単純に毎週繰り返しで会議室予約をしておけばよいだけです。 何曜日の何時くらいにどういう状態だったら、マズイとか大丈夫そうだ、というのも分かりやすくなります。 スプリント期間が長くなると、スプリントプランニングのあとや翌日などはペースダウンしがちです。 またスプリントの後半に向けて追い上げ型にもなりがちです。 ところが、1週間の場合は後半も何も、そもそも時間が短いので追い上げが効かず、いつも同じペースで着実にこなしていくことになります。
一週間で収まるサイズのプロダクトバックログ項目にするので明確な完成を定義しやすい。従ってプロダクトオーナーの受け入れを取りやすい
スクラムでは、スプリント単位で、完成の定義と受け入れ基準にしたがってプロダクトバックログ項目を完成させなければいけません。 プロダクトバックログ項目が大きいので、複数スプリントにまたがって1つのプロダクトバックログ項目に着手しようとしてはいけないのです。 つまり、スプリント期間が短ければ短いほど、プロダクトバックログ項目のサイズは小さくなるのが普通です （1つのスプリントに投入するプロダクトバックログ項目が1つということはなく、大きくてもスプリント期間の半分以下で終わるようなサイズの項目を複数個投入するのが一般的です）。 時間が短くプロダクトバックログ項目が小さいということは必然的に中身が明確であることにつながります。
スプリントに投入したプロダクトバックログに関してスプリント開始後にたくさん不明点が出てくるような状況だと、そのプロダクトバックログ項目は完成しない確率が高くなります。 長いスプリント期間であれば、とはいえ、なんとか頑張って吸収するということができるかもしれませんが、それは本来やるべき事前準備不足を隠してしまうことにもなります。 一方で、1週間スプリントだと、もし不明点がでてその時すぐにプロダクトオーナーと会話ができないような待ちが発生するとどうにもならなくなります。 したがって、プロダクトバックログリファインメントで事前に次以降のスプリントに投入される可能性のあるプロダクトバックログ項目が本当にReadyなのかを精査するようにもなります。 そして1週間の半分くらいの規模のプロダクトバックログ項目であれば、「なにができれば完成なのか」の認識は比較的容易に合わせられるはずです。 認識があっていれば、プロダクトオーナーの受け入れ確認も容易になります。
スパイクが必要なプロダクトバックログ項目が明確になる
上の項目に関連して、スプリント期間が長いほど、あるプロダクトバックログ項目を実装するのにあたって、調査系のタスクも一緒に含めてしまいがちです。 完成とは何なのかは合意できていても、それをどうやるのかはスプリントに入ってから調査して進めていってしまうのです。 一方で、1週間スプリントのような短い期間では、特定のプロダクトバックログに関する調査をスプリントに入ってからやっていたのでは、プロダクトバックログ項目が完成しないリスクが高くなります。 つまり事前に調査まで終わらせておいて、開発チームが自信をもって作れる状態までもっていくような力が働きます。 プロダクトバックログリファインメントなどで、調査が必要なプロダクトバックログ項目を明らかにして、バッファを使って事前調査したり、場合によってはプロトタイプなどを作るプロダクトバックログ（タイムボックス上限を定める）を事前にこなすようになっていきます。 こうすることで、プロダクトバックログ項目がスプリント期間中に完成する確率が上がっていきます。
プロダクトオーナーが変更を我慢しやすい
プロダクトオーナーはステークホルダーと協働し、開発チームのパフォーマンスを踏まえて、プロダクトをどうしていくかシビアな判断が必要になります。 そして、ビジネスの状況は刻一刻と変化します。 長いスプリントになればなるほど、ステークホルダーからの要求やビジネスの状況との乖離の影響を受けて、プロダクトバックログ項目を入れ替えたいという欲求が強まります。 一方で、スプリント期間中のプロダクトバックログ項目の入れ替えは、プロダクトオーナーと開発チーム間の調整が必要です。 単に追加のプロダクトバックログ項目を依頼したり、着手中のプロダクトバックログ項目の受け入れ条件を変更したり、といったことは開発チームの合意なしではできません。 一方で、プロダクトオーナーとしては変更したい理由があるのに、それが受け入れられないのを我慢しなければいけないことにもなります。
ここでスプリント期間が短ければ、現状は受け入れた上で、次のスプリントで軌道修正をかければよいと割り切ることができます。 その割り切りによって開発チームは割り込みを受けること無く集中して作業を進められます。
なお、プロダクトオーナーにはスプリントをキャンセルする権限が認められているので、どうしてもという場合はスプリント期間に関わらずスプリントを途中中止して構いません。 ただし、いつもそれをやっているとプロダクトは何もできず、開発チームのモチベーションにも影響があるので、数か月に1度といった頻度までが限界です。 プロダクトオーナーとしての準備を怠ったが故のキャンセルは許されません。
ごまかしが効かない
ここまで見てきた内容全体によって、スプリント自体のごまかしが効きにくくなります。 事前準備をきちんと行い、ムダなく着実に進めていかないと、成果がでない状況になります。 つまり、長いスプリントではなんとか吸収しきれていた問題は、短いスプリントだと大きな問題として露見していくことになります。 長いスプリントによって隠れていた本当の問題が露見すれば、それを改善することで、より成果が出やすくなります。
1週間スプリントの弊害
1週間スプリントの利点ばかり説明してきましたが、いくつかの弊害や考慮ポイントがあります。 最後にそれを説明しておきます。
複数開発チームがある状況では、結合が間に合わない
それなりの規模の開発で、開発チームが複数ある場合、1週間のスプリントではそれぞれの開発チームの成果物の結合が間に合わない可能性があります（Nexusなどでも毎スプリントの結合が求められています）。 複数開発チームが存在する場合、コミュニケーションのオーバーヘッドがどうしても避けられず、またどこか一箇所の問題が全体に影響を与えやすくなります。 したがって、バッチサイズを多少大きくして確実に結合していく必要がでてくるかもしれません。
いつも追い立てられている気がする・ゆっくり考える時間がない気がする
1週間という短い期間に区切ると、どうしても残り日数や時間を意識する回数が増えます。 したがって人によっては、いつも追い立てられていると感じることもあります。 持続可能なペースで働くことが重要なので、その場合は、バッファの比率を見直すのも1つの手です。 また、プロダクトの状況次第では、祝祭日の絡む週のスプリントをときどきスキップする、という選択もできるかもしれません（あまりお勧めはしませんが）。 別の要因として、外部からプレッシャーがかかっていることもあります。 持続不能なペースで働くこと、決めたことを全て達成することを約束しているわけではないので、組織内で別のよくない力学が働いていないかどうかを確認し、それを改善していくとよいでしょう。
リスクを管理する
プロダクトの開発を始めた初期の段階では不確実なこと、わからないことだらけです。 それらを見ないふりをして先に進めると、途中で大きな問題になってしまうことがあるので、なんらかの形でリスクをバックログ化、見える化しておくと良いでしょう。 このバックログは、プロダクトオーナーとスクラムマスターが中心となって対処していきます。
報告
組織の活動の一環としてプロダクトを開発する以上、なんらかの報告やレポートが必要になることが普通ですが、組織によって必要な内容は異なります。 初期の段階で、どんな頻度で、どんな内容を、誰にレポートしないといけないのかを明らかにしておきましょう。
報告の内容は、全体像やリスクを把握できるようなものにとどめる（最初は最低限から始める）ようにしましょう。 プロダクトバーンダウンチャートのようなものでも十分なことも多々あります。 スプリントの活動を詳細にレポートするのは意味はありません。 あくまでもプロダクトの観点やプロダクトに関係するリスクの観点に留めるようにします。
開発チームの時間を報告作業に使うと勿体無いので、自動で作るか、スクラムマスターやプロダクトオーナーが作成するのも良いでしょう。 また、レポートに対するフィードバックやそれを受けてのアクションがないなら、レポート自体を廃止するようにして、無駄をなくすようにします。
メトリクスの間違った活用に気を付ける
報告のときにあわせて関心を持つのがメトリクスです。 前述のとおり、外部への報告はあくまで全体像やリスクを把握できるようなものにとどめるべきですが、スクラムチーム自身の改善のためにはメトリクスは有効です。 逆に、スクラムチーム外から監視や人事評価やプロジェクト評価のために、チームのためのデータを使うと、以下のようなことが発生するので避けるようにしましょう。
ベロシティの数値そのものの大小が評価される
スプリントプランニングで、見積りが上振れする（インフレを起こす）ことにつながります。 あくまでベロシティは、このペースでいくといつ終わるのか、もしくはスプリント数が限られている場合は上からどのくらいまでのプロダクトバックログ項目ができそうか、という予測のツールでしかない点に注意してください。
スプリントのタスクにおいて、残り時間だけでなく、見積もり時間と実時間の乖離が測定され評価される
バッファを積んだ安全な見積もりを行い、早くタスクが完了しても、予実の差を発生させないように、時間が来るまで完了にさせないようになります。 知りたいのはそのスプリントプランニングで選択したプロダクトバックログ項目を完成できるかどうかであって、かかった時間を追跡するのは無意味です。 今後同じ作業をする場合に参考になるから、という話を聞くこともよくありますが、スプリントの回数をこなせば見積もりの精度は徐々にあがるとともに、レトロスペクティブ等で改善活動も行えます。 かかった時間を測定する時間はムダではないのか？をよく考えてください。 もしかしたら使うかも！の作業は本当にやるべきでしょうか？
スプリントのタスクをこなした数で評価を行う
開発チームのメンバーが自分ができる簡単なタスクだけを取りたがり、他のメンバーを助けないようになります（助けてもインセンティブがないと感じてしまうからです。 本当は開発チーム全体の責任にも関わらず…）。
バグの発生件数の多寡で評価される
バグを隠すようになります。 プロダクトの評価は、そのプロダクトをマーケットに投入することで、どれくらいビジネス価値が生まれたのか、それは投資したコストに見合ったものなのかで評価されるべきであって、その評価抜きに開発チームを評価しても仕方ありません。
最終更新
役に立ちましたか？
