仮想化が情報システム部門の業務内容を変える～JBグループ

　ホールディングカンパニーであるJBCCホールディングスの下に、サービスプロバイダーである日本ビジネスコンピューター株式会社（JBCC）などIT系グループ企業を形成するJBグループ。中小企業向け企業コンピュータの主流がオフコンメインだった時代には、IBMのAS/400（現・IBM System iシリーズ）のトップディーラーとして知られていたが、現在はハードウェアはマルチベンダー、オリジナルソフトやソリューションを揃え、ビジネスを行っている。

　同社がグループ内のサーバー統合に最初に取り組んだのは2004年。それ以来、サーバー統合を進め、2011年1月にはSystem iを含めた開発環境のサーバー統合を完了。これで社内のサーバー95％を統合するという。

　この結果、管理コストまで含めたコスト削減はもちろん、開発環境については新プロジェクト発足にかかるリードタイム短縮を実現した。

■データセンター活用でファシリティ管理作業から脱却

JBAT 上級執行役員先進技術研究所の佐藤利行研究所長

　「サーバーを統合し、手元で管理するのではなくデータセンターなどにサーバーを置くことで、情報処理部門の担当者の仕事はどう変化するのか。仮想化、クラウドといったことを実現することで、コストはどう変わるのか、そういったお客様の疑問に答えることが、社内サーバー統合を進めた狙いの1つです」――。

　JBグループの情報システム部門であるJBアドバンスト・テクノロジー株式会社（JBAT）上級執行役員先進技術研究所の佐藤利行研究所長は、こう説明する。

　2011年1月には、最後まで残ったIBM System iシリーズ開発用サーバーの統合が完了。2004年時点では全国に350台存在したサーバーが、最終的には物理サーバー15台に集約される計画だ。

　「お客様の環境を再現するために物理サーバーが不可欠な一部を除けば、95％のサーバー統合が完了することになります。サーバーを管理する情報システム担当者の業務は、本来の情報システムの管理ではなく、ファシリティ管理に時間を割かれていました。が、サーバー統合によって、情報システムの中身そのものを管理することへ業務がシフトしたと感じています」（佐藤氏）。

　ただし、サーバー統合をスタートした2004年時点での狙いは全く別のところにあった。

　「個人情報保護法が施行されたために、日本全国に点在していたサーバーを統合し、管理を強化するコンプライアンスの観点からサーバー統合がスタートしたのです」（佐藤氏）。

　全国の営業所に置かれていたサーバーは350台。これを全国4つの事業所に集め、台数も28台にまとめることになった。

　この時点では企業としての体制も現在とは異なっている。ホールティングカンパニー化されておらず、グループ企業トータルの情報戦略を考えるという観点も薄かった。

　その状況が変わったのは、2007年からだ。前年、ホールディングカンパニー制度を導入。佐藤氏が所属する社内の情報システム担当部門は、従来の情報システム部門の業務の延長としてグループ企業全体のIT戦略企画と共に、先進技術研究という業務を担当することとなった。

　先進技術研究の役割の1つが、JBグループ自身がモルモットとなって先進ソリューションを試すことだ。サーバー統合のようなソリューションは、従来の物販とは異なり、導入後の変化を実感しにくい。そこで、JBグループが実際に運用していく中でコスト、経営状況にどういった影響を与えているのかといったユーザーから上がる疑問の声に、自らの体験をもとに回答する。

全国に点在していた350台のサーバーを、データセンター1カ所、10台のサーバーに集約した

　2007年に実施したのは、災害対策、事業継続性見直しの観点から免震機能を持った建物にあるデータセンターにサーバーを預けることだった。全国の事業所4カ所に分散していた28台の10台のサーバーに集約した。

　情報系サーバーについては、免震機能を持ったデータセンターを活用しないケースもあるが、「コストでいえば免震機能をもったデータセンターの方が割高なのは当然です。そのため、基幹系サーバーは免震機能を持ったデータセンター、情報系はもっと価格が安いところで十分という声もありますが、現在の企業活動にはメールなど情報系サーバー活用が欠かせません。災害によるロスタイムを出さないためにも、情報系サーバーも免震機能を持ったデータセンターを活用することが必要だと考えました」（佐藤氏）という。

　データセンターを活用することで社内からサーバーがなくなる。それに対し、JBグループ社内からも、サーバー統合を検討するユーザー企業側からも不安の声があったという。

　ユーザー企業の経営層などからは、「サーバーが手元から無くなると、トラブルからのリカバー処理などにかかる時間が余計かかって、業務面でマイナスになるのでは？」という声があった。また、ユーザー企業の情報システムを担当する部署に所属する人からは、「自分の仕事がなくなるのでは？」という不安の声があった。

　佐藤氏をはじめとしたJBグループの情報システム担当者からも、「サーバーが手元からなくなることへの不安」はゼロではなかった。

　しかし、実際にはデータセンターにサーバーを預けることで、情報システム部門の運用・管理の手間、コストが低減するなどプラス効果が生まれているという。

　「情報システム部門担当者は、情報システムを管理すると言いながら実際にはファシリティを管理作業に多くの時間を割いてきました。データセンターを活用することで、この作業がなくなり、本来の情報システムを管理する業務に終始することができるようになりました」（佐藤氏）。

　コスト面でいえば、サーバーの台数が少なくなった分、電力コストが下がる。運用コストについては、どれくらい低下したのか、その効果を数字で示すのは難しいが、経営者、情報システム担当者にとってわかりやすい変化が、ビルに義務づけられているビル電源法廷点検がなくなることだ。ビルは半年に一度、電源を切って点検することが義務づけられている。こうした場合、社内にサーバーを置いている場合、情報システム担当者が休日出勤し、サーバーが無事に稼働するかをチェックしていることが多い。

　JBグループの場合、データセンター利用前は、全国4カ所にサーバーを置いていたため、1年だけで8回の点検作業が行われていた。データセンター活用後、この点検コストと作業負担がなくなるなどプラス効果が出ている。

　JBグループの情報システム部門は、2007年からユーザーに事例として紹介することをふまえたシステム構築を行うこととともに、「先進技術研究」というもう1つの役割が課せられるようになった。

　「先進技術研究とは、世の中で評価が定まる前の技術を評価し、次代の商材を探すという役割を担っていました。そこで注目したのが仮想化技術です。評価が定まる前の技術だった仮想化を、社内サーバー統合に積極的に活用していくこととしました」（佐藤氏）

　最初に仮想化を導入した2007年当時は、技術的にも未確定な部分もあったという。「この段階から、当社としては以前から研究していたVMwareを活用しました」。

　2007年段階では、物理サーバーは28台を10台に統合したが、この10台のサーバーの中に仮想化したサーバー71台が動作する環境となった。仮想化の際に導入したのはVMwareだった。

　2007年当時、仮想化技術は標準的なものが未確定であったが、JBグループでは以前から研究していたVMwareを採用する。

　「ちょうどVMwareが普及していくのと社内で採用するのが同じタイミングとなりました。仮想化に対して興味を持っているお客様に、自分達の実感をふまえて説明できたことはビジネスとしても大きなプラスとなったと思います」と佐藤氏は振り返る。

　2009年10月には、クラウド導入支援と試験環境を兼ねた「クラウド・インテグレーションセンター（略称＝CLIC）」をオープンする。従来、JBCCはハードウェアを販売し、その上に保守のようなサービス、ソフトなどを提供し、ビジネスとしてきた。しかし、クラウドの活用が主流となれば、従来型のハードウェア販売ビジネスは期待できない。

　佐藤氏はサーバー統合、仮想化を進めた背景を次のように説明する。

　「当社のトップからは、先進技術のショーケースを作り、クラウドに向けたビジネスを変えていく方向性を示せというリクエストがありました。当社がターゲットとしている中小企業のお客様は、サーバー統合や仮想化に興味はあっても、なかなか手を出せないという声があります。CLICや社内のサーバー統合は、そうした声に対する回答のひとつとなったのではないかと考えています」。

■第2段階として開発部門サーバーの統合、仮想化を推進

　こうして社内のサーバー統合、仮想化が進んでいく一方で、依然として残されていたのが開発に利用していたサーバーだった。

JBCC ERP事業部オープン技術本部・富山昌幸本部長

クラウド以前の開発環境の課題

開発環境のクラウド化により、開発・検証環境を短時間で用意可能になったほか、社内調達および構築工数の大幅削減を実現

　「開発用サーバーの場合、情報システム部門の管轄ではありません。各プロジェクトごとに必要なサーバーが置かれています。しかも、情報系サーバーとは異なり、JBグループに所属する企業ごとに別々のサーバーを利用しています。改めて数えてみると、JBCCだけで全国に100数十台の開発用サーバーがあることがわかりました」（JBCC ERP事業部オープン技術本部・富山昌幸本部長）。

　JBグループの場合、情報系で利用しているIAサーバーに加え、開発系サーバーには多くの顧客を持つIBM System iシリーズサーバーが多数存在していることも、サーバー統合が進まない1つの要因となっていた。

　「ところが2010年になって、社内の会議で、開発用サーバーの統合が進んでいないことがわかると、会長の石黒（JBCCホールディングス株式会社石黒和義代表取締役会長）から、『特別理由がないのであれば、開発系サーバーも統合、仮想化を進めるべきだ』という声があり、開発系サーバーの統合に着手することになったのです」（富山本部長）

　ソフトメーカーではなく、システムインテグレーターの開発用サーバーを統合し、仮想化するというと、1つのサーバーに異なる顧客の環境が混在することになる。セキュリティなどの面で問題はないのだろうか。

　「開発用サーバーの統合というと、異なるお客さまのシステムを混在させるという印象を持たれるかもしれませんが、このサーバーはあくまでも開発用です。動作確認のテスト等は実施しないのでデータは持っていません。純粋な開発環境のみです。しかも、『アクセスできるのは各プロジェクトに関わっているスタッフだけ』といったセキュリティ管理をきちんと行えば、開発環境の統合、仮想化は十分可能であると判断しました」（富山本部長）。

　ただし、サポートの観点からどうしても物理的にハードウェアを残す必要があるケースにも配慮。サポート用のサーバーに関しては統合せず、残すこととした。

　また、同じ開発用サーバーではあるがIAサーバーの統合運用スタートは7月から、iシリーズの統合は2011年1月からスタートすることとした。これは、同じサーバー統合といっても、IAサーバーとiシリーズとでは、かなり環境が異なることが明らかになったためだという。

　「やはりIA系サーバーの仮想化と、iシリーズの仮想化はだいぶ違います。例えばパーティションの数についても、iシリーズの場合、1ブレードあたり最大で20まで。そういった違いをひとつひとつ確認しながら作業を進めていく必要があります」（富山本部長）。

　すでに7月から稼働しているIAサーバーについては、「開発環境は仮想サーバーに適している」という声があがっている。

　現段階では物理サーバーは15台、仮想サーバー170台が動いている。7月のスタート以来、トラブルはない。予想以上に多くのサーバーが活用され、早くもサーバーが足りない事態が起こるほどだという。

　「開発環境の場合、利用するのはエンドユーザーではなく、技術者です。新しい技術が登場し、テスト的に利用してみたいという要望があっても、これまでは物理的にサーバーを用意する必要があり、実現までに早くて10日間、20日間の時間がかかっていました。これが仮想化環境となったことで申請後、即サーバーを起ち上げることができるようになったので、7月のスタート以来、予想以上の数のサーバーが必要になっているのです。通常、開発プロジェクトについては稟議、承認というプロセスが必要ですが、開発者が1時間、2時間勉強したいという要望であれば、申請なしでも開発環境を提供するようにしています」（富山本部長）。

　現在は実施していないが、開発者にコスト意識を持たせる意味もあって、将来的にはプロジェクトごとにサーバー使用量に応じた課金制度をとることも検討中しているそうだ。

■サービストラブルの自動復元機能作りを模索

　サーバーの仮想化完了後については、「開発者の環境については、サーバーだけでなくクライアント側の仮想化することを検討しています。JAVAと.NETを使い分ける必要がある開発者は、2台のパソコンを置いて作業しています。クライアント仮想化を実現すれば、パソコンが1台ですみます。ソフトウェア保守のために異なるバージョン環境を保持しなければならない場合など、クライアント環境の仮想化は有効な手段になりそうです。また、パブリッククラウドの活用も検討しています。低価格のパブリッククラウドを活用すれば、従来のようにデータを整理して容量を小さくするのではなく、機密性の低いデータについてはパブリッククラウドに移すという発想も可能です。どういった使い方をすればいいのか、トライアルしてみたいと考えています」（佐藤氏）と早くも新しい試行錯誤が始まりそうだ。

　さらにシステム自身についても、新たな課題が見えてきた。JBグループでは、24時間、365日体制でシステム監視を行う「SMAC（ソリューションマネジメント&アクセスセンター）」という組織を持っている。社内システムの監視もここで行っているが、複数のサービスを利用している場合、それぞれちゃんと稼働しているのかを確認する作業を自動化できないかという声があがっている。

　「これまで、サーバーが稼働しているのかを監視するという感覚でしたが、それ以上に手間がかかるのは各アプリケーション、サービスがきちんと動いているのかの確認です。現在は人の手で行っていますが、監視だけでなく、トラブルがあったと認識した際にはアプリケーション、サービスが自動修復する機能を持っていれば、運用コストのさらなる削減が可能になります」（佐藤氏）

　これを実現する技術ツールを持つことで、情報システム部門の業務負担が軽減するだけでなく、システムインテグレーターとして新しい商材になると見ている。