BSA
The Business Case for Portability †
数百ものプロジェクトの経験が示すこととしては、クロスプラットフォームでポータブルなコードを書くことは多くの開発組織のスキルレベルで対応可能だ。
ただそのようなコードが書けるとして、それをすべきかどうかだ。
ポータブルなソリューションを作成することのただ一つの正当な理由は、さらに利益を生むプロダクトとして結果的になることだ。
収入面での問題は、十分に大きな市場と収益性の高い料金を獲得できるか、できないかに基づいている。
マーキテクトはよくこれらの収入面の要因を明確にするために良いと考える。
しかしながら、マーキテクトはキーとなるコスト要因を忘れがちだ。
以下を考えてみよう。
・開発者のトレーニングや品質保証、開発をサポートする人たちや、テストなどそれらのプラットフォームをサポートするためのコスト
・それらのプラットフォームをサポートするためのソフトウェアやハードウェアの設定や購入のコスト。それぞれのグループがそれらの業務のための配慮すべき違うニーズを持っている。開発者は動作速度が早いハードウェアを渡せば、もっとも生産的だろうし、通常最速だろう。QAやサポートチームはマッチしたターゲットとなる顧客のセグメントの動作オプションをちょうど反映した範囲のハードウェアを必要とする。もしIT部門でその役割が果たせない場合は、開発者やQAやサポートのだれかがそれをしないといけないだろう。これはよく見えないコストを生んだりする。
・それぞれのプラットフォームで厳密に製品が動作することを確認するための、開発者やQAのテストする時間。一般的なルールでは、大きく顧客の複雑化した設定（サポートするプラットフォームの完全なセット）が多くても製品のリリースまでには実施しようとするだろう。これは必然的なコストではないかもしれないが、代わりに収入の減少となるだろう。
・複数のリリースサイクルの管理の複雑さ。例としてSoalrisとHP-UXとLinuxをサポートすることにしたとしよう、これは3つのオペレーティングシステムを追跡しないといけないことを意味する。Sun MicrosystemsがニューバージョンのSolarisをリリースした場合、顧客はいつ製品がサポートをするかを知りたいと思うだろう。他のプラットフォームをサポートすることを選択する度に、製品のリリースサイクルをもっと管理することを少し諦めることになる。
これらのコストは十分な大きい標的市場によってのみ正当化することができる。
筆者が働いていたある会社ではSolaris-OracleデータベースとWindows-SQLServerの組み合わせをサポートしていた。
おおよそ90%がWindows-SQLServerで動作させていて、会社全体の80%以上の収入を占めていた。
クロスプラットフォームな製品をサポートするコストはリカバーができず、間違った市場の要求のためにお金を失っていた。
下記のような状況をクロスプラットフォームなソリューションを開発する前に直面するべきだ。
・市場の調査結果が、それぞれのプラットフォームに関連付けられた製品全体の開発やサポートのコストの増加を正当化するだけの十分な収入を明確化している。
・すべてのサポートするプラットフォームのテストや開発のトータルコストを知っていること。
・複数のプラットフォームをサポートしたり、テストや開発を許可するだけの十分な開発部門のリソースを持っていること。
・様々なプラットフォームをサポートしなければならない開発部門のそれを管理するための労力の相対的なインパクトを理解していること。例として、SolarisとWindowsをサポートしようとした場合、SolarisやWindowsのリリーススケジュールの遅延を説明しなければならない。
良いルールの核心はポータブルなテクノロジーはポータブルなアプリケーションよりも正当化しやすいことだ。
テクノロジーの場合、大きなソリューションのデザインされたソリューションの一部分を筆者は意味している。例としてリレーショナルなデータベースとコミュニケーションライブラリーを大きな市場が求めていたとする。Crossing th Chasm[ Moore 1999年 ]の本の中でオラクルがどうポータブルなテクノロジーが会社にとって重要な市場シェアを獲得したかが書かれている。
アプリケーションの場合、めったに大きなソリューションのコンポーネントとしてデザインされず、通常大きくて収益性の十分ある市場シェアを操作できる環境を伴って達成することができる。なぜならポータビリティは理解されないからだ。一つのオペレーティングシステム（Sun Solaris、MS Windows、IBM 360など）でしか実行されない、会社に収益をもたらす無数のアプリケーションがある。これらの会社は様々な理由からターゲットとなる実行環境を選ぶことを決定している。
ルールの核心はただのルールの核心だ。無数のプラットフォーム特有のテクノロジーとポータブルなアプリケーションがある。ポータブルなアプリケーションの例としては、いくつかのミッドレンジのサーバかデスクトップのアプリケーションを含む。
具体的な例としてはいくつかのミッドレンジなグラフィックツールはMacintoshとWindowsプラットフォームの両方で動作する。標準的なユーザにとってそれらのツールは許容ができるものだ。プロフェッショナルにとってはそうとはいかないし、プロフェッショナルの場合はハイエンドでプラットフォームで与えれれるすべてのケーパビリティを操作することになる。プラットフォーム特有のテクノロジーの多くの例として、Solarisでしか実行できないネットワークのアクセレーターや、Wintelプラットフォームでのみ実行されるシリアルポート拡張カードなどがある。この問題は複雑だが、開発チームがどうアプリケーションを開発すべきかを最終的に定義した標的市場につまるところかかっている。
コラム: ポータビリティはいつもお金と †
筆者はポータビリティの議論の範囲の両方のエンドを管理したことがある。筆者が働いていた会社は新興市場にたいして新しい種類のエンタープライズクラスのシステムをMicrosoft製品( MS Windows NT / 2000 とSQL Server )でのみで動作する、ポータビリティではないものをMicrosoftの開発ツールを使って開発していた。最初の挑戦はSun Microsystemsにシステムを売り込みに行ったことだった。読者も想像する通り、最初の返答は“No Thanks、我々はMicrosoftのテクノロジーをベースとするシステムは欲していない（にもかかわらず、実際彼らが述べた言葉は強い拒否ではなかったが）。Sun MicrosystemsはSolarisとOracleの組み合わせで動作する、Java/Java2EEのシステムを私たちに欲していた。私たちはまたファイザーからもMicrosoftのベースのソリューションはSolaris-Oracleの要求にフィットしない理由でnoの返答をされていた。
初期の拒否に対する対処は難しかった。なぜならSunとファイザーは良い顧客になるだろうと思っていたし、私たちは若くてハングリーなスタートアップだったからだ。しかしシンプルなコスト分析は私たちが現状のリソースでアプリケーションをポータブルにすることはできないというものだった。Sunにたいして開発に必要な資金について聞いた時、彼らはNoと言った。筆者は彼らを非難はしなかった。なぜなら我々が見積もったそのジョブは数百万ドルのコストになりそうだったから。
あまりよくない状況だったが、周りの人々はプラットフォーム特有のものにフォーカスしつづけることへの決断をサポートしてくれた。規律の良い結果によって収入に対する貪欲さが特に増幅された。そういった状況にもかかわらず私たちは自分たちのテクノロジーを改善し続けカスタマーリストは増えていった。そのようなプロダクトのリリースの中で、私たちはSunとファイザーに再び話を持って行った。偶然にもいくつかの良いことが起こっていた。開発したシステムは2社にとってそれなしでは会社を単純に継続できないほどの機能を持つポイントに到達していた。しかも彼らの競合はそのシステムへの適合を済ませ、システムによって使用許可を付加させることを彼らに与えていた。ついに彼らが動いた。最初にファイザー、遅れてSun。キーとなる教訓は、一つのプラットフォームでの良いソリューションを構築することは、多くのプラットフォームでの凡庸なソリューションよりももっと重要だということを。
ポータビリティの議論でもう一つのエンドでは、筆者はサーバソフトウェアでMicrosoft、Sun、Linuxのオペレーティングシステムで動作し、クライアントソフトウェアはWindowsとMacintoshで動作するものを管理したことがある。前述した例とは異なり、それらは完璧なアプリケーション（ソリューション）ではなかったが、顧客環境の大きなソリューションの一部に埋め込まれるコアのテクノロジーだった。このケースでは、テクノロジーはポータブルなソリューションを正当化する要求だった。サーバーサイドでは収入の分散はWindowsとUnixで実行させているユーザが半分ずつだった。クライアントサイドでは、私たちの最大の顧客だったAdobe、Symantec、Macromedia、Corel、RoxioはWindowsとMacintoshの両方での動作を要求していた。加えて彼らは継続的に私たちに他のプラットフォームにも移植できないか聞いてきていた。この確認は読者の顧客が収益性のあるポータブルなソリューションかどうかを確認するベストなアプローチだ。
担当者のつぶやき †
みんなの突っ込み †
