「自社の開発速度は他社と比較してどうなのか？早いの？遅いの？」という話をたまに聞きます。
比べたら負け、というのもよく聞く話。ですが、上位職の人や、経営陣から聞かれたとすると、「できません」「分かりません」とか「比べたら負けです」と言うのはそれはそれで難しい。
たとえ一度は言えたとしても、何度も言い続けるのは至難の技。
アジャイルな見積もりと計画作り に紹介されていたプランニングポーカーとベロシティを組み合わせれば
「ひょっとしたら比較できるかも？」と思い試したところ、（良いか悪いかは別の議論として）比較できたのでここに紹介。
プランニングポーカーは簡単に言うと、見積もり対象となるストーリー（or フィーチャー）を何人かで相対的に見積もりを出す、ということ。群衆の知識とでもいうべきか、皆んなでやれば意外と当たる、ということだと思う。
ベロシティは、ある特定のチームが固定された期間に完了させることのできる合計ポイントのこと。
詳細な説明は上述の書籍や他の方の説明に任せて、本題のやり方を説明します。
速度比較手順
前準備
- 比較したい他社の製品を選択。
- 他者製品のニュースリリースやリリースノートのようなものから、リリース日と機能を一覧にまとめる。（以降、機能一覧）
また、リリース日とリリース日の間を「他社の開発期間」と定義する。
つまり、比較したい他社製品の機能のうち、特定の期間にリリースされた機能を元に比較する前提で考える。
比較手順
- 機能一覧の項目一つずつをフィボナッチ数列（0,1,2,3,5,8,13,20,40,100）を使って、相対的にポイントで見積もる。
- 見積もりは複数人で実施する。
- 見積もりを行うメンバーに「自社製品に詳しくて、他者の比較対象製品のこともよく調べている」人が何人かいた方が心強い。
- 見積もる際に、あまり時間をかけすぎない方が良い。意見が割れたり迷う場合、もっともらしいことを言った人に賛同できるかどうかで決めれば良い。 どうしても合わない場合、平均値に近いポイントを取れば良い。
- 見積もった機能一覧から「工数で見積もる対象」をランダムに選定する。
- この時、大・中・小のポイントがほどよく混ざった状態で選んだ方が良い。見積もりやすいという理由で選ばない方が良い。
- もし40や100が含まれている場合、それは特大なので見積もり不可と判断して工数見積もりの対象外にすると良い。
- 「工数で見積もる対象」を実際に工数で見積もる。
- 設計、実装、テストなどを実施する想定し、「工数」（人月単位）で見積もる。
- 工数見積もりは、あくまでも「自社の開発チームが自社製品に組み込んだ場合」を想定して見積もる。
- ここでは前提条件などの認識を参加者でしっかりと合わせておく必要がある。認識が揃わないと、出した結果に納得感が持てない。
- 自社の開発チームが1ヶ月で「利用可能な開発時間」を算出する。
- 例えば、1チームが1ヶ月で開発に割ける時間は合計500時間（＝約3.1人月）みたいな感じ。
- 工数で見積もった機能から、上記の「利用可能な開発時間」に近くなるまで選択する。
- 上記例の場合、合計が3.1人月にできるだけ近くなるように選ぶ。(3.1人月は超えないようにする。)
- 上記で選んだ機能のポイント数を合計し、1ヶ月のベロシティと定義する。
- つまり、ここでの合計ポイントがチームで1ヶ月に消化できるポイント数ということになり、1ヶ月の開発速度を表すことができる。
- 機能一覧の全ポイントを合計し、上記のベロシティで割ることで、機能一覧の全機能を開発するのに何ヶ月かかるかが算出できる。
「他社の開発期間」の合計と比較すれば「早い」「遅い」が比較できる。
最後に
改めて伝えておくと、このやり方で出した見積もりやベロシティは正確ではないし、当たっているかどうかなんて誰にもわからない。
むしろ外れている可能性の方が圧倒的に高い。
重要なのは見積もる際の議論や、あまり時間をかけず、タイムボックスの概念を取り入れて答えを出すことなんじゃないかと思う。
あとは、出した答えが「なんとなく早いかも」「なんとなく遅いかも」という感覚や気分だけで答えるのではなく、ある一定の根拠で説明できるようになるので、この方法自体はそんなに悪くないと感じてる。
ここで出した数字を使うなら、どのように算出したかの方法も一緒に提示し、「当たっていない」ということを前提に、作業中に行う議論の内容も踏まえて客観的に自社の開発速度を考えてみることが良いと思う。間違っても、数字や答えだけが独り歩きしないように注意したい。