← 最新の論文
💻 computer science

A Capacity-Aware Parr Model for Agile Projects

本論文は、無制限のスタッフ配置を仮定することなく、正規化された潜在的エフォート需要と観測または計画されたキャパシティ・トラジェクトリを統合することで、アジャイルプロジェクトの進捗、完了時期、およびリソース不足を予測する、古典的なParrモデルのキャパシティを考慮したリファクタリングを提案する。

原著者: Pedro E. Colla

公開日 2026-07-03
📖 1 分で読めます☕ さくっと読める

原著者: Pedro E. Colla

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む

あなたは、ある長いロードトリップの計画を立てていると想像してください。あなたには、目的地に時間通りに到着するために、各段階でどれだけの燃料を消費すべきかを正確に示す地図があります。これが、従来のソフトウェアモデルが行っていることです。彼らは、「このプロジェクトを完了するには、中盤には大規模なチームが必要で、序盤と終盤は少人数でよい」という曲線を描きます。

しかし、現実の世界(特に「アジャイル」なソフトウェア開発チーム)では、問題が発生します。「いつでも、欲しい時に、誰でも雇える」わけではないからです。 あなたの会社には、5人の固定されたチームがあります。おそらく、彼らは週に40時間しか働けません。従来の地図は、「来月は20人必要です!」と言いますが、上司は「ダメだ、5人しかいない」と言うのです。

この論文は、その地図の新しい見方を提案しています。その曲線を「採用のための厳格なルール」として扱うのではなく、**「隠れた飢え(ワークへの渇望)」**として扱うのです。

コアとなる考え方:「飢え」 vs 「冷蔵庫」

著者であるペドロ・コラ(Pedro Colla)は、2つの要素を切り離して考えることを提案しています。

  1. 飢え(潜在的需要): これは「パル曲線(Parr Curve)」です。これは、プロジェクトが特定の時点で自然にどれだけの仕事をこなしたいと考えているかを表します。それは、日中の真ん中には非常に空腹になり、朝や夕方には空腹が和らぐ「胃袋」のようなものです。
  2. 冷蔵庫(キャパシティ): これは、実際に利用可能なリソースです。例えば、胃袋がステーキを欲しているときに、手元にあるのはサンドイッチ(5人)だけかもしれません。

古いやり方: 古いモデルは、もし曲線が「ステーキが必要だ」と言えば、必ずステーキを用意しなければプロジェクトは失敗するという前提に立っていました。彼らはチームの規模を曲線に合わせようと無理に動かしていました。

新しいやり方(この論文): 新しいモデルは、「なるほど、プロジェクトはステーキを欲しているが、我々にはサンドイッチしかない。サンドイッチができる限り多くのことをこなすが、ステーキを食べたと偽ったりはしない」と述べます。

平易な言葉による仕組みの説明

このモデルは、この「飢え」を追跡するためにシンプルな数式を使用します。そして、3つの問いを投げかけます。

  1. 食事全体はどのくらいの大きさか?(総エフォート量)。
  2. 飢えの曲線はどのような形をしているか?(プロジェクトは通常いつ最も忙しいのか?)。
  3. 今日、冷蔵庫には何が入っているか?(今週、実際に何人が利用可能か?)。

その後、モデルは以下を算出します。

  • 進捗(Progress): 今週、食事のどれくらいを実際に食べたか?
  • ギャップ(The Gap): 「キャパシティ不足」があったか(お腹は空いているのに食べ物がない状態だったか)?
  • スラック(The Slack): 食べる必要のない余分な食べ物が冷蔵庫にあったか?

「ローリング・フォアキャスト(繰り越し予測)」の比喩

あなたが車を運転していて、GPSをチェックしているところを想像してください。

  • 古いGPS: 「午後5時に到着するには、時速100マイルで走らなければなりません。」(交通状況や速度制限を無視しています)。
  • このモデル: 「あなたは午後5時に到着するために時速100マイルで走りたいと考えていますが、制限速度は時速60マイルです。したがって、到着は遅れます。現在のチーム規模が60マイルのままであれば、到着予定時刻を再計算しましょう。」

この論文は、実在するソフトウェアプロジェクト(5〜8人のチームが22週間働いたもの)のデータを使用して、このアイデアをテストしています。彼らはデータを半分に分けました。

  1. キャリブレーション(調整): 旅行の前半部分を使用して、特定のチームに適合するように「飢えの曲線」を微調整しました。
  2. 予測: 後半部分を使用して、最終的な結果を事前に知ることなく、チームの実際の規模のみに基づいて、モデルが将来を予測できるかどうかを確認しました。

彼らが達成したこと(および達成できなかったこと)

この論文は、自分たちが何を成し遂げたのかについて非常に正直です。

  • 内部的には機能している: モデルは、チームの進捗を正常に追跡し、彼らが「飢餓状態(人員不足)」であったか、あるいは「残り物(余剰キャパシティ)」があったかを特定することに成功しました。
  • シンプルである: このモデルは、なぜチームが遅いのか(コミュニケーション不足やバグなど)を説明しようとはしません。単に、プロジェクトが求めているものと、チームができることの間のギャップを測定します。
  • 魔法の水晶玉ではない: 著者らは、このモデルをたった一つのプロジェクトでしかテストしていないことを認めています。したがって、これが世界中のあらゆる企業で機能すると断言することはできません。普遍的なルールであることを証明するには、より多くのプロジェクトでテストする必要があります。

結論

この論文は、ソフトウェアの作り方に関する新しい方法を発明したわけではありません。代わりに、マネージャーのための**「より優れたダッシュボード」**を発明したのです。

それはマネージャーに「20人を雇わなければならない!」と命じるのではなく、「プロジェクトは20人を求めていますが、現在5人しかいません。その結果、プロジェクトが具体的にどれくらい遅れるのか、そしてチーム規模を5人のまま維持した場合、いつ完了するのかを正確にお伝えします」と伝えるものです。

これは、硬直した数学的な曲線を、限られたリソースという現実を尊重した、柔軟なツールへと変えるものです。

自分の分野の論文に埋もれていませんか?

研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。

Digest を試す →