プライベートクラウドで共通プラットフォーム化を推進。収益・ブランドを加速する日産自動車のIS／IT戦略「VITESSE」の内幕：ITでビジネスを変革。デジタル時代のテクノロジリーダーたち（3）（2/4 ページ）

共通プラットフォーム第3世代が稼働。ベンダーロックインからの解放

編集部　現在、グローバルでの共通プラットフォームを整備していますが、その目的と経緯を教えていただけますか？

木附氏　BESTにおける取り組みとして「プラットフォームの標準化」と「ITインフラの統合」があり、その一環として2008年から第1世代の共通プラットフォームの運用を開始しました。VITESSEを開始した2011年からは第2世代を、2014年からは第3世代の運用を開始しています。

　第1世代は「できるだけITインフラリソースを共用しよう」という発想で作られたもので、プライベートクラウドではありません。汎用性のあるアーキテクチャは構成できず、国内のアプリケーションの一部のみを稼働させるにとどまりました。プライベートクラウドといえるのは第2世代からです。日本の他、米国、欧州のシステムも部分的に対象とし、R＆D系、生産・販売系、一般管理系など、さまざまなビジネスドメインを支えるアプリケーションが一つのプラットフォーム上で稼働をしています。

　これに対して第3世代は、グローバルで統一したプラットフォームとしました。「アライアンススタンダードプラットフォーム」（ASP）と呼んでおり、サーバープラットフォームのアーキテクチャはルノーも含めて全て共通化しています。

　規模としては、現在物理サーバーが100台弱で、仮想的に動いているゲストOSが約1000台ほどです。1台の物理サーバーに10〜11ノードが稼働している計算になります。稼働しているアプリケーション数は米国、欧州のもの含めて約170になります。

編集部　既存の物理環境の横に、プライベートクラウドによる共通プラットフォームを構築して徐々にアプリケーションを移行しているのですね。そうした共通プラットフォーム構想は、そもそもどういった意図から始まったのでしょうか。

木附氏　もともとは「ベンダーのハードウエアにロックインされたくない」という考えから始まりました。ロックインされないためにはどうすればいいかと考えたとき、ハードウエアだけではなく、OS、ミドルウエアまで含めて標準化していく必要がありました。そこでアーキテクチャスタックを固めて、「多少の自由度は担保するが、標準に沿わないものはサポートしない」という姿勢を貫くことで共通プラットフォーム化を進めてきたのです。例えばサードパーティ製の良いソフトウエアがあったとしても、弊社の仮想環境に載らないなら選定から外すといった具合です。そうした条件を基準に、大多数のアプリケーションを標準環境に載せていきました。

編集部　ただ一般に、システム構成要素の中では標準化しやすいものと、そうでないものがあると思うのですが。

木附氏　ハードウエア系は標準化しやすいため、PC、サーバー、ネットワークは標準化してきましたが、ソフトウエアや新しいテクノロジの標準化は確かに難しいですね。どう変わっていくかが読みにくいですし、次から次へと新しいものが出てきます。標準を決めてしまうことによってシステム改善が停滞してしまうリスクもあります。そこで、変わりやすいもの、変化が読みにくいものについては、あえて標準にしないという戦略を採ってきました。

編集部　なるほど。一方、第3世代の共通プラットフォームについて、NIST（米国国立標準技術研究所）の定義では、自動化がプライベートクラウドの一大要件とされていますが、それに沿う形になっているのでしょうか？

「プライベートクラウドで何より重視しているのは、『業務部門のユーザーがどのようなサービスを使いたいのか』を知り、迅速に応えること」

木附氏　完全なオートメーションは行っていません。当初はそうした考えもありましたが、絶えずエボリューションを繰り返していくやり方の方を重視しました。最初に作り込んでしまうと初期投資も掛かりますし、後からの変更が難しくなります。インフラ整備で最も困るのは“変更・廃棄ができなくなること”です。そこで第1世代の時から6年間を標準的なサービス提供期間と定め、移行期間の最後の一年は旧システムのサービスレベルは保証しないなど、ユーザーとともに確実に新しいシステムに移行できる体制としてきました。

　それに、プライベートクラウドで何より重視しているのは、「業務部門のユーザーがどのようなサービスを望んでいるか」ということです。サービスに対するユーザーニーズを最優先して、要求が出るに従い、迅速にサービスラインアップを増やしていくアプローチを採っています。例えばポータル機能を使いたいなら「Microsoft SharePoint」を、分析系をやりたいならBIツールをサービス化するといった具合です。運用についてはバックエンドの改善で効率化しています。

編集部　では、例えばサーバーのプロビジョニングなど、開発部門向けのサービスも提供しているのですか？

木附氏　それはインフラ部隊が実施しており、まだセルフサービスとして開発部門には提供していません。インフラ側からすると、割り当てたリソースを無駄に使ってほしくないので、開発側の自由に任せたリソース増強はしたくはありません。一方アプリケーションの開発側はリソースに余裕を持たせて開発をしたいので、必要以上のリソースを要求しがちです。そうしたせめぎ合いの中で無駄や非効率が生じやすいサービスの提供については、やはり人の判断が必要だと考えています。私たちは、サーバーリソースを提供することで商売になるクラウドベンダーとは違いますから。

編集部　今後、全てのシステムを共通プラットフォームに移行する予定ですか？

木附氏　できるものは移行したいと思っています。ただし、コストを掛けて移行しても効果が望めないものは移行しません。例えばメインフレームなどのレガシー環境を無理にマイグレーションすることはしません。右から左に動かすだけで数億円が掛かるケースもありますから。移行してもアディショナルバリューが望めないものは、やっても意味がありません。

　アプリケーションも必要のないものは移行しません。一定の条件に基づいて改善や廃止を決めるロードマップを持っていますので、それに基いて移行プランを立てています。具体的には、機能の充足度、コスト、技術の古さ／新しさ、ビジネスへの影響度などを軸にポートフォリオ分析を行っています。

　例えば「ビジネスに対してクリティカルな影響があるのにテクノロジ的に古いもの」は開発部門にアップデートのリコメンドを出します。「ビジネスへのインパクトが少なくテクノロジ的に古い、さらにコストまで掛かるもの」は基本的にタイミングを見ながら徐々に廃止していく方針です。ですから、メインフレームでは基本的に新規アプリケーション開発は行っていません。リニューアルのタイミングを見て、共通プラットフォームに順次アプリケーション持って行き、メインフレームから徐々に出ていくということを地道にやっています。