第46回 Prowise Business Forum
株式会社 日立ソリューションズ
OSSソリューションビジネス推進センタ
2010/11/18
吉田 行男
なぜ企業はオープンソースを使わないのか（２）
～導入におけるメリットと安心・安全に活用するポイント～
０ 自己紹介
２０００～
Linuxを活用したビジネス企画に着手
２００３／４
OSSサポートサービスを開始
２００５／１
OSSミドル評価プロジェクトに参画
(JBoss,Tomcatクラスタ評価)
２００５／７
Linuxコンソーシアム参画
２００６～
Linux Foundation SI Forum に参画
(OSSミドルウェア／ツール調査)
２００８／６
オープンソースビジネス推進協議会（OBCI)
立上げに参画
２００９／７
OSSコンソーシアム立上げに参画
→ ２０１０より副会長
１. 章 OSSを取り巻く状況
２. 章 安全・安心に活用するポイント
３. 章 まとめ
～導入におけるメリットと安心・安全に活用するポイント～
なぜ企業はオープンソースを使わないのか（２）
Contents
１.章 OSSを取り巻く状況
～導入におけるメリットと安心・安全に活用するポイント～
１-１ OSSを取り巻く状況
Linux Foundation SI Forumが実施した
2009年度オープンソースソフトウェア導入実績調査から
① 調査概要
調査期間：2010/3 ～ 2010/4
調査対象期間：2009年度(2009/4～2010/3)
参加企業(９社) ：
•
ＮＥＣソフト株式会社
•
エヌ・ティ・ティ・コムウェア株式会社
•
株式会社シーイーシー
•
株式会社日立製作所
•
株式会社日立システムアンドサービス
•
東芝ソリューション株式会社
•
日本アイ･ビー･エム株式会社
•
富士通株式会社
•
レッドハット株式会社
１-１ OSSを取り巻く状況
② 結果
さらに活用範囲が広がるオープンソースソフトウェア
•
『導入実績多数(４社以上)』：
４５
件 →
６６
件へ
運用・管理、開発環境、Web/APサーバでは多くのＯＳＳの
導入実績がアップ
•
「定番化」
及び
「検証」から「導入」へ
の道筋
商用ソフトとの連携がさらに重要に
•
シングルサインオン等
業務アプリ、デスクトップアプリは今後も動きに注目
•
未だ「定番」なし。
ハイアベーラビリティへの期待も膨らむ
•
DRBD
や
UltraMonkey
等の活用頻度の高まり。
着実に使用実績が増えるRuby、Ruby on Rails
•
Ruby関連ビジネスは、完全にテイクオフした！
１-２ 企業が考えるOSS のメリット
各企業が考えるOSS のメリット
出典：IPA 第３回オープンソースソフトウェア活用ビジネス実態調査(2009年度調査)・コスト削減
・ベンダーロックイン回避
・柔軟性
１-３ OSS 普及の阻害要因
OSS 普及の阻害要因
出典：IPA 第３回オープンソースソフトウェア活用ビジネス実態調査(2009年度調査) サポートに対する不安
［OSS のコミュニティにどのように接触してよいかがわからない］
人財及び経験の不足
OSS に総合的に精通した上級技術者の不足
体系的な学習教材不足
ライセンスに対する懸念
大企業ではライセンスが複雑で扱いを誤ると訴訟に発展するリスク
中小企業では社内にライセンスを把握できる人材が不足
１-４ OSS 利用のサポート面の課題
OSS 利用のサポート面の課題(2009年度）
出典：IPA 第３回オープンソースソフトウェア活用ビジネス実態調査(2009年度調査)
コミュニティとの
１-５ OSS 利用のライセンス面の課題
OSS 利用のライセンス面の課題（2009年度）
出典：IPA 第３回オープンソースソフトウェア活用ビジネス実態調査(2009年度調査)ライセンスの
わかりにくさと
訴訟リスク
１-６ OSS 利用のその他の課題
OSS 利用のその他の課題（2009年度）
出典：IPA 第３回オープンソースソフトウェア活用ビジネス実態調査(2009年度調査)
OSS選定基準
必要？
２.章 安全・安心に活用するポイント
～導入におけるメリットと安心・安全に活用するポイント～
２-１ オープンソースのメリット
オープンソースのメリット
安価にシステムを構築できる
機能追加、バグ修正が速い
マルチプラットフォームに対応している
機能追加・バグ修正を自分で行うことも可能
サポートが打ち切られてもお手上げにならない
OSSの特性の理解
適切なOSSの選定
ライセンスへの適切な対処
メリットを最大限
に活かすポイント
２-２ OSSの特性の理解(1)
関連組織・団体の全体像
ユ
ーザ
開発コミュニティ
ディストリビュータ
Linuxカーネル
、ドライバ
GNUソフト
ライブラリ
コマンド
アプリケーション
・ソフトウェア
ApacheなどのOSS日本語フォント/オィ
ススイートなどの
商用ソフトウェア
デ
ィ
ス
ト
リ
ビ
ュ
ーシ
ョ
ン
イ
ン
ス
ト
ー
ラ
・
他
PFベンダ
SIer
総合ベンダ
動作確認済
マ
シ
ン
ハ
ード
ウェ
ア
運用管理ソフトなどの
商用ソフトウェア
構築
シ
ス
テ
ム
業務
ア
プ
リ
ケ
ーシ
ョ
ン
非Linuxマシン
ISV
動作確認済
商用ソフトウェア
(出典：日本OSS推進フォーラム「オープンソースソフトウェアが開発コミュニティからユーザに届くまでの仕組み」より２-２ OSSの特性の理解(2)
14
開発コミュニティ以外のベンダがサポートを提供
(出典：日本OSS推進フォーラム「オープンソースソフトウェアが開発コミュニティからユーザに届くまでの仕組み」よりユーザの自己責任の範囲を選択可能
ユーザ
① ② ③
④
⑤
PFベンダ
SIer
総
合
ベ
ン
ダ
ディストリビュータ
開発コミュニティ/開発企業
作業役割(例)
①
②
③
④
⑤
ディストリビュー
ションの作成
ユーザ
ディスト
リ
ビュータ
ディストリ
ビュータ
ディストリ
ビュータ
ディストリ
ビュータ
ターゲットマシン
へのインストール
ユーザ
ユーザ
PFベンダ
(ディストリ
ビュータ)
PFベンダ
(SIer)
総合ベンダ
ターゲットマシン
での動作確認
ユーザ
ユーザ
ユーザ
PFベンダ
(SIer)
総合ベンダ
様々な機器やソ
フトウェアを利用
したシステムの提
案
ユーザ
ユーザ
ユーザ
SIer
総合ベンダ
システム構築・
評価
ユーザ
ユーザ
ユーザ
SIer
総合ベンダ
運用時の問題切
り分け等
ユーザ
ユーザ
ユーザ
SIer
(ユーザ)
総合ベンダ
(ユーザ)
２-３ 適切なOSSの選定(1)
（１）オープンソースの機能/性能評価
（２）選定における考慮点
技術者/ベンダサポートの有無
プロジェクトの継続性
①
最新バージョンのリリース時期
②
コミュニティの設立からの期間
③
リリース計画
④
サポートポリシー
ソースコードの確保
問題解決ソースの確保
①
インストール手順
②
各種環境を構築するための手順
③
サービスなどの起動／停止手順
④
ライブラリ/APIのリファレンス
⑤
FAQ
適用するOSSを選定するために
２-３ 適切なOSSの選定(2)
異常処理に注意
（１）オープンソースの機能/性能評価
負荷テストは必須。
評価情報の有効利用
【ソフトウェア評価】
QualiPSo Open Source Maturity Model (OMM)
http://www.qualipso.org/
Qualification and Selection of Open Source Software (QSOS)
http://www.qsos.org/
Business Readines Rating (BRR) for Open Source
http://www.openbrr.org/
２-３ 適切なOSSの選定(3)
（２）選定における考慮点
技術者/ベンダサポートの有無
プロジェクトの継続性
ソースコードの確保
問題解決ソースの確保
２-３ 適切なOSSの選定(4)
（２）選定における考慮点
社内に技術者は？
サポートサービスを提供している会社は？
①技術者/ベンダサポートの有無
サポートのないものを
使うことは危険！
２-３ 適切なOSSの選定(5)
②プロジェクトの継続性チェック
最新バージョンのリリース時期
コミュニティの設立からの期間
リリース計画及び
サポートポリシー
6ヶ月前
設立時期が不明な場合、初期バージョンの
リリース時期等を参考に
コミュニティがプロジェクトを継続して活動させていく意思があることを確認。
項目
指標
１年以上
終了予定日の明示
平均的なサポートサービス
期間の明示
２-３ 適切なOSSの選定(6)
２-３ 選定における考慮点(7)
２-３ 選定における考慮点(8)
22
②ソースコードの確保
ソースコードの明確な一次配布先の確保
•コミュニティーのサイト(FTP,HTTP)に存在することが多い。コミュニ
ティーが活動を停止しない限り、確実にソースコードを入手可能。
ソースコードの正当性の確認
•第三者により改ざんされていないことをPGPまたはMD5により
確認する。(2002年に事例あり)
米CERT/CCは米国時間の10月8日、電子メールサーバソフトウェ
ア「Sendmail」のソースコードが改ざんされ、トロイの木馬が仕込
まれている可能性があると警告し、ソースコードの正当性を、PGP
署名やMD5チェックサムを用いて検証すべきとしている。
(http://www.itmedia.co.jp/enterprise/0210/09/n10.html)
２-３ 選定における考慮点(9)
①
バグ/セキュリティ関連情報、サポート情報
②
リリース情報
③
開発者向け情報
④
更新履歴(修正内容の明記も含む
①
インストール手順
②
各種環境を構築するための手順
③
サービスなどの起動／停止手順
④
ライブラリ/APIのリファレンス
⑤
FAQ
③問題解決ソースの確保
システム構築・運用に必要な手順
情報の主な供給元：
コミュニティーのWebサイト、
メーリングリスト、
ニュースグループ等。
システムの安定稼働に関わる情報
２-４ ライセンスへの適切な対処(1)
(1)どんなライセンスがあるのか？
注意！OSSの利用、改造、再配布の方法などが、
ライセンスにより異なる。
ライセンス類型
複製・
再頒布可能
改変可能
改変部分の
ソース公開要
他のコードと組合せた
場合、他のコードの
ソース公開要
GPL
○
○
○
○
MPL
○
○
○
×
BSDライセンス
○
○
×
×
フリーウェア(*)
／シェアウェア
○
×
－
－
商用ソフト
×
×
－
－
(出典：<日本ＯＳＳ推進フォーラム ビジネス推進ＷＧ監修>
ビジネスユースにおけるオープンソースソフトウェアの法的リスクに関する調査」)
２-４ ライセンスへの適切な対処(2)
(2) ライセンス違反とは？(CISCO社の事例)
The story
continues...
が
を２００３年に$５00Mで買収
GPLコードを利用
して
Broadcom’sの標準Linux
コンポーネントをカスタマイズ
コードを組み込み
チップセットの一つに
ブロードコムのチップセット
を
利用してiWRT54G 無線ルータを開発
FSFがCiscoを提訴
ライセンス違反で
全てのソースコード
を開示
開発者がファームウェアを変更し
低価格のルータ ($60) がハイエンド
マシンに生まれ変わった。
一括請負発注
納品
製品組込
M&A
ライセンス違
反
２-４ ライセンスへの適切な対処(3)
(2) ライセンス違反を起こさないために
・ツール等活用による自己評価
・外部コンサルの導入
・BlackDuck社、Palamida社等がソリューション提供
・Linux Foundationが、自己診断チェックリストを提供
２-４ ライセンスへの適切な対処(4)
①
トレーニング、教育
②
ツール
③
自己診断チェックリスト
④
The SPDX™ Standardワークグループ
⑤
コンプライアンス ディレクトリーおよび即時警告システム
⑥
コミュニティ
The Linux Foundation オープン コンプライアンスプログラム
Dependency Checker
動的、静的リンクのレベルでコードの混在を確認する
ツール
Bill of Material (BoM)
Difference Checker
BoM（部品表）の差分確認ツール。
２-４ ライセンスへの適切な対処(5)
２-４ ライセンスへの適切な対処(6)
コアコンプライアンスの構成要素
The Linux Foundation オープン コンプライアンスプログラム
検出と開示
出荷予定の製品に含まれているサードパーティ ライセンス ソフトウェ
ア (オープン ソース ソフトウェアを含む) の識別に関わるプロセス
調査と承認
社外に提供する自社製品のオープンソース使用計画の調査、及び企
業ポリシーによって義務付けられる場合は、社内プロジェクトについ
ても調査を実施。
義務の履行
OSS ライセンス義務を履行するために必要なコンプライアンス プラ
クティス。
コミュニティへの
貢献
従業員によるコミュニティ プロジェクトへの貢献、および企業によるコ
ミュニティ プロジェクトへのコードやその他リソースの貢献について、
調査および承認。
２-４ ライセンスへの適切な対処(7)
サポート項目
ポリシー
事業利益を確保すると同時に、OSS の利用を促進するよう、企業の方針を検討
コンプライアンス要員
の適正配置
コンプライアンス プログラムの履行に必要なスキルを持つ人材を集める
ビジネス プロセスの
適応
既存のビジネス プロセスの文脈に OSS コンプライアンスの諸事項をうまく組み込む
トレーニング
OSS コンプライアンスを履行するために行うべきことを、企業全体が確実に理解するた
めに必要な活動
コンプライアンス プロ
セス管理
「コンプライアンス プロセス管理」は、OSS コンプライアンスを履行するためのプロセス
機能の確立、保守、および改善
OSS インベントリ / 記
録管理
「OSS インベントリ / 記録管理」は、組織のニーズに沿って、OSS コンテンツと OSS コン
プライアンス作業の正確な記録を保持することにより、コンプライアンス照会に対する応
答や、コンプライアンス環境の変化に対応
自動化 / ツール サ
ポート
「自動化 / ツール サポート」は、コンプライアンス作業を支援するために、組織による
ツールの利用や考慮点について分析します。
検証
「検証」は、OSS に関する義務が正しく履行されていることを確認するために、OSS コン
プライアンス チームによって実行される独立した保証措置です。
プロセス順守の監査
「プロセス順守の監査」は、組織がチェックした項目を参照し、定義されたコンプライアン
ス プロセスを利用しているか、および、その利用により、期待した結果が得られている
かを確認します。
２-４ ライセンスへの適切な対処(８)
３.章 まとめ
～導入におけるメリットと安心・安全に活用するポイント～
３．まとめ
コミュニティの理解
OSSの適切な選定
ライセンスに注意
株式会社 日立ソリューションズ
OSSソリューションビジネス推進センタ
～導入におけるメリットと安心・安全に活用するポイント～
なぜ企業はオープンソースを使わないのか（２）
2010/11/18
吉田 行男
END
ご清聴ありがとうございました。
オープンソースソフトウェアで公開されている情報
各種ドキュメント
利用者参加情報
ソースコード
#include <stdio.h> intmain( int argc, char *argv[])
{
int x, y, z, i, j; for (i=0; i<MAXPATH;i++) {
: }
#include <stdio.h> int
main( int argc, char *argv[])
{
int x, y, z, i, j; for (i=0; i<MAXPATH;i++) {
: }
#include <stdio.h> int
main( int argc, char *argv[])
{
int x, y, z, i, j; for (i=0; i<MAXPATH;i++) {
: }
#include <stdio.h> int
main( int argc, char *argv[])
{
int x, y, z, i, j; for (i=0; i<MAXPATH;i++) {
: }
#include <stdio.h> int
main( int argc, char *argv[])
{
int x, y, z, i, j; for (i=0; i<MAXPATH;i++) {
: }
#include <stdio.h> int
main( int argc, char *argv[])
{
int x, y, z, i, j; for (i=0; i<MAXPATH;i++) {
: }
変更履歴
(リポジトリ)
+
マニュアル
ＦＡＱ
サポートフォーラム
メーリングリスト
(アーカイブ)
バグ情報
公開されているのはソースコードだけではありません
バグ情報って何だろう
具体的には修正が必要な事象に関する以下の情報の集まりです
バグはプログラムの問題点
• バグ情報はプログラムをより良くしていくため、主に開発者が利用する情
報です
• 問題点の情報を開発者間や利用者との間で共有します
• 修正方法の提案や修正内容についての議論も含みます
• 多くのOSSプロジェクトでは一般利用者からの報告も受け付けています
• 修正方法の議論や修正結果も公開されています
• 発生現象
• 重要度(深刻度)
• 発生条件・環境(OS, ハードウェア)
• 対象モジュール・機能
• 再現手順
• 回避方法
• 修正方法案
• 修正結果
他
バグトラッキングシステム
バグ報告方法
• バグ情報を管理する専用のバグトラッキングシステム
バグトラッキングシステムとは
• プログラムのバグ発見時に登録し、修正状況を管理するための専用シ
ステムです
• 最近はWebインターフェースを採用するものが主流です
• プロジェクトの進捗管理が可能な機能もあります
• ToDo管理やリリース予定
• バグ情報の分析、未修正一覧
• 定期的なフォローメール
主なバグトラッキングシステム
Bugzilla
http://www.bugzilla.org/
Mozilla Foundationが開発しているOSS
主な採用プロジェクト
•Mozilla project
•Linux Kernel
•Apache Project (httpd, Tomcat他)
•Samba Project
JIRA
http://www.atlassian.com/software/jira/
豪 アトラシアン社が開発したプロプライエタ
リ・ソフトウェア
OSSプロジェクト等には無償で提供される
主な採用プロジェクト
• JBoss
• Spring Framework
• Apache Project (Geronimo, Struts他, 今後の主流)
そのほか
•GNU GNATS
•独自系
•他
引用: Apache Project ASF JIRＡ (https://issues.apache.org/jira/ )より 引用: Mozilla Project Bugzilla (https://bugzilla.mozilla.org/ )より
バグトラッキングシステムの利用場面
注意
バグトラックはあくまでもバグ修正を管理するためのツールです
一般利用者のためのお助けフォーラムではありません
「単なる問い合わせ」のためにバグトラック投稿を行うと開発者に無用な作業を
増やしてしまいます
よくわからない場合は、まずユーザメーリングリスト等を活用しましょう
既存事例の調査
• 誰かが同じことをやってるかも
• 既に直っているかも
• 回避方法があるかも
新しいバグを見つけたので報告
•修正方法がわからなくても（わかればBest)
•開発者に伝える、会話ができる
•今後の開発に活かしてもらえるかも
•記録として残る
検索
コメント投稿
バグ情報
過去検索
投稿して会話
メーリングリスト
＆
やっぱり新しいバグだ
バグかもしれない
• マニュアルと動きが違う
• core dumpした
• ソースの間違いを見つけた
問題発生
使用者
回避策
バグ情報の活用
バグトラックは開発者のためのシステムです
もちろん開発者にとって非常に重要な情報ですが
それだけではありません
ソースコードがわからないと利用価値がない?
開発者以外では活用できない?
活用例(1)定期観測
定期的に参照
障害発生防止に役立てる
予め知っていれば顕在化(実際に問題となること)を防ぐこともできる
使用中のＯＳＳにどれくらい問題が残っているのか把握できる
例えば
• 利用しているバージョン
• 特定のコンポーネントだけ参照
• クローズになった物も検索対象
• 更新された期間を指定(この1ヶ月)
問題調査時とは異なる条件でバグを検索
「今月のバグ一覧」を取得できる
バグ情報の見方
修正されたバグは全てが今すぐ適用すべきものとは限りません
影響しそうなバグがあっても判断ができない場合は専門家に相談しましょう
• ユーザメーリングリストで相談
• サポートを行っている事業者
修正がたくさん…
毎月バグ一覧を見ていると…
•ドキュメントバグ
機能変更に伴う変更漏れ
単なるTypo
•コンパイルできない
特定のOSや環境、コンパイラの場合
新バージョンリリース直後に多い
•機能追加/改善
バグではないが、こうしたほうがいい
•動作上の問題解決
動作不良発生に伴う修正 実際には起きそうもないが論理的に好ましくない「修正されたバグ」を分類
• 本当に問題となるのは多くの場合一部のみ
• 機能名や設定情報を自身のシステムと比べてみましょう
• 設定変更で影響を受けなくできることも多くあります
引用: Apache Projecct Bugzilla (https://issues.apache.org/bugzilla/)より
