システム担当必見!オープン系開発をアウトソーシングするポイント

外国人の会議風景

更新日:2017年09月26日 | 公開日:2017年05月22日

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

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

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

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

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

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

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

新規オープン系開発の流れを知っておこう

パソコンとコーヒー

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

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

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

オープン系開発におけるウォーターフォール型開発の特徴

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

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

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

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

オープン系開発に適したウォーターフォール型開発の流れ
  • 開発範囲を決定し、RFP(提案依頼書)をまとめる
  • 発注先候補に対してオリエンテーションを行う
  • 相見積もりを検討して候補を絞り込んで決定
  • 基本契約書締結
  • 要求定義作成
  • 要件定義作成
  • 外部設計
  • 内部設計
  • 個別契約書作成
  • テスト計画
  • プログラムコーディング開始
  • 単体テスト
  • 結合テスト
  • システムテスト
  • 受入テスト
  • 納品
  • 本稼働
  • 保守・メンテナンス

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

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

オープン系開発におけるアジャイル型開発の特徴

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

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

オープン系開発に適したアジャイル型開発の流れ
  • 発注側と開発側からキーマンを含めた人選で共同開発チームを作ります。
  • 開発側だけでなく、発注側と共同のチームにて、開発範囲全体をいくつもの短い範囲に区分します。
  • 発注側の希望を優先させながら、可能な限り柔軟に業務プロセスの優先度を考慮し、どのプロセスから着手するかを決定します(期間は2週間が目安)。
  • 2週間という期間内に、そのプロセスでの要求の決定、実装、テスト、修正、完成までを行います。
    テストには発注者も加わって、開発陣へ必要なフィードバックします。
  • 完成した機能を評価し、次に着手する優先すべき区分を決めます。

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

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

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

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

レガシーシステムをオープン系システムに移行する流れを知っておこう

パソコンのキーボード

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

レガシーシステム移行計画書作成の重要性

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

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

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

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

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

データ移行のためにプロジェクトチームを発足させる

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

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

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

レガシーシステムからオープン系システムに移行する流れの実際

資料を見ながら会議をする風景

発注側が重要な役割を果たすデータ移行

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

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

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

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

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

オープン系システムへの移行を成功させる開発会社の選び方

様々なアイコンにタッチする男性

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

レガシーシステムからオープンシステムへの移行実績

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

チェックポイント
  • 移行規模
    移行期間、リプレイスした汎用機の数、データ容量など
  • 移行業種
    自社と同じ金融系であるとか、自社と同じ不動産系など、同業種の実績は貴重です
  • 移行業務内容
    自社と同じ顧客管理システムであるとか、自社と同じ営業支援システムなど、同様の業務内容の実績は貴重です

サポート体制が充実しているか

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

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

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

発注側のビジネスプロセス改善を一緒に考えてくれる会社を選ぶ

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

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

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

【まとめ】

握手するビジネスマン

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

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

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

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

いま知りたいこと
コンシェルジュが解決します!

コンシェルジュサービスは
3万社以上が利用している無料の相談サービスです。

コンシェルジュ

発注は時間も手間もかかりますよね?

コンシェルジュが解決します!

コンシェルジュに相談、あなたにあった業者を提案、発注の手間を削減!

完全無料

まずはお気軽にご相談ください