Entry Programming

なぜソフトウェアプロジェクトは思った以上に時間が掛かるのか – 統計モデル

2019-04-22

author:

なぜソフトウェアプロジェクトは思った以上に時間が掛かるのか – 統計モデル

ソフトウェアを多少開発したことのある人なら誰でも、どれ程の時間が掛かるか予測するのが難しいということを知っています。根本的に何かを解決する仕事に関しては、それに要する時間を何の先入観もなしに予測することは難しいものです。私が昔から持っている持論の一つは、これらの内いくつかは単純な統計から導き出せる、ということです。

あるプロジェクトに1週間掛かると予測するとしましょう。まずは、次の3つが同等の可能性で起こり得るものとします。要する時間がそれぞれ、1/ 2週間、1週間、2週間の3つです。結果の中央値は、実際の予測値と同じ1週間ですが、平均(または期待値)は7/6 = 1.17週間となります。予測値は中央値(1)に対して(偏らないよう)較正されていますが、平均値に対してはされていません。

「ブローアップ因数」(実際の時間を予測時間で割った値)の合理的なモデルは、対数正規分布のようなものです。予測値が1週間の場合は、実際の結果を、1週間前後の対数正規分布に従って分布する確率変数としてモデル化しましょう。これは、分布の中央値が正確に1週間であるという性質を持ちますが、平均値ははるかに大きくなります:

ブローアップ因数の対数をとると、0を中心とした良くある正規分布になります。これは、ブローアップ因数の中央値が1であること、またお忘れかも分かりませんが、log(1) = 0を前提にしています。ただしタスクが異なると、0の前後における不確実性が異なる場合があります。正規分布の標準偏差に対応するσパラメータを変えることで、これをモデル化できます:

いくつか数字を入れましょう:log (実際の時間 / 予測時間) = 1のとき、ブローアップ因数はexp (1) = e = 2.72です。プロジェクトがexp (2) = 7.4まで伸びる可能性もあれば、exp (-2) = 0.14で完了すること、つまり予測時間の14%で完了することも同様に起こり得ます。直感的に平均値が大きいのは、予測よりも早く完了したタスクにより、はるかに長い時間が掛かるタスクを補う方法が無いためです。私たちは0に縛られていますが、その他の方向には制限されていません。

これは単なる理論に過ぎないでしょうか?さあ、賭けてみて下さい!でもすぐに、実際のデータを読み解き、これが実証的データを使用して現実的・合理的にマッピングされることを示していきましょう。

ソフトウェアの予測

これまでの部分は良いとして、次はソフトウェア予測の観点から、これが意味するところを考えてみましょう。ロードマップを見て、それが20の異なるソフトウェアプロジェクトから成り立っていたとしましょう。そして予測します:それら全てを完成させるのに、どれ程の時間が掛かるでしょうか?

ここで平均値が極めて重要になります。平均値は単純に合計されますが、中央値はそうなりません。したがって、n個のプロジェクトの完成に掛かる時間を知りたければ、その平均値を調べる必要があります。ここに、すべてσ = 1の、進行中の3つの異なるプロジェクトがあるとします。

  Median Mean 99%
Task A 1.00 1.65 10.24
Task B 1.00 1.65 10.24
Task C 1.00 1.65 10.24
SUM 3.98 4.95 18.85

平均値は単純に合計され1.65 × 3 = 4.95になりますが、他の列ではそうはなりません。

それでは、σが異なる3つのプロジェクトを合計してみましょう:

  Median Mean 99%
Task A (σ=0.5) 1.00 1.13 3.20
Task B (σ=1) 1.00 1.65 10.24
Task C (σ=2) 1.00 7.39 104.87
SUM 4.00 10.18 107.99

ここでも平均値は単純に合計されていますが、先入観なしの場合に予測したであろう3週間からは離れています。不確実性の高いσ = 2のプロジェクトが、基本的に完成までの平均時間を左右していることに注目してください。99%値に関して言えば、左右するどころか、他のすべてを飲み込んでしまっています。さらに数を増やしてみましょう:

  Median Mean 99%
Task A (σ=0.5) 1.00 1.13 3.20
Task B (σ=0.5) 1.00 1.13 3.20
Task C (σ=0.5) 1.00 1.13 3.20
Task D (σ=1) 1.00 1.65 10.24
Task E (σ=1) 1.00 1.65 10.24
Task F (σ=1) 1.00 1.65 10.24
Task G (σ=2) 1.00 7.39 104.87
SUM 9.74 15.71 112.65

繰り返しになりますが、1つの例外タスクが、少なくとも99%値においては、計算を左右しています。平均値についても、これらのタスクすべてに要する時間の中央値がほぼ同じであるにも関わらず、1つの例外プロジェクトがその時間の約半分を占めてしまっています。私はこれをシンプルにするため、すべてのタスクの予測値は同じだが不確実性が異なると仮定しました。値を同様に変えても、同じ計算が適用されます。

面白いことに、私はこの勘を少し前から持っていました。予測値を合計していっても、最終的に複数のタスクを考える場合には、なかなか上手くいきません。その代わり、どのタスクが最も不確実性が高いのかを把握することです―これらのタスクが基本的に、完了までの平均時間を左右することになります。

このグラフは、平均値と99%値を不確実性(σ)の関数としてまとめたものです:

これこそ数学でしょう!私はプロジェクトの計画を通して、これを評価するようになりました。今では、タスクの予測値を合計することは、それらに要する時間を考える上で大変な誤解を招くと考えています。すべて飲み込んでしまうおかしなタスクが存在するので。

経験的データはどこに?

私は長い間、この「奇妙なおもちゃ理論」を頭の中にしまっていましたが、時々それを、私が観察してきた現実世界の現象の良い実例であると考えていました。しかしある日、ネットサーフィンの最中に、プロジェクトの予測と実際の時間に関する一連の興味深いデータを見つけました。何とも素晴らしいものでした!

予測時間と、実際の完了までに要する時間の、簡単な散布図を作ってみましょう:

ブローアップ因数の中央値は、このデータでは正確に1になるということがわかる一方、その平均値は1.81です。繰り返しますが、これは開発者たちが中央値を適切に予測しているという勘を裏付けるものですが、その平均値ははるかに高くなります。

ブローアップ因数の分布を見てみましょう。その対数をとります:

ブローアップ因数がexp (0) = 1のときの0が中心になっているのが良くわかります。

統計ツールボックスを使いこなそう

ここで少しマニアックな話をしましょう―お好みでなければ飛ばしてください。こちらの経験分布から何が読み取れるでしょうか?ブローアップ因数の対数は正規分布に従って分布すると予想されるかもしれませんが、それは必ずしも正しくありません。σはそれ自体がランダムで、プロジェクト毎に異なるということに注意してください。

σをモデル化するための便利な方法の1つは、逆ガンマ分布からサンプリングすることです。ブローアップ因数の対数が正規分布に従って分布していると(上記と同様に)仮定すると、ブローアップ因数の対数の「グローバル」分布は、スチューデントのt分布になります。

スチューデントのt分布を、上記の分布に当てはめてみましょう:

どうでしょう、ぴったり一致していませんか?t分布のパラメータは、σ値の逆ガンマ分布も定義します。

σ > 4などの値が、驚くほどありそうもないことに注目してください。しかし、もしそれが起こると、平均値が一気に数千倍上昇します。

なぜソフトウェアプロジェクトは思った以上に時間が掛かるのか

この一連のデータがソフトウェア開発の典型であると(疑わしいものですが)仮定するなら、さらにいくつかの数値を推測できます。t分布のパラメータを使えば、そのタスクのσがわからなくても、タスク完了までに掛かる平均時間を算出できます。

このデータから算出されるブローアップ因数の中央値は1(先程と同様)ですが、ブローアップ因数の99%値は32、99.99%値に至ってはなんと、5500万まで跳ね上がります。1つの(大げさな)解釈により、いくつかのタスクが本質的に不可能になってしまうのです。実際、これらの極端なケースは平均値に多大な影響を与え、どのタスクの平均ブローアップ因数も無限大になります。締め切りに間に合わせようと努力する人々にとっては、とんでもなく悪い知らせでしょう!

まとめ

もし私の理論が正しければ(まずあり得ませんが)、以下のような結論が得られます:

  • 人々は完了時間の中央値を上手く予想していますが、その平均値は考慮していない。
  • 分布が偏ってしまう(対数正規)ため、平均値は中央値よりも余程悪い。
  • n個のタスクの予測を合計しだすと、さらに良くないことになる。
  • 最も不確実性の高いタスク(最大規模のものが多い)が、すべてのタスク完了までに掛かる平均時間を左右することがよくある。
  • 何の情報もないタスクを完了するには、実は無限の時間が掛かる。

注釈

  • 明らかにこれは、私がWeb上で見つけてきたある一連のデータに基づいたものです。他のデータでは異なる結果になるかもしれません。
  • 他の統計理論と同じように、私の理論も当然、非常に主観的なものです。
  • この理論がどれだけ上手く機能するかを確認するため、より大きなデータに適用したいと思っています。
  • 私はすべてのタスクを、独立したものと仮定しました。実際には、そこには分析をより面倒なものにするような相関関係があるかもしれませんが、(私の考えでは)最終的には同じ結論に至るでしょう。
  • 対数正規分布値の合計は、別の対数正規分布値とはなりません。多くのタスクは実際には単なるサブタスクの合計であり、そのように安定してさえいれば良いため、これは分布の欠点と言えます。
  • 小さなタスクは分析を歪めるため、ちょうど7のところで奇妙なスパイクがあったので、ヒストグラムから小さなタスク(予測時間7時間以下)を削除しています。
  • いつものように、私のGitHub上にコードがあります。
  • Hacker NewsRedditで少し議論されています。

Erik Bernhardsson      
住宅ローンの新しい方法を探るスタートアップ企業、Betterの最高技術責任者。オープンソースとなっているLuigiやAnnoyをはじめ多くのコードを書く。NYC Machine Learningイベントを共催。

この記事は、著者の許可を得て翻訳しています。なお、原文はこちらです。