なぜ継続的なチーム開発では見積もりをポイントで出したいか
はじめに
システム開発を行うとき、見積もりの提示が求められることがあると思う。
そこで多くの場合求められるのは「時間」であるため、素直に時間単位で見積もりを行い 〇〇時間や××日として提示することが多いと思う。
今は、ストーリポイントなどの概念がよく知られている。
私は、継続的にチーム開発を行う際は、ポイントでの見積もりをするメリットがあると考えているので利用している。
一方で、なんでポイントで見積もりをやりたいかということが理解されていなくて、これまで何度か似たような説明をする機会があった。
そのような場合の説明のために文書にしておきたいと思った。
見積もりについては色々な側面から検討ができると思うが、ここでは「時間で見積もりを行うこと」と「ポイントで見積りを行うこと」という点にフォーカスして考え、それ以外の開発手法やポリシーをなどの要素はできるだけ除外して考えていこうと思う。
概要
ポイントの見積もりには、「継続的なチーム開発」において以下のような利点があると考えている。
- ポイントの見積もりは、開発対象を中心に議論がしやすい
- ポイントの見積もりは、属人化する可能性が比較的低い
- ポイントの見積もりは、改善活動の材料に利用しやすい
これ以降では、以下のような流れで説明していく。
- そもそも、なぜ見積もりを行うか
- 見積もりという行為はどのような流れで行われるか
- ポイントで見積もるとはどのような行為か
- ポイントで見積もる利点はなにか
なぜ見積もりをするか
システム開発を行うとき、システムを作ること自体は目的ではなく手段であることが多い。
目的の例としては、そのシステムを使って何か物を売りたいとか、人手で行っている作業を減らすとかがある。
そのため、システム開発に必要なコストを、そのシステムに期待される効果と比較したいというニーズがある。
コストが大きければ、実際に費用を投じる前に手段を変更することができるからだ。
あるいは、ある機能がいつ実装されるかということが知りたいかもしれない。
その理由は、その機能が実装されるまでの間に現在の運用についてどのような対応が必要かを検討したいのかもしれないし、その機能をすぐにユーザに使ってもらうためのプロモーションをいつ頃実施するべきかを検討したいのかもしれない。
このように、システム開発をしようと思ったときは様々な意思決定が伴う。
その意思決定には様々な情報が必要で、見積もり情報はその一部と言える。
だから私達は見積もりを求められる。
見積もりという行為の流れ
見積もりの情報は多くの場合、「期間」や「費用（金額）」という形で要求される。
結果、見積もる側は「時間」という形で提供をする事が多い。
「期間」が知りたければそのまま使えばよいし、我々の人件費という自明な情報を使えば「費用（金額）」が得られるからだ。
見積もりという行為のアウトプットが「時間」であるとして、見積もりという行為のインプットは何か？当然、「開発の対象」となる。
では、「開発の対象」が得られてから、「時間」を出力するために我々はどのような手順を踏むだろうか？
ここでは簡単にするために「開発の対象」を「目の前にあるいろんな形の積み木をすべて使って二つの塔に積み上げる」として話を進める。
以下のような順序で見積もりは行われると考える。
- 情報を収集する
- 作業規模を推定する
- 自身の経験に照らし合わせる
- 作業に必要な時間を見積もる
以降では、時間を見積もりに使うケースを想定して、それぞれのステップを分けて説明する。
情報を収集する
まずは、情報を集める。
例えば、以下のようなことをしてみるかもしれない。
- 積み上げる積み木の数を数えてみる
- 積み木を形ごとに数えてみる
- 積み木の重さを測る
- 積み木の硬さを測る
これらは対象について、直接的な情報を得ようとしている。
あるいは、間接的に関係する環境についての情報を集めるかもしれない。
以下のようなことが想像できる。
- 作業を行う部屋の床が水平か
- 作業を行う部屋に空調がついているか (風があるか)
とにかく、これから行う見積もり作業は情報が多ければ多くなるほど正確なものになると期待できるため、許される限り情報を集める。
これは積み木じゃなくてシステム開発に置き換えても簡単に想像できると思う。
すでに明らかな仕様やそのシステムの目的などを聞きたいと思うだろうし、そのシステムが稼働するプロットフォームが現時点で決まっているかどうかも知りたいと思うはずだ。
作業規模を推定する
集めた情報をもとに作業規模を推定する。
例えば、以下のようなことを考えたりする。
- 積み木の数は 50 個で、積み木の大きさは平均して 10cm だったから、おおよそ 250cm (= 2.5m) の塔を２つ建てることになる
- 積み木の形は9割が立方体で、残りの１割が直径 30cm の円柱であったから、一番下に円柱を置き辺が長い順に下から積み上げるようにすれば塔の安定性はそれなりに高そうだ
集めた情報をもとに対象を分析し、全体像を推定する。
必要に応じてそれを実現するために留意すべき点などを整理し、作業の規模やその難易度を整理していく。
システム開発においては、全体を一気に推定することは難しいだろうから、得られた情報をもとに対象を分割したりしながら推定することもあると思う。
その場合、以降の作業は分割したそれぞれに対して行われる。
自身の経験に照らし合わせる
推定した作業規模に対して自身の経験を照らし合わせる。
たまたま今回依頼があった、『積み木で塔を作り上げる』という仕事を以前に行っていたならラッキーだ。
その時の情報と、かかった時間の実績を踏まえればある程度予想がつくかもしれない。
そうでなければ、それ以外の自身の経験を想起する必要がある。
例えば、『この作業は、繊細な作業が必要そうだ。そういえば以前に 100 枚のドミノを並べた事があったが、あのときは 2時間位かかったな』など。
さらに、実はこの作業は２人のチームメンバーとともに行うということであれば、それらも考慮しないといけない。『Aさんはかなり器用だったはずだが、Bさんは逆に不器用だったな』など。
必要なら2人に自分の器用さについてのヒアリングをする必要があるかもしれない。
作業に必要な時間を見積もる
ここまでの情報を総合し、具体的な時間を見積もる。
得られた情報によってどのようにするかは変わってくると思う。
てんでなんの情報も無ければ、エイヤと時間を決めてしまうしかないかもしれないし、情報が豊富なら、なにかの理屈をつけて計算できるかもしれない。
ポイントで見積もるということ
ここではポイントで見積もるという行為自体について説明する。
ポイントで見積もり行うときは、見積もりの際に「時間」ではなく「相対的な規模」を用いる。
そして、その規模の大小をポイントという値で表現する。
規模の大小は相対的なものである必要があるため、基準作業と対応するポイントが必要となる。
これを何にするかは、見積もりを時間で行うか、ポイントで行うかという議論の外の条件に大きく左右されるので深くは言及しない。
以前に行ったシステム開発のある作業を基準として 3 ポイントと置くかもしれないし、見積もり対象の中の1つを 1 ポイントと置くかもしれない。
それ以外は、それほど時間で見積もるときと変わらない。
- 手持ちの情報をもとに、見積もり対象の作業規模を推定する。
- 基準作業の作業規模を考える。過去の作業が基準なら作業の全容を知っているし、これからやる作業なら内容は推定したものがある。
- 規模を比べてポイントを付ける。基準より規模が大きいと推定すれば、より大きいポイントが付くだろうし、半分程度だと思えば半分のポイントを付ける
これをすべての対象について行えば、システム開発に必要なポイントが合計何ポイントかがわかる。
料理を例にしよう。
例えば、以前『チャーハンを作る』という作業を 5 ポイントと見積もったとする。
そして、今回『オムライスを作る』という作業の見積もりを依頼されたとしよう。
材料などは違えど、米と材料を炒める作業はチャーハンもオムライスも大体同じそうだ。
これに加えて卵で包む作業があるだけだから 6 ポイントだろうと考えることができる。
一方で依頼者が求めているのは時間なので、このポイントを時間に変換してやる必要がある。
この変換方法も状況によって異なる。
例えば、基準作業が過去の作業によるものであったなら、その時かかった時間を使う。
3 ポイントの作業に 6h かかったとき、74 ポイントのシステム開発には 148h 程度は必要だと推定できる。
基準作業も見積もり対象なら、この基準作業にどれくらいの時間がかかりそうか考えることになる。
1 ポイントと見積もった作業に 1.5h かかりそうだと見積もったとき、63 ポイントのシステム開発は、94.5h 程度はかかるだろうと推定できる。
ポイントで見積もる利点
ここまでで、時間で見積もってもポイントで見積もってもそれほど大きな差はないんじゃないかと思う人も多いと思う。
私が話した人の多くもそのような印象をもっていて、そのためにいくらか追加の説明を要した経験がある。
ここで注目してほしいのは、ポイントでの見積もりは『作業の規模』に対してのみ注目するのに対して、時間での見積もりは『作業の規模』に加えて『作業者の特性』に対して注目する点だ。
この相違点がどのように働くかは、当然ながら開発が行われるコンテキストに強く依存する。
ここ以降は特に「継続的なチーム開発」を行うという前提を踏まえて見るようにしてほしい。
見積もった量の議論が比較的容易
裏を返せば時間で見積もると見積もった量の議論が難しいということになるので、そちら側から説明する。
難しさを生む理由は、『作業の規模』に加えて『作業者の特性』に対して注目することにある。
同じく料理の例を出そう。
Aさんは料理が得意で以前チャーハンを 15 分で作った。
Bさんは料理が苦手で以前チャーハンを 25 分で作った。
オムライスを作る見積もりを二人にお願いしたところ、Aさんは 20 分、Bさんは 40 分と見積もった。
ここで発生する問題の一つは、これらの数値をどのように解決するかだ。
A さんが作業すると決めつけて 20分 とするか？
B さんが作業する可能性を考慮して 40分 とするか？
それとも間をとって 30分 とするか？
この判断自体はそのときによって変わるだろうが、いずれを選択するにしても判断が難しい。
次に発生する問題は、見積もりによって算出した数値をより良くするための議論が展開しにくいことだ。
AさんとBさんの見積もりの違いには、お互いの特性の違いがかなり含まれていることは明らかだ。
そうすると、仮に Aさんが作業をするとしても 15分 になりうるとか、25分 はかかる可能性があるとかの議論がやりにくくなる。
なぜなら、Aさんが『自身の能力を見誤っているか否か』という点と、Aさんが『対象の規模を見誤っているか否か』という２つのポイントを合わせて考慮する必要があるからだ。
最後に、チーム開発ではこれが一番大きいと思っているが、見積もりが個人に紐付いてしまうという点が問題となる。
ここまでの話を踏まえればこれは自明だと思う。見積もりの結果に見積もり者の特性が大いに反映されている。
見積もり結果から逸脱しないように作業をしようと思えば、担当者を見積もり者個人にしようと考えるのが自然であると思う。
一方で、見積もり者が必要なタイミングにその作業ができない場合も考えられる。
そうなると、もともとの見積もりから実際の開発の進み方がかけ離れていくことが予想される。
また、この問題の影響で最も問題なのは、チームの中でその作業が見積もった人の「持ち物」かのような扱いになる恐れがあることだ。
こうなると担当作業以外は他人事になり、チームで協力する体制を作るのが難しくなる。
ポイントで見積もると、この懸念のいくつかが解決される。
まず、『作業の規模』のみに注目するため、個人の特性はそこに含まれない。
一方で、個人の特性により、対象を正しく分析できず異なるポイントになることは有り得る（これは時間見積もりでも同じだが）。
そうなった場合も、見積もり結果に対しての議論をすればいい。
対象に対して特化した知識を持った人が説明をすれば、他の人との知識の差を埋めることができるし、対象が専門でない人も別の視点から懸念点などを上げてくれるかもしれない。
大切なのは、(専門家の処理能力の高さではなく)『作業の規模』のみに注目することで、対象をより分析するような議論が行いやすいことだ 。
例えば、チャーハンを作るのが 5 ポイントに対して、オムライスを作ることの見積もりを依頼されたとする。
料理が得意な A さんは 6ポイントと見積もったのに対して、料理が苦手な B さんが 7 ポイントと見積もった。
料理が得意な A さんは、自身の料理経験をもとに、『こんなのチャーハンみたいなものに卵を乗せるだけだよ。6ポイントで十分』というかもしれない。
B さんは『完成イメージの卵はかなりのふわとろに見える。こんな卵が簡単に作れるとは思えない。6ポイントは過小だと思う』というかもしれない。
大事なのは、ここでの議論は『オムライス自体』や『オムライスを作る工程』に対して重きを置かれていることだ。
時間で見積もっていたら『私ならすぐ作れる』とか、『私はAさんの倍の時間がかかりそう』という議論が含まれてしまう可能性がある。
ただ、ポイントという量を算出する際に、時間を参考にするのは構わない。
直感的に、見積もり対象作業を自分がやったら 20 分くらいかかりそうだと考えた上で、
基準作業が 5 ポイントで、10 分くらいかかりそうだったという理由で、10 ポイントと見積もるのは問題ない。
別の人は、見積もり対象を 10 分かかりそうだと思って、基準作業に 5 分かかりそうだと思っても同様に 10 ポイントと見積もられるからだ。
これは、対象の作業規模が概ね 2 倍程度であるとチームで合意できたことになるので、これはこれで問題ない。
ただ、それを直接議論に持ち出してはいけない。この議論では、『見積もり対象に私が 20 分の時間を要するだろう』という主張はあまり意味がない。
『なぜ 20 分かかりそうか』を主張しないといけない。それには、基準作業と似ているところ、異なるところ、それらの特徴などを考えて言語化する必要がある。
個人の能力ではなく対象を中心とすることで、議論はフラットに行うことができる。
その結果、様々な視点を見積もりに取り入れやすくなるし、チーム全体でポイントの合意が取りやすくなる。
ポイントは改善の材料に使いやすい
ポイントの見積もりは『作業の規模』に対して行われるので、他の開発の情報と比較がしやすい。
タイムボックスを切って反復的な開発を行っているなら、以前の反復の結果と比較ができる。
そのようなやり方をやってなくても、以前の開発の規模と実績のデータは持っているはずだ。
以前の見積もりデータを用いて基準を決定し、ポイントを付けることで今回の開発が以前の開発に比べてどれくらいの規模がわかり、完了までの期間も推定できる。
そして、開発が完了したときにその推定とのズレを見ることで、改善結果の評価や課題発見の材料にできる。
一方で、時間で見積もる場合はチームや開発者が成長をした場合も見積もり結果の数字に織り込まれてしまう。
そのため、以前に二週間で完了した開発があり、新しいプロジェクトで二週間と見積もったとしても、以前の開発と同等の規模かどうかはわからないし、結果として三週間かかったとしても、以前のプロジェクトに比べて問題があったかなどの示唆は直接得ることが難しい。
推定値とのずれ方とそこから得られる示唆については、開発の進め方やポリシーなどに大きく依存するのでここでは言及しない。
ただ、アジャイルなど学習を重視するポリシーでは学習機会を増やすために短い期間の反復ので、そのような方法と相性が良いとは言えると思う。
継続したチーム開発では、チームのレベルアップのために様々な側面の改善活動を行いたいと考えるため、ポイントでの見積もりを行うメリットが大きいと考える。
終わりに
見積もりという行為の目的とその内容について整理した上で、ポイントで見積もりをするメリットについて、時間で見積もりをした場合と比べながら考えた。
何度か記載したとおり、見積もり方法はプロジェクトの進め方や、ポリシーとセットで考えることでその効果も変わってくる。
一方で、はじめから、ある開発方法のフレームワークの一部として捉えると、ポイントで見積もる行為自体の効能を意識しづらくなり、ポイントで見積もるという行為だけに意識が行きがちとなることがあるため、それ以外の条件を可能な限り仮定しないことにした。
その結果「ポイントで見積もる」ということ自体の特徴や目的が少しわかりやすくなったのではないかと期待している。
最後に余談だが、すべての例を料理にして書こうとはじめは思ったのだが、料理の工程には『中火で 5分炒める』など時間が固定された作業が結構ある。これがわかりやすいから基準作業にしてしまうと、ポイントで見積もっている風な時間見積もりになってしまうので例に使いたくなくなった。
システム開発では時間が固定であることが明らかな工程は少ないのでこのような疑問には当たらなかったが、もしかしたら料理はポイントで見積もる対象としては適していないのかもなーと書きながら思った。
物理的な物を作る工業的なものは料理のような要素が強いような気がするので、そこから輸入して構築されたソフトウェア開発のプロセスが実際のソフトウェア開発とのアンマッチを感じさせるシーンが多々あるのもそういうところなのだろうと改めて実感できた。
Discussion