ラボ型契約の保守・運用費用・ランニングコストについて

ラボ型契約の保守・運用費用は、月額で数万円から数百万円規模まで幅があります。金額を左右するのは、確保するエンジニアの人数、人月単価、契約期間の3つです。ラボ型契約では確保したチームの稼働時間に対して月額で払うため、作業量が少ない月でも原則として同じ額がかかります。

▼全体ガイドの記事
・ラボ型契約の完全ガイド

ラボ型契約の費用構造(月額固定・稼働ベース)

月額費用を中心に、エンジニアの人数、人月単価、契約期間を示した図。
月額を決める要素と総額を左右する期間を分けて捉えられます。

ラボ型契約の月額費用は、確保するエンジニアの人数と人月単価で決まります。たとえば、3名を人月単価80万円で確保すると、月額は240万円になります。一方、契約期間は月額を変えず、その月額を払い続ける期間の長さによって総額が決まります。

開発量が多い月でも、軽い改修だけの月でも、費用は原則変わりません。これは、支払いの対象が作ったものの量ではなく、チームの稼働時間だからです。

この点で、ラボ型契約は請負契約と仕組みが異なります。請負では作ったものに対して支払うのに対し、ラボ型契約では確保した時間に対して支払います。

リリース後も、バグ修正やセキュリティ更新は継続的に発生します。そのため、月額固定・稼働ベースの仕組みは保守・運用にも当てはまります。さらに、軽微な機能追加や問い合わせ対応、性能改善も必要になります。これらを専属チームにまとめて任せれば、毎月一定の費用でシステムを稼働状態に保てます。

保守に空き時間を回せるという利点がある一方で、稼働が少ない月には費用が割高になるリスクもあります。コスト管理では、この両面を理解することが出発点になります。

月額固定費の決まり方と人月単価の相場

月額固定費を大きく左右するのは人月単価で、その単価はエンジニアのスキルレベルと開発拠点によって変わります。拠点ごとの相場を並べて見ると、同じ人数でも金額に差が出る理由が分かります。

  • 首都圏(東京基準):初級は月60万〜100万円、中級は80万〜120万円、上級(プロジェクトマネージャー等)は100万〜160万円程度です。
  • 国内ニアショア:プログラマーは約52.8万〜63.5万円、シニアは約68万〜75.2万円、PMは約85万〜104万円です。
  • オフショア:ベトナムなどは東京より30%〜50%程度安く、プログラマーは約30万〜40万円、シニアは約40万〜60万円、ブリッジSEは約59万〜88万円です。
  • 人件費の安い地域:インドネシアなどでは、人月20万〜30万円程度になるケースもあります。

地方都市に拠点を置くと、東京の拠点より5%〜30%程度安く抑えられます。保守・運用では、単価に加えてチーム構成も月額のランニングコストを左右します。新規開発ほどの人数が要らない場合は、エンジニア1〜2名の小規模チームで抑えるのが一般的です。

コストを下げる実務上の方法の一つが、シェアードアサインです。高単価のPMやブリッジSEは他案件と掛け持ちにでき、専任の1.0人月ではなく、1ヶ月あたり0.2〜0.5人月など稼働率に応じて費用を按分します。こうすると、常時フル稼働の必要がない保守フェーズでも、必要な体制を保ちながらランニングコストを抑えられます。

「成果物」ではなく「稼働」に支払う構造

ラボ型契約は、稼働に対して支払う仕組みです。チームを確保した時点で月額費用が決まる一方、請負では作ったものが完成したあとに対価が確定します。

運用中は、事前に作業量を見積もれない作業も出てきます。そのため保守・運用では、システムを継続的に手入れする体制に対価を払う考え方が合います。

  • 突発的な障害対応:発生時の調査と復旧です。
  • 緊急のセキュリティパッチ適用:必要な更新に対応します。
  • 問い合わせを受けた調査:ユーザーからの連絡をもとに原因を調べます。

ラボ型契約なら、確保したチームが優先順位に応じて、こうした予測しにくい保守作業に対応できます。月額枠の範囲内であれば、追加の見積もりなしで動き始められます。

一方、請負ベースの保守では、作業ごとに見積もりと発注を繰り返します。その結果、緊急対応が遅れたり、追加費用がかさんだりすることがあります。

ラボ型契約の保守・運用費用は、必要なときにすぐ動ける専属体制を月額で確保するための費用と捉えられます。稼働に対する支払いは、先の読みにくい保守・運用と相性がよい仕組みです。

ポイント

複数社の月額を比べるときは、人数・人月単価・契約期間を揃えてから見ます。稼働の少ない月も費用は変わらないため、空き時間の使い道を先に決めておくことが判断の材料になります。

保守・運用をラボ型契約に含めるメリット

保守だけを切り出すより、開発と保守を同じ専属チームに含めるほうが、費用効率と品質の両面で利点があります。稼働に対して支払う構造を生かせるからです。

この契約なら、開発の空き時間を保守に回せます。同じチームが続けて担当すれば、知識も引き継げて、月額固定費を有効に使えます。

開発の空き時間を保守・QAに充てる使い方

ラボ型契約では、エンジニアに空き時間が生じても月額費用は発生します。そこで保守・運用をラボ枠に含めておけば、その時間を活用できます。

新規機能のタスクが一時的に途切れたときには、次のような仕事にチームを充てられます。

  • 既存システムの保守:稼働中のシステムを維持し続けます。
  • テスト(QA)の拡充:品質確認を厚くします。
  • 技術的負債の解消:積み残してきた課題を片づけます。
  • セキュリティ監査:システムの安全性を点検します。
  • ドキュメント整備:必要な資料を揃えます。

同じ月額費用でも、保守を含めればより多くの価値を得られます。開発だけの契約では、タスクが途切れると費用が無駄になります。一方で、その時間を保守に充てれば、システムの健全性向上につながります。

リリース直後は新機能の開発に集中し、落ち着いたあとは保守・改善・QAに比重を移せます。開発と保守を同じ枠で柔軟に切り替えれば、費用対効果を高められます。

月額費用は一定に保ったまま、需要に応じてチームの稼働を配分できます。保守の繁閑に合わせて契約を結び直す手間もかからず、常に一定の体制でシステムを見てもらえます。

同一チームによる知識継承とコストの抑制

開発時の知識が保たれるかどうかは、引き継ぎの負担や改修の品質を左右します。同じチームに任せれば、その知識は途切れにくくなります。

  • 引き継ぎ工数:同じチームなら、引き継ぎに費やす時間が少なく済みます。
  • 保守の効率:引き継ぎが少ない分、障害対応も速まり、長期的な総費用も抑えられます。
  • 改修と改善:影響範囲を見極めやすく、機能追加の品質も高まります。
  • ロックイン対策:要件定義や設計の経緯を文書に残し、特定の開発会社への依存を避けます。

請負契約では、納品後にチームが解散し、別のチームや会社が保守を引き継ぐことがあります。その際、設計思想や「なぜこの作りにしたか」という背景知識(暗黙知)が伝わらないと、既存コードの把握に工数がかかります。

把握に時間がかかると、保守コストが上がり、対応の遅れや不具合の見落としにつながります。一方で、同じチームへの長期依存にはベンダーロックインのリスクもあるため、任せる範囲を発注側も意識しておく必要があります。

ポイント

開発と保守を同じチームに任せるかは、保守の作業量が月ごとにどれだけ変わるかで判断します。作業量が少ない月が続くなら、契約の月額と照らして負担を確かめておくとよいでしょう。

請負の保守契約とのコスト構造の違い

ラボ型契約と請負ベースの保守を、稼働時間への課金と対応範囲への責任で比べた図。
契約形態によって、費用と責任の置き方が分かれます。

ラボ型契約(準委任)の保守と請負契約の保守では、コスト構造が異なります。どちらが安いかは一概には言えず、システムの性質や作業量、予測のしやすさによって、適した形態が変わります。

請負は対応範囲に責任を持ち、ラボ型契約は稼働時間に課金します。そのため、責任範囲と費用の関係を比べて、自社に合う保守形態を判断することになります。

「稼働に課金」と「対応範囲に責任」の違い

請負ベースの保守では、月額料金と対応範囲をあらかじめ定めます。たとえば、月額料金の中でバグ修正と軽微な改修を行い、大きな機能追加は別途見積もる形です。

開発会社は契約範囲に責任を負い、その範囲内であれば、作業量にかかわらず定額で対応します。発注側から見ると、範囲内は確実に見てもらえる一方、範囲外は追加費用がかかり、その都度交渉が必要になります。

請負ベースの保守料金は、一般に開発費の10〜20%程度を年額とします。月額に換算すると、小〜中規模システムで数万円〜十数万円程度が目安です。

ラボ型契約の保守は、対応範囲ではなく、確保したチームの稼働時間に課金します。優先順位に応じて柔軟に対応しますが、完成の保証はありません。

準委任契約では、開発会社は善管注意義務を負います。なお、契約不適合責任は負わないのが原則です。

  • ラボ型契約:稼働時間に課金するため、作業量が読みにくい場合でも柔軟に対応できます。
  • 請負ベース:対応範囲に責任を持つため、範囲を明確にして予算を固定したい場合に適しています。

ランニングコストにおける人の稼働費と環境維持費の切り分け

ランニングコストでは、人の稼働費とシステム環境の維持費を分けて把握します。ラボ型契約の月額費用は、このうちエンジニアチームの稼働費にあたります。

インフラ費用やライセンス費用は、原則として別途発生します。環境維持費には、次のようなものがあります。

  • クラウドサーバー利用料:多くは利用量に応じた従量課金です。
  • SaaS・ライブラリのライセンス料:各種サービスやライブラリの利用にかかります。
  • ドメイン・SSL証明書:システムを運用するうえで必要になります。
  • 監視・エラートラッキング:各種ツールやサービスの利用料です。

これらは、開発会社への支払いとは別に、発注企業が直接負担するのが一般的です。近年は、生成AIのAPI利用料など、利用量で変わる費用も増えています。

最新の料金体系は契約内容によって変わるため、個別に確かめておく必要があります。利用量が増えると費用も上がるので、上限や予算アラートを設けておくと、費用の膨らみに早く気づけます。

人の稼働費(月額固定)と環境維持費(変動・従量)は分けて考え、それぞれの負担者を契約で明確にしておきます。両者を混同すると、月額を払っているのに別途請求が来るという認識の違いが生じます。

ポイント

保守の契約形態は、作業量の予測しやすさで選びます。予測しにくい保守が中心なら稼働ベースが、範囲を決めて予算を固定したいなら請負ベースが合います。

閑散期のコストリスクと最適化

閑散期の固定費負担を抑える方法として、シェアードアサイン、体制の調整、業務幅の拡張、契約条件の工夫を並べた図。
空き稼働の活用と契約条件の調整を組み合わせて考えられます。

保守作業が少ない閑散期は、ラボ型契約における大きなコストリスクです。保守案件が減っても、確保した専属チームの固定費は発生し続けます。

契約期間の途中では解約が難しいため、発注量が少なくても費用は続きます。そこで、契約条件の工夫やシェアードアサイン、業務幅の拡張によって、負担を抑えていくことになります。

発注量が減った時の固定費負担

閑散期の費用負担は、契約上どこまで調整できるかによって変わります。固定費の内容と見直し方を、契約の段階で確かめておくことが大切です。

  • 月額固定費:稼働が少なくても、確保したチームの費用は契約どおり発生します。
  • 請負との比較:請負の保守なら、対応がない月は定額の保守料金だけで済む場合もあります。
  • 解約条件:中途解約の通知期間と違約金の有無を、契約時に確かめておきます。
  • 体制の調整:契約中の人数変更や、更新時のチーム規模・人月単価の見直し方法です。
  • 縮小方法:需要減に備えて、どこまで体制を絞るかを契約に定めておくことが、固定費リスクを抑える確実な策です。

保守作業の量の増減が大きい場合や、安定稼働して手がかからない場合は、固定費がコスト効率を下げることがあります。

シェアードアサインと業務幅の拡張による費用抑制

需要に応じて稼働を調整する方法の一つが、シェアードアサインです。保守では高単価のPMやブリッジSEを専任にする必要が薄いため、他案件と掛け持ちにできます。

その際は、1ヶ月あたり0.2〜0.5人月のように、稼働率に応じて費用を按分します。これにより、必要な管理体制と窓口を保ったまま、固定費を圧縮できます。

エンジニアの人数も、契約条項の許す範囲で調整できます。繁忙期には増員し、閑散期には最小限に絞ることで、稼働率を保てます。

もう一つの方法は、保守が少ない時期に業務の幅を広げることです。将来への投資となる仕事に、チームを充てます。

  • テストの自動化:繰り返しのテスト作業を、自動で回せるようにします。
  • 技術的負債の返済:既存システムに溜まった課題を解消します。
  • セキュリティ強化:システムの安全性を高めます。
  • ドキュメント整備:必要な資料を揃えます。
  • 次の機能開発の準備:将来の開発に向けて、必要な作業を進めます。

空き時間を改善に使えば、固定費をシステムの価値向上につなげられます。閑散期は、普段は手が回らない改善に投資する時期とも捉えられます。ただし、業務幅を広げるには、発注側がチームに意味のある仕事を用意し続ける必要があります。

ポイント

閑散期に備えて、契約期間と中途解約の条件を先に確かめておきます。縮小できる範囲を契約に書いておくと、発注が減ったときの判断が早まります。

まとめ

保守・運用費用とランニングコストは、月額固定・稼働ベースの構造から捉えると分かりやすくなります。月額は人数と人月単価で決まり、契約期間はその月額を払う長さとして総額を左右します。

開発と保守を同じ専属チームに任せれば、空き時間を保守やQAに充てられます。さらに、同一チームが知識を保つことで、長期的な保守コストも抑えられます。

請負ベースとの違いは、稼働に課金するか、対応範囲に責任を持つかにあります。ただし、安定稼働して作業が少ないシステムでは、請負のほうが効率的な場合もあります。

人の稼働費と環境維持費を分けて管理し、クラウドの従量課金やライセンス料も把握しておきます。閑散期の固定費には、シェアードアサインや業務幅の拡張、契約上の人数調整で備えられます。

これらの費用構造と契約上の注意点を踏まえ、自社のシステムに合う形態かを見極めてください。そのうえで、信頼できる開発パートナーに相談することをお勧めします。

▼全体ガイドの記事
・ラボ型契約の完全ガイド

会社紹介

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

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

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

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

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

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