スクラムでも見通しを立てたい

ということで、自分がよくやっているスクラムチームにおける見通しの立て方を雑にまとめておきます。

なんで見通し立てたいの？

開発の見通しが立たないと、何の見通しも立たないからです。

例えば、これからどんな機能を開発していけばプロダクトの価値を高めて成長させられるかを考えるとき、それらがどのくらい時間がかかりそうか、今の開発はいつ終わりそうかの情報がないと判断がつかないんですよね。 優先順位づけにはROI（Return On Investment）が大切とよくいわれますが、まさにそれです。

次のリリースがいつされるかによってステークホルダーの仕事が計画されます。 営業資料やスクリプトの更新をする人や、サポートサイトの準備をしている人もいるでしょうし、CSのメンバーの学習期間を設計したい人もいます。 プレスを計画するステークホルダーもいますよね。

また、目標と現在地がないと、良いのか悪いのか判断できないし、他者にも伝えられないですよね。 リリースの目標を置くことに嫌な印象を持つ人は多いと思いますが、それは目標が約束になってしまうからです。 そうではなく、目標は期待を明らかにしたものとして扱いましょう。 この期待はステークホルダーからの「このくらいにリリースしてほしい」「このくらいでリリースできるんじゃなかろうか」というものです。 それと同時に、自分たちが「このくらいでリリースしたい」「このくらいでリリースできるようになりたい」「このくらいにリリースできるように頑張りたい」というものでもあります。

さて、見通しを立てたくなってきたところで、見通しの立て方の話をしていきます。

見通しの立て方基本のキ

多くのスクラムチームは、以下のものを所有しています。

• 順番に並べられたプロダクトバックログ（PBL）
• 各プロダクトバックログアイテム（PBI）は相対見積もりでポイントが見積もられている
• スプリントごとに完了したPBIのポイントの合計をベロシティとして計測している（3スプリントの平均など）

ない場合はここからで！

さて、これらが揃っていれば見通しを立てるのは簡単です。

あるPBIが完了するまでの期間を見通したい場合、以下の式から算出できます。

例えば、PBI_Cが完了する見通しを立てようとします。 PBI_Cは5spで見積もっており、PBI_Cの前にはPBI_A（2sp）とPBI_B（3sp）が置いてあります。 ここで、spはstory pointの単位です。 ベロシティは4spです。 このとき、PBI_Cが完了する見通しは、以下のように求められます。

見通しが、立った！

現実は甘くないので工夫が必要

すべてのPBIのポイントなんてついてない

ですよね！ 今後戦略や状況が変わることもあるので、すべてのPBIを見積もり、変化があれば再見積もりはムダです。 しっかりリファインメントしているPBIは1スプリントまたは2スプリント先くらいまでですよね。 PBI_Zまでの見通しを立てたいけど、PBI_G以降はまだ見積もりしていない状況はよくあります。

こんなときは、「それまでのPBIの平均値を使う」をやってます。

先ほどの例、PBI_Aが2sp、PBI_Bが3sp、PBI_Cが5spなら、その平均は3.3です。 PBI_D以降の見積もり前のチケットも平均すると3.3sp程度であることを期待します。

PBI_Hが完了する見通しは、以下のように求められます。

PBI_D以降はリファインメントして見積もりが出たらその値で見通しを立て直せます。 その場合、平均値も変わりますので、都度見通しを把握して目標とのギャップを検査することが大切です。

すべてのPBIなんて出し切ってない

PBLは前の方はINVESTになっていますが、後ろに行くほどまだ大きいままだったり、PBIが作成されていないことがあります。 ある程度の規模のプロジェクト全体を見通したいときに、まずすべてのPBIを作成せよ、となればその後の変更可能性を考えるとムダで過剰ですよね。

そんなときは「エピック見積もり」をします。

エピックとは、複数のユーザーストーリーを束ねたものです。 逆に言えば、エピックをさらに細かく作業可能な大きさにしたものがユーザーストーリーとも言えます。 ここではユーザーストーリー≒PBIとして読み替えてください。

エピック見積もりとは、PBIでやっているのと同じように、エピック間で相対見積もりをすることだす。

プロジェクトはいくつかのエピックにわかることができます。 エピックもユーザーストーリーと同じように、誰にどのような価値を与えたいかでわかることができます。

例えば、Epic_Aを2ep、Epic_Bを3ep、Epic_Cを5epと見積もったとします。 ここで、epとはepic pointのことです。 Epic_Aが2スプリントで完了したとすると、エピックベロシティ（1スプリントあたりの完了ep）は、2ep / 2sprint = 1[ep/sprint]となります。 Epic_Cが完了するまでの残スプリントは以下のように求められます。

見通し立ちましたね。

ちなみにepはspに換算できます。 例えばEpic_AにカテゴライズされるPBIのspの合計が20だったとします。 Epic_Aは2epなので、1epは20/2=10sp程度であると期待できます。 この換算をするとEpic_B = 3ep = 30sp、Epic_C = 5ep = 50spと見なすことができ、通常のベロシティを用いて見通しを立てられます。

1epが何spかは、エピックの完了のたびに更新されます。 3epのEpic_Bが終わってみたら45spあったのならば、45/3=15sp/epです。 Epic_Aでは10sp/epだったので差分があります。 なので、平均をとって、12.5sp/epを期待します。 これにより、Epic_Cは12.5 × 5 = 62.5spを期待して見通しを立てられます。

やっぱり約束として独り歩きしそうだから共有したくない

このマインドセットをチーム外にも広げるのは、やはり難しいです。 しかし、自分たちの見通しを共有しないことは、信頼関係を強める結果は絶対に生みません。 なんとかしたいところ。

まずはやはりマインドセットの醸成です。 何度でも見通しであり、目標を達成するために全力を注ぐことにコミットしつつ、不確実性があることを伝えていきましょう。 見通しの情報がどこかに残るのであれば、近い場所に「現時点での見通しであり、常に変化していきます」と書いておきましょう。

とはいえ、根気と強い心が必要です。 僕も持ち合わせていないです。 なので僕は「適当なバッファ」を積んでいます。

バッファの積み方は、残spに傾斜をつけます。 例えば残spが20spでベロシティが5spのとき、そのまま計算をすれば$ceil(20/5)=4$スプリントが見通しです。 この20spに1.2の傾斜をつけると、ceil(24/5)=5スプリントとなります。 実際の見通しよりも長い見通しになりますが、それを初期から掲げます。 目標とのギャップがよりシビアにはなるのですが、こういう組織では約束未達が非難されるのだと思うので、むしろこのくらいの危機感を持って取り組んだほうがよい感覚すらあります。 そして、プロジェクト初期から難しいかもしれないという感覚をステークホルダーに持ってもらうことも有用です。 傾斜をかけているので、完了PBIが増えるほどバッファは小さくなっていきます。 見かけ上、見通しが目標にミートしてきているように見えます。 ちょっと詐欺みたいですが、大丈夫→無理となるよりも、無理→大丈夫となったほうがよい印象を与えられるときもありますよね。

スクラムじゃなくてカンバンなのだけど？

あるタイムボックスで動いていなくても、ここまでの見通しの立て方は機能します。

僕もカンバンに取り組むチームでこの見通しの立て方を実践していました。 その場合は、各日から過去21営業日の間に完了したチケットのspの合計を21で割った値を1日あたりに完了できるsp、つまりベロシティとしていました。 このベロシティを使えば、残spを何日（何営業日）で完成させられそうかが検査できます。

新しいチームなのでベロシティないです

最初はベロシティないですし、感覚的には1ヶ月くらいしないと見通しのために使える指標にはならない気がします。 不安定すぎて、見通しがころころ変わり、ステークホルダーからすると逆に不信感を得てしまうかもしれません。

それでも初期から見通しを示せと言われたらどうしましょう。 「KKD」に頼りましょう。

KKDは勘・経験・度胸の頭文字をとったものです。 特に最初のうちやエピック見積もりのような大きめのものを見積らなければならないときは、KKDで見積もりができるシニアエンジニア、リードエンジニアの力を借ります。 ここまで紹介した方法に比べると精度は低くなりますが、ある程度らしい情報を可視化できます。

見通しを立てたらどうするの？

ここまでで、どうにかこうにか見通しがたったはずです。 そして、目標も立てました。 次はどうしたらいいでしょうか？

見通しと目標のギャップから適応する

ここまででも話していますが、見通しと目標のギャップを検査して、適応します。 スコープを見直してもいいですし、ペアプロなどに取り組むとか。 人を増やすという選択肢も初期フェーズなら取れることもあります。

更新し続ける

見通しは日々刻々と変わっています。 更新し続けて、検査し続けて、適応し続けましょう。 少なくともイテレーションごとに更新するので、自動化したり少ない労力で続けたりできる工夫が必要です。

Conclusion

こんなこと考えてやってます！ 目標立てて、見通し立て続けて、検査して適応して、プロジェクトを成功に導こう！

あ、もちろん大切なのは、リリースした事実よりも、ユーザーが価値を感じたかどうかですよね！

雑記、失礼しました！