VMwareの開発体制とインフラは？

　次に同氏は、VMwareの開発体制とインフラについて紹介した。「ほとんどの本稼働用の製品には、SCM（ソースコードマネジメント）として、PerforceとGitを利用しています。プログラミング言語は、C、C++、Java、Python、Rubyなど、開発プロジェクトやエンジニアリングによって使い分けられています」（スティーブン氏）

　Perforceに関して言えば、VMwareにおいて1日あたり1000万回以上も操作され、複数の機能追加やバージョン管理を平行して作業するためのブランチ数は1万以上、1日あたりのマージが100以上、レプリカは100以上、10GBのデータがレプリケーションされているという状況だ。

　同社のベアメタル型ハイパーバイザーであるvSphereの開発スケジュールは、メジャーリリース版が12から18カ月のサイクルだという。それを受けて、マイナーリリース版がバグ修正を6ヵ月ごとに繰り返して発行される。たとえば最新のvSphere ver.6.0は、2015年3月にリリースされ、マイナーリリース版の6.0u1は今年9月に発表される予定だ。

「開発体制は、コアのディベロップメントチームがメジャーリリース版を担当し、並行して他チームがマイナーリリース版を担当します。開発手法には、いわゆる一般的な“ウォータフォールモデル”を採用しています。そのため開発後のテストには、かなり時間を取っています」（スティーブン氏）

　2013年には、vCloud Airも発表された（日本は2014年11月リリース）。これは、VMware vSphere上に構築された専有型ハイブリッドクラウドプラットフォームだ。オンプレミスやプライベートクラウドと、パブリッククラウドの双方を利用できる。2016年に登場予定のサービスについては、クラウドファーストのアプローチによって、DevelopmentとOperationsを組み合わせたソフトウェア開発手法「DevOps」で開発を進めている。

VMWareの変革を促す3つの開発アプローチとは？

　続いてスティーブン氏は、同社の変革を促す新しい3つの開発アプローチについて紹介した。まず1つ目は「Eating Our Own Dogfood」という手法だ。もともとはマイクロソフトが提唱したもので、Dogfoodとは開発中の製品を外部に出す前に社内で行うβテストのことを指す。開発スタッフは、自身が開発に没頭していると、製品や機能に慣れが生じ、客観的な判断ができなくなる恐れがあるので、適正な判断が行えるように取るべきプロセスがEating Our Own Dogfoodである。これにより、製品内の機能間の連携や、他技術との相互運用などの問題点が浮き彫りにされるそうだ。


「Perforceで管理されたソースコードを自動的にビルドし、複雑なテスト環境で展開しています。このテスト環境は、社内でカスタマイズされたもので、物理サーバー上でESXをネスト（入れ子）化した構成とし、ユーザー環境と似た多数の仮想環境を構築することで、テストを迅速に実施できます。これにより、Eating Our Own Dogfoodで不具合を発見し、しっかりとバグを修正していきます」（スティーブン氏）

【次ページ】開発と品質管理の無駄を減らす「Dev Owns Quality」