twitter icon   twitter icon   rss icon

Linux.com Japan

Home 特集 コラム 赤井 誠の「Linuxビジネスの作り方」 「Linuxビジネスの作り方」VOL.14

赤井誠の「Linuxビジネスの作り方」

「Linuxビジネスの作り方」VOL.14

 

今回、久しぶりに、コラムをアップデートします。2月末にこのコラムの趣旨にあったレポートが発行され、話題になったからです。それは、オープンソースの品質についてです。

オープンソースソフトウェアの品質については、昔から議論が続いています。

2月24日、コベリティ社(ソースコード解析ツールなどを開発・販売) は、オープンソースプロジェクト45件および独自開発ソフトウェア41件のソースコードを解析した「2011年度版Coverity Scanレポート」http://www.coverity.com/html_ja/press/press_story72_02_24_12.html を発表しました。この中で、「オープンソース・コードの品質は独自開発のコードとほぼ同等である」とレポートされています。そのため、いろいろなところで、このレポートが話題になっています。それらの議論を読んでいる中で、気がついたことを紹介したいと思います。(今回議論の対象は、エンタープライズ向けソフトウェアです。)

一般的に、オープンソースソフトウェア(OSS)の品質について語られるときは、実際に動作している状態で、不具合が多いか、少ないかという観点がほとんどだと思います。しかし、エンタープライズ環境で使用する場合は、品質というキーワードで語るには、他にも考慮する点があります。

今回は、次の4つの観点から品質を考えてみたいと思います。

1.コード品質

2.テスト品質

3.サポート品質

4.企業品質

コード品質とは、ここでは、単純に、機能を実装しようとしているソースコードの品質ということとします。一般的には、この領域が、オープンソースの品質がいいか、悪いかということが語られるところだと思います。上の報告にあるように、以前からも、コード品質には、商用ソフトウェアに比べて差があるわけではないといわれています。これは、単純に考えれば、想像できますが、ソースコードの品質は、そのコードを実装する人と、それをレビューする人の品質に大きく依存します。つまり、クローズであろうが、オープンであろうが、そのプロジェクトメンバーの構成や対応プロセスに依存するといえるでしょう。オープンソースでも、商用ソフトウェアでも、それらのプロジェクトに関係するプログラマーのレベルが重要だということになります。

テスト品質とは、製品を出荷する前に実施するテストということにします。ソフトウェア製品も、一般的な製品と同じように出荷前にテストを繰り返します。例えば、車を出荷する前には、耐久テスト、衝突テスト、燃費などさまざまなテストが繰り返されます。同じくソフトウェア製品でも、いろいろな観点からテストが行われます。例えば、実際にユーザーに使ってもらって、フィードバックをもらうもの。長期間負荷をかけつつ連続稼働を実施するもの(48時間連続100%稼働など)。障害を実際に発生させて、その時に期待される挙動が確認するもの(例えば、ネットワークの回線を突然抜く。電源を突然抜くなど)などです。

ソフトウェア開発において、エンジニアリソース(人、金など)が一番かかるもの1つが、このテスト工程です。例えば、導入される顧客の環境ごとに、サーバー、ストレージ、ネットワークの構成が違うことがあります。それらの環境を想定したうえで、テストを実施する必要があります。どういう項目をどの環境で実施するかという場合分けであるテストケースを決めることが重要です。例えば、Windows Server 2008 R2 で、x86 Server でサーバーを構成し、ストレージは、FC SAN 、iSCSI,  CIFS で接続されたデータを使用する。ネットワーク回線は、社内および社外からのアクセス。アクセスされる最大のユーザーは、1分に1人といったことを決めます。テストケースの設定を適切に実施し、必要な機能をテストを実施するようにしないと、費用やテスト工数が大きくなってしまいます。そのため、いかに効率よく必要な機能項目をカバーしていくかというのが腕の見せどころになります。

さて、オープンソースの中で、エンタープライズ向けで使用されることが多い、 Red Hat Enterprise LinuxやMySQL商用版などは、これらのテスト(テスト内容が公開されることはほとんどありません) を十分にこなした上で、出荷されています。バグが見つかったら、すぐにパッチを当てて、出荷というなことは、通常ほぼありません(契約書をご覧ください。優先度、対応時間の目安が記述されています)。多くの有償オープンソースソフトウェアでは、パッチができあがったとしても、すぐに出荷せずに、テストを1週間程度実施して、正式に製品版にとりこまれて、出荷されることが多くのプロセスです。作成したパッチが、違う機能の障害を引き起こないようにすることは、商用ソフトウェアでも、オープンソースでも、注意すべきポイントだからです。

オープンソースはテストしていないという噂をしゃべる人がいますが、確かに、まず動くことを前提にして、頻繁にリリースを繰り返すモデルも存在します。しかし、有償で販売されているエンタープライズ向けオープンソースでは、パッチは必要なテストをクリアした上でリリースされます。そのテスト手法やプロセスについては、商用ソフトとそれほど変わりません。

3つ目のサポート品質については、実際に販売された後で、障害や不具合が発生したときに、どのように顧客に対して、対応するのかということとします。

どのように顧客に対応していくかということについては、2つのポイントで検討が必要です。まずは、サポート窓口の品質です。最近は、ウェブでの問い合わせ受付も主流になってきましたが、電話での問い合わせも、まだまだ多くの企業が提供しています。この問い合わせ窓口の対応によって、問題解決に要する時間が大きく変わってきます。問題が発生してる場合、問題が発生する現象を再現させたり、問題の発生原因を切り分けたりするスキルはもちろん重要です。それに加えて、直接顔を合わせているわけではないので、電話での応対態度やウェブなどでのリプライ内容の質も大切です。

次のポイントは、問題発生から、解決に至るまでのプロセスに対するものです。特に重要な障害(セキュリティホールやシステム停止など)が発生している場合は、定期的に適切な報告を顧客は期待します。日本以外の国々でのサポートでは、何か新しい事項が起こるまでは、問い合せをもらった顧客に対して、進捗を報告しないこともよくあります。しかし、日本では、進捗がなかったとしても、「なかったこと」の報告を期待されることもよくあります。このようなギャップを埋めていくことが、顧客から見たサポート品質が高いという評価につながることもよくあります。

最後は、会社としての品質です。問題が起こったときに、ほとんどの最終的な対応責任は、ソフトウェアを提供している会社にあります(対応する責任であって、金銭などの責任ではありません)。どのように顧客やステークホルダーなどとコミュニケーションをとっていくかということが重要な点になります。特に、企業が重要なシステムにそのソフトウェアを使用している場合は、真摯に対応していくことが求められます。必ずしも、問題はそのソフトウェアを導入している企業だけに閉じるわけではありません。例えば、ECサイトであれば、商品を購入した顧客まで、影響が及ぶこともあります。そのため、適切にユーザーである顧客に現状や、問題点、解決方針などの情報を提供してくことなど求められます。問題対応には、技術上の問題解決だけでなく、ビジネス上での人間関係のトラブルまで発生することもありますから、会社一体になって、問題解決に取り組む必要があります。

以上、品質について、4つの観点から、簡単に説明しました。特に、後半の3つの品質を向上していくには、商用ソフトウェア、オープンソースソフトウェアであることとは、関係がないことに気がつく人も多いでしょう。、シェアの高いエンタープライズ向け商用ソフトウェアを提供している企業の多くは、長い経験や実績から、人材育成、プロセスが確立しているため、これらの品質が高い傾向にあります。オープンソースソフトウェアを提供している企業の中には、改善活動を繰り返し、すでに商用ソフトウェアを提供している企業と同等レベルの品質を提供しているところも多くあります。しかし、これから、有償オープンソースソフトウェアを提供する企業にとっては(あるいは、これから商用ソフトウェアを提供する企業にとっても)、これから実績を積みながら、改善していくことも必要になるでしょう。なぜなら、これらの品質向上には、時間がかかるからです。

品質については、不具合率という数値化できるものがあります。また、一方で、数値化できない人間関係や気持ちといった部分に影響される部分もあります。それらを理解したうえで、品質についての議論を考えてみることも必要だと思います。

著者プロフィール

赤井 誠(あかい まこと)
赤井 誠(あかい まこと)

MKTインターナショナル株式会社 代表取締役社長。
日本ヒューレット・パッカード株式会社に入社後、HP-UXやHPソフトウェアの開発に従事。その後、マーケティングに移動し、HP製品だけでなく、各種ISV製品販売推進を担当。サービス事業戦略部門を経て、2003年からLinuxビジネス立ち上げのリーダーとなり、日本HPをLinux No.1ベンダーに導く。ハイパフォーマンス・コンピューティング、VMWare、Microsoft Windows、HP製クラウド管理ソフトウェアのビジネス開発担当を歴任。2010年より、株式会社サイバーリンクスにて新規事業開発に従事。2011年4月 MKTインターナショナル株式会社を起業し、現職。
『マックで飛び込むインターネット』(翔泳社) の執筆以降、ライター活動も実施中。『MySQLクックブック』『JBoss (開発者ノートシリーズ) 』(オライリージャパン) など多数。
ここで述べられていることは私の個人的な意見に基づくものであり、私の所属する組織とは何ら関係はありません。

Twitter id:  mktredwell

新着コラム

シェーン・コークランの「法務、ビジネス、そしてコミュニティの交差するところ」
シェーン・コークランの「法務、ビジネス、そしてコミュニティの交差するところ」
赤井 誠の「Linuxビジネスの作り方」
シェーン・コークランの「法務、ビジネス、そしてコミュニティの交差するところ」
シェーン・コークランの「法務、ビジネス、そしてコミュニティの交差するところ」
飯尾 淳の「デスクトップ?何それ、おいしいの?」
飯尾 淳の「デスクトップ?何それ、おいしいの?」
Linux Foundationメンバーシップ

30人のカーネル開発者

人気コンテンツ

  1. Today's Linux 2018/04/16 2018年 4月 15日
  2. Today's Linux 2018/04/19 2018年 4月 18日
  3. Today's Linux 2018/04/17 2018年 4月 17日
  4. Today's Linux 2018/04/20 2018年 4月 19日
  5. Today's Linux 2018/04/23 2018年 4月 22日

Linux Foundationについて

Linux Foundation はLinux の普及,保護,標準化を進めるためにオープンソース コミュニティに資源とサービスを提供しています

 

The Linux Foundation Japan

サイトマップ

問い合わせ先

サイトに関するお問い合わせはこちらまで

Linux Foundation Japan

Linux Foundation

Linux Training

提案、要望

Linux.com JAPANでは広く皆様の提案、要望、投稿を受け付ける予定です。

乞うご期待!