リリース管理（Release Management） †
要約 †
リリース管理には三つの要素がある。
何をリリースするのか、誰が対象なのか、そしてなぜ彼らはそれを欲しがるのかだ。
何をリリースするのか †
特定のコンポーネントのパッチみたいな小さなものをリリースすることもあれば、プロダクト全体のように大きなものをリリースすることもある。ここで扱うのはそういう話。
- フルリリース（完全リリース）
- プロダクト全体をリリースするもので、新規インストールのときに使うことが多い。
- パーシャルリリース（モジュールリリース、アップデートリリース、fractionalリリース）
- 何らかの機能的なサブセットをリリースするもので、ベースシステムを拡張するオプションモジュールなどに使う。
- パッチリリース
- プロダクトのサブセットで、インストール済みのコンポーネントに既知のエラーがあった場合などにそれを置き換える目的で使うことが多い。一般に、パッチリリースで既存システムに新機能を追加すべきではない。
リリースの決定は流動的なものだ。ふたつのマイルストーンを含めたフルリリースを計画していたとしよう。ここで、競合他社が手ごわい機能のリリースをアナウンスしてきたとする。競合の先を行くためには、最初のマイルストーンだけを含めたフルリリースを出して、二番目のマイルストーンはパーシャルリリースにすることになるだろう。こういった要素が、「何をリリースするのか」に関するmarketectの判断に影響を及ぼす。
誰が対象なのか †
アルファリリースは内輪だけを対象として、外部のユーザー向けにはベータリリースで対応することもある。ここで扱うのはそういう話。
- limitedリリース（managedリリース、controlledリリース）
- 特定の顧客だけを対象としたリリース。たとえば、ある特定のハードウェア環境でだけ発生するバグに対するパッチリリースなど。
- generalリリース
- すべての顧客を対象としたリリース。
Marketectと開発チームは、「誰を対象にするのか」と「何をリリースするのか」を混同しがち。
「誰を対象にするのか」はスコープの話で、「何をリリースするのか」はサイズの話。
新しいウィルスが見つかったら、アンチウィルスソフトのベンダーはすぐにでもウィルス定義ファイルをアップデートしたい。
このリリースのサイズは小さめだが、スコープは大きい。
誰もが使えるように、ベンダーのウェブサイトで公開されることだろう。
多くの企業が、リリースの対象を定めるのに苦労している。たいていは、顧客についてよくわかっていないのがその原因だ。
たとえばSolarisとWindows XPをサポートしているとして、Windows XP版だけに軽微なバグが見つかったとしよう。
Windows XP版を使っている顧客を把握していない限り、すべての顧客に対してアナウンスする必要がある。
非効率極まりないし、そもそもその通知は、パッチをあてるべき人にだけ届けばいいものだ。
なぜそれを欲しがるのか †
顧客側がリリースを受け入れる動機は幅広い。
「セールの10日前のタイミングで実運用環境にパッチをあてるなんて無理」と積極的に拒否することもあれば、「今すぐにでも欲しいんだ」と熱烈に受け入れることもある。
たいていのリリースは、その両極端の間のどこかに落ち着く。顧客がリリースを受け入れてくれるように、飴（新機能、パフォーマンス改善、バグ修正、信頼性向上など）と鞭（旧バージョンのサポート終了など）を活用することになるだろう。
飴と鞭のバランスをいかにうまくとっていくかがmarketectの腕の見せどころ。
新しいリリースは、以前のリリースとの互換性を保っていることが多い。
でも、そもそも三年前にリリースされたソフトウェアとの互換性を保つべきなのだろうか？
おそらく、その必要はないだろう。互換性を保つためのコスト（リグレッションテストや運用の検証、サポート費用など）がかかりすぎる。
もちろん、新しいリリースにアップグレードする気のない主要顧客を失うリスクはある。
インストールベースをできるだけ最新にしていくのがmarketectのだいじな仕事だ。
しかし、どんなに気にしたところで「バージョンスキッパー」は出てくるものだし、そういった人向けのアップグレードパスも用意する必要がある。どんなにしんどいパスであってもだ。
担当者のつぶやき †
みんなの突っ込み †
