コンサルティング事業 2021.01.15

工数見積りの”ぶれ幅”を理解する試み

楽観的か悲観的か。理想時間か現実時間か。工数見積りがもつ"ぶれ幅"への理解を深めて、チームの見積り精度を上げようという試みです。

こんにちは。コンサルティング事業部の米丸です。

工数見積りって難しくないですか?

※ここでの工数見積もりは、WEB開発プロジェクトにおいて、スケジュール計画やコスト算出のもととなる、作業ボリュームの予想のことを指します。

経験のあるエンジニアやマネージャーでも、工数見積りを出すこと自体や、出された見積りに対してどうバッファを入れてスケジュールに落とし込むかに、悩まれている方は少なくないのではないでしょうか。

工数見積りには、以下の2つのぶれ幅が存在します。

 ①楽観的な見積りと悲観的な見積りとのぶれ幅
 ②理想時間と現実時間とのぶれ幅

工数見積もりが難しい理由はいくつかありますが、特にこのぶれ幅への理解が浅いために、見積もりを出す側と受け取る側とで、コミュニケーションのずれが生まれ、見積もりの精度を下げていることが多いと感じています。逆に言えば、このぶれ幅に対してのルールをチーム内で取り決めることで、見積もりの精度を上げられることができるはずです

見積もりのぶれ幅への理解を深めることで、チームでの見積り精度アップを試みてみます。

①楽観的な見積りと悲観的な見積りとのぶれ幅

ソフトウェア開発にかかる開発期間のばらつきは、以下のような形のベータ分布に従うといわれています。

うまくいけば左端の短い期間(楽観値)で開発が終わるが、問題が起きれば右端の期間(悲観値)まで開発は長引いてしまう、という開発期間の幅を表しています。

このグラフをもとにまずお伝えしたいことは、不確実性の高いプロジェクトにおいて、この幅は必ず存在するため、事前に正確な工数を言い当てることは不可能だということです。正確な見積りを出さないといけないというプレッシャーから解放されてください笑

そして、チーム内でこの見積もりの幅の共通認識を持たずにいることで、エンジニアが出した悲観値基準の見積もりを、マネージャーが最頻値相当の見積もりと受け取ってスケジュールを引いてしまう、というようなコミュニケーションに起因するロスが起きていないでしょうか。その見積もりがどこを基準としているかをすり合わせるだけでも、大きな事故が防げるかと思います。

もう少し詳しく見ていきます。
このベータ分布のうち、楽観値は開発が問題なくスムーズに進んだ場合の工期、悲観値は想定外の問題が起きた場合の工期、最頻値は最も確率が高い現実的な工期を指します。左右非対称になっているのは、どんなに努力しても開発期間の短縮には限界がある一方で、開発を遅らせる問題には制限がない(例えば担当エンジニアが体調を崩す、とか)ためと言われています。

面白いのは、左右非対称であるため、最頻値の見積もり以内で開発できる可能性は50%に満たないということです。その見積り内に収まる確率が50%となるライン(50%ライン)は、最頻値よりも少し右側にあります

そのため、最も妥当そうな最頻値の見積もりを基準にスケジュールを引いてしまうと、2回に1回”以上”の確率でスケジュールを超えてしまうことになります。規模の小さい(参加者の少ない)開発では、最頻値でも問題ないといわれていますが、規模の大きいプロジェクトでは、より不確実性が大きくなるため、最頻値ではなく50%ラインを基準にするのが良いとされています。参考に、三点見積り法とよばれる、50%ラインを算出する計算式を紹介しておきます。

三点見積り法による50%ラインの算出式

50%ラインの見積もり(期待値)=(楽観値+(最頻値×4)+悲観値)/6

ただ、毎回上記の計算をして期待値を出すのは、少し骨が折れます。大事なのは、チーム内でどこを基準として見積りすべきかをルール化し、コミュニケーションロスを防ぐことだと思います。

弊チームでは、見積りしやすい最頻値を基準として見積り、一定の係数をかけてスケジュールを引く、といったことを行っています。

②理想時間と現実時間とのぶれ幅

作業見積「3日」と答えた開発機能が、実際に「3日」で終わることは稀ではないでしょうか?この「3日」という見積は「(何者にも邪魔されず、集中して作業した場合に)3日かかる」というように、暗黙の前提のもとに立てられた理想の時間であることが多いです。しかし、実際には、他者からの割込みや並行タスクに対応しながら開発するため、現実にかかる時間は理想時間よりも長くなることが通常です。

理想時間とは

精神と時の部屋のような、何者にも邪魔されない環境で作業した場合の見積もり時間。

現実時間とは

差し込みのタスクや、並行して受け持っているタスクの影響を受けた、実際に開発にかかる期間。

エンジニアが出した「3日」という理想時間の見積をもとに、マネージャーがそのまま3日間の線を引くと、悲劇の始まりです。まずは、この理想時間と現実時間とを分けて考えることが大事です。

例:エンジニア「作業時間だけでいえば3日かかりますが、実際には、定例ミーティングや新人君のOJTの時間を考慮すると、5日は必要です」

ただ、現実時間の見積もりを出すといっても、予想できない差し込みのタスクもあり、簡単ではありません。現実時間の見積もり精度を上げるために、個人的に気を付けている点を上げてみます。

●実績を記録する

実績として日ごろから開発にどれくらい時間をかけられているかを記録し、平均的な開発時間を把握しておくと役立ちます。

以前Twitterで、エンジニアの一日のうちの開発時間が話題になっていました。通常は一日8時間で計算されることが多いと思いますが、リプライを見ると、開発に充てられる実際の時間は一日6時間だという方が多かったようです。

これはチーム状況によると思うので、1週間ほど自チームの開発時間の実績を計ってみてください。仮に一日6時間だった場合、3日(3×8=24時間)の理想時間見積もりは、現実時間だと4日(24÷6)に換算できることになります。弊チームでは、定例ミーティングや並行タスクを考慮して、1日の2/3を開発に充てられるものと基準を置いています。またこれは状況によって変わるので定期的に見直すのがよいです。

●タスク切り替えのオーバーヘッドを最小限にする

プログラミングは創造性の高い作業です。できれば、まとまった時間をとって集中的に作業できた方が捗りますが、現実的にはそうもいきません。一度中断した作業を再開するときに、ローカル開発環境を切り替え、どこまで進めていたかを思い出すといった、切り替えるための時間が余計にかかります(これをオーバヘッドとか、思い出しコストとか呼んでいます)。そのため、連続して作業できる時間が細切れになればなるほど、総作業時間も増えていってしまうのです。

このオーバーヘッドを見積もりに考慮することは難しいので、そもそも発生させにくい工夫ができると捗ります。例えば、作業を中断する小タスクやミーティングは午前中にまとめてしまい、午後に作業時間をまとまって取るようにする、難易度の高いタスクに集中する人と、細かいタスクをさばく人とで役割を分ける、といった感じです。見積もりの精度を上げるために、枠組みを見直してみてください。

●テストと修正のキャッチボール回数を想定しておく

開発者とテスターが分かれている体制の場合に、「テスト⇒修正⇒再テスト⇒再修正」という2者間でのキャッチボールが発生します。このキャッチボールの往復の回数は、1回の往復で終わることもあれば、4回も5回もかかってしまうこともあり、開発精度によってまちまちです。そして、このキャッチボールの回数が増えると、その間にタスクの受け渡しのロスや前述のタスク切り替えのオーバーヘッドが発生するため、開発にかかる現実時間が思ったよりも延びていってしまいます

この時、開発中に発生する不具合数を予想することは、なかなか至難の業です。ただ、このキャッチボールが何往復かかりそうか、であれば、比較的経験をもとに予想がたてやすいのではないでしょうか。

「この案件ならキャッチボール回数を2回以内に抑えられそうだ」などと、開発案件の規模に応じた想定キャッチボール数をチームですり合わせておくと、見積もりがしやすくなります(そしてこれは、テストだけでなく、例えばクライアントからのレビューといった二者間のキャッチボールのすべてでいえることです)。

もし、想定回数を超えるキャッチボールが発生した場合は、見積り精度の問題ではなく、開発精度が低いことが問題なので、スキルマッチや開発プロセスに無理が無かったかを見直してみてください。

まとめ

・工数見積りには、楽観値か悲観値か、理想時間か現実時間か、の2つのぶれ幅がある。
・ぶれ幅に対しての基準をチームで定める。曖昧にしない。

出典

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
不安とストレスから解放される見積りとスケジュール方法

この記事をシェアする
事業について詳しく知る

コンサルティング事業について詳しく知りたい方はこちら

コンサルティング事業部SDPグループマネージャーエンジニア

RECOMMEND

おすすめ記事