IT企業の利益改善は制約理論で進める｜受託・SaaSの実践法

案件は増えているのに、利益が残らない。
採用しても責任者や一部のエンジニアに業務が集中する。
この状態に悩む中小IT企業は少なくありません。
原因は、個人の頑張りや技術力だけでは説明できない場合があります。

IT企業の利益改善は、仕事の流れを止めている工程を見つけ、その工程に合わせて営業・開発・運用を整えることが基本です。
本記事では、制約理論を受託開発、SaaS、システム保守の現場に当てはめる方法を解説します。

IT企業が忙しいのに利益が残らない理由

案件が途切れず、メンバーも残業しているのに利益が伸びない場合、仕事量そのものよりも仕事の詰まり方を確認する必要があります。
開発案件は、営業、要件定義、設計、実装、レビュー、テスト、納品、請求と流れます。
一つでも待ち時間が長い工程があると、後工程の人員を増やしても案件全体は早く進みません。

忙しいのに利益が残らない状態は、売上不足ではなく、制約工程の前後に作業と待ち時間が滞留している状態です。
たとえば、代表者しか見積もりを承認できない会社では、開発者が空いていても受注開始が遅れます。
技術責任者しか設計レビューをできない会社では、実装が終わっても次の案件に進めません。

中小IT企業では、特定の人に判断が集中しやすい点が特徴です。
少人数で品質を守ってきた結果、案件の入口や出口を一人が握ることがあります。
この状態で採用だけを先に進めると、新しい人の教育や確認も制約担当者に集まり、かえって停滞することがあります。

まず、直近の受託案件または保守案件を3件選びます。
各案件について、担当者が実作業した日と、誰かの返答を待った日を分けて書き出してください。
厳密な工数管理表がなくても、カレンダー、チャット、チケット履歴からおおよそ確認できます。

• 商談開始から契約までで、最も長く待った確認を記録する
• 開発開始から納品までで、差し戻しが多い工程を記録する
• 保守対応で、同じ担当者に集中する判断や承認を記録する
• 月末請求で、情報不足により確認が発生した案件を記録する

ここで探すべきなのは、最も忙しい人ではありません。
案件全体を次へ進められない状態を作っている工程です。
制約が見えれば、値上げ、採用、AI導入といった施策も、優先順位を誤りにくくなります。

制約理論とは何か｜中小IT企業向けの使い方

制約理論は、全体の成果を最も遅い工程から考えるフレームワークです。
製造業で知られる考え方ですが、人と情報が流れるIT企業にも使えます。
開発の速さだけでなく、案件化、顧客との合意、品質確認、運用引き継ぎまでを一つの流れとして扱う点に特徴があります。

制約理論では、制約を見つけ、制約を止めず、ほかの工程を制約に合わせ、最後に制約そのものを強化します。
いきなり全社改革をする必要はありません。
一つのサービス、一つのチーム、一つの案件群に絞って試せます。

中小IT企業向けには、次の4段階に簡略化すると運用しやすくなります。

• 制約を見つける：案件が最も長く止まる工程を、事実で確認する
• 制約を守る：制約担当者が、優先度の低い会議や割り込みで止まらないようにする
• 前後を合わせる：制約の処理量を超える仕事を、前工程で抱え込みすぎないようにする
• 制約を強化する：標準化、権限移譲、外部活用、AI支援で処理能力を上げる

たとえば、設計レビューが制約なら、全エンジニアに生成AIを導入することが最優先とは限りません。
先に、レビュー観点のテンプレート、確認済み設計の事例、レビュー前のセルフチェックを整えます。
責任者が判断すべき論点だけを残せば、同じ時間でも確認できる案件数が変わります。

一方で、制約工程を無理に高速化して品質を落とすと、手戻りが増えます。
制約理論は、単に急ぐ方法ではありません。
利益を生む案件の流れを、品質を保ちながら安定させる方法です。
改善前後は、売上だけでなく、案件の滞留日数、手戻り回数、責任者の確認時間も見比べてください。

受託開発の制約を見つけて単価改善につなげる

受託開発では、開発工程より前の要件整理や見積もりが制約になることがあります。
顧客の要望を十分に整理しないまま受注すると、開発中の確認、仕様変更、追加要望が増えます。
その結果、見かけ上は案件数が多くても、予定外工数が利益を削ります。

受託開発の単価改善は、価格表を変える前に、無償で引き受けている判断と調整を見える化することから始めます。
特に、営業担当が受注時に約束した内容と、開発チームが実際に対応した内容の差を確認してください。
この差が大きい会社では、単価交渉よりも受注条件の整備が先になります。

案件ごとに、受注金額だけではなく、利益を止める要因を分類します。
分類は細かくしすぎないことが大切です。
最初は次の4区分で十分です。

• 要件不足：顧客の目的、対象範囲、決定者が決まらないまま開始した
• 変更管理不足：追加要望を契約範囲と分けずに対応した
• レビュー集中：責任者や顧客の確認待ちで作業が止まった
• 引き継ぎ不足：営業から開発、開発から保守への情報が不足した

たとえば要件定義が制約なら、提案段階で「画面数」だけを見積もる運用を見直します。
対象業務、利用者、例外処理、外部連携、顧客側の確認担当を、契約前に確認する項目へ加えます。
情報を増やすことが目的ではありません。
開発開始後にしか判断できない事項を減らすことが目的です。

顧客との関係を損なわずに単価を見直すには、作業時間の請求ではなく、判断の区切りを明確にします。
たとえば、調査、要件定義、基本設計、追加変更を別の合意単位にします。
中小IT企業の値上げは、一律の単価改定より、追加対応を曖昧にしない契約と運用で実現しやすくなります。

見積もりや要件定義の標準化には、過去案件の検索環境も役立ちます。
社内資料を安全に参照するRAGの考え方は、「社内ナレッジをRAGで検索可能にする実装ステップ｜https://strategy-design.jp/blog/internal-knowledge-rag-search-implementation/」でも解説しています。

SaaS・保守の利益率を制約理論で見直す方法

SaaSやシステム保守では、売上が継続するため、個別対応の負担が見えにくくなります。
問い合わせに丁寧に対応しているうちに、特定顧客向けの設定変更、データ修正、操作説明が増えることがあります。
契約が続いていても、対応時間が増え続ければ利益率は下がります。

SaaSと保守の利益改善では、問い合わせ件数よりも、同じ原因で人の判断が何度必要になったかを追うことが重要です。
問い合わせが多くても、ヘルプページや画面改善で解消できるものがあります。
一方、毎回個別確認が必要な依頼は、業務設計や契約条件に制約がある可能性を示します。

まず、直近1か月の問い合わせや保守依頼を、内容ではなく対応の型で仕分けします。
顧客名ごとの集計だけでは、製品や運用に共通する問題を見落とします。

• 操作案内：利用者が自力で解決できる情報が不足している
• 設定変更：標準機能で吸収できず、個別作業が必要になっている
• 障害調査：監視や一次切り分けの情報が不足している
• データ修正：入力ルールや権限設定に問題がある
• 判断依頼：顧客と自社の責任分担が曖昧になっている

制約がサポート責任者なら、最初に採用を急ぐ前に、一次回答を分けます。
問い合わせフォームに必要情報を追加し、定型回答を整え、緊急度の判断基準を決めます。
AIを使う場合も、回答を自動化すること自体が目的ではありません。
担当者が確認すべき案件だけに集中できるようにすることが目的です。

AIエージェントは、定型的な情報収集や社内確認の補助に使えます。
ただし、顧客への回答や権限変更を任せる範囲は慎重に決める必要があります。
AI活用は、制約担当者の判断を代替する前に、判断前の情報収集と記録を整える用途から始めると進めやすいです。
実装の考え方は「AIエージェント業務組み込みの設計図｜https://strategy-design.jp/blog/ai-agent-workflow-implementation-smb/」も参考になります。

お盆前後に行う下半期の制約改善アクション

お盆前後は、顧客や協力会社の稼働が変わり、通常より案件が進みにくい時期があります。
一方で、開発チームの予定を調整しやすい会社では、日常業務に埋もれがちな採算確認や標準化を進める機会にもなります。
無理に大きな改革を始める必要はありません。

下半期の改善では、制約を一つに絞り、90日間で変える運用を決めると実行に移しやすくなります。
「生産性を上げる」といった目標では、現場が何を優先すべきか分かりません。
「見積もり承認を週内に完了する」「レビュー前の確認漏れを減らす」のように、工程で表現します。

経営者、営業責任者、開発責任者が60分程度集まり、次の順で確認してください。
会議では印象ではなく、直近案件の事実を材料にします。

• 直近3件の案件で、最も長い待ち時間があった工程を確認する
• その工程に、誰の判断とどの情報が必要だったかを確認する
• 制約担当者が今後90日で減らせる定型作業を一つ決める
• 前工程が抱え込む仕事量を、週単位で調整する方法を決める
• 月1回、滞留日数と手戻りの理由を確認する場を予定に入れる

数字は増やしすぎないでください。
経営会議で見る数字は、案件別の粗利見込み、進行中案件数、制約工程の滞留日数の3つから始められます。
粗利見込みは、受注金額から外注費と想定工数を差し引く簡易的な把握でも構いません。
大切なのは、完了後ではなく進行中に赤字化の兆候を捉えることです。

改善に必要なツール導入や開発を検討する場合は、補助金が使える可能性もあります。
ただし、対象経費や申請時期、事業計画の要件は公募ごとに異なります。
補助金は導入目的を決めた後に検討し、最新の公募要領で必ず確認してください。
IT企業自身が提供側になる場合も、顧客への説明に制度を使う場合も、採択を前提に投資判断をしない姿勢が必要です。

よくある質問

あわせて読みたい

• 社内ナレッジをRAGで検索可能にする実装ステップ — レビューや調査の滞留削減に役立つ
• AIエージェント業務組み込みの設計図 — 制約工程の周辺業務を補助できる
• 中小企業のAI導入、何から始める？進め方と成功のポイント — AI導入の優先順位づけに関連する