オープンソースカンファレンス 2013 Nagoya オープンソース「 … · 2013-06-25 · ・ 2011年の国内ソフトウェア場は 2兆1,235億800万円、前年比成長率マイナス0.5

オープンソースビジネス推進協議会 Copyright©2013OBCI All rights reserved.

Mail ： [email protected] Web： http://www.obci.jp/

オープンソース「超」入門

オープンソースカンファレンス２０１３ Nagoya

オープンソースビジネス推進協議会（OBCI)理事株式会社日立ソリューションズオープンソース技術開発センタ

2013/06/22

吉田行男

オープンソースビジネス推進協議会 Copyright©2013 OBCI All rights reserved.

自己紹介

1

【経歴】入社当時は、金融端末のソフトウェア開発に従事。 2000年頃より、Linux/OSSのビジネス開発を担当。 2012年より、オープンソース技術開発センタセンタ長

【現在の業務】 OSSを活用するビジネスのための支援

• 新しい技術/OSSの発掘・評価検証 • ビジネス・ソリューションの立ち上げ支援 • 現在特にフォーカスしている領域

【社外活動】 OSSコンソーシアム副会長兼クラウド部会リーダオープンソースビジネス推進協議会(OBCI)理事(セミナー担当) Linux Foundation SI Forum リーダ他

クラウドクラウドの運用自動化（CloudStack, OpenStack, …）仮想デスクトップ（VERDE, RHEV-D ,…）

業務バッチ処理基盤既存COBOL資産の活用（OpenCOBOL）業務バッチ処理の高速化（Asakusa Framework）


目次１. オープンソース(ＯＳＳ)とは？２. オープンソースの状況３. オープンソースライセンス４. オープンソース導入時のポイント

2

オープンソースビジネス推進協議会 Copyright©2013 OBCI All rights reserved. 3

１. オープンソース(ＯＳＳ)とは？


１-２オープンソースの定義

4

1.自由な再頒布が出来ること

2.ソースコードを入手できること

3.派生物が存在でき、派生物に同じライセンスを適用できること

4.差分情報の配布を認める場合には、同一性の保持を要求してもかまわない

5.個人やグループを差別しないこと

6.適用領域に対する差別をしないこと

7.再配布において追加ライセンスを必要としないこと

8.特定製品に依存しないこと

9.同じ媒体で配布される他のソフトウェアを制限しないこと

10.技術的な中立を保っていること

■ OSI（※1）が定めるオープンソースの定義 ※1・・Open Source Intiative(オープンソース文化の啓蒙を目的に設立された国際NPO法人）

ポイント

・オープンソース ≠ 著作権を放棄されたソフトウェア・ソースコードがインターネット等で公開されている・再配布の自由と改変の自由がある


ソースコードを公開し、世界中の技術者が同じソフトウェアの開発に取り組むことで、機能・品質を継続的に向上していくことができる

１-３オープンソースの目的

■ なぜ、ソースコードを公開するのか？

ポイントオープンソースの目的はソフトウェアの機能・品質の向上

世界中の利用者達世界中の開発者達

改良公開

フィードバック

品質向上オープンソース

機能向上

5


１-４オープンソース関連組織・団体の全体像(１)

6

統合ベンダ

ユーザ

開発コミュニティ

Linuxカーネルドライバ

GNUソフトライブラリコマンド

アプリケーションソフトウェア

(ApacheなどのOSS)

ディストリビュータ

ディストリビューション

インストーラ

他

非Linuxマシン

日本語フォント/ オフィススイート等の

商用ソフトウェア

運用管理ソフト等の商用ソフトウェア

ISV

動作確認済み商用ソフトウェア

(出典：日本OSS推進フォーラム「オープンソースソフトウェアが開発コミュニティからユーザに届くまでの仕組み」より

PFベンダ

ハードウェア

動作確認済みマシン

SIer

業務アプリ

構築システム

■ 関連組織・団体の全体像


１-４オープンソース関連組織・団体の全体像(２)

7

(出典：日本OSS推進フォーラム「オープンソースソフトウェアが開発コミュニティからユーザに届くまでの仕組み」より

作業役割(例) ① ② ③ ④ ⑤

ディストリビューションの作成

ユーザディストリビュータ




ターゲットマシンへのインストール

ユーザユーザ PFベンダ (ディストリビュータ)

PFベンダ (SIer)

総合ベンダ

ターゲットマシンでの動作確認

ユーザユーザユーザ PFベンダ (SIer)

総合ベンダ

様々な機器やソフトウェアを利用したシステムの提案

ユーザユーザユーザ SIer 総合ベンダ

システム構築・評価

ユーザユーザユーザ SIer 総合ベンダ

運用時の問題切り分け等

ユーザユーザユーザ SIer

(ユーザ)

総合ベンダ

(ユーザ)

① ② ③ ④ ⑤

開発コミュニティ/開発企業

ユーザ

総合ベンダ

SIer

PFベンダ


ポイントユーザが自己責任の範囲を選択することが可能

■ 開発コミュニティ以外によるサポート提供形態


１-５コミュニティとは？

8

「オープンソース・コミュニティ」 – 一般的な「コミュニティ」は、「共同体、集団、地域社会」

– 特定のオープンソース・ソフトウェアの開発や普及活動を行うことを目的とした、人々の集まり

開発コミュニティ – オープンソースを開発するコミュニティ

（例）Seasarプロジェクト、Ruby開発コミュニティ

– 企業がコミュニティを主導する場合もある

（例）MySQL（Oracle）、JBoss（RedHat）

ユーザーコミュニティ – オープンソースを利用するにあたり、情報交換を行ったり、日本

語ドキュメントの作成を行ったりするコミュニティ

（例）日本JBossユーザ・グループ、日本MySQLユーザ会、日本PostgreSQLユーザ会、日本JasperServerユーザ会


１-６オープンソースは大丈夫？

9

オープンソースは品質が悪い？ – 誤解です。 – むしろ、商用製品よりも品質が高いケースもあります。 – 大規模システムへの導入実績も豊富です。

オープンソースは実は高い？ – 誤解です。 – 利用ノウハウがない場合は、有償サポートサービスを活用することで、リスクを低

減しつつ、確実にソフトウェアコストを削減できます。

オープンソースを扱えるエンジニアがいない？ – 誤解です。 – 商用製品を扱えるエンジニアであれば、オープンソースも簡単に扱えます。 – ソースコードレベルのサポートは、有償サポートサービスのご利用をお勧めします。

オープンソースは自己責任？ – 様々な有償サポートサービスがあります。有効に活用しましょう！

■ オープンソースの３つ（＋１）の誤解


２. オープンソースの状況

10


２-１国内市場動向

11

国内ソフトウェア市場動向・ 2010年の国内ソフトウェア市場は2兆1,337億2,300万円。売上額1位はマイクロソフト（シェア

18.3％）、2位は富士通（10.0％）、IBMと日立が同率3位（6.9％）

・ 2011年の国内ソフトウェア市場は2兆1,235億800万円、前年比成長率マイナス0.5％。 2011年5月時点の予測から7.6ポイント上方修正

・公共／教育向けやメインフレーム向けで震災の影響を強く受けるも、事業継続面からのインフラ補強や企業のグローバル対応の加速が成長材料

・ 2010年～2015年の年平均成長率は2.5％、2015年市場規模は2兆4,168億9,700万円と予測。 2013年には2008年時ピークの2兆2,572億8,000万円を超える見込み

国内オープンソースソフトウェア利用実態・ユーザー企業におけるオープンソースソフトウェア（OSS）の最大メリットはコスト削減

・ソリューションプロバイダーの30％以上はOSSプロジェクトが増加傾向

・ OSSの使用実績の多さがITビジネス売上高の増加に繋がっている

・サポートに対する懸念やエンジニア不足の課題を業界挙げて解決していくことが必要

出典：IDC「国内オープンソースソフトウェア利用実態調査結果」

出典：IDC「国内ソフトウェア市場動向および予測」


２-２ OSS導入実績調査(1)

12

Linux Foundation SI Forumが実施した 2011年度オープンソースソフトウェア導入実績調査から

① 調査概要調査期間：2012/3 ～ 2012/4 調査対象期間：2011年度(2011/4～2012/3) 参加企業(8社) ：

• 株式会社日立製作所（日立Grは、日立で纏めて回答） • 株式会社アシスト • 日本電気株式会社／ＮＥＣソフト株式会社 • 日本電信電話株式会社／株式会社ＮＴＴデータ • デル株式会社 • 東芝ソリューション株式会社 • 日本ヒューレット・パッカード株式会社 • 富士通株式会社/株式会社PFU


２-２ OSS導入実績調査（２）

13

分野結果

OS / Distribution Android、Debian、Ubuntuなどが導入され、OS利用の多様化が進行導入実績多数： CentOS, Fedora, Android, Debian, Ubuntu等導入実績あり： LKST, openSUSE, Vine Linux

仮想化 / クラウド「クラウドビジネス」との融合により、大規模な仮想化環境の導入が必要クラウドインフラの費用を圧縮するためOSSのツールへの移行が進展導入実績多数： KVM, Xen, OpenStack 導入実績あり： oVirt, VirtualBox, CloudStack, QEMU等

DB・関連ツール昨今のクラウド・ビッグデータビジネスの影響を色濃く反映 Hadoopの導入実績の増加に合わせ、関連ツール類も増加導入実績多数： PostgreSQL、MySQL 導入実績あり： CDH、memcached

調査結果

全体概況クラウド／仮想化／ビッグデータ関連OSSの導入実績が急速に進んでいる。本年度、検証実績があるCloudForms、CloudFoundryなどは来年は導入実績が予想される。


２-２ OSS導入実績調査（３）

14

最も積極的に投資が進む分野でOSSの活用が活発

– 「クラウド」「ビッグデータ」

分野 OSSツール導入実績社数

クラウド OpenStack ３

CloudStack ２

Eucalyptus ３

ビッグデータ Apache Hadoop ４

Apache Hbase ５

ITのトレンドはOSSが主導し、ベンダが追従する


(*)代表的なOSSの一覧

15

カテゴリ OSS

OS Linux、FedoraCore、CentOS、Android、openSUSE、Debian

仮想化 KVM、Xen

ネットワーク DHCP、Asterisk、OpenSSH、OpenSSL、Squid、BIND

セキュリティ FreeRADIUS、OpenSSH、OpenSSL

ファイルサーバ Samba、NFS、WebDAV、Samba SWAT

運用、管理 Hinemos、MRTG、OpenLDAP、OpenSSO、Zabbix

開発、テスト Hibernate、Perl、PHP、RubyStruts、eXo Platform

DB、関連ツール Apache DB、OpenOLAP、MySQLPostgreSQL

Web、APサーバ Apache、Jboss、Tomcat、zimbra、eXo Platform

Desktop Firefox、openoffice.org、Thunderbird

代表的なOSSの一覧

OSSはたくさんの種類があり、上記は代表的なOSSの一部。 Linuxの普及促進団体であるThe Linux Foudationが、安心して活用できるオープンソースソフトウェアとして、現時点で選別しているものだけでも約400種類存在。


(*)2008年～2010年まで継続的に使われているOSS

16

Apache Ant Python Dbunit PukiWiki Apatche Samba Eclipse WTP qmail

BIND Squid fml qpopper CentOS Apache Struts GanttProject RRDTool CVS Subversion gimp Seasar (S2DAO)

Eclipse Apache Tomcat Hibernate Selenium FedoraCore Trac Apache Jakarta sendmail

Firefox vsftpd Apache Log4J SQLite Apache JMeter Xen MRTG swatch

MySQL rsync MySQL Administrator

Thunderbird

OpenLDAP ab (apacheBench) Nagios Tortoise SVN OpenSSH analog Namazu Ubuntu OpenSSL Apache XML NET-SNMP Ultra Monkey

Perl bonnie Openoffice.org VNC PHP Bugzilla OpenOLAP webmin

Postfix CACTI OpenPNE WIRESHARK PostgreSQL Courier-IMAP pgAdmin III Xoops

企業が中心となって支援しているOSS 団体が中心となっている支援しているOSS


２-３オープンソースの利用状況

17 (OBCI オープンソースカンファレンス2013 Tokyo/Spring OSS「超」入門)

■ 各業界の｢トップ企業グループ｣での利用状況

業種利用しているオープンソース

大手銀行、地銀、信用金庫 Tomcat / JBoss 他

大手証券会社 JBoss / MySQL 他

大手自動車メーカー PostgreSQL 他

大手自動車部品メーカー Apache / Tomcat / JBoss / OpenAM / Liferay 他

大手電子機器メーカー Tomcat / JBoss / MySQL / OpenAM / Liferay 他

大手家電メーカー Tomcat / Subversion / OpenAM 他

大手化学メーカー Tomcat / PostgreSQL 他

通信会社 Tomcat / JBoss / OpenLDAP 他

電力会社、電力会社グループ企業 JBoss / PostgreSQL / OpenAM / Liferay 他

大手流通業 Apace / JBoss / Liferay 他

大手商社 JBoss / MySQL 他

大手メディア企業 JBoss / MySQL 他

大手システムインテグレーター各種OSS 事例多数


２-４オープンソースの適用状況

18 (OBCI オープンソースカンファレンス2013 Tokyo/Spring OSS「超」入門)

■ OSからミドルウェア、業務アプリケーションの領域へ

オペレーティングシステム Linux

Webサーバー Apache

アプリケーションサーバー Tomcat / JBossAS

データベース MySQL / PostgreSQL

シングルサインオン OpenSSO

ポータル Liferay

Bi Jaspersoft

CRM SugarCRM

ERP Compiere / ERP5

オフィススイート

OpenOffice

スマートフォン用プラットフォーム

Android

アプリケーション領域

ミドルウェア領域

オペレーティングシステム

サーバ領域端末領域

情報家電向けLinux


３. オープンソースライセンス

19


３-１オープンソースライセンスの重要キーワード(２)

20

FSF(Free Software Foundation, Inc.)のRichard Stallman氏が提唱プログラム(もしくはその他の著作物)を自由とし、加えてそのプログラム

の改変ないし拡張されたバージョンもすべて自由であることを要求するための、一般的な手法の一つ

オープンソースを入手した者が、それを再頒布したり、改変したりできる自由を保証するもの

■ 「コピーレフト」

Copyright - all rights reserved -

Copyleft - all rights reversed -

ポイントコピーレフトとは、すべてのソフトウェアは誰でも自由に利用・再配布・改変できるべきであるという考え方


３-２オープンソースライセンスの類型(１)

21

■ オープンソースライセンスの類型 (ソースコード公開条件とライセンス波及度合いの観点から分類)

◆ コピーレフト型・・・ GPL(GNU General Public License)類型・コピーレフト性の最も強いライセンス・改変部分のソースコード公開が必要・ライセンス条件の伝播があり、オープンソースと組み合わせたオープンソース以外のソースコード公開の義務がある

◆ 準コピーレフト型・・・ MPL(Mozilla Public License)類型・改変部分のソースコード公開が必須・ライセンス条件の伝播なし・準拠法、裁判管轄、特許権への対応が明示されており法的解釈が明確

◆ 非コピーレフト型・・・ BSDライセンス類型・ソースコードの開示義務がないため、利用者にとっては都合が良い・商用ソフトウェアへの組込みが可能


３-２オープンソースライセンスの類型(２)

22

(出典：<日本ＯＳＳ推進フォーラムビジネス推進ＷＧ監修> 「ビジネスユースにおけるオープンソースソフトウェアの法的リスクに関する調査」)

ライセンス類型代表的なライセンス特徴

コピーレフト型(GPL類型)

GPL (GNU General Public License) • コピーレフト

• ソースコード公開義務

(組合わせたコードにも伝播)

AGPL (GNU Affero General Public License)

European Union Public License

準コピーレフト型

(MPL類型)

LGPL (GNU Lesser General Public License) • 企業開発のオブジェクトコードを企業独自のライセンスで頒布

• ソースコード公開義務

MPL (Mozilla Public License)

Common Development and Distribution License

Apple Public Source License

Eclipse Public License

Common Public License

非コピーレフト型

(BSD ライセンス類型)

BSD License • 最も制約が弱く、開発したソフトウェアの権利が守れない

• ソースコード公開の義務なし

MIT License

ZPL (Zope Public License) V2.0

Apache License

Artistic License (Perl License)

■ 代表的なオープンソースライセンス


３-２オープンソースライセンスの類型(３)

23

ライセンス類型複製・

再頒布可能改変可能

改変部分のソース公開

要

他のコードと組合せた場合、他のコードの

ソース公開要

オープンソース

GPL類型 ○ ○ ○ ○

MPL類型 ○ ○ ○ ×

BSDライセンス類型

○ ○ × ×

フリーウェア(*)／シェアウェア

○ × －－

商用ソフト × × －－

(出典：<日本ＯＳＳ推進フォーラムビジネス推進ＷＧ監修> ビジネスユースにおけるオープンソースソフトウェアの法的リスクに関する調査」)

■ オープンソースライセンス類型の比較

ポイント利用・改造・再配布の方法などがライセンスにより異なる


３-２オープンソースライセンスの類型(４)

24 (出典： Black Duck Software. “Open Source License Data”

45.12%

8.50%8.22%

7.97%

6.77%

6.25%

4.96%

2.41%

1.81% 1.13% 6.86% GNU General Public License (GPL) 2.0

Artistic License (Perl)

MIT License

GNU Lesser General Public License (LGPL) 2.1

GNU General Public License (GPL) 3.0

BSD License 2.0

Apache License 2.0

Code Project Open 1.02 License

Microsoft Public License (Ms-PL)

Mozilla Public License (MPL) 1.1

Others

■ オープンソース利用状況


４. オープンソース導入時のポイント

25


４-１開発工程ごとのポイント(１)

26

ポイントポイントを考慮して選定することで、デメリットを抑えられる

【オープンソース利用のデメリット】 • 緊急時の技術サポートが受けられない • オープンソースに詳しい技術者が少ない

【オープンソース利用のメリット】 • 調達コストの低減、開発効率向上 • ベンダロックインの回避

OSS導入時のポイントを考慮した選定

・システム構成・ライセンス・性能・品質 etc OSS選定ガイドラインの参照


【OSS製品選定/評価】・システム構成 (★) ・ライセンス (★) ・性能・品質 (★) ・ライフサイクル (★) ・情報量 (★) ・保守性 (★)

★OSS特有の選定ポイントを含む箇所

４-１開発工程ごとのポイント(２)

27

システム要件の定義

ハードウェアソフトウェアの選定

基本設計

詳細設計

構築

テスト

運用

【設計・導入】・正しい設計、設定

【テスト】・テストの粒度の調整 (★)

【保守時の情報収集】・コミュニティのチェック (★) ・サポート (★)


４-２ OSS製品選定/評価（１）

28

複数のOSS・製品を組み合わせる場合、バージョン依存の問題が発生し得る

(1) システム構成

Apache HTTP Server (Webサーバ)

J2EE

MySQL (Database)

Struts (P層フレームワーク)

ロジック

Tomcat (Servlet コンテナ)

J2SE

Apache Commons(ユーティリティ)

MySQL Connector/J (Database コネクタ)

：コンポーネントのバージョンによって問題が発生し得る箇所

ポイント OSS内で利用されているコンポーネントのバージョンを調査し、バージョン依存の問題が発生しないコンポーネントを選定する


４-２ OSS製品選定/評価（２）

29

(２) 性能・品質 OSSを利用して、十分な性能が出るか検証が必要

ポイント従来の製品選定と同様に、「単体で十分な性能が出るか」「前提ソフトウェアと組合わせて十分な性能が出るか」検証する

バグやセキュリティ脆弱性の発生頻度と修正状況、安定して動作するバージョンを調査する

異常処理には注意

負荷テストは必須

評価情報の有効利用

オープンソース＝性能十分

ＯＫ！オープンソース＝

性能不足

ＮＧ＋


４-２ OSS製品選定/評価（３）

30

システム全体のライフサイクル

そのため、どれくらいの期間システムが利用されるのか顧客要望を聞く

◆ 1～2年間しか利用されないシステム

◆ 5年間以上利用されるシステム

コミュニティ活動が活発 → 情報が豊富 → Ｑ＆Ａの反応が早い → 不具合の修正が早い

運用中のシステムで利用しているOSSの開発が停止する可能性がある

* EOL:End Of Lifecycle

アップデート修正パッチ

OSSコミュニティ

OSS

保守担当

EOL(OSS寿命) OSSコミュニティ

OSS

保守担当

コミュニティ活動が停止 → バグ修正のコスト増 → バグ修正が不可能

(３) ライフサイクル



31

OSSのライフサイクル

旧バージョン

メジャーバージョンのリリース直後

安定期 EOL後

リリース EOL

次期バージョン

OSSでは、新機能の追加やUI変更の際にメジャーバージョンアップを行うその際、前バージョンの開発は一定期間で終了することが多いため注意が必要である

◆ OSSのライフサイクルは主に次の３つに分けられる

・メジャーバージョンのリリース直後・安定期・EOL後

◆ OSSのライフサイクルの一例

* ライフサイクルポリシーはOSSそれぞれで異なるため、確認する



32

ライフサイクルの時期ごとのリスク

◆ メジャーバージョンのリリース直後

旧バージョン


安定期 EOL後

リリース EOL


新たな機能の追加を目的とした大きなバージョンアップの直後の状態

問題点

・機能追加や再実装の際に入り込んだ不具合が残っている

・UIの変更により、求めている機能がどこにあるか分からない

・APIや実装の変更により、旧システムとの連携に失敗する

→メジャーバージョンリリース直後のOSSの利用は避ける



33

◆ 安定期

旧バージョン


安定期 EOL後

リリース EOL


実装が安定し、不具合があまり発生しなくなった状態

・前提ソフトウェアとの連携で発生する不具合が少なくなる

・インターネット上の情報や技術書が出回り、学習が容易になる

・マイナーバージョンを見直すことが少なくなるメリット

→利用時のリスクが少ない



34

◆ EOL後

旧バージョン


安定期 EOL後

リリース EOL


次期バージョンの開発が活発化し、現行バージョンのリリースが打ち切られた後の状態

問題点・不具合や脆弱性が見つかった場合でも対応されない

→ EOLを過ぎたOSSを利用する場合は、対策が必要


４-２ OSS製品選定/評価（４）

35

(４) 情報量

◆ 実績のある製品、実績のあるOSS(有償サポート契約済み)

◆ 実績のあるOSS(サポートなし)

◆ 実績のないOSS

学習コストは低い

→製品マニュアル、技術サポート窓口を備えている

学習コストは比較的低い

→インターネット上の情報、日本語の解説書が豊富にある

→利用経験のある社内の部署とノウハウを共有できる

学習コストは高いため、OSSに詳しい人がいない場合は利用を避ける →英語のドキュメントしか公開されていない

→ソースコードを読まないと仕様が分からない

→技術的な問い合わせ先がない

OSSごとに情報量に格差があるため、学習コストを考慮する必要がある



36

■ 問題解決ソースの確保

【システム構築・運用に必要な手順】 ① インストール手順 ② 各種環境を構築するための手順 ③ サービスなどの起動/停止手順 ④ ライブラリ/ＡＰＩのリファレンス ⑤ Ｑ＆Ａ

【システムの安定稼動に関わる情報】

① バグ/セキュリティ関連情報、サポート情報 ② リリース情報 ③ 開発者向け情報 ④ 更新履歴(修正内容の明記も含む)

情報の主な提供元コミュニティのWebサイトメーリングリストニュースグループ等



37

OSSコミュニティが公開している情報(バグ、セキュリティ脆弱性の発生状況と修正状況)を参照することで、OSSの品質の判断基準にできる

ポイント・OSSの品質の判断基準の1つとして、オープンソースコミュニティが公開している情報を利用できる

■ OSSコミュニティが公開する情報


４-２ OSS製品選定/評価（５）

38

OSSとして公開されている製品を利用する場合

OSSに詳しい開発者がいない場合、「OSSとして公開されている製品」や「有償サポート契約」の利用も検討する

OSSとして公開されている製品を利用する →ex. Red Hat Enterprise Linux

メリット・OSSの品質は開発元が保証する・開発元にバグ情報を提供することで、パッチを入手できる・マニュアルなどの技術情報が豊富である

(５) 保守性

パッケージ購入

・アップデート・物理媒体・マニュアル・Q&A対応・パッチ

・バグ情報・技術的な質問

OSSとして公開

OSS

保守担当開発元

第三者



39

有償サポート契約を結ぶ場合

・OSSの品質はベンダが保証する・ベンダにバグ情報を提供することで、パッチを入手できる・コミュニティの動向を常に調査する必要がない・ベンダ経由でOSSコミュニティに働きかけてバグを修正するよう促すことができる・顧客は問題解決の支援を受けることができる

メリット

有償サポートサービスを提供するベンダとサポート契約を結ぶ

有償サポート契約

OSS

保守担当ベンダ・バグ情報・技術的な質問

・パッチ・Ｑ＆Ａ対応



40

有償サポート契約を結ばない場合

OSSコミュニティが提供している情報(パッチ、掲示板、メーリングリスト)を参照して、開発・運用を行う

問題点

・コミュニティの動向を常にチェックし続ける必要がある・品質の保証がない・コミュニティの活動状況に左右される →ex. 質問に対して回答がない。バグが修正されない

OSS

保守担当・バグ報告・技術的な質問

・パッチ・Ｑ＆Ａ対応

ベンダ


４-３設計/導入

41

(１) OSSの利用範囲を明確にする

OSSの利用範囲を明確にしないまま開発作業を行った場合、問題が発生した場合の原因の切り分けが困難になる

ポイント・開発/保守作業を効率化するため、クラス図、シーケンス図を作成する際にOSSの利用範囲を明確にしておく。


４-４テスト

42

(１) テストの粒度

OSSの実績テスト項目ありなし

単体テスト △ ○

結合テスト ○ ○

○：実施する △：利用実績がない場合は実施する

結合テスト自社開発部分と組み合わせる部分を中心に必ず実施する

単体テスト実績のあるOSS：プロジェクトの特性や顧客要望を考慮して実施する

実績のないOSS：利用する機能のみを単体テストする

実績のないOSSを利用する場合、テスト工程で綿密なテストを実施することで、性能・品質を確保する必要がある


４-５運用

43

(１) 保守時の情報収集製品とOSSで不具合発生時に必要になるコストが異なる

評価項目種別

ソフトウェア保守契約

サポートサービス (情報提供、問題解決)

ソフトウェアの不具合修正

製品結ぶ ― 開発元が修正する

結ばない ― 修正されない

OSS ― 結ぶ

ベンダから支援を受けて独自に修正する

― 結ばない独自に修正する

ポイント・ OSSの有償サポート契約を結ばなかった場合、OSSコミュニティの情報を元に利用者が自力解決する必要がある


４-６その他の考慮点(１)

44

(１) プロジェクトの継続性チェックコミュニティがプロジェクトを継続して活動させていく意思があることを確認

＃項目指標

１最新バージョンのリリース時期

６ヶ月前以降

２コミュニティ設立からの期間

１年以上 ※設立時期が不明な場合は初期バージョンのリリース時期を参考にする

３リリース計画およびサポートポリシー

終了予定日の明示平均的なサポートサービス期間の明示



45

◆ (御参考) プロジェクトの継続性チェック(１)



46

◆ (御参考) プロジェクトの継続性チェック(２)


４-６その他の考慮点(２)

47

◆ (御参考) OSSレーダースコープ (http://radar.oss.scsk.info/)

オープンソースビジネス推進協議会 Copyright©2013OBCI All rights reserved.

Mail ： [email protected] Web： http://www.obci.jp/

『OSS』超入門

END

48

http://www.obci.jp/

Documents

オープンソースカンファレンス 2013 Nagoya オープンソース「 … · 2013-06-25 · ・ 2011年の国内ソフトウェア場は 2兆1,235億800万円、前年比成長率マイナス0.5