基幹システム

基幹システムとは

基幹システムとは、企業がその事業遂行に不可欠な主たる業務を支援し、処理するための情報システムです。日本語では基幹系システム、基幹業務システムとも呼んだり、英語ではEnterprise System、Mission-Critical System、あるいはBackbone Systemと訳したりします。英語の呼び方に関してはそれぞれ少しずつニュアンスが異なるようです。

Enterprise Systemは企業全体にわたる業務プロセス、情報の流れ、レポーティングや分析をサポートする情報システムです。この言葉は、特に、部門横断、企業全体にわたるところがキーポイントです。典型的なものがERP(Enterprise Resource Planning)でしょう。

Mission-Critical Systemも同様に使われる場合があります。すなわち、企業活動を遂行する上で必要不可欠で、停止すると企業活動の継続に支障をきたし、大きな損害が生じるシステムという意味です。この言葉は例えばジェット機のナビゲーションシステムや原子力発電所の制御システムのような用途のシステムにも使われます。

Backboneという言葉はその名の通り背骨です。例えば、Backbone Networkと言えばエンドユーザと接する枝葉のアクセス回線を除いた、アクセスポイント間を結ぶ幹となるネットワークを表します。情報システムの場合は、エンドユーザとのUI(User Interface)部分を除いたデータを処理する部分であり、事業や法令などの大きな変化がない限り変わらない根幹の処理を行う部分です。具体例としては財務会計システムや銀行の勘定系システムなどがイメージしやすいでしょう。

このように、基幹システムという言葉はいくつかの意味を含んでおり、業種や使うシーンによって多少ニュアンスが異なりますが、企業にとって最重要なシステムを表す言葉であることは間違いありません。

情報系システムとの比較

基幹システムでないものとしては情報系システムが挙げられます。情報系システムは企業の基幹業務を円滑に進めるために、社内、あるいは社内と社外のコミュニケーションや社外への情報提供を行うための情報システムを指します。具体的にはメールシステムや各種グループウェア、その他、文書管理システム、情報検索、メッセージングシステム等が挙げられます。顧客とのQ＆AやCRM(Customer Relationship Management)、SFA(Sales Force Automation)などのシステムも情報系システムに含まれます。さらには、基幹システムの情報を利用して構築するデータウェアハウスなども情報系システムに分類されます。

もともと、企業のコンピュータ化、システム構築は基幹システムから始まりました。大型ホストコンピュータ全盛の時代はほとんどのシステムが基幹システムだったと言えます。情報系システムは基幹システムに比べて新しく、情報系システムがなくても企業の業務は回っていたため、「情報系システムは停止しても他の手段で代替できる」と説明されることがあります。

しかしながら、インターネットを含む社内外ネットワークと情報共有インフラの利用を前提として業務が遂行されている現在、情報系システムの重要性は増す一方です。企業の神経系ともいえる情報系システムの良し悪しが企業業績をも左右する時代になっています。簡単な例で言えば、メールやグループウェアが停止すれば、それを電話とFAXで代替することはもう不可能なのです。

従って、その重要性、あるいは他の手段で代替できるか否かで基幹システムと情報系システムを区別することは難しくなってきています。区別するならば、企業情報システムに関しては、最終的に決算、すなわち会計システムにつながるデータに直接関与するシステムか否かという方がわかりやすいかもしれません。

基幹システムの具体例

基幹システムの代表的な例としては、まず、ERP(Enterprise Resource Planning)がサポートしている下記のようなシステム群が挙げられます。

これらの基幹システムは例えば製造業であればほとんどの企業に共通かつ必要なものです。ERPではこれらの基幹システムが一つのデータベースシステムで統合的に構築されています。これにより関連する情報が時間差なく同時に更新され、経営状況をリアルタイムに把握できることが大きな利点とされています。

日本の製造業では現場の意見を重視するため、生産管理システムは企業によって大きく仕様が異なることもあります。一方、会計システムや人事システムの基本的な概念や構成は企業によって大きく変わることはありません。一般的に基幹システムと言えば、この領域の情報システムを指す場合も多いようです。

上記のような一般企業に共通的な情報システムではなく、個別事業に特化した下記のような情報システムも基幹システムとみなせます。この他にもそれぞれの企業の事業を支える基幹システムは業種や業務の数だけあると考えられます。

基幹システムの特徴

基幹システムはその企業の幹となる業務を支えるシステムです。多くは、大規模であり、その企業の事業が変わらない限り大きくは変わらない安定的なシステムです。一般的には下記の特徴があります。

1．大規模、多くのアプリケーションの集まり

基幹システムは全社規模で企業の業務を支えるシステムです。通常、ひとつの業務に対しそれぞれ専用のアプリケーションを用意します。業務の数だけアプリケーションがあるので数百から数千本、あるいはそれ以上の数のプログラムで構成されます。毎日使うアプリケーションもあれば、年1回しか使わないアプリケーション、異常時のみ使うアプリケーション等も含まれます。一方、グループウェアに代表される情報系システムは比較的少ない種類の共通のアプリケーションを多数の利用者が高頻度で使います。

2．定型的で仕様変更の頻度は少ない

基幹システムは安定稼働後の仕様変更はそう多くはありません。業務のやり方は都度変化があっても、基幹システムで扱うデータは大きく変わらないためです。例えば、財務会計システムをイメージすると、業務の方法が多少変わっても、会計ルールが変わらない限り財務会計システムに大きな変更はありません。基幹システムは企業の事業の普遍的な部分を管理・制御しているのとも言えるでしょう。

3．社内利用で使い慣れた人が継続利用する

基幹システムは原則、該当業務の担当者が使うことが前提です。従って、それぞれの業務担当者にとって使いやすく、効率的な仕様が求められます。例えば、入力系の画面では、見栄えや初めてでもわかりやすいインタラクティブな案内表示よりも、効率的に入力業務が行えるような項目配置や操作方法、素早い動きなどが重視されます。そのため、情報系システムに比べて実用重視で簡素なデザインのものが多い傾向にあります。ただし、最近ではスマホやタブレット普及の影響で、基幹システムにも使い心地を重視するUX(User eXperience)の概念が広がりつつあります。

4．安定稼働が求められる

安定稼働はもちろんすべての情報システムに求められる要件ですが、特に基幹システムは事業に直結しているため、システムが正常に稼働し続けることが重視されます。停止は企業にとって大きな損失につながりかねません。業種によっては大きなトラブルが社会問題となる場合もあります。システム停止しないための冗長化、BCP対策などに対する投資も優先的に実施されます。

5．長期間利用する

定型的で仕様変更の頻度が少ないシステムゆえ安定稼働した後は長期間利用されます。6年から長いものでは10年以上、中には20年、30年使い続けるものもあります。もちろん、その間、情報技術は進歩し、ハードウェアやミドルウェアは更新されていきますが、アプリケーションの仕様はほとんど変えずに新たなプラットフォームに対応させて使い続けます。すなわち、長期間使い続けられるプラットフォームや保守体制が重要なファクターとなります。

基幹システムの課題

基幹システムにおける最大の課題はなんといっても老朽化、レガシーシステム化でしょう。基幹システムの特徴のところで述べたように、基幹システムは大規模システムであり、短いサイクルで再構築されることなく、長期間にわたりそのまま、あるいは機能追加されながら利用されてきました。

そのため、レガシーシステム化した基幹システムは下記のような問題を抱えています。

• ハードウェアやミドルウェア、また開発言語などのITアーキテクチャーが古く他システムや新たなデバイスと連携できない。また、新しい技術を使った機能強化ができない。
• 古い技術や開発言語に対応できる人材が不足し、その補充・育成も難しく、将来維持ができなくなるリスクがある。
• 再構築しようとしても、長い年月をかけて継ぎ足して巨大化複雑化したシステム全容を把握している人材がいない。また、予算、開発人員の不足や費用対効果が悪いことなどから再構築に踏み切れない。

レガシーシステムは企業の基本業務を支えて続けている必要不可欠のシステムですが、事業を革新し新たな利益を生みだすシステムではありません。従って、大きな労力とコストをかけて再構築しても投資効果がはっきりしない。そのまま使えるのであればプラットフォームを更新して使い続けた方がいい、という考え方もあります。もし再構築しなければ事業が回らなくなるのであれば再構築されているはずですが、問題を先送りできるところもレガシーシステム問題の特徴なのかもしれません。

一方、AI、IoTに代表される新しい技術は直接企業の事業を革新し新な価値を生み出す可能性を秘めています。多くの企業、特に経営者は基幹システムを再構築するよりも、新しい技術を活用して事業を飛躍させる方に経営資源を振り分けたくなるでしょう。しかしながら、レガシーシステムを古いアーキテクチャーのまま放置すれば、やがて、技術者が調達しにくくなり、中身を知る人材がいなくなり、再構築自体が難しくなります。いつかは何とかしなければならない時限爆弾のようなものです。このようなレガシーシステムを何とかするための考え方がモダナイゼーションです。

モダナイゼーション

モダナイゼーションとその選択肢

モダナイゼーションとは古いITやアーキテクチャーで構築され、長年利用されてきた基幹システムを、現在のITに対応できるようリニューアルさせる考え方です。かつて、基幹システムをメインフレームからオープン系のハードウェアに移行することをダウンサイジングと呼んでいました。最近では、レガシーマイグレーションやモダナイゼーションあるいはITモダナイゼーション、システムモダナイゼーションなどと呼んでいます。基幹システム再構築というと一から作り直すイメージが強いですが、モダナイゼーションはその目的に応じて、さまざまな手法を駆使して、レガシーシステムを新たに生まれ変わらせていくこと意味します。

古い基幹システムではシステム仕様書が最新になっていなかったり、そもそもどれくらいのプログラムが実稼働しているかさえ把握できていなかったりする場合があります。そのため、モダナイゼーションでは、まずは、現行システムの資産調査から始めます。例えば、稼働実績などから実稼働しているプログラムを特定したり、ソース解析ツールなどを使ってドキュメントを自動生成(リドキュメント)したりします。

現行システム調査結果と解決すべき課題、その企業のモダナイゼーションの目的に照らし合わせ、現行システムの資産を、1.不必要な資産(プログラム等)、2.そのまま再利用する資産、3.新たに作り直す資産に振り分けます。そして、2.3について次のような手法を目的に応じて適用します。

ラッピングは外部システムから新しいインターフェース経由で現行システムを利用できるようにすることです。現行システムはそのまま利用しますが、古いアーキテクチャーのままだと周りのシステムと連携できないため、新たなインターフェースで包み込むイメージです。

リインターフェースは、新しい端末やデバイスに対応するためユーザインターフェースに関わる処理のみを置き換えることです。例えば、メインフレームの専用端末をWindows PCに置き換えたり、ブラウザーベースに置き換えたりする際によく採用されていました。

リホストは例えばメインフレーム上のCOBOLのプログラムをそのまま互換性のある最新のハードウェアに乗せ換えたり、互換性のあるオープンCOBOLへコンバージョンしたりして、ほとんどプログラムの変更をせずに新しいプラットフォームに移行させます。うまくいけば最も簡単な移行方法です。最近では新しいプラットフォームとしてクラウドの採用が増加しています。

コンバージョンはコンバージョンツールにより、例えばCOBOLからJavaに機械的にプログラムのソースコードを変換します。この成否はコンバージョンツールの出来にかかっています。言語を新しいものに変更するため、古い言語の技術者を保持する必要はなく、保守要員を調達しやすくなります。ただし、機械的にコンバージョンされたソースコードは人が読みやすく理解しやすいものとは限りませんので注意が必要です。

リライトは現行システムのプログラム仕様はそのままに新しい開発言語でプログラムを書き直すことです。人手でプログラミングするため、新しい言語に適した形式のメンテナンスしやすいソースコードに改善することが可能です。コンバージョンツールと組み合わせて、コンバージョンできない部分をリライトすることもあります。

リビルドは業務内容や仕様の見直しも含めて新たに作り直すことです。コストや時間は最もかかりますが、現状の課題を解決し新たな効果を創出することができます。将来的にもビジネス変化に対応できるシステム構築が可能です。

リビルド

前項の手法のうち業務改善を伴うのはリビルドのみです。他の手法は現行システムをそのまま使い続けるための延命策とみなせます。現在のシステム仕様で業務上問題なく、将来的にもあまり業務内容が変化ないようなシステムであれば、コストと期間で有利なリビルド以外の手法を採用することになるでしょう。一方、事業変化に応じて臨機応変に対応させていかなければならないシステム、あるいは現在解決すべき課題が山積みしているシステムの場合は多少費用をかけてもリビルドを選択すべきでしょう。

リビルドを選択する場合、問題となるのは開発人員、費用と期間です。基幹システムは一般に大規模の場合が多い一方、開発できる規模には上限があります。リビルドする部分をできるだけ絞り込んだ上で、さらにその限界を拡げるためには、できるだけ効率的な開発手法を取り入れることが重要です。

リビルドの進め方

基幹システムでは前項で述べたように、多数のアプリケーションがあります。基幹システム開発、リビルドではこの数百本数千本のアプリケーションを効率的に開発しなければなりません。

リビルドでは、現行システムの仕様や稼働しているアプリケーションを参考にしながら新たに要件定義を起こします。現在の業務が止まらないよう、現行システムで稼働している機能を抜け漏れなく調査することが非常に重要です。現行システムのドキュメントが現実を網羅している保証はなく、また、現行システムの仕様すべてを把握しているSEや現行業務をすべて把握している業務担当者がいるとは限りません。ここをクリアすることがリビルドで成功するため最も重要なポイントです。

メインフレームで長年稼働している古いシステムには、既に使われていない不要なプログラム資産が相当数あります。まずは現行調査でそれらを排除し対象を絞り込みます。さらに、稼働しているアプリケーションでも本当に必要かどうか検討して不要な業務の削減を試みます。例えば、紙で印刷している管理帳表等は本当に使っているのか、データで提供してEXCELにダウンロードで代替できないのかなどを検討することで、かなりのプログラム開発工数の削減が期待できます。このように、業務プロセスの見直しを実施し、不要な業務を排除し、開発規模を絞った上で、新しい効果を生む機能を追加します。

効率的な基幹システムの開発

標準化、パターン化

基幹システム開発の世界ではメインフレームの時代から「標準化」、「パターン化」の文化がありました。多くのプログラマーで開発する基幹システム開発では、できるだけ属人性を排除し、誰が組んでも同じレベルのプログラムになるように工夫します。基幹システムには複雑な画面やビジネスロジックを伴うさまざまな処理形式のプログラムもありますが、多くは画面からデータベースにデータを登録したり、データベースから画面や帳票にデータを出力したりするような形式のものです。このようなプログラムはデータ形式と基本的な処理(検索、登録、変更、削除、帳票出力等)が決まればプログラム構造が決まります。基幹システムのプログラムはパターン化しやすいのです。

一方、情報系のシステムは基幹系のシステムに比べて少ないプログラムを多数のユーザが高頻度で利用します。それぞれのアプリケーションがより便利に、より使い勝手がよく、より効果的になるように工夫をこらしながら開発する必要があります。使い勝手はやってみないと分からない部分もあり、基幹システムほどパターン化ができません。

基幹システムの設計とデータモデリング

基幹システムを変化の少ないBackbone Systemととらえるならば、このBackbone Systemを手際よく図で表す、すなわちモデリングすることが重要です。企業活動において最も安定しているのはデータです。業務のやり方は変化が激しいですが、記録するデータは比較的安定しているからです。その意味で基幹システムを設計するには、まずデータ構造を押さえておく、データを切り口に全体をモデリングすることが極めて有効です。

事業で使われているデータは、電子化されているいないにかかわらず、すべて事業活動の管理対象となるものです。データモデリングではこれらをすべて集めて適切な構造を与えてデータモデルを作成します。そして、最終的にはデータベースシステムに反映させます。基幹システムとは事業の管理過程をサポートするシステムであり、管理過程で使われるデータを蓄積したデータベースと入出力を行うシステムととらえることができます。そう考えると、基幹システム開発におけるデータモデリングが非常に重要で効果的だということが理解できるのではないでしょうか。

超高速開発ツールによる基幹システム開発

基幹システムを効率よく開発するために、メインフレームの時代から標準化、パターン化、及び部品化を行い、コーディング部分を極力減らすことが図られてきました。その後、生産性が高い簡易言語である各種4GL (4th Generation Language）が積極的に活用されました。オープンシステムの時代になると、仕様情報からソースコードを自動生成するようなしくみが自作され、あるいは数多く市販されてきました。

最近では、設計情報からほぼノンプログラミングでアプリケーションを生成するさまざまな超高速開発ツールが販売されています。そのほとんどは基幹システムを含むエンタープライズ系のソフトウェア開発をターゲットにしていますが、さらにその多くはデータモデルを開発の起点にしています。

基幹システムはデータベースとの入出力処理が基本であり、そのアプリケーションは標準化、パターン化しやすいことは前に述べた通りです。そのため、データモデルが決まり、データベース設計が完了すれば、そのデータベースに対して検索、登録、変更、削除やデータダウンロードや帳票出力を行うプログラム構造を標準的に決めることが可能です。すなわち、データベース設計情報のみからプログラムの自動生成を行うことが可能なのです。超高速開発ツールの中にはこのような性質を利用して少ない設計情報からプログラムを自動生成できるものもあります。

超高速開発ツールで大きな効果をあげるには、そのツールの特性を理解して、個々のアプリケーションをそのツールの得意な処理パターンで実現するように設計段階で考慮する必要があります。適切な設計をすることでまさしく「超高速」な生産性を実現できるだけでなく、保守性の高いシステムを構築することができます。逆に、既存システムの画面レイアウトや処理形式等をそのまま再現することにこだわると効果が半減します。

その他の考慮として、まず、Javaなどの開発言語で直接ソースコードを書くスクラッチ開発と違って、超高速開発ツールでは標準機能では実現できない処理もあります。その場合、代替手段があるのか、一部コーディングすれば実現できるのかなど、どこまで実現可能なのかを事前に確認することが重要です。さらに、大規模な基幹システムの場合、性能面で不安はないか、長期間の利用に耐えられる機能、性能、拡張性、プラットフォームからの独立性、そして長期保守体制などの検証も必要でしょう。

考慮すべき点はあるものの、超高速開発ツールはパターン化された処理が多い大規模な基幹システムにこそ適しています。基幹システムのリビルドでは必須と言ってもいいでしょう。