okkyの日記: リリースノートはセールス目線で
弊社も製品はときどきバージョンアップする。で、そうするとリリースノートと言うのが出てくる。
リリースノートは基本的に技術の観点から書かれているので、各お客様について、どの機能が重要でどの機能が重要じゃないのかを読み取るのは、担当とお客様自身の仕事になる。
アメリカとかのお客様は、この辺のリリースノートは全部自力で読む。自社のシステムがどの会社のどの製品のどの機能を使っているのか、基本的に外部に教えたくないからだ。その辺は機密情報に属する。だって乱暴な話、同じハードウェア・ソフトウェアセットを用意したら同じようなサービスが出来ちゃうかもしれない。特に小さいが小回りが利く、なんて所は同じ事を市場占有率 No.1 な会社に真似をされたらひとたまりも無い。製品を買った相手に聞くようなこともしない。そこから大手に情報が回るかもしれないじゃないか。
しかし、日本では SIer に丸投げで、その SIer すらろくにリリースノートを読まない。理由は「英語で書かれているから」とかそういう頭が痛くなるような理由だ。
やむをえないので、各製品のお客様担当が読む事になるが、だからといってリリースノートの分量が減るわけじゃない。どうやって読む量を減らせばいいのか、という相談が来た。内容を読んで、理解してお客様に説明する必要があるのだ、と。まぁ、うちらだって英語を読むのは苦手だ。
.
いや、相談されてもな。魔法はないのでやれる事は1種類しかない。
まず、お客様のニーズを細かく分類する。単純に何を使っていて何を使っていないかではなく。
- 何を使っている/使っていない
- 何を使いたいと思っている/使いたくないと思っている(本当に使いたい機能と、存在する機能に齟齬がある事がある。機能 x は本当は使いたくないが、本来使いたい機能 y が存在しないのでやむなく x で代替している、とかね)
- 各機能について、何が重要なのかを知る(Security なのか Performance なのか Robustness なのか)
こうすると、リリースノートの中でどれが優先度が高くて、どれが優先度の低いものなのか、細かく分類できるようになる。で、とりあえずリリースノートに書かれた fix 情報などを、この観点で分類する。で、優先度の高いものから順番に処理をしていく。
優先度がつくということは、すごく乱暴に言うと「優先度の低いものは後回しにして良い」と言う事だ。自分たちも見たくないだろうが、実はお客様も聞きたいと思っていない。だから、説明しなくても一緒だ。どうしても気になるなら、あとで聞いてくるだろう。それから調査しても遅くは無い。
.
で、これはようするに「既存客に新製品を売り込む」時と同じだ。
- ニーズを正確に把握し、
- ニーズに沿った説明をし、
- 余計なことを言って客をパンクさせる、などという状態を回避する
営業さんが業務の一環として行っている事を行い、結果を共有すればよい。そうすれば、複数の人間を使ってリリースノートを分割し、優先度をつけられるようになる。優先度がついたら、上のほうを読むのは担当自身の仕事になるが、どうせ読まなきゃいけないのは3-7個の間の数に決まっている。それ以上必要になる事はまずもって、ない。
.
なので、どうすればいいのか、の説明はこうなる。
「担当の営業さんに相談してごらん?!」
リリースノートはセールス目線で More ログイン