IT人材不足のフルスクラッチ・オーダーメイド開発について

人材不足の時代にフルスクラッチ開発を選ぶなら、まず標準化を優先し、Fit&Gap分析で独自に作る範囲をコア領域に絞るのが基本です。限られた人材を、競争力に直結する部分に集中させられます。

全体像は、下のIT人材不足の完全ガイドでも確認できます。

▼全体ガイドの記事
・IT人材不足の完全ガイド

人材不足時代のフルスクラッチの是非

標準仕様への適合、必要箇所の独自開発、保守の担い手を示す3枚のカード図。
標準化と独自開発を分けると、限られた人材の役割が見えます。

IT人材が潤沢な時代は、自社の要望を盛り込むフルスクラッチも現実的でした。一方で、人材不足が常態化した今は、すべてを独自に作る必要があるかを問い直すことが欠かせません。そのうえで、人材を価値の高い領域に集中させるため、スマートIT分業の観点から、作り込む範囲と標準に委ねる範囲を分けて考えます。

「標準化優先」の原則と、安易なフルスクラッチの回避

独自の仕組みを増やすほど複雑になり、保守の負担が膨らみます。そのため、まずパッケージやSaaSを優先し、安易なフルスクラッチは避けます。

経済産業省のDXレポートでも、標準化優先が示されています。限られたIT人材で持続可能なシステムを維持するためです。

  • 業務を標準仕様に寄せる:現行業務をそのまま独自に再現せず、標準化を検討する
  • 必要な部分だけ独自開発:標準で対応できない箇所に限って作り込む
  • 保守の担い手を確保する:標準品の保守や更新は提供側に委ねる

独自に作り込む部分が増えるほど、保守に必要な専門人材も増え、その確保が難しくなります。一方で、標準的なパッケージやSaaSなら、提供側が保守・更新を担うため、自社の人材を他の業務に振り向けられます。

「自社の業務は特殊だから独自開発しかない」と決める前に、独自性が競争力に直結する部分を見極めます。

Fit&Gap分析によるコア領域と非コア領域の切り分け

すべての業務をパッケージやSaaSに置き換えられるとは限りません。たとえば、競争力の源泉となる独自のプロセスは、標準品では再現できない場合があります。

Fit&Gap分析は、自社の業務要件と製品の標準仕様を照らし合わせ、合う点と合わない点(ギャップ)を洗い出す手法です。そのうえで、システムをコアと非コアに分けます。

  • 非コア領域:標準仕様に業務を寄せられる部分
  • コア領域:自社の強みとして独自に作る付加価値の部分
  • 内部人材の役割:コア領域やDX推進などの戦略的な取り組みに集中する

非コア業務や標準的な運用・保守は、SaaSや外部パートナーに委ねます。こうした分業を「スマートIT分業」と呼びます。

独自開発と標準品を組み合わせて考えるのが現実的です。限られた人材を活かすため、フルスクラッチはコア領域に限ります。さらに、この切り分けは、開発と保守の負担の大きさも左右します。

ポイント

標準品で足りる業務は標準仕様に寄せ、独自に作るのはFit&Gap分析でコア領域と判定された部分に絞ります。判断に迷うときは、その部分が競争力に直結するかを基準にします。

フルスクラッチの重さと現実的なリスク

初期開発費、年間保守費、既存システムの維持・運営費、将来の保守点検割合を数値付きパネルで示す図。
開発時の支出に加え、運用後も予算を占める負担が続きます。

フルスクラッチ開発を検討するなら、その「重さ」を正しく理解しておく必要があります。重さは開発時だけでなく、リリース後の長期的な保守・運用の負担としても続きます。特に人材不足の時代には、費用面の重さと、属人化による「2025年の崖」の再生産が大きなリスクになります。

IT予算を圧迫する開発・保守コストの重さ

ゼロから設計・構築するフルスクラッチでは、必要な人材も、期間も、費用も大きくなります。

  • 初期の開発費:業務システムは規模により数百万円から数千万円、大規模なら億単位に達する場合もある
  • 継続する保守費:年間費用は開発費の10〜20%程度が一般的

ここで示した開発費の相場感は、一般的な知識に基づく補足です。

独自システムでは、開発が終わったあとも保守や改修の負荷が続きます。本当の負担は、リリース後に始まるといえます。また、国内企業のIT関連費用の約80%は、既存システムの維持・運営に使われています。

経済産業省は、独自システムの構築・維持を続けると、将来はIT予算の9割以上を保守点検に割くリスクを指摘しています。保守だけで予算が尽きると、新しい価値を生む投資に回せなくなります。こうした状況で安易に独自開発を選ぶと、人材不足の時代に企業の成長余力を損なうおそれがあります。

属人化が招く「2025年の崖」の再生産

フルスクラッチでは、属人化やブラックボックス化も深刻なリスクになります。複雑な独自システムは特定の担当者しか理解できない状態になりがちです。加えて、設計書が不十分だと、異動や退職のあとに保守できなくなる場合があります。

レガシーシステムも、かつては最新の独自システムでした。ところが、ベテランの高齢化や退職でブラックボックス化し、手がつけられなくなった例があります。これが「2025年の崖」を生んだ構造です。

今フルスクラッチで作れば、十数年後に「崖」を再生産するおそれがあります。さらに、将来の保守人材を確保できる保証もありません。

  • ドキュメント整備:設計書や関連資料を徹底して残す
  • 保守体制の設計:特定の個人に依存しない体制を最初から組み込む

そのため、開発の時点で、開発後に誰がどう維持するかまで見据えておく必要があります。上記の2つは、その備えの中身です。

ポイント

開発費だけでなく、リリース後の保守費も含めて負担を見積もります。属人化を防ぐには、設計書を残し、特定の個人に頼らない保守体制を最初から組むことです。

パッケージ・SaaSとの比較とハイブリッド戦略

開発手段の使い分けを中心に、フルスクラッチ、パッケージ、SaaS、ローコード・ノーコードの特性を示す注釈図。
汎用業務から独自性の高い領域まで、手段ごとに役割が異なります。

各手段の特性を比べ、領域ごとに使い分けることが現実的です。人材不足の時代に合うハイブリッド戦略も、この使い分けを土台に組み立てます。

フルスクラッチ・パッケージ・SaaS・ローコードの特性比較

手段ごとの特性を把握すると、業務に応じた使い分けを検討できます。

  • フルスクラッチ:自由度が高く要望を反映できる一方、費用・人材・保守の負担と属人化リスクが大きい
  • パッケージ:特定業務向けの製品を導入する。フルスクラッチより安く早いが、過剰な改修は保守負担を重くする
  • SaaS:月額利用のクラウドサービス。提供側が保守・更新を担い、自社で人材を抱えずに済むため、人材不足下と相性がよい
  • ローコード・ノーコード:コードをほとんど書かずに、専門人材が不足していても現場主導で開発できる

SaaSや業界共通の標準システムは、肥大化・複雑化したシステムを整理する際にも活用できます。こうした活用により、保守運用のコストと人手を大幅に抑えられます。

汎用業務にはSaaSやパッケージを、現場の小さな業務にはローコードを選びます。ただし、フルスクラッチを検討するのは、他社との差別化が必要なコア領域に限られます。

可視化・断捨離による段階的な刷新

刷新の機会に、全システムを一度に作り直したくなりがちです。しかし、人材不足のもとで同時に進めると、人手が尽き、各案件が中途半端になるおそれがあります。

無理のない刷新には、段階を踏んで進める方法が現実的です。

  1. 社内のITシステムを一覧にして、利用状況と重要度を確認する
  2. 使われていない機能や重複システムを廃棄し、保守対象から外す
  3. 汎用業務はSaaSへ移し、差別化が必要なコア領域は必要に応じて作り込む
  4. 優先順位をつけ、段階的に刷新する

この流れに沿って進めると、人材を計画的に配分できます。また、フルスクラッチを適用する範囲も、システム全体を見渡したうえで判断できます。刷新は、ポートフォリオを管理しながら継続して進めるものです。

ポイント

手段は領域ごとに使い分け、差別化が必要なコア領域に限ってフルスクラッチを検討します。刷新は、可視化と断捨離を経て段階的に進めます。

フルスクラッチを選ぶ場合の体制とAI活用

Fit&Gap分析で、競争力に直結するコア領域にはフルスクラッチが必要と判断されることもあります。そうした場合でも、人材不足を前提に体制と技術を整えれば、リスクを抑えられます。その鍵は、オフショアと内製コアを組み合わせ、生成AIで生産性を高める進め方です。

オフショア活用と内製コア確保のハイブリッド体制

国内だけでコア領域の人材を確保するのが難しい場合、オフショア開発(グローバル開発)が選択肢になります。たとえば、ベトナムなど海外の技術者プールを活用し、AIエンジニアやデータサイエンティストをチームに組み込めます。さらに、時差を活用すれば、24時間体制に近い開発でリードタイムを短縮できる場合もあります。

一方で、企画から開発までを外部に任せる「丸投げ(フルアウトソーシング)」は避けます。

  • 自社のコアメンバー:要件定義、アーキテクチャ設計、品質管理などの上流工程を担う
  • オフショアチーム:開発やテストなどの実装を担う

丸投げは、ベンダーロックイン、技術ノウハウの喪失、意思決定の遅れを招くおそれがあります。また、コア領域の独自性を自社で制御できなくなる点も問題です。

自社のコアは外部へ明け渡さず、頭脳は社内に残したうえで、実装を外部で補うことが成功の条件です。これにより、開発スピードと内製力を高められます。

生成AIによるフルスクラッチ開発の効率化

人材不足のもとでフルスクラッチを成功させるには、生成AIを活用して効率を上げます。特に、工数のかかる開発ほど、生産性向上の効果が表れます。

  • コーディング支援:GitHub Copilotなどで、コードを書く時間を最大50%削減できるデータがある
  • 課題完了時間:GitHubの実証実験では、参加開発者95名の課題完了時間が55%短縮した
  • テスト自動化:手作業のシステムテストをAIで自動化し、工数を90%削減した事例がある
  • 既存システムの解析:仕様書のないコードから設計書を作成したり、レガシー言語を書き換えたりできる

NTTデータグループは、航空券予約システムのJava 8からJava 17への更新事例を公表しています。全量約16,000ステップのうち、非互換となる約5%の修正に生成AIを活用しました。同社の説明では、手作業と比べて作業時間を大幅に減らし、高い生産性を実現したとのことです。

コア領域に絞ったうえで、AIとオフショアの体制を組み合わせれば、持続可能な独自システムを目指せます。

ポイント

フルスクラッチを選ぶなら、要件定義や設計などの上流は自社のコアメンバーが担い、実装はオフショアに任せることが成功条件です。そのうえで、生成AIで生産性を高めます。

まとめ

フルスクラッチ開発の判断は、人材不足という前提を外せません。2030年のIT人材不足は最大約79万人、レガシー放置による損失は2025年以降、年間最大12兆円と警告されています。

安易なフルスクラッチは開発と保守の負担を増やし、属人化によって「崖」を再生産するおそれがあります。基本は、標準化を優先し、Fit&Gap分析でコアと非コアを分けることです。そのうえで、非コアはSaaSや外部に委ね、内部人材をコア領域に集中させる「スマートIT分業」を検討します。

各手段の特性を踏まえたうえで、可視化と断捨離を進め、段階的に刷新する方法が現実的です。コア領域にフルスクラッチが必要なら、上流を内製し、実装をオフショアが担う体制を組みます。そこに生成AIによる生産性向上を合わせれば、人材不足のもとでも独自システムの構築を目指せます。

フルスクラッチは、その後も維持できるかが問われます。新規開発のあとも十数年にわたって誰が支えるのかに答えられるかが、賢明な判断の分かれ目です。

Fit&Gap分析で、独自性が競争力に直結する領域と標準品に委ねられる領域を洗い出すと、適用範囲を判断しやすくなります。なお、独自開発を検討する際は、領域の切り分けやハイブリッド体制の設計に知見を持つ開発パートナーへの相談も選択肢です。

▼全体ガイドの記事
・IT人材不足の完全ガイド

会社紹介

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

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

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

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

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

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