これらはそれぞれ異なる分野向けの，異なる目的を持ったツールです。クラウド分野においては，さまざまなソフトウェアをユーザーが望む形で動的に切り替えながら，使いたいと考えるでしょう。デバイスの分野においては，特定のソフトウェアをデバイスを壊すことなく使いたいと考えることでしょう。

Snappyは，単一のデバイス上に含まれるソフトウェアコンポーネントを持ったシステムを作ることを目的にしています。スピーカーやWi-Fiステーションといったデバイスに新しい機能を追加するために，他のソフトウェアに影響を与えることなく，新しいソフトウェアをインストールするといったシナリオです。それ以外にも，ソフトウェアを簡単にアップグレードしたり，アンインストールすることも考えています。

JujuとSnappyは現在，異なるチームが開発を行っています。Jujuのチームでは，どのようにすればクラウドの世界により多くの品質の高いソフトウェアを導入できるかを考えています。Snappyのチームでは，単一のデバイスに対して，ソフトウェアの追加や削除，アップグレードの信頼性を高められるかを考えています。それぞれ異なる哲学を持っているのです。ただし，将来的には一緒になるだろうと思います。

たとえばNTTのように，大量のネットワークデバイスの機能追加や更新をリモートで行わなくてはならない場合，その処理・手順には高い信頼性が求められます。マルチデバイスへの対応について考えるようになった時，JujuとSnappyの連携を考える必要がでてくるでしょう。

Jujuは5年たちましたが，Snappyはまだ1年ほどの若いプロジェクトです。今はまだシングルデバイスの操作の信頼性を高めることに注力したいと考えています。

OILには今は主にサーバーメーカーに参画していただいています。日本のメーカーで言えばNEC様のAvotonサーバーも入っています。現在はストレージベンダーも含めて話をしているところで，おそらく近々に発表できるものと思います。ちなみに，どこがパートナーに入ったらいいと思います？

ベンダーとの協業は私たちも重要であると考えています。OILはデータベース，メッセージングシステム，Software-Defined Network，スケーラブルストレージといったさまざまなコンポーネントの組み合わせから，数多くのデータを生成するからです。特に「うまく動かなかった」とき，OILはそのすべてのログやマシンの情報をベンダーに提供できます。

OpenStack上に特定のベンダーのソフトウェアをデプロイしようとしてうまく動かなかった時，必ずしもそのソフトウェアが悪いとは限りません。OpenStack上の別のベンダーが提供するコンポーネントが悪いのかもしれませんし，Charmに問題があるかもしれません。OpenStackのすべてのコンポーネントを単一のベンダーで網羅するのは難しいので，CanonicalがOILに参画するベンダーの統合的なテスト環境を用意し，自動的にテストを回すことで，何か問題が発生した時に真に関連するベンダーへと素早く情報を提供します。

ユーザー側から見た場合も，OILで使われているものであればある程度安心して導入できるのではないでしょうか。

はい。ただし先程も言ったように，JujuについてはSnappyとの連携ができるまでは使わないでしょう。主にスイッチの管理はSnappyが担当します。Snappyが機能の追加を行い，SnappyそのもののインストールはMAASが行う形です。

ラックにOSがないホワイトボックススイッチが接続された時，MAASが新しいボックスがあることを検知し，OSとしてSnappyをインストールします。あとはSnappyを使って機能を追加していき，MAASのクラスタコントローラーによってスイッチ設定を行うイメージです。ここまでが完全に自動化されます。

私たちはハードウェアを作ることはありません。ただ，Ubuntuを利用するあらゆるマニュファクチャーとパートナーシップ契約を結びサポートすることはもちろんあり得ます。個人的にホワイトボックススイッチのマーケットには興味を抱いています。とてもイノベーティブな分野だからです。

明日にでも最初のパートナーシップについて発表できるでしょう（注7⁠）⁠。

日本は私たちにとって非常に重要なマーケットであると考えています。なぜならPaaSやIaaS，DaaSなどソフトウェアのスケールを先導するさまざまなビジネスが存在するからです。これらはいずれも私たちにとっても興味のある事柄です。

日本は，新しく柔軟でスケールするシステムへと加速しています。私たちも共に歩みたいと考えています。