日本全国267人のファンのみなさまこんにちは
やっと原付が全開走行できるようになりました、ふなです。
なかなか原付の整備は楽しいですね。
アドレスV100は細かいバージョンがあり
同じ部品でも微妙に違うという話をよく聞きますが
それを体験できることがありました。
プーリーフェイスを交換したんですが、
キックのギア受けカバーがプーリーフェイスにネジで
止まっています。
当然、外したネジを使って、もう一度取付ようとすると
なんとつかない。
穴の位置は同じだが、ネジの大きさが変わっていた。
取り外し前が5mmで、交換部品は4mmだった。
ホームセンターに行き、4mmのステンレスネジと
ワッシャーとバネワッシャーを3セット購入。
45円でした。あのね、45円のために1時間ちかく時間をロス。
そのくらい部品は共通にしてほしいぞよ。
後期のマシンのはずなので、前期のマシンは4mmだったのかも
しれない。なんだかなー。
まあしっかりつくようになったからいいのかね。
これではエンジンスワップとか先が思いやられます。
GWあたりにエンジンスワップしようと思っているのに、、、
むーん、困ったもんだ。
でもメンテナンスは楽しいな。
さて、20日はfimoがメンテナンスするそうです。
いろいろな方の書き込みからわかるように
fimoのサイトは自社運営ではなく、OEM提供のサイトです。
おそらく独立サーバープラン的なものだと思っています。
昔、KBB社にも確認したのですが、
顧客が自由に機能を追加できる仕組みはなく
何か機能追加があれば、KBB社が請け負うという仕組みです。
つまり、APIはないのです。
それでもアプリがリリースされた時には喜びました。
アプリがリリース出来るってことはまがりなりにも
APIのようなものがあるから実現できるので、、、
ところが、調べてがっかりしたのがアプリは顧客作成ではなく
KBB社製でした。つまりアプリ作成まで外注だったわけです。
内部的なAPIはあるでしょうが、決して表には出ないでしょう。
独自サーバープランのような仕組みの良いところは
初期費用が安く、ランニングコストが高いので
早期撤退すれば、費用が安く済むという利点があります。
失敗時のリスクが少なく済むわけですね。
成功時には、高いランニングコストを払うので、
それに伴い、連動して売り上げを確保する必要があります。
会員がどんどん増えて、SHOP等の売り上げが上がれば
それは十分賄えるはず、という計算があったと思います。
その計算通りになっているか知る由はありませんが
元社員の方の話とか聞いていると、かなり台所事情は苦しいようです。
たしか技術者は募集していると思いましたが年俸450万程度でしたので
そんなに技術的に高い人は集まらなっただろうな、という気がします。
OEMのサーバですので、デザイン変更も出来ず、アプリも外注なので
WEBデザインの専門家とアプリの専門家を雇っても、活躍する場がないはずなのです。
でも雇ったってことには意味があると見ています。
1つの可能性としては、いよいよ、OEMサーバを捨てる時が来るのかも、と
期待しています。
SNSはOPEN-PNEでカバーできるし、SHOPもEC-CUBEとこちらもオープンソースの
プロダクトを選択でき、それをレンタルサーバーで実装すればいけるはずです。
そうすれば、ランニングコストは下がり、サーバの自由度も上がり、
WEBデザインの専門家とアプリの専門家が120%能力を発揮できる場所が
作れるはずなのです。
前に雇った技術者がLinux技術者だとしたら、OEMサーバからの脱却を
計るはずなので、、、
って、OPENPNE+ECCUBEって、SWAN時代に私が提案した案ですけどね。
まあいいや。
IDの共有部分だけ開発すればOKなので。
そうなると、ハッピー!となるはずですが、実は大きなハードルがあります。
それはKBB社が内部データを渡さない、というハードルです。
せっかくの顧客を逃すわけがないので、内部データの情報を提供するには
1億円払え、いやなら使い続けろ、というような条件を出すことは分かっています。
これもSWAN時代に指摘したこと。
でも、そこは知恵の出しようです。
おそらく4年位fimoを運営してきていれば、内部データを抜き取る方法を
見つけているはずです。
4年近くもシステムを触っていれば、セキュリティホールも抜け穴も見つけられるでしょう。
ただ単にKBB社の養分として会員が増える度に、サーバ強化で毎月のランニングコスト上昇を
指をくわえてみているだけではないはずなので。
アメリカ映画でもそうでしょう。
強力な敵がやってくるような時には、地下に反乱軍が潜んでいるではありませんか。
彼らは敵の弱点を発見し、そこをついて生き延びています。
その時がいよいよ来るのではないか、と期待してます。
オープン系のシステムなら自分たちでコードが書けます。
APIも実装可能です。アプリも独自で作ることが出来ます。
淡水系に進出するのも簡単なのです。
(ドメイン追加するだけだしね)
APIを公開すれば、会員が欲しい機能を自由に追加出来るし
アプリも糞みたいなものから有用なものが産まれるし
欲しいサービスが勝手に追加されるようになります。
会員数が2次関数的に伸びます。
これがWEB2.0の強いところですね。
そこまでやれるはずです。
出来ない言い訳並べる時間があるなら、出来る方法を模索したほうが
どれだけ生産的かなぁと思いますね。
これは過度な期待ではないと思うんだけどね。
そろそろ述べ登録者が3万人を超えて、ランニングコストがしゃれにならない
レベルまで来ていると思うんだよね。
(通常会員数連動でランニングコストは上がる)
今後、どういう動きをするか、楽しみではあります。
普通に「プレミアム会員募集」とか言って、ユーザーから
金を集めようとかしたら、ああ、コストUPをユーザーに負担させたのね
って残念な感じになるのかなぁ。
リーダーの力量が試される時でもあります。
じゃあまた!どんな未来を描くか楽しみ!
やっと原付が全開走行できるようになりました、ふなです。
なかなか原付の整備は楽しいですね。
アドレスV100は細かいバージョンがあり
同じ部品でも微妙に違うという話をよく聞きますが
それを体験できることがありました。
プーリーフェイスを交換したんですが、
キックのギア受けカバーがプーリーフェイスにネジで
止まっています。
当然、外したネジを使って、もう一度取付ようとすると
なんとつかない。
穴の位置は同じだが、ネジの大きさが変わっていた。
取り外し前が5mmで、交換部品は4mmだった。
ホームセンターに行き、4mmのステンレスネジと
ワッシャーとバネワッシャーを3セット購入。
45円でした。あのね、45円のために1時間ちかく時間をロス。
そのくらい部品は共通にしてほしいぞよ。
後期のマシンのはずなので、前期のマシンは4mmだったのかも
しれない。なんだかなー。
まあしっかりつくようになったからいいのかね。
これではエンジンスワップとか先が思いやられます。
GWあたりにエンジンスワップしようと思っているのに、、、
むーん、困ったもんだ。
でもメンテナンスは楽しいな。
さて、20日はfimoがメンテナンスするそうです。
いろいろな方の書き込みからわかるように
fimoのサイトは自社運営ではなく、OEM提供のサイトです。
おそらく独立サーバープラン的なものだと思っています。
昔、KBB社にも確認したのですが、
顧客が自由に機能を追加できる仕組みはなく
何か機能追加があれば、KBB社が請け負うという仕組みです。
つまり、APIはないのです。
それでもアプリがリリースされた時には喜びました。
アプリがリリース出来るってことはまがりなりにも
APIのようなものがあるから実現できるので、、、
ところが、調べてがっかりしたのがアプリは顧客作成ではなく
KBB社製でした。つまりアプリ作成まで外注だったわけです。
内部的なAPIはあるでしょうが、決して表には出ないでしょう。
独自サーバープランのような仕組みの良いところは
初期費用が安く、ランニングコストが高いので
早期撤退すれば、費用が安く済むという利点があります。
失敗時のリスクが少なく済むわけですね。
成功時には、高いランニングコストを払うので、
それに伴い、連動して売り上げを確保する必要があります。
会員がどんどん増えて、SHOP等の売り上げが上がれば
それは十分賄えるはず、という計算があったと思います。
その計算通りになっているか知る由はありませんが
元社員の方の話とか聞いていると、かなり台所事情は苦しいようです。
たしか技術者は募集していると思いましたが年俸450万程度でしたので
そんなに技術的に高い人は集まらなっただろうな、という気がします。
OEMのサーバですので、デザイン変更も出来ず、アプリも外注なので
WEBデザインの専門家とアプリの専門家を雇っても、活躍する場がないはずなのです。
でも雇ったってことには意味があると見ています。
1つの可能性としては、いよいよ、OEMサーバを捨てる時が来るのかも、と
期待しています。
SNSはOPEN-PNEでカバーできるし、SHOPもEC-CUBEとこちらもオープンソースの
プロダクトを選択でき、それをレンタルサーバーで実装すればいけるはずです。
そうすれば、ランニングコストは下がり、サーバの自由度も上がり、
WEBデザインの専門家とアプリの専門家が120%能力を発揮できる場所が
作れるはずなのです。
前に雇った技術者がLinux技術者だとしたら、OEMサーバからの脱却を
計るはずなので、、、
って、OPENPNE+ECCUBEって、SWAN時代に私が提案した案ですけどね。
まあいいや。
IDの共有部分だけ開発すればOKなので。
そうなると、ハッピー!となるはずですが、実は大きなハードルがあります。
それはKBB社が内部データを渡さない、というハードルです。
せっかくの顧客を逃すわけがないので、内部データの情報を提供するには
1億円払え、いやなら使い続けろ、というような条件を出すことは分かっています。
これもSWAN時代に指摘したこと。
でも、そこは知恵の出しようです。
おそらく4年位fimoを運営してきていれば、内部データを抜き取る方法を
見つけているはずです。
4年近くもシステムを触っていれば、セキュリティホールも抜け穴も見つけられるでしょう。
ただ単にKBB社の養分として会員が増える度に、サーバ強化で毎月のランニングコスト上昇を
指をくわえてみているだけではないはずなので。
アメリカ映画でもそうでしょう。
強力な敵がやってくるような時には、地下に反乱軍が潜んでいるではありませんか。
彼らは敵の弱点を発見し、そこをついて生き延びています。
その時がいよいよ来るのではないか、と期待してます。
オープン系のシステムなら自分たちでコードが書けます。
APIも実装可能です。アプリも独自で作ることが出来ます。
淡水系に進出するのも簡単なのです。
(ドメイン追加するだけだしね)
APIを公開すれば、会員が欲しい機能を自由に追加出来るし
アプリも糞みたいなものから有用なものが産まれるし
欲しいサービスが勝手に追加されるようになります。
会員数が2次関数的に伸びます。
これがWEB2.0の強いところですね。
そこまでやれるはずです。
出来ない言い訳並べる時間があるなら、出来る方法を模索したほうが
どれだけ生産的かなぁと思いますね。
これは過度な期待ではないと思うんだけどね。
そろそろ述べ登録者が3万人を超えて、ランニングコストがしゃれにならない
レベルまで来ていると思うんだよね。
(通常会員数連動でランニングコストは上がる)
今後、どういう動きをするか、楽しみではあります。
普通に「プレミアム会員募集」とか言って、ユーザーから
金を集めようとかしたら、ああ、コストUPをユーザーに負担させたのね
って残念な感じになるのかなぁ。
リーダーの力量が試される時でもあります。
じゃあまた!どんな未来を描くか楽しみ!
コメントする