基幹システムのキホン：業務内容や構成・言語などなど
「基幹システム」という言葉を初めて聞くと、なんだか難しそうに感じるかもしれません。この記事では、細かい技術解説よりも「結局なに？」「どこで使うの？」「誰がどうやって作るの？」「止まるとどうなる？」「なぜ復旧に時間がかかる？」がイメージできるように、概要をまとめます。
基幹システムとは
基幹システムとは、会社の「中心となる仕事（業務）」を回すためのシステムです。多くの会社で共通しているのは、お金や物の流れに直結するところを支えている点です。
たとえば、受注・出荷・請求・入金・会計、在庫管理、購買（仕入れ）などが代表例です。これらは止まると売上が立たなかったり、出荷が止まったり、請求できなくなったりします。だからこそ「基幹（＝中心）」と呼ばれます。
Webサイトやスマホアプリと違い、派手な見た目や新機能よりも「間違えない」「数字が合う」「止めない」ことが価値になりやすいのも特徴です。
どこで使われている？
基幹システムは、製造業や卸売業、金融、物流、小売など「物やお金を大量に扱う業界」で特に重要になりがちです。ただし、どんな業界にも中心業務はあるので、形は違っても“基幹に相当する仕組み”はだいたい存在します。
業界によって「中心」が少し違う
- 金融：取引・残高・決済など（止まるとサービスが止まる）
- 卸売：受発注・在庫・物流・請求（止まると出荷できない）
- サービス業（制作・受託など）：案件・工数・請求・入金（止まると請求漏れや原価が分からない）
- 研究機関：予算・購買・資産管理（止まると研究費の執行や監査対応が詰まる）
つまり「基幹システム＝その業界で事業を回すための背骨」と考えると分かりやすいです。
実例：ニュースになるとき、何が止まった？
「基幹が止まる」と言われてもピンと来ない場合は、ニュースで“止まった内容”を見ると理解しやすいです。ここでは事件の詳細よりも、「どの業務が止まったか」という観点で短く紹介します。
- ランサムウェアによる出荷停止：ランサムウェア攻撃により国内グループ会社のシステム障害が発生し、注文・出荷などの業務に影響が出た旨を公表しています。
- システム障害によるATM停止：複数回のシステム障害が発生し、ATMなどのサービス停止につながった事例として金融当局が行政処分の理由等で言及しています。
ポイントは「サイトが見れない」だけでなく、受注・出荷・決済・問い合わせ対応など、事業の中心が止まるところまで波及しうる点です。
誰がどうやって作っている？
基幹システムは、1人で作るものではなく、いろいろな役割の人が分担して作ります。初心者向けにざっくり言うと、チーム戦です。
関わる人（ざっくり）
- 使う人（現場担当・キーユーザー）：業務の流れや例外を知っている
- まとめる人（PM/リーダー）：スケジュール、優先順位、関係者調整を回す
- 設計する人：画面やデータ、他システムとのつなぎ方を考える
- 作る人（開発・インフラ）：プログラムや設定を実装する
- 守る人（運用・保守）：監視、障害対応、復旧、改善を担当する
作り方（流れだけ）
- 業務を整理する（何を正しいルールにするか決める）
- 画面・帳票・データの形を決める（設計）
- 作ってテストする（実装・検証）
- 本番へ切り替える（移行・切替）
- 運用しながら改善する（監視・障害対応・改修）
大規模になるほど「分業」が強くなる
基幹は規模が大きくなりやすく、関係者も増えます。その結果、全体の設計や管理、品質の責任を持つ会社と、実装（設定やプログラミング）を担当する会社が分かれることがあります。
この構造だと、工程が進むほど話が具体的になり、だんだん会話が噛み合わなくなって、結局は実装担当も会議に同席して擦り合わせる場面が出やすくなります。これは誰かがサボっているというより、基幹は例外や影響範囲が大きく、伝言ゲームが破綻しやすいことが原因です。
障害はなぜ起こる？
基幹システムの障害は、単純なバグだけが原因ではありません。初心者向けに言うと、よくある理由は次の3つです。
1) つながりが多く、影響範囲が広い
基幹は単体で完結していないことが多いです。倉庫、決済、取引先連携（EDIなど）、問い合わせ窓口、周辺の業務システムとつながっています。どこかが詰まると別のところに連鎖しやすく、障害が大きく見えます。
2) 例外処理が多い
現場の業務には例外がたくさんあります。返品、値引き、請求の取りまとめ、締め後の修正など、例外が積み上がるほど複雑になります。
3) 変更が難しく、積み重ねで複雑になる
基幹は止められないので、気軽に大改修しにくいです。結果として小さな改修を何年も積み重ね、全体が分かりにくくなることがあります。外から見ると「なんでこんなところで？」に見えても、内部は歴史が詰まっています。
どんな構成で作られている？
「基幹システム」と聞くと、1つの巨大なシステムを想像しがちですが、実際はそうとも限りません。中心（コア）にある仕組みと、周辺（つながる仕組み）が組み合わさって全体として動いていることが多いです。
基幹システムは「既製品を入れて終わり」ではない
基幹システムは、既製品（パッケージ）を導入して使うケースもありますが、それだけではありません。会社によってはサーバーを自社で保有して運用したり（オンプレ）、業務に合わせてシステムを一から作ったり（スクラッチ）することもあります。
実際には「会計はパッケージ、受発注は自社開発、基盤はクラウド」のように、複数の選択肢を組み合わせて全体を作っていることも多いです。
構成を考えるときの2つの軸
- どこに置くか：オンプレ（自社でサーバーを持つ）／クラウド（外部の環境を借りる）
- どう作るか：パッケージ（既製品を導入）／スクラッチ（自社向けに一から開発）
まずはこの2軸で捉えると、「基幹システムの構成」の話が理解しやすくなります。
基幹システムでよく使われるプログラミング言語
基幹システムは、Webサイトやスマホアプリのように「この言語だけで作る」とは限りません。中心処理、夜間バッチ、他システムとの連携、画面、データ集計など役割が分かれているため、複数の言語や技術が組み合わさるのが一般的です。
中心の処理（売上・在庫・会計など）で登場しやすい
- COBOL：特に金融や長年運用している大企業の基幹で残りやすい言語です。古いというより「長年の業務ロジックが資産として詰まっている」ため、簡単に置き換えられません。
- Java：企業システムの定番。大規模開発、長期運用、周辺システムとの連携が多い現場でよく使われます。
- C#（.NET）：業務アプリでよく使われます。Windows中心の業務環境と相性が良いケースがあります。
- SQL（＋DBの拡張言語）：基幹はデータが命なので、検索・集計・更新で必ず登場します。
バッチ処理（夜間処理・締め処理）で登場しやすい
- COBOL / Java：大量データを扱う夜間バッチで使われることがあります。
- シェルスクリプト：ジョブ実行やファイル処理、連携の糊付けとして使われがちです。
- Python：集計・加工・自動化など、周辺で活躍しやすい言語です（中心ロジックというより補助・連携側で登場しやすいイメージです）。
画面（業務画面）で登場しやすい
- JavaScript / TypeScript：Webベースの業務画面なら定番です。
- HTML / CSS：見た目や入力UIの土台として登場します。
なぜ「古い言語」が残るの？
基幹システムで言語が古く見えるのは、流行に乗れていないからというより、止められない業務を支えながら長年改修を積み重ねてきた結果です。業務の例外処理や会計・在庫の整合性がコードに詰まっているため、置き換えは「言語の移行」ではなく「業務の移植」になり、難易度が跳ね上がります。
基幹システムは古い？
古く見えることは多いです。理由はシンプルで「止められないから」です。Webサービスのように頻繁に作り直すのが難しく、長く使い続ける傾向があります。
古くなりやすい理由
- 止められない（24時間、月末締め、決算などがある）
- 相手がいる（取引先連携やEDIなどは自社だけで変えられない）
- データが重要（移行でミスると大事故になりやすい）
古い＝悪ではない
古くても安定して動き、運用が成熟しているケースもあります。ただしブラックボックス化が進むと、変更がさらに難しくなり、障害時の復旧も遅くなる傾向があります。
不具合があるとどうなる？なぜ復旧に時間がかかる？
基幹システムの不具合で怖いのは、単に「画面が開かない」だけではありません。会社の仕事に直結します。
止まると起きること
- 受注できない、出荷できない
- 請求できない、入金確認ができない
- 月末の締めや決算が止まる
- 取引先にも影響が広がる
復旧が遅くなりやすい理由
- 影響範囲が広いので、どこまで壊れているか確認が必要
- 二重計上や在庫ズレなどが起きていないか、整合性チェックが必要
- 急いで直して別の障害を起こすと被害が増えるため、慎重に復旧する
基幹では「とりあえず動いた」だけでは不十分で、「正しく動く」「数字が合う」までが復旧です。だから復旧に時間がかかることがあります。
まとめ
基幹システムとは、会社の中心業務を支える“仕事の背骨”です。どこで使われるかは業界で違いますが、共通して「止まると事業が止まる」領域を支えています。
作り方はチーム戦で、大規模になるほど分業が進みます。障害が起きると影響範囲が広く、数字の整合性まで含めて戻す必要があるため、復旧に時間がかかりやすいのも特徴です。
また、基幹は「既製品を入れて終わり」ではなく、オンプレ・クラウド、パッケージ・スクラッチなどの選択肢を組み合わせて構成されることがあります。プログラミング言語も役割に応じて複数が登場しやすい分野です。
