AAXプラグイン開発はなぜ遅れているのか？

海外のBlogに掲載されている『なぜAAXプラグイン開発が遅れているのか？』デベロッパ、AVIDに多数の友人を持つという筆者の鋭い切り口からの問題の洗い出しと今後予想をぜひとも御覧ください。

オリジナルテキストはこちら＞＞＞『AAX 64 bit Plug-in Support – Why The Delay?』

AAX 64bitプラグインのサポート: なぜ遅れているのか？

Pro Tools 11発売と同時に、利用できるサードパーティプラグインの不足は移行を考えているユーザーにとって問題だ。しかしこれは間違いなくAvidにとっても大問題だ。もしユーザーが自身のワークフローへの影響がなくなったと判断するまでPro Tools 11の購入を遅らせるのであれば、今期どころかもしかすると2四半期にまたがって主要な売上げが失われることになる。我々が実施したアンケートでも、少なくとも25%のユーザーが対応状況を理由にアップグレードを行なわないと答えている。

ここで多くの人から寄せられた質問がある:。『なぜ遅れているのか？』我々はこの問題に対する共通の理由を探るべく、多くはオフレコだが、多くのデベロッパに話を聞いた。

SDKの問題

AAXプラグイン開発で最も重要なのがSDK(ソフトウェア開発キット)だ。デベロッパはこれを使ってプラグインを制作、ポーティングする。時を追ってSDK自体が改良されることもあるが、多数のデベロッパから、Avidが新しいバージョンのSDKをリリースする度にプラグインの開発に問題が発生していたという。これがAAXプラグインの開発およびリリースの遅延につながった。

PACEの問題

舞台裏で進められたPACEによるセキュリティ・システムは、現在AAXプラグインに統合されている。すべてのAAXプラグインはPro Tools 11で動作するためにいわゆる「デジタル署名」を要求される。iLokサーバー不具合に端を発する一連の問題に対して、PACEは大幅な労力を必要とされ、結果として当初いくつかのプラグイン・メーカーが予定していた発表時期に遅れが生じた。

デベロッパはAAXを最優先していない

デベロッパは異なるDAWプラットフォーム、OSシステムにプラグインを提供している。AAX、RTAS、そしてVSTやAUだ。AAXは、AvidやPro Tools 11への移行を予定しているユーザーにとって、重要リストのトップに位置しているかもしれない、しかしサードパーティのデベロッパにとって、そうであるとは限らない。AAXよりも優先する項目があるかもしれない。

SDKやPACEなど問題が重なって発生する場合、デベロッパは問題の解決までリソースを他のプロジェクトに振り分けるかもしれない。そうすることで生産性や売上を落とさずに済む。好き嫌いを別にすれば、Pro ToolsだけがDAWのすべてではない。デベロッパにとって、常にリストの最優先事項というわけではない。彼らにとってはビジネスと、次いで業界内のパートナーこそ優先しなくてはならない。必ずしも相互排他的というわけではないが、逆に包括的でもない。

コミュニケーション

もしAvidが正しく物事を進めていれば、喜んで擁護したいところだが、ことAAXに関して、Avidからの情報公開が常に明確だったとは言い難い。AAXプラグインにおいて32bitと64bit2つのフォーマットがあることに、多くのユーザーは未だにハッキリしない状況に置かれている。Pro Tools 10に対応したAAXがインストールされているからといって、Pro Tools 11ですべてが読み込まれるか、というとそうではない。Pro Tools 10で動作する32bitオンリーのAAXプラグインを製作することが、混乱に拍車をかけてしまうかもしれないのだ。

個人レベルでは、このブログを通じて知った多くの友人がAvidで働いている。そして過去数年間の雇用カットにより、少ない人員で同じあるいはより多くの業務を処理しなければならなくなった。Pro Tools 11を送り出すことは記念碑レベルの功績だが、チームに課せられたプレッシャーは計り知れない。この点を過小評価すべきではないだろう。

さて、これは貧弱なコンセプトとデザイン、マネージメントによる結果なのか？いや、非難に加担するには安易すぎるんじゃないか？敵意を隠さない人が大勢いるが、その多くは出店を冷やかしているくらいの気分なんだろう。始めから買おうとも思わない人々が石を投げているのだ。この記事はそんな事に加担するつもりはない、かわりに純粋なユーザーが現時点での問題を理解するための助けになればいいと思う。そこでデベロッパには「なぜ遅れているか」以外についても質問してみた。

最初の質問は、VSTとAUだけに絞ったほうがシンプルなんじゃないかというものだ。あるデベロッパからはこんな返答があった「AAXは優秀なプラットフォームだし、諸々の問題は別に考えておくのが正しいと思う。新しいフォーマットを創ることはとても難しいタスクだ。Avidは決して安易に取り組んでいるわけではないよ」

もう一つの質問は、この移行期にあたって他にどんな要素が含まれているか、というものだ。別のデベロッパからはこんなコメントをもらった「ユーザーの期待が常に現実的だとはかぎらないんだ。もっと早く欲しいと同時にバグもない状態が望まれる。リソースには限りがあるからどんなデベロッパでもこれは不可能だ。今日AAXプラグインをリリースしてしまうこともできなくはない。でもQA(品質管理)のチーム、ひいてはユーザーにとって好ましくないことになる。ユーザーの不興を買ったり、今までの成果を犠牲にするつもりはないんだ」「Avidはこうしたユーザーの期待を、もっとうまく調整できたかもしれない。Pro Tools 11のリリース時に25%くらいのプラグインが対応する、3ヶ月で50%とか、より現実的なタイムラインを提示すれば結果は違っていたはずだ」

「期待」ということでいえば、他のデベロッパからはこんな返答があった「多くの人が、大きな移行期には痛みが伴うことを忘れてしまっていた。AppleがIntelチップに移行した時も、多くのソフトウェアが動作しなくなった。いくつかのプラグインは１年以上も対応しないままだった」「フォーラムに行って自分ならもっと上手くできた、Avidは駄目だ、と主張するのは簡単だ。もしくは友達がAvidで働いているから内部情報に詳しい、とかね。正直に言えば、こうした人のほとんどがマネージメントや製品開発のプロセスを驚くほど無視した主張をする。本気にしてはいけない、もし彼らが主張するとおりにそれほど賢いなら、フォーラムで一日くだを巻く代わりに、とっくにそうした会社で働いているはずだからさ」

また、いくつかのデベロッパは、このタイミングを自社のプラグイン・デザインを再評価する良い機会と捉えているようだ。AAXの到来をプラグイン開発プロセスの改善に利用している会社さえある。数日前に届いたDave Tremblayの返答にもこうある。「もし変更に時間をかけているのなら、今がうまくやるためのチャンスだ。将来的にもこれは良いことだ」

デベロッパとの会話からは、予想したとおり幾つもの視点が見えてくる。ほぼ全員が、大きな移行期においてこれらの遅延は避けようのないものだと考えている。と同時に一方では、いくつかの点についてもっと適切にコントロールできたのではないかと考える人もいる。確かなことは、Avidとサードパーティ・デベロッパは品質に妥協せず、できるだけ早くAAX対応を果たせるよう必死に開発を進めている、ということだ。我々が望むほど早くはないかもしれない。だが記事の文頭を思い返して欲しい。Avidとっても、AAX対応が早く進むことが最良なのだ。