ストーリーポイントだけでは採算が崩れる開発組織のための補完策
はじめに：「ベロシティは出ているのに、なぜ利益が残らないのか」
スクラム開発を回している組織で、よく聞かれる悩みがあります。「ベロシティは安定している、スプリントも完走している、それなのにプロジェクトの粗利が想定より低い」——これはスクラム特有の現象であり、決してチームの怠慢ではありません。スクラムが優れているのは「予測可能なソフトウェア開発の進行」であって、「採算管理」ではないからです。
本記事では、スクラム開発で工数が見えづらくなる構造的な理由と、Jiraだけでは届かない経営・採算・人事評価の領域を整理します。スクラム×工数管理の両立を考える開発PM・EM・受託開発のDeliveryマネージャー向けに、現実的な補完策まで解説します。
この記事でわかること
- スクラムで工数が見えなくなる3つの構造的理由
- Jira（およびストーリーポイント）では届かない領域
- スクラム × 工数管理を両立させる4つの仕組み
- 受託開発・社内開発における具体的な実装パターン
第1章：スクラムで工数が見えない3つの構造的理由
理由① ストーリーポイントは「時間」ではない
スクラムにおけるストーリーポイントは、相対的な複雑度・リスク・規模を表す指標であり、時間（人時）ではありません。これは設計思想として正しく、見積精度の劣化を防ぐためにあえて時間と切り離されています。
しかし採算管理の世界では、最終的に「人時×単価」で原価が決まります。ストーリーポイントだけで運用すると、ベロシティが安定していてもプロジェクトの実工数は誰にも見えず、案件粗利が後追いでしか分からない、という状況が常態化します。
理由② スプリント外の作業が記録から漏れる
スクラムのプロダクトバックログとスプリントバックログには、計画に組み込まれた作業しか入りません。一方で、現場では次のような工数が日々発生しています。
- 本番障害対応・問い合わせ調査
- 他チームからの依頼・社内ヘルプ
- リファクタリング・技術検証（POC）
- 採用・育成（コードレビュー、メンタリング）
- 会議（リファインメント、レトロスペクティブ）
これらは正規のチケットとして起票されないことが多く、ベロシティ計算からも外れます。結果、開発者の総稼働時間に対するスプリント貢献率（チャージ率に相当）が極端に低くても、ダッシュボード上は問題なく見えてしまいます。
理由③ ロール混在で原価計算ができない
一つのスクラムチームには、開発者・スクラムマスター・プロダクトオーナー・QAなど複数のロールが混在します。それぞれ単価も役割も異なるのに、ストーリーポイントベースの管理ではロール別の工数配分が見えません。
とくに受託開発では、契約上「人月単価×ロール別配分」で原価を出す必要があるケースが多く、ロール別工数の不可視化は採算管理の致命傷になります。
第2章：Jiraでは届かない3つの領域
Jiraはタスク管理・スクラムの計画と実行支援において強力なツールです。しかし以下の領域はJira単体では届かず、別の仕組みが必要です。
領域① 案件採算管理
ストーリー数・ベロシティ・残ポイントは見えますが、それを「実時間」「人時単価」「原価」「想定粗利」に変換するレイヤーがJiraにはありません。スプリントが順調でも、契約金額に対して工数が膨らんでいれば、案件は赤字に向かっています。
領域② 顧客契約金額・商談との連動
Salesforceで管理されている商談・契約情報と、Jira上の開発進捗は通常分離されています。営業が握ったスコープと、開発が消化しているチケットが別世界で動いているため、契約上限を超えそうな案件の早期検知ができません。
領域③ 人事評価・育成
Jiraのアサイン情報は「誰に何のチケットが渡っているか」までしか語りません。タスクの難易度、納期遵守率、稼働種別の偏り、チーム貢献量といった人事評価の根拠データは、ストーリーポイントの世界の外にあります。
スクラムは開発の進行を予測可能にするためのフレームワーク。採算管理・契約管理・人事評価は、スクラムの「外側」に補完レイヤーを置くべきテーマであり、Jiraだけで全てを賄おうとすると無理が出る。
第3章：スクラム × 工数管理を両立する4つの仕組み
仕組み① ストーリーポイントと実工数を両立させる
ストーリーポイントの運用は維持したまま、別レイヤーで「実工数（時間）」を記録します。重要なのは、開発者の入力負担を最小化すること。15分単位のタイマーやドラッグ操作で、その日のうちに記録できる仕組みでないと定着しません。
仕組み② 稼働種別を標準化して記録する
スプリント貢献・本番障害対応・調査・リファクタリング・会議・採用育成といった稼働種別を標準化し、工数入力時に選択する形にします。これにより、開発者の総稼働のうち何割がプロダクト価値に向いているかが定量化できます。
仕組み③ 案件・契約・タスクを連結させる
Salesforceの商談・契約情報と、Jiraのチケット、そして実工数を1つのデータモデルで連結します。契約金額・想定工数を起点に、消化工数・残工数・想定粗利率がリアルタイムで見える状態を作ります。受託案件の場合、これがあるだけで赤字案件の早期検知率は劇的に上がります。
仕組み④ ロール別単価で原価を自動計算する
各メンバーにロール別単価（フルコスト）を設定し、入力された工数から自動的に原価が計算される仕組みにします。スクラムチームごとに、スプリント原価とプロダクト価値（受注金額や売上）を並べることで、チームの収益貢献が定量化されます。
第4章：Task RelayとJiraを組み合わせた実装パターン
Task Relayは、Salesforce上で動作するプロジェクト＆工数管理SaaSです。Jiraを置き換えるのではなく、Jiraを残したまま「採算・契約・評価レイヤー」を補完する使い方が現実的です。
- Salesforceの商談・取引先・案件と、Jiraチケットを案件IDで連携
- 工数入力はTask Relay上で行い、タスク（チケット）単位×稼働種別×15分単位で記録
- ロール別フルコスト単価により、案件粗利率がリアルタイム集計
- ストーリーポイントはJira側で運用継続し、実工数との二軸で分析可能
- メンバー別ダッシュボードで、人事評価に必要なタスクデータが自動蓄積
「スクラムを壊さず、採算と評価を取り戻す」——Task Relayが受託開発・社内開発の現場で果たす役割は、まさにこの補完にあります。
| 観点 | Jira（スクラム） | Task Relay（補完レイヤー） |
|---|---|---|
| 進捗管理 | ストーリーポイント・ベロシティ | 実工数・残予算・想定粗利率 |
| 工数記録 | 簡易ログ・任意記録 | タスク×稼働種別×15分単位 |
| 契約金額連動 | 基本的に分離 | Salesforce商談と連結 |
| ロール別原価 | 不可視 | フルコスト単価で自動算出 |
| 人事評価データ | アサイン履歴のみ | 難易度・納期遵守・貢献量を蓄積 |
まとめ：スクラムの理想と、経営の現実をつなぐ
スクラム開発の工数管理は、「ストーリーポイントだけで全てを語れる」という幻想を捨てるところから始まります。Jiraが扱う領域は明確に強いですが、案件採算管理・契約管理・人事評価はその外側にあるテーマであり、別の仕組みで補完する必要があります。
スクラムを壊すのではなく、補完レイヤーで支える——この考え方を取り入れることで、開発組織は「ベロシティは出ているが利益が残らない」状態から、「予測可能で、採算も合い、メンバーも公正に評価される」状態へと進化します。
スクラムを壊さず、
採算と評価を取り戻す。
Jiraと並走するTask Relayの補完レイヤーで、ストーリーポイントと実工数の両立、契約金額連動、人事評価データの蓄積を実現します。