スクラムを開発方法論に採用しているチームで開発者をしています。最近たまたま見積もりについての話題がチームであがり、私の経験や考えを整理してみる機会にしようと考えました。お断りとして、本稿の考え方が正しいと主張する意図はありません。世の中にはさまざまなチームや開発スタイルがあります。私が経験していない業務においては他のやり方もうまくいくケースがあると考えています。
スクラムガイド には見積もりの実践について明確な指針を提供していません。一方でスプリントを設定し、スプリントプランニングを行う上で通常はその期間内にスプリントゴールの達成を図ることから、必然的になんらかの見積もりを行うことを前提としています。インターネットを検索すると、プランニングポーカーとストーリーポイントを用いた見積もりの記事も多くみつかります。私の立場として、ストーリーポイントという見積もり手法をやや懐疑的にみています。この手法は一定の制約の中でしか機能しないのではないかと私は考えています。その理由や背景も後述します。
また、チームのスプリントにバーンダウンチャートが導入されました。バーンダウンチャートの運用についてスクラムマスターと議論していて、私の見解とは大きく異なることに気付きました。スクラムのルールとバーンダウンチャートの目的が合致せず、不思議に思ったのでそれについても後述します。バーンダウンチャートもスクラムには含まれません。
TL/DR (要約)
- (ストーリーポイントを用いない) 見積もりは担当者によって変わる
- 見積もりの精度は見積もり対象に対する情報量や知識量に依存する
- 見積もりはその見積もりを行った時点での予測に過ぎない
さらにまとめると言いたいことはこうです。
- 見積もりは外れるので常に補正していく
スクラムと見積もり
アジャイル開発とスクラム 第2版 で木下氏が書かれた「2020スクラムガイド改訂とスクラムの3つの罠」というコラムで、デイリースクラムの目的を次のように述べています。
デイリースクラムの目的は状況に合わせた再計画であるため、形式的な報告だけではいけない。
私自身、このコラムを読むまで勘違いしていました。デイリースクラムとは昨日やったことや今日やることの報告をするものだと考えていました。本当の目的は、なにか障害があったときにスプリントの計画を柔軟に再プランニングすることです。スクラムガイドにも「デイリースクラム」の節に次のように説明されています。
開発者が計画を調整できるのは、デイリースクラムのときだけではない。スプリントの残りの作業を適応または再計画することについて、より詳細な議論をするために、開発者は⼀⽇を通じて頻繁に話し合う。
スプリントゴールが変わるような再プランニングをデイリースクラムで議論するのは構わないと思いますが、ゴールに含まれないタスクやスプリントバックログアイテムの再プランニング (次スプリントへの先送り) は開発者が能動的に行えばよいのではないかと私は考えていました。しかし、スクラムマスターからは次のようなコメントをいただき、私の考えるスクラムの運用や見積もりとスクラムマスターのそれとは大きく乖離していることに気付きました。
- 基本的にはスプリントプランニングで立てた計画は変更しない
- スプリントの中止だけ唯一 PO に権限が与えられている
- スプリントの終了日にすべてやりきらなければならないということはない
- 検査／適用／透明性を実現できることが重要である
- バーンダウンチャートはスクラムには含まれない
スプリントとバーンダウンチャート
チームでは Backlog を用いて バーンダウンチャート を表示しています。
Backlog のヘルプセンターの概要には、バーンダウンチャートの意味や目的については説明していないので、バーンダウンチャートとは？意味やメリット、作り方のポイントを解説 の記事を読み解きながらバーンダウンチャートの目的や役割を次にまとめます。
バーンダウンチャートとは、マイルストーン (スプリント) の期間における、仕事量と時間の関係を表したものである。当初の計画と現時点の進捗状況がどのぐらい乖離しているかを視覚的に表現してくれる。グラフの傾きが進捗のスピードを表し、グラフが横ばいになると進捗が停滞していることを表す。バーンダウンチャートのメリットとして、計画と実際の進捗との乖離が明確になるのと、残された期間に対する仕事量の関係を視覚的に確認できることがあげられる。マイルストーンの完了後に当初の計画と実際の進捗との管理を振り返ることにも使える。
たしかにこの説明からも、スプリントにおいて完了できないタスクをそのまま置いておき、そのスプリントの振り返りの材料とする使い方はできるように読めます。またバーンダウンチャートの注意点として、次の2点があげられている。
- バーンダウンチャートは目安のひとつとして使う
- バーンダウンチャートでは表現できないメトリクスがあるので、これだけでプロジェクト管理はできない
- タスクをできるだけ正確に見積もれるようにする
- タスクの見積もりに正確さを欠いてしまうと、理想線・計画線と実績線が大きく乖離してしまう
- 「作業完了」の定義がメンバー間で異なると、仕事量の推定が不確かなものになり、適切なチャート運用を困難にしてしまう
バーンダウンチャートの適切な運用にはタスクの正確な見積もりが必要であると、この記事では説明されています。バーンダウンチャートを利用するのであれば、なるべく正確な見積もりとなるように努めるのは正しいでしょう。ここで、スプリントにおける、あるタスクの見積もりが外れたときに、そのタスクのマイルストーン (スプリント) を変更するかどうかでスクラムマスターと私では意見が分かれました。
スクラムマスターはタスクのマイルストーン (スプリント) はスプリント期間内では変更しないため、バーンダウンチャートはバーンダウンしなくてよいと主張します。一方で、私はバーンダウンチャートをみながら、マイルストーン (スプリント) に間に合いそうにないタスクはマイルストーン (スプリント) の変更を行い、スプリントが完了するときにはタスクがゼロになる、バーンダウンするのがよいのではないかと主張しました。
意見や考え方の相違そのものを私は気にしてはいません。しかし、スクラムマスターと私で見積もりに対する考え方が大きく異なることから、バーンダウンチャートの運用に食い違いが出ました。
本稿では、私の見積もりに対する考え方を説明した上でバーンダウンチャートの運用について述べます。
見積もりと不確実性コーン
そもそも正確な見積もりはとても難しいというのが私の経験則です。多くの人は共感してくれるのではないかと思います。大前提として、見積もりは誰がやっても外れる ものであり、一定のズレを織り込んだ上でプロジェクト管理を行うべきであると私は考えます。
私の経験では、見積もりと計画との乖離を過剰に責めるとメンバーが不正や誤魔化しを行い、結果的に品質が大幅に劣化して、後になってから (たいていは運用が始まってから) 大きな問題に発展することがありました。問題はわかった時点で対応する方がずっとコストが低くなります。品質管理の視点から見積もりのズレを誤魔化す必要は全くなく、そのズレを認識した時点で然るべき補正をしていくことが重要だと私は考えています。
見積もりの話題によく引用される図に 不確実性コーン があります。エンジニアリング組織論への招待 から引用します。
プロジェクトの進行とともに見積もりのバラツキがどのように推移していくかを表したものです。プロジェクトの初期は最大4倍程度のズレが発生する可能性があり、終了前ではほとんどズレないということを表しています。調べてみると、この図は1981年に発表されたものでウォーターフォール型開発の時代の話しだそうです。現代の開発で同様にみなしてよいか、検討の余地はあるかもしれません。一方で私の経験則においてもこの図のバラツキは一定の理があるように受け取れます。
私は次の要因によってこのズレが起きるのではないかと考えます。
- プロジェクトの初期は必要な情報が不足している
- プロジェクトの初期はメンバーのスキルが未熟である
- 情報もスキルもない状態では知識や知恵を得るのが難しい
そのため、プロジェクトが進むことで次のことが発生して見積もりのズレが補正されるのではないかと考えます。
- プロジェクトの初期と比べて、相対的に情報が増える
- メンバーが成長する (スキルや知識を身につける)
ストーリーポイントとプランニングポーカー
チームでも度々ストーリーポイントの話題が出るため、ストーリーポイントとプランニングポーカーという手法での見積もりについても考察します。
私はストーリーポイントもプランニングポーカーも実践したことはないため、この記事を読んだ程度の浅慮で書きます。そのため、本節の内容は誤っている可能性があり、参考程度に読んでください。
ストーリーポイントは、ストーリーポイントを実践できる状態のチームを先に作る必要があるのではないかと私は考えます。作業時間や工数をストーリーポイントに抽象化し、それをプランニングポーカーという手法で高い精度で見積もったとしても、そのストーリーポイントを誰でも同じぐらいの速度・品質でメンバーが対応できないと意味をなしません。というのは、どんな理屈を述べても最終的にストーリーポイントは作業時間や工数と対応付けられてしまうからです。現実の期限が10ストーリーポイント後になりますということはありません。
スクラムは属人性を排除して、メンバー全員がどんな作業でも同じぐらいの速度・品質でできることを目指すフレームワークであるというのは正しいと思います。しかし、現実の世界でその状態を維持するのはとても難しいのではないかと私は考えます。メンバーの知識やスキルセットには個人差があり、退職や移動などチームのメンバーは入れ替わります。そして、現実の業務にはドメイン知識や経験が必要とされ、その習得のために一定の学習コストを要します。1人でできる作業を複数のタスクに分割してメンバー全員が担当することによって属人化をなくすというのがスクラム的なやり方だというのは重々承知していますが、それを実践するには業務に対して過大なリソースを割り当てる必要があります。大雑把に言えば、1人でできるタスクを3つのタスクに分割して3人でやるような話しになるのではないでしょうか。大企業ではそういった働き方をしているかもしれません。
現実の世界では、特定の業務に対するドメイン知識やスキルは担当者個人に紐付いていることがよくあります。例えば、ある担当者 A が3年かけて身につけた知識やスキルを、3ヶ月ほどメンバー B や C に教えたからといって、B や C が A と同じことができるようにはならないことはあるでしょう。A, B, C でプランニングポーカーを行い、ストーリーポイントを見積もったとしても、A と B, C における実際の作業速度は大きく異なります。さらに本当は速度だけではなく、品質レベルも平準化しないといけません。しかし、品質は速度よりもさらに平準化が難しいです。
スクラム的な見積もり、ストーリーポイントとプランニングポーカーを実践するには、まずチームの知識やスキルセット、実践における品質レベルを先に平準化する必要があります。強いて言えば、過半数以上のメンバーの知識やスキルセットが高くない、深いドメイン知識を必要としない業務開発などに対してこの手法はうまくいくのではないかと思えます。私の知人からもそういう事例を聞いたこともあります。
ストーリーポイントのデメリット
【翻訳】ストーリーポイントを使うのをやめよう の記事では、ストーリーポイントの弊害についてまとめられています。2012年に書かれた記事でやや古く、いまの状況とあっていないこともあるかもしれません。この記事に出てくる成熟したチームで直感による見積もりを補正する程度でうまくいっている話しや著者の知人のベテランのアジャイル実践者のほぼ全員、何年もの間ストーリーポイントとベロシティ計算を利用していないと述べています。
これはストーリーポイントに限った話しではありませんが、測定される値に報酬が与えられるものはすべてが改ざんされるという キャンベルの法則 と呼ばれるものが、まさにこの記事で述べられている弊害のいくつかに当てはまるでしょう。さらにひどいことにストーリーポイントが誤解されてしまうと、その抽象化された概念の曖昧さゆえに誤解を正すために時間と労力を要するといったことも述べられています。
余談ですが、私の周りでストーリーポイントを実践していたり、その有用性を説く開発者はほとんどいません。
見積もりは担当者が決める
前節では、チームにおけるメンバーの知識やスキルセットが平準化されていない状態で、みんなで見積もることは役に立たないと私は述べました。本節では一旦、時間や工数といった従来のやり方で見積もるときの手法について考察します。
時間や工数を見積もる場合、見積もりは外れるという前提とともに、タスクの担当者が決めて補正していく やり方がもっともうまくいくのではないかと、私の経験則から考えています。X というタスクを、A は3日、B は5日で完了すると仮定します。前提として、X というタスクを A が担当するのか、B が担当するのかで見積もりは変わることを受け入れます。A が担当しても B が担当してもよいが、B が担当するときは3日ではなく、B の知識やスキルセットを考慮して5日という見積もりとします。
実際に B が X のタスクの作業をしていて5日では終わりそうにないことが、4日目にわかったとします。このとき、あと何日かかりそうかの再見積もりも他メンバーではなく、B が自分で見積もるようにします。見積もりが外れると同時に、B は再見積もりと一緒に振り返りの機会を得ます。認知心理学ではこのことを 活動中の振り返り (reflection in action) と呼んでいて、学習におけるメタ認知的活動の1つと分類しています。見積もりが外れたときの再見積もりには、それ自体を省察の機会とする狙いがあります。見積もりが外れることは構わないが、なぜ外れたかを振り返ることが重要であると私は考えます。
タスクの担当者に再見積もりを行わせる別の理由に、進捗中のタスクには情報の非対称性が生じやすいという背景があります。組織における情報の非対称性とは、マネージャーが知っていてメンバーが知らない情報が多いという状況を指すことが多いですが、現場の業務においてはその逆が生じます。B が担当者として作業しているタスクの状況を他メンバーがその実態を把握するのはとても難しいです。とくにソフトウェア開発はそうです。B が行った作業状況を最も理解しているのは B 自身であり、B が再見積もりする方が見積もりの精度が高くなる可能性が高いと言えます。
多くのケースで見積もりが外れるのは、想定していない状況や情報不足によることが多いです。そこで B は X というタスクを完了する上で必要な情報や気付きを得て学びにつながります。仮にその学びを他メンバーに共有したとしても、B の暗黙知を過不足なく他メンバーに共有することもまた難しいです。このような実務の1つ1つの作業がメンバーの知識やスキルセットの形成につながり、それをチームで平準化するためにやはり時間を要すると言えるでしょう。
見積もりは常に補正する
前節で見積もりは担当者が行うことを私は提案しました。さらに見積もりはプロジェクトやスプリントの開始時点で行うものと考えがちであるが、私はそのように考えていません。何度も申し上げているように 見積もりとは外れるもの という前提があるからです。
作業を進めていく過程でさまざまな情報を取得したり、たまたま担当者が体調が崩してパフォーマンスを落としたり、その時々の状況にあわせて担当者の状態が変化します。知識や情報量が増えることは見積もりを減らす方向に作用し、体調を崩すことは見積もりを増やす方向に作用します。担当者の状態が変化したときに再見積もりすることは、時間が経つと、より精度の高い見積もりになるという 不確実性コーン の理論とも合致します。
見積もりを自身の状態の変化にあわせて行うという考え方は、プロジェクトやスプリントの開始時点で見積もることとも矛盾しません。熟達者の見積もりの精度が高い理由は、見積もり対象のタスクの知識や情報を開始時点から他メンバーよりも多くもっているという点があげられます。
「エンジニアリング組織論への招待」の「プロフェッショナルの仕事」という節に次の図が紹介されています。
熟達者であっても未知のタスクをこなすときの初期の見積もりは外れることが多いはずです。しかし、熟達者は不確実性の高いものから取り掛かるため、作業の早い段階で全体像をみえるようにしてしまい、後半は品質の作り込みを行うだけなので未知のタスクであっても早い段階で精度の高い見積もりに補正してきます。一方で、経験が少ない人はわかる範囲から作業を進め、後半になってから不確実性の高いものに取り掛かるため、作業の後半になっても見積もりのズレ幅が大きくなってしまう場合があります。
ここでは不確実性が高いものとは、その対象に対する知識や情報が不足していると言い換えられます。タスクにおいて不確実性が高いものは何かを把握することにも一定の経験やスキルを要するのです。前節で、時間とともに見積もりの精度が上がる背景を、必要な情報の取得とスキルや知識の習得と考えました。もし作業の後半になって行った再見積もりのズレも大きい場合、不確実性の高い作業を認識できていなかったと考えられるのではないでしょうか。
見積もりは外れるという前提とバーンダウンチャート
スクラムマスターは、スプリントプランニングで決めたタスクの見積もりに対してどのぐらい完了できたかみるためにバーンダウンチャートを用い、バーンダウンしなくてもよいと主張しました。おそらくバーンダウンチャートがバーンダウンしなかったことはスクラムイベントのふりかえりで見返すだけという運用を想定しているのでしょう。この背景はプランニングでは正確に見積もることと決めたことができなかったという事実を重視していると言えるでしょう。
一方で私は 見積もりは外れる という前提から、スプリント中に日々バーンダウンチャートをみながら実際のタスクの進捗と見積もりとの差異を確認し、見積もりのズレから気付きを得てタスクの見積もりやタスクのマイルストーンを補正しながら、スプリントの完了までにバーンダウンチャートをバーンダウンさせる運用を想定しています。冒頭でも説明したようにデイリースクラムの目的は再プランニングにあります。スプリントプランニングで決めたことを重視せず、日々の進捗にあわせて変えていこうという実践を重視しています。
スクラムの目的である検査／適用／透明性を実現するために、チームにとってどちらがうまくいくかという議論のたたき台として本稿を書きました。
余談ですが、見積もりと関連して短過ぎるスプリントの弊害もあるように感じています。私が参加しているスクラムチームはスプリントを1週間にしていますが、メンバーの業務に対する習熟度が低いと適切なタスク分割ができず、タスクが1つのスプリントで完了せず、複数のスプリントにまたがって同じタスクに取り組んでいるということも常態化しています。これが常態化すると、スプリントでタスクをやり切るというタイムボックスの効果が薄れます。さらにプランニングは前スプリントに完了しなかったタスクが優先となってしまい、新たに追加できるタスクが少なくなることから、プランニングの意義が減ってしまうようにも感じています。
まとめ
個人的には、見積もりやタスクの完了にバーンダウンチャートが役に立つとはあまり考えていません。
本当の意味で、マイルストーン (スプリント) でタスクが完了しないことを、そのタスクの担当者はある時点から気付いています。こういった見える化したいという意図は、プロジェクト管理をする立場の人から、タスクの進捗が担当者との情報の非対称性によって分からないから見える化したいというモチベーションに基づいていると私はみています。そして、バーンダウンチャートをみて、そのスプリントにて、プランニングで決めたタスクが完了しそうにないとわかったら、プロジェクト管理の立場の人がタスクのマイルストーンを変えていくのがよいのではないかと私は考えています。スクラムで言えば PO でしょうか？
一般論として、タスクの担当者は、タスクが完了しないことを認めたくない傾向があります。タスクが完了しないことは見積もりや実務能力の未熟さを露呈するものなので、自身が無能だと思われたくないという心理が働きます。これは容易に品質を犠牲にしてもタスクを完了させたいというインセンティブに変わります。とくにまだ十分に時間がある中で間に合わないという判断を下すのは担当者にとってはある種の屈辱感もあります。
したがって、私はマネージャーの立場と責任においてタスクの先送りをするのがよいと考えています。タスクが遅延したのは、担当者が無能だからではなく、マネージャーが無理なスケジュールにタスクを割り当てたという体裁にしてしまうのです。しかし、スクラムにはマネージャーに相当する役割がいないので、担当者以外にタスクが間に合わないという判断を誰が下すのでしょうか。スクラム的にはチームで話し合って決めるというのが教科書に書いてあると思います。しかし、私はそれでもチームって誰ですか？と聞いてしまいたくなります。
