Hatena::ブログ(Diary)

まこぽっぽ

2008-11-11

現状のセカンドライフ内のスクリプト製品について書いてみようか。

21:46

最初のポストの計画は、結局計画倒れ。なんだかセカンドライフスクリプト周りの世界についてこれ以上首を突っ込むのは自分のアバターを危険に晒すだけでたいして利益があるわけではない、と思うようになってきたのもあります。え、単に根性がないからだって?あは。

ところで、そろそろ単体のスクリプト製品を販売するような形態は成り立たなくなりつつあります。というか、はじめからかなり胡散臭い商売やっていうのは分かっててやってるんだけどね。今成り立っているのは、ほとんどが外部サーバ(自分で立てたサーバなど)でその製品向けにWebサービスの口を開けて、3階層のうちのビジネスロジックデータベースはそっちでもってしまって、セカンドライフの中のアイテムには、UIだけをもたせるという形式です。こうした場合のスクリプト製品としての提供形態なんですが、2パターンあります。

ユーザにとっては、一回こっきりお金を払えば、いつまでも使えるため、手持ちのリンデンドル(ゲーム通貨)が無くなってしまっても安心です。しかしサービス提供側は、未来永劫同じWebサービスを提供し続けなければいけなくなります*1。例えば自分がSLを辞めたくなったり、サーバを潰したりしたくなったからといって、サービスを打ち切ってしまうと、「使えなくなったぞこの糞製品」と某所でDISられる可能性もあります。

  • サービスとして提供し、毎月(自動的にユーザから代金を回収するスクリプトなどを使用して)お金を取る

サービス提供側はサービスを打ち切りたくなったり機能を追加したりしたときに、来月からサービス中止(値上げ)と宣言すれば、ユーザとの契約はいつでも変更できます*2。しかし、ユーザにとっては設置した瞬間に「この製品は、あなたから自動的にお金をとりますよ」とメッセージが出るわ、毎月いつのまにかリンデンドルの残高が減っていくわであまりいい気分がしなかったりします*3。説明書にサービス形態についての説明がちゃんと書かれていなかったり、書かれていても読解能力が無いユーザに買われてしまった場合、「この製品は危ない」とDISられる可能性もあります。

どっちの形態にしろ、小心者で飽き症の自分にはこれでやっていく自信はありません。だからといって、スタンドアロン製品を売ってまともに生計を立てるような販売力もありません。ジェネリックな製品*4を大量販売なんてなおさらです。ということで、気分を変えて和洋融合物の製作をまじめにやりだそうかとしています。でももうそろそろ現実世界に戻って、QTやらscalaやらのお勉強をしてみたかったりします。

*1:「私にはいつでもこのサービスを打ち切る権利がありますよ」と注意書きしてある製品も少なからずありますが

*2:そういった契約関係に慣れていない高齢者などに襟首掴まれる可能性はなくはないですが

*3:ユーザにお金を支払うシステム(「ベンダー」といわれる商品販売システムや、「チップジャー」といわれるチップ自動支払いシステムなど)は、ユーザが製品を使って売上を上げたうちの何割かを天引きするという形態なので、残高がマイナスになることはないです

*4:既に市場に出回っているスクリプト製品を機能を真似て作り、先行よりも安く販売しているもの。スタンドアロンで完結する分には、現状で使えるAPIは限られているため、ある程度のプログラミングの素養がある人間がスクリプトの説明書さえ読めば、まったく同じ機能のスクリプトを簡単に作り出すことができます。セカンドライフをやっている人たちの中では、「パクリ製品」と呼ぶそうです。日本の「スクリプト屋さん」と言われるショップの大部分がこれで成り立っているみたいです

2008-06-15

スクリプトの機能的な価値とお客から見た価値の差異について

13:40

http://d.hatena.ne.jp/gothedistance/20080612/1213250813#tb

最近よく出入りしているクライアントで見聞きして感じたことと、上のエントリで言及されていることがよく似ているので紹介。

私はRLではSIer下請けのようなことをしてますが、SLではスクリプトのパッケージ販売兼受託カスタマイズのようなことをしてます。RLでは元請けの顔しか見えず、お客さんの顔を見ることがなく、ともすればこの案件は無難に片付ければいいか的仕事に陥りがちになります。しかしSLで同じような感じで仕事をすると、発売したパッケージは売れないわお客との縁は切れてさようならになるわ、ろくなことがないと分かっているのでRL以上に気を遣ってます。

しかし力の入れ方を間違えると、努力したつもりなのにさっぱり売れないといったことがままあります。逆に、スクリプトなど全く分からない人が、他の人が作ったスクリプト商品をバシバシ売っていけてしまう、ということもままあります。そういう人に色々理由を聞いたところ、お客さんの心理を考えたディスプレイや価格設定だったり、商品の大雑把な機能だけを押さえてあとは想像を膨らませて「こんなことにも使えますよ」と提案していたり、どうも技術屋からすると胡散臭いの一言で済まされそうなことに力を入れているみたいです。


良いものをサプライすることと、良いものであると価値を説明し納得してもらうことは、全く別物。


うちの商品は、リリースするときに何パターンかの使い方を想定してそれを売り文句にして出しているのですが、あとあと使いこなしているクライアントに話を聞くと、全く別の使い方で使いこなしていたりします。パッケージ商品になると、どうしても「こうやって使ってほしい」という願望が下心に現われて、それが商品パネルに現われたりしてしまうのですが、きっと「ふーん、これなら私の店には用がなさそうなスクリプトね」とスルーされることになっています。逆に、自分がクライアントの現場を見て、どんなお客さんがどんな過ごし方をするところなのかを把握した上で、商品紹介すると、お客さんに真剣に検討してもらえる確率が高くなったりします。

それは買ってもらった後のサポートも同じことで、「○○が動かないんだけど」という疑問に対して、技術的に(SLの仕様で)こういう理由で動かないんです、という説明が、技術者的に「正しい」回答なんですが、それでお客さんが納得してくださるかは別で、いったいこのお客さんはこの製品を何に使おうとして動かないと仰せなのかを行間をよみまくって質問しまくって、製品にこだわらずその問題を解決する手法を見つけて提案するのが、クライアント的からみると「正しい」回答なんかなあ、と思うようになりました。なかなか時間がとれないし、外国人だったらクライアントが起きてる時間に英語で話をしないといけないので、全てをそのやり方でやるのはしんどいですけど。

エンジニアである以上常に良いものをサプライしたい、常にコードを書いていたい。そういった願望がありますので、様々な技術情報を収集をしていく。技術的な興味を中心においてしまうと視線が内向きになってしまう。その弊害をはぶさんは指摘されていますが、これはSI業界の多重下請け構造にも一因があります。クライアントの顔が見えないポジションで仕事をしているケースが非常に多いのです。クライアントの困りごとを聞ける環境になかったら、どうしようもないということ。これは大きな問題です。なんにせよ、営業が出来るエンジニアはマジで最強です。そういう視点を持つと自分の望む仕事が獲得できる可能性も高くなると思う。

はい、RLではクライアントの顔が全く見えません。きっとクライアントからみるとどうしようもないものを納品しているんだと思うんですが、元請けからの評価基準が技術的な生産性や(機能的な)品質指標となっているので、どうしてもそっちをクリアすることに専念してしまいます。生活が大事なエンジニアは、そっちをクリアするための技術獲得には余念がありません(笑

2008-06-09

ToolDirectoryの詳細

| 20:29

・カテゴリごと

・検索

・英語のツールは日本語で使い方載せる

・ツールの販売自体は行わず、SLURLかSLExchangeのURLをのせるかにする

解決しないといけないこと

・登録制にする?それとも自由に書いていってもらう?

 →最初はyahooのように登録依頼を自分でさばいたほうが確実か。記述レベルがそろってきたら自由に書いていってもらうようにする

ScripterDirectoryの詳細

| 21:04

スクリプタープロフィールの表示(得意分野3つまでとか)

スクリプタープロフィールや案件は検索できるようにする

・プロフィールに、受注したオファーの内容も書けるといいなあ

・オファーに、オファーについての質問を受け付けるところがあるといいなあ

・ソース公開を要求するかしないかも書けるといいなあ

・オファーされたものが届いたかを発注者側が確認してチェックを入れる(検収?)

・オファー成立したら成立金額とオファー内容を公開(それまでは伏せる)

・発注した人もレビューを受けるようにする(取り逃げ防止)

・レビューは何回でも書き換え可能


希望内容登録→オファー受付→締切&選定→決定者にメール→あとはよしなに→両方に対するレビュー登録


先にToolFinderを検討して、公開してから裏でScripterFinderを作る


解決しないといけないこと

・成立後、直接やり取りさせると成立金額無視されて法外に請求されたりするかも → 間に入る?それとも自己責任でやってもらう?

 →自己責任かなあ。お金を先にしたら生産物来なくなる危険性があるし、生産物先にしたらお金来なくなる危険性があるから、どっちもどっちなような気がする。それだったら仲介してあとは双方で連絡とってもらった方がやりやすいのかも

・レビューの人数が少ないと受注者にとって不利なことを書けなくなるかも

・お互いの名前はどこまで公開する?

 →オファー段階では発注者は一応全員の見れて、受注者は見れない。成立したら双方のは見れて、一般に受注者の名前が公開される。まだ作りこんでみないとわからない。

いまはじめようとしていること

| 20:16

どうもこんにちは。まこぽっぽといいます。

今日から新しいことを始めようとしているので、自分が忘れないように日記を作りました。

やりたいこと

| 20:25

セカンドライフの中で、自分のやりたいことを実現するようなスクリプトをだれもが早く手に入れる仕組みを作ること。

なんで?

| 20:25

今巷に「こんなスクリプトが欲しい」という質問が殺到していますが、それに対してプログラム言語の知識を学習するように(暗に)要求するような回答が多々みられます*1。確かに質問者のなかにはスクリプトを学習したいと思っている人はいるでしょう。しかし、実際のインワールドでの感触からは*2、このような質問をしてくる人の多くが、「言語的な構造なんてどうでもいいし、プログラム言語の知識を1から勉強するような時間と体力はないよ。それよりも物体の中に投げ込んだらすぐに動いてくれるような(完成した)スクリプトがすぐに欲しいんだよ」と思っているのではないかと思ってます。この背景から、言語構造を意識せずに、やりたい!と思ったことがすぐに実現できるような仕組みを提供できれば、スクリプトで四苦八苦する時間をもっと有意義な構想の時間に充てることができるので、幸せになれるんじゃないかなあと考えました。*3

どんなものを提供するの?

| 20:25

今のところ、こんなものを計画しています。

Tool Directory

SL上に散らばっているツールを、作者による売り込みその他のバイアスをなくした状態でYahoo!のようなディレクトリに再構成し、英語のツールは日本語による使い方を掲載しながら、探しやすい状態でまとめたサイト。*4

Scripter Directory

やりたいことを登録すると、事前に登録したスクリプターさんがオファーを出し、頼んだ人はいちばんいいと思うオファーを選んで返事ができるという仕組み。


以上、こんなところです。

*1スクリプトの記述言語はLSLといって、C言語を不親切にしてステートという概念をもたせたような感じのものです。なんとincludeが全くできず、変数定数はそれぞれのファイルに定義しなければならないわ、他のファイルに書いた関数は、自分でメッセージング処理を書かなければ呼び出せないわで、C言語に親しんでいる人でも慣れるまで相当の時間がかかる割には、これに慣れてしまうと日常のPGにちょっと悪影響を及ぼしたりもします。ただ、言語マニアの人にとっては、今の実装はとってもおいしい材料りますので、ぜひ中に入ってトライしてみるといいと思います。

*2:私が接しているセカンドライフ中の人のほとんどが、40代以降(≠マの人)か、女性(≠同様)のようです。50代60代はごろごろいます。今や、3Dオタクの巣窟というより、昼間の団地のような状態なんじゃないでしょうか。特に長時間インしている人たちは。

*3:提供といっても、全部のスクリプトを無料提供しようということではないです。スクリプトを作る人も幸せになるには、MMOという性質上、どうしてもお金が絡んできます。今のところ、あとあとめんどくさいことにならないように、スクリプトを作った人はそれ相応の対価をもらうという方針でいこうとしてます。

*4:現在は「SL Exchange」に適当な検索語を突っ込んで探したり、各サイトの質問コーナーで探したりしている方が大半と思われます。SL Exchangeは作者が高い掲載料を払えば上の方に掲載されるというバイアスがあり、しかも英語サイトなので、とっても英語が堪能な日本人以外には使いにくい構造となっています。