約束に気をつける (Beware the Promises You Make) †
要約 †
- 契約上の管理とサポートする対象にはくれぐれも気をつけた方がよい。
- 以前、引き継いだ契約に「Macintosh OS 8.1 以降」に対応するというものがあった。
- マーケティングチームが将来的なことについて も約束してきたが、私たちには受け入るは難しかった。
- あきらかに言って私たち開発チームにとって 解決不可能な課題になることは明らかだ。
- 可搬性のあるソフトウェアを構築した際は、契約を尊重するためにも、販売した後のことまで配慮しなければならない。
- 少なくとも、対応するバージョンとプラットフォームは、具体的に明確にするべきだ。
- 古いプラットフォームの対応に割く時間を制限するためにも、プラットフォームによっては個別のサポートポリシーがほしくなるだろう。
チャプターサマリー †
- 可搬性を主張する人は、自分の欲求を後押しするために数々の主張を行う。一般的には次のような主張がある。
- 新しい標的市場への取り組み
- 今の環境は残しておきたいけど、新しい環境でも使いたいという既存顧客への対応
- 可搬性のあるアプリケーションが欲しい理由も、それを構築したい理由も、実際はたいしたことではない。
- 開発者は簡単だと思っていたり、かっこいいと思っていたりする。
- 別のソリューションに依存しているアーリーイノベーターやアーリーアダプターのうち一人か二人くらいは、あなたのプロダクトが可搬性を備えるべきだ、という主張なら、どんなものであっ ても慎重にチェックしている。
- 可搬性のあるアプリケーションを作るにあたってビジネス上の正当な理由があるとしたら、そうすると利益が出るということだけである。マーケテクトは売上のモデルを作ることに長けているが、必要なコストがどうなっているのかわかっていない。
- 可搬性のあるアプリケーションを作るのは考えているよりもずっと困難で、長い時間がかかる。
- 苦痛のマトリックスはテストしなければならない組み合わせを網羅している。
- 扱いやすいマトリックスを作るためには、次のような点に気をつけなければならない。
- 無意味な組み合わせ、対応しない組み合わせを取り除くこと。
- サポートする構成を常に明確にする。そして新しい構成をサポートする場合は慎重に進める。
これをチェックしよう †
- 対応しているそれぞれのプラットフォームについて、開発、品質管理、技術サポート、営業のリソースは足りているか。
- 対応しているそれぞれのプラットフォームをテストするのに十分な時間をかけているか。
- プロダクトが動作するプラットフォームのベンダーによって提供された重要なリリースが、テクノロジーロードマップに追加されているか。
- テストに費す労力を最適化するため、マーケット駆動な構成マトリックスを作っているか。
これを試してみよう †
- 対応しているプラットフォームは何か? それはなぜか?
- プラットフォームごとの市場占有率はどううなっているか?それぞれのプラットフォームごとのコストや利点はどううか?
- どれかのプラットフォームをサポート対象外にするとどんなことが起きるか?
- あるいは、サポートするプラットフォームを追加したらどんなことが起きるか?
担当者のつぶやき †
みんなの突っ込み †
- IEがいなくなる世界は目の前に来ているし、Safariが第二のIE化しているという話もあったりするので頭が痛い -- おかざわ?
