なぜ企業はオープンソースを使わないのか（２）

Size: px

Start display at page:

Download "なぜ企業はオープンソースを使わないのか（２）"

あきみさどひら
5 years ago
Views:

1 第 46 回 Prowise Business Forum なぜ企業はオープンソースを使わないのか (2) ~ 導入におけるメリットと安心安全に活用するポイント ~ 2010/11/18 株式会社日立ソリューションズ OSS ソリューションビジネス推進センタ吉田行男

2 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

3 なぜ企業はオープンソースを使わないのか (2) ~ 導入におけるメリットと安心安全に活用するポイント~ Contents 1. 章 OSSを取り巻く状況 2. 章安全安心に活用するポイント 3. 章まとめ

4 なぜ企業はオープンソースを使わないのか (2) ~ 導入におけるメリットと安心安全に活用するポイント~ 1. 章 OSS を取り巻く状況

5 1-1 OSS を取り巻く状況 Linux Foundation SI Forum が実施した 2009 年度オープンソースソフトウェア導入実績調査から 1 調査概要調査期間 :2010/3 ~ 2010/4 調査対象期間 :2009 年度 (2009/4~2010/3) 参加企業 (9 社 ) : NEC ソフト株式会社エヌティティコムウェア株式会社株式会社シーイーシー株式会社日立製作所株式会社日立システムアンドサービス東芝ソリューション株式会社日本アイビーエム株式会社富士通株式会社レッドハット株式会社 4

6 1-1 OSS を取り巻く状況 2 結果さらに活用範囲が広がるオープンソースソフトウェア導入実績多数 (4 社以上 ) :45 件 66 件へ運用管理開発環境 Web/AP サーバでは多くの OSS の導入実績がアップ定番化及び検証から導入への道筋商用ソフトとの連携がさらに重要にシングルサインオン等業務アプリデスクトップアプリは今後も動きに注目未だ定番なしハイアベーラビリティへの期待も膨らむ DRBD や UltraMonkey 等の活用頻度の高まり着実に使用実績が増える Ruby Ruby on Rails Ruby 関連ビジネスは完全にテイクオフした! 5

7 1-2 企業が考える OSS のメリット各企業が考える OSS のメリットコスト削減ベンダーロックイン回避柔軟性出典 :IPA 第 3 回オープンソースソフトウェア活用ビジネス実態調査 (2009 年度調査 ) 6

8 1-3 OSS 普及の阻害要因 OSS 普及の阻害要因サポートに対する不安 [OSS のコミュニティにどのように接触してよいかがわからない ] ライセンスに対する懸念大企業ではライセンスが複雑で扱いを誤ると訴訟に発展するリスク中小企業では社内にライセンスを把握できる人材が不足人財及び経験の不足 OSS に総合的に精通した上級技術者の不足体系的な学習教材不足出典 :IPA 第 3 回オープンソースソフトウェア活用ビジネス実態調査 (2009 年度調査 ) 7

9 1-4 OSS 利用のサポート面の課題 OSS 利用のサポート面の課題 (2009 年度 ) コミュニティとの付き合い方出典 :IPA 第 3 回オープンソースソフトウェア活用ビジネス実態調査 (2009 年度調査 ) 8

10 1-5 OSS 利用のライセンス面の課題 OSS 利用のライセンス面の課題 (2009 年度 ) ライセンスのわかりにくさと訴訟リスク出典 :IPA 第 3 回オープンソースソフトウェア活用ビジネス実態調査 (2009 年度調査 ) 9

11 1-6 OSS 利用のその他の課題 OSS 利用のその他の課題 (2009 年度 ) OSS 選定基準必要? 出典 :IPA 第 3 回オープンソースソフトウェア活用ビジネス実態調査 (2009 年度調査 ) 10

12 なぜ企業はオープンソースを使わないのか (2) ~ 導入におけるメリットと安心安全に活用するポイント~ 2. 章安全安心に活用するポイント

13 2-1 オープンソースのメリットオープンソースのメリット安価にシステムを構築できる機能追加バグ修正が速いマルチプラットフォームに対応している機能追加バグ修正を自分で行うことも可能サポートが打ち切られてもお手上げにならないメリットを最大限に活かすポイント OSS の特性の理解適切な OSS の選定ライセンスへの適切な対処 12

14 ユーザ開発コミュニティ務アプリーション非 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 ディストリビューションの作成ターゲットマシンへのインストールターゲットマシンでの動作確認ユーザディストリビュータディストリビュータユーザユーザ

15 2-2 OSS の特性の理解 (2) 開発コミュニティ以外のベンダがサポートを提供ユーザの自己責任の範囲を選択可能ユーザ SIer PF ベンダ総合ベンダディストリビュータ作業役割 ( 例 ) ディストリビューションの作成ターゲットマシンへのインストールターゲットマシンでの動作確認ユーザディストリビュータディストリビュータユーザユーザ PFベンダ ( ディストリビュータ ) ディストリビュータ PF ベンダ (SIer) ユーザユーザユーザ PFベンダ (SIer) ディストリビュータ総合ベンダ総合ベンダ開発コミュニティ / 開発企業様々な機器やソフトウェアを利用したシステムの提案システム構築評価運用時の問題切り分け等ユーザユーザユーザ SIer 総合ベンダユーザユーザユーザ SIer 総合ベンダユーザユーザユーザ SIer ( ユーザ ) 総合ベンダ ( ユーザ ) ( 出典 : 日本 OSS 推進フォーラムオープンソースソフトウェアが開発コミュニティからユーザに届くまでの仕組みより 14

2-3 適切な OSS の選定 (1) 適用する OSS を選定するために (1) オープンソースの機能 / 性能評価 (2) 選定における考慮点技術者 / ベンダサポートの有無プロジェクトの継続性 1 2 3 4

16 2-3 適切な OSS の選定 (1) 適用する OSS を選定するために (1) オープンソースの機能 / 性能評価 (2) 選定における考慮点技術者 / ベンダサポートの有無プロジェクトの継続性最新バージョンのリリース時期コミュニティの設立からの期間リリース計画サポートポリシーソースコードの確保問題解決ソースの確保インストール手順各種環境を構築するための手順サービスなどの起動 / 停止手順ライブラリ /APIのリファレンス FAQ 15

17 2-3 適切な OSS の選定 (2) (1) オープンソースの機能 / 性能評価異常処理に注意負荷テストは必須評価情報の有効利用ソフトウェア評価 QualiPSo Open Source Maturity Model (OMM) Qualification and Selection of Open Source Software (QSOS) Business Readines Rating (BRR) for Open Source 16

18 2-3 適切な OSS の選定 (3) (2) 選定における考慮点技術者 / ベンダサポートの有無プロジェクトの継続性ソースコードの確保問題解決ソースの確保 17

19 2-3 適切な OSS の選定 (4) (2) 選定における考慮点 1 技術者 / ベンダサポートの有無社内に技術者は? サポートサービスを提供している会社は? サポートのないものを使うことは危険! 18

20 2-3 適切な OSS の選定 (5) 2 プロジェクトの継続性チェックコミュニティがプロジェクトを継続して活動させていく意思があることを確認項目最新バージョンのリリース時期指標 6 ヶ月前コミュニティの設立からの期間リリース計画及びサポートポリシー 1 年以上設立時期が不明な場合初期バージョンのリリース時期等を参考に終了予定日の明示平均的なサポートサービス期間の明示 19

21 2-3 適切な OSS の選定 (6) プロジェクトの継続性チェック例 1 20

22 2-3 選定における考慮点 (7) プロジェクトの継続性チェック例 2 21

年に事例あり ) 米 CERT/CC は米国時間の 10 月 8 日電子メールサーバソフトウェア Sendmail のソースコードが改ざんされ

23 2-3 選定における考慮点 (8) 2 ソースコードの確保ソースコードの明確な一次配布先の確保コミュニティーのサイト (FTP,HTTP) に存在することが多いコミュニティーが活動を停止しない限り確実にソースコードを入手可能ソースコードの正当性の確認第三者により改ざんされていないことを PGP または MD5 により確認する (2002 年に事例あり ) 米 CERT/CC は米国時間の 10 月 8 日電子メールサーバソフトウェア Sendmail のソースコードが改ざんされトロイの木馬が仕込まれている可能性があると警告しソースコードの正当性を PGP 署名や MD5 チェックサムを用いて検証すべきとしている ( 22

24 2-3 選定における考慮点 (9) 3 問題解決ソースの確保システム構築運用に必要な手順 1 インストール手順 2 各種環境を構築するための手順 3 サービスなどの起動 / 停止手順 4 ライブラリ /APIのリファレンス 5 FAQ システムの安定稼働に関わる情報情報の主な供給元 : コミュニティーの Web サイトメーリングリストニュースグループ等バグ / セキュリティ関連情報サポート情報リリース情報開発者向け情報更新履歴 ( 修正内容の明記も含む 23

25 2-4 ライセンスへの適切な対処 (1) (1) どんなライセンスがあるのか? ライセンス類型複製再頒布可能改変可能改変部分のソース公開要注意!OSS の利用改造再配布の方法などがライセンスにより異なる他のコードと組合せた場合他のコードのソース公開要 GPL MPL BSD ライセンスフリーウェア (*) / シェアウェア - - 商用ソフト - - ( 出典 :< 日本 OSS 推進フォーラムビジネス推進 WG 監修 > ビジネスユースにおけるオープンソースソフトウェアの法的リスクに関する調査 ) 24

26 2-4 ライセンスへの適切な対処 (2) (2) ライセンス違反とは?(CISCO 社の事例 ) GPL コードを利用して Broadcom s の標準 Linux コンポーネントをカスタマイズ製品組込一括請負発注納品コードを組み込みチップセットの一つに M&A 全てのソースコードを開示 FSF が Cisco を提訴ライセンス違反でブロードコムのチップセットを利用して iwrt54g 無線ルータを開発ライセンス違反 The story continues... がを 2003 年に $500M で買収開発者がファームウェアを変更し低価格のルータ ($60) がハイエンドマシンに生まれ変わった 25

27 2-4 ライセンスへの適切な対処 (3) (2) ライセンス違反を起こさないために外部コンサルの導入 BlackDuck 社 Palamida 社等がソリューション提供ツール等活用による自己評価 Linux Foundation が自己診断チェックリストを提供 26

28 2-4 ライセンスへの適切な対処 (4) The Linux Foundation オープンコンプライアンスプログラム 1 2 トレーニング教育ツール Dependency Checker Bill of Material (BoM) Difference Checker The Code Janitor 動的静的リンクのレベルでコードの混在を確認するツール BoM( 部品表 ) の差分確認ツール不適切なコメントを残していないか確認ツール自己診断チェックリスト The SPDX Standardワークグループコンプライアンスディレクトリーおよび即時警告システムコミュニティ 27

29 2-4 ライセンスへの適切な対処 (5) 自己診断チェックリストの考え方 28

30 2-4 ライセンスへの適切な対処 (6) The Linux Foundation オープンコンプライアンスプログラムコアコンプライアンスの構成要素検出と開示調査と承認義務の履行コミュニティへの貢献出荷予定の製品に含まれているサードパーティライセンスソフトウェア ( オープンソースソフトウェアを含む ) の識別に関わるプロセス社外に提供する自社製品のオープンソース使用計画の調査及び企業ポリシーによって義務付けられる場合は社内プロジェクトについても調査を実施 OSS ライセンス義務を履行するために必要なコンプライアンスプラクティス従業員によるコミュニティプロジェクトへの貢献および企業によるコミュニティプロジェクトへのコードやその他リソースの貢献について調査および承認 29

31 2-4 ライセンスへの適切な対処 (7) サポート項目ポリシーコンプライアンス要員の適正配置ビジネスプロセスの適応トレーニングコンプライアンスプロセス管理 OSS インベントリ / 記録管理自動化 / ツールサポート検証プロセス順守の監査事業利益を確保すると同時に OSS の利用を促進するよう企業の方針を検討コンプライアンスプログラムの履行に必要なスキルを持つ人材を集める既存のビジネスプロセスの文脈に OSS コンプライアンスの諸事項をうまく組み込む OSS コンプライアンスを履行するために行うべきことを企業全体が確実に理解するために必要な活動コンプライアンスプロセス管理は OSS コンプライアンスを履行するためのプロセス機能の確立保守および改善 OSS インベントリ / 記録管理は組織のニーズに沿って OSS コンテンツと OSS コンプライアンス作業の正確な記録を保持することによりコンプライアンス照会に対する応答やコンプライアンス環境の変化に対応自動化 / ツールサポートはコンプライアンス作業を支援するために組織によるツールの利用や考慮点について分析します検証は OSS に関する義務が正しく履行されていることを確認するために OSS コンプライアンスチームによって実行される独立した保証措置ですプロセス順守の監査は組織がチェックした項目を参照し定義されたコンプライアンスプロセスを利用しているかおよびその利用により期待した結果が得られているかを確認します 30

32 2-4 ライセンスへの適切な対処 (8) チェックリストサンプル 31

33 なぜ企業はオープンソースを使わないのか (2) ~ 導入におけるメリットと安心安全に活用するポイント~ 3. 章まとめ

34 3. まとめ OSS を安全安心に使うためにはコミュニティの理解 OSS の適切な選定ライセンスに注意 33

35 ご清聴ありがとうございました END なぜ企業はオープンソースを使わないのか (2) ~ 導入におけるメリットと安心安全に活用するポイント~ 2010/11/18 株式会社日立ソリューションズ OSS ソリューションビジネス推進センタ吉田行男

36 付録 35

オープンソースソフトウェアで公開されている情報公開されているのはソースコードだけではありませんソースコード

h> char { *argv[]) main( int#include <stdio.

h> int argc, char x, y, z, i, j; for { int *argv[]) main( int

*argv[]) main( int argc, char int (i=0; x, i<maxpath;i++) y,

i, j; { : { for int (i=0; x, i<maxpath;i++) y, z, i, j; } : {

37 オープンソースソフトウェアで公開されている情報公開されているのはソースコードだけではありませんソースコード <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

38 バグ情報って何だろうバグはプログラムの問題点バグ情報はプログラムをより良くしていくため主に開発者が利用する情報です問題点の情報を開発者間や利用者との間で共有します修正方法の提案や修正内容についての議論も含みます多くの OSS プロジェクトでは一般利用者からの報告も受け付けています修正方法の議論や修正結果も公開されています具体的には修正が必要な事象に関する以下の情報の集まりです発生現象重要度 ( 深刻度 ) 発生条件環境 (OS, ハードウェア ) 対象モジュール機能再現手順回避方法修正方法案修正結果他 37

39 バグトラッキングシステムバグ報告方法バグ情報を管理する専用のバグトラッキングシステムバグトラッキングシステムとはプログラムのバグ発見時に登録し修正状況を管理するための専用システムです最近は Web インターフェースを採用するものが主流ですプロジェクトの進捗管理が可能な機能もあります ToDo 管理やリリース予定バグ情報の分析未修正一覧定期的なフォローメール 38

主なバグトラッキングシステム Bugzilla http://www.bugzilla.

40 主なバグトラッキングシステム Bugzilla Mozilla Foundation が開発している OSS 主な採用プロジェクト Mozilla project Linux Kernel Apache Project (httpd, Tomcat 他 ) Samba Project JIRA 豪アトラシアン社が開発したプロプライエタリソフトウェア OSS プロジェクト等には無償で提供される主な採用プロジェクト JBoss Spring Framework Apache Project (Geronimo, Struts 他, 今後の主流 ) 引用 : Mozilla Project Bugzilla ( ) よりそのほか GNU GNATS 独自系他引用 : Apache Project ASF JIRA ( ) より 39

Best) 開発者に伝える会話ができる今後の開発に活かしてもらえるかも記録として残る

41 バグトラッキングシステムの利用場面問題発生既存事例の調査誰かが同じことをやってるかも既に直っているかも回避方法があるかもバグ情報メーリングリスト使用者バグかもしれないマニュアルと動きが違う core dump したソースの間違いを見つけた回避策検索コメント投稿過去検索投稿して会話新しいバグを見つけたので報告修正方法がわからなくても ( わかれば Best) 開発者に伝える会話ができる今後の開発に活かしてもらえるかも記録として残る注意バグトラックはあくまでもバグ修正を管理するためのツールです一般利用者のためのお助けフォーラムではありません単なる問い合わせのためにバグトラック投稿を行うと開発者に無用な作業を増やしてしまいますよくわからない場合はまずユーザメーリングリスト等を活用しましょう & やっぱり新しいバグだ 40

42 バグ情報の活用バグトラックは開発者のためのシステムですソースコードがわからないと利用価値がない? 開発者以外では活用できない? もちろん開発者にとって非常に重要な情報ですがそれだけではありません 41

43 活用例 42

利用しているバージョン特定のコンポーネントだけ参照クローズになった物も検索対象更新された期間を指定 ( この 1 ヶ月 )

44 活用例 (1) 定期観測定期的に参照障害発生防止に役立てる予め知っていれば顕在化 ( 実際に問題となること ) を防ぐこともできる使用中の OSS にどれくらい問題が残っているのか把握できる問題調査時とは異なる条件でバグを検索例えば利用しているバージョン特定のコンポーネントだけ参照クローズになった物も検索対象更新された期間を指定 ( この 1 ヶ月 ) 今月のバグ一覧を取得できる引用 : Apache Projecct Bugzilla ( ) より 43

バグ情報の見方毎月バグ一覧を見ていると修正がたくさん引用 : Apache Projecct Bugzilla

org/bugzilla/) より修正されたバグを分類ドキュメントバグ機能変更に伴う変更漏れ単なる Typo

こうしたほうがいい動作上の問題解決動作不良発生に伴う修正実際には起きそうもないが論理的に好ましくない

45 バグ情報の見方毎月バグ一覧を見ていると修正がたくさん引用 : Apache Projecct Bugzilla ( より修正されたバグを分類ドキュメントバグ機能変更に伴う変更漏れ単なる Typo コンパイルできない特定の OS や環境コンパイラの場合新バージョンリリース直後に多い機能追加 / 改善バグではないがこうしたほうがいい動作上の問題解決動作不良発生に伴う修正実際には起きそうもないが論理的に好ましくない本当に問題となるのは多くの場合一部のみ機能名や設定情報を自身のシステムと比べてみましょう設定変更で影響を受けなくできることも多くあります修正されたバグは全てが今すぐ適用すべきものとは限りません影響しそうなバグがあっても判断ができない場合は専門家に相談しましょうユーザメーリングリストで相談サポートを行っている事業者 44

46 バグ情報取得の工夫バグトラッキングシステムでは CSV 等で一覧を取得できるので再利用しやすくすることも可能です Apache (Bugzilla) 検索画面も結果一覧 MySQL Bugs もバラバラ別プロジェクトだから当然だが CSV でローカル DB に自動取り込み今月 Close になったものを強調独自フォーマットで HTML 表示引用 : Apache Projecct Bugzilla ( よりローカルバグ DB 引用 : MySQL Bugs ( ) より今月のバグが一目瞭然とりあえずこれだけはチェックしておこうか 45

47 活用例 (2) 統計分析バグ情報の統計バグ報告や修正の件数を見てみることで開発の活発さやプログラムの成熟度の一端を知ることが出来ますバグ報告が多いということはバグ報告バグ報告バグ報告バグ報告バグ報告バグ報告利用者利用者利用者利用者利用者利用者問題が多いかも? 利用者も多い修正が多いということはバグバグバグバグバグバグバグバグ開発者開発者開発者実際に問題が多かったメンテナンスが活発に行われている 46

48 統計の実例実際に OSS で毎日報告される新規バグ報告と修正されたバグの件数を月別に集計したものを他の情報と合わせて見てみます注意以後の図のコメントは個人的な見解ですプロジェクトやプログラムの客観的な評価を示すものではありません 47

49 Apache HTTP 2.0 のバグトラック集計 Apache 2.0.x 新規報告 FIXED 報告も修正もほとんどなくなってきているリリース間隔が非常に長く最近リリースがない 2.2 に移行を考えるか Apache Projecct Bugzilla ( ) より集計 48

50 Apache HTTP 2.2 のバグトラック集計 40 Apache 2.2.x 新規報告 FIXED 報告件数増加傾向ユーザ増加中? 修正も多いが頻繁にリリースされている今まさに旬? Apache Projecct Bugzilla ( ) より集計 49

51 MySQL server 5 のバグトラック集計 MySQL 5 (5.0.x, 5.1.x を含む ) 新規報告 GA a GA 報告件数も修正件数も減少し現在はほぼ一定定期的かつ非常に頻繁なリリース FIXED MySQL Bugs ( ) より集計 50

52 まとめバグ情報は開発者にとって非常に重要なものです OSS ではバグ情報管理も公開されています利用者にとっては問題発生時の調査情報源となります個別のバグ情報以外にも活用方法があります運用上の障害予防に活用することができますバージョンの選択バージョンアップ時期の目安など運用に役立てることもできます使用している OSS の現状を理解するための重要な情報源の一つとなりますバグ情報も活用して OSS を効果的に利用しましょう 51

HIGIS 3/ﾌﾟﾚｾﾞﾝﾃｰｼｮﾝ資料/J_GrayA.ppt

HIGIS 3/ﾌﾟﾚｾﾞﾝﾃｰｼｮﾝ資料/J_GrayA.ppt OSC 2018 Nagoya オープンソースを安心して利用するために ~ 選定と管理 ~ 2018/5/19 株式会社日立ソリューションズクラウドソリューション本部クラウドサービスビジネス部第 1 グループ加藤尚樹 Hitachi Solutions, Ltd. 2018. All rights reserved. はじめに昨今オープンソースソフトウェア (OSS) のビジネス利用は Web