BSA / Changing Brand Elements

BSA

Changing Brand Elements †

要約 †

ブランド要素の変更は、UIの国際化よりは難しいことが多い。主な理由は次のふたつ。

• 一般に、ブランド要素の変更をサポートするようには求められない。そんなに頻繁に起こるものではないから。
• ブランドは、プロダクトやそのアーキテクチャに多大な影響を及ぼす。開発チームはそれを甘くみていることが多いが、以下のようにいろんなところに影響が及ぶ。

変更の影響が及ぶ分野 †

サブシステム名

サブシステムやコンポーネントの名前は機能ベースのものであることが望ましいが、プロダクトやブランドにちなんだ名前になることも多い。また、機能ベースでつけた名前が結局プロダクトやブランドの名前になることだってある。

ソースコードリポジトリ

リポジトリの構造をプロダクト名にちなんだものにしていた場合、プロダクト名の変更にあわせて変更の必要がある。

QAやテクニカルサポートの追跡システム

この手のシステムにはバグのカテゴリ分けに対応しているものがある。プロダクト名やブランド名にちなんだカテゴリを使っているのなら、これも変更しなければいけない。Web上でユーザー向けにサポート情報を公開する場合などは特に重要。

コンポーネントの物理的な場所

コンポーネントのインストール先は、会社名やモジュール名を反映させたものにするのがいちばん無難だ。これらが変わるときには注意が必要だ。

APIの命名や構造

APIも、さまざまなブランド要素にちなんだ名前や機能になることが多い。たとえば、会社名やプロダクト名を関数のプレフィックスにして分類するなど。

エラーメッセージ

…にも、会社名やプロダクトのブランド要素名が含まれるかもしれない。

QAや自動テストの基盤

ここまでに挙げたあれこれを変更したなら、QAや自動テストにも変更が必要になるだろう。

Sales Collateral（宣材？）

…とは、セールスを支援するためにつくるモノのこと。ウェブサイトとかホワイトペーパーとかケーススタディとか用語集とか。

QAと変更 †

ブランドやブランド要素を変更するにあたってのQA作業は、かなりのものになることが多い。 システムの多くの部分が変わるし、ターキテクチャが変わる可能性もあるので、完全なQAサイクルをまわす必要がある。

かつて、インストーラのバグに悩まされたことがある。ある状況で、新しいソフトウェアを古い場所にインストールしてしまうというものだった。 ベータテスト中に見つかったのがせめてもの救いだった。

担当者のつぶやき †

みんなの突っ込み †