続：企業向け Linux の選択

前回の「企業向け Linux の選択」で、 Linux においてサポート体制の充実が急務であるという話をしたが、 では、具体的にどうサポートすればいいか、という部分を補足しよう。

Linux は確かに企業に浸透し始めたが、実際には非常に大きな問題が発生しつつある。

■企業ユーザーの憂鬱

コンピュータ業界ではもとより OS は非常に重要なものとして考えられてきた。メインフレームの世界では、商用のシステムが OS のレベルで、突然フリーズしたり、停止したり、ましてや、コンピュータをいきなりリセットする、などということはあり得ないことだった。

ところが PCと MS-DOS の登場でその常識が打ち破られた。CPU の性能の問題もあり、PC の OS レベルでの不安定な挙動を許容する風潮が生まれてしまった。Windows（MS-DOS）のこのような点を Linux も受け継いでいる部分もあるが、これは企業の、特にメインフレーム系や Unix サーバーのユーザーには信じがたいことだ。

しかし Linux が企業ユーザーに対しても普及し始めた。 当然、Linux を使う利点があるからである。 PC からサーバーまで同じOSで幅広く稼動でき、ネットワークに強い。そして、ベンダーロックインがない。 特に、インテル系サーバーであれば、 どのベンダーのものでも同じような環境で Linux を使える。 今では、メインフレームの代名詞とも言える IBM　z シリーズでも Linux が使える。 したがってメインフレームのネイティブ OS に長年慣れていたユーザーが Linux を使用し始めることになる。

ところが、そういったユーザーにとっては、Linux について、驚くことがたくさんあるに違いない。メインフレームの基準から見ると、 Linux OS はまだまだ完全な OS と呼ぶには躊躇する部分があるからである。

いきなり細かい話になるが、まず、OS のメッセージの問題から入ろう。

■Linux のメッセージはわかりにくい

システムに問題が発生したときに、通常は、様々なレベルでメッセージが出力される。OS レベルに限って言うと、Linux のメッセージはわかりにくい。そう思う企業ユーザーは多い。メインフレームの環境に長年親しんできたユーザーは特にそうだ。メインフレームでは OS の問題が一件でも発生したら、大ごとである。Linux の場合、そうした問題の件数が多いのは、まあ、やむを得ないとしていても、発生したときのエラーメッセージがわかりにくいのは困る。

まず、このようなケースではマニュアルが十分でない。メインフレームや Unix と比較すると、通常のマニュアルも貧弱だ。ましてや、エラーコード表、メッセージマニュアルなどに、まともなものがほとんどない。

同様の問題が、パッチについても言える。

よく「パッチを当てる」というが、Linux では頻繁に起こる。どこまで OS に含めるか、あるいは、パッケージの構成にもよるので一概には言えないが、標準的な Linux の場合、その頻度は、おおよそ年間数百個程度である。平均すると、1日に１個以上という計算となる。一度に一個ずつという訳でもないが、ならせば、ほぼ毎日だと覚悟した方がいい。

パッチの種類は、セキュリティホールの対策というケースもあるが、細かいバグフィックスや、機能強化などもある。ある機能ごと一気にバージョンアップしてしまうこともある。日々、そのような頻度でメンテナンスを続けていく必要があるのである。最近はネットワーク化が進んでいて、ネットワークに接続した状態で使うのが常識となっているが、そのような環境では、パッチを当てないと危ないという不安もある。

つまり、パッチを確実、かつ迅速に提供する、 これが商用 Linux ディストリビュータの条件ともなっている。 世界規模で、タイムリー、安定的、そして自動的にパッチを供給できる商用ディストリビュータは、 現在、Red Hat と SUSE の2つしかない。 つまりパッチの提供に関しては、エンタープライズレベルのサーバー用途では、この二者択一しかないと言えるだろう。

■アプリケーションレベルでの検証は誰がやるか

よく指摘される問題は、このパッチに関する個々の説明が貧弱で、 内容がわからない、というものである。なぜそのパッチを当てなければいけないか、 そのパッチを当てるとどういう影響が出るのか、 特に現在使用している既存のアプリケーションレベルにまで影響を及ぼすのかどうか、という点である。そこまでは、検証されていない場合が多い。 つまり OS 全体として改善されるのはわかるが、 他の機能との連携で問題が生じないかのどうかという検証を誰がやるのかという問題である。

普通に考えれば、パッチを提供する Linux ベンダーがそうような役割を果たしてもいいのだが、現状では、それは無理だと考える人もいる。OS 上で動いているアプリケーションは各企業によって異なるが、世界中の企業が使っているアプリケーションをすべてテストして、パッチを作っているわけではないからだ。

しかし、誰かがそれをやるべきだ。ところが、現状では、 Linux ベンダーにそこまでの義務はない、という風潮が根付いてしまった。

Linux ベンダーとの通常のサポート契約には、 マニュアルが不備だった場合の改善は、まず含まれていない。 したがって、わかりにくいメッセージを元に誰かがソースコードを追うはめになる訳だが、それでも問題を特定するのは難しいことが多い。 問題が特定できないと、バグか、仕様なのかを判断できない。 こうした作業に時間をかけて、業務に支障をきたす訳にもいかない。

開発はコミュニティなのだから、 コミュニティに頼ると考える人もいるかもしれないが、それは筋が違うと言える。 コミュニティは善意の開発リソースであり、 使用に際して発生した問題を解決する義務は負っていない。

当然、次にそれを利用して OS としてパッケージ化した、 Linux ベンダーに矛先が向く。 しかし、Linux ベンダーはパッケージ化するのに精一杯で、 そこまでのリソースを持っていない場合が多いし、 ビジネス的にもペイしないと考えられている。 したがって、Linux を提供するハードベンダーがある程度、 それを肩代わりしているケースが多い。しかし、それで本当にいいのだろうか。

障害発生時の対応や、 パッチとアプリケーションの検証は誰かがやるべきであり、 少なくともメインフレームの場合は、 メインフレームベンダーがやっていた。 Unix が普及したときも最終的には、やはり、ハードベンダーがやった。 OS の開発をハードベンダー自らが行っていたからだ。 Sun の Solaris も Sun が OS ベンダーとして、そのような検証を請け負った。 だから、そういったことは OS ベンダーが行うのが当然だと企業ユーザーは思っていた。しかし Linux の OS ベンダー、つまり、Linux ベンダーにはそれができないと考えられているのが現状だ。

当初、企業ユーザーも、ハードベンダーも、 Linux ベンダーがそこまで検証する体制を持ち、 実践するものであると期待したが、 しかしそれは難しいのだろうと思い始めた。 Linux ベンダーはおおむね規模が小さいし、 そのような場合は、検証したくてもできないのだ。 さらに、これは非常に重要な点だが、Linux ベンダーにはエンタープライズソリューションの経験があまりないということだ。

エンタープライズシステムでは、複数の人がチームとして、 計画的に作業していることが多いので、 対応がフォーマット化されている方が効率がよい。 また、作業する場合も複数の人が順番に行うことが多いので、 特定のノウハウにあまり依存するのは、やはり効率が悪い。 つまり、マニュアル化がしっかりしていることが重要なのである。 障害が発生したときも、障害の解析、切り分け、 検証等をスムーズに行い、ベンダーに報告、対応を考える。 パッチのように提供される場合は計画的に検証作業を行い、 迅速にシステムへの適応を図る。 このような仕組みと体制が重要なのである。

しかし、Linux では検証作業に至る以前に、マニュアルそのもの、 メッセージの内容、パッチの説明などが不十分なため、作業が思い通りに進まない。 これが大きな問題となりつつある。 こうした、さまざまな理由によって生じた不備を誰かが肩代わりして、 埋めなければならない。

したがって、顧客としてのエンドユーザーは、 システムを提供しているハードベンダーにその責任を担わせようとした。 ハードウェアベンダーにはエンタープライズシステムとはどう対処すればいいのかという知識もあり、 サーバー OS の開発・保守経験も豊富にあるからだ。 そこで、ハードベンダーがやむを得ず Linux ベンダーの弱点をカバーするようになった。これが現状だ。

■サポートのポイント、品質の改善

サポートの第一歩は、まずは品質の保証だ。 しかし、保証への道のりは用意ではない。

現在の Linux コミュニティが目指しているものは、まず機能強化だ。 品質については、一般ユーザーが安定的に使えるというあいまいな基準だけだ。 だから、Linux ベンダーも概ね、機能強化を重視する体制がまずあり、 それから品質を改善するという順番になっている。

コミュニティの開発のレベルでも、テストは行っているが、 保証ということではない。 それを利用する Linux ベンダーが、 企業の責務として更にテストを行う。 つまり、品質の改善である。1999年以降、企業向けのビジネスを本格的に目指すようになって以来、それでどうにか商用レベルで通用すると言われるまでに補強してきた。

Red Hat が早い時期に企業に受けいれられた理由もそこにある。 OS としての最低限のテストをきちんと行った。 そして、Red Hat は Linux OS をエンタープライズ向けに販売するというビジネスモデルを作り上げた。 具体的には、当初、商用でも1万円以下だった製品を、 エンタープライズ向けに、年間サポート付きで、 約20万円で販売することにしたのである。 （現在では価格が下がり、最低価格は10万円を少し切る。）

■サポートの範囲

値段は高くなったが、結果的に Linux の企業向け製品は市場に受け入れられ、 これ以降、 Red Hat 社は順調に売り上げを伸ばし、 利益の面でも黒字化を果たした。 こうして、エンタープライズ Linux と呼ばれる製品は、Red Hat と同様の価格帯、 サービス内容となり、一年間という期間ごとのサブスクリプション契約という形態となった。（企業向け以外は、サポートが付かないパッケージを無償でダウンロードできる。）

しかし、ここにきて、サポートの内容に問題が出てきた。

言い換えると、Linux が企業内システムに浸透するスピードに、 サポートの内容が追いつけなくなったのだ。 企業での導入が加速したのは Linux 業界にとって喜ばしいことだったが、 Red Hat 自体がそのスピードに追いつけずにいる。 これが今後の課題だ。

ここでいうサポートの内容として考慮しなければならないものは、 障害解析、 障害対応、パッチの提供、 製品の保証期間などは基本的なサポート項目だけではない。 OS の品質そのものもある。 さらに、ミドルウェアとの連携の保証、 システムとして総合的な技術レベルのサポートも含まれる。 こうした技術的な検証やテスト、それに関連する情報の提供をすべて含め、 サポートと呼ぼう。

■社会インフラを支えるためのサポート

時折、銀行のオンラインシステムなど、 社会インフラの基幹部分に当たるようなシステムがダウンしてニュースになることがあるが、このような場合、原因究明の調査はとても大事だ。 二度と同じ事態を起こしてはならない。そして、 調査にはデータが必要だ。どうやって、 そのシステムが正常に稼動していることを証明するのか。 つまり、正常に稼動するように努力をしたのか、ということも問われる。

当然、これらのことはユーザーがシステムを購入するときに各ベンダーに要求する。 ベンダーは、ユーザーの業務に使用しても大丈夫だというデータをユーザーに提出し、ユーザーは比較検討して一番いいものを選択する。 こうした購入プロセスを経ていれば、最低限の証明はできる。 メインフレームや Unix では、そういうデータはきちんと用意されていた。 したがって、システムに問題が発生しても、特に落ち度がない場合、 ベンダーやユーザーが手抜きしたのではない、予測不可能だった、 ということを裏づけできるかもしれない。

エンドユーザーから見れば、 自社のアプリケーションもテストしなければいけない。 それが社会インフラを担う企業の責任だからである。 使用している OS、ハードウェア、ソフトウェアを総合的にテストして、 それが正しい選択だったということをユーザーとしても証明しなければいけない。 そのためにはデータが必要だ。

■足りないのは人材か、それとも…

さて、データとは何かを説明しよう。

Linux の障害パッチ情報は、Bugzilla（バグジラ）に掲載されている。 あらゆるパッチがそこに掲載されているといっても過言ではない。

したがって、Linux ベンダーは、まず、「Linux のバグで、わからなかったら Bugzilla を見てください」と言う。しかし、これが、なぜ問題かというと、 Bugzilla はもともとハッカー向けに作られているからだ。 一般に公開されてもいる。おまけに英語だ。

Linux 界には、長らく「Bugzilla にないものは、バグではない。 （If it’s not in Bugzilla, it’s not a bug.）」という"常識"がまかり通っている。今後追加されるであろう機能についての記述も入っているので、 Linux のトラッキング・システムとしては、 現状、最も優れたものであることも事実だ。 ところがこれが Linux のすべてのデータかというとそうではないだろう。

企業レベルで考えると、Bugzilla の内容以上に、もう少しデータがほしい。 そういった場合、現状では、Linux ベンダーはあまり積極的でない。 そこまでの義務はサポート契約に含まれていないというのが言い分であろう。 Linux ベンダーに理解ある人たちは Linux ベンダーもビジネスだから、 そこまでの要求するのは酷であるとの意見も多く聞く。果たして、そうなのだろうか。

そもそもユーザー企業はハッカーの養成機関ではない。 企業が社員として、求めるのは、ハッカーとしての能力もあれば越したことはないが、むしろ IT の専門家、あるいは優秀な企業エンジニアとしての資質、能力である。 問題は、 なぜそうした IT の専門家が Linux では通用しないのか、ということだ。

それは、Linux そのものの情報提供に不備があるからだ。 確かにソースコードが公開されているわけだから、 これ以上、正確な情報はないとも言えるが、 いきなり、そこまで持っていくことに無理があるのだ。

■障害対応の順番

たとえば障害が発生したときに、障害を分析し、 Bugzilla に似たような報告があるかどうかを検証する。 同様の問題があれば一歩前進だが、ない場合は、 新しいバグとして登録しなければならない。 そして、障害を回避するような使い方で解決を待つ。 概ね、このような流れで進む訳だが、 こうした過程で様々な問題が指摘されている。

まず、情報が少ない。先も述べたように、Linux のメッセージは不親切だし、 パッチ情報も詳しく説明されていない場合が多い。 Bugzilla だけにも頼れないので、 一気にソースコードを追う羽目になることも少なくない。 ついでに言うと、こうした解析を行うためのデバッガも Unix に比べると見劣りがする。ここまでの状況で、企業ユーザーのエンジニアがどこまで効率よく、 こうした作業に参加できるのかという問題だ。 こうした人材が不足しているからといって、 一概に Linux の人材が足りないと結論付けるのは早計であろう。

つまり、Linux そのものが、 企業ユーザーから見ればまだまだ不親切なのである。 Linux はハッカーにとっては楽しい OS かもしれないが、 企業ユーザーは仕事である。 企業の IT エンジニアが、常に OS のソースコードを追いかけなければならない事態が過去にあっただろうか。

■サポートには投資が必要

Linux のビジネスモデルでは、開発の仕組みはコミュニティに頼り、 販売はディストリビュータが行う。しかしサポートは誰がやることになったのか。

Linux ベンダーが提供するサブスクリプションには、 パッチの提供は必ず付いてくる。 したがって、購入すれば、Linux 自体の品質や機能は確実に改善されていく。

電話・メールなどによる問い合わせサポートは Linux ベンダーによって多少異なるが、金額に応じて提供される。 さらに、ハードベンダーやソリューションプロバイダ、 システムインテグレータなども独自の付加価値を加味したサポートを提供し、それを購入することも可能だ。

しかし、すべての問題は、Linux ベンダーのもともとのサポートの質に起因していると考えるべきだ。

Linux ベンダーの提供するサポートとは、 現状では一般には平日の通常の勤務時間帯に限定した電話、 メールによる問い合わせサポートが主である。 24×7、つまり、24時間365日のサポート、オンサイトサポート、バグの詳細説明、 バグのアプリケーションへの影響の検証、特殊な機能追加、 などは完全に別メニューであり、そもそも実施した例がない場合すらある。 マニュアルの改善、 エラーコード表の作成、メッセージマニュアルの改善を請け負った Linux ベンダーの話は聞いたことがない。 つまり、実際には Linux ベンダーからの“まともな”サポートは期待できないというのが現状だ。

■Linux ベンダーは甘やかされている？

Linux ベンダーは、Linux を OS としてパッケージングすることに注力するのが精一杯で、メインフレーム並み、Unix 並みのサポートにまで手が回らない。 そこをハードベンダーなどが肩代わりしてやっている訳だが、 そこが問題なのである。

Linux は無料でダウンロードすることもできるので、 当初サポートも無料の印象が強く、 そのサポートを有料にするのに各ベンダーがしばらく対応に苦慮した時期があった。 また、低コストだから Linux を選択するという考え方も存在したが、 最近は、高いとか安いではなく、積極的に Linux を選択する理由があるから、 選択するというのが普通だ。

それにしても、開発の大部分をコミュニティに依存している訳だし、 Linux ベンダーとしての開発投資は従来の OS の開発に比べれば非常に効率がいい。 投資が少ない部分、サポートにもっとお金をかけるべきであろう。 Linux ベンダーこそ、そういう考え方を持つべきだが、 ハードベンダーは、そこの部分で、Linux ベンダーの肩を持ちすぎているのかもしれない。その部分を Linux ベンダーの代わりに、 企業ユーザーをサポートしている例が多い。

Red Hat は Linux フォーカス、Linux カーネルフォーカスの会社である。 もともとエンタープライズの経験は少ない。 アプリケーションスタックも Linux の定番である Apache 程度のノウハウしかない。そこで大きな決断をした。つまり、 JBoss の買収である。この買収により、大きな賭けに出た。

それは、OS オンリーベンダーからの脱却である。 JBoss 買収で、Red Hat が真剣にアプリケーションの分野で、 エンタープライズユーザーに対してサポートするかもしれないという期待が膨らんだ。

しかし、それは、まだ兆しが見えただけだ。 これがうまくいくという保証はどこにもない。方向性をうち出しただけで、 本当に Red Hat と JBoss が融合できるかどうかすら疑問だ。 ただ、OS オンリーベンダーからの脱却を図ろうとしているのは事実であり、 これにより、エンタープライズサポートの質が向上することを期待するしかない。 Red Hat の最大の弱み、それはエンタープライズサポートの経験のなさだからである。

■Red Hat とNovell の戦略の違い

Novell が目を付けたのは、正にその点である。 2003年11月に欧州最大手の SUSE の買収を発表し、 2004年から本格的に Linux 市場へ参入した。 企業向け Linux とソリューションの提供が目的とされた。

SUSE が Novell SUSE に変わって、一番の違いはサポート品質の改善である。 Novell は IT ベンダーとして Linux を手がけるには、 まずサポートの改善を行わなければならないということを、 NetWare の成功体験を通して、 よく理解していた。 顧客の満足、それがサポートの第一歩だということも。

だから、SUSE が Novell に買収されたときに、 Red Hat とは違うことが起きるのではないかという期待があった。 つまり、エンタープライズビジネスの経験が豊富だった Novell が SUSE Linux を変えるかもしれないという期待だ。

今までは、Red Hat と SUSE の比較だった。 つまり、Linux OS としての技術的な完成度、 利用できるミドルウェア/アプリケーションソフトウェアの有無、 市場シェア、などだ。

だが、これからは Red Hat と Novell の比較となる。 つまり、サポート内容の充実度、エンタープライズ経験などが加わるということだ。

Linux ベンダーがもっとしっかりサポートすれば、 企業ユーザーから最近聞こえてくる不満はなくなるはずだ。 企業から見た Linux の選択基準は、今後はエンタープライズサポートの体制と質の比較になるのは間違いない。