開発体制構築の保守・運用費用・ランニングコストについて

保守運用のランニングコストは、運用体制、委託範囲、求める品質によって、月10万円前後から月400万〜600万円程度まで変わります。また、費用の差を生むのは体制の組み方と委託の範囲で、中間マージンやSLAの水準もそこに関わります。

▼全体ガイドの記事
・開発体制構築の完全ガイド

保守運用体制とランニングコストの関係

ランニングコストには、サーバー代やライセンス費などのインフラ費用に加え、システムを支える人員と体制の費用も含まれます。特に、障害の一次対応、改善要望の受付や実装判断、定期更新やセキュリティ対応を誰が担うかで、月々のコストは数倍変わります。保守運用の費用を左右するのは、このように体制の組み方です。

保守運用体制は開発の開始時点から設計しておく必要があり、後から担当者を探すと、引き継ぎ工数や属人化のリスクが費用に加わります。

保守運用体制の組み方によるコストの違い

内製・外部委託・混成のどれを選ぶかで、費用の構造が変わります。各体制の違いは、固定費や対応速度に表れます。

  • 内製:人件費が毎月かかる固定費になる一方、迅速な対応ができ、ノウハウも社内に残ります。
  • 外部委託:月額保守費で済みますが、委託先の利益や管理費、依頼調整の手間が含まれます。
  • 混成:重要な判断や緊急対応を自社で担い、監視や一次対応は外部に任せる形です。

適した体制は、重要度や改修頻度、社内人材の余力によって異なります。特に、安さだけで選ぶと運用実態に合わず、追加対応や緊急依頼で割高になります。

開発体制の設計時から見据える運用フェーズ

保守費は、リリース後に発生するものではなく、開発体制を設計する時点から左右されます。開発の段階から運用までを見据えておけば、リリース後の引き継ぎや属人化に伴う費用を抑えられます。

  • 目的の違い:開発チームは改善を、運用チームは安定稼働を重視しています。
  • 分断の回避:連携が足りないと仕様が伝わらず、運用側が手探りで対応するため工数がかかります。
  • DevOps:開発と運用を組織として連携・融合させる考え方が有効です。
  • 運用を考えた設計:監視、ログ取得、障害切り分けのしやすさを盛り込み、対応工数と費用を抑えます。
  • 担当者の決定:開発初期に保守担当を決めておけば、開発メンバーから知識を移せます。

ポイント

保守の担当を開発の初期に決めておくかで、引き継ぎの工数と月々の費用が変わります。障害対応から定期更新まで、誰が何を担うかを先に分けて考えるのが目安です。

保守運用体制の組み方とコスト構造

内製型・外製型・混成型の費用の持ち方と、本文に示された費用目安を並べた図。
体制の違いは、固定費・月額保守費・役割分担に表れます。

保守運用体制は、内製型・外製(受託保守)型・混成型に分かれ、人員構成と費用がそれぞれ異なります。ここで示す相場は、あくまで一般的な目安です。金額は契約形態や地域、システム規模によって変わるため、実際の費用は個別見積もりで確かめてください。

内製運用体制の人員構成と月額コスト

自社で内製する場合、費用の大半は人件費という固定費になります。運用・保守を担う4〜5名のチームでは、月額およそ400万〜600万円が目安です。

この金額には給与のほか、法定福利費、採用費、PCやライセンスなどの環境費用も含まれます。ただし、改修や対応の頻度が低いシステムでは、固定費が割高に感じられることもあります。

  • 対応の速さ:障害時に、外部への依頼や見積もりを待たずに動けます。
  • 知識の蓄積:システムの内部構造を知るメンバーが社内に残ります。

改修が頻繁な事業の根幹システムや、対応速度が事業継続に直結するシステムでは、固定費を負担しても内製の意義があります。そのため、費用の額だけでなく、こうした見えにくい価値も含めて判断するとよいでしょう。

外製(受託保守)体制のコストの考え方

外部ベンダーに委託する外製体制では、月額保守費という変動費で負担する形になります。費用の目安と契約範囲を、あらかじめ確かめておくとよいでしょう。

  • 相場の目安:初期開発費の年10〜15%程度、月換算で約1%前後です。
  • 費用例:初期開発費1,000万円なら月10万円前後が目安で、実額は契約内容で変わります。
  • 固定費を回避:自社で運用人材を抱えずに済む一方、保守費には委託先の利益や管理費が含まれます。
  • 対応範囲:軽微な不具合修正は月額内、機能追加は別見積もりという線引きもあります。

なお、契約範囲を超える対応には追加費用がかかります。範囲が曖昧なまま契約すると想定外の請求が重なるため、定額と追加費用の境界をはっきりさせておく必要があります。

混成・DevOps融合体制のバランス

混成型は、内製の固定費と外製の追加費用を抑えつつ、コストと機動力のバランスを取る選択肢です。判断の材料になるのは、役割分担と人月費用です。

  • 自社の役割:重要な判断や緊急時の意思決定を担います。
  • 外部の役割:定常監視、一次対応、定型保守をラボ型チームや運用ベンダーに任せられます。
  • 国内人月単価:SIerやSES経由で1人月を確保する場合、月額80万〜120万円程度です。
  • オフショア人月単価:IT人材が豊富な拠点では1人月30万〜50万円程度ですが、ブリッジSE費用が加算されます。
  • チーム連携:組織にDevOpsを取り入れ、共通のツールと情報を使って開発と運用をつなぐと手戻りが減ります。

役割を自社の運用実態に合わせて配分すれば、固定費と変動費のどちらにも偏らず、ランニングコストを調整できます。

ポイント

固定費を抱える価値は、改修や障害対応が頻繁で、対応の速さが事業継続に直結するシステムかどうかで決まります。改修が少ない場合は、月額の委託費と比べてみてください。

多重下請け構造と中間マージンの実態

元請けから二次請け、三次請けへ続く階層と、管理費や実作業者の見えにくさを示す図。
再委託の段数が増えるほど、作業者と費用の流れを追いにくくなります。

保守運用費を考えるうえで、IT業界特有の多重下請け構造は避けて通れません。元請けから二次請け、三次請けへと再委託する形が見られます。

発注費の何割が実作業者に届き、何割が中間で消えるかを理解しておかないと、払い続ける保守費の妥当性を判断しにくくなります。そのため、費用を押し上げる仕組みを知ったうえで、体制面から中間マージンを抑える方法を考えることが欠かせません。

多重下請けが保守コストを押し上げる仕組み

多重下請けは、費用だけでなく作業者の把握や品質管理にも影響します。

  • 中間マージン:開発費の3割超が消えるとの指摘もありますが、契約によって大きく異なります。
  • 費用の配分:支払った保守費の一部は実作業者に届き、残りは各層の管理費と利益になります。
  • 作業者の把握:階層が深いと実作業者が見えにくく、品質や対応速度を管理しづらくなります。
  • 再委託の管理:委託先の概要や契約内容を確認できないと、トラブルの原因究明に時間がかかります。

費用の妥当性を判断するには、自社のシステムが何層の体制で支えられているかを把握しておく必要があります。

体制の透明化による中間マージンの抑制

中間マージンを抑えるには、多重下請けの階層をできるだけ浅くします。再委託先や契約範囲が見えれば、費用と品質責任の所在も把握できます。

  • 階層を浅くする:実際に作業する開発・運用チームと直接契約する方法があります。
  • 再委託を明確化:元請けに契約時点で有無と範囲を定めさせ、発注側も委託先の概要や契約内容を確認・管理します。
  • 直接チームを確保:内製寄りの体制やラボ型の専属チームを組むという選択肢もあります。

中間マージンを減らせば、同じ予算でより多くの実働リソースを確保できます。また、保守費は値引き交渉よりも、支出を見える形にし、不要な階層を減らす体制設計で抑えていきます。

ポイント

発注先が何層の体制で支えられているかが分からないときは、まず委託先の概要と契約内容の確認を求めてください。階層が浅いほど、費用の内訳と実作業者の顔ぶれが見えやすくなります。

SLAと属人化解消を担う運用体制

SLAの指標や品質水準、対応記録、共同作業を4枚のカードに整理した図。
品質の設定と知識の共有を並行して整える構成です。

体制設計では、求める品質をどう担保するかを最初に考える必要があります。安さだけで体制を選ぶと、緊急時の損失が膨らむこともあります。

SLAを担保する運用体制の設計

SLA(サービスレベル合意)は、保守品質を明文化するもので、水準に応じて体制と費用が変わります。品質水準と費用は、トレードオフの関係にあります。

  • 設定する指標:API連携やデータ処理の応答時間、障害時の一次対応時間、復旧目標時間を決めておきます。
  • 高い品質水準:24時間365日の監視や即応人員が必要になり、費用が上がります。
  • 業務時間内の対応:それで足りるシステムなら、過剰な監視体制を避けられます。
  • 影響度に応じた配分:一律に最高水準を求めず、事業への関わりの大きさに合わせてSLA・体制・費用を分けます。

SLAを定めないまま契約すると、求める品質と費用が釣り合わず、過剰投資か対応不足になりがちです。そのため、品質の求め方を体制と費用の形に置き換えて設計することが、要点になります。

属人化を解消するナレッジ体制によるコストの安定

属人化は、保守費が不安定になり高騰する大きな原因です。一人しか分からない状態だと、その人の稼働時間に対応が左右され、離脱した時点で対応できなくなることがあります。引き継ぎや作り直しには多額の費用がかかるため、発注側と開発会社は、ナレッジを形式知として蓄積する仕組みを設けておく必要があります。

  • 対応記録:不具合や対応履歴をインシデント管理表や課題一覧に記録します。
  • 共同作業:ペアプログラミングやモブプログラミングで複数人が知識を共有します。

記録を残せば、誰もが同じ対応を取れるようになります。また、共同作業では暗黙知をチーム全体にリアルタイムで広げられます。

担当者が変わっても、品質と費用が個人の稼働や離脱に左右されにくくなります。属人化の解消は、短期の効率より長期の費用の安定をもたらす投資で、体制設計に欠かせません。

ポイント

監視や即応の体制が重すぎないかは、SLAの水準と事業への影響度を照らして確かめるとよいでしょう。担当者が替わっても対応が続くかは、対応記録の有無で判断できます。

体制最適化によるランニングコスト削減

体制を成熟度や事業状況に合わせて見直すと、ランニングコストを継続的に下げられます。代表的な削減策は、内製化への移行と段階的な体制移行の二つです。

内製化移行による中間マージンの削減

外部委託から内製への移行は、中長期の費用削減に有効です。初年度の費用と、効果が出る条件を確かめておく必要があります。

  • 初年度の負担:採用や育成に費用がかかり、外注継続より一時的に増えることがあります。
  • 2年目以降の効果:中間マージンや都度契約費がなくなり、総費用が下がる場合があります。
  • 製造業の事例:5名規模の内製体制で、2年目以降の年間費用を約3割削減しました。
  • 宿泊事業者の事例:クラウド運用保守を内製化し、クラウド利用費を約29%削減した事例もあります。
  • 向くシステム:改修・運用頻度が高く、外注のたびに費用がかさむシステムです。

ほとんど改修しないシステムでは、固定費だけが残ることがあります。そのため、初年度の投資回収を見通したうえで、対象を選んで段階的に移行するとよいでしょう。

段階的な体制移行によるTCOの最小化

月額費だけで比べると、社内外の調整や体制移行にかかる費用が見えなくなります。そのため、システムのライフサイクル全体の総保有コスト(TCO)で評価すると、体制ごとの費用の違いがつかみやすくなります。

  • TCOの内訳:開発・運用費、外部調達費、社内外の協調コスト、体制移行費です。
  • 100%外部委託:変動費で柔軟ですが、調整コストや中間マージンが膨らみがちです。
  • 100%内製:調整コストはゼロに近づく一方、固定費のリスクがあります。
  • 混成型:多くの場合、中核部分を内製し、周辺の作業を外部に出す形がTCOを抑えやすい一方、知識移転の費用が必要です。
  • 段階的な移行:外部委託を続けながら内製比率を上げ、知識を社内に蓄積します。

保守運用費は、単年度の安さだけでなく、数年単位で体制を進化させる設計として考えます。

ポイント

内製化の対象にするのは、改修や運用の頻度が高く、外注のたびに費用がかさむシステムです。初年度は負担が一時的に増えることがあるため、投資の回収を見通してから移行してください。

まとめ

保守運用費の大半は人と体制にかかり、内製・外製・混成のどれを選ぶかで費用の構造が変わります。判断の要点は、内製なら固定費、外製なら追加費用と契約範囲、混成なら役割分担です。

多重下請けの中間マージンを抑えるには、体制の内訳を見える形にして、階層を浅くします。SLAは事業への影響度に応じて設計し、ナレッジを共有して属人化を解消すると、費用が安定します。

内製化や段階的な体制移行は、TCOを継続的に下げる方法です。開発の初期から運用を見据えて体制を設計すると、長期的に費用を抑えることにつながります。さらに、見直しの際は、現状の体制図と費用の流れを描き、何層を経てシステムが支えられているかを一覧にします。

▼全体ガイドの記事
・開発体制構築の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。