情報システムへのオープンソースソフトウェア導入に関するガイドライン策定
Guideline development about Open-Source Software introduction to information system.
大木 安紀†

大久保 隆夫†

田中 英彦†

Yasunori Ohki

Takao Okubo

Hidehiko Tanaka

1.はじめにトウェアは、企業・組織の基幹システムとなる ERP(Enterprise

本報告では、サーバサイドソフトウェアに特化したオープンResource Planning)・CRM(Customer Relationship Management)などソースアプリケーションソフトウェアの組織内情報システムから、情報共有・コミュニティサイト構築のための CMS(Contentへの導入ガイドライン策定に向けた過程を報告する。

Management System) 、e-learning システムの LMS(Learning
Management System)まで幅広くリリースされている。これは、2.研究の背景
昨今、IT システムのコスト削減等を理由に官公庁・地方公共企業・組織の情報システムを全方位でカバーできる程度ラインナップが増えていることになる。

団体を中心に各業種において Linux などのオープンソースソフトウェアの導入が進んでいる。さらにオープンソースソフトウ

4.オープンソースソフトウェアの問題点

ェアの利用は、DBMS やアプリケーションサーバなどミドルウ

日経コンピュータの記事[1]でオープンソースソフトウェアのェアの領域にまで進展している。さらに、最近では組織内の情導入失敗事例が紹介されている。この事例では、オープンソー

報システムで使用可能な高い完成度を有するオープンソーススソフトウェアの導入により初期コストは削減することがでアプリケーションソフトウェアが開発され、公開されるようにきたが、ベンダに支払うサポート費用がランニングコストを押なった。ソフトウェアには、サーバサイドで動作するタイプとし上げ、トータルでコスト高となったと伝えている。

クライアントサイドで動作するタイプがある。クライアントサ

ユーザ企業がオープンソースソフトウェアに対する主な懸念

イドで動作するアプリケーションの代表としては、ワープロソ

事項は矢野経済研究所の調査[3]によると、人材不足・互換性・フトや表計算ソフトに代表されるオフィスソフトが考えられサポート・実績となっている。

る。オープンソースソフトウェアのオフィスソフトではOpenOffice.org が有名である。しかし、クライアントサイドでは情報を交換する際ファイルという形で交換する場合が多い。そういった場合、Microsoft Office が圧倒的なシェアを獲得しているためオープンソースソフトウェアを導入した場合、オープンソースソフトウェアがオープンスタンダードを採用したとしていてもマーケットシェアの少なさから情報交換を阻害してしまうことが考えられる。しかし、Web ベースのサーバサイドアプリケーションであればクライアント環境に大きな影響を受けることなく導入が可能である。しかし、業務に直結するア

図 1 オープンソースソフトウェアにプリケーションソフトウェアとしてオープンソースソフトウ

対する問題点や不安ェアの導入を考えるとオープンソースというソフトウェアの(矢野経済研究所の調査結果を基に作成[3])特性上、問題が発生する可能性が考えられる。

さらに、ソフトウェアカテゴリ・特性によっては、技術以外そこで、導入時の指標となるべき考慮点をまとめたオープンの問題も発生すると考えられる。例えば ERP であれば日本固ソースソフトウェア導入に関するガイドラインが必要である有の税制への対応や J-SOX 法対応など法令準拠などである。と考えた。

これらの問題点などからソフトウェアカテゴリによってオープンソフトウェアが適用可能な領域、適用が望ましくない領域、

3.オープンソースソフトウェアの現状アプリケーションソフトウェアの領域のオープンソースソフ†

情報セキュリティ大学院大学

さらに導入側組織の特性によって、オープンソースソフトウェ
アの導入可能な組織、導入が望ましくない組織があることが明かとなった。

5.ガイドラインの検討

運用プロセス

ソフトウェアの導入から運用・保守、移行までのソフトウェ

運用者が運用するためのスキルについて考慮する必要があ

アの一生をライフサイクルという。ソフトウェアライフサイクる。利用者に対してヘルプデスクや FAQ 等のサービスを提供

ルをベースにオープンソースソフトウェア導入ガイドラインする必要がある。オープンソースソフトウェアは、ユーザ向けを策定する。ソフトウェアライフサイクルは各所で独自に定義のマニュアルが整備されていない場合がある。そのため、運用されているが、ソフトウェアライスサイクルを標準化したJIS X者側で作成またはそれに準じた作業を行う必要がある。

[2]0160 ソフトウェアライフサイクルプロセス がある。JIS X

保守プロセス

0160 は、ISO/IEC 12207-1996 Information technology - Software life

ソフトウェアに障害が発生した場合に問題を解決するプロ

cycle processes と互換性を持つソフトウェアライフサイクルプセスである。オープンソースソフトウェアは、ソースコードがロセスの国際標準である。JIS X 0160 には、複数のライフサイ公開されているため容易にソフトウェア修正を行うことがでクルプロセスが定義されているが、主にソフトウェアの導入・きる。しかし、導入組織に修正するためのスキル・予算がない

運用・保守に関するライフサイクルプロセスは、主ライフサイ場合には、修正の作業が発生しないようプロダクトを評価するクルプロセスである。主ライフサイクルプロセスのスタックを必要がある。ソフトウェアいずれその使命を終え移行作業が発図 2 に示す。

生する。その際データを移行する必要が発生する。データの保存形式が特殊でないプロダクトを選ぶ必要がある。
取得プロセスで検討すべき事項
各プロセスでオープンソースソフトウェア導入に際しての検討事項を踏まえて、要求定義を満たすオープンソースソフトウェアを調査必要がある。日本語への対応や、バックアップ機能
図 2 JIS X 0160-1996 のの有無、インストーラの整備なども詳しく調査する必要がある。

主ソフトウェアライフサイクルプロセス

オープンソースソフトウェアと商用ソフトウェアを比較し導導入ガイドラインでは、これらの各プロセス内でオープンソ入の判断を行う場合、危険性(サポートがタイムリーに受けらースソフトウェアを主軸とし作業手順を策定し、その作業手順れない可能性・サポート打ち切りの可能性・対応が難しいアッの随所で検討事項を抽出する。

プデートの発生・コミュニティの解散)、費用(運用コストの増

取得プロセスは、オープンソースソフトウェア導入するに当減・修繕費用)、利益(ソフトウェアの導入によって得られる業たって重要なプロセスである。取得プロセスでは、それに続く務効率の向上)等から総合的に判断する必要がある。オープンプロセス内で想定される事柄を事前に把握し導入決定の際にソースソフトウェアを導入する場合には、費用と機能や運用に選択基準としなければならない。この作業が正確に履行されなおいてトレードオフを求められることも考えられる。

かった場合、オープンソースソフトウェアの導入に際して判断を誤るもととなる。

6.終わりに供給プロセス

今後、各プロセスでオープンソースソフトウェアを導入する

ユーザ部門に対してソフトウェアの品質を保証する必要があ際に検討すべき事項を提案した。今後はさらに検討事項を詳細る。オープンソースソフトウェアの場合使用者側で評価を行い、化する。同一の検討事項であっても導入する組織の特性・ソフ品質保証を行う必要がある。また、安全性及びセキュリティ評

トウェアの特性によって選択が変わることが予想される。そこ

価・確保手法、ソフトウェアのライセンスリスクも組織の特性でオープンソースソフトウェアの導入ガイドライン策定後、モに合わせ評価する必要がある。

デルケースに適用し、考察を行いさらにオープンソースソフト開発プロセス

ウェアの導入ガイドラインのブラシアップを行う。

開発プロセスおもに専用ソフトウェアを開発するためプロサポートを受けられるのか・安全に運用保守ができるのかなど

引用文献[1]日経コンピュータ(2006/11/13). 変容するオープンソース.
[2]日本工業標準調査会(1996).ソフトウェアライスサイクルプを含めた安全性仕様、ソフトウェアそのものがセキュアである

ロセス.

かはもとより、ソフトウェアをセキュアに保つことができるか[3]矢野経済研究所(2006). Linux/オープンソースソフトウェアといったセキュリティ仕様、人間工学的仕様等が問題なると考の導入実態と今後の展望 2006.

セスであるが、ソフトウェアへの要求事項についてオープンソースソフトウェア導入する際にも参考になる。ソフトウェアのえられる。