「人月」はシステム開発の世界で昔から使われている工数の単位です。一方、アジャイル開発の世界には「ストーリーポイント」という単位があります。「人月」ではなく「ストーリーポイント」を使う意味について、普段人月で仕事をしている立場の私の理解をシェアします。

結論としては、「人月」ではなく「ストーリーポイント」を使う意味は、工数は相対的であること、同じ作業者やチームであっても時間当たりの生産性は変化しうるを認めること、だと理解しています。

なお、不確実性の存在を前提とするアジャイル開発では見積もりをすること自体がナンセンスであるという考え方（No-Estimates）もあるようですが、ここでは触れません。

「人月」への批判

「人月」という単位は、工数・作業量を"人数"と"時間(月)"という誰にとっても共通の、絶対的、定量的な数値の掛け算で表すことができるため、非常にわかりやすく、今でも多くの現場で用いられています。一方で、この単純すぎる単位、モデルには批判もあります。

人と月は交換できない
最も代表的な批判は、「人月の神話」で指摘されている"システム開発において人と月は交換できない"というものです。田植えのような作業者の間でコミュニケーションを図らなくても仕事が分担できる場合、1人で10ヶ月かかる作業は、10人でやれば1ヶ月で終わらせることができるでしょう。しかし、システム開発においてそれは当てはまらず、人数が増えることによるコミュニケーション労力の増大が分担による作業時間の短縮をすぐに上回ってしまうため、実際には人と月は交換可能ではありません。

人月の前提
もう少し分解してみると、人月を使う=人と月が交換できると考えることは、下記の2つの前提を置くということではないでしょうか。
① 工数は人×月によって絶対的、客観的に表すことができる
② 1人が1カ月働けば1人月、n人がmヶ月働けばn×m人月の作業をこなせる

そして、やはりこれらの前提は現実的ではありません。ビル・ゲイツの「優秀なソフトウェア・プログラマーは平均的なプログラマーの1万倍の価値がある」という発言をはじめとして、エンジニアの生産性は個人間で大きな差があることは各所で指摘されています。つまり、誰が作業するかによってかかる工数は異なります。また、同じメンバーからなるチームであっても、各人の作業に対する習熟度やチームとしての成熟度に応じて生産性は変化するでしょう。

現実に即して考えると、上記の二つの前提は下記のように修正するべきでしょう。
①' 工数は作業者やチームによって相対的なものである
②' 同じ作業者やチームであっても時間当たりの生産性は変化しうる

「ストーリーポイント」を使う意味

上記の内容を踏まえ、ストーリーポイントを使う意味を考えます。

工数に対する前提を見直した上で、なお人月を使い続けるとすれば、次のような現象が起こりえることになります。

・この仕事は、チームAがやると3人月だが、チームBがやると4人月かかる
・ある3人のチームは、先月は2.5人月の作業をこなし、今月は慣れてきたので3人月の作業をこなした。来月は3.2人月の作業をこなせる見込みだ

許容できなくはないですが、「人月」という言葉を使っている限り、どうしても違和感がある、誤解を与える印象になってしまいます。

ストーリーポイントを使うとどうでしょう。ストーリーポイントは絶対的、客観的な単位と結びついておらず、相対的なものです。そのため、同じ作業に対してチームAとチームBで異なるストーリーポイントを与えることも、チームAとチームBが一カ月で消化できるストーリーポイントが異なることも違和感なく行えます。つまり、不確実性を受け入れ、①'、②'の前提に立つと、必然的に工数を表すために絶対的な「人月」ではない相対的な単位が必要になるということです。

ということで、結論として、「人月」ではなく「ストーリーポイント」を使う意味は、①' 工数は相対的であること、②' 同じ作業者やチームであっても時間当たりの生産性は変化しうるを認めること、だと理解しています。