情報管理技術士 学習ノート
← 一覧へ
SW工学・管理
#대가산정#유지관리#운영비#요율제#투입공수#132회
最終更新 · 2026-09-29

ソフトウェア運用段階の対価算定（SW事業対価算定ガイド 2023）

1. 概要

A. 定義

「ソフトウェア事業対価算定ガイド（2023改定）」に基づき、SW運用段階（保守・運用）の対価を機能規模・投入工数・サービスレベル（SLA）のような測定可能な指標に基づいて算定することで、発注・契約の合理的な根拠を提供する標準化された方式である。

ソフトウェアの総所有コスト（TCO）は、開発時点の一度で終わるものではない。むしろシステムが実際に価値を生み出すのは、引き渡し以降の長い運用・保守期間であり、多くの研究や実務経験は、SWライフサイクル全体コストの60〜80%が運用段階で発生すると見ている。それにもかかわらず、長い間、運用対価は「慣行的に開発費の何%」のように根拠の弱い形で計上される場合が多かった。

このような恣意的な算定は、二方向の歪みを生む。一方では、低価格受注競争によって対価が過度に低く計上され、人員を十分に投入できず、その結果、障害対応が遅れて品質が低下する悪循環が生じる。反対側では、根拠なく過大に計上されて予算が浪費される。発注者と遂行者の双方が「なぜこの金額なのか」を説明できない状態では、紛争が頻発せざるを得ない。

対価算定ガイドは、まさにこの恣意性を減らすための仕組みである。韓国ソフトウェア産業協会（KOSA）が毎年改定して公表するこのガイドは、開発費を機能点数（FP）ベースで算定するように、運用段階もまた規模・工数・SLAという計量指標に基づいて対価を算出するように方法を標準化する。すなわち「いくら支払うのか」を交渉力ではなく測定値で説明できるようにすることが、核心的な目的である。

B. 保守と運用の区分

ガイドは運用段階を、性格が全く異なる二つの活動に分ける。保守は、引き渡された応用SWの瑕疵を直し（瑕疵補修）、法・制度の変化やユーザー要求に合わせて小規模な機能を改善・補修する活動である。この負担は概ね管理対象SWの規模（機能点数）に比例する。機能が多く複雑なシステムほど、手を入れる箇所も改善要求も多いためである。

一方、SW運用は、システムが24時間安定して稼働するように常時監視し、障害が起きれば即座に対応し、構成・バックアップ・性能を管理する活動である。この負担はSWの大きさよりも、何名がどのようなサービスレベル（SLA）で常駐するかに左右される。どんなに小さなシステムであっても無停止（24×365）監視が必要であれば交代人員が必要であり、逆に大きなシステムであっても夜間無人運用であれば人員は減る。

二つの活動のコストドライバー（cost driver）が異なるため、一つの算定式で一括りにすると必ず歪みが生じる。規模に比例する保守を人員基準のみで測れば大型システムの改善負担が過小評価され、人員に比例する運用を規模基準のみで測れば高可用性要求が反映されない。そのためガイドは、保守は料率制（開発費×料率）、運用は投入工数（M/M×単価）、そして両者が混在する現実には固定費/変動費の分離という、それぞれ異なる方式を提示する。以下で各方式を原理とともに見ていく。

2. 運用段階対価算定の全体体系

まず、運用段階対価がどのような系統に分かれるのか全体構造を見れば、個別の算定式の位置を理解しやすい。

flowchart TD
  OP["SW運用段階の対価"] --> MA["保守<br/>規模比例"]
  OP --> OPR["SW運用<br/>人員比例"]
  MA --> R1["応用SW料率制<br/>開発費再算定 × 料率"]
  MA --> R2["商用/公開SW保守<br/>購入価基準の料率"]
  OPR --> M1["投入工数方式<br/>M/M × 労務単価"]
  OPR --> M2["固定費 / 変動費<br/>混合精算"]

この体系において、左の系統（保守）は「作っておいたものの規模」がコストを決定し、右の系統（運用）は「常駐する人とサービスレベル」がコストを決定する。2023年改定版はこれに加えて、商用SW・公開SW保守費、セキュリティ性維持サービス費、そして複数のシステムを束ねて運用する統合運用保守の対価体系まで包括するよう範囲を広げた。すなわち、単一システム一つではなく、複数のサービスが絡み合う現実を反映しようとする方向へ進化している。

核心は「性格に合った物差しを当てよ」という原則である。ある活動が規模に比例するのか、人員に比例するのか、それとも要請量に応じて変動するのかをまず判別し、それに合った算定式を選んでこそ、対価と実際の所要が一致する。次節から三つの代表的な方式を順に説明する。

3. 応用SW料率制保守費

flowchart LR
  D["開発費再算定<br/>現在のFP・単価基準"] --> A["補正係数の適用<br/>難易度・SLA"]
  A --> R["保守料率(%)を乗じる"]
  R --> C["年間保守費"]

料率制保守費は、再算定した開発費に保守料率（%）を乗じる方式で求める。一見単純だが、この方式が成立するには二つの前提が必要である。第一は保守負担がSW規模に比例するということ、第二はその規模を開発費という貨幣単位に換算できるということである。二つの前提が合致するとき、料率制は最も簡便でありながら争いの少ない方式となる。

ここで最も重要な概念が「開発費再算定」である。これは、すでに運用中のSWを今また作ると仮定したときにかかる費用を、現在基準の機能点数（FP）とFP当たり単価で改めて計算した値である。過去に実際にかかった開発費をそのまま使わない理由は、時間が経って単価が上がったり、機能が追加・削除されて規模自体が変わっている可能性があるためである。再算定を通じて「現在の規模」を客観的に測り直すのである。

これに乗じる保守料率は通常10〜15%水準を基準としつつ、サービスレベル・難易度・障害対応時間目標のような補正係数を反映して調整する。例えば夜間・休日にも即座に対応しなければならないシステムは料率を高くし、変更がほとんどない安定したシステムは低くする。具体的に、再算定開発費が10億ウォンで料率が12%であれば、年間保守費は約1.2億ウォンと算出される。もし24時間対応要求で補正係数が付いて料率が15%になれば約1.5億ウォンとなる。このように規模という客観的指標に依拠するため、算定過程が透明で紛争の余地が少ない。

ただし料率制にも限界がある。規模が大きいのに実際にはほとんど手を入れない安定システムであれば料率制が過大計上を生むことがあり、逆に規模は小さくても変更要求が殺到するシステムであれば過小計上になる。そのため実務では料率制を基本としつつ、実際の変更履歴を根拠に料率を調整したり、後で説明する変動費方式と併用したりする。

項目 内容
算定式 保守費 = 開発費（再算定）× 保守料率（%）
料率 サービスレベル・難易度の補正係数を反映（通常10〜15%水準）
再算定 現在の機能点数・単価基準で規模を測り直す
前提 保守負担がSW規模（機能点数）に比例
特徴 規模ベース、簡便・客観的、紛争の余地が少ない

4. SW運用の投入工数算定方式

運用費は規模ではなく、実際に何名がどれだけ投入されるかで算定するのが合理的である。常時監視・障害対応のような活動は、SWが大きくても小さくても定められた人員が勤務しなければならないためである。例えば無停止監視の持ち場は、システム規模とは無関係に「その持ち場に人がいなければ」維持されない。このように運用は本質的に人員集約的であり、コストドライバーが規模ではなく人員である。

そのため算定式は 運用費 = 投入工数(M/M) × 労務単価 + 直接経費 + 利潤 の形をとる。ここでM/M（Man-Month）は一人が一ヶ月働く量を意味する工数単位であり、労務単価はSW技術者の等級別平均賃金（統計庁・協会の公表値）を根拠とする。投入工数は、運用対象規模、処理すべき業務量、そしてSLA（可用性・応答時間目標）を総合して算定する。

SLAは特に工数を大きく左右する。例えば平日日中（8×5）のみ対応すれば1〜2名で十分なシステムであっても、24時間無停止（24×365）監視へと要求が上がれば、交代勤務のために4〜5名以上が必要になる。同じシステムであってもSLA目標が可用性99%から99.9%へ上がれば、対応人員と予備人員が増えて工数が増加する。具体的に、3名が常駐し等級平均労務単価が月600万ウォンであれば、人件費だけで月1,800万ウォン、年2.16億ウォン水準となり、ここに経費・利潤が加わる。

この方式の強みは、運用の実際の性格をそのまま反映する点である。規模では説明できない「常駐しなければならないコスト」を正直に計量するためである。一方、弱みは投入工数の算定が協議に依存する部分が大きく、業務量・SLAの根拠を明確にしなければ依然として争いの余地が残るという点である。したがって契約時には、監視の時間帯、目標応答時間、月間処理件数のような指標を具体的に明示しなければならない。

項目 内容
算定式 運用費 = 投入工数(M/M) × 労務単価 + 経費・利潤
投入工数の算定 運用業務量・SLA・対象規模ベース
労務単価 SW技術者の等級別平均賃金基準
前提 運用負担が規模より投入人員に比例
特徴 実投入ベース、常時運用の性格に適合

5. 固定費/変動費算定方式

flowchart LR
  T["運用対価"] --> F["固定費<br/>常時運用人員"]
  T --> V["変動費<br/>需要ベースの作業"]
  F --> B["月定額保証"]
  V --> S["実績精算"]

現実の運用業務は、性格の異なる二つの部分が混在している。一つは「常に必要な部分」で、常時監視・基本保守・定期点検のように毎月固定的に発生する。もう一つは「要請があるときだけ発生する部分」で、機能改善・大規模障害対応・一時的な負荷処理のように時期と量がまちまちである。この二つを一つの方式で一括りにすると、実際の所要と対価が食い違う。

そのためガイドは、常時的な性格の固定費（月定額）と、要請・作業量に連動する変動費を分離して算定するようにしている。固定費は予測可能な基本費用を安定的に保証して遂行者が最小人員を維持できるようにし、変動費は実際に発生した分だけ精算して発注者が不要な費用を払わないようにする。すなわちこの分離は、予測可能性（固定費）と公正性（変動費）を同時に捉えようとする設計である。

実務では概ね、固定費を骨格として置き、その上に変動費を乗せる混合方式を使う。例えば月間の基本監視・保守費用を固定費2,000万ウォンと定め、機能改善の要請は件当たりまたは投入M/Mで算定して変動費として別途精算する形である。こうすれば平常時には安定した対価が保証され、大規模な改善が必要な月には実際の作業量分だけ追加されるため、双方とも納得できる。ただし変動費の精算基準（何を変動と見るのか、単価をどう設定するのか）を契約書に明確にしておかないと、かえって都度の協議で対立が大きくなりうる。

区分 内容 性格
固定費 常時運用人員・基本保守費用 月定額、予測可能
変動費 改善・障害など要請・作業量連動費用 実績精算
適用 サービス特性に応じて固定+変動の混合 公正性・柔軟性

6. 三方式の比較と適用事例

三つの方式は優劣の関係ではなく、対象業務のコストドライバーが何かに応じて選択する道具である。料率制はコストドライバーが規模のとき、投入工数は人員のとき、固定+変動は需要変動が大きいときに適合する。誤った物差しを当てれば歪みが生じる。例えば人員集約的な24時間監視を料率制のみで測れば、規模が小さいという理由で対価が低く計上され、必要な交代人員を確保できなくなる。

具体的な事例として三類型を対比してみよう。第一に、機能が膨大だが変更が頻繁でない大型行政情報システムの応用SW保守は料率制が適合する。規模が大きく改善負担が規模に比例するため、再算定開発費100億ウォンに料率12%を適用して年12億ウォンで算定する形である。第二に、規模は中程度だが無停止・即時対応が必須の対国民サービス（例：オンライン民願ポータル）は投入工数が適合する。24時間交代のために5名常駐、等級平均労務が月600万ウォンであれば人件費だけで年3.6億ウォン水準で算定される。第三に、平常時の運用は安定しているが政策変化のたびに大規模改編が集中するシステムは固定+変動が適合する。固定監視費を月2,000万ウォンとし、改編プロジェクトを変動費で別途精算するのである。

方式 適合する状況 コストドライバー 代表事例
料率制 規模比例の保守 SW規模(FP) 大型行政情報システム
投入工数 人員集約の常時運用 投入人員・SLA 無停止の対国民サービス
固定+変動 需要変動の大きい業務 常時+要請量 政策連動で改編が頻繁なシステム

7. 深化：対価体系の最新動向

対価算定ガイドは固定された文書ではなく、産業変化に合わせて毎年改定される生きた基準である。2023年改定版（2023.12.08公表）では、料率制保守費だけでなく商用SW・公開SW保守費、セキュリティ性維持サービス費など類型が細分化された。これは自社開発SWのほかに商用パッケージとオープンソースが混在する現実を反映したもので、それぞれ購入価・ライセンス基準の料率やセキュリティパッチ支援対価を別途算定するようにした。

最も注目すべき変化は、クラウド・SaaS移行と統合運用保守の反映である。過去にはシステムを一つ一つ個別契約で運用したが、最近は複数のシステムを束ねて一つの事業として統合運用・保守する形態が増えた。これに伴い協会はSaaS導入事業の対価体系と統合運用保守事業の対価算定方法を提示し、個別合算ではなく統合運用の規模の経済と共通インフラを反映するようにした。クラウド環境ではインフラ費用が使用量ベース（従量制）に変わるため、対価体系も固定人員中心からサービス・使用量中心へ移行する趨勢である。

試験答案の観点では、「なぜ運用対価を計量化すべきか」（低価格受注・品質低下の悪循環の遮断）、「保守と運用の違い」（コストドライバー：規模 vs 人員）、「三方式の選択基準」を軸に叙述し、最新動向としてクラウド・SaaS・統合運用を付け加えれば、深みのある論述になる。

8. 考慮事項および示唆点

  • 性格に合った方式の選択：規模比例が明確な保守は料率制、人員集約的な運用は投入工数、需要変動の大きい業務は固定+変動の混合が適合する。一つの万能式を強いれば低価格・過大の歪みが生じるため、発注前に対象業務のコストドライバーからまず判別すべきである。
  • SLA・業務量ベースの計量化：対価の根拠をSLA（可用性・応答時間）・月間処理件数のような測定指標で明示してこそ、低価格受注と品質低下の悪循環を断ち切れる。契約書に成果物・投入計画・精算基準を具体化して解釈紛争を予防する。
  • 公共SW対価の現実化と生態系：ガイドの趣旨は、対価を現実化してSW技術者の処遇とSW品質をともに引き上げることにある。これは単なる予算問題ではなくSW産業生態系の持続可能性に直結し、低価格慣行が固定化すれば優秀な人材の離脱につながる。
  • クラウド・統合運用移行への対応：SaaS・クラウドの拡大で費用が従量制に変わり、複数システムの統合運用が増えることで、固定人員中心の算定からサービス・使用量中心の算定への移行を準備すべきである。統合運用は規模の経済を活用しつつ、責任の所在を明確にする契約設計が鍵となる。
  • ガイドの法的性格と協議の余地：対価算定ガイドは強制規定ではなく勧告的性格の基準であるため、料率・補正係数・労務単価には依然として協議の余地がある。したがってガイドを根拠としつつ、事業特性に合った補正と明確な契約条項で補完してこそ実効性がある。

参考資料

一言まとめ: SW運用段階の対価は、規模に比例する*保守を料率制（開発費×料率）で、人員に比例する運用を投入工数（M/M×単価）*で算定し、常時費用は固定費・作業量連動費用は変動費に分けてコストドライバーに合わせて計量化することが核心であり、最近では商用・公開SW・クラウド・統合運用まで反映するよう対価体系が進化している。