導入容易性を上げるために：学習コストとビジネスモデル・ミスマッチ
製品開発の悩みの１つは、導入可能性と導入容易性のジレンマです。一般に強い支持を受けるほどターゲットは狭くなると思いますが、システムも同じで特定のシステムへの親和性を強めるとそれ以外のシステムでは使いにくくなってしまいます。
ラウンドアバウトが現在CentOS上のApacheモジュールをプラットフォームに選択したのは、Webサーバーの環境としては一番のシェアがあるからです。それでも日本でそのシェアは50%前後のようです。今は残念ながら残りの半分はあきらめるざるを得ません。RH系Apache環境では、Apacheと一体となって動くことで、システム的には圧倒的に高い導入容易性を誇ります。しかし、導入容易性はシステム特性ばかりではありません。ラウンドアバウトでは、４つの切り口でさらに導入容易性を高める施策を打ち出しています。
■４つの切り口
- 学習コスト ： 製品利用に対して必要とされる知識を身に着ける為のコスト
- ビジネスモデルミスマッチ ： 製品を使いたくても収益モデルと合わない為に使えない
- 導入・所有コスト ： 製品の調査、購入、インストール、設定、保守、ライセンス管理などのコスト
- ライセンス不使用コスト ：製品性能がオーバースペックの時、余剰分の性能に対するコスト
製品知識は製品を導入するうえで欠かせませんが、 あまりに多くの知識が必要だと、その学習コストが非常に大きくなって導入効果が薄れかねません。といって理解が不十分であれば、せっかくの機能が使えなくなったり、かえってトラブルになってしまいます。
学習コストに対する問題について、ラウンドアバウトは基本設計のポリシーによって、増えるのではなく、大幅に下げる効果があります。なぜかと言えば…
- オートレイアウト、自動容量調整などは、携帯端末１つ１つのスペックに対する知識を不要とするので、この点でコンテンツ制作者は学習する要素を大幅に減らすことができる。
- PCHTML、全ての携帯用HTMLなど、全ての言語が利用でき、混在も可能であるので、自分の持っているスキルに合わせて開発可能なので、追加で学習すべき事項が極小化される。
- 起動や遮断などもっとも重要な作業は、Apache管理の一環として行われるので、ラウンドアバウト独自の作業がそもそも存在しない。
- 設定に関しても基本的にデフォルトのままであり、設定方法もApacheの設定方法と同じなので、Apache設定の知識があれば学習する必要がない。
- システム構成、アプリケーション構成が変わらないので、ラウンドアバウト導入前後でURLや設定などに影響を与えるものが基本的には無い。
学習コストや運用負荷コストという隠れたコストはライセンス購入費に比較して目立ちませんが、システム開発・運用にとっては実に厄介な問題です。ラウンドアバウトでは、そのコストが増えるどころか、トータル的にはかなり削減されます。
ラウンドアバウトを長く使用しているお客様には、「導入していることを忘れていました」「空気みたいで存在感がないですね」などと言われますが、これ以上の褒め言葉は無く、これこそ理想的なミドルウェアの姿であると考えています。
■ビジネスモデルミスマッチに対する対策
せっかく製品が気に入っても、料金モデルが導入したいサービスに合わない場合が多くあります。
- 利用者には月額料金を取っているのに、製品は初期費と年間保守費である
- ドメイン毎に課金しているサービスなのに、製品はサーバー単位である
- 組み込んで数を売る自社製品に取り入れたいが、製品の価格体系と合わない
SI、製品、ASP、クラウド、有料会員ビジネス、EC、広告モデル、B2B、B2C、自社システムなどなど、ITビジネスは非常に多様です。ラウンドアバウトは携帯サイトを簡単に作成できるミドルウェアなので、どこにでも、どんな用途でも利用価値がありますが、通常の「サーバ単位・初期費・年間保守料」では、ビジネスに組み込めないケースが多々出てきます。
そこでラウンドアバウトは 「パートナーライセンス」を当初から提案しています。様々なビジネスモデルに合わせてラウンドアバウトのライセンスモデルを合わせる方法です。ラウンドアバウトは、第一にソフトウェアであり、第二にApacheというシステムに融合しやすい製品です。その柔らかさを生かしてすでに幾つかの製品やサービスの中でパートナーのサービスを支えています。
ソフトウェアなんだから、柔らかく考えると無限に可能性が広がる
そう考え、市場にアプローチしています。
■残りの２つ
もう２つの導入を妨げるコスト問題については、次からのエントリーで触れていく予定です。
→導入・所有コストを無くす：だから、ラウンドアバウト導入済みホスティング