新規構築と移行～オープン系システム開発のそれぞれにおける注意点【2024年最新版】

オープン系システム開発とは、１つのメーカーで統一されたソリューションではなく、複数の異なるメーカーの製品を組み合わせて使うことに特徴があります。
例えば、オープン系と対比される汎用系システムにおいては、コンピュータから周辺機器、さらにコンピュータ上で動作するソフトウェアまでもすべて、NECや富士通といった特定のメーカーの製品で統一され、保守メンテナンスもメーカー系の会社が担当する場合がほとんどです。

こうしたクローズドのシステムの場合には、そのコンピュータ上で動作する基本ソフトも周辺ソフトも、納品先の企業の業務に合わせて独自開発し、ハードウェアの調達からシステムの設計、納品までを担当した会社（グループ）が、バージョンアップのときにも半永久的に担当するといった構図ができあがっていました。

こうした取引形態では、納品されたあとも長い付き合いになるわけなので、システムの不具合やバージョンアップなどもハード機器メーカーがバックに付いており、自社用に設計からすべて担当してくれたシステム構築会社に任せておけば安心という抜群の安定感があります。

しかし、システム納品時やバージョンアップ時に他社との競争がまったくないと言ってよい状態なので、技術的なイノベーションや、他社と価格を競わせた上でのプライスダウンなどが図りにくいというデメリットが指摘されてきました。

現在でも大企業のシステムや、勘定系システムと呼ばれる金融機関向けシステムなどは、こうしたクローズドの汎用系システムが採用されていますが、最近ではより自由度の高く、価格メリットも出やすいオープン系システムの開発が盛んになってきています。

以上のような経緯から、これからオープン系システムの開発を行うという場合には、新規構築と移行（マイグレーション）と２つのケースに分けて考えることが大切です。

現在すでに汎用系システムが納品されている場合には、既存のシステムをどうやってオープン系に移行していくかが大きな課題となり、新規にオープンシステムを構築する場合には、汎用系のメリットであった安定感をオープン系で確保することなどが課題となります。

この記事ではオープン系システム開発における新規構築とマイグレーションと２つのケースの注意点について解説します。

1980年代まで汎用系システムはシステム開発において主流の方法でした。
しかし1990年代初め頃より「ダウンサイジング」という言葉が盛んに使われるようになり、大型化していたシステム構築を小回りの利くコンパクトな設計に置き換えていこうという流れが出てきました。

また、1990年代中盤からはインターネットの商用利用が解禁されたこともあり、TCP/IPプロトコルをベースとしたオープンなネットワークを前提とするシステム構築が一気に主流となっていきます。

具体的には、WindowsやUNIXといったオペレーティングシステムを採用し、データベースはOracle、IBM、SybaseなどのRDBMSベンダーのソリューション、技術的には、Javaテクノロジの採用などが目立ってきました。

厳密には、オペレーティングシステムやRDBMSなども営利企業が提供しているものであり、オープンな技術の代名詞的存在であるUNIXにしても、各UNIXパッケージは営利企業が提供しているので、個々のベンダーに依拠する部分は完全にはなくならないと言えます。

しかし、製品を組み合わせて使う上で必要な技術開示などはメーカーごとに温度差はあるものの、基本的には公開されている技術や有償サポートなどで対応することは可能ですので、汎用系システム開発に対して開かれたオープンな開発であることは間違いないでしょう。

それでは、レガシーシステムのマイグレーションの手法を見ていきましょう。
レガシーマイグレーションの手法は大きく分けて下記の３つがあります。

「リホスト」とは、大型コンピュータや専用の周辺機器などのハードウェア的な部分を、UNIXやWindowsなどのオープン系システム搭載のサーバーと周辺機器にマイグレーションして、内部で動いている既存アプリケーションはそのままいじらずに、移行後のダウンサイジングしたコンピュータ上の仮想レイヤーで動作させるというものです。

イメージ的には、重要な建築物などを保存するときに、解体をせずにテーマパークなどの新しい土地に引っ越しをするようなものだと考えられます。
現在動作している既存アプリケーションには手を加えずに移植しますので、マイグレーションにあたってシステムが動かなくなってしまうなどのリスクは最小限にすることが可能です。
しかし、ハードウェア的な部分ではコストダウンが図れるもののプログラム部分のソースコードはいじりませんので、基本的なレガシー構造はそのままとなり、ソフトウェア的なオープン化には手を付けないで済ませてしまうということになります。

「リライト」においては、「リホスト」で行ったハードウェア部分のマイグレーションに加えて、ソフトウェアのソースコード部分を書き直します。
ただし、ソースコードをいじると言っても、時代に合わせてオープンな設計にやり直すことには手を付けません。
あくまで、既存のソースコードのリライトです。具体的にはCOBOLなどで書かれた汎用機専用のプログラムの設計はそのままで、Javaなどのオープン系のプログラミング言語にアプリケーションロジックの変更はせずに書き直します。

時代に合わせてプログラムの書き方そのものをオープンにするということはせずに、内容に改変を加えずに逐次翻訳をするようなものだと言えます。マイグレーションリスクは先程の「リホスト」と次に解説する「リビルド」の中間になります。

「リビルド」はマイグレーション手法の中で、最も徹底してシステムをオープン化します。
システムの設計レベル（ロジックレベル）から見直す方法であり、単にシステムを移行するだけにとどまらず、BPR（ビジネスプロセス・リエンジニアリング）が必要となるケースがほとんどです。

BPRとは売り上げ、収益率などの企業活動の目標を達成するために、既存の業務内容や業務フロー、組織構造、ビジネスルールを全面的に見直し、再設計（リエンジニアリング）することを言います。
レガシーシステムが設計された時代（例えば汎用系システム全盛期の1980年代）と現在では、30年以上の開きがあり、その間、企業の目標達成のための業務内容や業務フロー、組織構造、ビジネスルールは改善、改良され続けてきたと考えるのが普通です。

であれば、汎用系システムの完全なマイグレーション化を果たすためには、こうした業務内容や業務フロー、組織構造、ビジネスルールの改良に合わせて、汎用機の設計そのものをアップデートしなければなりません。

そのレベルまで手を付ける方法が「リビルド」となりますので、移行リスクは最も高く、コストもかかってきます。

ここまで、既存のレガシーシステムのマイグレーションについて整理してきましたので、次はオープンシステムの新規構築の注意点について見ていきましょう。

オープン系システム開発は、ハードウェア機器のダウンサイジング、インターネットの商用利用が解禁されたことによるTCP/IP系ネットワークの普及、UNIXやWindowsなどのオペレーティングシステムの登場などを背景として、この20年で急速に広まりました。

銀行などの勘定系システムなどを一部の例外として、新規にシステム構築をするときにはオープン系システムを前提とすることが当たり前になっています。

また、オープン系システム開発では、既存のビジネスのフローを見直して、業務プロセスそのものを解決するための具体的手段としてシステム構築が提案されることが多くなってきています。
つまり、既存のビジネスフローを単純にシステム化して効率性を上げるというだけでなく、BPR（ビジネスプロセス・リエンジニアリング）の実現手段としてシステム構築が注目されているのです。

したがって、オープン系システム開発を行う場合には、これまで以上にビジネスプロセスのあるべき姿をきちんと洗い出し、それをシステム化していくという部分が重要になってきています。
単に効率化を目指してシステム構築を外注するということ以上に、自社においてどんなBPRを行って、他社との競争力を確保していくかといった視点が発注側に必要になってきています。

新規のオープン系システム開発では、UNIXやWindowsなどのオペレーティングシステムをベースとして、TCP/IP系ネットワークのメリットを活かしやすいwebブラウザをインタフェースとしたシステムが広く採用されています。

また、情報系、基幹業務系などの開発では、あらかじめソリューションのひな形をパッケージ化した、ライセンスタイプのパッケージソフトが多数用意されていますので、そうしたパッケージソリューションを活用することで、短期間にクオリティの高いシステムが構築可能となっています。

インターネットの商用利用が解禁されたことによるTCP/IP系ネットワークの普及は、企業のシステム開発にも大きな影響を与えました。
それまでは、汎用機専用の操作画面をゼロから設計して構築していましたが、クライアント端末に標準インストールされているwebブラウザでサーバーへアクセスして業務を行うという方法が一般化しました。

webブラウザから接続するサーバー機は、汎用系で使われているようなホストコンピュータではなく、通常のデスクトップパソコンの性能を高めたパソコンタイプのサーバー機です。
このサーバー機には、UNIXやWindowsといったオペレーティングシステムがインストールされています。

システムの発注側が注意すべき点は、サーバー機にインストールするオペレーティングシステムをWindowsにするか、UNIXにするか決定することです。

オープン系と言いながら、UNIXもWindowsも商用パッケージとなっており、完全にすべての情報が無料で手に入るわけではありません。
一般的にライセンス料金はUNIX系のパッケージに比べてWindows系のほうが高額になっていますが、その分、有償サポートなどはWindows系のほうが充実していると言えるでしょう。

また、UNIXはあくまでサーバー専用のオペレーティングシステムであり、最近でこそクライアント側でGUI（グラフィカルユーザーインタフェース）環境で操作できるUNIXディストリビューションも出てきているとはいえ、ビジネスシーンでのクライアント側の環境としてはWindowsが一般的です。

このため、クライアント側でサーバーと連携した操作を快適に行いたい場合などは、クライアント側で標準のオペレーティングシステムとなっているWindowsを採用したほうが、システム構築がやりやすいという案件もあります。

逆に、サーバー機能はすべてサーバーで完結して、ユーザーはwebブラウザだけを使えばよいという場合には、サーバーにどんなOSがインストールされているかを意識する必要はありません。
こうしたシステム構築の場合には、UNIXがコスト的なメリットが大きいと言えます。

一般的に、汎用系システムの開発に比べてオープン系システム開発のほうが工期は短いとされています。
しかし、短いと言っても完全にゼロから設計していく大規模なオープン系システム開発では、半年や１年といった長期にわたる開発も珍しくありません。

また、「オープン系システム開発のミニ歴史」で触れたように、オープン系システム開発では、既存のビジネスフローを単純にシステム化して効率性を上げるというだけでなく、BPR（ビジネスプロセス・リエンジニアリング）の実現手段としてシステム構築が注目されています。
こうしたBPRをゼロから設計していくことは大変な労力と時間がかかります。

そのため、オープン系システム開発では、製造業、卸売業、小売業、不動産業、自治体、学校、病院などの業界ごとに、ビジネスプロセスの標準的な流れをパッケージ化した製品が多数用意されています。

また、業界をまたいだ、顧客管理、営業支援、会計管理、給与計算、ワークフロー、グループウェアなどの業務別のソリューションについても多数のパッケージが存在します。

こうしたパッケージを使えば、工期の大幅な短縮が図れるだけでなく、ゼロからシステムを設計して構築することに比べてコストも大幅に抑えることができます。
また、あらかじめ典型的なBPRが洗練された状態でひな形として用意されているので、あとはパッケージに足りない部分を洗い出して自社独自の仕様を追加カスタマイズしてもらえばよいので、設計段階の失敗のリスクが非常に小さくなるため、非常に大きなメリットがあります。

最後に、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。

以上、オープン系システム開発の注意点について新規構築と移行（マイグレーション）に分けて解説してきました。
解説の都合上、２つに分けましたが、既存のレガシーシステムを移行しながら、一方で新規のパッケージベースのオープン系システム開発を同時並行で行うなどのケースももちろん可能です。

最後に、２つのケースで外注先を選定するときのポイントについて解説しておきます。

まず既存レガシーシステムのマイグレーションを実施するときの注意点ですが、マイグレーションのリスクを高めたくないので、まずはハードウェア機器のダウンサイジング優先したという場合、競争力のないシステムがそのまま会社のビジネスプロセスとして残ってしまうということがあります。

確かに、老朽化したハードウェアをリプレイスすることが耐用年数的に急務でありながらBPRには手が付けられていないというケースでは、既存のビジネスロジックに手を付けない「リホスト」や「リライト」で急場をしのぐこともしかたがない、という場合もあるでしょう。

ただし、それは問題の先送りにすぎないことも事実であり、他社と比べて競争力のないアプリケーションを維持するために、新規にハードウェアの投資をするという後ろ向きの戦略になっていることは間違いありません。

複数の外注先に相談してみれば、社内で想定していたよりもずっとわずかのコストで、既存のレガシーシステムのマイグレーションが「リビルド」レベルで可能であるということが分かるかもしれませんので、まずは「リビルド」を含めて外注先の提案を聞いてみることをおすすめします。

もう一つ、新規にオープン系システムの開発を実施する場合の注意点です。
オープン系システム開発では、複数のベンダーの製品を組み合わせてコストメリットを出していきますので、複数のベンダーの技術情報を参照しながらシステム構築を行うことになります。

当然のことながら、設計段階だけでなく実装フェーズにおいても、単一のベンダーの製品を前提とする場合と比べて作業は複雑化しますし、難易度が上がります。
また、納品後のトラブルのときにも、データベースで採用したOracleの製品が不具合の原因なのか、オペレーティングシステムのWindowsなのか、パッケージベンダーのセールスフォース・ドットコムが原因なのか…という「原因の切り分け」を行っていくことが必要です。

こうした点は、汎用系システムの開発の安定性に比べて、発注先の経験や技術レベルに大きく依存してきます。

このような、マイグレーションのときに「リビルド」を含めて親身に相談に乗ってくれる業者を探したり、オープン系システム開発の新規開発の経験が豊富で技術力が高い外注先をピックアップしたりしたいときには、ぜひ「アイミツ」にお声をおかけください。

経験豊富なコンシェルジュが、御社のオープン系システム開発をサポートするベストの外注先を選定いたします。