第 46 回 Prowise Business Forum なぜ企業はオープンソースを使わないのか (2) ~ 導入におけるメリットと安心 安全に活用するポイント ~ 2010/11/18 株式会社日立ソリューションズ OSS ソリューションビジネス推進センタ 吉田行男
0 自己紹介 2000~ Linux を活用したビジネス企画に着手 2003/4 OSS サポートサービスを開始 2005/1 OSS ミドル評価プロジェクトに参画 (JBoss,Tomcat クラスタ評価 ) 2005/7 Linux コンソーシアム参画 2006~ Linux Foundation SI Forum に参画 (OSS ミドルウェア / ツール調査 ) 2008/6 オープンソースビジネス推進協議会 (OBCI) 立上げに参画 2009/7 OSS コンソーシアム立上げに参画 2010 より副会長 1
なぜ企業はオープンソースを使わないのか (2) ~ 導入におけるメリットと安心 安全に活用するポイント~ Contents 1. 章 OSSを取り巻く状況 2. 章安全 安心に活用するポイント 3. 章まとめ
なぜ企業はオープンソースを使わないのか (2) ~ 導入におけるメリットと安心 安全に活用するポイント~ 1. 章 OSS を取り巻く状況
1-1 OSS を取り巻く状況 Linux Foundation SI Forum が実施した 2009 年度オープンソースソフトウェア導入実績調査から 1 調査概要 調査期間 :2010/3 ~ 2010/4 調査対象期間 :2009 年度 (2009/4~2010/3) 参加企業 (9 社 ) : NEC ソフト株式会社 エヌ ティ ティ コムウェア株式会社 株式会社シーイーシー 株式会社日立製作所 株式会社日立システムアンドサービス 東芝ソリューション株式会社 日本アイ ビー エム株式会社 富士通株式会社 レッドハット株式会社 4
1-1 OSS を取り巻く状況 2 結果 さらに活用範囲が広がるオープンソースソフトウェア 導入実績多数 (4 社以上 ) :45 件 66 件へ 運用 管理 開発環境 Web/AP サーバでは多くの OSS の導入実績がアップ 定番化 及び 検証 から 導入 への道筋 商用ソフトとの連携がさらに重要に シングルサインオン等 業務アプリ デスクトップアプリは今後も動きに注目 未だ 定番 なし ハイアベーラビリティへの期待も膨らむ DRBD や UltraMonkey 等の活用頻度の高まり 着実に使用実績が増える Ruby Ruby on Rails Ruby 関連ビジネスは 完全にテイクオフした! 5
1-2 企業が考える OSS のメリット 各企業が考える OSS のメリット コスト削減 ベンダーロックイン回避 柔軟性 出典 :IPA 第 3 回オープンソースソフトウェア活用ビジネス実態調査 (2009 年度調査 ) 6
1-3 OSS 普及の阻害要因 OSS 普及の阻害要因 サポートに対する不安 [OSS のコミュニティにどのように接触してよいかがわからない ] ライセンスに対する懸念大企業ではライセンスが複雑で扱いを誤ると訴訟に発展するリスク中小企業では社内にライセンスを把握できる人材が不足 人財及び経験の不足 OSS に総合的に精通した上級技術者の不足体系的な学習教材不足 出典 :IPA 第 3 回オープンソースソフトウェア活用ビジネス実態調査 (2009 年度調査 ) 7
1-4 OSS 利用のサポート面の課題 OSS 利用のサポート面の課題 (2009 年度 ) コミュニティとの付き合い方 出典 :IPA 第 3 回オープンソースソフトウェア活用ビジネス実態調査 (2009 年度調査 ) 8
1-5 OSS 利用のライセンス面の課題 OSS 利用のライセンス面の課題 (2009 年度 ) ライセンスのわかりにくさと訴訟リスク 出典 :IPA 第 3 回オープンソースソフトウェア活用ビジネス実態調査 (2009 年度調査 ) 9
1-6 OSS 利用のその他の課題 OSS 利用のその他の課題 (2009 年度 ) OSS 選定基準必要? 出典 :IPA 第 3 回オープンソースソフトウェア活用ビジネス実態調査 (2009 年度調査 ) 10
なぜ企業はオープンソースを使わないのか (2) ~ 導入におけるメリットと安心 安全に活用するポイント~ 2. 章安全 安心に活用するポイント
2-1 オープンソースのメリット オープンソースのメリット 安価にシステムを構築できる 機能追加 バグ修正が速い マルチプラットフォームに対応している 機能追加 バグ修正を自分で行うことも可能 サポートが打ち切られてもお手上げにならない メリットを最大限に活かすポイント OSS の特性の理解適切な OSS の選定ライセンスへの適切な対処 12
ユーザ開発コミュニティ 務アプリーション非 Linux マシン ードウェア運用管理ソフトなどの 築システム2-2 OSS の特性の理解 (1) 関連組織 団体の全体像 アプリケーション ソフトウェア Apache などの OSS GNU ソフトライブラリコマンド Linux カーネル ドライバ ISV 日本語フォント / オィススイートなどの商用ソフトウェア 商用ソフトウェア ディストリビュータ ディストリビューションインストーラ 他動作確認済商用ソフトウェア ハPFベンダ作確認済マシン総合ベンダ動ケ業SIer 構( 出典 : 日本 OSS 推進フォーラム オープンソースソフトウェアが開発コミュニティからユーザに届くまでの仕組み より 13
2-2 OSS の特性の理解 (2) 開発コミュニティ以外のベンダがサポートを提供 ユーザの自己責任の範囲を選択可能 ユーザ 1 2 3 4 5 SIer PF ベンダ 総合ベンダディストリビュータ 作業役割 ( 例 ) 1 2 3 4 5 ディストリビューションの作成 ターゲットマシンへのインストール ターゲットマシンでの動作確認 ユーザ ディストリビュータ ディストリビュータ ユーザ ユーザ PFベンダ ( ディストリ ビュータ ) ディストリビュータ PF ベンダ (SIer) ユーザ ユーザ ユーザ PFベンダ (SIer) ディストリビュータ 総合ベンダ 総合ベンダ 開発コミュニティ / 開発企業 様々な機器やソフトウェアを利用したシステムの提案 システム構築 評価 運用時の問題切り分け等 ユーザユーザユーザ SIer 総合ベンダ ユーザユーザユーザ SIer 総合ベンダ ユーザ ユーザ ユーザ SIer ( ユーザ ) 総合ベンダ ( ユーザ ) ( 出典 : 日本 OSS 推進フォーラム オープンソースソフトウェアが開発コミュニティからユーザに届くまでの仕組み より 14
2-3 適切な OSS の選定 (1) 適用する OSS を選定するために (1) オープンソースの機能 / 性能評価 (2) 選定における考慮点 技術者 / ベンダサポートの有無プロジェクトの継続性 1 2 3 4 最新バージョンのリリース時期コミュニティの設立からの期間リリース計画サポートポリシー ソースコードの確保問題解決ソースの確保 1 2 3 4 5 インストール手順各種環境を構築するための手順サービスなどの起動 / 停止手順ライブラリ /APIのリファレンス FAQ 15
2-3 適切な OSS の選定 (2) (1) オープンソースの機能 / 性能評価 異常処理に注意 負荷テストは必須 評価情報の有効利用 ソフトウェア評価 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/ 16
2-3 適切な OSS の選定 (3) (2) 選定における考慮点 技術者 / ベンダサポートの有無 プロジェクトの継続性 ソースコードの確保 問題解決ソースの確保 17
2-3 適切な OSS の選定 (4) (2) 選定における考慮点 1 技術者 / ベンダサポートの有無社内に技術者は? サポートサービスを提供している会社は? サポートのないものを 使うことは危険! 18
2-3 適切な OSS の選定 (5) 2 プロジェクトの継続性チェック コミュニティがプロジェクトを継続して活動させていく意思があることを確認 項目 最新バージョンのリリース時期 指標 6 ヶ月前 コミュニティの設立からの期間 リリース計画及びサポートポリシー 1 年以上 設立時期が不明な場合 初期バージョンのリリース時期等を参考に 終了予定日の明示平均的なサポートサービス期間の明示 19
2-3 適切な OSS の選定 (6) プロジェクトの継続性チェック例 1 20
2-3 選定における考慮点 (7) プロジェクトの継続性チェック例 2 21
2-3 選定における考慮点 (8) 2 ソースコードの確保 ソースコードの明確な一次配布先の確保 コミュニティーのサイト (FTP,HTTP) に存在することが多い コミュニティーが活動を停止しない限り 確実にソースコードを入手可能 ソースコードの正当性の確認 第三者により改ざんされていないことを PGP または MD5 により確認する (2002 年に事例あり ) 米 CERT/CC は米国時間の 10 月 8 日 電子メールサーバソフトウェア Sendmail のソースコードが改ざんされ トロイの木馬が仕込まれている可能性があると警告し ソースコードの正当性を PGP 署名や MD5 チェックサムを用いて検証すべきとしている (http://www.itmedia.co.jp/enterprise/0210/09/n10.html) 22
2-3 選定における考慮点 (9) 3 問題解決ソースの確保 システム構築 運用に必要な手順 1 インストール手順 2 各種環境を構築するための手順 3 サービスなどの起動 / 停止手順 4 ライブラリ /APIのリファレンス 5 FAQ システムの安定稼働に関わる情報 情報の主な供給元 : コミュニティーの Web サイト メーリングリスト ニュースグループ等 1 2 3 4 バグ / セキュリティ関連情報 サポート情報リリース情報開発者向け情報更新履歴 ( 修正内容の明記も含む 23
2-4 ライセンスへの適切な対処 (1) (1) どんなライセンスがあるのか? ライセンス類型 複製 再頒布可能 改変可能 改変部分のソース公開要 注意!OSS の利用 改造 再配布の方法などが ライセンスにより異なる 他のコードと組合せた場合 他のコードのソース公開要 GPL MPL BSD ライセンス フリーウェア (*) / シェアウェア - - 商用ソフト - - ( 出典 :< 日本 OSS 推進フォーラムビジネス推進 WG 監修 > ビジネスユースにおけるオープンソースソフトウェアの法的リスクに関する調査 ) 24
2-4 ライセンスへの適切な対処 (2) (2) ライセンス違反とは?(CISCO 社の事例 ) GPL コードを利用して Broadcom s の標準 Linux コンポーネントをカスタマイズ 製品組込 一括請負発注納品 コードを組み込みチップセットの一つに M&A 全てのソースコードを開示 FSF が Cisco を提訴ライセンス違反で ブロードコムのチップセットを利用して iwrt54g 無線ルータを開発 ライセンス違反 The story continues... が を 2003 年に $500M で買収 開発者がファームウェアを変更し低価格のルータ ($60) がハイエンドマシンに生まれ変わった 25
2-4 ライセンスへの適切な対処 (3) (2) ライセンス違反を起こさないために 外部コンサルの導入 BlackDuck 社 Palamida 社等がソリューション提供 ツール等活用による自己評価 Linux Foundation が 自己診断チェックリストを提供 26
2-4 ライセンスへの適切な対処 (4) The Linux Foundation オープンコンプライアンスプログラム 1 2 トレーニング 教育ツール Dependency Checker Bill of Material (BoM) Difference Checker The Code Janitor 動的 静的リンクのレベルでコードの混在を確認するツール BoM( 部品表 ) の差分確認ツール 不適切なコメントを残していないか確認ツール 3 4 5 6 自己診断チェックリスト The SPDX Standardワークグループコンプライアンスディレクトリーおよび即時警告システムコミュニティ 27
2-4 ライセンスへの適切な対処 (5) 自己診断チェックリストの考え方 28
2-4 ライセンスへの適切な対処 (6) The Linux Foundation オープンコンプライアンスプログラム コアコンプライアンスの構成要素 検出と開示 調査と承認 義務の履行 コミュニティへの貢献 出荷予定の製品に含まれているサードパーティライセンスソフトウェア ( オープンソースソフトウェアを含む ) の識別に関わるプロセス 社外に提供する自社製品のオープンソース使用計画の調査 及び企業ポリシーによって義務付けられる場合は 社内プロジェクトについても調査を実施 OSS ライセンス義務を履行するために必要なコンプライアンスプラクティス 従業員によるコミュニティプロジェクトへの貢献 および企業によるコミュニティプロジェクトへのコードやその他リソースの貢献について 調査および承認 29
2-4 ライセンスへの適切な対処 (7) サポート項目 ポリシー コンプライアンス要員の適正配置 ビジネスプロセスの適応 トレーニング コンプライアンスプロセス管理 OSS インベントリ / 記録管理 自動化 / ツールサポート 検証 プロセス順守の監査 事業利益を確保すると同時に OSS の利用を促進するよう 企業の方針を検討 コンプライアンスプログラムの履行に必要なスキルを持つ人材を集める 既存のビジネスプロセスの文脈に OSS コンプライアンスの諸事項をうまく組み込む OSS コンプライアンスを履行するために行うべきことを 企業全体が確実に理解するために必要な活動 コンプライアンスプロセス管理 は OSS コンプライアンスを履行するためのプロセス機能の確立 保守 および改善 OSS インベントリ / 記録管理 は 組織のニーズに沿って OSS コンテンツと OSS コンプライアンス作業の正確な記録を保持することにより コンプライアンス照会に対する応答や コンプライアンス環境の変化に対応 自動化 / ツールサポート は コンプライアンス作業を支援するために 組織によるツールの利用や考慮点について分析します 検証 は OSS に関する義務が正しく履行されていることを確認するために OSS コンプライアンスチームによって実行される独立した保証措置です プロセス順守の監査 は 組織がチェックした項目を参照し 定義されたコンプライアンスプロセスを利用しているか および その利用により 期待した結果が得られているかを確認します 30
2-4 ライセンスへの適切な対処 (8) チェックリストサンプル 31
なぜ企業はオープンソースを使わないのか (2) ~ 導入におけるメリットと安心 安全に活用するポイント~ 3. 章まとめ
3. まとめ OSS を安全 安心に使うためには コミュニティの理解 OSS の適切な選定 ライセンスに注意 33
ご清聴ありがとうございました END なぜ企業はオープンソースを使わないのか (2) ~ 導入におけるメリットと安心 安全に活用するポイント~ 2010/11/18 株式会社日立ソリューションズ OSS ソリューションビジネス推進センタ 吉田行男
付録 35
オープンソースソフトウェアで公開されている情報 公開されているのはソースコードだけではありません ソースコード <stdio.h> int#include <stdio.h> main( int#include argc, <stdio.h> char *argv[]) main( int#include argc, <stdio.h> char { *argv[]) main( int#include <stdio.h> argc, char { int *argv[]) main( int#include <stdio.h> int argc, char x, y, z, i, j; for { int *argv[]) main( int int argc, char (i=0; x, i<maxpath;i++) y, z, i, j; { for { *argv[]) main( int argc, char int (i=0; x, i<maxpath;i++) y, z, i, j; { *argv[]) { for int (i=0; x, i<maxpath;i++) y, z, i, j; { : { for int (i=0; x, i<maxpath;i++) y, z, i, j; } : { for int (i=0; x, i<maxpath;i++) y, z, i, j; { } for (i=0; : i<maxpath;i++) { } : } : } : } + 変更履歴 ( リポジトリ ) 利用者参加情報 メーリングリスト ( アーカイブ ) 各種ドキュメント マニュアル FAQ バグ情報 サポートフォーラム 36
バグ情報って何だろう バグはプログラムの問題点 バグ情報はプログラムをより良くしていくため 主に開発者が利用する情報です 問題点の情報を開発者間や利用者との間で共有します 修正方法の提案や修正内容についての議論も含みます 多くの OSS プロジェクトでは一般利用者からの報告も受け付けています 修正方法の議論や修正結果も公開されています 具体的には修正が必要な事象に関する以下の情報の集まりです 発生現象 重要度 ( 深刻度 ) 発生条件 環境 (OS, ハードウェア ) 対象モジュール 機能 再現手順 回避方法 修正方法案 修正結果 他 37
バグトラッキングシステム バグ報告方法 E-mail バグ情報を管理する専用のバグトラッキングシステム バグトラッキングシステムとは プログラムのバグ発見時に登録し 修正状況を管理するための専用システムです 最近は Web インターフェースを採用するものが主流です プロジェクトの進捗管理が可能な機能もあります ToDo 管理やリリース予定 バグ情報の分析 未修正一覧 定期的なフォローメール 38
主なバグトラッキングシステム 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 他, 今後の主流 ) 引用 : Mozilla Project Bugzilla (https://bugzilla.mozilla.org/ ) より そのほか GNU GNATS 独自系 他 引用 : Apache Project ASF JIRA (https://issues.apache.org/jira/ ) より 39
バグトラッキングシステムの利用場面 問題発生 既存事例の調査 誰かが同じことをやってるかも 既に直っているかも 回避方法があるかも バグ情報 メーリングリスト 使用者 バグかもしれない マニュアルと動きが違う core dump した ソースの間違いを見つけた 回避策 検索コメント投稿 過去検索投稿して会話 新しいバグを見つけたので報告 修正方法がわからなくても ( わかれば Best) 開発者に伝える 会話ができる 今後の開発に活かしてもらえるかも 記録として残る 注意バグトラックはあくまでもバグ修正を管理するためのツールです一般利用者のためのお助けフォーラムではありません 単なる問い合わせ のためにバグトラック投稿を行うと開発者に無用な作業を増やしてしまいますよくわからない場合は まずユーザメーリングリスト等を活用しましょう & やっぱり新しいバグだ 40
バグ情報の活用 バグトラックは開発者のためのシステムです ソースコードがわからないと利用価値がない? 開発者以外では活用できない? もちろん開発者にとって非常に重要な情報ですがそれだけではありません 41
活用例 42
活用例 (1) 定期観測 定期的に参照障害発生防止に役立てる予め知っていれば顕在化 ( 実際に問題となること ) を防ぐこともできる使用中の OSS にどれくらい問題が残っているのか把握できる 問題調査時とは異なる条件でバグを検索 例えば 利用しているバージョン 特定のコンポーネントだけ参照 クローズになった物も検索対象 更新された期間を指定 ( この 1 ヶ月 ) 今月のバグ一覧 を取得できる 引用 : Apache Projecct Bugzilla ( https://issues.apache.org/bugzilla/ ) より 43
バグ情報の見方 毎月バグ一覧を見ていると 修正がたくさん 引用 : Apache Projecct Bugzilla (https://issues.apache.org/bugzilla/) より 修正されたバグ を分類 ドキュメントバグ機能変更に伴う変更漏れ単なる Typo コンパイルできない特定の OS や環境 コンパイラの場合新バージョンリリース直後に多い 機能追加 / 改善バグではないが こうしたほうがいい 動作上の問題解決動作不良発生に伴う修正実際には起きそうもないが論理的に好ましくない 本当に問題となるのは多くの場合一部のみ 機能名や設定情報を自身のシステムと比べてみましょう 設定変更で影響を受けなくできることも多くあります 修正されたバグは全てが今すぐ適用すべきものとは限りません 影響しそうなバグがあっても判断ができない場合は専門家に相談しましょう ユーザメーリングリストで相談 サポートを行っている事業者 44
バグ情報取得の工夫 バグトラッキングシステムでは CSV 等で一覧を取得できるので再利用しやすくすることも可能です Apache (Bugzilla) 検索画面も結果一覧 MySQL Bugs もバラバラ別プロジェクトだから当然だが CSV でローカル DB に自動取り込み今月 Close になったものを強調独自フォーマットで HTML 表示 引用 : Apache Projecct Bugzilla (https://issues.apache.org/bugzilla/) より ローカルバグ DB 引用 : MySQL Bugs (http://bigs.mysql.org/ ) より 今月のバグが一目瞭然 とりあえずこれだけはチェックしておこうか 45
活用例 (2) 統計分析 バグ情報の統計 バグ報告や修正の件数を見てみることで開発の活発さやプログラムの成熟度の一端を知ることが出来ます バグ報告が多いということは バグ報告バグ報告バグ報告バグ報告バグ報告バグ報告利用者利用者利用者利用者利用者利用者 問題が多いかも? 利用者も多い 修正が多いということは バグ バグ バグ バグ バグ バグ バグ バグ 開発者開発者開発者 実際に問題が多かった メンテナンスが活発に行われている 46
統計の実例 実際に OSS で毎日報告される新規バグ報告と修正されたバグの件数を月別に集計したものを他の情報と合わせて見てみます 注意以後の図のコメントは個人的な見解です プロジェクトやプログラムの客観的な評価を示すものではありません 47
Apache HTTP 2.0 のバグトラック集計 40 2.0.58 Apache 2.0.x 2.0.61 新規報告 FIXED 35 2.0.59 2.0.63 30 25 報告も修正もほとんどなくなってきている リリース間隔が非常に長く最近リリースがない 2.2 に移行を考えるか 20 15 10 5 0 2005.12 2006.02 2006.04 2006.06 2006.08 2006.10 2006.12 2007.02 2007.04 2007.06 2007.08 2007.10 2007.12 2008.02 2008.04 2008.06 2008.08 2008.10 2008.12 2009.02 2009.04 2009.06 Apache Projecct Bugzilla ( https://issues.apache.org/bugzilla/ ) より集計 48
Apache HTTP 2.2 のバグトラック集計 40 Apache 2.2.x 新規報告 FIXED 2.2.0 2.2.4 2.2.6 2.2.9 2.2.12 2.2.2 2.2.8 2.2.10 35 2.2.3 2.2.11 30 25 報告件数増加傾向 ユーザ増加中? 修正も多いが頻繁にリリースされている 今まさに旬? 20 15 10 5 0 2005.12 2006.02 2006.04 2006.06 2006.08 2006.10 2006.12 2007.02 2007.04 2007.06 2007.08 2007.10 2007.12 2008.02 2008.04 2008.06 2008.08 2008.10 2008.12 2009.02 2009.04 2009.06 Apache Projecct Bugzilla ( https://issues.apache.org/bugzilla/ ) より集計 49
MySQL server 5 のバグトラック集計 200 180 160 140 120 MySQL 5 (5.0.x, 5.1.x を含む ) 新規報告 5.0.15GA 5.0.33 5.0.51 5.0.67 5.0.75 5.0..37 5.0.77 5.0.18 5.0.51a 5.0.82 5.0..24 5.0..41 5.0..19 5.1.30GA 5.0.45 5.0.83 5.0..27 5.0..20 5.0.84 報告件数も修正件数も減少し現在は 5.0..22 ほぼ一定 定期的かつ非常に頻繁なリリース FIXED 100 80 60 40 20 0 2005.11 2006.01 2006.03 2006.05 2006.07 2006.09 2006.11 2007.01 2007.03 2007.05 2007.07 2007.09 2007.11 2008.01 2008.03 2008.05 2008.07 2008.09 2008.11 2009.01 2009.03 2009.05 2009.07 MySQL Bugs ( http://bugs.mysql.org/ ) より集計 50
まとめ バグ情報は開発者にとって非常に重要なものです OSS ではバグ情報管理も公開されています 利用者にとっては問題発生時の調査情報源となります 個別のバグ情報以外にも活用方法があります 運用上の障害予防に活用することができます バージョンの選択 バージョンアップ時期の目安など運用に役立てることもできます 使用している OSS の現状を理解するための重要な情報源の一つとなります バグ情報も活用して OSS を効果的に利用しましょう 51