システム担当必見！オープン系開発をアウトソーシングするポイント【2024年最新版】

オープン系開発とは、システム構築にあたってある特定のメーカーのハードウェアやソフトウェアを前提とすることなく、実現したいソリューションを優先して最適な組み合わせを選択できる開発方法です。

オープン系開発と対比される汎用系開発では、採用する汎用機（ハードウェア）メーカーが導入する機種に合わせてソフトウェアを独自に設計して構築します。
このため、汎用系開発ではどこのメーカーのハードウェアを採用するかで、ソフトウェアの開発のアウトソーシング先も自動的に決定されます。
また、一度発注して納品されたあとも、運用管理やシステムの更新はすべてそのハードウェアメーカーに依頼することになりますので、アウトソーシング先に悩む必要がないものの、極端にそのハードウェアメーカーに依存する体制になってしまいます。

通常の外注方法では常識となっている、相見積もりを取って価格や提案の内容を比較検討することもなく、何十年も１つの会社がかなりの予算をかけたプロジェクトを独占して受注しているという状態になりますので、時代に合わせてシステムを作り直すこともなかなか進まないということになりがちです。

こうした中、１社のハードウェアやソフトウェアにとらわれることなく、また、現在取引を続けている汎用機メーカーにもとらわれず、自社が実現したいソリューションを優先して最適な組み合わせを選択できるオープン系開発が注目されてきています。

オープン系開発では、コンピュータ本体や周辺機器などのハードウェアと、ビジネスロジックやデータ構造などのソフトウェアをオープンに設計・構築して最適なソリューションを実現していくところに特徴があります。
オープン系開発のアウトソーシングを考える企業は、使いたいハードウェアやパッケージソフト、予算に合ったハードウェアやパッケージソフトを自由に組み合わせて、オリジナルのシステム構築が可能です。

ただし、手放しで良いことばかりでもなく、どんな組み合わせでも動くという保証がない、トラブルが起きたときにどこに原因があるのか切り分けが難しいといったことに注意が必要です。

この記事では、そうしたオープン系開発をアウトソーシングするポイントについてお伝えします。

オープン系システム開発には、２つの大きなパターンがあります。

ひとつは、「ウォーターフォール型」と呼ばれるもので、開発工程をいくつかのフェーズに分割して、前フェーズの成果物を次のフェーズに順次引き継いでいくというものです。
ちょうど、滝が上から下へと流れ落ちるように一方向に順番に開発していくことから「ウォーターフォール（滝）型」と呼ばれます。

もうひとつは、最近主流の「アジャイル型」です。
アジャイルとは「俊敏」という意味で、アジャイル開発では、１回の開発期間を短く設定した上で、その１回の完成型を発注者とともに検証します。
ウォーターフォール型のように、前のフェーズの開発を必ず引き継いでいくということはなく、次回に必要な要件の優先順位を１回の短い期間ごとに再検討して、次の開発内容を決定します。

まず確認しておきたいのは、ウォーターフォール型開発は、オープン系開発だけで採用される開発方法ではないということです。
ウォーターフォール型開発そのものは、汎用機開発の時代に整備されてきた開発手法であり、最初に設計を厳密に行って、前行程の成果物を次の開発フェーズに引き継ぐという手堅い開発手法は、いかにも汎用機開発向けと言えます。

オープン系開発において、このウォーターフォール型開発を行う場合には、オープン系開発ならではのいくつかの改良ポイントがあります。
オープン系開発では、ビジネスプロセスの実現が重要になりますので、発注者側がどんなことをやりたいのか、という上流工程、超上流工程の洗い出しが重要になります。

オープン系開発における「上流工程」「超上流工程」の大切さについてはこちらの記事を御覧ください。

オープン系開発におけるウォーターフォール型のポイントをシステム構築の流れでまとめると下記のようになります。

特に最初の３段階である「1. 開発範囲を決定し、RFP（提案依頼書）をまとめる」「2. 発注先候補に対してオリエンテーションを行う」「3. 相見積もりを検討して候補を絞り込んで決定」は、オープン系開発ならではのフェーズと言えます。

伝統的なウォーターフォール型開発の説明では、「5. 要求定義作成」から始まるケースがほとんどですが、オープン系開発においては、自社がどんなことをやりたいのか（1. 開発範囲を決定し、RFP（提案依頼書）をまとめる）、各開発会社の強みを踏まえて提案してもらう機会を設ける（2. 発注先候補に対してオリエンテーションを行う）、自社に最適な提案を採用する（3. 相見積もりを検討して候補を絞り込んで決定）というプロセスを経て、初めて基本契約を結んで、要求定義作成に移ります。

オープン系開発用にアレンジされたウォーターフォール型開発でも、アウトソーシングを考える発注側企業の役割が重要になっていることがお分かりいただけたと思いますが、最近主流のアジャイル型開発では、さらに発注側企業のプレゼンスが増しています。

オープン系開発におけるアジャイル型のポイントをシステム構築の流れでまとめると下記のようになります。

例えば、顧客管理システム（CRM）を構築する場合、ウォーターフォール型ではどんなデータ構造にするのか、どんな検索を実現するのかといった設計を行い、設計段階で発注側企業の了解が取れた場合には、その設計図に従って地道に長期間にわたる構築作業を行っていきます。

これに対してアジャイル型開発では、最小限の完成形ができた時点、例えば既存の顧客データからダイレクトメールを発送すべき優良顧客を抽出するというプログラムが完成した時点などで、一度発注社側にシステムを評価してもらいます。

検収OKならばそのダイレクトメール発送システムは納品扱いとなり、ほかにどんな機能を実現するかについてプロジェクトチームで話し合いをして、優先順位に従って次の開発内容を決定します。

このように、開発内容そのものを柔軟に組み換え、変更していくという開発手法は古いタイプのクローズドなシステムの場合には考えられないことです。
オープン系開発ならば、激しい市場の変化、ライバル他社の動向などを考慮しながらこうした俊敏な開発が可能となります。

新規のオープン系開発の特徴を、「ウォーターフォール型開発」「アジャイル型開発」に分けて整理してきました。
今度は、社内にクローズドなレガシーシステムを抱えており、そのシステムをオープン系システムに移行したいという場合を考えてみましょう。

社内にクローズドなレガシーシステムを抱えている場合、移行の最も大きな動機はハードウェアの耐用年数でしょう。
レガシーシステムにおいては、ハードウェア専用のプログラムが納品されており、ハードウェアのリプレイスに伴ってソフトウェア部分の書き換えも必須になってきます。
このため、「どうせリプレイスをするのならば、これを機会に時代に即したオープン系システムに移行してはどうだろうか」という声が出てくるわけです。

新規のオープン系開発と違って、既存のレガシーシステムをオープン系システムに移行する場合には、現在稼働して業務を実行しているシステムを損なうことなく、いかにスムーズに移行を完了するかというところがポイントとなります。

汎用機システムでは、オンライン化されていない紙ベースの複雑なマニュアルや、仕様書、設計図などがたくさんあり、運用手順もマニュアル以外に属人化されてドキュメント化されていない部分（○○さんに聞かないと分からないという部分）が多数あることが普通です。

このため、レガシーシステムの移行においてはまず、きちんとした「移行計画書」を作ることが必須となってきます。

作成にあたっては、納品時に添付された設計図などのドキュメントをすべて用意するとともに、社内のキーマン（属人化したノウハウの持ち主）、アウトソーシング先企業の担当者とミーティングを繰り返し実施する必要があります。

レガシーシステムの移行では、開発側でレガシーシステム移行（マイグレーション）の経験とノウハウを持った人材を用意してもらう必要があります。

そして、それと同じくらい重要なのが、社内でレガシーシステムのデータを扱ってきた人材を確保することです。
新規のオープン系開発の場合には、新しくオープン系のハードウェアとソフトウェアを用意すればよいわけですが、既存のレガシーシステムからオープン系システムへの移行では、ハードウェア、ソフトウェアの移行とともに、現在取り扱っているデータの完全な移行が重要になってきます。
このデータはしばしば企業の財産と言ってもよい貴重なものですので、漏れや損傷が絶対に起こらない形で慎重に移行する必要があります。

したがって、このデータ移行では、データに漏れや損傷がないかを常にチェックする社内の人間の参加が不可欠となります。
開発チームと社内で普段データを扱っている人員がプロジェクトチームを発足させるなどして連絡を密にしながら移行作業をしていく必要があります。

データのマイグレーションは、レガシーシステムからオープンシステムへデータを転送するプロセスとなります。
汎用機とオープン系開発で使うコンピュータでは、ストレージのデータフォーマットが違いますので、フォーマットに合わせたデータ変換が必要になります。

基本的な作業としては、旧レガシーシステムと新オープン系システムの間でデータの整合性を取るデータマッピングという作業を行います。
データマッピングは新旧システムのロジックに合わせて行いますが、どうしても古いシステムのデータがそのまま新しいシステムに適合できない場合が出てきます。

その場合には、手作業での移行が必要になったり、（半）自動化できる場合でも、どういう判断基準で旧データを加工して新データに引き継ぐかなどを検討したりすることが必要になります。

こうした検討や確認作業は開発業者任せにはできません。
オープン系システムに移行した後もデータがこれまで通り有益に活用できる状態であるかどうかは、発注側企業の担当者が必ず確認しなければなりません。

こうして手作業や（半）自動化作業で移行していくデータは、無意味なデータを削除して有益なデータを残していく「データクレンジング」を繰り返してデータ品質を向上させていきます。
このデータ移行の工程（設計、抽出、クレンジング、ロード、検証）においては、発注側企業の担当者、プロジェクトチームの役割が極めて大きいことを認識しておきましょう。

オープン系システムへのデータ移行において発注側が重要な役割を果たすことを確認しましたので、オープン系開発フェーズで重要な役割を果たす開発企業の選定ポイントについて見ていきましょう。

新規にオープン系システムの開発を行った実績とともに、レガシーシステムからオープンシステムへの移行実績も必ずチェックするようにしましょう。
移行実績の中身としては、下記の３点を確認しましょう。

オープン系システムでは、レガシーシステムに比べて万が一のトラブル時の「原因の切り分け」が困難です。
単一のメーカーを前提としたレガシーシステムの場合には、不具合の情報なども単一メーカーが収集し、対処にあたった経験豊富なエンジニアも自社内で抱えていることがほとんどです。

しかし、オープン系システムの場合には数社の製品を組み合わせてシステムを完成させるという性質上、不具合の情報も各社でバラバラに保管しており、現在生じている不具合がどのメーカーの製品、もしくはソフトウェアのどの部分にあるのか原因を特定することに時間がかかってきます。
エンジニアも、過去に経験したことのない不具合に対処せざるを得ないケースが多く、そうした面でもレガシーシステムに対して解決までに時間を要するケースが多くなります。

こうした制約のある中、迅速に解決までの努力をしてくれる充実したサポート体制を持つオープン系開発企業は貴重です。
オープン系開発のアウトソーシングでは、レガシーシステムの発注のときよりも、このサポート体制についてきちんと検討することが大切です。

オープン系システム開発においては、旧来のビジネスプロセスを改善するビジネスプロセス・リエンジニアリング（BPR）が重要になってきます。
ただ単に、新しい技術を使ってシステムを組むということだけでは、本当の意味でシステムを刷新することにはなりません。

古いシステムは古いビジネスプロセスを前提に構築されています。
大きな予算を使って新しいオープンなシステムを構築する以上は、時代に即した、同業他社と比べても十分競争力のあるシステムを導入しなければその意味は半減すると言えるでしょう。

オープン系システム開発の実績豊富な開発会社は、新しいビジネスプロセスの構築の実績もある会社だと言えます。
ぜひ自社のBPRに踏み込んだ親身な提案をしてくれる経験豊富なオープン系システム開発会社を選びましょう。

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

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

以上、オープン系開発をアウトソーシングするポイントについて、発注側企業が積極的に果たすべき役割なども踏まえて整理してきました。

オープン系開発では、伝統的なウォーターフォール型開発でも、先進のアジャイル型開発でも発注側企業がどんなシステムを作りたいのか、というビジネスプロセスに踏み込んだ完成形のイメージを持つことが大切になってきます。

また、レガシーシステムからオープン系システムに移行する場合であっても、単に旧システムを移し替えるだけでなく、移行を機に時代に即した競争力あるシステムを構築するという視点が求められてきます。

こうした発注側の意向に応えてくれる優良開発会社を選ぶときには、ぜひ経験豊富なコンシェルジュが多数在籍している「アイミツ」をご活用ください。
御社のご要望をくみ取った上で、最適なオープン系開発会社をピックアップいたします。