【アジャイルFAQ 第9回】ストーリーポイントの人日換算を上司に求められます

 この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。
 第6〜8回はスクラムのイベントの話でした。今回から、見積りと予測の話に入ります。イベントの回と同じく、「本音の疑問→アンチパターン→勘違いの根っこ→処方」の順で読み解いていきます。

 ストーリーポイントで見積りをしていますが、上司から「で、それは何人日なの？」と毎回聞かれます。答えに窮して、結局「1ポイント＝0.5人日」のような対応表を作ってしまいました。これでは相対見積りの意味がない気がしますし、どうせ換算するなら最初から人日で出せばいいのでは、と思ったりもします。
 どう答えるのが正解だったのでしょうか？

 表現の違いこそあれ、ご質問のテーマ（ポイントと人日）は、ほんとによく訊かれます。3つの観点でこの質問を考えてみましょう。

• 上司が必要としているのは、本当に「人日」なのか
• 換算表を作ったのは、そんなに悪いことだったのか
• 人日で答えないなら、いったい何で答えればいいのか

 上から順に答えます。

• 上司が本当に必要としているのは、たいてい人日ではなく、「いつ終わるの？（あるいは、間に合うの？）」「いくらかかるの？」です。人日はそれらを導き出す手段として訊かれているにすぎません。
• 換算表を作ったこと自体は責められません（だって訊かれているんですから）。ただし、「1ポイントは〇〇に相当」と固定した瞬間に、いくつかの歯車が——後に述べるように——逆回転を始めます。「最初から人日で」という気持ちはもっともで、見積りの場で全員が人日に直しているなら、そのほうが正直です。ただ、そうなった原因はポイントではなく、換算表のほうにあります。
• 答えるべきは、ポイントの換算値よりも、リリース予測とコストの見通しです。実績のベロシティと残りのバックログから「◯月上旬〜◯月下旬に完了見込み」と幅つきで答えられれば、社内の上司のニーズはたいてい満たされます（ただし、発注側の稟議に人日が要る場合は別ですが、それは処方で扱います）。

 質問の字面を追わず、その質問の裏にある「相手がほんとに知りたいこと」に答える——これに尽きます。話の軸は二つ、「上司の質問を翻訳すること」と「外側に出す数字と、内側の計画の道具を分けること」です。

 研修や現場で、「ストーリーポイントは相対値です」「人日に換算してはいけません」と指導されたことのある方は多いと思います。そのとき、こんな疑問を持ちませんでしたか？

• 予算も稟議も人日で回っている。換算しなければ、話が通らないではないか
• 結局、見積りの場で全員が頭の中で人日に直している。だったら最初から人日でよいのでは
• 相対値のままで、上司は何を判断できるのか

 どれも正当な疑問です。先に答えを書くと、鍵は「1ポイント＝◯人日」から導出される数値とベロシティは、似て非なる数字だという一点にあります。換算値は「この項目は3人日」と、項目の原価を語る数字です。ベロシティは「このチームは1スプリントに25ポイント片づく」と、チームの流量を語る数字です。計画に要るのは後者で、前者を計画の場に持ち込むと、項目ごとの帳尻合わせが始まります。

 予算や稟議が人日で回っているなら、人日につなぐ必要はあります。ただし、つなぐのは項目ではなく合計です。残りの合計ポイントをベロシティで割って期間を出し、期間にチームの月額を掛けて金額を出す。このやり方なら、個々の項目に人日を貼らずに済みます。
 上司が判断したいのは、相対値そのものではなく「いつ終わるか」「いくらかかるか」です。上司に渡すべきは、ポイントという材料ではなく、そこから導いた見通しのほうです。

 とはいえ、これだけでは言葉足らずでしょう。先に換算要求がどんな姿になりがちかを並べ、そのうえで一つずつ答えます。

 換算を巡っては、いくつかのアンチパターンがあります。心当たりのあるものがあれば、そこから読んでください。

その１：対応表型——最も多い型です。「1ポイント＝0.5人日」のような固定の対応表を作り、ポイントを掛け算して人日に直して報告する。冒頭の質問が、まさにこれです。作った直後は平和ですが、見積りの場で全員が人日に逆算を始め、「これはあれの2倍くらい」という比較の速さが失われていきます。

その２：成績表型——ポイントが「あの人は今月何ポイント消化した」という個人の生産性指標や、「Aチームは毎スプリント30ポイント、Bチームは15ポイント。Bは生産性が半分か」というチーム間の比較に転用された型です。見積りは自己防衛の道具になり、大きめに見積もる誘惑、簡単な項目を選ぶ誘惑が生まれ、数字は膨らみ、予測の道具としては死にます。測定基準が目標になると、それは良い測定基準ではなくなる——経済学者チャールズ・グッドハートの名にちなむ「グッドハートの法則」として知られる現象です。そもそもポイントはチーム内の相対値であり、チームAの5とチームBの5には何の互換性もありません。換算表は、その事実を覆い隠します。

その３：値切り型——発注側や管理部門が、人日に直した数字を見て「この画面が3人日？ 前は2人日でできたでしょう」と個々の項目を値切りにかかる型です。ポイントの内訳が人日の内訳に化けた瞬間、見積りは予測ではなく交渉の材料になります。第3回で見た、見積の内訳が保証の文言に流れ込む構図と同じです。

その４：沈黙型——「換算しない」という教えを守り、上司の質問に「ポイントは相対値なので人日には直せません」とだけ答えて、会話が終わる型です。正しいことを言っていますが、上司が本当に知りたかった「いつ・いくら」には何も答えていません。教えを守ったつもりで、翻訳を放棄しています。

 四つの型に共通する前提があります。ポイントは工数の別名だという前提です。この前提に立つと、換算表を作るのは当然であり、個人やチームの比較に使えるはずであり、内訳を値切れるはずであり、逆に「換算できないなら何の役にも立たない」という結論まで、すべて自然に導かれます。どの型も、この前提を疑わなかった先に現れます。

 ここまでを踏まえて、先ほどの疑問に一つずつ答えます。

 まず、換算しなければ話が通らないのではないか。その通りです。組織の予算策定や稟議、外部への報告は人日・人月で回っており、その言語に接続しないと話は通りません。これは現実で、否定しても始まりません。しかも、ポイントから人日への換算は数学的に可能です。スプリントで使った人日を、そのスプリントで完成したポイントで割れば、「1ポイント＝◯人日」は単純な算数で出ます。多くの現場の換算表は、実際にこうして実績から作られています。出どころは正しい。
 それでも、換算値とベロシティは同じものではありません。違いは、数字が何を主張しているかにあります。ベロシティは「このチームは1スプリントに◯ポイント片づく」という、チームというシステムの流量です。会議も割り込みも待ち時間も含んだ、事後の観測値であり、その期間内に開発した個々の項目については何も主張しません。合計についてだけ語ります。換算値はそのベロシティを一つの定数として固定し、チームの人数とスプリント長を加味して、「この項目は3人日」と項目に関連付けた属性値に変えたものです。つまり、項目の原価を語る数字に変わっています。同じ実績から出ていても、片方はチームの流量、片方は項目の原価。ここが分かれ目です。
 項目の原価になった瞬間、項目ごとに値切る、3人日の項目に5日かかった人を責める、項目単位で再見積りを求める、が「正当な使い方」になります。見積もる側はそれを見越してポイントを膨らませ、ポイントは成績指標に変わる。先ほどの四つの型は、どれもここから生まれています。流量のままなら、これらは最初から成り立ちません。
 では、これから作るものの見通しは、どうやって人日・人月の言語に接続するのか。項目に掛けるのではなく、合計で割ります。残りのバックログの合計ポイントを実績のベロシティで割れば、残りのスプリント数が出ます。それが「いつ終わるか」です。そのスプリント数にチームの月額を掛ければ、「いくらかかるか」が出ます。ベロシティは動く観測値なので、幅（20〜30）のまま扱え、予測も幅になり、ずれは「予測の更新」として次の計画に戻ってきます。もし換算値を見積りの段階で項目に掛けると、計画はその時点で確定し、同じずれが「遅れ」として現れます。
 人日・人月の言語と合計値とを接続する形なら、チーム内の見積りはポイントを使うというスタイルを守れたまま、チームの外の人々が期待する見通しを実績値に基づいて提示することができます。実績そのものを問われたときは、もっと単純で、「このチームは、この3ヶ月で人件費◯円を使い、◯◯を届けた」と、項目ごとの換算を経ずに言えます。

 もっとも、正直なところ、換算値を毎スプリント毎に見直しをかけ、項目単位に見るのをやめ合計にしか使わないなら、項目に掛けても合計で割っても出てくる数字は同じです。違いは計算結果ではなく、数字の意味と、それが招く運用にあります。この話は、ベロシティを扱う回の末尾で、もう少し丁寧に扱います。

 次に、頭の中で人日に直しているなら、最初から人日でよいのではないか。その状態なら、確かにそうです。相対見積りの利点は、「これはあれの2倍くらい」という比較が、絶対値の見積りより速く、チームの合意として出せることにあります。見積りの場で全員が人日に逆算しているなら、その利点はもう失われていて、時間で見積もるほうが正直です。ただしそれは、ポイントが無意味だからではなく、対応表がポイントを人日の別名に変えてしまったからです。対応表をやめれば、比較の速さは戻ります。

 そして、相対値のままで、上司は何を判断できるのか。相対値そのものは判断に使えません。上司が判断に使うのは、相対値とベロシティの実績から導いた「いつ終わるか」「いくらかかるか」です。ポイントは上司に見せる数字ではなく、その見通しを作るための、チーム内部の材料です。上司に渡すべきは材料ではなく、見通しのほうです。

 「工数の別名」という前提はどこから来るのか。私たちの多くは、見積りとは工数を積み上げるものだと教わってきました。機能ごとに人日を見積もり、合計して期間と金額を出す。この文化の中でストーリーポイントに出会うと、それを「人日の新しい単位」として理解するのは自然な反応です。怠慢の話ではありません。ただ、単位の置き換えではなく、道具の置き換えだということが、研修ではなかなか伝わりません。

 翻って、ストーリーポイントとは何か。道具である前に、何を測った数かを言っておきます。ポイントは、作るものの大きさ——量と複雑さと不確実性を合わせたもの——を、そのチームの目盛りで表した相対値です。工数が「人が投入する時間」という投入側の量であるのに対し、大きさは作る対象の側の量です。ただし、大きさそのものに絶対値はないので、「これはあれの2倍くらい」という比で表します。比が使えるのは、同じ二つの項目にかかる工数は作る人によって変わっても（Aさんなら1日と2日、Bさんなら3日と6日）、2倍という比は変わりにくいからです。だから比だけを持つ。そして目盛りはチーム固有なので、チームの外に持ち出すと意味を失います。

 そのうえで、本来のストーリーポイントは何のための道具か。アジャイルの計画づくりは、経験主義の上に立っています。見積りを事前に確定させるのではなく、実績を透明にし、予測と実績のずれを検査し、計画を適応させる。ストーリーポイントは、この「実績から予測する」ための道具です。
 見積り——ポイントは、項目同士の大きさの比較を、速くチームの合意として出すためのもの。絶対値ではないので、個人の作業のスピードや日々の割り込みに左右されにくく、合意が壊れにくい。
 実績——スプリントごとに完成したポイントの合計（ベロシティ）が、チームの実績。これが、ポイントを期間に換える唯一の根拠です。
 予測——残りのポイントを実績のベロシティで割れば、残りのスプリント数が出る。実績にはばらつきがあるので、予測は幅になります。幅は、実績が貯まるほど頼れるようになり、ばらつきの原因を減らすほど狭まります（ばらつきの扱いは、ベロシティを扱う回で）。

 ここまで来れば、対応表型の問題点は明らかです。「1ポイント＝0.5人日」が問題なのは、根拠がないからではなく、チームの流量だった実績を項目の原価に変え、しかも根拠だった実績が変わっても表が変わらないからです。変えるべきは、「項目ごとにポイントを人日に直す」から「合計ポイントと実績のベロシティで見通しを出し、チームの外の言語にはその見通しで接続する」へ、です。この置き換えが、本稿の処方のすべての前提です。

 ここからは具体策ですが、どれも道具にすぎません。見積りと予測の技法は有識者がさまざまに提案してくれていて、どれを選んでもかまいません。もっとも、「換算表を捨てた」と宣言しただけなら、沈黙型と変わりません。試したあとは、上司との会話が「何人日？」から「いつ？　いくら？」に変わったかで、効いたかどうかを見てください。

まず、直近数スプリントのベロシティと、残りのポイントを並べる
 直す前に、いまの状態を一枚にします。直近5〜8スプリントのベロシティ（最悪値と最良値）と、残りのバックログの合計ポイントを一枚に並べてください。実績が3スプリント分もあれば、粗くても幅は出せます（頼れる幅になるには5スプリントほど要りますが、その話は次回に）。この一枚があるだけで、「何人日？」への答えは「換算できません」ではなく「今の実績だと、◯〜◯スプリントです」に変わります。以降の処方は、この一枚から始まります。

「いつ終わるか」にはリリース予測で答える
 直近数スプリントのベロシティの幅と、残りのバックログの合計ポイントから、完了時期を幅で示します。「残220ポイント、ベロシティは20〜30なので、8〜11スプリント、つまり◯月〜◯月です」。単一の日付ではなく幅で答えるのがポイントです。上司が金額で聞くなら、幅をそのまま金額に変えます。「最良と最悪の差は3スプリント、つまりチーム月額の1.5ヶ月分が今の見通しの振れ幅です」。この幅を最良値・最悪値の2本の線でバーンダウンチャート上に表現する「レンジドバーンダウン」（PMI Disciplined Agileで紹介されている、幅つきのバーンダウン表現）というプラクティスもあります。幅の広さ自体が不確実性の正直な表現であり、スプリントを重ねるほど幅は狭まっていきます。この「予測が徐々に精緻になる」体験を上司と共有できると、対話の質が変わります。
 そしてこの転換は、答える側だけでは完結しません。開発者は幅と根拠を毎回同じ形式で示し、尋ねる上司の側は「何人日？」の代わりに「いつ？　いくら？」で問い直してみる。双方がこの形に慣れたとき、換算表は要らなくなります。

「いくらかかるか」にはチームの運営費で答える
 アジャイルなチームのコストは、タスクの積み上げではなく「このチームを何ヶ月走らせるか」で決まります。更改案件のように成果物のまとまりで予算を組む場面の「器」は、第4・5回の方式（ユースケースの本数×規模に深さの初期設定を重ねて量を出し、実測で期間と金額に換える）で作れます。一方、継続的に走るチームの費用の考え方は単純です。チームの月額（人件費＋経費）×期間。この計算に人日換算は不要です。むしろ「固定されたチームが期間内に価値を最大化する」というアジャイルの資金モデルを説明する好機です。

それでも換算が要るなら、用途を限定する
 稟議や契約でどうしても人日が必要な場面はあります。その場合は、過去の実績（このチームは四半期で人件費◯円を使い、◯◯を届けた）から算出した概算値を、チームの外に出す用途に限って用意し、チーム内の見積り・計画には持ち込まない、と線を引いてください。実績から出した換算値そのものは、この用途に限り、実績が更新されるたびに引き直すなら、問題ありません。「外向けの通貨」と「内側の計画の道具」の分離です。第3回で「予算の器」と「保証の範囲」を切り離す話をしましたが、これも同じ構図です。原則はひとつです。チームの外に出す換算値は実績から、チームの中の計画は予測で。どちらも同じ記録から導き、算出根拠を文書に残す。こうしておけば、外に出す数字と中で使う数字の出どころが違うのではないか、という疑いは生じません。この線引きを上司と合意できるかが勝負どころで、換算表の副作用（インフレ、ノルマ化、チーム間比較）を先に説明しておくと通りやすくなります。

発展: ポイントをやめる道もある
 PBIを十分小さく均一に分割できるようになると、ポイントを振らずに「個数」で予測する方法（スループットベースの予測）が成立します。見積りの議論時間はほぼゼロになり、「何人日？」への答えは「毎スプリント平均◯個完成しています」に変わります。成熟したチームの選択肢として、頭の片隅に置いてください。

 ストーリーポイントは「チーム内部の計画の道具」として生まれましたが、組織の会計・稟議・契約は今も人日/人月の言語で動いています。この2つの言語の境界に立って通訳をする人——本来はPOやマネージャーの仕事です——が明示的に任命されないため、境界の摩擦は毎回、見積もった開発者本人に降ってきます。そして開発者は善意で換算表を作り、数年後に同じ副作用に悩む。この繰り返しです。
 背景には、続くコスト削減のプレッシャーもあります。経営層にとってアジャイルが「早くて安い」という文脈で期待されているほど、「で、いくら安くなったのか」を人日で確かめたくなる。換算要求は、その期待の裏返しでもあります。だからこそ、幅つきの完了予測とチーム運営費という「別の答え方」で、期待の中身そのものを組み替えていく価値があるのです。

 換算表を求められたら、それは翻訳者が不在だというサインです。表を作る前に、翻訳の仕事を誰が引き受けるかを話し合ってください。確かめるべきは、上司との会話が「何人日？」から「いつ？　いくら？」に変わったかどうか、ということです。それがこのチームの見積りが予測の道具として働いているかの計器です。

次回: 「ベロシティが安定しません。計画に使っていいの？」