現代の基幹システムの課題とは？開発の外注プロセスも解説

「システム活用が手遅れになった状態で、これからの競争は生き残れない」

現在、データはあらゆる産業で利用されています。その重要度は、インターネット黎明期と比べ物にならないほど跳ね上がり、競争力において勝敗のカギを握るまでに至りました。データが集まるシステムを有効活用できないと、「市場の変化に付いていけない」「保守費や運用費が高騰する」「トラブルに上手く対応できない」など、企業成長を鈍化させる要因にもなってしまうでしょう。

中でも事業遂行に欠かせない基幹システムは問題視されており、2000年問題の対応時に導入以降、リプレイスされていないシステムが数多く存在します。そのままシステムを放置し続ければ、企業の可能性を狭めることにもなりかねません。

本コラムでは、長年使われる基幹システムの問題点や外注プロセス、注意すべきポイントをお伝えします。

基幹システムとは？

基幹システムは、業務や事業における重要な情報を管理するシステム全般を指します。一般的には人事・会計・販売・生産・物流などの管理システムが含まれます。基幹システムが止まってしまうと、企業活動も止まってしまうため、企業を維持するうえで欠かせないシステムといえるでしょう。

ERPとの違い

同一視されやすいERP（Enterprise Resource Planning）は企業資源計画と訳され、ヒト・モノ・カネ・情報を一元管理するための統合基幹業務システムです。それぞれが独立したシステムとして運用される基幹システムとは異なり、複数のシステムが統合されたパッケージ製品になります。

両システムの決定的な違いは利用目的です。基幹システムが業務や事業のために利用されるのに対し、ERPは経営におけるリソース把握や戦略立案のために使われます。特定業務の効率アップを図る基幹システム、経営基盤を強化するERPと切り分けることができます。

基幹システムの昨今の事情

経済産業省のDXレポートによると、何らかのレガシーシステムを持つ企業は85.6％。数あるシステムの中で、レガシー化した基幹システムは2割にあたります。

 

レガシー化した基幹システムの割合は、DXレポート内でも増加傾向にあり、2025年には導入から21年を超える基幹システムは6割にも及ぶと想定されています。

そのような問題が大きく広まるきっかけとなったのが、経済産業省が警鐘を鳴らした2025年の崖です。複雑化・老朽化・ブラックボックス化したシステムが残り続けた場合、2025年以降、年間で最大12兆円の経済損失が出る可能性を示しています。また、SAP 2025年問題によるERPパッケージの保守サポート終了（現在は2027年まで延長）も大きな問題とされています。

古くなった基幹システムは、早期に刷新したほうが良いでしょう。しかし、「基幹システムは当たり前の動きをしているだけで、わざわざ再構築しなくとも延命処置で事足りないか」という意見が社内で出ることもあるのではないでしょうか。では、複雑化・老朽化・ブラックボックス化したシステムには、どのような問題があるのかを確認してみましょう。

複雑化

システムが複雑化する大きな原因は、世の中のニーズが多様化している点にあります。それに対応すべく、何度も新しい機能を継ぎ足してアナログ業務を無理やりシステム化することによって、システムがますます複雑になっていくのです。また、従業員が既存システムの操作に慣れていて、変更をかけると業務に支障が出てしまうため、外部に補完機能を追加するケースもあります。

複雑化が引き起こす問題

• 機能が枝分かれしていて扱うのが難しい
• 似たプログラムが複数あって判別できない
• 部署ごとに蓄積したデータが連携できない

複雑化したシステムは解明が困難であり、重要な問題が顕在化するまで放置されることもあります。

老朽化

システムは導入当時の技術で作られており、長期的に使われている場合、開発言語などが時代の主流とマッチしない可能性が高まります。古い技術に対して、機能は何度も継ぎ足されているため、サーバーが負荷に耐えられないことも出てくるでしょう。また、世の中が新しい技術に置き換わっていく関係で、メンテナンスできる従業員が減っていき、結果的に維持費の高騰にもつながります。

老朽化が引き起こす問題

• システムが意図せずダウンする
• 故障した場合の代替がきかない
• 古い技術に対応できるエンジニアが確保できない

老朽化したシステムは対応の難易度が年々上がっていくため、システムの維持にかかるコストは着実に増えていくでしょう。

ブラックボックス化

複雑化や老朽化によって、運用・保守は属人的になっていきます。基幹システムの保守は少人数で担当している場合が多く、担当者が異動や退職でいなくなると、管理方法やカスタマイズの経緯が分からなくなり、一気に維持管理ができない状態に陥るリスクもあるでしょう。また、引き継ぎも回を重ねるほど、共有不足などのミスが起きやすくなります。

ブラックボックス化が引き起こす問題

• システム復旧に大幅な時間をとられる
• トラブルが起きても対応できるエンジニアが社内にいない
• ヘルプデスク業務に追われてシステム企画などの動きができない
• システム拡張が一向に進まず、人件費が通常以上に膨れ上がっている

ベンダーに依存してしまうと社内にノウハウを蓄積しにくいため、DXとの兼ね合いを考慮したうえで、内製化を選ぶ企業も増えてきています。

古い基幹システムは、操作の難しさ、維持費の高さ、技術の属人化などによって、企業のデジタル競争力を削いでいくことが懸念されます。だからこそ、これからの競争を生き抜くには、レガシーシステムから脱却し、時代に即した基幹システムの導入・開発が重要となるでしょう。

基幹システムの外注プロセス

システムを内製する傾向が出ているとはいえ、「絶対的に内製を選ぶべき」というわけではありません。動かすプロジェクト数や人的リソースによっては、無理して内製を選ぶよりも、外注でこれまでのプロセスを見直すことに注力したほうが、よりリスクを抑えられる可能性があります。

ここではシステムを外注するうえでのプロセスと、注意すべきポイントをご紹介します。

①システム開発の種類を選ぶ

システム開発には汎用系・オープン系・web系の３種類があります。

汎用系

汎用コンピュータを使ったシステム開発です。通常のコンピュータでは行えないほどの膨大なデータの高速処理や機密性の高いデータを扱う場合に選ばれます。金融の勘定系システム、メーカーの生産管理システムなどで採用されるケースがあります。

オープン系

OS、レンタルサーバー、周辺機器などを組み合わせて行うシステム開発です。汎用機レベルの高速処理が必要ない場合は、オープン系のほうがコストを抑えられるでしょう。受発注・顧客・在庫などの情報を管理する業務系アプリケーションの開発に採用されるケースがあります。

web系

パソコン・スマートフォンでの利用を想定し、ブラウザやモバイルアプリでの動作を前提としたシステム開発です。外出先でのデータ確認が必要な場合や、勤怠管理などのweb上で完結できるシステムの開発に採用されるケースがあります。クラウドサービスを利用することで、自社でサーバーを持たないという選択も可能です。

②開発手法を決める

システムを開発するうえでの手法は、主にフルスクラッチとカスタマイズの選択肢があります。

フルスクラッチ

企業の業務を細かく分析し、ゼロからオーダーメイドで開発する手法です。独自性の高い業務がある場合などに選ばれます。初期費用の高さがデメリットではありますが、雛型を使わないことでカスタマイズの制約がなく、従業員の使いやすさも考慮するなど、柔軟な開発が可能です。

カスタマイズ

既存のパッケージ製品を、より企業に合うようにカスタマイズする手法です。定額制のものが多いため、複雑な業務を行わない場合だけでなく、初期費用を抑えたい場合にも選ばれます。また、基幹システムの寿命を考慮し、再構築の負担軽減として選択肢に入ることもあるでしょう。フルスクラッチと比べて機能の拡張性には限界がありますが、近年では話題のSaaS型が登場し、バリエーションも豊富になっています。

③要件定義を進める

予算やスケジュールに加え、システム開発には業務の現状理解が重要になります。要件定義では社内で必要な情報を整理し、ベンダーとの打ち合わせの中で必要な機能を決めていきます。

特に現場ヒアリングは重要であり、実際にシステムを扱う従業員から、「どのようなフローで業務を進めているのか」「どのような部分に課題を感じているか」といった情報を吸い上げ、達成すべき目標を明確にすることで、ベンダーとの意思疎通がスムーズになります。

④開発（ベンダー選定）

開発を依頼するベンダーの選定は、見積もりの金額や開発スピードだけでなく、目標に対する提案が妥当か、機能は適切に網羅されているか、将来的な拡張性や運用面が考慮されているかなども基準となります。また、プロジェクトの進捗や品質の追いやすさを考えても、連携が取りやすいベンダーを選ぶこともポイントです。

⑤テスト

プログラミング完了後は、テスト環境で正常に動くかどうか、使いにくいと感じる点がないかをチェックし、問題があれば修正を行います。

近年は、開発時間の短縮やリスクの低減を目的としたアジャイル開発が増えてきているため、プログラム単位での単体テストやプログラム全体の動作検証する結合テスト、発注要求を満たしているか最終チェックする総合テストといった段階的なテストを行うこともあります。

⑥運用保守

システムは完成後にも定期的なメンテナンスや改修を行っていく必要があります。データを蓄積するうちに処理速度が落ちる、アクセス数が増えすぎてシステムの動きが止まる、新しい業務に対応する機能がないなど、完成後のトラブル解消や追加要望の実現を踏まえて、計画を立てていくことを心がけましょう。

人材選びがキーポイント

前述したシステムを外注する際のプロセスには、複数のエンジニアが関わってきます。また、内製化する際でもエンジニア＝社内SEと一括りにされがちですが、実は幅広い業務があることをご存じでしょうか。プロセスごとに担当も異なるため、内製化を検討するには、エンジニアの業務を具体的に理解する必要があるでしょう。ここでは重要なセクションに関わるエンジニアの業務をそれぞれご説明します。

システムエンジニア（SE）

要件定義・基本設計・詳細設計などの上流工程を担当するエンジニアです。顧客の要求を整理し、システムの仕様を決め、開発チームとのパイプ役も務めます。プログラマを経験している場合が多く、システムの知識やプログラミング技術も豊富に持っています。

インフラエンジニア

ネットワーク、サーバー、データベース、セキュリティの設計・構築・運用を担当するポジションです。システムの運用にはこれらが欠かせず、日々これらを監視し、問題発生時には原因を特定・解消するトラブルシューティングまで行います。

プロジェクトマネージャー（PM）

プロジェクトを統括するポジションです。予算や工数から計画を立て、開発チームを編成し、プロジェクトの進捗・品質の管理や評価を行います。

発注側では、ベンダーに依存しがちな体質から脱却し、システムのブラックボックス化を予防することが可能です。PMの存在は社内にノウハウを蓄積し、将来的なDX推進に活かせる体制づくりにも役立てるでしょう。

企業ごとに人員状況が異なるため、プロジェクトを円滑に進めるうえでどのようなエンジニアが必要なのかを知り、求められるスキルを考慮したうえでのチームづくりが大切です。

ジョブ型雇用が進む中でのエンジニア活用法

基幹システムの長期使用には、複雑化・老朽化・ブラックボックス化といった問題が生まれ、さまざまなトラブルのきっかけになります。再構築の手段としては内製・外注の2種類で、プロジェクト数や人的リソースに応じて選択すると良いでしょう。

システム開発を外注した場合に注意すべきポイントは、社内にノウハウを蓄積していくことです。ベンダーに頼り切ってしまうと、社内にシステムの全貌を知る者がおらず、結果的にブラックボックス化してしまいます。

しかし、ノウハウを蓄積するにはエンジニアの存在が不可欠です。エンジニアは転職市場にて売り手扱いとなっているので、優秀な人材と出会うのは中々簡単なことではありません。昨今耳にする、ジョブ型雇用という考え方が今後ますます広がると、雇用に限らない方法を採用するなどのように、エンジニアとの関わり方も見直す必要が出てくるでしょう。

フリーランスITエンジニア専門エージェント「HiPro Tech」では、前述したエンジニアに加えて、様々な分野のスキルを有するITフリーランサーが活躍しています。

 

当サービスは専門スキルを有するITフリーランサーの活用によって、開発体制の内製化や強化など、社内の開発リソース不足の解決を支援することができます。

社内にノウハウを蓄積し、デジタル改革成功を目指すための足掛かりとして、ぜひ当サービスをご検討ください。