TRACERY Lab.(トレラボ)

TRACERY開発チームが、要件定義を中心として、システム開発で役立つ考え方や手法を紹介します。

RDRAで見積りを行う方法その4〜アジャイル開発編

シリーズ: モデルベース要件定義手法RDRA

TRACERYプロダクトマネージャーのharuです。

前回の記事までは、「RDRA×見積りシート」によるウォーターフォール開発の見積り方法を解説してきました。

アジャイル開発では、「一定の人数のチームを組成し、その体制を維持しながら一定期間で開発を進める」という特性があり、ウォーターフォール型開発とは異なる見積りアプローチが必要です。

これは、予算確保や契約上の制約(アジャイル開発では準委任契約が採用されることが多い)により、一定期間・一定体制での計画が求められるケースが多いためです。

本記事では、「RDRA×見積りシート」のアジャイル開発用見積りシートを用いた見積りの考え方と全体の流れを解説します。

アジャイル開発用見積りシートの全体像

下図にアジャイル開発用見積りシートの全体像を示します。

アジャイル開発用見積りシートの全体像

アジャイル開発用見積りシートでは、要件モデルを起点に、次の4ステップで見積りを導出します。

  1. 要件モデルから機能規模(SFP)を算出
  2. 機能規模を生産性で割り、開発工数(人月)を算出
  3. チーム体制から開発期間を算出
  4. ロール別の要員数と単価から総費用を算出

ウォーターフォール開発と同様に、要件モデル → 規模 → 工数 → 期間 → 費用という一貫した流れで見積りを行いますが、アジャイル開発では「スコープを固定する」のではなく、「体制と期間を固定する」点が大きく異なります。

SFPを算出し、SFPを開発工数(人月)に変換する

SFPとは、シンプルファンクションポイント法(Simple Function Point)の略で、システムの機能規模を簡易的に定量化するための手法です。

要件モデルからSFPを算出し、それを生産性で割ることで開発工数(人月)を導出します。このプロセス自体はウォーターフォール用見積りシートと共通です。

なお、アジャイル開発ではストーリーポイントを用いるケースも多くありますが、SFPは以下の点で有効です。

  • 要件モデルと直接対応付けられる
  • プロジェクト初期段階でも算出可能
  • 見積りの客観性・再現性を担保できる

そのため、アジャイル開発用見積りシートではストーリーポイントの代替ではなく、初期見積りの基準軸としてSFPを活用します。

実務では、この初期見積りをもとにスプリント開始後にストーリーポイントへ再スケーリングする、といった使い方も可能です。

SFPによる開発工数の算出方法の詳細については、RDRAで見積りを行う方法その2〜ウォーターフォール開発・工数編の「SFPを算出する」「SFPを開発工数(人月)に変換する」の章を参照してください。

SFPを開発工数(人月)に変換する

開発期間を算出する

開発工数が算出できたら、次に「どの期間で開発できるか」をチーム体制から導出します。

アジャイル開発では、一定のチームを維持しながら開発を進めるため、以下の考え方を取ります。

  • 期間ではなく体制(キャパシティ)を固定する
  • 工数をそのキャパシティで割ることで期間を算出する

具体的には、シニア開発者・開発メンバーそれぞれの人数と稼働率をもとに、月あたりの開発要員数を算出し、次の式で開発期間を求めます。

開発期間 = 全体の開発工数 ÷ 月あたりの開発要員数

開発期間を算出し、月あたりのSFP数を確認する

たとえば、全体の開発工数が16人月であり、月あたりの開発要員数が4人の場合、開発期間は4か月となります。

ただし、この計算はあくまで理想的な並列化を前提とした近似値です。実務では以下の要因により乖離が発生します。

  • コミュニケーションコストの増加
  • スキル差による生産性のばらつき
  • 作業の依存関係による並列化の制約

そのため、算出結果はそのまま確定値として扱うのではなく、後述する見積り誤差とあわせて判断することが重要です。

実務では、この理論値に対してバッファを持たせる、もしくは過去実績から補正係数を掛けるといった調整が一般的です。

総費用を算出する

次に、開発体制をロール単位で分解し、それぞれの要員数と単価から総費用を算出します。

対象となる主なロールは以下の通りです。

  • プロダクトオーナー
  • 開発マネージャー(SM)
  • シニア開発メンバー
  • 開発メンバー
  • インフラメンバー
  • 移行メンバー

それぞれについて、月あたりの要員数と単価を設定し、以下の式で費用を算出します。

ロール別費用 = 月あたりの要員数 × 単価 × 開発期間

これを合計することで総費用を導出します(下図)。

総費用を算出する

ロールごとに分けて積算することで、以下のメリットがあります。

  • 費用の内訳が明確になる
  • 見積りの妥当性を説明しやすくなる
  • 要員構成の調整によるコスト最適化が可能になる

なお実務では、インフラや移行といったロールは期間全体で均等に投入されるとは限らず、特定のタイミングで増減します。

本シートでは平均化した値として扱いつつ、必要に応じて補正する前提で利用します。

見積り誤差の推定

見積りは単一の数値ではなく、幅(レンジ)で提示することが重要です。

特にアジャイル開発では、スコープが変動する前提で進むため、不確実性を織り込んだ見積りが不可欠です。

アジャイル開発用見積りシートでは、ウォーターフォール用見積りシートと同様に、要件の検討状況を設定することで、総費用の下限〜上限を自動算出できます。

このレンジは主に以下の要因で変動します。

  • 要件の不確実性
  • 技術的難易度の不透明さ
  • チームの生産性のばらつき

見積りレンジを提示することで、関係者は「どの程度のリスクを含んだ計画なのか」を理解した上で意思決定できます。

初期段階では±50%程度の幅を持つことも珍しくなく、要件の具体化に伴い徐々に収束していきます。

考え方の詳細はRDRAで見積りを行う方法その3〜ウォーターフォール開発・工期、金額編の「見積り誤差の推定」の章を参照してください。

見積り誤差の推定

最後に

本記事では、「RDRA×見積りシート」のアジャイル開発用見積りシートを用いて、要件モデルから算出したSFPを起点に、体制(キャパシティ)から開発期間を導き、ロール別の要員数と単価から総費用を算出するまでの流れを解説しました。

アジャイル開発の見積りは、「スコープを固定する」のではなく、「体制と期間を固定し、その中で提供できる価値を最大化する」という前提に立つ必要があります。そのため、見積りは単なる金額算出ではなく、どの体制で、どの程度の価値を、どの期間で提供するのかを定義する行為でもあります。

「RDRA×見積りシート」を用いることで、要件モデルという共通の基盤から、ウォーターフォール・アジャイルいずれの開発手法においても一貫したロジックで見積りを導出できます。 これにより、見積りを経験や勘に依存させるのではなく、説明可能で再現性のあるプロセスとして扱うことが可能になります。

プロジェクト初期の見積り精度を高めたい場合や、顧客への説明責任を果たす必要がある場面で、本手法は特に有効です。

実務では、この見積り結果を初期計画として活用し、開発の進行に応じて継続的に見直していくことが重要です。本手法が、そのための基準軸として機能すれば幸いです。

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860