収益ポイントのシフト
利用者の近くで収益を得る(収益ポイントのシフト)
創業時より、利用者に価値もたらすアプリケーション開発こそが最重要であると考え運営してきております。しかしながら営利企業ゆえ「利用者 < 支払者」となってしまい、利用者に価値をもたらす事より支払者(発注者)に喜んでもらえる事に開発の重点が移ってしまう事が非常に残念ながら過去に起きておりました。
この矛盾を解決するため収益ポイントを出来る限り利用者の近くへ移す事を決断しました。 利用者の近くで収益を上げる事で、「利用者に価値をもたらすアプリケーション」=「支払者に喜んで頂ける事」とする事が可能となり、事業構造として良いアプリケーションを開発出来る体制とする事が可能となりました。
- 自社販売向けアプリケーション開発であれば「利用者 = 支払者」となります。
- 収益シェア事業向けアプリケーションであっても「利用者 = 支払者」となります。
現在では自社販売向けと収益シェア事業向けの開発を主として行っており、結果として受託開発は行っておりません。
受託開発のマイナス
利用者に価値をもたらすアプリケーションを開発するのではなく、支払者(発注者)が良いと考えるアプリケーションを開発する事になってしまう事が、業界全体で広く普遍的に起きております。もちろん弊社においても過去多く起こりました。
「利用者に価値をもたらすアプリケーション」=「発注先が良いと考えるアプリケーション」の場合は、利益をもたらす価値があるアプリケーションを開発する事が出来ます。
しかし「利用者に価値をもたらすアプリケーション」 NOT =「発注先が良いと考えるアプリケーション」の場合は、利益をもたらす価値があるアプリケーションを開発する事が出来ません。
開発側が利用者にとって良い提案をしても、発注側が予算などにより提案を受け入れなければ開発する事が出来なくなり、利用者に価値をもたらすアプリケーション開発が難しくなってしまいます。
リリースして終わりではない
開発してリリースして終わりではありません。アプリケーションをマーケットにリリースした時点が本当のスタートポイントです。
本当に価値を高めてより良いアプリケーションに育てていきたいのならば、サービス開始後であっても利用者の希望に耳を傾けて随時改善改良していかなければなりません。
利用者により高い価値をもたらす事(高いユーザーエクスペリエンスの提供)が可能であると思えば、利用者から要求が無くとも積極的に改善改良を行い新たな機能や新たなUIを実装し続ける事が必要となります。
自社販売向けまたは収益シェア事業向けの開発の場合は、「利用者 = 支払者」となりますので上記した改善改良を随時行う事が可能となります。
しかしながら受託開発の場合、「利用者 NOT= 支払者」となってしまうので、発注先がアプリケーションを随時改善改良していくための予算を用意しなければ、アプリケーションを改善改良を随時行う事が不可能となってしまい時間の経過とともに陳腐なアプリケーションとなってしまいます。