Eric Sink
SourceGear 社、ソフトウェア開発者
February 2005
日本語版最終更新日 : 2005 年 4 月 8 日
要約: Eric は、ISV がユーザーを信頼しなければ、ユーザーからも信頼されないと主張しています。この記事には英語のページへのリンクも含まれています。
私はマイクロソフトの社員ではないことを読者のみなさんにもう一度お伝えしておきます。私は、ここ 1、2 年で、マイクロソフトのデベロッパー ツール グループが世間に示す姿勢が変化してきていると思います。デベロッパー ツール グループは、あらゆることをオープンにするようになりました。このような動向を業界用語では "透明性"
と言います。このような概念を推進する統率力は、サーバーおよびツール担当の上級副社長である Eric Rudder によってもたらされたと話してくれた人もいます。
この透明性の考え方は、Community Technology Preview や Product Feedback Center など、さまざまな形で目にすることができます。しかし、最も顕著な変化は、マイクロソフトの社員が書き込んださまざまな Weblog (ブログ) がいたるところに存在することでしょう。私はつい最近まで、マイクロソフトのある社員が書き込んだ Weblog を毎日読むのを習慣にしていました。現在は膨大な数の Microsoft Weblog があるので、簡単にはすべてを読み始めることはできません。大量の Weblog を読むことができるのは、Scoble だけです。
この記事では、この透明性の考え方を詳しく調査し、小規模の ISV にとってもこの透明性が非常に重要になっている理由について説明します。
ソフトウェア販売という魔法
ISV の特徴を真剣に考えてみると、ソフトウェアを販売するということは驚くべきことだと感じます。有史以来、大部分の製品は実体のあるものでした。土地を購入すれば、穀物を植えることができます。テーブルソーを購入すれば、板を切断できます。オレンジ色のシャツを購入すれば、イリノイ州でのバスケットボール試合にふさわしい格好になります。このような製品には実体があります。
これに対して、ソフトウェアとはデジタルな知的所有物で、偶然適切な順序になった一連のバイト列にすぎません。実際に、ここ SourceGear 社では、売上の大部分は物質的なやり取りが行われていません。お金が T-1 回線から流入し、製品が流出していきます。それは、ときに魔法のように見えます。顧客はまったく実体の見えないものを購入し、それに対して現金を支払うのです。
しかし、古いことわざにあるように、金のなる木はありません。顧客がソフトウェアを購入しようと、大砲やバターを購入しようと、すべての製品購入者がお金を手放すという難しい決断を下すようにまでに、一定の信用と信頼が必要になります。消費者の立場から言えば、製品の種類が異なれば、必要だと感じる信頼度も異なります。車を購入する場合は、非常に高い信頼度が必要だと感じます。しかし、ペーパー クリップを購入する場合は、それほど高い信頼度は必要ありません。
ここでは、ソフトウェアの購入は極めて "高い信頼度" が必要な取り引きであることを説明します。人々は ISV からソフトウェアを購入するとき、現在と将来の両方において、以下のように多くのことを ISV に期待し、信頼することになります。
- 購入する製品が、使用しているコンピュータで機能すること。
- 問題が生じたときに ISV がサポートしてくれること。
- ISV が製品の機能を強化し続けること。
- 機能強化されたバージョンを手ごろな適正価格で入手できること。
- 当分の間、倒産しないこと。
つまり、ユーザーにソフトウェア代金の支払いを求めることで、ISV も多くのことを要求されます。ISV はユーザーから信頼されることを期待していますが、では ISV はどの程度ユーザーを信頼しているでしょうか。
この比喩的な表現が拡大解釈されないで私の意図を明確に示すために、ISV とユーザーの関係を 2 人の人間の人間関係と比較してみましょう。"お互いに" 信頼しあっていないと人間関係は成り立ちません。一方が信頼を求めても、自分が信頼していなければ関係は成り立ちません。
ユーザーをまったく信用しようとしないソフトウェア企業家をよく見かけます。誰かを信頼すると、攻撃を受けやすくなることは真実です。人間関係とまったく同様に、信頼することにはリスクが伴います。傷付くこともあります。しかし、信頼がなければ関係はまったく成り立ちません。
透明性は ISV がユーザーを信頼する 1 つの手段です。法人組織の裏側をユーザーに見せることでユーザーに信頼を示せば、ユーザーから容易に信頼を得ることができるようになります。
ここアメリカ中西部には、透明性を理解していると思われる Steak-n-Shake というレストラン チェーン店があります。この店のスローガンは、"目に見えることが正しいこと" です。つまり、客に料理を準備しているところを見せれば、バーガーに怪しいものを混入できないという考え方です。
この考え方をまだ理解できない方は、さらに私の話に耳を傾けてください。次のセクションでは、透明性を持つことで ISV がユーザーを信頼できる 8 つの方法を紹介します。
1. Weblog を保有する
私が ISV のユーザーならば、以下のような Weblog を希望します。
- 健全を装った従来のようなマーケティング声明は希望しません。企業や製品について、実在の人物が 1 人称で話していることを聞きたいと考えます。
- CEO の言葉からの短い引用を含むプレス リリースには興味がありません。CEO の話全体の引用を希望します。
- 顧客対応部門の担当者の話は聞きたくありません。製品の開発に携わっている実際の開発者が書き込んだものを読みたいと考えます。
Weblog では、製品を支える人々を知る手段が提供されます。
Weblog であれば何でもよいというわけではありません。ここでは、私の考え方を説明します。多くの Weblog は、朝食に何を食べたかや昨夜遊ぶ手段を見つけたかどうかを、世間の人々に話さなければいけないと感じる人によって書き込まれています。それ以外にも、宗教や政治に対する考え方を書くため、または遠くの親戚に日々の子供の写真を見せるために Weblog を保有する人もいます。このような Weblog は、私が考えている "ブログ" とは種類が異なります。
ここで推奨している種類のブログは、多くの人々が "企業 Weblog" と呼ぶものです。世間の人々に製品を支える人たちの個人的な一面を示すことが目的ですが、個人的になりすぎてもいけません。あなたがどういう人であるかを示すことよりも、主にトピックを重視してください。つまり、大切なことは、難解な人生について詳しく書くことではなく、企業や製品について書くことです。
小規模 ISV に勤めている場合は、Weblog を書くことを検討してください。ただし、危険をよくわきまえた上でこの課題に取り組んでください。優れた Weblog を書くことは見た目よりも困難です。Weblog を書くには多くの時間や労力が必要になります。それでも、Weblog を適切に書きあげれば、企業の透明性を大幅に高める優れた手段になります。
2. Web ベースのディスカッション フォーラムを提供する
ISV とユーザーが共同でコミュニティを形成します。どのようなコミュニティを形成すればよいでしょうか。"Law and Order" の再放送を見るために近隣の人々が全員家の中に閉じこもってしまう地域に住みたいですか。それとも、外に出て外気に触れ、隣の芝生を褒め、ガソリンの価格について慰め合う地域に住みたいですか。
ユーザーに対する最も簡単かつ最善の働きかけの 1 つは、会話の場所を提供することです。人々は、特に共通の話題を共有すると、それについて話し合いたくなります。単純な Web ベースのディスカッション フォーラムで、これを実現する場所を提供できます。
この種のフォーラムには、以下のような 2 とおりのコミュニケーションを図ることができるという利点があります。
- 1 つは、ユーザーから ISV に話しかけることができます。ユーザーが助けを必要としたときに ISV に質問できます。ユーザーはバグを報告できます。また、新しい機能を要求できます。迷惑を被ったときに不満をぶつけることもできます。
- もう 1 つは、ユーザー同士で会話できることです。誰かが製品のことで困ったときに同情できます。ユーザー同士で助け合うことができます。
すべてが適切に機能すると、ISV もユーザーも莫大なメリットを得ることができます。活発なコミュニティになれば、製品全体の重要性が高まります。
ただし、実際のコミュニティでは何が起こるかわかりません。実際のコミュニティで起こることを制御することはできませんが、起こったことを明確に制御することはできます。基本的なガイダンスは、以下のようなインフラストラクチャを提供し、障害を取り除くことです。
- 人々がコメントや質問を簡単に投稿できるようにします。誰の妨げにもならない優れたフォーラム ソフトウェアを使用します。
- 社員全員の参加を求めます。開発者がディスカッションに積極的になれば、コミュニティの動きは活発になります。
- 寛大な議長になってください。個人攻撃や完全に主題から外れている話題は取り除きます。ただし、メッセージが寄せられているということは、誰かが製品に不満を持っているということなので、そのメッセージを削除しないでください (苦情があるということは、関心があるということなので、とにかく不満を受け付けます。苦情を言ってもらい、製品を向上させてください)。
この目的では、Telligent Systems から私の友人の無償プラグを挿入するのが適切なようです。Weblog の優れたソフトウェアやディスカッション フォーラムが必要な場合は、このサイトに用意されています (私と Telligent Systems 社とは繋がりはありません)。
ユーザーの発言が必ずしも気に入らなくても、製品について話し合う場所をユーザーに提供します。これは、ユーザーに信頼を示すための優れた方法です。
3. 製品の問題点を隠蔽しない
上記のように、通常、ソフトウェア ユーザーは、製品の機能が将来確実に強化されていくことを知りたいと考えています。
もちろん、この規則には例外があります。先週、私は Scrabble コンピュータ ゲームを約 20 ドルで購入しました。この場合は、将来のアップグレードはあまり重要ではありません。現在の形式でゲームを楽しめればそれで構いません。恐ろしいバグを発見しない限り、このベンダがアップグレードを提供することはあまり期待していません。
しかし、大部分のソフトウェア製品の場合は違います。Vault の購入者は、製品の将来について頻繁に質問を寄せます。この製品の購入者は製品を長期にわたって使用する予定で、この先、製品の機能が継続的に強化されることを知りたいと考えています。
ただし、ユーザーは製品の機能強化を希望するだけでなく、通常は、製品が特に "どのように" 機能強化され、成熟していくのかについても関心を持っています。ユーザーは、製品の機能が "幅広く" 強化されるだけでなく、"細部に渡って" 強化されることで安心します。ここでは、これらの用語を以下のように定義します。
- 新しいユーザーにアピールするときは、製品の機能が "幅広く" 強化されます。
- 既に製品を所有しているユーザーに対して品質を向上させるときは、製品の機能が "細部に渡って" 強化されます。
通常、製品を幅広く強化するには、新しい機能を追加します。まったく新しい分野のユーザーを獲得することを目的とする場合は、多くの場合、まったく新しい機能を製品に追加することになります。たとえば、現在、Eclipse 統合を Vault の機能として追加する処理を行っています。一部の既存のユーザーもこの機能を求めていますが、これを追加する主な動機は新しいユーザーを獲得することです。
問題は、ISV が製品の機能を細部に渡って強化することではなく、幅広く強化することにこだわるという悪い癖に陥りやすいことです。"新しい機能" と "新しい収益" との関係はわかりやすいですが、単に既存のユーザーを満足させるために強化を行うビジネス ケースを作成することは困難です。
それでもやはり、ユーザーが満足しなければよくない結果を招くことは直感的に分かります。そのため、小規模 ISV にとっては、時間を割いて以下のような現在のユーザーを満足させ続ける行動を取ることが重要になります。
- 製品はどのくらい磨き上げられているでしょう。単に機能するだけでしょうか。それとも光沢があり清潔ですか。
- 優先順位が低レベルおよび中レベルのバグを修正する時間を取れますか。それとも、緊急レベルや高レベルのバグを修正し、他のバグはそのまま残しますか。
- 製品を向上させたり、高速にしたり、現在のユーザーにとって使いやすくしたりするために、開発者の時間を費やしていますか。それとも、お金を受け取った途端、ユーザーのことは忘れてしまいますか。
つまり、私が言いたいことは、通常、製品の問題点を隠蔽しようとする企業は、問題点を解決しない企業であるということです。
完璧なソフトウェア製品はありません。あらゆる製品に問題点があります。唯一の論点は、ベンダがそれらの問題を解決しているかどうかです。製品の問題点をオープンにすることで、それらの問題を解決することに責任を持とうとする企業であると認識します。ユーザーが信頼できる企業はこのような企業です。
4. 正当なユーザーを困らせない
まず、ユーザーが製品の使用許諾契約書に従うのに役立つ何らかのメカニズムを大部分の ISV が実装することには、意味があるということは明確にしておきます。ここでは、このメカニズムを "ライセンス執行コード" と呼ぶことにします。
しかし、正直に言いましょう。ライセンス執行コードは、非常に無駄なものです。製品の他の機能と同様に、ライセンス執行コードの設計、実装、およびテストに時間やお金が費やされます。ただし、この "機能" からユーザーに利益がもたらされることはありません。
したがって、ライセンス執行コードを含める際は、度が過ぎないようにすることが非常に重要です。目的は、"正当なユーザーを正当と認める" ことだけです。これより踏み込んでも、実際に起きるのは以下の 2 つのことだけです。
- 勝てない争いになります。だまそうとする人が勝ちます。
- 製品が使いにくくなることで、正当な製品ユーザーを傷付けます。
断然、正当なユーザーの方が一般的なので、正当なユーザーに最適な製品とすることに意味があります。ライセンス執行コードは、簡単かつ必要最低限にする必要があります。ライセンス執行コードを含めることで、ユーザーに信頼していないことを伝えています。このメッセージは大声で叫ばず、ささやくようにしてください。ライセンス執行コードは正当なユーザーにとっては価値のないものなので、少なくとも正当なユーザーを傷付けないようにしてください。
すべての SourceGear 製品では、基本ライセンス執行として単純なシリアル番号手法を使用しています。SourceGear では、この機能がまったく面倒ではなくなるようにしようと努力しています。しかし、ここまでたどり着くにはいくらか回り道をしなければならなかったことも告白しましょう。
Vault 1.0 をリリースしたときに、ユーザーが 2 台のサーバーで同じ Vault シリアル番号を使用できないように設計された "ライセンス認証" システムを含めました。誰もがライセンス認証を避けたいと思っていても、マイクロソフトも行っているので、うまく行くだろうと考えました ("私たちの責任ではありません。マイクロソフトが始めたことです!")。
しかし、事態は予想どおりにはいきませんでした。第一に、マイクロソフト製品のライセンス認証手法の動作は思っていたほど悪くはないようです。基本的にはこの考え方は好きではありませんが、マイクロソフト製品のライセンス認証によって実際に不都合が生じたことはないということは認めざるを得ません。数か月前、自宅用に新しい PC を構築しました。Windows と Office の新しいコピーを購入し、どちらの場合もライセンス認証は正常に機能しました。
それに対して、SourceGear のライセンス認証はあまり満足できるものではありませんでした。この "機能" はほとんどの場合は動作しましたが、動作しないときは本当に苛立ちを感じました。ライセンス認証に苦労しているユーザーを助けようと電話に向かっている自分に気付いたことが何度もありました。構成を間違えたために、ユーザーが製品をインストールできないこともありました。しかし、ライセンス執行コードに問題があるために、製品をインストールできないユーザーがいることははるかに大きな問題です。本当に恥ずかしい思いをしたこともありました。
ライセンス認証によって、技術サポートの負荷が増加し、ユーザーを悩ませ、保守するコードが増加しました。ライセンス認証から何らかのメリットを得たとしても、そのメリットは目に見えません。Vault 3.0 リリースではライセンス認証を削除しました。ユーザーを信頼することに意味があるだけでなく、作業量が大幅に減少します。
5. 簡単なデモ ダウンロードを提供する
現在では非常に一般的なことなので、言及することすらばかげていると感じますが、ユーザーが製品を購入する前に試用できるデモ ダウンロードを提供します。どんなシビアな ISV でも、ユーザーが製品を見る前に必ず料金を支払わせるポリシーを実装することはないと思います。
それでも、デモ ダウンロードを用意すべきかどうかについての疑問はないとしても、デモ ダウンロードを適切に管理する方法についての疑問はあるでしょう。高い信頼を得る方法は、以下のとおりです。
- 機能を制限しないで、使用期限を付けたデモを用意します (デモとして "機能を低下させている" ISV は、私を信頼していないので、私も彼らを信頼しません)。
- デモを見るためだけに、ユーザーに登録を要求しないでください (私はプライバシー ポリシーではなく、製品を評価します)。
- 製品について他言しないことをユーザーに同意させないでください (製品について話すことを禁じる ISV は何かを隠そうとしているようで、信頼できません)。
オンライン デモは扱い方次第で、ユーザーに信頼を示す 1 つのチャンスになります。
6. 返金を保証する
ISV への信頼が決定的に表れるのは、返金保証かもしれません。何らかの理由で購入後にユーザーの気持ちが変わった場合、ユーザーは製品の使用を中止し、ISV は返金します。通常、この決定を下すために、ユーザーに販売後 30 日間の猶予を与え、場合によってはそれ以上の猶予期間を与えます。この種のポリシーの動機付けは非常に単純です。つまり、ユーザーのリスクを取り除くことで、容易に ISV と関係を結べるようにします。
返金保証によって、企業の透明性は著しく向上します。また、購入見込みのユーザーは、見たいものをすべて見ることができます。ユーザーは製品を試し、技術サポートを試して、購入過程の雰囲気を感じることができます。ユーザーは製品に満足できなかった場合、[Undo] をクリックするだけで返金を受け取ることができます。
この種のポリシーは非常にリスクが高いように思われますが、多くの事例が示す証拠により、実際にはリスクが少ないことが一律に示されています。返金保証を提供する多数の ISV と話をしましたが、全員同じように話してくれました。今までに返金要求をしたユーザーは非常に少数で、多数のユーザーが購入した製品に大きな信頼を抱いているということです。
7. 財務状態を少しだけ共有する
私は小規模 ISV からソフトウェアを購入するとき、通常、以下のようなさまざまな企業財務情報を知りたいと考えます。
- 収益が高い企業か。
- 企業が所有している現金はいくらか。借金はいくらか。
- どのような種類の企業か。所有者は誰か。
- 外部からの出資者がいるか。
- 創立者は未だにかかわっているか。創立者が相当な株式を保有しているか。
私は人よりも詮索好きだと思います。ISV の本質がどのように作用するかを知っているので、企業のあらゆる側面を気にしています。
これらすべての情報の公開を勧めているわけではありません。ただし、情報をほんの少し共有するだけで、ユーザーからの信頼が高まる場合があります。多くのソフトウェア企業は生き残れません。ユーザーは、その会社が当分の間倒産しないかどうかを知りたがります。会社が堅実に運営され、有益に運用されているならば、そのことをユーザーに知らせてください。
8. 今後の計画について話す
社会通念によれば、守れない約束をしてはいけません。これはすばらしいアドバイスで 100% 同感です。
しかし、このアドバイスを、約束は一切すべきではないと解釈する人もいます。私は、もっと前向きに解釈ができると信じています。ユーザーは、ISV の将来の計画を本気で知りたいと考えています。次期リリースにどのような新しい強化機能が含まれるか、そのリリースを入手できる時期はいつ頃なのかを知りたいと考えています。このような質問に、確実に答えることはできるでしょうか。
常に、約束は少なく、結果は多くということだけは覚えておいてください。この範囲内にとどまっていれば、将来のリリース計画についてユーザーと話すことを検討してください。
不透明にすること
ここまで、信頼性と脆弱性のレベルについて説明してきましたが、非常識だと思われたかもしれません。理解できないことではありませんが、私を非常識なことに熱弁を振るう困った奴だと診断した方のために、以下の 2 つのことをお伝えしておきます。
まず、必ずしも ISV が上記のすべての提案を実装することを期待しているわけではありません。いつものように常識に従って、私のアドバイスが自社の状況に適しているかどうかを判断してください。
次に、すべての ISV が "完全に" 透明であることは期待していません。上記のすべての要点に沿って行動する場合でも、内密にしておきたいことは数多くあります。
たとえば、ユーザーが ISV の実収入や所得額を知る必要はありません。ISV が作業項目や技術サポート チケットの追跡に使用する内部データベースに、ユーザーがアクセスできる必要もありません。また、ユーザーから報告されたバグに付ける優先順位についてのチームの議論を、ユーザーが聞く必要もありません。
相互信頼がなければ関係が成り立たないのと同様に、健全な境界がなければ関係は成り立ちません。
提案を実践する
私はこの記事の執筆中に、良心の呵責に苦しみました。正直に言うと、現在の SourceGear は、上記 8 つの論点のうち 7 つで非常によいスコアを獲得しました。しかし、執筆しながらスコアを獲得しなかった残りの 1 つの論点に悩まされました。
1997 年の会社創立以来、SourceGear では "払い戻しは致しておりません" というポリシーを明示してソフトウェア製品を販売しています。購入希望のユーザーには、30 日間のデモ期間を最大限に利用するように推奨しており、ユーザーがより多くの時間を必要とする場合は大幅な期間延長に応じています。返金のわずらわしさに手を焼かなくて済むように、ユーザーには製品を購入する前に多くの時間を費やして製品を評価することを推奨しています。
通常、このアプローチでも有効に機能しますが、完璧ではありません。Web サイトで "払い戻しは致しておりません" というポリシーを明示していても、返金についてユーザーから問い合わせを受けることもあります。また、このポリシーはかなり厳格に見えますが、正直に言うと自社の製品を好まない人から金銭を受け取ろうとは思っていません。返金要求がそれ程多くあったわけではありませんが、思い出す限り、正当な期間内に返金を求めたユーザーを拒絶したことはありません。
このように、SourceGear のポリシーと実践は矛盾しており、返金を行う際に一貫性のある方法で要求を処理する標準はありません。さらに、"払い戻しは致しておりません" というポリシーを明示していることで、SourceGear を親しみにくい会社にしています。これで SourceGear の信頼性に疑問を抱く人もいるのではないかと思っています。
SourceGear は変わろうとしています。以後、SourceGear のポリシーは 30 日間の返金保証期間を設けます。この件についてここで詳細を説明し、読者を退屈させるつもりはありません。すべての詳細については、SourceGear Web サイトで示しています。透明性というテーマに関する私の見解が、読者にとって有益かもしれないという理由だけで、この話題を共有しました。
まとめ
ある記事を公開すると、その記事について私と議論することを希望する方々から頻繁に連絡があります。今回は、そのような議論の場として適切な場所をご紹介します。
最後に一言アドバイスをして締めくくろうと思います。細部まであら探しをしてもかまいませんが、この記事の要点を見過ごさないでください。つまり、"ユーザーを信頼しなければ、ユーザーからも信頼されません" ということです。私の提案は気に入らないかもしれません。そのこと自体は問題ありませんが、この原則が読者の状況にどのように当てはまるかを考えてみてください。
The Business of Software
