これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。

前提となるプロジェクト

　今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。

• 細かい仕様は決まっていないが、作るものの要件はある程度明確である
• アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど)
• 数ヶ月以上のプロジェクトである

短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。

プロジェクト初期にやっておきたいことは何か

　上記のようなプロジェクトの場合、とにかく最速出す必要がある（どんなプロジェクトでも開発速度の最大化は目指すと思うが締め切りが固定だと特にその傾向は強まる）。そのため、いかに全員が同じ目標に向かえるか、いかに全員が自律的に動けるか、いかに刻一刻と変わる状況でも全員の認識があっているか、いかにトラブルを即座に解消できるかにかかっている。

　また、このようなプロジェクトの場合、まだコントロールしやすいのは「スコープ」である。そのため、いかにやらないタスクを判断するかも重要である。

　これらを考慮して、次のことをプロジェクト初期にやったほうが良いと感じている。

• 全員とゴールイメージを共有し、何が終わればリリースが出来るかの認識を合わせる
• プロダクトバックログをスプリントで終わる単位に分解
• 全員で集まってタスクの見積もりをする
• ベロシティ測定とバーンアップチャートの作成
• タスクの追加/分割/やらない判断フローの作成
• 短いスパンの改善フローの用意

　ある程度教科書どおりのスクラムをするというリストにはなってしまったけど、それぞれのセクションで経験に基づいた工夫を書いたつもりだ。

全員とゴールイメージを共有し、何が終わればリリースが出来るかの認識を合わせる

　まず前提として、 全員のゴールイメージが一致していなければならない。そうでないと、同じ目標に向かって全員で協力することも出来ないし、メンバーが各々自律的に動いても効率的に目標に向かえない。そのため、全員とゴールイメージを共有し、何が終わればリリースが出来るかの認識を合わせることが非常に大切である。

　ゴールイメージを一致させるための手法は様々なものがあるのでどれを使っても良い。ただし最低でも、なぜ作るのか、いつまでに何を作るのかについては全員が把握している状態を目指す。これまでの経験からは、インセプションデッキはなぜ作るのか、誰が関係者かなどがパッと判断しやすいので使いやすいと思っている。

　「いつまでに何を作るか」について、Webサービスやアプリを作る時は以下のようなものがあると認識合わせがやりやすかった。

• 全画面の画面イメージ
  • やはり絵があると、圧倒的に全員の認識を一致させやすい
  • 絵があることが大事なので、手書きでもAdobe XDのようなツールでも何でも良い。ただし、プロジェクトが進行した時に仕様はどんどん変わるので、画面イメージを修正しやすいツールを使えるとベターである
• タスク管理ツールで管理された全ユーザーストーリーが入ったプロダクトバックログ
  • 全ユーザーストーリーがタスク管理ツールに入っていると、これを全て実装したら終わりということが見える化されるので、認識を一致させやすい
  • プロダクトオーナーが「その時点」で思いつく全ユーザーストーリーを洗い出しタスク管理ツールに登録しておく
  • タスク管理ツールは自分たちが使いやすいなら何でも良い

プロダクトバックログをスプリントで終わる単位に分解

　ここまでで現時点で思いつくユーザーストーリーが入ったプロダクトバックログが完成しているはずである。そこで次にプロダクトバックログに登録されたタスクを、ある程度1スプリントで終わる単位にしておくと良い。1スプリントで終わらない単位のまま進めてしまうと、ベロシティが参考にならないものになったり、今起こっている問題が巨大タスクに埋もれてぼやけてしまったりということが起こるためである。

　この段階での分解はある程度ざっくりで良い。また、この段階では全員ではなく、必要最低限の人だけ集めて分解するくらいで良いと思う。

　具体的な手順としては

• 分解に必要な人を集める
  • 最低限だとプロダクトオーナー、スクラムマスター、エンジニア1人、デザイナ1人くらい
• ユーザーストーリーを一つずつ見ながら、1スプリントで終わらなそうなら1つずつ分解していく
  • 分解単位はユーザーストーリー単位にこだわらず、タスク単位になっても良いだろう

全員で集まってタスクの見積もりをする

　現時点で網羅的なプロダクトバックログが出来たので、続いて全員で集まってそれぞれのタスクの見積もりをする。それぞれのタスクの見積もりの流れとしては、1タスク(1プロダクトバックログアイテム)ごとに以下のような流れが良い。

• 見積もりできるように、どうなったらタスクが完了かを明確にする。分からないことがあればみんなでどんどん質問しながら完了条件を詰めていく
• 全員で見積もりを出す。見積もりの単位は、ストーリーポイントでも理想日でも何でも良い
  • 参考:見積もりの基礎知識と「ストーリーポイント vs 理想日」の考察 - yigarashiのブログ
• 見積もった結果、1スプリントで終わらなそうな規模だということが分かったら、さらに分解しておく

　ここでポイントなのは、時間をかけてでも全員でやるということである。1~2日かけてでも行う価値があるパートだと思っている。なぜ全員で時間をかけてでもやると良いかというと

• 見積もり時にわからないことはみんなで質問していくことで、よりタスク内容が明確になる。プロダクトオーナーが見落としていたことを発見できたり、簡単だと思っていたことが実は難しいということが発見できたりする
• 全員で全タスクを一度でもいいから見ておくと、全員がより鮮明にゴールイメージを意識できるようになり、自律的に動きやすくなる

ベロシティ測定とバーンアップチャートの作成

　最終ゴールに対して、間に合いそうかを見える化し続けるには速度を測るしか無い。そして状況の図を作っておくことで、スケジュールに対する温度感を全員で一致させやすくなる。

　そこで、お手本通りスプリントごとのベロシティを測定し、毎スプリントごとにみんなで状況を即座に確認できるようにバーンアップチャートなどの図を作る。図に関してはバーンアップチャートでもバーンダウンチャートでも好きなものを使って良い。

　個人的にはバーンアップチャートの方が好みである。なぜなら、タスクの消化具合だけでなく新規タスクが増えている状況も可視化できるため、遅れている原因が新規タスクが増えているためなのか、速度に問題があるからなのかがひと目で切り分けられるからだ。

　ここまでで現時点でのタスク一覧とスプリントごとの速度を出せたので、間に合いそうかの温度感を全員で一致させやすくなった。

タスクの追加/分割/やらない判断フローの作成

　これまでで、「現時点」でやるべきタスク一覧は作れている。しかし、プロジェクトが進むにつれて新しくタスクを発見したり、タスクに取り組んでみると巨大タスクだったり、リリースまでに必須でなさそうな部分を見つけたり、スケジュールを考えるとやむなく落とす判断をしたり、といったことをしたい場合が必ず出てくる。

　そのため、タスクの追加/分割/やらない判断フローを先んじて作成しておくと良い。特に「やらないものを決める」フローをきちっと決めておくのが大事だと思っている。

　それぞれのフローの例は次のようなものが考えられるだろう。

• タスクの追加フロー: 新しいタスクを見つけた人がタスク管理ツールに登録する -> 数人で集まって見積もりしておく -> 次の日の朝会でリリースまでにやるかやらないかを判断する
• タスクの分割フロー:
  • 1スプリント内で終わらなそうな規模だと発見したら or リリースまでに必須ではない部分を発見したら分割する
  • 発見した人が分割し、タスク管理ツールに登録する -> 分割したタスクを数人で見積もりする -> 次の日の朝会で分割したそれぞれのタスクについて、リリースまでにやるかやらないかを判断する
• やらない判断フロー:
  • タスク追加/分割時は朝会でやるかやらないか判断する
  • タスク追加/分割時以外でリリース必須でなさそうなタスクを見つけたら、見つけた人が朝会で提案する。朝会に「やらないタスク提案コーナー」を作っておくと提案しやすくなる

　ちなみに「やらない判断が出来ず、結局やるものが増えてしまう」ということはプロジェクトあるあるなのだが、これまで紹介していることを実践しておけばやらない判断はしやすい状態になっている。なぜなら、

• ゴールイメージが揃っており、必須で残したいものは判断しやすくなっている
• バーンアップチャートで間に合うかどうかがひと目で分かる
• プロダクトバックログでリリースまでにやらなければならないものが全てリストアップされている

という3点が揃っているため、タスクを落とす必要性を全員で理解できる状態になっているからである。

　これで、速度はバーンアップチャートでひと目で分かるようになり、かつやらない判断フローも決まったので、スコープをよりコントロールしやすくなった。

短いスパンの改善フローの用意

　最後に改善フローを用意しておく。締切が厳しいプロジェクトの場合、出来る限り素早く問題発見・改善を回したいので、短いスパンで改善フローを用意しておくと良いだろう。また、問題のキャッチを素早く行えるように、問題に気づいた人が相談しやすい状況を維持することも大事である。

　これまでだと下のような工夫をしたことがある。

• スプリント会を短いスパン(1週間とか)で取り、KPT会を行う頻度を増やす
  • Good +KPT(GKPT)にすると書きやすくなり、Goodからチームに知見を溜めやすいということもあった
  • 参考:KPTにGを足して、スクラムで最強のチームを作る!! - 株式会社クラフトマンソフトウェア
• 朝会に相談コーナーを用意する
  • 気づいた時に即座にメモできるように、scrapboxやgoogle docsなど複数人で編集できる会場を用意しておき、朝会以外の時間でも書けるようにしておくとベター

まとめ

　今回は、自分が締切がかなり厳しいプロジェクトを経験して、その経験からこういう特性のプロジェクトの初期にまずこれだけはやったほうが良いということを紹介してみた。ある程度教科書的なスクラムにはなったと思うけど、それぞれのセクションで経験に基づいた工夫も書けたかなと思う。参考になると嬉しい。

参考

• KPTにGを足して、スクラムで最強のチームを作る!! - 株式会社クラフトマンソフトウェア
• 見積もりに関して
  • 見積もりの基礎知識と「ストーリーポイント vs 理想日」の考察 - yigarashiのブログ
  • なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;